WO2009097801A1 - Method, terminal and server for version negotiation - Google Patents

Abstract

A method for the version negotiation, comprises: the server initiates a session to the terminal using a device management notification message; the device management message is initiated by the default protocol version on the server; if the terminal could not identify the device management notification message, a device management notification message of other protocol versions is retransmitted to the terminal.

Description

 Version negotiation method and terminal, server

 The present application claims priority to Chinese Patent Application No. 200810066058.0, entitled "Version Negotiation Method and Terminal, Server", filed on February 2, 2008, the entire contents of which is incorporated herein by reference. .

Technical field

 The present invention relates to device management, and more particularly to version negotiation in device management.

Background technique

OMA (Open Mobile Alliance) DM (Device Management) VI. ² (hereinafter referred to as the DM Specification) is a unified device management specification developed by the OMA DM WG. The DM system provides a low-cost solution for managing and setting environment and configuration information in wireless network terminal devices (such as mobile terminals and functional objects in terminals) to solve problems encountered during the use of these network devices. Install and upgrade software and firmware through OTA (over the air wireless network), and provide more personalized and personalized services to enhance the user experience. The party can be the information management department of the mobile operator, service provider or partner.

 The OMA DM technology consists of two phases, one of which is called Bootstrap (initialization, or boot), which enables a device to transition from an empty state with no parameter configuration to a state where a management session can be initiated to the DM server. The terminal that has been Bootstrap can be further Bootstrap so that the device can initiate a session to the new DM server. In addition to basic connection information, device and user application settings can be configured during the Bootstrap process.

One stage of the DM is the management phase, in which the server can manage or provision the terminal equipment. The DM management phase is divided into two phases: the session establishment phase and the management session phase, in which the process of the session establishment phase is as wrong! The reference source was not found. As shown in the following figure: When the server needs to manage the terminal, the server initiates a notification to the terminal, which is called management session package 0, and the management session package 0 includes information such as the protocol version, the session identifier, and the server identifier, and the management session packet 0 is used. The trigger terminal initiates a session to the server. After receiving the management session packet 0, the terminal starts to establish a session with the server, that is, sends a management session packet 1 to the server, and the management session packet 1 includes authentication information, device information, etc., for the server to verify the identity of the terminal and understand the terminal. Device related parameters. After receiving the management session packet 1, the server sends a management session packet 2 to the terminal, which includes authentication information, an initialization management operation, or a user interaction command, for the terminal to verify the identity of the server and start Some information about managing the terminal or interacting with the user for that management session.

 For the management session packet 0, the transmission mode may be different from the subsequent management session packet, and one of the transmission modes is implemented by WAP Push carried on the SMS (short message), and the terminal parses the WAP Push message. It can be known that the information in the message is for the DM application, and it is also known that the message is carried in the message.

 In addition to the case where the server initiates the session, the terminal may also initiate the session actively. The process at this time is different from the process in FIG. 1 above, that is, the process does not include the management tongue packet 0.

 Due to the development of OMADM, existing features are gradually unable to meet some new demands that are constantly emerging. Therefore, DM technology has begun and will continue to produce new versions of technical specifications. Different devices (including servers and terminals) in the prior art may be used. Different versions of the technical specifications, the same device may also support multiple versions of the technical specifications, these devices will have version compatibility issues when conducting a session.

Summary of the invention

 The technical problem to be solved by the embodiment of the present invention is that the server and the terminal cannot negotiate the version of each other.

 The method for version negotiation provided by the present invention is characterized in that it comprises:

 The server initiates a session to the terminal using the device management notification message;

 If the terminal cannot identify the protocol version of the device management notification message; then re-send the device management notification message of the other protocol version to the terminal.

 A version negotiation method provided by the present invention includes:

 The server initiates a session to the terminal using the device management notification message;

 If the terminal cannot completely identify the device management notification message, but can identify the server identifier and the session identifier in the device management notification message, send the first management session packet to the server according to the server identifier and the session identifier. ;

 If the server can identify the first management session packet, proceed with the session; if the server cannot identify the first management session packet, select another protocol version to resend the device management notification message to the terminal.

 A method for version negotiation provided by the present invention includes:

 The terminal initiates a session to the server by using the first management session packet;

