WO2010124571A1 - 节点信息获取方法、客户端、服务器 - Google Patents

节点信息获取方法、客户端、服务器 Download PDF

Info

Publication number
WO2010124571A1
WO2010124571A1 PCT/CN2010/071937 CN2010071937W WO2010124571A1 WO 2010124571 A1 WO2010124571 A1 WO 2010124571A1 CN 2010071937 W CN2010071937 W CN 2010071937W WO 2010124571 A1 WO2010124571 A1 WO 2010124571A1
Authority
WO
WIPO (PCT)
Prior art keywords
value
command
server
node
client
Prior art date
Application number
PCT/CN2010/071937
Other languages
English (en)
French (fr)
Inventor
陈波
鞠飞
袁磊
周韬
阳翰凌
沈建
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to US13/259,178 priority Critical patent/US8892711B2/en
Publication of WO2010124571A1 publication Critical patent/WO2010124571A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/18Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20Transfer of user or subscriber data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/04Error control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information

Definitions

  • the present invention relates to the field of communications, and in particular to a node information acquisition method, client, and server for the OMA DM protocol.
  • OMA DM Open Mobile Alliance Device Management
  • SyncML OMA Information Synchronization Markup Language
  • DM Device Management
  • the OMA DM protocol is an application protocol under the OMA SyncML protocol.
  • a session completes various device management functions by sending various commands and obtaining a response from the terminal.
  • the commands supported by the OMA DM protocol include Get, Add; Replace, Exec, Delete, and so on.
  • the commands supported are a subset of the OMA SyncML protocol.
  • For each command a series of status values are defined in the OMA DM protocol to clearly define the execution results of the commands in the session.
  • the status values of these commands are defined in the protocol document "OMA-TS-DM_RepPro-Vl_2-20070209-A.pdf".
  • a return value defined for a Get command includes 200 (command execution succeeds OK), 215 (The command does not execute Not Executed), 401 (unauthorized Unauthorized), 404 (data not found Not Found), 405 (command not executed command not allowed), etc.
  • These state values explicitly define the Get command in Most of the results that may occur during execution, such as successful command execution, node not found, no permission, no authentication, unsupported operation, command failure, Uniform Resource Identifier (URI) is too long, etc. .
  • URI Uniform Resource Identifier
  • the Get command returns a failure, and the failed status code is the same as the failed URI. And no section of the Result tag has been successfully obtained.
  • the server issues a get command with multiple items:
  • the URIs you want to get in the above Get command are It is a standard node specified in the DM protocol. In the client, there is no access right for the nodes specified in some items. For example, as shown in Figure 2, for the /DMAcc/AppAuth/Client/AauthSecret node, it is the authentication data. In the password field, the server only has the Replace permission, but there is no Get permission. That is to say, there are some items in multiple items that do not have permission to obtain.
  • the client After receiving the above Get command, the client performs the get operation and is in the third Item. If there is no permission and the execution fails, the entire Get command returns the command 425 (no permission, the operation is rejected). It should be noted that the implementation of different clients is different, and other status indicating error may be returned here. As follows:
  • the server needs to obtain information of three nodes, and the terminal has actually obtained the information of two of the nodes, but only fails at the third node. In the case that most of the node information is successfully obtained, the server only gets the prompt that the Get command fails to execute, and the maximum amount of information cannot be obtained.
  • Such processing wastes the processing power of the client and also wastes network resources, and if the server does not have an appropriate retrying strategy (for example, splitting the Get command separately), it will not be able to fully obtain the required information.
  • the main object of the present invention is to provide a node information acquisition method. , client, server, to solve the above problems in the related technology.
  • a node information obtaining method for optimizing a Get command including a multi-item in a device management protocol.
  • the method for obtaining the node information according to the present invention includes: the client receives the Get command sent by the server, obtains the value of the node under all the items in the Get command, and determines that the value of the node under the partial item fails; the client sends the port to the server.
  • Node information under item Preferably, before the client receives the Get command sent by the server, the method further includes: setting a new state value for the Get command, where the new state value is used to indicate that the node value of the part of the Get command fails.
  • the method further includes: the client determines that the Get command includes multiple items.
  • the method further includes: the server receiving the response message, and determining that the response message carries a new status value; the server acquires the node information under the item whose value is successful according to the predetermined label, and the node The information is saved; the server performs a predetermined operation on the node under the item whose value is failed.
  • the predetermined operation comprises one of the following: abandoning the node under the item whose value fails.
  • the client includes: a receiving module, configured to receive a Get command sent by the server; an obtaining module, configured to obtain a value of a node under all items in the Get command; and a first determining module, configured to determine a part of the item
  • the sending module fails to send a response message carrying a new status value indicating that the node under the partial item fails to execute the Get command when the Get command is executed, wherein the response message further carries a predetermined label, and the predetermined message is reserved.
  • the tag is used to encapsulate the node information under the item whose value is successful.
  • the client further includes: a second determining module, configured to determine that the Get command includes multiple items.
  • a server for optimizing a Get command including a multi-item in a device management protocol.
  • the server includes: a sending module, configured to send a Get command to the client; and a receiving module, configured to receive, by the client, a new state value carrying a failure of the node value under the partial item when the Get command is executed.
  • the response message where the response message further carries a predetermined label, and the predetermined label is used to encapsulate the node information under the item with a successful value.
  • the server further includes: a determining module, configured to determine that the response message carries a new status value; and a saving module, configured to acquire, by the predetermined label, the node information under the item whose value is successful, and save the node information;
  • the module is configured to perform a predetermined operation on a node under the item whose value is failed.
  • the predetermined operation comprises one of the following: abandoning the node under the item whose value fails
  • the client when executing the Get command of the OMA SyncML DM containing multiple Items, the client can notify the server that the Get is not completely successful through a special status value, but is partially successful, and is included in the Result tag.
  • the successfully obtained node values solve the problem that when the one or more items in the Get command fail in the related art, the remaining valid information cannot be valid, and the useful nodes can be obtained more efficiently, and the nodes that cannot be acquired can be located. It also improves the effectiveness of the client's operation on the Get command and avoids the waste of network resources.
  • FIG. 1 is a schematic diagram of a definition of a return value of an OMA SyncML DM protocol terminal Get command in the related art
  • FIG. 2 is a schematic diagram of a description of an AauthSecret node by the OMA SyncML DM protocol in the related art
  • FIG. 3 is a node according to an embodiment of the present invention.
  • FIG. 4 is a flowchart of a process when a client receives a Get command of a plurality of items according to an embodiment of the present invention
  • FIG. 5 is a diagram of a server carrying a new one according to an embodiment of the present invention
  • FIG. 6 is a block diagram of a client in accordance with an embodiment of the present invention
  • FIG. 7 is a block diagram of a server in accordance with an embodiment of the present invention.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In the related art, when one or more items in the Get command fail, the remaining valid information cannot be valid. To this end, the present invention provides an optimization of the Get command in the OMA SyncML DM protocol. method. The method enhances the processing of the Get command in the protocol, and defines a new state value for the case where the partial node Get fails in the multiple items.
  • the embodiment of the invention also discloses the processing when the client receives the Get command containing multiple items. The method, and the processing method after the server receives the response from the client.
  • the method for obtaining the node information includes: the client receives the Get command sent by the server, obtains the value of the node under all the items in the Get command, and determines that the value of the node under the partial item fails; the client sends the new value to the server.
  • the response message of the status value wherein the new status value is used to indicate that the node value of the part of the item fails to be executed when the Get command is executed, and the response message further carries a predetermined label, and the predetermined label is used to encapsulate the item with a successful value.
  • a node information obtaining method for optimizing a Get command including multiple items in a device management protocol.
  • the processing of setting a new state value by the Get command will be described first.
  • the Get command is defined.
  • 12 status values used to indicate the result of command execution are shown in Figure 1, including: 200 (for success), 404 (for nodes not found), and so on. It can be seen that the 12 state values shown in FIG. 1 cannot indicate that some of the nodes in the item in the Get command proposed by the present invention are successfully acquired and some of the nodes fail to be acquired. Therefore, the embodiment of the present invention defines a new state value for the above case, which is used to indicate that the Get command part of the multiple items is successfully executed (that is, the node indicating that some items in the Get command fail to be valued). For the definition of the state value, the embodiment of the present invention does not specify its form.
  • the new state value has the same basic form as other state values, but the value is not the same as the existing state value.
  • the embodiment of the present invention uses 222 to indicate such a state, indicating that the execution result of the Get command is "partially successful.” It should be noted that the embodiment of the present invention not only specifies the use of 222 as the response state value of the state. After the new state value is set, the process shown in FIG. 3 can be performed.
  • FIG. 3 the process shown in FIG. 3 can be performed.
  • Step S302 The client receives the server and sends the Obtaining the (Get) command, first determining that the Get command includes multiple entries (item), and then obtaining the values of the nodes under all the items in the Get command, and determining that the values of the nodes under the partial items fail;
  • Step S304 The client sends a response to the server carrying a new status value (eg, 222) The message is sent, and the response message further carries a predetermined label, where the predetermined label is used to encapsulate the node information under the item with a successful value.
  • a new status value eg, 222
  • the client after receiving the Get command of the class, the client performs an operation of acquiring a value for a node under each of the Items.
  • the response status of the Get command in the response message returned by the client in the server should not be a failure, but the above definition.
  • the new status value is 222.
  • the client response message it should also contain a Result tag, which carries the node information of the correctly obtained value.
  • the returned response message can look like this:
  • FIG. 4 is a flowchart of processing when a client receives a Get command of multiple items according to an embodiment of the present invention. As shown in FIG. 4, the method includes the following processing: Step 401: A client receives a Get command from a server, and Found that it contains multiple
  • Item 402 The client invokes the local interface to obtain the value of the node in all the items.
  • Step 403 Determine whether the value of the node in the Item fails. If not, enter the step.
  • Step 404 is a normal processing flow in the current protocol.
  • the client encapsulates the response message, and sets a status code of 200 to indicate that the Get command is successfully executed. After the execution is completed, Go to step 407; Step 405, the step is the processing scope of the present invention.
  • the status code is set to 222 when the response message is encapsulated;
  • Step 406 Client Continuing to add a Result tag to the response packet, the node that successfully obtained the value is encapsulated according to the protocol specification;
  • Step 407 the client sends the response packet to the server, and ends the processing flow of the Get command.
  • the client can carry a new status value in the response message to notify the server that some of the items under the item are not successfully acquired.
  • the following describes the operation after the server receives the response message.
  • the server needs to process the response message, including the following operations:
  • the server receives the response message, and determines that the response message carries a new status value. 2.
  • the server obtains the node information from the predetermined label (ie, the Result tag), and saves the node information.
  • the server performs a predetermined operation on the node of the item whose value is failed, including one of the following: abandoning the session of the node of the item whose value is failed; sending the Get command again to take the value of the node of the item whose value is failed.
  • the server can know that the processing result of the Get command is the acquisition part successfully according to the status code 222.
  • FIG. 5 is a flowchart of processing when a server receives a response message carrying a new status value according to an embodiment of the present invention.
  • the method includes the following processing: Step 501: The server receives response information of the client; 502, the server determines whether the status code of the response message is 222. If not, the normal processing flow is performed, and the process proceeds to step 504.
  • step 503 is performed; step 503, after the status code is 222, the processing policy is executed. Including: Save the correct value, and retry the Get operation again for the unobtained value. The value of the node under the item that is not obtained may be retried or discarded; step 504, the session ends.
  • the server can obtain useful nodes more efficiently and locate nodes that cannot be acquired.
  • Apparatus Embodiment 1 According to an embodiment of the present invention, a client is provided for optimizing a Get command including a multi-item in a device management protocol, and FIG. 6 is a block diagram of a client according to an embodiment of the present invention, as shown in FIG.
  • the client includes: a receiving module 60, an obtaining module 62, a first determining module 64, and a sending module 66.
  • the client according to an embodiment of the present invention will be described in detail below. It should be noted that, before performing the following processing, it is first necessary to define a new state value, which is used to indicate that the Get command part of multiple items is successfully executed (ie, represents the part of the Get command). The node value of item failed.)
  • the embodiment of the present invention does not specify its form. In practical applications, the new state value has the same basic form as other state values, but the value is not the same as the existing state value.
  • the embodiment of the present invention uses 222 to indicate such a state, indicating that the execution result of the Get command is "partially successful.” It should be noted that the embodiment of the present invention not only specifies the use of 222 as the response state value of the state.
  • the receiving module 60 is configured to receive a Get command sent by the server. After the receiving module 60 receives the Get command sent by the server, the second determining module needs to determine that the Get command includes multiple items, and then the obtaining module 62 obtains the Get command.
  • the value of the node under all the items is obtained; after the obtaining module 62 obtains the values of the nodes under all the items in the Get command, the first determining module 64 determines that the value of the node under the partial item fails; 66.
  • Node information. Among them, the returned response message can be as follows:
  • ⁇ /SyncBody> ⁇ /SyncML> there are two places in the returned response message that are obviously different from the traditional response message.
  • the status value is no longer 425 ( Or other failure messages), but 222 (indicating that the acquisition is successful, but not complete);
  • Apparatus Embodiment 2 According to an embodiment of the present invention, a server is provided for optimizing a Get command including a multi-item in a device management protocol.
  • 7 is a block diagram of a server according to an embodiment of the present invention. As shown in FIG.
  • a server according to an embodiment of the present invention includes a transmitting module 70 and a receiving module 72.
  • a server according to an embodiment of the present invention will be described in detail. It should be noted that, before performing the following processing, it is first necessary to define a new state value, which is used to indicate that the Get command part of multiple items is successfully executed (that is, the node indicating that some items in the Get command fail).
  • the state value the embodiment of the present invention does not specify its form.
  • the new state value has the same basic form as other state values, but the value is not the same as the existing state value. For example, you can define a status value of 900 in this case, or you can define it as 222.
  • the embodiment of the present invention uses 222 to indicate such a state, indicating that the execution result of the Get command is "partially successful.” It should be noted that the embodiment of the present invention not only specifies the use of 222 as the response state value of the state.
  • a server according to an embodiment of the present invention will be described. Specifically, the sending module 70 is configured to send a Get command to the client; the receiving module 72 is configured to receive a new one that is sent by the client and that has a value indicating that the node under the part of the item fails to execute the Get command.
  • the response message of the status value wherein the response message further carries a predetermined label, and the predetermined label is used to encapsulate the node information under the item whose value is successful.
  • the determining module determines that the response message carries a new status value; if the new status value is carried, the saving module obtains the node information according to the predetermined label, and The node information is saved; subsequently, the execution module performs a predetermined operation on the node under the item whose value is failed.
  • the operation of the execution module includes one of the following: abandoning the session of the node of the item whose value is failed; sending the Get command again to take the value of the node of the item whose value is failed.
  • the client when executing the Get command of the OMA SyncML DM with multiple Items, the client can notify the server that the Get is not completely successful through a special status value, but is partially successful, and The successfully obtained node values are included in the Result tag, and the problem that the acquired valid information cannot be valid when one or more items in the Get command fail in the related art is solved, and the useful nodes can be obtained more efficiently. Locating a node that cannot be obtained also improves the effectiveness of the client's operation on the Get command, and avoids the waste of network resources.
  • modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device, or they may be separately fabricated into individual integrated circuit modules, or they may be Multiple modules or steps are made into a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.
  • the above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the scope of the present invention are intended to be included within the scope of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种节点信息获取方法、客户端、服务器,其中,该方法包括:客户端接收服务器发送的Get命令,获取Get命令中的所有item下的节点的取值,并确定部分item下的节点取值失败;客户端向服务器发送携带有新的状态值的响应消息,其中,新的状态值用于表示执行Get命令时部分item下的节点取值失败,且响应消息中还携带有预定标签,预定标签用于封装取值成功 的item下的节点信息。 通过本发明的上述技术方案,可以更高效的获取有用节 点,定位无法获取的节点,还提高了客户端对Get命令操作的有效性,避免了浪费网络资源的情况发生。

