WO2024050754A1 - Procédé de démarrage de client, premier dispositif, dispositif de configuration et plateforme en nuage - Google Patents

Procédé de démarrage de client, premier dispositif, dispositif de configuration et plateforme en nuage Download PDF

Info

Publication number
WO2024050754A1
WO2024050754A1 PCT/CN2022/117782 CN2022117782W WO2024050754A1 WO 2024050754 A1 WO2024050754 A1 WO 2024050754A1 CN 2022117782 W CN2022117782 W CN 2022117782W WO 2024050754 A1 WO2024050754 A1 WO 2024050754A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
request
cloud platform
information
user
Prior art date
Application number
PCT/CN2022/117782
Other languages
English (en)
Chinese (zh)
Inventor
茹昭
吕小强
包永明
张军
杨宁
Original Assignee
Oppo广东移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oppo广东移动通信有限公司 filed Critical Oppo广东移动通信有限公司
Priority to PCT/CN2022/117782 priority Critical patent/WO2024050754A1/fr
Publication of WO2024050754A1 publication Critical patent/WO2024050754A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Definitions

  • the present application relates to the field of communication technology, and more specifically, to a method for starting a client, a first device, a configuration device and a cloud platform.
  • the client is usually a temporary client, or the user type of the client is a temporary user
  • a complete connection plan needs to be executed when establishing a connection between the client and the cloud platform, that is to say, a complete connection plan needs to be executed
  • Client configuration process, client registration process, and client login process are stipulated that a complete connection plan needs to be executed
  • Client configuration process, client registration process, and client login process are stipulated that a complete connection plan needs to be executed.
  • client configuration process, client registration process, and client login process Client configuration process, client registration process, and client login process.
  • the user types corresponding to the client also include long-term users. For long-term users, complex connection solutions will degrade the user experience if the connection between the client and the cloud platform needs to be re-established before each use of the client. Therefore, traditional connection solutions are not compatible with both temporary user and long-term user scenarios.
  • This application provides a method for starting a client, a first device, a configuration device and a cloud platform.
  • a client a first device
  • a configuration device a configuration device
  • a cloud platform a cloud platform
  • a method for starting a client including: a first device receiving a first request sent by a configuration device, the first request being used to request starting the client in the first device, the The client is used to communicate with the cloud platform.
  • a method for starting a client including: the cloud platform communicates with a client configured in a first device, the client of the first device is started based on the first request, and the third A request is used to request to start the client.
  • a method for starting a client including: configuring a device to send a first request to a first device, the first request being used to request to start a client in the first device, and the client The terminal is used to communicate with the cloud platform.
  • a first device including: a receiving unit configured to receive a first request sent by a configuration device, the first request being used to request to start a client in the first device, and the client The terminal is used to communicate with the cloud platform.
  • a cloud platform including: a communication unit configured to communicate with a client configured in a first device, where the client of the first device is started based on a first request, and the first Request is used to request to start the client.
  • a configuration device including: a sending unit configured to send a first request to a first device, the first request being used to request to start a client in the first device, and the client Used to communicate with the cloud platform.
  • a seventh aspect provides a first device, including a processor, a memory and a communication interface, the memory is used to store one or more computer programs, the processor is used to call the computer program in the memory, so that the The first device performs some or all of the steps of the method of the first aspect.
  • An eighth aspect provides a cloud platform, including a processor, a memory, and a transceiver.
  • the memory is used to store one or more computer programs.
  • the processor is used to call the computer program in the memory so that the cloud The platform performs some or all of the steps in the method of the second aspect.
  • a ninth aspect provides a configuration device, including a processor, a memory, and a transceiver.
  • the memory is used to store one or more computer programs.
  • the processor is used to call the computer program in the memory so that the configuration
  • the device performs some or all of the steps of the method of the third aspect.
  • embodiments of the present application provide a communication system, which includes one or more of the above-mentioned first device, configuration device, and cloud platform.
  • the system may also include other devices that interact with terminal devices or network devices in the solutions provided by the embodiments of this application.
  • embodiments of the present application provide a computer-readable storage medium that stores a computer program, and the computer program enables a communication device (for example, a first device, a configuration device, and a cloud platform ) performs some or all of the steps in the methods of each aspect described above.
  • a communication device for example, a first device, a configuration device, and a cloud platform
  • 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, and the computer program is operable to cause the communication device ( For example, the first device, the configuration device, and the cloud platform) perform some or all of the steps in the methods of the above aspects.
  • the computer program product can be a software installation package.
  • embodiments of the present application provide 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. .
  • a request for starting the client (also called the "first request") is introduced to start the client to accommodate the needs of both long-term users and temporary users.
  • the configuration device can directly request to start the client by sending a first request to the client. Compared with the traditional connection scheme, it does not require Repeating the client configuration process helps simplify the connection solution and improve user experience.
  • the configuration device may also request to start the client corresponding to the temporary user by sending a first request to the first device.
  • Figure 1 is a schematic diagram of the system architecture applicable to the embodiment of the present application.
  • Figure 2 is a model structure of a Matter device applicable to the embodiment of this application.
  • Figure 3 is a flow chart for connecting the client to the cloud platform.
  • Figure 4 is a flow chart for starting a client according to an embodiment of the present application.
  • Figures 5(a) to 5(c) are schematic flowcharts of a method for starting a client according to an embodiment of the present application.
  • 6(a) to 6(c) are schematic flow charts of a method for starting a client according to another embodiment of the present application.
  • Figure 7 is a schematic diagram of the first device according to the embodiment of the present application.
  • Figure 8 is a schematic diagram of the cloud platform according to the embodiment of the present application.
  • Figure 9 is a schematic diagram of a configuration device according to an embodiment of the present application.
  • Figure 10 is a schematic structural diagram of a communication device according to an embodiment of the present application.
  • Figure 1 is a schematic diagram of the system architecture applicable to the embodiment of the present application.
  • the system 100 shown in Figure 1 may include a first device 110, a configuration device (mediator) 120, a cloud platform 130 and a second device 140.
  • the first device 110 may be a device capable of communicating with the cloud platform 130 .
  • the first device 110 may be provided with a client, and the client may be used to communicate with the cloud platform 130 and communicate with the second device 140 through the cloud platform 130 .
  • the user can access the cloud platform 130 through the client and access the second device 140 through the cloud platform 130 .
  • the user can access the cloud platform 130 through the client and control the second device 140 through the cloud platform 130 .
  • the above-mentioned client may be an application (application, APP) or an applet, etc.
  • the second device 140 may be a device capable of communicating with the cloud platform 130 .
  • the second device 140 can provide service functions for users. Therefore, the second device 140 can also be called a server (server) or a service device.
  • the configuration device 120 is used to configure the first device 110 and/or the second device 140 .
  • the configuration device 120 may configure the first device 110 and/or the second device 140 to communicate with the cloud platform 130 .
  • the configuration device 120 can configure the client in the first device 110 so that the client can communicate with the cloud platform 130 .
  • the configuration device 120 may be an application (application, APP) or applet.
  • the configuration device 120 can be installed on a terminal device, where the terminal device can be a mobile phone, a tablet computer (Pad), a notebook computer, a handheld computer, a mobile internet device (mobile internet device, MID), a wearable Equipment, virtual reality (VR) equipment, augmented reality (AR) equipment, wireless terminals in industrial control, wireless terminals in self-driving, remote surgery (remote medical) Wireless terminals in surgery, wireless terminals in smart grid, wireless terminals in transportation safety, wireless terminals in smart city, and wireless terminals in smart home wait.
  • the embodiments of the present application do not limit this.
  • Cloud platform 130 also known as cloud computing platform or “cloud” can be understood as providing network communication capabilities for services based on hardware resources and software resources. Therefore, in this embodiment of the present application, the client in the first device 110 can access or control the second device 140 through the cloud platform 130 .
  • the cloud platform 130 can be built based on one or more cloud servers to provide network functions.
  • the above-mentioned cloud platform 130 can also be other systems or devices that can provide network functions.
  • a cluster system that can provide network functions, etc.
  • the embodiments of the present application do not limit this.
  • configuration device 120 may be an APP or applet that matches the client.
  • configuration device 230 may be a different APP or applet from the client. The embodiments of the present application do not limit this.
  • the above-mentioned system 100 may be, for example, an Internet of Things (IoT) system.
  • IoT Internet of Things
  • the Internet of Things is the "Internet where everything is connected", which can be understood as a network that is extended and expanded based on the Internet. Any item can be connected to the Internet through various information sensing devices (such as radio frequency identification, global positioning systems, etc.) Together they form a huge network for information exchange and communication to achieve interconnection between all things.
  • the above-mentioned first device and/or second device may be an IoT device.
  • IoT devices can include vehicle-mounted terminals, smart home equipment, intelligent monitoring equipment, etc.
  • Smart home devices may include, for example, smart air conditioners, smart refrigerators, washing machines, rice cookers, sweeping robots, and other devices.
  • Intelligent monitoring devices may include, for example, surveillance cameras, temperature sensors, sound sensors and other devices.
  • the above-mentioned cloud platform may be an IoT cloud platform, referred to as "IOT cloud", which is used to provide communication service functions for IOT devices in the IOT system.
  • IOT cloud an IoT cloud platform
  • the system 100 is introduced taking an IoT device as an example.
  • the first device 110 is a vehicle-mounted terminal
  • the second device 140 is a smart home device
  • the configuration device 120 can be a terminal device.
  • the terminal device 120 can configure the client in the vehicle-mounted terminal 110 so that the client can communicate with the cloud platform 130 .
  • the user can access and/control the smart home devices on the cloud platform (or smart home devices connected to the cloud platform) through the client.
  • a client that can access and/or control smart home devices can also be called a "smart home client".
  • the client can control the switch of the smart air conditioner and set the air conditioner temperature, wind speed, etc. through the cloud platform.
  • the client can control the sweeping robot to start or stop working, control the working mode of the sweeping robot, etc. through the cloud platform.
  • the Connectivity Standards Alliance launched an Internet of Things application layer technology standard—Matter Standard Protocol, which can provide an interoperable application layer for smart home devices based on Internet Protocol (Internet Protocol, IP) solution.
  • IP Internet Protocol
  • the matter standard may also be called a connected home over IP (CHIP) standard.
  • 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.
  • the client introduced above supports the Matter protocol, it can be called a "Matter client”.
  • the above-mentioned second device supports the Matter protocol, it can be called a “Matter server”.
  • the first device and/or the second device supporting the Matter protocol may also be called “Matter devices”.
  • Figure 2 is a model structure of a Matter device applicable to the embodiment of this application.
  • the data model structure 200 of the Matter device includes a node 210, an endpoint 220, and a cluster 230.
  • Node 210 encapsulates an addressable and unique resource on the network, has a set of functions and capabilities, and the user can clearly view it as a functional whole.
  • node 210 may be the highest or outermost first-order element in the data model. In other words, node 210 is the only addressable element in the outermost layer of the data model.
  • one physical entity can support multiple nodes 210 .
  • a node can have multiple node 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 within the scope of the specified node ID is the access network for the interaction.
  • a node may include one or more endpoints 220. Endpoint 220 is an instance, which can be a service or a virtual device, as indicated by the device type. Each endpoint 220 conforms to one or more device type definitions that define the clusters supported on the endpoint. Whereas a cluster is an object class instantiated on an endpoint.
  • a device type defines a consistent set of endpoints 220.
  • a device type defines a set of requirements for a node 210 or endpoint 220.
  • Clusters 230 are functional building block elements of the data model, and thus clusters may also be referred to as “functional sets”, “functional clusters", “functional clusters”, etc.
  • the cluster specification defines clients and servers that interact with each other.
  • Cluster 230 can be viewed as an interface, service or object class, which is the lowest independent functional element in the data model.
  • Each cluster 230 is defined by a cluster specification that defines the elements of the cluster 230, including properties, events, commands, and behaviors related to interactions with these elements. Properties, events, commands, and behaviors in cluster 230 are mandatory or optional, depending on the definition of cluster 230 .
  • the above clusters can be divided into two categories: utility cluster (utility cluster) or application cluster (application cluster).
  • Utility clusters are not part of the endpoint's primary application operations. It can be used for configuration, discovery, addressing, diagnostics, monitoring device health, software updates, and more. It may have a temporary relationship with its cluster counterpart.
  • the utility cluster may include a client cluster.
  • Application clusters support the primary operations of endpoints.
  • Application clustering supports one or more persistent application interactions between clustered clients and clustered servers.
  • the client of the cluster can send control commands to the server of the cluster (i.e., switch cluster) to control the switch of the smart light.
  • a cluster command (also known as a "command") is a set of data fields, each data type, that is passed between client and server cluster instances to invoke the behavior of the command recipient.
  • each command can be listed in a table, which can contain the data quality columns of the command: identification (ID), name (name), direction (direction), response (response), access (access) ), constraint and 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.
  • Attributes can be understood as cluster data. Currently, the agreement stipulates that each attribute can be listed in a table, including a data quality column. Data quality columns can include ID, name, (data) type, constraints, other qualities, access, default (value), and consistency. In some implementations, properties may also define their associated semantics and behavior. Properties can reflect the device's queryable/settable status, configuration, and capabilities. In some cases, if no privileges are explicitly defined for a property, default access privileges take effect.
  • commands and attributes in the embodiments of this application may also include other quantitative qualities, or include part of the above-mentioned data qualities.
  • the embodiments of the present application do not limit this.
  • Identification represents the unique field ID of the field, or in other words, it is the unique identification of the command.
  • Name represents the unique name of the field, or in other words, the name of the command.
  • the value of the data type can be an octet string, expressed as "octstr or octstring"; the value of the data type can be a string (string); the value of the data type can be X Bit unsigned number (unsigned X-bit integer, uintX), where the value of ; Boolean value is represented as "bool”.
  • 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 client to server. For another example, it can be determined from the server to the client.
  • Access permissions are used to define how an element can be accessed (such as read or write) and what permissions are required to access the data.
  • access rights may include V, where V indicates that read access or call access requires view privileges.
  • Access permissions can also include O, which means "read access”, “write access” or “call access” require operation permissions.
  • Access permissions can also include R, which stands for read access.
  • Access permissions can also include W, which represents write access.
  • Responses usually present in a command list, are used to define the command's response.
  • Default used to define the default value. It should be noted that the default value is not the value used when the service device returns to the factory refresh settings. The default value can indicate that the consistency specified for the data field can be optional or change over time. Default values can be defined to complete the dependency when the actual data field value is not present.
  • Consistency used to define the optionality and dependencies of any data model element or set of elements.
  • this column is valid for properties, commands, events, enumerations, and fields of commands, events, or structures.
  • "M" indicates that the corresponding command is part of the basic mandatory feature set.
  • client-to-server command consistency means that the server should recognize and support client-to-server commands and generate responses as defined.
  • Server-to-client command consistency means that the server should send commands in a manner defined by cluster behavior, i.e., in response to client-to-server commands. The consistency of the command depends on the supported server features. Clients should not be required to support optional commands or commands that rely on optional features.
  • constraints can contain all and desc. Among them, all is used to define that all values are allowed in numeric data types. Desc is used to indicate that the constraints are defined in the description section. In other cases, constraints can also indicate the maximum value of the corresponding parameter value, expressed as "max N". For example, in the embodiment of this application, when N is 99, "max 99" is used to indicate that the maximum value of the corresponding parameter is 99. For another example, in the embodiment of this application, when N is 400, “max 400” is used to indicate that the maximum value of the corresponding parameter is 400. In other cases, constraints can be used to define the number of bytes occupied by parameters. For example, when the value of the constraint is 32, it is used to indicate that the number of bytes occupied by the corresponding parameter is 32.
  • Range represents the value range of the field.
  • the range can support two forms: explicit constraints and width constraints.
  • explicit constraints can indicate the minimum and maximum values corresponding to the values of the fields.
  • explicit constraints indicate that the value range of a certain field is (0, 128).
  • the above width constraint can be used to limit the number of bytes occupied by the value of a field, or in other words, the width constraint can limit the value of a field to a specific number of bytes.
  • a width constraint can indicate that the maximum number of bytes occupied by the value of a certain field is 8 bytes.
  • the client needs to establish a connection with the cloud platform based on the connection solution between the client and the platform.
  • the connection solution between the client and the platform includes the client configuration process, client registration process, client login process, etc. The following describes the client configuration process, client registration process, and client login process in conjunction with steps S311 to S327 shown in FIG. 3 .
  • step S311 the configuration device determines that the first device has the capability to support the client.
  • the configuration device can query the capabilities of the first device to determine whether the first device supports the configuration client.
  • the first device can also directly configure and report the capability of the first device, so that the configuration device can determine whether the first device supports the configuration client.
  • step S312 the configuration device pops up a dialog interface, prompting the user to choose whether to agree to use the first device to control the second device.
  • step S313 if the user agrees to use the first device to control the second device, the configuration device sends a certificate request to the first device.
  • CSR certificate signing request
  • step S314 the client generates a key pair and stores the private key in the key pair in the safe zone.
  • step S315 the client sends a CSR response command to the configuration device to transmit the CSR.
  • CSR may be a CSR data format defined in public key cryptography standards (PKCS) #10. Accordingly, CSR can follow the following principles: CSR carries certificate request information, which can include version information, subject information, public key information, etc.
  • the subject information may include the vendor ID of the first device, the product ID of the first device, etc.
  • the public key information may indicate the public key in the above-mentioned key pair (see step S340).
  • the above-mentioned supplier ID of the first device and the product ID of the first device can be obtained from the data recorded in the basic information cluster (general_Info cluster) of the first device.
  • the above-mentioned CSR can be digitally signed, and the digital signature of the CSR can be generated based on the private key in the key pair.
  • step S316 the configuration device sends information 1 to the cloud platform, where information 1 is used to apply for a cloud connection credential, that is, an access token (access token) for the client, and information 1 carries a CSR.
  • a cloud connection credential that is, an access token (access token) for the client
  • information 1 carries a CSR.
  • step S317 after the CSR verification is passed, the cloud platform can assign a client identification to the client.
  • step S318 the cloud platform generates the client's certificate based on the client ID and public key corresponding to the client.
  • step S319 the cloud platform allocates an access token to the client and establishes a binding relationship between the user ID, client ID and access token.
  • step S320 the cloud platform uses the client's public key to encrypt the access token to obtain an encrypted access token.
  • step S321 the cloud platform sends information 2 to the configuration device to indicate the client's certificate and CToken.
  • the parameters contained in the above information 2 may include CToken, certificate chain (CertChain) and token expiration (TokenExpiration) information.
  • CToken certificate chain
  • CitChain certificate chain
  • TokenExpiration token expiration
  • Table 1 shows information such as the parameters included in the information 2, the value type of the parameters, whether the parameters are necessary, and the description of the parameters.
  • step S322 the configuration device sends information 3 to the first device to configure the client's certificate, CToken, and cloud registration address for the client.
  • the configuration parameters in the above information 3 can include: client certificate (represented by "ClienCert”), intermediate certificate (represented by “IntermediateCert”), root certificate (represented by "RootCert”), cloud address of the cloud platform (cloud address) , CToken and token expiration information.
  • client certificate represented by "ClienCert”
  • intermediate certificate represented by "IntermediateCert”
  • root certificate represented by "RootCert”
  • cloud address of the cloud platform cloud address
  • CToken and token expiration information can be found in Table 2.
  • Table 2 shows the parameters included in the information 3, the field where the parameter is located, the identifier of the parameter, the data type of the parameter, the constraints of the parameter, the necessity of the parameter, and the description of the parameter.
  • step S323 the first device decrypts the information 3 using the private key to obtain the above parameters in the information 3. And configure the client based on the above parameters.
  • step S324 the client connects to the cloud platform based on the cloud address and uses the client certificate to establish a secure connection with the cloud platform.
  • step S325 the client sends a registration request (also called “cloud registration request” or “client registration request”) to the cloud platform.
  • a registration request also called “cloud registration request” or “client registration request”
  • the above registration request can carry the client ID and access token.
  • Table 3 shows the interface description of the registration request.
  • the hypertext transfer protocol (HTTP) method based on the registration request can be the POST method, and the interface access address of the registration request can be the account (account). .
  • HTTP hypertext transfer protocol
  • Table 4 shows the interface parameters of the registration request. Table 4 points out the position of the parameters in the registration request in the request, the name of the parameter, the value type of the parameter, whether the parameter is necessary, and the description of the parameter and other information.
  • Location parameter value type necessity illustrate body access token string yes Client access token main body Client ID string yes The client ID assigned to the client by the cloud platform.
  • step S326 the cloud platform sends a registration response command (also called “cloud registration response") to the configuration device.
  • the registration response command will carry the updated access token sent by the cloud platform.
  • the cloud platform does not need to update the client's access token.
  • Table 5 shows the parameters included in the registration response command, the location of the parameters, the value type of the parameters, whether the parameters are necessary, and the description of the parameters.
  • step S327 the client of the first device logs in to the cloud platform based on the client identifier and the access token carried in the registration response.
  • the user After successfully logging into the cloud platform, the user can communicate with the second device on the cloud platform through the client. For example, discover the second device, access the second device, control the second device, etc.
  • the client is usually a temporary client, or the user type of the client is a temporary user, therefore, when establishing a connection between the client and the cloud platform, it is stipulated that the complete solution shown in Figure 3 needs to be executed, that is to say , need to perform the client configuration process, client registration process and client login process.
  • the user types corresponding to the client also include long-term users. For long-term users, complex connection solutions will degrade the user experience if the connection between the client and the cloud platform needs to be re-established before each use of the client. Therefore, traditional connection solutions are not suitable for long-term user scenarios.
  • the embodiment of the present application provides a solution for starting a client, and introduces a request for starting the client (also called a "first request") to be compatible with the needs of long-term users or temporary users.
  • a request for starting the client also called a "first request”
  • the configuration device can directly request to start the client by sending a first request to the client.
  • the configuration device may also request to start the client corresponding to the temporary user by sending a first request to the first device.
  • Figure 4 is a flow chart for starting a client according to an embodiment of the present application.
  • the method shown in Figure 4 includes step S410.
  • step S410 the configuration device sends a first request to the first device.
  • the first request is used to request the first device to start the client (also called “client to be started”). Therefore, the first request can also be called “start client request” (start client request).
  • the user type of the above-mentioned client may be a long-term user, or in other words, the above-mentioned client may be a long-term client.
  • the user corresponding to the client may be the owner of the vehicle.
  • the user type of the above-mentioned client can also be a temporary user, or in other words, the above-mentioned client can be a temporary client.
  • the user corresponding to the client may be a temporary passenger of the vehicle.
  • the first device may also send a response command to the first request (see step S420) to the configuration device to indicate whether the client is successfully started.
  • the first request may indicate the client to be activated by carrying indication information of the client to be activated.
  • the indication information may be, for example, a client identifier.
  • the client can be started based on the startup password, where the startup password is used to verify whether to start the client, or in other words, the startup password is used to authenticate the user who starts the client, or in other words, to start the client.
  • the password is used to authenticate to the configuration device. If the startup password is used to authenticate the configuration device, the startup password can also be called the configuration device password (mediator password, MedPassword).
  • the first request may carry the client's startup password.
  • the startup password carried in the first request matches the startup password of the client prestored in the first device, the client can be started.
  • the startup password carried in the first request does not match the startup password of the client prestored by the first device, the client may be refused to be started.
  • the above matching can be understood as the startup password carried in the first request is the same as the pre-stored startup password of the client, or the startup password carried in the first request is different from the pre-stored startup password of the client but satisfies the preset correspondence. relation.
  • the embodiments of the present application do not limit this.
  • the client can inform the configuration device of the client's startup password, so that when the configuration device starts the client through the first request, it can carry the startup password in the first request.
  • the client can carry the above-mentioned startup password through the add cloud response command (also known as the "response command for the second request").
  • the add cloud response command may include: status code (status code) and startup password, where the status code is used to indicate to the client Whether the cloud platform was added successfully.
  • the first device may be equipped with clients that communicate with different cloud platforms, and the client identifiers of these clients may be the same.
  • the first request may carry the cloud platform corresponding to the client to be started. Instruction information so that the first device can identify the client to be started.
  • the first request may only carry the unique identifier corresponding to the client to be started, and no longer carry the indication information of the cloud platform.
  • the above indication information of the cloud platform may be any information used to identify the cloud platform, which is not limited in the embodiments of the present application.
  • the indication information of the cloud platform may be the identification of the cloud platform (cloud ID).
  • the indication information of the cloud platform may be the address of the cloud platform.
  • the parameters in the first request may include the client identifier of the client to be activated, the activation password of the client to be activated, and the cloud address corresponding to the client to be activated.
  • Table 7 also shows the data type of the parameter, the identification of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter and the necessity of the parameter.
  • the first device may determine the client to be started based on the client identifier in the first request. Then based on the correspondence between the pre-stored client identification and the startup password, it is determined whether the pre-stored startup password of the client to be started matches the startup password in the first request. And based on the corresponding relationship between the pre-stored client and the cloud address, it is determined whether the pre-stored cloud address of the client to be started matches the cloud address in the first request.
  • the first device can start the client to be started, and send a response command to the first request to the configuration device to indicate that the client is started successfully.
  • the first device may refuse to start the client to be started, and send a response command to the first request to the configuration device to indicate that the client fails to start.
  • client information such as client identification and cloud platform indication information introduced above can be maintained as attributes of the functional cluster.
  • the first device may include a function cluster (also called a "client function cluster"), and the function cluster is used to record the client in the first device.
  • the first device may be recorded in the functional cluster, and for information about clients of temporary users, the first device may not be recorded in the functional cluster.
  • the functional cluster can include attributes: long-term user list (or long-term client list), the constraint of this attribute can be "all”, the quality of this attribute can be "N”, and the permission of this attribute can be " R”, the default value of this attribute can be "empty”, the necessity of this attribute can be "M”, the data type of this attribute can be a list, and the client structure (represented as "ClientStruct” is recorded in the list ").
  • the client information recorded in the client structure can be as shown in Table 9, including client identification, user identification and cloud address.
  • Table 9 also shows the data type of the parameter, the identification of the parameter, the constraints of the parameter, the quality of the parameter, the authority of the parameter, the default value of the parameter and the necessity of the parameter.
  • the configuration device may query whether there is a suitable client in the first device (for example, a client corresponding to the cloud platform where the configuration device is located). If it is determined that the first device is configured with If there is a suitable client, the configuration device can request the first device to start the client by sending a first request.
  • a suitable client for example, a client corresponding to the cloud platform where the configuration device is located.
  • the configuration device can determine that the first device has been configured with a client connected to the cloud platform. At this time, the configuration device can directly start the client through the first request.
  • the information of the client in the first device can be maintained through the functional cluster.
  • the commands supported by the client for example, the command for configuring the client and/or the command for starting the client
  • the above functional cluster also includes commands supported by the client.
  • the above functional cluster includes one or more of the following commands: a first request; a response command for the first request; a second request for instructing the client to add the cloud platform; a response command for the second request , where the response command for the second request is used to indicate whether the cloud platform is added successfully; the third request for requesting the client's CSR; the response command for the third request, where the response command for the third request is used to
  • the cloud platform requests a certificate from the client for authentication.
  • the above second request is also called add cloud request.
  • the second request includes one or more of the following information: the client's certificate information for authentication on the cloud platform, the cloud platform's Instruction information, as well as access token information of the cloud platform.
  • the response command for the second request may also be called "add cloud response command”.
  • the response command to the second request includes: information indicating whether the cloud platform is successfully added, and/or the client's startup password.
  • the above third request may also be called a CSR request command, and accordingly, the third response command to the third request command may be called a "CSR response command".
  • the commands supported by the functional cluster in the embodiment of this application are introduced below in conjunction with Table 10.
  • the commands included in the functional cluster include CSR request command, CSR response command, add cloud request command, add cloud response command, and start client request command.
  • Table 10 also shows the identification corresponding to each command, the direction of the command, the response of the command, the authority of the command, and the necessity of the command.
  • the above-mentioned client information and commands supported by the client can also be maintained through multiple different functional clusters, which is not limited in the embodiment of the present application.
  • the parameters contained in each of the above commands will be introduced in detail below. For the sake of brevity, they will not be described again here.
  • the client configuration process may be triggered.
  • the configuration device can read the long-term user list in the first device. If a suitable client is not recorded in the long-term user list, the client configuration process can be triggered.
  • the configuration device determines that the first device is not configured with a client connected to the cloud platform.
  • the configuration device can trigger the client configuration process.
  • the first device may perform related operations slightly differently for a long-term user client or a temporary user client. Therefore, during the process of configuring the client, the configuration device may inform the first device of the user type of the client.
  • the configuration device may send first indication information to the first device to indicate the user type of the client.
  • the first indication information may indicate that the user type of the client is a long-term user, or the first indication information may indicate that the user type of the client is a temporary user.
  • the second indication information may indicate whether the user type of the client is a long-term user.
  • the second indication information may indicate whether the user type of the client is a temporary user.
  • the above-mentioned first indication information may be carried in a CSR request command (also called a third request).
  • the parameters of the CSR request command in the embodiment of this application are introduced below in conjunction with Table 11.
  • the CSR request can carry the parameter long-term user (ie, the first indication information) to indicate the user type corresponding to the client.
  • the identifier of the long-term user field can be 0, and the data type of this field can be a Boolean value.
  • the Boolean value is true (true)
  • it is used to indicate that the user type of the client is a long-term user.
  • the Boolean value is false, it is used to indicate that the client's user type is a temporary user.
  • first instruction information can also be carried in other commands except the CSR request command, or the first instruction information can also be carried in a dedicated command, which is not limited in the embodiments of the present application.
  • the first device may send a CSR response command (also called a "response command for the third request") to the configuration device, where the CSR response command carries the client's CSR.
  • Table 12 shows the parameters of the CSR response command in the embodiment of the present application. Refer to Table 12.
  • the CSR request can carry the parameter CSR.
  • Table 12 also shows the identification corresponding to the parameters, the data type of the parameters, the constraints of the parameters, the quality of the parameters, the default values of the parameters, and the necessity of the parameters.
  • the configuration device may send second indication information to the cloud platform to indicate the user type of the client.
  • the second indication information may indicate that the user type of the client is a long-term user, or the second indication information may indicate that the user type of the client is a temporary user.
  • the second indication information may indicate whether the user type of the client is a long-term user.
  • the second indication information may indicate whether the user type of the client is a temporary user.
  • the above-mentioned second instruction information may be carried in a client application request (also called an "application request"), where the client application request is used to apply for the client's certificate and token from the cloud platform.
  • client application request also called an "application request”
  • the client application interface description and the parameters in the client application request according to the embodiment of the present application in conjunction with Table 13 and Table 14. Refer to Table 13.
  • the HTTP method used by the client to apply for the interface is POST, and the interface access address is "/addclient".
  • Table 14 shows the parameters carried in the client application request command.
  • the application request command may include acceptance, Internet media type (content-type), access token, CSR, and long-term user.
  • Table 14 also shows the location, value type, necessity and description of the parameters.
  • the user type of the client may be configured by the user through the configuration device. That is to say, the user can select the user type of the client as a long-term user or a temporary customer by configuring the device.
  • the user can select the user type of the client as a long-term user or a temporary customer by configuring the device.
  • other methods can also be used to help the configuration device determine the user type of the client, and the embodiment of the present application does not limit this.
  • the cloud platform can send the client's certificate to the configuration device through a client application response command for the client application request.
  • the above certificate can be indicated by the parameter "CertChain” in the client application response command.
  • the above certificate may include one or more of a client certificate (represented by "ClienCert”), an intermediate certificate (represented by "IntermediateCert”), and a root certificate (represented by "RootCert”).
  • the client needs to access the cloud platform based on the access token.
  • the client may need to access the cloud platform multiple times. If the client uses the same access token each time to access the cloud platform, it may not be conducive to improving the security of the cloud platform. For example, for a long-term user client, the user may access the cloud platform multiple times through the client. If the access token remains unchanged, it may be intercepted by the attacker, threatening the security of the cloud platform.
  • the cloud platform can configure a first token (also called "refresh token") for the client, which is used by the client to request the cloud platform to update the access token. Accordingly, the client can access the cloud platform based on the updated access token.
  • a first token also called "refresh token”
  • the above access token update mechanism helps to improve the security of the cloud platform compared to always using the same access token to access the cloud platform.
  • the first device when the original access token of the first device expires, can apply to the cloud platform for updating the access token based on the first token.
  • the embodiment of this application does not specifically limit the timing of applying for an update token.
  • the first device can also apply to the cloud platform for an update access token based on the first token when the original access token is about to expire. . That is, the first device may apply to the cloud platform for updating the access token based on the first token at the target time, where the expiration time of the target time and the original access token is less than the first time interval.
  • the first device may periodically apply to the cloud platform for updating the access token, where the update period of the access token may be less than or equal to the validity period of the access token.
  • the above-mentioned first token may be carried in the registration response command.
  • Table 15 shows the interface parameters of the registration response command in the embodiment of this application. Referring to Table 15, the registration response command may include access token, token expiry, user identification and first token. Among them, the position of the above parameters in the command, the value type corresponding to the parameter, the necessity of the parameter, and the description of the parameter can be found in Table 15.
  • the first device can log in to the cloud platform based on the user identity, that is, the first device sends the second information to the cloud platform.
  • the second information is used to request to log in to the cloud platform. Therefore, the second information may be called a "login request".
  • the second information may include the user identification of the client.
  • the HTTP method of the login interface can be POST, and the access address of the login interface can be expressed as "/session”.
  • the login request command may include acceptance, Internet media type (content-type), access token, user ID, client ID, and login status (login).
  • content-type content-type
  • access token access token
  • user ID user ID
  • client ID login status
  • login status login status
  • the AMTP protocol can be used to communicate between the client and the second device.
  • the client needs to send the client's access address to the cloud platform so that subsequent communication can be based on the client's access address.
  • the above method also includes: the first device sends third information to the cloud platform, and the third information includes the access address of the client.
  • the access address is an access address based on the AMTP protocol.
  • the cloud platform can determine that the client selects the AMTP protocol for communication. That is to say, the third information is also used to indicate that the communication protocol supported by the client is the AMTP protocol. .
  • the above third information may be carried in a registration request, where the registration request is used by the client to request registration on the cloud platform.
  • the parameters carried in the registration request in the embodiment of this application are introduced below in conjunction with Table 18.
  • the registration request may include an access token, a client identifier, and a client access address (eg, client uniform resource locator (ClientURL)).
  • client URL client uniform resource locator
  • Table 18 also shows the position of each parameter in the command, the value type of the parameter, the necessity of the parameter, and the description of the parameter.
  • the third information may be carried in the login request, which is used by the client to request to log in to the cloud platform.
  • the parameters carried in the login request command in the embodiment of this application are introduced below in conjunction with Table 19. Compared with the parameters shown in Table 17, the parameters in Table 19 include the client access address (for example, ClientURL).
  • the cloud platform can inform the first device of the access address of the second device, that is, the access address of the second device based on the AMTP protocol (also known as "access URL"). "). That is to say, the above method further includes: in response to the third information, the first device receives fourth information sent by the cloud platform, where the fourth information includes the access address of the second device to be accessed by the client.
  • the client when the client successfully logs in to the cloud platform, the client can communicate with the second device based on the access address of the second device. For example, the client can send control information to the second device based on the access address of the second device to control the second device.
  • the above fourth information may be carried in a response command to the registration request, that is, a registration response command.
  • Table 20 shows the parameters included in the registration response command in this embodiment of the present application.
  • the registration response command includes an access token, a user ID, and an access URL, where the access URL is used to indicate the access address of the second device.
  • Table 20 also shows the position of the above parameters in the registration response command, the value type corresponding to the parameter, the necessity of the parameter, and the description of the parameter.
  • the above fourth information may be carried in a response command to the login request, that is, a login response command.
  • Table 21 shows the parameters included in the login response command in the embodiment of this application. As shown in Table 21, the login response command includes an access token, a client identifier, and a URL of the client, where the access URL is used to indicate the access address of the second device. In addition, Table 21 also shows the position of the above parameters in the login response command, the value type corresponding to the parameter, the necessity of the parameter, and the description of the parameter.
  • the transmission method of the third information and the transmission method of the fourth information introduced above can be used alone or in combination.
  • the third information may be carried in the login request, and accordingly, the fourth information may be carried in the login response command.
  • the third information may be carried in the registration request, and accordingly, the fourth information may be carried in the registration response command.
  • the third information may be carried in the registration request, and correspondingly, the fourth information may be carried in the login response command.
  • the third information may be carried in the registration response, and correspondingly, the fourth information may be carried in the login request.
  • the embodiment of the present application does not limit the order of interaction between the access address of the client and the access address of the second device.
  • the client may first send the client's access address to the cloud platform, and then the cloud platform may send the access address of the second device to the client.
  • the cloud platform may first send the access address of the second device to the client, and then the client may send the access address of the client to the cloud platform.
  • the cloud platform may send the access address of the second device to the client through a registration response command, and then the client sends the client's access address to the cloud platform through a login request.
  • the solution of the embodiment of the present application will be introduced below with reference to Figures 5 and 6, taking the IOT scenario as an example.
  • the above-mentioned cloud platform can be an IoT cloud platform
  • the client can be an IoT client
  • the first device can be a vehicle-mounted terminal
  • the second device can be a smart home device
  • the configuration device can be a mobile phone.
  • the command and information function clusters involved in Figure 5 and Figure 6 have the same meaning as the above introduction and use the same names. For the sake of brevity, please refer to the above introduction and will not go into details below.
  • Figures 5(a) to 5(c) are schematic flowcharts of a method for starting a client according to an embodiment of the present application.
  • the method shown in Figure 5(a) includes steps S511 to S527.
  • step S511 the mobile phone establishes a secure connection with the vehicle-mounted terminal.
  • a mobile phone can establish a connection with a vehicle-mounted terminal through Bluetooth low energy (BLE) combined with the wireless network communication technology Wifi.
  • BLE Bluetooth low energy
  • step S512 the mobile phone checks the client cluster of the vehicle-mounted terminal.
  • the client cluster can be seen in the above introduction combined with Table 9 and Table 10. For the sake of simplicity, it will not be described again here.
  • step S513 the user confirms using the mobile phone to use the vehicle-mounted terminal as the IoT client to access the smart home device.
  • step S513 may be located before step S512, or the two steps may be performed simultaneously, or step S512 may be located before step S513, which is not limited in the embodiment of the present application.
  • step S514 the mobile phone reads the long-term user list in the client cluster and confirms whether a suitable client is recorded in the long-term user list.
  • step S515 is executed. If the client included in the long-term user list is different from the cloud platform where the mobile phone is located, or the user ID of the client is inconsistent with the user ID of the mobile phone, step S516 is executed.
  • step S515 the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the client.
  • step S5166 the mobile phone prompts the user to select long-term mode or temporary mode.
  • the above long-term mode corresponds to creating a client whose user type is long-term user
  • the temporary mode can correspond to creating a client whose user type is temporary user.
  • the following description takes the client where the user chooses to create a long-term user as an example.
  • the solution below can also be applied to creating temporary users.
  • step S517 the mobile phone sends a CSR request command to the IoT client.
  • the CSR request command can carry the user type of the client.
  • CSR request command can be found in the introduction shown in Table 11 above.
  • step S5128 the IoT client generates a key pair and sends a CSR response command to the mobile phone.
  • the CSR response command can be found in the introduction above in conjunction with Table 12.
  • step S519 the mobile phone sends a client application request command to the IoT cloud platform to apply for an IoT client certificate and token through the IoT cloud interface.
  • the client's application request carries the client's user type.
  • step S520 the IoT cloud platform sends a client application response command to the mobile phone.
  • the mobile phone can obtain the IoT client certificate chain and token returned by the IoT cloud platform through the client application response interface.
  • Table 22 shows the parameters included in the client application response command in the embodiment of the present application, as well as the value type of the parameters, the position of the parameters, the necessity of the parameters, and the description of the parameters.
  • step S521 the mobile phone sends an add cloud request command to the IoT client to request the client to add a cloud.
  • Table 23 shows the parameters included in the add cloud request command in this embodiment of the present application.
  • the add cloud request command can include the IoT client certificate, intermediate certificate, root certificate, cloud address, CToken and token expiration information.
  • Table 23 also shows the identifier of the parameter, the data type of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter and the necessity of the parameter.
  • step S522 the IoT client uses the private key in the key pair to decrypt the Ctoken and obtain the access token.
  • step S523 the IoT client sends an add cloud response command to the mobile phone.
  • the add cloud response command includes the client's startup password.
  • the mobile phone can store the startup password in the add cloud response command and associate the startup password with the client ID and cloud address of the IoT client.
  • add cloud response commands please refer to the relevant introduction in Table 6 above.
  • step S524 the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the IoT client.
  • a client start request command to the vehicle-mounted terminal to request to start the IoT client.
  • Step S515 can be understood as that when a suitable client is configured in the first device, the configuration device can directly start the client through step S515.
  • Step S524 can be understood as that when the first device is not configured with a suitable client, the configuration device can start the client through step S524 after reconfiguring the client.
  • step S525 the IoT client verifies whether the cloud address and startup password corresponding to the client ID in the client startup request are consistent with those recorded in the client cluster.
  • step S526 is executed. If the cloud address and startup password corresponding to the client ID in the client startup request are inconsistent with those recorded in the client cluster, step S527 is executed.
  • step S526 the vehicle-mounted terminal starts the IoT client and indicates that the mobile phone IoT client is started successfully.
  • step S527 the vehicle-mounted terminal indicates to the mobile phone that the IoT client fails to start.
  • the vehicle-mounted terminal can indicate to the mobile phone the reason why the IoT client fails to start, for example, the startup password of the IoT client is wrong, the client ID of the IoT client does not exist, etc.
  • the cloud platform can generate a CToken and establish a binding relationship according to the method shown in steps S317 to S320.
  • the cloud platform can generate a CToken and establish a binding relationship according to the method shown in steps S317 to S320.
  • step S531 the IoT client connects to the IoT cloud address and uses the certificate to establish a secure connection with the IoT cloud platform.
  • step S532 the IoT client sends a client registration request to the IoT cloud platform to request client registration on the IoT cloud platform.
  • the client registration request may include the client ID and access token.
  • the client registration request please refer to the introduction in Table 3 above.
  • step S533 in response to the client registration request, the IoT cloud platform sends a client registration response command to the IoT client.
  • the client registration response command can carry a new access token, user ID, and first token assigned by the IoT cloud platform to the IoT client.
  • client registration response command please refer to the introduction in Table 5 above.
  • the client login process in the embodiment of this application is introduced below with reference to Figure 5(c).
  • the method shown in Figure 5(c) includes steps S541 to S542.
  • step S541 the IoT client sends a login request to the IoT cloud platform to request to log in to the IoT cloud platform.
  • the above login request includes a user ID, a client ID, and an access token. Please refer to the introduction in conjunction with Table 17 above.
  • step S542 in response to the login request, the IoT cloud platform sends a login response command to the IoT client.
  • Table 24 shows a possible implementation of the login response command in the embodiment of this application.
  • the login response command may include Internet media type and token expiration information.
  • FIGS. 6(a) to 6(c) are schematic flow charts of a method for starting a client according to another embodiment of the present application.
  • the method shown in Figure 6(a) includes steps S611 to S627. It should be noted that the method shown in Figure 6 can be applied to the client using the AMTP protocol to communicate with smart home devices.
  • step S611 the mobile phone establishes a secure connection with the vehicle-mounted terminal.
  • step S612 the mobile phone checks the client cluster of the vehicle-mounted terminal.
  • the client cluster can be seen in the above introduction combined with Table 9 and Table 10. For the sake of simplicity, it will not be described again here.
  • step S613 the user confirms using the mobile phone to use the vehicle-mounted terminal as the IoT client to access the smart home device.
  • step S613 may be located before step S612, or the two steps may be performed simultaneously, or step S612 may be located before step S613, which is not limited in the embodiment of the present application.
  • step S614 the mobile phone reads the long-term user list in the client cluster and confirms whether a suitable client is recorded in the long-term user list.
  • step S615 is executed. If the client included in the long-term user list is on a different cloud platform than the mobile phone, or the user ID of the client is inconsistent with the user ID of the mobile phone, step S616 is executed.
  • step S615 the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the client.
  • step S616 the mobile phone prompts the user to select long-term mode or temporary mode.
  • the above long-term mode corresponds to creating a client whose user type is long-term user
  • the temporary mode can correspond to creating a client whose user type is temporary user.
  • the following description takes the client where the user chooses to create a long-term user as an example.
  • the solution below can also be applied to creating temporary users.
  • step S617 the mobile phone sends a CSR request command to the IoT client.
  • the CSR request command can carry the user type of the client.
  • CSR request command can be found in the introduction shown in Table 11 above.
  • step S618 the IoT client generates a key pair and sends a CSR response command to the mobile phone.
  • the CSR response command can be found in the introduction above in conjunction with Table 12.
  • step S619 the mobile phone sends a client application request command to the IoT cloud platform to apply for an IoT client certificate and token through the IoT cloud interface.
  • the client's application request carries the client's user type.
  • step S620 the IoT cloud platform sends a client application response command to the mobile phone.
  • the mobile phone can obtain the IoT client certificate chain and token returned by the IoT cloud platform through the client application response interface.
  • Table 25 shows the parameters included in the client application response command in the embodiment of the present application, as well as the value type of the parameters, the position of the parameters, the necessity of the parameters, and the description of the parameters.
  • step S621 the mobile phone sends an add cloud request command to the IoT client to request the client to add a cloud.
  • Table 26 shows the parameters included in the add cloud request command in this embodiment of the present application.
  • the add cloud request command can include the IoT client certificate, intermediate certificate, root certificate, cloud address, CToken and token expiration information.
  • Table 26 also shows the identifier of the parameter, the data type of the parameter, the constraints of the parameter, the quality of the parameter, the default value of the parameter and the necessity of the parameter.
  • step S622 the IoT client decrypts the Ctoken using the private key in the key pair to obtain the access token.
  • step S623 the IoT client sends an add cloud response command to the mobile phone.
  • the add cloud response command includes the client's startup password.
  • the mobile phone can store the startup password in the add cloud response command and associate the startup password with the client ID and cloud address of the IoT client.
  • add cloud response commands please refer to the relevant introduction in Table 6 above.
  • step S624 the mobile phone sends a client start request command to the vehicle-mounted terminal to request to start the IoT client.
  • a client start request command to the vehicle-mounted terminal to request to start the IoT client.
  • step S615 and step S624 can be understood as two scenarios of sending a start client request command.
  • Step S615 can be understood as that when a suitable client is configured in the first device, the configuration device can directly start the client through step S615.
  • Step S624 can be understood as that when the first device is not configured with a suitable client, the configuration device can start the client through step S624 after reconfiguring the client.
  • step S625 the IoT client verifies whether the cloud address and startup password corresponding to the client ID in the client startup request are consistent with those recorded in the client cluster.
  • step S626 is executed. If the cloud address and startup password corresponding to the client ID in the client startup request are inconsistent with those recorded in the client cluster, step S627 is executed.
  • step S626 the vehicle-mounted terminal starts the IoT client and indicates that the mobile phone IoT client is started successfully.
  • step S627 the vehicle-mounted terminal indicates to the mobile phone that the IoT client fails to start.
  • the vehicle-mounted terminal can indicate to the mobile phone the reason why the IoT client fails to start, for example, the startup password of the IoT client is wrong, the client ID of the IoT client does not exist, etc.
  • the cloud platform can generate a CToken and establish a binding relationship according to the method shown in steps S317 to S320.
  • the cloud platform can generate a CToken and establish a binding relationship according to the method shown in steps S317 to S320.
  • the client configuration process and client startup process are introduced above in conjunction with steps S611 to S627. If the IoT client is started successfully, the client registration process will be introduced below with reference to Figure 6(b).
  • the method shown in Figure 6(b) includes steps S631 to S633.
  • step S631 the IoT client connects to the IoT cloud address and uses the certificate to establish a secure connection with the IoT cloud.
  • step S632 the IoT client sends a client registration request to the IoT cloud platform to request client registration on the IoT cloud platform.
  • the client registration request may include the client ID, access token, and access address of the IoT client.
  • the client registration request please refer to the introduction in Table 18 above.
  • step S633 in response to the client registration request, the IoT cloud platform sends a client registration response command to the IoT client.
  • the client registration response command can carry the new access token, user ID, first token, and access address of the smart home device assigned by the IoT cloud platform to the IoT client.
  • the client registration response command please refer to the introduction in Table 20 above.
  • the client login process in the embodiment of this application is introduced below with reference to Figure 6(c).
  • the method shown in Figure 6(c) includes steps S641 to S642.
  • step S641 the IoT client sends a login request to the IoT cloud platform to request to log in to the IoT cloud platform.
  • the above login request includes a user ID, a client ID, and an access token. Please refer to the above introduction in conjunction with Table 17.
  • step S642 in response to the login request, the IoT cloud platform sends a login response command to the IoT client.
  • Table 27 shows a possible implementation of the login response command in the embodiment of this application.
  • the login response command may include Internet media type and token expiration information.
  • the access address of the IoT client and the access address of the smart home device are exchanged.
  • the access address of the IoT client and the access address of the smart home device can also be interacted through login request and login response commands.
  • the commands introduced in Table 19 and Table 21 can be used.
  • the client registration request and client registration response can be combined with the commands introduced in Table 3 and Table 5.
  • FIG. 7 is a schematic diagram of the first device according to the embodiment of the present application.
  • the first device 700 shown in FIG. 7 includes: a receiving unit 710.
  • the receiving unit 710 is configured to receive a first request sent by a configuration device, where the first request is used to request to start a client in the first device, where the client is used to communicate with the cloud platform.
  • the first request carries a startup password of the client, and the startup password is used to authenticate the user who starts the client.
  • the first device further includes: a first processing unit, configured to determine whether the startup password carried in the first request matches the prestored startup password of the client; if the The startup password carried in the first request matches the pre-stored startup password, and the first processing unit is also used to start the client.
  • a first processing unit configured to determine whether the startup password carried in the first request matches the prestored startup password of the client; if the The startup password carried in the first request matches the pre-stored startup password, and the first processing unit is also used to start the client.
  • the first request carries indication information of the cloud platform.
  • the first device further includes: a second processing unit configured to select the client based on the cloud platform information carried in the first request.
  • the first device includes a functional cluster
  • the functional cluster is used to indicate commands supported by the client; and/or the functional cluster is used to record the first device Client corresponding to long-term users.
  • the function cluster is used to indicate one or more of the following information of the client: the client identifier of the client; The user identification of the terminal; and the instruction information of the cloud platform.
  • the function cluster includes one or more of the following commands: the first request; a second request for instructing the client to add the cloud platform; for the second The response command for the request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully; the third request for requesting the CSR of the client; the response command for the third request, wherein, the response command to the third request is used to request from the cloud platform a certificate for identity verification of the client.
  • the second request includes one or more of the following information: the client authenticates itself on the cloud platform. Certificate information, indication information of the cloud platform, and access token information of the cloud platform.
  • the response command to the second request includes: information indicating whether the cloud platform is added successfully, and /or, the startup password of the client.
  • the receiving unit is configured to receive the first information sent by the cloud platform, where the first information includes a first token, and the first token is used to send the message to the cloud platform.
  • the cloud platform requests to update the access token.
  • the first device further includes: a first sending unit, configured to send second information to the cloud platform, where the second information is used to request to log in to the cloud platform, the The second information includes the user identification of the client.
  • the receiving unit is configured to: receive first indication information sent by the configuration device, where the first indication information is used to configure the user type of the client.
  • the user type of the client is configured by the user through the configuration device.
  • the user types include long-term users or temporary users.
  • the user type of the client is a long-term user.
  • the first device further includes: a second sending unit, configured to send third information to the cloud platform, where the third information includes the access address of the client.
  • the third information is carried in a registration request of the client requesting to register on the cloud platform, and/or the third information is carried in a login request of the client. Describe the login request of the cloud platform.
  • the access address is an access address based on the AMTP protocol
  • the third information is used to instruct the client to use the AMTP protocol to communicate.
  • the receiving unit is configured to: in response to the third information, receive fourth information sent by the cloud platform, where the fourth information includes the information to be accessed by the client.
  • the access address of the second device is configured to: in response to the third information, receive fourth information sent by the cloud platform, where the fourth information includes the information to be accessed by the client. The access address of the second device.
  • the fourth information is carried in a response command to a registration request for the client to register on the cloud platform, and/or the fourth information is carried in a response command to the registration request of the client.
  • the response command of the login request of the client requesting to log in to the cloud platform.
  • FIG. 8 is a schematic diagram of the cloud platform according to the embodiment of the present application.
  • the cloud platform shown in Figure 8 may be, for example, one or more cloud servers.
  • the cloud platform 800 shown in FIG. 8 includes: a communication unit 810.
  • the communication unit 810 is used to communicate with the client configured in the first device.
  • the client of the first device is started based on a first request, and the first request is used to request to start the client.
  • the first request carries a startup password of the client, and the startup password is used to authenticate the user who starts the client.
  • the first request carries cloud platform information of the client.
  • the first device includes a functional cluster, and the functional cluster is used to record the client.
  • the function cluster is used to indicate one or more of the following information of the client: a client identification of the client; a user identification of the client; and an indication of the cloud platform information.
  • the function cluster includes one or more of the following commands: the first request; a second request for instructing the client to add the cloud platform; for the second The response command for the request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully; the third request for requesting the CSR of the client; the response command for the third request, Wherein, the response command to the third request is used to request the cloud platform for a certificate used for identity authentication of the client.
  • the second request includes one or more of the following information: used for the client to identify itself on the cloud platform Verified certificate information, indication information of the cloud platform and access token information of the cloud platform.
  • the response command to the second request includes: information indicating whether the cloud platform is added successfully, and /or, the startup password of the client.
  • the communication unit is further configured to: send first information to the first device, where the first information includes a first token, and the first token is used to send The cloud platform requests to update the access token.
  • the communication unit is further configured to: receive second information sent by the first device, where the second information is used to request to log in to the cloud platform. Contains the user ID of the client.
  • the communication unit is further configured to: receive second instruction information sent by the configuration device, where the second instruction information is used to configure the user type of the client.
  • the user type of the client is configured by the user through the configuration device.
  • the user types include long-term users or temporary users.
  • the user type of the client is a long-term user.
  • the communication unit is further configured to receive third information sent by the first device, where the third information includes the access address of the client.
  • the third information is carried in a registration request of the client requesting to register on the cloud platform, and/or the third information is carried in a login request of the client. Describe the login request of the cloud platform.
  • the access address is an access address based on the AMTP protocol
  • the third information is used to instruct the client to use the AMTP protocol to communicate.
  • the communication unit is further configured to: in response to the third information, send fourth information to the first device, where the fourth information includes the client to be accessed The access address of the second device.
  • the fourth information is carried in a response command to a registration request for the client to register on the cloud platform, and/or the fourth information is carried in a response command to the registration request of the client.
  • the response command of the login request of the client requesting to log in to the cloud platform.
  • FIG. 9 is a schematic diagram of a configuration device according to an embodiment of the present application.
  • the configuration device 900 shown in FIG. 9 includes a sending unit 910.
  • the sending unit 910 is configured to send a first request to the first device, where the first request is used to request to start a client in the first device, where the client is used to communicate with the cloud platform.
  • the first request carries a startup password of the client
  • the startup password is used to authenticate the user who starts the client
  • the first request carries the The client’s cloud platform information.
  • the first device includes a function cluster
  • the function cluster is used to indicate the commands supported by the client; and/or the function cluster is used to record the commands in the first device.
  • a client for long-term users.
  • the function cluster is used to indicate one or more of the following information of the client: a client identification of the client; a user identification of the client; and an indication of the cloud platform information.
  • the function cluster includes one or more of the following commands: the first request; a second request for instructing the client to add the cloud platform; for the second The response command for the request, wherein the response command for the second request is used to indicate whether the cloud platform is added successfully; the third request for requesting the CSR of the client; the response command for the third request, wherein, the response command to the third request is used to request from the cloud platform a certificate for identity verification of the client.
  • the second request includes one or more of the following information: used for the client to identify itself on the cloud platform The verified certificate information, the address information of the cloud platform and the access token information of the cloud platform.
  • the response command to the second request includes: information indicating whether the cloud platform is added successfully, and /or, the startup password of the client.
  • the configuration device further includes: a processing unit, configured to: if the user type of the client is a long-term user, Stores the client's startup password.
  • the sending unit is further configured to: send first indication information to the first device, where the first indication information is used to configure the user type of the client.
  • the user type of the client is configured by the user through the configuration device.
  • the user types include long-term users or temporary users.
  • the user type of the client is a long-term user.
  • the receiving unit 710 may be a transceiver 1040.
  • the first device 700 may also include a processor 1010 and a memory 1020, as specifically shown in FIG. 10 .
  • the communication unit 810 may be a transceiver 1040.
  • the cloud platform 800 may also include a processor 1010 and a memory 1020, as specifically shown in Figure 10.
  • the sending unit 910 may be a transceiver 1040.
  • the configuration device 900 may also include a processor 1010 and a memory 1020, as specifically shown in Figure 10.
  • Figure 10 is a schematic structural diagram of a communication device according to an embodiment of the present application.
  • the dashed line in Figure 10 indicates that the unit or module is optional.
  • the device 1000 can be used to implement the method described in the above method embodiment.
  • the device 1000 may be a chip, a terminal device or a network device.
  • Apparatus 1000 may include one or more processors 1010.
  • the processor 1010 can support the device 1000 to implement the method described in the foregoing method embodiments.
  • the processor 1010 may be a general-purpose processor or a special-purpose processor.
  • the processor may be a central processing unit (CPU).
  • the processor can also be another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), or an off-the-shelf programmable gate array (FPGA) Or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA off-the-shelf programmable gate array
  • a general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.
  • Apparatus 1000 may also 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 foregoing method embodiment.
  • the memory 1020 may be independent of the processor 1010 or integrated in the processor 1010.
  • Apparatus 1000 may also include a transceiver 1030.
  • Processor 1010 may communicate with other devices or chips through transceiver 1030.
  • the processor 1010 can transmit and receive data with other devices or chips through the transceiver 1030.
  • An embodiment of the present application also provides a computer-readable storage medium for storing a program.
  • the computer-readable storage medium can be applied in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.
  • An 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 in the terminal or network device provided by the embodiments of the present application, and the program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.
  • An embodiment of the present application also provides a computer program.
  • the computer program can be applied to the terminal or network device provided by the embodiments of the present application, and the computer program causes the computer to execute the methods performed by the terminal or network device in various embodiments of the present application.
  • the "instruction" mentioned may be a direct instruction, an indirect instruction, or an association relationship.
  • 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, and B can be obtained through C; it can also mean that there is an association between A and B. relation.
  • B corresponding to A means that B is associated with A, and B can be determined based on A.
  • determining B based on A does not mean determining B only based on A.
  • B can also be determined based on A and/or other information.
  • the term "correspondence” can mean that there is a direct correspondence or indirect relationship between the two, or it can also mean that there is an associated relationship between the two, or it can also be a relationship between indicating and being instructed, configuring and being configured, etc. .
  • predefinition or “preconfiguration” can be achieved by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in devices (for example, including terminal devices and network devices).
  • devices for example, including terminal devices and network devices.
  • predefined can refer to what is defined in the protocol.
  • the "protocol” may refer to a standard protocol in the communication field, which may include, for example, LTE protocol, NR protocol, and related protocols applied in future communication systems. This application does not limit this.
  • the size of the sequence numbers of the above-mentioned processes does not mean the order of execution.
  • the execution order of each process should be determined by its functions and internal logic, and should not be determined by the implementation process of the embodiments of the present application. constitute any limitation.
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in 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 they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in various embodiments of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another, e.g., the computer instructions may be transferred from a website, computer, server, or data center Transmission to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means.
  • the computer-readable storage medium may be any available medium that can be read by a computer or a data storage device such as a server or data center integrated with one or more available media.
  • the available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVD)) or semiconductor media (e.g., solid state disks (SSD) )wait.
  • magnetic media e.g., floppy disks, hard disks, magnetic tapes
  • optical media e.g., digital video discs (DVD)
  • semiconductor media e.g., solid state disks (SSD)

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Un procédé de démarrage d'un client, un premier dispositif, un dispositif de configuration et une plateforme en nuage sont fournis. Le procédé comprend l'étape suivante : un premier dispositif reçoit une première requête envoyée par un dispositif de configuration, la première requête étant utilisée pour demander le démarrage d'un client dans le premier dispositif, et le client étant utilisé pour communiquer avec une plateforme en nuage. Dans des modes de réalisation de la présente demande, une première requête utilisée pour démarrer un client est introduite, de façon à être compatible avec des exigences à la fois d'utilisateurs à long terme et d'utilisateurs temporaires.
PCT/CN2022/117782 2022-09-08 2022-09-08 Procédé de démarrage de client, premier dispositif, dispositif de configuration et plateforme en nuage WO2024050754A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/117782 WO2024050754A1 (fr) 2022-09-08 2022-09-08 Procédé de démarrage de client, premier dispositif, dispositif de configuration et plateforme en nuage

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/117782 WO2024050754A1 (fr) 2022-09-08 2022-09-08 Procédé de démarrage de client, premier dispositif, dispositif de configuration et plateforme en nuage