If the server cannot identify the first management session packet, the terminal resends to the server Send the first management session package of the other protocol version.

 A version negotiation method provided by the present invention is characterized in that it comprises:

 The server sends a device management notification message to the terminal;

 The device management notification message includes a version number supported by the server; such that the terminal can select a version supported by the server to conduct a session with the server.

 A version negotiation method provided by the present invention includes:

 The terminal sends the first management session package to the server;

 If the server does not support the version of the first management session package, returning a second management session package to the terminal;

 The second management session package includes a version number supported by the server; such that the server can select a version supported by the server to conduct a session with the terminal.

 A terminal provided by the present invention includes:

 An identification unit, configured to identify a device management notification message sent by the server;

 The error response information unit is configured to generate and send the error response information to the server when the identification list cannot identify the device management notification message or partially identify the device management notification message sent by the server.

 A server provided by the present invention includes:

 a device management notification message packet sending unit, configured to send a device management notification message to the terminal; a policy setting unit, configured to set a policy;

 The policy processing unit is configured to process according to the policy setting unit when the terminal sends the error response information or sends the first management session packet.

 A terminal provided by the present invention includes:

 a first management session packet sending unit, configured to send a first management session packet to the server; a policy setting unit, configured to set a policy; and processed according to a policy set by the policy setting unit.

 A server provided by the present invention includes:

 An identifying unit, configured to identify a first management session packet sent by the terminal;

a second management session packet sending unit, configured to partially identify the first management session packet The second management session packet replies to the terminal.

 In the embodiment of the present invention, the version of the terminal and the server are negotiated, thereby achieving the effect of mutual compatibility between the devices.

DRAWINGS

 1 is a flow chart of a session establishment phase of a prior art DM management phase;

 2 is a flowchart of a version negotiation method according to Embodiment 1 of the present invention;

 3 is a schematic diagram of a terminal according to Embodiment 1 of the present invention;

 4 is a schematic diagram of a server according to Embodiment 1 of the present invention;

 FIG. 5 is a flowchart of another version negotiation method according to Embodiment 1 of the present invention; FIG.

 6 is a schematic diagram of another terminal according to Embodiment 1 of the present invention;

 Fig. 7 is another server of the first embodiment of the present invention.

detailed description

Embodiment 1

 According to different management initiators, the method is divided into two situations: server initiation and terminal initiation. When the server or terminal supports multiple versions of the protocol, the default protocol version is used to initiate the session. If only one version of the protocol is supported, the version itself is the default protocol version.

 The embodiment of the invention provides a method for version negotiation. The method is as shown in FIG. 2, including: the server uses a device management notification message to initiate a session to the terminal;

 The terminal identifies the device management notification message;

 When the terminal cannot recognize the device management notification message: no response or error response information is sent to the server; the server processes according to the local setting policy.

 When the terminal part identifies the management session package: no response is made or an error response message is sent to the server, and the server processes according to the local setting policy; or initiates a session with the server by using the first management session package, and the server processes according to the server local policy.

 details as follows:

 1, the server initiates a session

The server initiates a session with the terminal by using the management session package 0. Since the management session package 0 is initiated by the default protocol version on the server, the terminal has two cases for identifying the information in the management session package 0, that is, the management session cannot be recognized at all. Package 0, can partially identify management session packet 0. 1.1, the terminal can not identify the management session package at all 0

 If the DM agent in the terminal determines that the management session packet 0 sent by the server cannot be identified, the terminal may take different countermeasures according to the local settings, such as not responding, or sending a management packet to the client. The server feedback error response information, the error response information includes at least an error prompt and a correlation identifier (Correlator), wherein the error prompt indicates to the server that the terminal does not recognize the management session packet 0; the correlation identifier is for the receiver (ie the server) to identify which error response message is for the management session packet 0, which requires the server to carry the same correlation identifier when sending the management session packet 0, which can be associated with the management session packet 0 It is carried in the SMS at the same time, and can carry different correlation identifiers when sending different management session packets 0. Optionally, the information may also be used to manage the session including the DM protocol version supported by the terminal. The error response information can be implemented by using various transmission means, and the present invention is not limited, and one of the methods is to use SMS.

 After the server receives the error response message, if the message only contains an error message, the server selects to initiate another version of the management session packet 0 according to the local policy setting, and the policy may be sequentially selected or preset. Priority selection. If the management session also includes a protocol supported by the terminal to resend the management session packet 0, the method of selection is also set according to local policies, such as in order or by a certain priority. If the server only supports one version of the protocol or tries all the supported versions of the protocol to the terminal, then no action is taken after receiving the error response message.

 In this case, if the terminal chooses not to respond, the server may process according to the local policy settings, for example, after more than one time threshold, repeatedly initiate management session packet 0. It can be repeated sending the same version of the management package 0, or repeatedly sending different versions of the management session package 0, or a combination of various forms of the two cases to ensure that the terminal can receive the correct or compatible version accurately and quickly. Management session package 0.

 1.2, terminal part identification management session package 0