Description

节点信息获取方法、 客户端、 服务器 技术领域 本发明涉及通信领域, 并且特别地, 涉及一种用于 OMA DM协议的节 点信息获取方法、 客户端、 服务器。 背景技术 在相关技术中, 开放移动联盟设备管理 (Open Mobile Alliance Device Management , 简称为 OMA DM ) 业务是基于 OMA 信息同步标准协议 ( Synchronization Mark up Language , 简称为 SyncML ) DM 目关标准的移动 数据增值业务, 它使得运营商实现了通过无线方式对移动终端进行远程管理 的能力。 运行于手机中的设备管理(Device Management, 简称为 DM )客户 端需要同月艮务器进行协议规定的交互来完成 SyncML DM功能, 其中包括设 备信息管理、 参数釆配、 终端软件 /固件升级等功能。
OMA DM协议是隶属于 OMA SyncML协议之下的应用协议。 在 OMA DM协议中, 会话是通过发送各种命令并获取终端的响应的方式来完成各种 设备管理功能。 OMA DM协议支持的命令包括 Get (获取)、 Add (添加;)、 Replace (取代;)、 Exec (执行;)、 Delete (删除)等多种, 其支持的命令是 OMA SyncML协议的子集。 对于每一种命令, OMA DM协议中都定义了一系列的状态值, 用以明 确定义会话中命令的执行结果。 这些命令的状态值定义在协议文档 《OMA-TS-DM_RepPro-Vl_2-20070209-A.pdf)〉中。 图 1是相关技术中 OMA SyncML DM协议终端 Get命令返回值的定义的示意图,如图 1所示,在 OMA SyncML DM协议中,对 Get命令定义的返回值包括 200(命令执行成功 OK ), 215 (命令没有执行 Not Executed ), 401 (未 ·ί受权 Unauthorized )、 404 (数据 未找到 Not Found ), 405 (命令没有执行权限 command not allowed )等 12个, 这些状态值明确的定义了 Get命令在执行过程中可能出现的大部分结果, 例 如, 命令执行成功、 节点未找到、 无权限、 未鉴权、 操作不支持、 命令失败、 通用资源标识符 ( Uniform Resource Identifier, 简称为 URI ) 太长等。 在实际应用中,还可能出现一种协议中对 Get命令的执行结果未明确定 义的处理方式, 即, 在同一个 Get命令中通过多个 Item对多个节点 ( URI ) 进行获取操作。 由于协议对上述情况未作明确的处理方式规定, 实际应用中 在遇到上述情况时, 才艮据如下方式进行处理:
1、 所有 URI均获取成功, 则返回状态码 200表示成功, 并在 Result标 签中——列出获取到的值。
2、 某一个或者多个 Item中的 URI获取失败, 则 Get命令返回失败, 失 败状态码与失败的 URI—致。并且无 Result标签反馈已经成功获取的部分节
下面, 举例对上述处理方式进行说明。 在该实例中, 没有完整的列出同 步包头信息, 但不影响本例需要说明的问题。 如下所示, 在会话开始后的某 阶段服务器发出一个 get命令中含有多个 Item:
<SyncML>
<SyncHdr>
<VerDTD> 1.2</VerDTD>
<VerProto>DM/ 1.2</VerProto>
<SessionID>8155</SessionID>
<MsgID> 1 </MsgID>
……略
</SyncHdr>
<SyncBody>
<Get>
<CmdID> K/CmdID>
<Item>
<Target> <LocURI>./DevInfo/Lang</LocURI> </Target>
</Item>
<Item>
<Target>
<LocURI>./DevInfo/Man</LocURI> </Target>
</Item> <Item>
<Target>
<LocURI>./DMAcc/AppAuth/Client/AAuthSecret</LocURI> </Target> </Item> </Get> <Final /> </SyncBody> </SyncML> 上述 Get命令中想要获取的 URI均是 DM协议中规定的标准节点, 在 客户端中,对有些 item中指定的节点是没有获取权限的, 例如,如图 2所示, 对于 /DMAcc/AppAuth/Client/AauthSecret 节点, 是鉴权数据中的密码字段, 服务器只有 Replace权限, 但没有 Get权限, 也就是说, 多个 Item中出现某 些 Item没有权限获取的情况是存在的。 客户端在收到上述 Get命令后, 执行获取操作, 并在第三个 Item中因 无权限而执行失败, 整个 Get命令返回命令 425 (无权限, 操作被拒绝), 需 要说明的是, 不同客户端的实现有所区别, 这里也可能返回 405等其它表示 错误的状态。 如下所示:
<SyncML xmlns="SYNCML:SY CML1.2"> <SyncHdr>
<VerDTD> 1.2</VerDTD>
<VerProto>DM/ 1.2</VerProto>
<SessionID>8155</SessionID>
<MsgID> 1 </MsgID> 略
</SyncHdr>
<SyncBody>
<Status>
<CmdID> K/CmdID>
<MsgRef K/MsgRef
<CmdRef K/CmdRef
<Cmd>Get</Cmd>
<Data>405</Data> </Status>
<Final />
</SyncBody>
</SyncML> 如上所述, 服务器需要获取三个节点的信息, 而终端实际上已经获取到 了其中两个节点的信息, 只是在第三个节点处失败。 在大部分节点信息获取 成功的情况下, 服务器只得到了 Get命令执行失败的提示, 未能得到最大的 信息量。 这样的处理浪费了客户端的处理能力, 同时也浪费了网络资源, 并 且服务器如果没有适当的重试策略 (例如, 拆分 Get命令单独获取) 将导致 其不能全面的获取到需要的信息。 发明内容 考虑到相关技术中 Get命令中某个或者多个 Item失败时, 其余获取的 有效信息均无法生效的问题而提出本发明, 为此, 本发明的主要目的在于提 供一种节点信息获取方法、 客户端、 月艮务器, 以解决相关技术中存在的上述 问题。 为了实现上述目的, 根据本发明的一个方面, 提供了一种节点信息获取 方法, 用于对设备管理协议中包含多 item的 Get命令进行优化。 根据本发明的节点信息获取方法包括: 客户端接收服务器发送的 Get 命令, 获取 Get命令中的所有 item下的节点的取值, 并确定部分 item下的 节点取值失败; 客户端向服务器发送携带有新的状态值的响应消息, 其中, 新的状态值用于表示执行 Get命令时部分 item下的节点取值失败, 且响应消 息中还携带有预定标签, 预定标签用于封装取值成功的 item下的节点信息。 优选地, 客户端接收服务器发送的 Get命令之前, 上述方法还包括: 对 Get命令设置新的状态值, 其中, 新的状态值用于表示 Get命令中部分 item 下的节点取值失败。 优选地, 客户端接收服务器发送的 Get命令之后, 还包括: 客户端确定 Get命令中包含多个 item。 优选地, 客户端向服务器发送响应消息之后, 还包括: 服务器接收响应 消息, 并确定响应消息中携带有新的状态值; 服务器根据预定标签获取取值 成功的 item下的节点信息,并将节点信息进行保存;服务器对取值失败的 item 下的节点执行预定操作。 优选地, 预定操作包括以下之一: 放弃对取值失败的 item下的节点的 为了时限上述目的, 根据本发明的另一方面, 提供了一种客户端, 用于 对设备管理协议中包含多 item的 Get命令进行优化。 根据本发明的客户端包括:接收模块,用于接收服务器发送的 Get命令; 获取模块,用于获取 Get命令中的所有 item下的节点的取值;第一确定模块, 用于确定部分 item下的节点取值失败; 发送模块, 用于向服务器发送携带有 表示执行 Get命令时部分 item下的节点取值失败的新的状态值的响应消息, 其中, 响应消息中还携带有预定标签, 预定标签用于封装取值成功的 item下 的节点信息。 优选地, 客户端进一步包括: 第二确定模块, 用于确定 Get命令中包含 多个 item。 为了时限上述目的, 才艮据本发明的再一方面, 提供了一种月艮务器, 用于 对设备管理协议中包含多 item的 Get命令进行优化。 根据本发明的服务器包括: 发送模块, 用于向客户端发送 Get命令; 接 收模块, 用于接收客户端发送的携带有表示执行 Get命令时部分 item下的节 点取值失败的新的状态值的响应消息, 其中, 响应消息中还携带有预定标签, 预定标签用于封装取值成功的 item下的节点信息。 优选地, 服务器进一步包括: 确定模块, 用于确定响应消息中携带有新 的状态值;保存模块,用于 居预定标签获取取值成功的 item下的节点信息, 并将节点信息进行保存; 执行模块, 用于对取值失败的 item下的节点执行预 定操作。 优选地, 预定操作包括以下之一: 放弃对取值失败的 item下的节点的
借助于本发明的技术方案, 在执行含有多个 Item的 OMA SyncML DM 的 Get命令时,客户端可以通过特殊的状态值告知服务器 Get未能完全成功, 但有部分成功, 并且在 Result标签中附带这些成功获取了的节点值, 解决了 相关技术中 Get命令中某个或者多个 Item失败时,其余获取得的有效信息均 无法生效的问题, 可以更高效的获取有用节点, 定位无法获取的节点, 还提 高了客户端对 Get命令操作的有效性, 避免了浪费网络资源的情况发生。 本发明的其它特征和优点将在随后的说明书中阐述, 并且, 部分地从说 明书中变得显而易见, 或者通过实施本发明而了解。 本发明的目的和其他优 点可通过在所写的说明书、 权利要求书、 以及附图中所特别指出的结构来实 现和获得。 附图说明 图 1是相关技术中 OMA SyncML DM协议终端 Get命令返回值的定义 的示意图; 图 2是相关技术中 OMA SyncML DM协议对 AauthSecret节点描述的示 意图; 图 3是根据本发明实施例的节点信息获取方法的流程图; 图 4是根据本发明实施例的客户端在接收到多个 item的 Get命令时的 处理流程图; 图 5 是根据本发明实施例的服务器在接收到携带有新的状态值的响应 消息时的处理流程图; 图 6是才艮据本发明实施例的客户端的框图; 图 7是根据本发明实施例的服务器的框图。 具体实施方式 在相关技术中, 存在 Get命令中某个或者多个 Item失败时, 其余获取 的有效信息均无法生效的问题, 为此, 本发明提供了一种优化 OMA SyncML DM协议中 Get命令的方法。 该方法增强了协议中对 Get命令的处理, 为多 个 Item中部分节点 Get失败的情况定义新的状态值;本发明实施例还公开了 客户端收到含有多个 Item的 Get命令时的处理方法、以及服务器收到客户端 的响应后的处理方法。 其中, 节点信息获取方法包括: 客户端接收服务器发送的 Get命令, 获 取 Get命令中的所有 item下的节点的取值, 并确定部分 item下的节点取值 失败; 客户端向服务器发送携带有新的状态值的响应消息, 其中, 新的状态 值用于表示执行 Get命令时部分 item下的节点取值失败,且响应消息中还携 带有预定标签, 预定标签用于封装取值成功的 item下的节点信息。 以下结合附图对本发明的优选实施例进行说明, 应当理解, 此处所描述 的优选实施例仅用于说明和解释本发明, 并不用于限定本发明。 在以下的描述中, 为了解释的目的, 描述了多个特定的细节, 以提供对 本发明的透彻理解。 然而, 艮显然, 在没有这些特定细节的情况下, 也可以 实现本发明, 此外, 在不背离所附权利要求阐明的精神和范围的情况下, 下 述实施例以及实施例中的各个细节可以进行各种组合。 根据本发明的实施例, 提供了一种节点信息获取方法, 用于对设备管理 协议中包含多 item的 Get命令进行优化。 下面, 首先对 Get命令设置新的状 态值的处理进行说明。 在现有 OMA DM协议 ( 1.2版本及其之前) 中, 对于 Get命令定义了
12种状态值, 用以表示命令执行的结果。 这 12种状态值如图 1所示, 包括: 200 (表示成功)、 404 (表示未找到节点) 等。 可以看出, 如图 1所示的 12种状态值均无法表示本发明所提出的 Get 命令中的所有 item下的节点有一部分获取成功、 一部分获取失败的情况。 因 此, 本发明实施例为上述情况定义一个新的状态值, 用以表示多个 Item 的 Get命令部分执行成功的情况 (即, 表示 Get命令中部分 item的节点取值失 败)。 对于该状态值的定义, 本发明实施例不规定其形式, 在实际应用中, 该 新的状态值基本形式如其它的状态值一样, 只是取值与现有状态值不一样即 可。 例如, 可以定义该情形下的状态值为 900, 也可以定义它为 222。 为了 描述方便, 在下面的描述中, 本发明实施例使用 222来表示这种状态, 表示 对 Get命令的执行结果是 "部分成功"。 需要说明的是, 本发明实施例不仅仅 指定使用 222作为该状态的响应状态值。 在设置了新的状态值后, 就可以进行如图 3所示的处理, 图 3是根据本 发明实施例的节点信息获取方法的流程图, 包括以下步骤: 步骤 S302, 客户端接收服务器发送的获取 (Get )命令, 首先确定 Get 命令中包含有多个条目 ( item ), 随后, 获取 Get命令中的所有 item下的节 点的取值, 并确定部分 item下的节点取值失败; 步骤 S304, 客户端向 艮务器发送携带有新的状态值(例如, 222 ) 的响 应消息, 且响应消息中还携带有预定标签, 该预定标签用于封装取值成功的 item下的节点信息。 具体地, 客户端收到该类 Get命令后, 对其中的每个 Item下的节点进 行获取值的操作。 当某个或者某些 Item下的节点获取失败, 并且仍然有 Item 下的节点获取成功时, 客户端在返回服务器的响应消息中, 对 Get命令的处 理结果状态不应该是失败, 而是上述定义的新的状态值 222。 在客户端响应 消息中, 还应该包含 Result标签, 该 Result标签携带正确获得的值的节点信 息。 返回的响应消息可以如下所示:
<SyncML xmlns="SYNCML:SY CML1.2"> <SyncHdr>
<VerDTD> 1.2</VerDTD>
<VerProto>DM/ 1.2</VerProto>
<SessionID>8155</SessionID>
<MsgID> 1 </MsgID> ……略
</SyncHdr>
<SyncBody>
<Status>
<CmdID> K/CmdID> <MsgRef K/MsgRef
<CmdRef K/CmdRef
<Cmd>Get</Cmd>
<Data>222</Data>
</Status> <Results>
<CmdID> K/CmdID>
<MsgRef K/MsgRef
<CmdRef K/CmdRef <Item>
<Source>
<LocURI>./DevInfo/Lang </LocURI> </Source>
<Data>en-us</Data> </Item> <Item> <Source>
<LocURI>./DevInfo/Man </LocURI> </Source> <Data>ZTE </Data>
</Item>
</Results>
<Final />
</SyncBody> </SyncML> 从上面的描述可以看出, 釆用本发明实施例, 在返回的响应消息中有 2 个地方明显与传统的响应消息不同, 一是状态值不再是 425 (或其它失败消 息 ), 而是 222 (表示获取成功, 但不完整); 二是 SyncBody中, 除了对状态 Status 的描述外, 还添加上了获取信息成功的两个节点的信息, 一并发送给 服务器端。 下面结合附图, 对上述技术方案进行详细说明。 图 4是根据本发明实施 例的客户端在接收到多个 item的 Get命令时的处理流程图, 如图 4所示, 包 括如下处理: 步骤 401 , 客户端收到来自服务器的 Get命令, 并且发现其中含有多个
Item; 步骤 402 , 客户端调用本地接口获取所有 Item中节点的取值; 步骤 403 , 判断是否有 Item中的节点取值失败, 如果没有, 则进入步骤
404, 如果确定取值失败, 则进入步骤 405; 步骤 404,该步骤是目前协议中正常的处理流程,客户端封装响应消息, 并设状态码为 200表示 Get命令执行成功, 在执行完成后, 进入步骤 407; 步骤 405 ,该步骤是本发明的处理范畴,客户端发现有 Item中包含的节 点取值失败的情况后, 在封装响应消息时, 将状态码设置为 222; 步骤 406, 客户端继续在响应包中添加结果 (Result ) 标签, 按照协议 规范将成功取得值的节点封装进去; 步骤 407,客户端将响应包发送给服务器,结束对 Get命令的处理流程。 通过上述处理, 客户端可以在响应消息中携带新的状态值, 以通知月艮务 器有部分 item下的节点没有获取成功,下面对服务器接收到响应消息后的操 作进行说明。 在步骤 S304之后, 服务器需要对响应消息进行响应的处理, 包括以下 操作:
1、 服务器接收响应消息, 并确定响应消息中携带有新的状态值; 2、 服务器从预定标签 (即, Result 标签) 获取节点信息, 并将节点信 息进行保存; 3、 服务器对取值失败的 item的节点执行预定操作, 包括以下之一: 放 弃对取值失败的 item的节点的会话; 再次发送 Get命令对取值失败的 item 的节点进行取值。 具体地, 月艮务器在收到上述客户端的响应消息后,才艮据状态码 222就可 以知道 Get命令的处理结果为获取部分成功。 随后, 服务器会根据 Result标 签下的 Item判断哪些节点获取成功, 哪些获取失败, 对于成功的节点进行保 存, 对于失败的节点, 服务器可以选择放弃会话, 也可以单独再进行 Get命 令进行获取。 下面, 结合附图, 对服务器的操作进行详细的说明。 图 5是根据本发明 实施例的服务器在接收到携带有新的状态值的响应消息时的处理流程图, 如 图 5所示, 包括如下处理: 步骤 501 , 服务器收到客户端的响应信息; 步骤 502, 服务器判断响应消息的状态码是否为 222, 如果不是, 则进 行正常的处理流程, 并进入步骤 504, 如果是, 则执行步骤 503; 步骤 503 , 判断状态码为 222后, 执行处理策略, 包括: 保存正确的取 值,以及对未取得的值再次进行重试 Get操作等方法。其中,对未取得的 item 下节点的值可以进行重试, 也可以放弃; 步骤 504, 结束会话。 通过上述处理, 使月艮务器可以更高效的获取有用节点, 定位无法获取的 节点。 装置实施例一 根据本发明的实施例, 提供了一种客户端, 用于对设备管理协议中包含 多 item的 Get命令进行优化, 图 6是根据本发明实施例的客户端的框图, 如 图 6所示, 根据本发明实施例的客户端包括: 接收模块 60、 获取模块 62、 第一确定模块 64、 发送模块 66。 下面对根据本发明实施例的客户端进行详 细说明。 需要说明的是, 在进行下述处理前, 首先需要定义一个新的状态值, 用 以表示多个 Item的 Get命令部分执行成功的情况(即, 表示 Get命令中部分 item的节点取值失败)。 对于该状态值的定义, 本发明实施例不规定其形式, 在实际应用中, 该 新的状态值基本形式如其它的状态值一样, 只是取值与现有状态值不一样即 可。 例如, 可以定义该情形下的状态值为 900, 也可以定义它为 222。 为了 描述方便, 在下面的描述中, 本发明实施例使用 222来表示这种状态, 表示 对 Get命令的执行结果是 "部分成功"。 需要说明的是, 本发明实施例不仅仅 指定使用 222作为该状态的响应状态值。 下面, 对根据本发明实施例的客户端进行说明。 具体地, 接收模块 60用于接收服务器发送的 Get命令; 在接收模块 60 接收服务器发送的 Get命令后, 第二确定模块需要确定 Get命令中包含多个 item, 随后, 获取模块 62获取 Get命令中的所有 item下的节点的取值; 在 获取模块 62获取 Get命令中的所有 item下的节点的取值后, 第一确定模块 64确定有部分 item下的节点的取值失败; 随后, 发送模块 66向服务器发送 携带有表示执行 Get命令时部分 item下的节点取值失败的新的状态值的响应 消息, 其中, 响应消息中还携带有预定标签, 预定标签用于封装取值成功的 item下的节点信息。 其中, 返回的响应消息可以如下所示:
<SyncML xmlns="SYNCML:SY CML1.2">
<SyncHdr> <VerDTD> 1 2</VerDTD>
<VerProto>DM/ 1.2</VerProto>
<SessionID>8155</SessionID>
<MsgID> 1 </MsgID> ……略 </SyncHdr> <SyncBody> /3/:/ O /60sil£ssoiAV
Figure imgf000016_0001
o o
</Item>
</Results>
<Final />
</SyncBody> </SyncML> 从上面的描述可以看出, 釆用本发明实施例, 在返回的响应消息中有 2 个地方明显与传统的响应消息不同, 一是状态值不再是 425 (或其它失败消 息 ), 而是 222 (表示获取成功, 但不完整); 二是 SyncBody中, 除了对状态 Status 的描述外, 还添加上了获取信息成功的两个节点的信息, 一并发送给 艮务器端。 装置实施例二 根据本发明的实施例, 提供了一种服务器, 用于对设备管理协议中包含 多 item的 Get命令进行优化。 图 7是根据本发明实施例的服务器的框图, 如 图 7所示, 根据本发明的实施例的服务器包括发送模块 70、 接收模块 72, 下面, 对根据本发明实施例的服务器进行详细说明。 需要说明的是, 在进行下述处理前, 首先需要定义一个新的状态值, 用 以表示多个 Item的 Get命令部分执行成功的情况(即, 表示 Get命令中部分 item的节点取值失败)。 对于该状态值的定义, 本发明实施例不规定其形式, 在实际应用中, 该 新的状态值基本形式如其它的状态值一样, 只是取值与现有状态值不一样即 可。 例如, 可以定义该情形下的状态值为 900, 也可以定义它为 222。 为了 描述方便, 在下面的描述中, 本发明实施例使用 222来表示这种状态, 表示 对 Get命令的执行结果是 "部分成功"。 需要说明的是, 本发明实施例不仅仅 指定使用 222作为该状态的响应状态值。 下面, 对根据本发明实施例的服务器进行说明。 具体地, 发送模块 70用于向客户端发送 Get命令; 接收模块 72用于接 收客户端发送的携带有表示执行 Get命令时部分 item下的节点取值失败的新 的状态值的响应消息, 其中, 响应消息中还携带有预定标签, 预定标签用于 封装取值成功的 item下的节点信息。 在接收模块 72接收客户端发送的响应消息后, 确定模块会确定响应消 息中携带有新的状态值; 如果携带的是新的状态值, 其中的保存模块就会根 据预定标签获取节点信息, 并将节点信息进行保存; 随后, 执行模块对取值 失败的 item下的节点执行预定操作。 执行模块的操作包括以下之一: 放弃对 取值失败的 item的节点的会话; 再次发送 Get命令对取值失败的 item的节 点进行取值。 需要说明的是, 在不背离所附权利要求阐明的精神和范围的情况下, 可 以对上述各个模块进行各种改变以及组合。 综上所述, 借助于本发明的技术方案, 在执行含有多个 Item 的 OMA SyncML DM的 Get命令时, 客户端可以通过特殊的状态值告知服务器 Get 未能完全成功, 但有部分成功, 并且在 Result标签中附带这些成功获取了的 节点值, 解决了相关技术中 Get命令中某个或者多个 Item失败时, 其余获取 得的有效信息均无法生效的问题, 可以更高效的获取有用节点, 定位无法获 取的节点, 还提高了客户端对 Get命令操作的有效性, 避免了浪费网络资源 的情况发生。 显然, 本领域的技术人员应该明白, 上述的本发明的各模块或各步骤可 以用通用的计算装置来实现, 它们可以集中在单个的计算装置上, 或者分布 在多个计算装置所组成的网络上, 可选地, 它们可以用计算装置可执行的程 序代码来实现, 从而, 可以将它们存储在存储装置中由计算装置来执行, 或 者将它们分别制作成各个集成电路模块, 或者将它们中的多个模块或步骤制 作成单个集成电路模块来实现。 这样, 本发明不限制于任何特定的硬件和软 件结合。 以上所述仅为本发明的优选实施例而已, 并不用于限制本发明, 对于本 领域的技术人员来说, 本发明可以有各种更改和变化。 凡在本发明的 ^"神和 原则之内, 所作的任何修改、 等同替换、 改进等, 均应包含在本发明的保护 范围之内。

