一種節點信息的發送方法和裝置的制作方法

專利名稱：一種節點信息的發送方法和裝置的制作方法
技術領域：
本發明關于無線通信領域，特別關于無線通信中的設備管理規范技術， 具體的講是一種一種節點信息的發送方法和裝置。
背景技術：
開放移動聯盟設備管理規范VI.2 (Open Mobile Alliance Device Management VI.2，以下簡稱DM規范)是OMA DM WG制定的設備管理統 一規范。DM規范提供了一種低成本方案，用于第三方管理和設置無線網絡終 端設備(比如手機終端及終端中的功能對象)中的環境和配置信息、解決這 些網絡設備在使用過程中遇到的問題，通過OTA(over the air無線網絡)方式 進行軟件和固件的安裝、升級等操作，并提供更加人性化和個性化的服務， 提高用戶體驗。其中，第三方可以是移動運營商，業務提供商或者合作方的 信息管理部門。
如圖1所示，為現有DM規范的整體結構圖，其中，終端設備上的DM代 理(DM Agent)用于解釋和執行DM服務器下發的管理命令。終端設備上存 儲的DM管理樹可以被認為是一個DM服務器通過DM協議對終端設備進行 管理的接口。其中DM管理樹包括一些基本管理對象(MO， Management Object)， DM服務器通過對管理樹對象的操作達到控制終端管理對象的目的， 操作命令有獲取(Get)、替換(Replace)、執行(Exec)、復制(Copy)、刪除 (Delete)等。其中，所述的基本管理對象擁有自己的標識，稱為管理對象標 識(MOI)，用以唯一的標識一個管理對象。
DM管理樹、管理對象是由節點組成的，例如根節點、內部節點和葉子節
5點，每個節點都有自己的屬性。葉子節點可以有節點值，但不能再有子節點， 內部節點不能有節點值，但可以有子節點。在管理樹中還存在著一類未命名 節點，它起到占位符的作用，當服務器或終端對它進行實例化時，它才會被 命名，這類節點叫做X節點。命名后，該節點及其下面的子節點被稱為實例。
若該節點正好是MO的根節點，則稱作MO實例。
如圖2中的連接參數管理對象、設備信息管理對象等都屬于內部節點， 而設備ID、制造廠商、終端型號都屬于葉子節點。OMADM規范定義了一套 設備管理樹節點的屬性值，用于對節點進行描述，各屬性值主要包括權限 控制列表、類型、格式、名稱、大小、位置(統一資源標識，URI， Unified Resource Identifier)等。
由于設備生產廠商的競爭，不同類型的終端會有不同的內部結構，管理 對象的結構和其包含的節點的屬性等也不相同，因此在DM服務器可以對終 端設備進行管理之前，需要規定一種方法使設備的生產商可以對終端設備進 行描述，并告知DM服務器，這樣，DM服務器才可以根據這個描述對終端 進行管理，這種描述方法稱為DDF (設備描述框架)。
DM規范技術包括兩個階段，其中第一個階段稱為Bootstrap (初始化， 或引導)，該階段能使一個設備從沒有參數配置的空狀態轉換到可以向DM 服務器發起管理會話的狀態。除了基本的連接信息外，設備和用戶應用設置 信息也可以在Bootstrap過程中進行配置。第二個階段為管理階段，在此階段 服務器就可以對終端設備進行管理或信息的設置。
Bootstrap可以通過兩種方法來實現， 一種是CP，即客戶端配置， 一種是 DM，即使用DM的消息來初始化。
OMA DM定義了 DMAcc (設備管理帳號)標準管理對象，這個對象存 儲的是終端與服務器建立連接時所需要的相關參數，如連接參考、服務器地 址和認證信息等。DMAcc的信息主要是通過Bootstrap技術來配置的。
OMA DM還定義了 Inbox (收件箱)標準管理對象，使用這個對象，月艮務器對終端添加管理對象時，可以不給出添加的絕對路徑，而告知終端MOI 讓終端自己解析對象的路徑。
DM服務器對終端進行管理的前提是需要了解當前終端上的管理樹相關
信息，例如節點的位置、名稱和節點值等，但有時終端并未告知服務器這些 信息，或者單方面修改這些信息，導致雙方的信息不對稱。
現有技術有一種方法是服務器通過發送獲取命令或搜索命令在管理樹上
査找一個節點的位置，即URI。
在實現本發明過程中，發明人發現現有技術中至少存在如下問題現有
技術需要服務器發送命令并同時給出一些節點相關信息，然后終端在管理樹 上搜索節點的相關信息才能獲得節點位置，這首先使得雙方需要建立一個會 話來完成該搜索任務，其次需要在終端上設計一個搜索程序并花費時間執行 該程序。所以該技術方案是一種低效和浪費資源的做法。