In this case, the DM proxy of the terminal can partially identify the management session packet 0, and at least identify the server identification information and the session identification information included in the management session packet 0, and the terminal can completely follow the method of case 1.1. In addition, the session can be initiated directly with the server, that is, the management session packet 1 is sent, and the protocol version used for initiating the session is determined by the policy set locally by the terminal. Such as from high to low or a certain priority. After receiving the management session packet 1, the server selects whether to continue the session according to the support for the management session packet 1 protocol version, that is, if the protocol version of the management session packet 1 is supported, the session is continued. If not, the server according to the local policy setting Select to initiate another version of Management Session Pack 0, which can be selected in order or by a certain priority. If the server only supports one version of the protocol, then no action is taken after receiving the management session package 1. The server in the management session package 0 may include all the version numbers supported by the server, in addition to the protocol version number of the identity management session package 0 itself, and may optionally include the preferred version number recommended by the server. The terminal can determine a version according to the information to establish a session with the server, for example, the terminal selects to use the same version as the management session package 0, or selects one of the versions supported by the server, or selects the preferred version number recommended by the server, so as to avoid the above The repeated attempts described save resources and time.

 An embodiment of the present invention provides a terminal. As shown in FIG. 2, the terminal includes:

 An identification unit, configured to identify a device management notification message sent by the server;

 The error response information unit is configured to generate and send the error response information to the server when the identification list cannot identify the device management notification message or partially identify the device management notification message sent by the server.

 The terminal may further include a first management session packet sending unit, configured to initiate a session with the server by using the first management session packet when the identifying unit portion identifies the device management notification message sent by the server.

 An embodiment of the present invention provides a server. As shown in FIG. 4, the server includes:

 a device management notification message sending unit, configured to send a device management notification message to the terminal; a policy setting unit, configured to set a policy;

 The policy processing unit is configured to process according to the policy setting unit when the terminal sends the error response information or sends the first management session packet. The embodiment of the present invention further provides a method for version negotiation, where the method is as shown in FIG. 5, the terminal initiates a session with the server by using the first management session package;

The server identifies the first management session package; The server does not respond to the second management session packet, and the terminal terminates the session beyond the time threshold, and processes according to the local policy of the terminal;

 When the server part identifies the first management session packet, the second management session packet is used to reply to the terminal. If the terminal supports the protocol version of the second management session packet sent by the server, the first management session packet of the protocol version is redirected to the server. Send, if not supported, send to the server with the first management session packet of the other protocol version.

 details as follows:

 The terminal initiates a session with the server by using the management session package 1. Since the management session package 1 is initiated by the default protocol version on the terminal, the server has several cases for identifying the information in the management session package 1, that is, the management session cannot be recognized at all. Package 1, can partially identify management session package 1.

 2.1, the server does not recognize the management session package at all 1

 At this point, the server discards the management session packet 1 and does not respond. The terminal terminates the session after more than one time threshold, and then processes according to the local policy settings, for example, repeatedly sending the same version of the management session packet 1, or repeatedly sending. Different versions of Management Session Pack 1 are required to ensure that the server can receive the correct or compatible version of the Management Session Pack 1 accurately and quickly. If the terminal only supports one version of the protocol, the session is no longer initiated.

 2.2, the server can partially identify the management session package 1

 In this case, the server can at least identify the session identifier in the management session packet 1, and optionally, the terminal identifier can be identified. In this way, the server can select the supported protocol version to reply to the management session packet 2 to the terminal, and the selected method is also selected according to the policy setting order or by priority. The management session package 2 includes the version number supported by the server. Optionally, it also includes an error message indicating to the terminal that the management session package 1 is not supported.

 The terminal determines whether the version number of the management session package 2 is supported. If it is supported, the management session packet is resent to the server according to the protocol of the version. If not, the terminal selects to send the other version of the management session packet according to the policy. Then repeat the steps in 2.2.

The terminal includes all the version numbers supported by the terminal, and may also include the preferred version number recommended by the terminal, in addition to the protocol version number of the management management session package 1 itself. The server determines a version based on the information to establish a session with the terminal, for example, the server selects to use the same version as the management session package 1, or selects one from the version supported by the terminal, or selects the terminal. The preferred version of the recommendation, which avoids multiple iterations as described above, saving resources and time. The embodiment of the invention provides a terminal. As shown in FIG. 6, the terminal includes:

 a first management session packet sending unit, configured to send a first management session packet to the server;

 The policy setting unit is used to set the policy; it is processed according to the policy set by the policy setting unit.

 The embodiment of the present invention further provides a server, as shown in FIG. 7, the server includes: an identifying unit, configured to identify a first management session packet sent by the terminal;

 And a second management session packet sending unit, configured to reply to the terminal by using the second management session packet when the first management session packet is partially identified.

 The method provided in Embodiment 1 can not only negotiate during the management session, but also negotiate only the version, that is, the session package does not include other management session contents except the version-related fields. In this case, the session package Dedicated to the negotiated version between the server and the terminal, and the management session begins after the version is negotiated. This negotiation process can be in the same session as the subsequent management session process or in different tongues.