Claims

权 利 要 求 书
1. 一种节点信息获取方法, 用于对设备管理协议中包含多条目 item的获 取 Get命令进行优化, 其特征在于, 包括:
客户端接收服务器发送的所述 Get命令, 获取所述 Get命令中的所 有 item下的节点的取值, 并确定部分 item下的节点取值失败;
所述客户端向所述服务器发送携带有新的状态值的响应消息, 其 中, 所述新的状态值用于表示执行所述 Get命令时部分 item下的节点取 值失败, 且所述响应消息中还携带有预定标签, 所述预定标签用于封装 取值成功的 item下的节点信息。
2. 根据权利要求 1所述的方法, 其特征在于, 所述客户端接收服务器发 送的所述 Get命令之前, 还包括:
对所述 Get命令设置所述新的状态值, 其中, 所述新的状态值用于 表示所述部分 item下的节点取值失败。 根据权利要求 2所述的方法, 其特征在于, 所述客户端接收服务器发 送的所述 Get命令之后, 还包括:
所述客户端确定所述 Get命令中包含多个 item。 根据权利要求 3所述的方法, 其特征在于, 所述客户端向所述服务器 发送所述响应消息之后, 还包括:
所述服务器接收所述响应消息,并确定所述响应消息中携带有所述 新的状态值;
所述艮务器从所述预定标签获取所述取值成功的 item 下的节点信 息, 并将该节点信息进行保存;
所述艮务器对取值失败的 item下的节点执行预定操作。 根据权利要求 4所述的方法, 其特征在于, 所述预定操作包括以下之 放弃对所述取值失败的 item下的节点的会话; 一种客户端, 用于对设备管理协议中包含多条目 item的获取 Get命令 进行优化, 其特征在于, 所述客户端包括:
接收模块, 用于接收服务器发送的所述 Get命令;
获取模块, 用于获取所述 Get命令中的所有 item下的节点的取值; 第一确定模块, 用于确定部分 item下的节点取值失败;
发送模块, 用于向所述服务器发送携带有表示执行所述 Get命令时 部分 item下的节点取值失败的新的状态值的响应消息, 其中, 所述响应 消息中还携带有预定标签, 所述预定标签用于封装取值成功的 item下的 节点信息。 才艮据权利要求 6所述的客户端, 其特征在于, 所述客户端进一步包括: 第二确定模块, 用于确定所述 Get命令中包含多个 item。 一种服务器, 用于对设备管理协议中包含多条目 item的获取 Get命令 进行优化, 其特征在于, 所述客户端包括:
发送模块, 用于向客户端发送所述 Get命令;
接收模块, 用于接收所述客户端发送的携带有表示执行所述 Get命 令时部分 item下的节点取值失败的新的状态值的响应消息, 其中, 所述 响应消息中还携带有预定标签, 所述预定标签用于封装取值成功的 item 下的节点信息。 根据权利要求 8所述的服务器, 其特征在于, 还包括:
确定模块, 用于确定所述响应消息中携带有所述新的状态值; 保存模块, 用于才艮据所述预定标签获取所述取值成功的 item 下的 节点信息, 并将该节点信息进行保存;
执行模块, 用于对取值失败的 item下的节点执行预定操作。 根据权利要求 9所述的服务器, 其特征在于, 所述预定操作包括以下 之一:
放弃对所述取值失败的 item下的节点的会话;
PCT/CN2010/071937 2009-04-30 2010-04-20 节点信息获取方法、客户端、服务器 WO2010124571A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/259,178 US8892711B2 (en) 2009-04-30 2010-04-20 Method for acquiring node information, and client and server

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200910138532.0 2009-04-30
CN200910138532.0A CN101877861B (zh) 2009-04-30 2009-04-30 节点信息获取方法、客户端、服务器