Publications (1)

Publication Number Publication Date
WO2024050754A1 true WO2024050754A1 (fr) 2024-03-14

Family

ID=90192705

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/117782 WO2024050754A1 (fr) 2022-09-08 2022-09-08 Procédé de démarrage de client, premier dispositif, dispositif de configuration et plateforme en nuage

Country Status (1)

Country Link
WO (1) WO2024050754A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200274934A1 (en) * 2017-09-22 2020-08-27 Intel Corporation Device management services based on restful messaging
WO2021072749A1 (fr) * 2019-10-18 2021-04-22 Oppo广东移动通信有限公司 Procédé de commande d'autorisation de dispositif, dispositif, et support de stockage
CN113746857A (zh) * 2021-09-09 2021-12-03 深圳市腾讯网域计算机网络有限公司 登录方法、装置、设备及计算机可读存储介质
CN113746633A (zh) * 2021-08-05 2021-12-03 深圳Tcl新技术有限公司 物联网设备绑定方法、装置、系统、云服务器和存储介质
WO2022016434A1 (fr) * 2020-07-22 2022-01-27 Oppo广东移动通信有限公司 Procédé de désenregistrement de dispositif, procédé d'enregistrement de dispositif, dispositif de communication et plateforme en nuage

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200274934A1 (en) * 2017-09-22 2020-08-27 Intel Corporation Device management services based on restful messaging
WO2021072749A1 (fr) * 2019-10-18 2021-04-22 Oppo广东移动通信有限公司 Procédé de commande d'autorisation de dispositif, dispositif, et support de stockage
WO2022016434A1 (fr) * 2020-07-22 2022-01-27 Oppo广东移动通信有限公司 Procédé de désenregistrement de dispositif, procédé d'enregistrement de dispositif, dispositif de communication et plateforme en nuage
CN113746633A (zh) * 2021-08-05 2021-12-03 深圳Tcl新技术有限公司 物联网设备绑定方法、装置、系统、云服务器和存储介质
CN113746857A (zh) * 2021-09-09 2021-12-03 深圳市腾讯网域计算机网络有限公司 登录方法、装置、设备及计算机可读存储介质