Embodiment 2

 The protocol versions supported by the terminal are 1.3 and 1.4, and the servers support 2.0, 1.2, 1.3, and 1.4. The server initiates the management session packet 0 to the terminal with the default protocol version 2.0. The specific contents of the management session packet 0 are as follows:

 2.0! .... i tongue ID Server ID The version information is given at the very front of the management session pack 0. In addition, the association with the management session packet 0 may also include a correlation identifier, such as using a string abc, or using the time of sending the packet as a correlation identifier, such as 20080201143300, without limiting the specific representation of the correlation identifier. After receiving the management session packet, the terminal finds that the protocol version is not supported at all. If the feedback flag set locally is feedback error response information to the server and the terminal receives the correlation identifier, the terminal feeds back the information to the server as follows:

Error: 100 version does not support 1.3; 1.4 where Error: 100 indicates that the terminal is responding with an error, the error type is 100, the error description is "version not supported", and the following 1.3; 1.4 is the terminal support version. The type of error can be no, That is, it is only indicated by Error, and the terminal support version may not be available because it is optional. In addition, 20080201143300 is the correlation identifier fed back to the server, indicating that this is a reply to the management session packet 0 sent above, instead of the other management session packet 0, which is mandatory.

 After the server receives the error response information, if the information does not include the version information supported by the terminal, that is, 1.3; 1.4 is not included, the server performs subsequent processing according to the locally set policy. The policy set locally by the server may be a version selection policy. The flag bit, for example, the flag bit = 0 indicates that the version is selected in descending order, the flag bit = 1 indicates that the version is selected in order from small to large, and the flag bit = 2 indicates that the version is selected in the preset version order, for example, preset. The version order is 2.0, 1.2, 1.3.... and so on. If the flag is equal to 2, the server will initiate management session packet 0 again, and the protocol version is 1.2. The above process will be repeated by the subsequent terminal and server.

 After the server receives the error response message, if the information includes the version information supported by the terminal, that is, 1.3; 1.4, the server selects a version according to the local policy flag bit, and the flag bit setting may be the same as the above version selection policy flag bit. similar. If the flag is set to =1, the server selects the version from the smallest to the largest. The version 1.3 again initiates the management session packet 0.

 Note that if the server only supports version 2.0, you will not receive any subsequent actions after receiving the error response message. In this example, if the feedback flag set in the terminal is no response, the server may perform corresponding processing according to a locally set time gate P艮 and a repeated transmission policy flag, for example, the time threshold is set to 60 seconds, and the transmission is repeated. The policy flag is: Flag bit = 0 indicates that the version 2.0 management session packet 0 is sent three times, then the management session packet 0 of version 1.2 is sent three times, and so on until all versions are sent; the flag bit = 1 indicates duplicate Send 1.2 management session package 0 until all versions have been sent, then repeat the 2.0 version of management package 0, and so on. The time threshold and flag bits can also be set to other values, and parameters such as the number of repetitions, the order of rotation, the number of version rotations, and the like should not be construed as limiting the invention. If the terminal initiates a session with the server during the iterative process, the iterative process stops.

Embodiment 3

 The protocol versions supported by the terminal are 1.3 and 1.4, and the servers support 2.0, 1.2, and 1.3. The server initiates the management session packet 0 to the terminal with the default protocol version 2.0. The specific contents of the management session packet 0 are as follows:

2.0 .... tongue identification server identification The terminal identifies the server ID and session identifier information included in the management session packet 0, and directly initiates a session with the server using version 1.4. The version used to initiate the session is determined by the local policy flag, which is the server-side version in the second embodiment. The selection strategy flag is similar and will not be mentioned.

 Since the server does not support version 1.4, the server terminates the session and then initiates other versions of the management session package 0 according to the local policy flag bits, for example, the version 1.3 management session package 0 is initiated in descending order.

 The terminal can initiate the management session package of version 1.3 this time. 1 Start a management session with the server. Embodiment 4

 The protocol version supported by the terminal is 1.2 and 2.0, and the server supports 2.0.

 The terminal uses the default protocol version 1.2 to initiate the management session package 1. The management session package 1 is as follows:

<SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerDTD>l .2</VerDTD>

 <VerProto>DM/l .2</VerProto>

 <SessionID> 1 </SessionID>

</SyncHdr>

 <SyncBody> </SyncBody>