Publications (1)

Publication Number Publication Date
WO2010124571A1 true WO2010124571A1 (zh) 2010-11-04

Family

ID=43020303

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/071937 WO2010124571A1 (zh) 2009-04-30 2010-04-20 节点信息获取方法、客户端、服务器

Country Status (3)

Country Link
US (1) US8892711B2 (zh)
CN (1) CN101877861B (zh)
WO (1) WO2010124571A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9026582B2 (en) * 2010-03-23 2015-05-05 Htc Corporation Device management methods and related apparatus for enhancing applicability of status messages in response to commands
US9131360B2 (en) 2010-12-10 2015-09-08 Htc Corporation Apparatus and method of open mobile alliance
CN103455366A (zh) * 2012-06-01 2013-12-18 阿里巴巴集团控股有限公司 一种调用外部***服务的方法及装置
CN103906089A (zh) * 2012-12-28 2014-07-02 中兴通讯股份有限公司 命令报文反馈方法及装置
US9867894B2 (en) 2015-07-02 2018-01-16 Xenex Disinfection Services, Llc. Germicidal apparatuses with configurations to selectively conduct different disinfection modes interior and exterior to the apparatus

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0921655A2 (en) * 1997-10-31 1999-06-09 Fujitsu Limited Multicast transmission method
CN1625865A (zh) * 2002-04-30 2005-06-08 诺基亚有限公司 用于管理树状数据交换的方法和设备
CN1852138A (zh) * 2005-07-30 2006-10-25 华为技术有限公司 一种终端管理方法及***

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6691165B1 (en) * 1998-11-10 2004-02-10 Rainfinity, Inc. Distributed server cluster for controlling network traffic
US6985921B2 (en) * 2001-02-06 2006-01-10 Hewlett-Packard Development Company, L.P. Reliability and performance of SNMP status through protocol with reliability limitations
US7343418B2 (en) * 2002-06-03 2008-03-11 Microsoft Corporation Peer to peer network
CN101282348B (zh) * 2007-04-06 2011-03-30 上海晨兴电子科技有限公司 运用http协议实现流媒体功能的方法
CN101175041A (zh) * 2007-11-29 2008-05-07 武汉理工大学 一种Ad Hoc网络最优能量消耗路径选择方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0921655A2 (en) * 1997-10-31 1999-06-09 Fujitsu Limited Multicast transmission method
CN1625865A (zh) * 2002-04-30 2005-06-08 诺基亚有限公司 用于管理树状数据交换的方法和设备
CN1852138A (zh) * 2005-07-30 2006-10-25 华为技术有限公司 一种终端管理方法及***