發明內容
本發明的目的在于提供一種節點信息的發送方法，用以解決現有服務器 與終端之間為獲取節點信息而造成資源浪費的問題。
本發明的目的在于提供一種節點信息的發送裝置，用以解決現有服務器 與終端之間為獲取節點信息而造成資源浪費的問題。
為了實現上述目的，本發明實施例提供一種節點信息的發送方法，該方
法包括從設備管理服務器接收節點建立消息；根據所述節點建立消息在終
端設備管理樹中建立相應節點；向所述設備管理服務器發送所述相應節點的
節點信息。
為了實現上述目的，本發明實施例提供一種節點信息的發送裝置，該裝
置包括節點建立消息獲取單元，用于從設備管理服務器接收節點建立消息； 節點建立單元，用于根據所述節點建立消息在終端設備管理樹中建立相應的
節點；節點信息發送單元，用于向所述設備管理服務器發送所述相應節點的節點信息。
上述技術方案的有益效果在于，可以簡便的使設備管理中的服務器端與 終端方便的節點信息保持對稱，方便后續的管理操作。


此處所說明的附圖用來提供對本發明的進一步理解，構成本申請的一部 分，并不構成對本發明的限定。在附圖中-
圖1為開放移動聯盟設備管理規范的整體結構圖2為現有終端設備內管理樹中各管理對象的結構狀態示意圖3為本發明實施例提供的節點信息的發送方法的流程圖4為本發明另一實施例提供的節點信息的發送方法的流程圖5為本發明另一實施例提供的節點信息的發送方法的流程圖6為本發明又一實施例節點信息的發送方法的流程圖7為本發明實施例提供的節點信息的發送裝置的結構圖。
具體實施例方式
為使本發明的目的、技術方案和優點更加清楚明白，下面結合實施方式 和附圖，對本發明做進一步詳細說明。在此，本發明的示意性實施方式及其
說明用于解釋本發明，但并不作為對本發明的限定。
如圖3所示，為本發明實施例提供的基于終端設備的節點信息對稱方法 的流程圖，該方法包括
步驟301，從設備管理服務器接收節點建立消息；無論是在Bootstrap階 段還是在管理階段，終端上的節點一般是由服務器創建的，而創建過程中可 能產生一些新的節點信息，這時，終端即時向服務器反饋這些信息就省去了 服務器后續再向終端查詢的麻煩。其中，在Bootstrap階段，根據現有技術， 服務器先對終端進行Bootstrap,此時服務器向終端發送的消息可以是CP消息或DM消息。在管理階段，服務器直接向終端發送節點建立指令。
步驟302，根據所述節點建立消息在終端設備管理樹中建立相應的節點；
(尤其是DMAcc管理對象相關節點)；
步驟303，向所述設備管理服務器發送所述相應節點的節點信息，在 Bootstrap階段，終端發起會話告知服務器節點創建后的相關信息，在管理階 段，終端通過同步回復或異步回復的方式告知服務器節點創建后的相關信息。
上述實施例的有益效果在于，可以簡便的使設備管理中的服務器端與終 端方便的節點信息保持對稱，方便后續的管理操作。
實施例一
在Bootstrap階段，服務器發送CP消息，具體如下
<wap-provisioningdoc version-" 1.0">
characteristic type="APPLICATION"> <parm name="APPID" value="w77> <!-APPID表示本消息是針對終端上的DM應用的--〉 <parm name-"PROVIDER-ID" value="com.mgmtsrv.manage'7> <!-- PROVIDER-ID表示DM服務器標識-->
</characteristic> </wap-provisioningdoc〉
服務器發送CP消息的情況下，根據現有技術的描述，終端會把CP消息 中的相關參數值映射到管理樹上，例如把APPID、 PROVIDER-ID等參數值映 射到一個新生成的DMAcc管理對象的AppID和ServerID節點中去。此時終 端則會對這個DMAcc管理對象的根節點迸行命名，這樣便生成了一項服務器 未知的節點信息。
為了使服務器即時了解所述未知的節點信息，終端可以在Bootstrap之后 發起的會話中告知服務器這些信息。下面是一個例子 〈SyncML xmlns='SYNCML:SYNCML 1.2'〉<SyncHdr>... </SyncHdr> <SyncBody> <AIert>
<CmdID>l</CmdID〉
<Data>1224</Data><!—客戶端事件—>
<Item>
<Source>
<LocURI>./DMServer/Server 1 /ServerlD </LocURI> <!-LocURI中為終端反饋的節點路徑--〉 </Source>
<Data> com.mgmtsrv.manage </Data> <!-Data中為終端反饋的節點值-> </Item〉 </Alert> <Final/> </SyncBody> </SyncML>
該會話消息中，終端通過Alert命令來告知服務器Bootstrap之后的一些 服務器未知的節點信息，其中在Item/Source/LocURI中攜帶了一個節點URI， 即./DMServer/Serverl/ServerlD ，又在Item/Data中攜帶了節點值，即 com.mgmtsrv.manage,通過這兩個信息，服務器就可以知道CP消息中與 com.mgmtsrv.manage相關的帳號參數被映射到了 Serverl這個管理對象實例 中，這是一個DMAcc管理對象實例，這個實例的URI為./DMServer/Serverl， 這樣就使服務器知道了 Bootstrap消息中相關參數映射的位置，方便了服務器 后續對這些參數的管理。
其中，假設服務器能夠知道該終端DMAcc管理對象的父節點URI，例如 通過DDF獲知，則終端發送的節點信息中可以只包括管理對象實例的名稱，例如上面這個例子中，終端只發送Serverl和服務器標識com.mgmtsrv.manage
這兩個信息即可。
而假設Bootstrap消息中僅包含了一個服務器的相關參數，例如只包含 com.mgmtsrv.manage的相關帳號參數，則終端可以改為發 送./DMServer/Serverl禾卩urn:oma:mo:oma-dm-dmacc:l.O這兩個f言息,其中后者 是DMAcc管理對象的MOI，這樣服務器也可以知道與com.mgmtsrv.manage 相關的帳號參數被映射到了 Served這個管理對象實例上。同樣在服務器知道 終端DMAcc管理對象父節點URI的條件下，終端只發送Served和 urn:oma:mo:oma-dm-dmacc: 1.0這兩個信息艮卩可。
如圖4所示，終端判斷服務器發送的節點建立消息中沒有包含節點的名 稱，則終端自行對節點進行命名后通過發送特征節點信息告知該節點在設備 管理樹中的名稱，如在上述實施例中，服務器發送的節點建立消息和終端反 饋的節點信息均包含特征節點信息"com.mgmtsrv.manage",并且終端反饋的 節點信息中還包括建立的節點的名稱，這樣服務器就通過特征節點信息 "com.mgmtsrv.manage "得知了建立的節點在終端設備管理樹中的名稱為 Server 1 。
其中，如果節點建立消息中只有一個管理對象實例，則終端也可以通過 管理對象標識MOI告知建立的節點在設備管理樹中的名稱，因為每個管理對 象擁有自己的管理對象標識(MOI)，用以唯一的標識一個管理對象，所以服 務器也可以通過該MOI獲取建立的節點在終端設備管理樹中的名稱。
艮P，所述的節點建立消息和節點信息中包含特征節點信息或管理對象標 識，該特征節點信息或管理對象標識用于標識所述相應節點，這時終端判斷 所述的節點建立消息如果沒有包含節點的名稱，則所述發送所述相應節點的 節點信息包括發送所述相應節點的節點名稱。
實施例二
若服務器先對終端發送DM消息進行Bootstrap,按現有技術描述，這個步驟中DM消息具體如下
〈SyncML xmlns='SYNCML:SYNCML1.2'〉 〈SyncHdr〉……〈/SyncHdr〉 <SyncBody> <Add>
<CmdID〉0</CmdID> <Item>
<Target><LocURI>./Inbox</LocURI〉</Target> <!— Target表示在Inbox中添加節點-->
<Data>
<MgmtTr6s>
<VerDTD〉 1.2</VerDTD> <Node>
<NodeName>ServerX</NodeName> <!-上面是DMAcc管理對象名稱-> <RTProperties〉
<TypexDDFName> urn:oma:mo:oma-dm-dmacc: 1 .CX/DDFNamex/Type〉
<!-上面是DMAcc管理對象標識--> </RTProperties> <Node>
<NodeName>AppID</NodeName>
</Nod6> <Node>
<NodeName>ServerID</NodeName> 〈Value〉 com.mgmtsrv.manage </Value><!— ServerID的值為com.mgmtsrv.manage —> </Node>
</Node> </MgmtTree> </Data> </Item> </Add> <Final/> </SyncBody> </SyncML>
(注在DM消息的例子中為了明晰消息的含義，采用了xml格式，在 實際的Bootstrap消息中應采用wbxml格式，另外例子中省略了一些無關的部 分。)
服務器發送基于DM的Bootstrap消息后，根據現有技術的描述，終端可 以對管理對象進行重新命名，例如對上述例子中DMAcc管理對象名稱 ServerX進行重新命名，重命名為Serverl。或者，在Bootstrap消息中服務器 就沒有指定管理對象根節點的名稱，這時終端可以自行指定。這兩種情況下， 都相當于終端生成了一項服務器未知的節點信息。
Bootstrap之后終端可以使用與實施例一相同的方法告知服務器未知的節 點信息。終端還可以使用Generic Alert (通用警告)的方法來達到同樣的目的。
下面是一個例子
〈SyncML xmlns='SYNCML:SYNCMLl .2，> <SyncHdr>…</SyncHdr> <SyncBody> <Alert〉
<CmdID〉l</CmdID> <Data>1226</Data> <!—通用警告—><Item>
<Sourcs>
<LocURI>./DMServer/Server 1/ServerlD </LocURI> ^-LocURI中為終端反饋的節點路徑—>
</Sourc6>
<Meta>
<Type xmlns="syncml:metinf'> Re versed-Domain-Name: org. openmobilealliance .BootstrapComplete. dmacc </Type>
〈!-Type中的信息標識了下面Data元素攜帶的數據類型--> <Format xmlns="syncml:metinf'>chr</Format> <Markxmlns="syncml:metinf，>critical</Mark> </Meta>
<Data> com.mgmtsrv.manage <7Data〉 〈!-Data中為終端反饋的節點值-> </Item> </Alert> <Final/> </SyncBody〉 </SyncML>
從上面的通用警告中，服務器同樣了解到了./DMServer/Server 1 /ServerlD 和com.mgmtsrv.manage這兩個信息，通過這兩個信息，服務器就可以知道 Bootstrap消息中與com.mgmtsrv.manage這個ServerlD相關的管理對象根節點 名稱ServerX被重命名為Served,它的URI為./DMServer/Server 1 ，這樣就使 服務器知道了 SeiverX管理對象實例的位置，方便了服務器后續對它的管理。
在通用警告中還有一個Item/Type元素，它指明了 Data元素攜帶的數據 類型，本例中具體為
14Reversed-Domain畫Name: org.openmobilealliance.BootstrapComplete .dmacc
這表示該通用警告攜帶的是在Bootstrap完成后由DMAcc管理對象發出
的節點信息數據。
假設服務器能夠知道該終端DMAcc管理對象的父節點URL例如通過 DDF獲知，則終端發送的節點信息中可'以只包括管理對象實例的名稱，例如 上面這個例子中，終端只發送Serverl和服務器標識com.mgmtsrv.manage這 兩個信息即可。
而假設Bootstrap消息中僅包含了一個服務器的相關參數，例如只包含 ServerX的相關帳號參數，則終端可以改為發送./DMServer/Serverl和 um:oma:mo:oma-dm-dmacc:l.O這兩個信息，其中后者是DMAcc管理對象的 MOI，這樣服務器也可以知道ServerX被更名為Serverl 。同樣在服務器知道 終端DMAcc管理對象父節點URI的條件下，終端只發送Serverl和 urn:oma:mo:oma-dm-dmacc: 1.0這兩個信息艮卩可。
從上述可知，如圖5所示，本發明實施例提供的方法包括從設備管理 服務器接收節點建立消息；根據所述節點建立消息在終端設備管理樹中建立 相應節點；其中，終端在設備管理樹中建立節點時改變節點的名稱，并通過 發送特征節點信息ServerID或管理對象標識MOI告知建立的節點在設備管理 樹中的名稱，如在上述實施例中，服務器發送的節點建立消息和終端反饋的 節點信息均包含特征節點信息"com.mgmtsrv.manage"，并且終端反饋的節點 信息中還包括建立的節點的名稱，這樣服務器就通過特征節點信息 "com.mgmtsrv.manage"得知了建立的節點在終端設備管理樹中的名稱。
其中，如果節點建立消息中只有一個管理對象實例，則終端也可以通過 管理對象標識MOI告知建立的節點在設備管理樹中的名稱，因為每個管理對 象擁有自己的管理對象標識(MOI)，用以唯一的標識一個管理對象，所以服 務器也可以通過該MOI獲取建立的節點在終端設備管理樹中的名稱。
實施例三在實施例二的場景下，還有一種方法可以實現告知服務器未知節點信息 的功能，前序步驟與實施例二相同，在終端向服務器反饋節點信息時采用下 面的消息
〈SyncML xmlns='SYNCML:SYNCML1.2，> <SyncHdr>…〈/SyncHdr〉 <SyncBody> <Alert>
<CmdID〉 1 </CmdID>
<Data〉... </Data><!—某種類型的警告—〉 <Item>
<Source>
<LocURI>./DMServer/Serverl </LocURI> <!-LocURI中為終端反饋的節點路徑--> </Source>
<Data>./Inbox/ServerX </Data〉 <!-Data中為服務原先指定的節點路徑-> </Item> </Alert〉 <Final/> </SyncBody〉 </SyncML>
采用該消息，服務器可以得知原來指定的路徑(包括節點名稱)./ Inbox/ServerX在經過終端處理后變成了./DMServer/Serverl 。
從上述可知，本發明實施例提供的方法包括從設備管理服務器接收節
點建立消息；根據所述節點建立消息在終端設備管理樹中建立相應節點；其 中，終端在設備管理樹中建立節點時改變節點的名稱，然后發送節點建立后 在所述終端設備管理樹中的節點信息和該節點在節點建立消息中的名稱至所述的設備管理服務器，所述節點信息包含該節點在終端設備管理樹中的名稱。 終端通過這樣的方法也可將建立消息中的節點名稱和終端設備管理樹中的節 點名稱相對應。 實施例四
終端在處理Bootstrap消息時，還有可能對一些節點值進行改變，例如終 端處理如下的Bootstrap消息
〈SyncML xmlns='SYNCML:SYNCMLl .2'> <SyncHdr>……</SyncHdr〉 <SyncBody> <Add>
<CmdID〉0</CmdID> <Item>
<Target><LocURI>./Inbox</LocURI></Target〉 <!-- Target表示在Inbox中添加節點-->
<Data>
<MgmtTr66>
〈VerDTD〉 1.2</VerDTD〉 <Node>
<NodeName>ServerX</NodeName> <!-上面是DMAcc管理對象名稱--> <RTProperties>
<TypexDDFName> urn:oma:mo:oma"dm"dmacc: 1.0<7DDFNamexyType>
<!--上面是DMAcc管理對象標識-〉 </RTProperties>
<Node>
<NodeName>PrefConRef</NodeName><RTProperties> ... </RTProperties> <Value〉./Inbox/Internet</Value>
<!— Value中是連接參考PrefConRef的值—>
</Node>
<NodeName>Internet</NodeName> <!-連接管理對象-> <RTProperties> ... </RTProperties>
</Node> </MgmtTree〉 </Data> </Item> </Add> <Final/> </SyncBody> </SyncML>
消息表明在ServerX節點下有一個子節點PrefConRef，它的值 為./Inbox/Intemet，這個值指向消息中另一個管理對象的地址，即Internet連接 管理對象。終端收到這個Bootstrap消息后首先會把Internet連接管理對象存 放在管理樹相應的位置上，例如./Connectivity路徑下，然后終端再對 PrefConRef的值進行更改，把./Inbox替換為./Connectivity,若終端再重命名了 Internet連接管理對象為Intemet234 ，則此時PrefConRef的值則更改 為./Connectivity/Intemet234。這相當于生成了一項服務器未知的節點信息。終 端通過一條DM會話消息告知服務器，例如
〈SyncML xmlns='SYNCML:SYNCMLl .2'> <SyncHdr>... </SyncHdr> <SyncBody><Alert>
<CmdID>l</CmdID> <Data>1224</Data><!—客戶端事件--> <Item>
<Source>
<LocURI>./DMServer/Server 1/PrefConRef </LocURI> 〈!-LocURI中為終端反饋的節點路徑--〉 </Source〉
<Data> ./Connectivity/Internet234 </Data> 〈!-Data中為終端反饋的節點值--〉 </Item> </Alert> <Final/> </SyncBody> </SyncML>
這類似實施例一的發送方法，服務器收到消息后知道某個節點值被終端 做了變更，從上述可知，如圖6所示，本發明實施例提供的方法包括從設 備管理服務器接收節點建立消息；根據所述節點建立消息在終端設備管理樹 中建立相應節點，其中，終端在設備管理樹中建立節點時改變節點的節點值; 終端發送的節點信息包含該節點建立后在所述終端設備管理樹中的節點值。
實施例五
在Bootstrap階段和管理階段，服務器都可以在終端上創建一些除管理對
象根節點以外的其它節點，這些節點的名稱也可能被終端進行命名或更名，
終端在將節點更名后，通過發送該節點在建立消息中的節點URI和在設備管
理樹中的節點URI使服務器獲知該節點的信息，例如服務器發送以下消息 〈SyncML xmlns='SYNCML:SYNCML1.2'> <SyncHdr>……</SyncHdr>
19<SyncBody> Add>
<CmdID>0</CmdID> <Item>
<Targ€
<!— Target表示在./DMServer/Serverl/AppAuth中添力卩節點—>
<Data>
<MgmtTr6e>
<VerDTD> 1.2</VerDTD> <Node>
<NodeName>AppAuthX </NodeName> <!-上面AppAuthX為服務器指定的節點名稱 <RTProperties> ... </RTProperties> <Node>
<NodeName> AAuthLevel</NodeName> <!—AAuthLevel是一個子節點--〉 <RTProperties> ... </RTProperties> <Value>CLCRED</Value>
</Node>
>
</Node> </MgmtTree> </Data> </Item> </Add> <Final/> </SyncBody> </SyncML>終端收到消息后發現AAuthLevel的上一層節點名稱為AppAuthX，之后 終端希望對其重新命名，例如命名為AppAuth345。之后終端在回復消息中反
饋這個信息，如
〈SyncML xmlns='SYNCML:SYNCMLl，2'〉 〈SyncHdr〉…</SyncHdr> <SyncBody> <Status>
<CmdReP>0</CmdRef> <Cmd>Add</Cmd〉
<SourceRef>./DMServer/Serverl/AppAuth/AppAuthX </SourceRef>
<!--服務器下發的URI--> <Data>200</Data> <Item> <Source>
<!--終回復端的URI-->
</Source> </Item> </Status>
</SyncBody> </SyncML>
其中，在反饋消息中終端給出了服務器下發的節點URI，并給出了終端 重命名后的節點URI，它們分別為yDMServer/Serverl/AppAuth/AppAuthX 和./DMServer/Serverl/AppAuth/AppAuth345。終端也可以僅反饋節點名稱信 息，即AppAuthX和AppAuth345。即，終端發送節點建立后在所述終端設備 管理樹中的節點信息和該節點在節點建立消息中的名稱至所述的設備管理服務器，所述節點信息包含該節點在終端設備管理樹中的名稱。
其中，如果服務器下發的消息中某個節點的名稱為空，則終端反饋時可 以給出其子節點URI和其節點值，如
〈SyncML xmlns='SYNCML:SYNCML1.2，> <SyncHdr>... </SyncHdr> <SyncBody> <Status>
<CmdRef^O</CmdRef> <Cmd>Add</Cmd>
〈SourceRefX/DMServer/Serverl/AppAuth </SourceRef>
<Data〉200</Data>
<Item>
<Source>
<LocURI>./DMServer/Server 1 /AppAuth/AppAuth345/ AAuthLevel </LocURI>
<!--終回復端的某子節點URI-》
</Source>
<Data> CLCRED</Data>
<!--終回復端的節點值-->
</Item> </Status〉
</SyncBody〉 </SyncML>
通過這種方式，服務器也能了解到終端反饋的AppAuth345對應的是哪一 個實例。
本例中給出的是使用Status進行同步回復的例子，同樣在終端處理時間過長的情況下也可以使用通用警告異步回復的方法，反饋的內容與上面是類 似的。
相應于本發明上述提出的保持DM樹節點信息對稱的方法，本發明還提 出了一種對應的終端設備，如圖7所示，為本發明終端設備的主要組成結構 框圖，其主要包括
節點建立消息獲取單元701，用于從設備管理服務器接收節點建立消息； 節點建立單元702，用于根據所述節點建立消息在終端設備管理樹中建立 相應的節點；
節點信息發送單元703，用于向所述設備管理服務器發送所述相應節點的 節點信息。
上述實施例的有益效果在于，可以簡便的使設備管理中的服務器端與終 端方便的節點信息保持對稱，方便后續的管理操作。
在本發明另一實施例中，所述節點建立消息獲取單元，還用于獲取所述 節點建立消息中的特征節點信息或管理對象標識；該特征節點信息或管理對 象標識用于標識所述相應節點；所述節點信息發送單元還包括第一子單元， 所述第一子單元用于發送所述特征節點信息或管理對象標識。
在本發明另一實施例中，所述裝置還包括節點名稱發送控制單元，用 于判斷所述的節點建立消息是否包含節點的名稱，如果否，則觸發節點信息 發送單元；所述節點信息發送單元還包括第二子單元，所述第二子單元用于 根據所述節點名稱發送控制單元的觸發，向所述設備管理服務器發送所述相 應節點的節點名稱。
在本發明另一實施例中，所述的裝置還包括節點值改變單元，用于在 終端設備管理樹中建立相應節點時，改變所述相應節點的節點值；所述節點 信息發送單元還包括第三子單元，所述第三子單元用于向所述設備管理服務 器發送所述相應節點改變后的節點值。
在本發明另一實施例中，所述的裝置還包括節點名稱改變單元，用于在終端設備管理樹中建立相應節點時，改變所述相應節點的名稱；所述節點 信息發送單元還包括第四子單元，所述第四子單元用于向所述設備管理服務 器發送所述相應節點改變后的名稱。
在本發明另一實施例中，所述裝置還包括，節點名稱改變單元，用于在
終端設備管理樹中建立相應節點時，改變所述相應節點的名稱；所述節點信
息發送單元還包括第五子單元，所述第五子單元用于向所述設備管理服務器 發送所述相應節點改變后的名稱和該節點在節點建立消息中的節點名稱。
在本發明上述實施例中，所述的節點建立消息是指客戶端配置消息或 設備管理消息。所述的節點建立后在所述終端設備管理樹中的節點信息是通 過客戶端事件、通用警告或狀態命令發送的。
以上所述的具體實施方式
，對本發明的目的、技術方案和有益效果進行 了進一步詳細說明，所應理解的是，以上所述僅為本發明的具體實施方式
而 已，并不用于限定本發明的保護范圍，凡在本發明的精神和原則之內，所做 的任何修改、等同替換、改進等，均應包含在本發明的保護范圍之內。
2權利要求
1、一種節點信息的發送方法，其特征在于，所述方法包括從設備管理服務器接收節點建立消息；根據所述節點建立消息在終端設備管理樹中建立相應節點；向所述設備管理服務器發送所述相應節點的節點信息。
2、 根據權利要求1所述的方法，其特征在于，所述的節點建立消息和節 點信息中包含特征節點信息或管理對象標識，該特征節點信息或管理對象標 識用于標識所述相應節點。
3、 根據權利要求2所述的方法，其特征在于，所述方法還包括判斷所 述的節點建立消息是否包含節點的名稱，如果否，所述發送所述相應節點的節點信息包括發送所述相應節點的節點名稱。
4、 根據權利要求2所述的方法，其特征在于，所述方法還包括在終端 設備管理樹中建立相應節點時，改變所述相應節點的節點值；所述發送所述相應節點的節點信息包括發送所述相應節點改變后的節 點值。
5、 根據權利要求2所述的方法，其特征在于，所述的方法還包括在終 端設備管理樹中建立相應節點時，改變所述相應節點的名稱；所述發送所述相應節點的節點信息包括發送所述相應節點改變后的名稱。
6、 根據權利要求1所述的方法，其特征在于，所述的方法還包括在終端設備管理樹中建立相應節點時，改變所述相應節點的名稱；所述發送所述相應節點的節點信息包括發送所述相應節點改變后的名 稱和該節點在節點建立消息中的節點名稱。
7、 根據權利要求1至6任一項所述的方法，其特征在于，所述的節點建立消息是指客戶端配置消息或設備管理消息。
8、 根據權利要求1至6任一項所述的方法，其特征在于，所述的節點信 息是通過客戶端事件、通用警告或狀態命令發送的。
9、 一種節點信息的發送裝置，其特征在于，該裝置包括節點建立消息獲取單元，用于從設備管理服務器接收節點建立消息； 節點建立單元，用于根據所述節點建立消息在終端設備管理樹中建立相 應的節點；節點信息發送單元，用于向所述設備管理服務器發送所述相應節點的節 點信息。
10、 如權利要求9所述的裝置，其特征在于，所述節點建立消息獲取單 元，還用于獲取所述節點建立消息中的特征節點信息或管理對象標識；該特 征節點信息或管理對象標識用于標識所述相應節點；所述節點信息發送單元還包括第一子單元，所述第一子單元用于發送所 述特征節點信息或管理對象標識。
11、 根據權利要求10所述的裝置，其特征在于，所述裝置還包括 節點名稱發送控制單元，用于判斷所述的節點建立消息是否包含節點的名稱，如果否，則觸發節點信息發送單元；所述節點信息發送單元還包括第二子單元，所述第二子單元用于根據所 述節點名稱發送控制單元的觸發，向所述設備管理服務器發送所述相應節點 的節點名稱。
12、 根據權利要求10所述的裝置，其特征在于，所述的裝置還包括節 點值改變單元，用于在終端設備管理樹中建立相應節點時，改變所述相應節 點的節點值；所述節點信息發送單元還包括第三子單元，所述第三子單元用于向所述 設備管理服務器發送所述相應節點改變后的節點值。
13、 根據權利要求10所述的裝置，其特征在于，所述的裝置還包括節 點名稱改變單元，用于在終端設備管理樹中建立相應節點時，改變所述相應節點的名稱；所述節點信息發送單元還包括第四子單元，所述第四子單元用于向所述 設備管理服務器發送所述相應節點改變后的名稱。
14、根據權利要求9所述的裝置，其特征在于，所述裝置還包括，節點 名稱改變單元，用于在終端設備管理樹中建立相應節點時，改變所述相應節 點的名稱；所述節點信息發送單元還包括第五子單元，所述第五子單元用于向所述 設備管理服務器發送所述相應節點改變后的名稱和該節點在節點建立消息中 的節點名稱。
全文摘要
本發明實施例提供一種節點信息的發送方法和裝置，所述方法包括從設備管理服務器接收節點建立消息；根據所述節點建立消息在終端設備管理樹中建立相應節點；向所述設備管理服務器發送所述相應節點的節點信息。本發明可以簡便的使設備管理中的服務器端與終端方便的節點信息保持對稱，方便后續的管理操作。
文檔編號H04W68/00GK101442791SQ200810241159
公開日2009年5月27日 申請日期2008年12月26日 優先權日2008年12月26日
發明者劉海濤, 悅 宋, 睿 王 申請人:深圳華為通信技術有限公司