</SyncML>

 Where <^1⁄23⁄40 〖0> identifies the DM protocol version.

 The server does not respond because it cannot recognize the management session packet 1. The time threshold is set to 30 seconds on the terminal, and a repeat transmission policy flag similar to that of the second embodiment is set. After 30 seconds, the terminal terminates the session, and then the 2.0 version of the management session package 1 is repeatedly sent to re-establish the session. The server can identify the management session package 1 and the management session begins.

Embodiment 5

 The protocol versions supported by the terminal are 1.2 and 2.0, and the servers support 2.0 and 3.0.

The terminal initiates management session package 1 using the default protocol version 1.2. The management session package 1 is as follows: <SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerDTD>l .2</VerDTD>

 <VerProto>DM/l .2</VerProto>

 <SessionID>2</SessionID>

 <MsgID>K/MsgID>

<Source>

 <LocURI>IMEI:493005100592800</LocURI>

 </Source>

</SyncHdr>

 <SyncBody> </SyncBody>

</SyncML>

 In this example, the server can partially identify the session identifier in the management session packet 1, that is, the content in <8688101110>, and optionally identify the terminal identifier, that is, the content in <801«^>, and the message identifier, that is, < MsgID>† content. The server then selects the version of the reply according to a setting of the version selection flag in the second embodiment. According to the flag bit, the server selects the version 2.0 to reply to the terminal with the management session package 2, and the management session package 2 is as follows:

<SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerSchema>2.0</VerSchema>

 <VerProto>DM/2.0</VerProto>

 <SessionID>2</SessionID>

<Target>

<LocURI>IMEI:493005100592800</LocURI> </Target>

</SyncHdr>

 <SyncBody>

 <Status>

 <MsgRef> 1 </MsgRef><CmdRef>0</CmdRef>

 <Cmd>SyncHdr</Cmd>

 <CmdID>6</CmdID>

 <SourceRef>IMEI:493005100592800</SourceRef> <Data>430</Data><!—Version is not supported ~>

 </Status>

</SyncBody>

</SyncML>

 The management session package 2 optionally includes a <Status> portion for prompting the terminal. The server does not support the management session package version 1. After receiving the management session package 2, the terminal determines the version number or <Status>. The server does not support 1.2, but supports 2.0, the terminal uses version 2.0 to re-initiate management session package 1 to establish a session with the server, and then the terminal locally records the version of the session with the server, and still uses the version and server in the next management session. Session, the method of recording can be to modify the default protocol flag. After the server receives the management session packet 1 and determines that the management session packet is completely supported by the terminal, the management session starts.

Embodiment 6

 The protocol version supported by the terminal is 1.2, and the server supports 1.2, 2.0 and 3.0.

 The server initiates management session package 0 using the default protocol version 1.2, which also includes all version numbers supported by the server, and the preferred version number recommended by the server. The preferred version number is an optional field, and the management session package 0 is as follows:

1.2 1.2; 2.0; 3.0 2.0 Session ID Server ID where 1.2; 2.0; 3.0 is all supported version numbers, followed by 2.0 is the preferred version number. These two messages can be used to manage the reserved field of session packet 0 in the version 1.2 protocol before sending management session packet 0. Insert the corresponding field to achieve, of course, if you do not use the 1.2 version of the management session package 0, then the insertion position of these two fields is not limited. In addition, if there is no preferred version number, the field is padded with 0.

 The terminal recognizes that the management session package 0 uses a version of 1.2 and initiates a management session using version 1.2. If the version supported by the terminal is 2.0 and 3.0, the version can be selected according to the setting of the local flag: Flag bit=0 Select the version recommended by the server and supported by the terminal. If not recommended, select the priority supported by the server and the priority in the terminal. High version; flag bit = 1 Select the version supported by the server and with a higher priority in the terminal. Thus, if the flag bit is 0, the terminal establishes a session using version 2.0. If 1, and the priority of version 3.0 in the terminal is high, the terminal uses the version 3.0 to establish a tongue. The terminal then records the version of the session with the server locally, and still uses this version to talk to the server the next time the session is managed.

Example 7

 The protocol versions supported by the terminal are 2.0 and 3.0, and the servers support 2.0 and 3.0.

 The terminal initiates a management session package 1 using the default protocol version 3.0, which also includes all version numbers supported by the terminal. The management session package 1 is as follows:

<SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerSchema>3.0</VerSchema>

 <VerProto>DM/3.0</VerProto>

 <VerProtoSet>DM/2.0/3.0<A3⁄4rProtoSet>

 <SessionID>2</SessionID>

</SyncHdr>

 <SyncBody> </SyncBody>

</SyncML>