Also Published As

Publication number Publication date
CN101877861A (zh) 2010-11-03
CN101877861B (zh) 2015-05-06
US20120023216A1 (en) 2012-01-26
US8892711B2 (en) 2014-11-18

Similar Documents

Publication Publication Date Title
EP2326047B1 (en) Method and system for terminal configuration and management
JP6240312B2 (ja) M2m通信システムにおいて購読及び通知のための方法及びそのための装置
CN104883267B (zh) 网络配置访问方法及装置
KR101740449B1 (ko) M2m(machine-to-machine)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치
JP2007525870A (ja) 装置管理システム内における管理ノードの指定
WO2007003103A1 (en) A method for sharing data and a method for recovering the backup data
WO2009100632A1 (zh) 设备管理的方法和终端、装置、***
CN112449315A (zh) 一种网络切片的管理方法及相关装置
EP2512064A1 (en) Data configuration method and apparatus
KR101139836B1 (ko) 웹 서비스 기반 관리 서비스를 발견하기 위한 2단계 방식의방법 및 시스템
KR20170096632A (ko) 장치들에의 테넌시의 할당
WO2012122730A1 (zh) 基于Tr069协议获取设备状态的方法、ACS及***
WO2010124571A1 (zh) 节点信息获取方法、客户端、服务器
US9438603B2 (en) Method for managing access right of terminal to resource by server in wireless communication system, and device for same
KR102059643B1 (ko) 디바이스 관리 방법과 서버, 시스템 및 모바일 장치
CN103428013B (zh) 设备管理方法、***和网关设备
WO2014187241A1 (zh) 控制无线网络直连群组中无线设备断开的方法及无线设备
US20120079093A1 (en) Device management method, device management apparatus, and device management system
WO2012139463A1 (zh) 终端设备的初始化方法及装置
TWI474731B (zh) WiMAX用戶端及設置該WiMAX用戶端參數之方法
WO2014194526A1 (zh) 移动网络数据资源获取方法、设备及***
CN112087318B (zh) 一种网络管理方法、服务器、客户端及***
JP4989440B2 (ja) 端末管理システム、端末管理サーバ及び端末装置
JP5095831B6 (ja) 機器管理の方法、端末、装置およびシステム
Alliance Enabler Test Specification (Interoperability) for Lightweight M2M

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: 10769260

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13259178

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10769260

Country of ref document: EP

Kind code of ref document: A1