Similar Documents

Publication Publication Date Title
US11128612B1 (en) Zero-touch provisioning of IoT devices with multi factor authentication
JP7474302B2 (ja) 通信ネットワークにおける自動サービス登録
US10630647B2 (en) Secure wireless communication between controllers and accessories
US10951592B2 (en) Secure wireless communication between controllers and accessories
US10177933B2 (en) Controller networks for an accessory management system
EP3149548B1 (fr) Réseaux de dispositifs de commande pour un système de gestion d'accessoires
KR101741967B1 (ko) 에이전트 디바이스를 제1 디바이스 레지스트리로부터 제2 디바이스 레지스트리로 할당하기 위한 방법
WO2014088340A1 (fr) Procédé et appareil d'authentification d'autorisation d'accès dans un système de communication sans fil
WO2014069898A1 (fr) Procédé et appareil pour authentifier une autorisation d'accès à des ressources spécifiques dans un système de communication sans fil
WO2015184382A2 (fr) Réseaux de dispositifs de commande pour un système de gestion d'accessoires
US11394534B2 (en) Electronic device sharing key with external electronic device and operating method for electronic device
WO2024050754A1 (fr) Procédé de démarrage de client, premier dispositif, dispositif de configuration et plateforme en nuage
US20190349348A1 (en) Registry apparatus, agent device, application providing apparatus and corresponding methods
WO2024050753A1 (fr) Procédé de communication, premier dispositif, dispositif de configuration et plateforme en nuage
WO2024130508A1 (fr) Procédé de configuration de réseau de dispositif, configurateur, serveur, dispositif et terminal d'utilisateur
US20220141658A1 (en) One-time wireless authentication of an internet-of-things device
WO2023230983A1 (fr) Procédé et appareil d'établissement de canal d'interfonctionnement, puce, et support de stockage
KR20170058847A (ko) 이종 플랫폼 간 통신 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22957726

Country of ref document: EP

Kind code of ref document: A1