If the server cannot identify the management session packet 1, it uses the trial error method similar to that in the fourth embodiment to solve. In this example, the server can partially identify the management session packet 1, and then select the version of the reply according to the setting of a version selection flag bit: flag bit=0 selects the version used by the terminal, flag bit=1 according to service The default version of the server is selected (2.0, 3.0). If the flag is set to 1, the server selects version 2.0 to reply to the management session packet 2, and the management session package 2 is as follows:

<SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerSchema>2.0</VerSchema>

 <VerProto>DM/2.0</VerProto>

 <SessionID>2</SessionID>

</SyncHdr>

 <SyncBody>

</SyncBody>

</SyncML>

 After receiving the management session package 2, the terminal continues the session with the server using version 2.0, and then the terminal locally records the version of the session with the server, and still uses the version to communicate with the server during the next management session. The recording method may be Modify the default protocol flag.

Example eight

 The protocol versions supported by the terminal are 1.2 and 2.0, and the servers support 1.2, 2.0 and 3.0. The server initiates management session package 0 using the default protocol version 1.2, which also includes all version numbers supported by the server, and the preferred version number recommended by the server, wherein the preferred version number is an optional field, and the management session package 0 is as shown in the following table. :

 3.0 1.2; 2.0; 3.0 version negotiation ^ tongue identification server identification where 1.2; 2.0; 3.0 is all supported version numbers, followed by 0 means no preferred version, followed by "version negotiation" means that the purpose of this session is for version negotiation . This information can be implemented by inserting the corresponding field in the reserved field of the management session packet 0 in the version 1.2 protocol before sending the management session packet 0. Of course, if the management session packet 0 of version 1.2 is not used, the insertion of these fields is not limited. position.

The terminal can select the version according to the setting of the local flag bit: the flag bit=0 selects the version recommended by the server and supported by the terminal, and if not recommended, selects the server-supported and high priority in the terminal. Version; flag = 1 selects the version supported by the server and has a higher priority in the terminal. If the flag is set to 1, and the priority of version 2.0 is high, the terminal uses the version 2.0 to send the management tongue packet 1. The terminal records the negotiated session version locally, and uses version 2.0 and the server in the future management session with the server. Continue the conversation. Management session package 1 is as follows:

<SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerSchema>2.0</VerSchema>

 <VerProto>DM/2.0<A3⁄4rProto>

 <VerProtoSet>DM/1.2/2.0<A3⁄4rProtoSet>

 <SessionID>3</SessionID>

 </SyncHdr>

</SyncML>

 Note that other management session content is not included in this management session package. In addition, <VerProtoSet> is an optional field.

 After the server receives the management session packet 1, the session can be ended, or the management session can be followed. The server records the negotiated session version locally, and uses the 2.0 version protocol in the future management session with the terminal. Of course, because there is a ^^1^0861> field, the server can also select the 1.2 version in the future session. See if the settings on the terminal accept the session for that version.

 If the terminal and the server do not support the same version of the protocol, for example, the terminal only supports version 1.3 in this example, the packet 1 replied to the server can be as follows:

 <SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerDTD>l .3</VerDTD>

 <VerProto>DM/l .3</VerProto>

 <VerProtoSet>DM/l .3<A3⁄4rProtoSet>

 <Data>430</Data>< !—Version is not supported ~>

 </SyncHdr>

</SyncML>

Terminal <Data> tells the server that the version is not supported, and <Data> is an optional field. Example nine

 The protocol versions supported by the terminal are 2.0 and 3.0, and the servers support 2.0 and 3.0.

 The terminal initiates a management session package 1 using the default protocol version 2.0, which also includes all version numbers supported by the terminal. The management session package 1 is as follows:

<SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerSchema>2.0</VerSchema>

 <VerProto>DM/2.0<A3⁄4rProto>

 <VerProtoSet>DM/2.0/3.0</VerProtoSet>

 <SessionID>4</SessionID>

 </SyncHdr>

</SyncML>

 The server selects the version of the reply according to the setting of a version selection flag: Flag bit = 0 Selects the version used by the terminal, and the flag bit = 1 is selected in the order of the server preset (2.0, 3.0). If the flag is set to 1, the server selects the version 2.0 to reply to the management terminal 2, and the server records the negotiated session version locally, and uses the version 2.0 protocol in the future management session with the terminal. Session Pack 2 looks like this:

<SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerSchema>2.0</VerSchema>

 <VerProto>DM/2.0</VerProto>

 <VerProtoSet>DM/2.0/3.0<A3⁄4rProtoSet>

 <SessionID>4</SessionID>

 </SyncHdr>

</SyncML>

Note that in the above two management session packets, the management session package does not include other management session contents. The two parties can determine according to this situation that this is a version negotiation process, excluding management content. Of course, you can also add a management session package. Field, such as <86881011 Ding 6>, to indicate that this session is Version negotiation session. In addition, <VerProtoSet> is an optional field.

 After receiving the management session package 2, the session can be ended, or the management session can be followed. The terminal records the negotiated session version locally, and uses version 2.0 and the server to continue the management session with the server in the future. The method of recording may be to modify the default protocol flag. Of course, because of the <VerProtoSet> field, the terminal can also select version 3.0 in a future session, and then see if the settings on the server accept the version of the session.

 In addition, if the server version is not supported, you can also reply to the information that is not supported by the version in package 2. Example ten

 As mentioned in the third and fifth embodiments, the terminal and the server can partially identify the management session packet sent by the other party, and the field in the management session packet needs to be set to a version-compatible field, for example, the management session package in the second embodiment. 0: as shown in the following table:

 2.0 .... tongue identification server identifier Since the terminal does not support version 2.0, the session identifier and server identification field need to be set to the version compatibility field, that is, the position of these two fields is set to version 1.2 in version 2.0. The same place, this can facilitate the terminal of 1.2 to contact the server. This method can be extended to more versions so that each version of Management Session Pack 0 has some compatibility. Of course, the version identifier can also be fixed at the beginning of the management session packet 0 as a version compatibility field.

 For another example, in the management session package 1 in the fifth embodiment:

<SyncML xmlns='SYNCML:SYNCMLl .2'>

 <SyncHdr>

 <VerDTD>l .2</VerDTD>

 <VerProto>DM/l .2</VerProto>

 <SessionID>2</SessionID>

 <MsgID>K/MsgID>

<Source>

 <LocURI>IMEI:493005100592800</LocURI>

</Source> </SyncHdr>

 <SyncBody>

</SyncBody>

</SyncML>

 Both the server and the terminal can set <8688101110> as a version-compatible field, that is, the name and position of the field remain unchanged regardless of any version, so that both parties can identify a session through it, and then reply to the tongue. So that the parties will not immediately terminate the session because they are unrecognizable. The <Source> <MsgID> field can also be set to the version compatibility field.

 The <VerProtoSet> mentioned in the seventh embodiment and related embodiments can also be set as a version compatible field.

 In addition, <^3⁄4^丁0>, <^1⁄2^ mentioned in the related embodiments. 11611^> and <^1⁄2^1"01;0> can also be set to version compatible fields to meet the requirements of the mutual negotiation method and the version negotiation session method.

Embodiment 11

 As mentioned in Embodiments 6 and 8, the management session package 0 includes all the version numbers supported by the server in addition to the protocol version of the server, and optionally includes the preferred version number recommended by the server, and also includes the seventh embodiment. Version negotiation field. This can be achieved by extending the function in the management package 0. Of course, it can also be implemented by adding new fields. This example is described in more detail on the basis of the previous example.

 (1) In the existing version 1.2 protocol of the DM, an empty field has been reserved in the management session package 0 for future expansion functions. The present invention has made some extensions to the 1.2 protocol, and all versions supported by the server and The preferred version is placed in this field as shown in the following table:

 1.2 1.2;2.0;3.0 2.0 version negotiation Session ID Server ID

 1.2; 2.0; 3.0 is the supported version number, and the following 2.0 is the preferred version number. The subsequent version negotiation indicates that the purpose of this management session package is to establish a version negotiation session instead of a management session.

 The three fields of the extension can be set to the version compatibility field as described in Embodiment 10, that is, all subsequent versions can recognize the location and content of the field, so that the versions of the terminal and the server can be mutually negotiated.

(2) As mentioned above, it can also be implemented by adding a new field. As shown in the above table, only the position of the field may be different, and the present invention does not limit the specific location of the field in the management session packet 0. But this Similarly, terminals that support version 1.2 cannot recognize these three fields, and only the terminals of subsequent versions can recognize them. Alternatively, you can set the new field to be a compatible field for all subsequent versions.

 Note that in the above method, the specific content and representation of the field are not limited. For example, 1.2; 2.0; 3.0 can be expressed only as 3.0, and then the default server supports all versions below 3.0, namely 1.2 and 2.0. In addition, it is not necessary to divide by a semicolon, and it can be expressed in other ways, as long as the terminal can know the version supported by the server.

 The same is true for the ^^1^0861> mentioned in the seventh embodiment and subsequent related embodiments, that is, it can be realized by the function extension on the 1.2 version or adding a new field in the subsequent version, and the specific content and the same are not limited. display method.

Example 12 determines the corresponding field

 In the header of the DS notification packet, except for the notification-id, the rest of the content is exactly the same as the DM.

Thus, the methods of the above embodiments can be applied to DS.

 For other data synchronization packages, such as data synchronization package 1, as follows:

<SyncML>

 <SyncHdr>

 <VerDTD> 1.2</VerDTD>

 <VerProto>SyncML/l .2<A3⁄4rProto>

 <SessionID>4</SessionID>

 <MsgID>K/MsgID>

 <Target>

 <LocURI>http ://www. syncml.org/ sync-server</LocURI>

 </Target>

 <Source>

 <LocURI>IMEI:493005100592800</LocURI>

</Source> </SyncHdr>

 <SyncBody>

</SyncBody>

</SyncML>

 This is exactly the same as the DM, and therefore the methods of the above embodiments are also applicable.

Claims

Rights request

 A method for version negotiation, which is characterized by comprising:

 The server initiates a session to the terminal using the device management notification message;

 If the terminal cannot identify the protocol version of the device management notification message; then re-send the device management notification message of the other protocol version to the terminal.

 2. The version negotiation method according to claim 1, wherein the selection of the other protocol versions is selected in descending order.

 The version negotiation method according to claim 1, wherein the determining that the terminal cannot identify the device management notification message is: the first management session of the terminal is not received within a preset time. The packet or the error response information fed back by the terminal, the error response information indicating that the terminal cannot identify the device management notification message.

 The version negotiation method according to claim 3, wherein the error response information includes device management protocol version information supported by the terminal;

 After receiving the error response information, the server resends the device management notification message according to the device management protocol version supported by the terminal.

 The version negotiation method according to claim 3, wherein the error response information is transmitted by using a short message SMS.

 6. A version negotiation method, comprising:

 The server initiates a session to the terminal using the device management notification message;

 If the terminal cannot completely identify the device management notification message, but can identify the server identifier and the session identifier in the device management notification message, send the first management session packet to the server according to the server identifier and the session identifier. ;

 If the server can identify the first management session packet, proceed with the session; if the server cannot identify the first management session packet, select another protocol version to resend the device management notification message to the terminal.

 7. A method of version negotiation, characterized in that it comprises:

 The terminal initiates a session to the server by using the first management session packet;

If the server cannot identify the first management session packet; the terminal resends the first management session packet of the other protocol version to the server.

8. The version negotiation method according to claim 7, wherein the selection of the other protocol versions is selected in descending order.

 The version negotiation method according to claim 8, wherein the determining that the server cannot identify the first management session packet is based on: not receiving the second management of the server within a preset time. The tongue packet or the error response information received by the server, the error response information indicating that the server cannot identify the device management notification message.

 10. The version negotiation method according to claim 9, wherein the error response information includes device management protocol version information supported by the server;

 After receiving the error response information, the terminal resends the first management session packet according to the device management protocol version supported by the server.

 The version negotiation method according to claim 9, wherein the error response information is transmitted by using a short message SMS.

 12. A version negotiation method, comprising:

 The server sends a device management notification message to the terminal;

 The device management notification message includes a version number supported by the server; such that the terminal can select a version supported by the server to conduct a session with the server.

 13. The method of version negotiation according to claim 12, wherein the device management terminal preferentially selects the preferred version number and the server for subsequent sessions.

 14. The version negotiation method of claim 13, further comprising: the terminal establishing a session with the server using a version lower than a preferred version number recommended by the server in the notification message.

 The 15-version version negotiation method is characterized in that it comprises:

 The terminal sends the first management session package to the server;

 If the server does not support the version of the first management session package, returning a second management session package to the terminal;

 The second management session package includes a version number supported by the server; such that the server can select a version supported by the server to conduct a session with the terminal.

16. The method of version negotiation according to claim 15, wherein said second tube The session package also includes a preferred version number recommended by the server, so that the terminal can preferentially select the preferred version number and perform subsequent subsequent steps with the server.

 17. The version negotiation method of claim 16, further comprising: the terminal establishing a session with the server using a version lower than a preferred version number recommended by the server in the second management session package.

 18. A terminal, comprising:

 An identifying unit, configured to identify a device management notification message sent by the server;

 The error response information unit is configured to generate and send the error response information to the server when the identification list cannot identify the device management notification message or partially identify the device management notification message sent by the server.

 19. A server, comprising:

 a device management notification message packet sending unit, configured to send a device management notification message to the terminal; a policy setting unit, configured to set a policy;

 The policy processing unit is configured to process according to the policy setting unit when the terminal sends the error response information or sends the first management session packet.

 20. A terminal, comprising:

 a first management session packet sending unit, configured to send a first management session packet to the server; a policy setting unit, configured to set a policy; and processed according to a policy set by the policy setting unit.

 21. A server, comprising:

 An identifying unit, configured to identify a first management session packet sent by the terminal;

 And a second management session packet sending unit, configured to reply to the terminal by using the second management session packet when the first management session packet is partially identified.