專利名稱：采用snmp協議的通信系統和消息交互方法
技術領域：
本發(fā)明涉及通信領域，尤其涉及采用SNMP協議的通信系統和消息交互方法。
背景技術：
簡單網絡管理協議SNMP是專門設計用于在網絡中管理網絡節(jié)點(服務器，工作站，路由器，交換機等)的一種標準協議，它是一種應用層協議。SNMP使得網絡管理員可以管理網絡效能，發(fā)現并解決網絡中的問題(通過SNMP接收設備上報的Trap或者INFORM報文)以及規(guī)劃網絡的增長。
SNMP管理的網絡有三個主要的組成部分被管理的設備，代理(Agent)和網絡管理系統(NMS)。被管理設備是一個網絡節(jié)點(服務器，工作站，路由器，交換機等)，包含SNMP代理并處在管理網絡之中，它主要是收集并存儲管理信息。通過SNMP，網絡管理系統NMS能得到這些信息。代理(Agent)是被管理設備上的一個網絡管理軟件模塊。SNMP代理擁有本地的相關管理信息，并把它們轉換成與SNMP相兼容的格式。
SNMP V1定義了5種報文
Get-Request操作管理進程從代理進程中提取一個或多個參數的值。
Get-Next-Request操作管理進程從代理進程中提取一個或多個參數的下一個參數的值。
Set-Request操作管理進程設置代理進程的一個或多個參數值。
Get-Response操作代理進程返回的一個或多個參數值，它是前面3種操作的響應操作。
Trap操作代理進程主動發(fā)出的報文，通知管理進程有事情發(fā)生(在V2中重定義為SNMP V2-Trap)。
SNMP V2中增加了2種報文Get-Bulk-Request操作管理進程從代理進程中提取一個或多個參數后面多個參數的值。
Inform-Request操作實際上是有應答的SNMP V2-Trap(陷阱)。
下面介紹SNMP封裝成UDP數據報的操作的報文格式(以SNMPV2為參考)，如圖1，一個SNMP報文由一個版本標識符(versionidentifier)，一個SNMP共同體標識符(community name)和一個數據字段(PDU)組成。版本標識符用于區(qū)分SNMP版本，0為SNMPV1，1為SNMP V2。共同體表示符實際上是管理進程和代理進程使用的字符串口令。PDU則是經過編碼的數據字段。
SNMP V2基本的PDU格式如圖2，SNMPv1的GetRequest、GetNextRequest、GetResponse和SetRequest具有和V2相同的格式，只是SNMPv1的Trap和它們有不同的格式，SNMPv1的Trap與SNMPv2的SNMPv2-Trap格式也不同。PDU類型字段用來區(qū)分具體的操作類型，請求標識符(Request-ID)是一個32位的整數。在一個Response-PDU中的Request-ID值取它所回應的那個請求PDU的Request-ID值。錯誤狀態(tài)(Error Status)和錯誤索引(Error Index)在一個響應報文Response-PDU中，非零的錯誤狀態(tài)(Error Status)值表示發(fā)生了額外的事件使得不能完成請求的操作。這時，錯誤索引(Error Index)的非零值表示了引起這個額外事件的變量綁定表中的那個變量綁定的信息。變量綁定表中包含許多個變量綁定{name，value}，代表操作的變量。
管理站和被管設備之間需要遵循統一的接口，這樣管理站才知道被管設備上可以被使用的數據，這樣的接口是用MIB文件定義的。MIB指的是管理信息庫，具體是指代理進程包含的，并且能夠被管理進程查詢和設置的進程的集合。接口的定義方法是用統一的語法(管理信息結構SMI)，將信息描述到文件(MIB文件)，管理服務器和代理器照規(guī)定的語法對文件進行解析，從而獲取信息。
SNMP協議中操作基本上都是由網絡管理系統發(fā)起，代理端被動的接受網絡管理系統發(fā)起的GET和SET等操作，代理端只有通過Trap(陷阱)或者INFORM(通知)才能夠通知自身有一些重大事件發(fā)生。首先，這是一個很簡單的交互模型，在較為復雜的消息交互的應用場景下不適用。比如，網絡管理系統希望通過自己給定的參數，而從代理端獲得想要的數據，通過GET操作不行，因為無法去設置參數，改變一下策略，在GET操作之前先把所需要的參數SET給代理端，結果也是不可行的，因為網絡管理系統不知道什么時候代理端能把所需要的數據準備好，只有數據準備好了才能夠通過GET操作去獲取，第三個策略可以讓代理端準備好數據，在用Trap或者INFORM通知網絡管理系統來GET，或者直接將變量綁定在Trap或者是INFORM的綁定列表中上傳，第三個策略是可行的，但是如果這樣的操作是比較麻煩的。其次，現有的交互模型中，網絡管理系統得壓力比較大，因為很多代理端的數據都要靠網絡管理系統去輪詢。
如果可以在SNMP的協議的基礎上實現消息交互，上述問題就迎刃而解了。
發(fā)明內容
針對以上一個或多個問題，本發(fā)明提供了采用SNMP協議的通信系統以及消息交互方法，解決了目前SNMP交互模型較為簡單的問題，并且只通過一個變量的設置就可以讓網絡管理系統和代理端做出多種響應，實現了普通系統中的消息交互機制。
根據本發(fā)明的采用SNMP協議的通信系統包括SNMP管理站，用于與至少一個被管設備預先定義接口，并根據接口解析來自至少一個被管設備的消息并進行相應操作；SNMP代理，用于轉發(fā)來自SNMP管理站或至少一個被管設備的消息；以及至少一個被管設備，用于根據預先定義的接口解析來自SNMP管理站的消息并進行相應操作。
其中，SNMP管理站發(fā)送至至少一個被管設備的消息通過設置請求數據字段SET-REQUEST PDU承載，并將設置請求數據字段中的變量綁定列表中的最后一個變量綁定為消息號。
消息號被設置為SNMP代理在接收設置請求數據字段時按照變量綁定列表的次序設置變量的值。
至少一個被管設備發(fā)送至SNMP管理站的消息通過SNMP v2Trap或Inform數據字段承載，并將其變量綁定列表中的第二個變量綁定為用于標識SNMP v2 Trap(陷阱)或Inform(通知)數據字段承載的是消息的信息，并將變量綁定列表中的最后一個變量綁定為消息號。
根據部本發(fā)明的采用SNMP協議的消息交互方法包括以下步驟步驟S502，SNMP管理站和至少一個被管設備之間定義接口及其消息號和變量；步驟S504，SNMP管理站通過至少一個SNMP代理向至少一個被管設備發(fā)送消息，將消息的消息體按照約定的次序綁定在數據字段綁定列表中，并將數據字段的綁定列表中的最后一個變量綁定為消息號；以及步驟S506，被管設備根據消息號進行處理，并從變量綁定列表中按照約定的次序取出消息體。
SNMP管理站發(fā)送至至少一個被管設備的消息通過設置請求數據字段SET-REQUEST PDU承載。
根據本發(fā)明的采用SNMP協議的消息交互方法包括以下步驟步驟S512，SNMP管理站和至少一個被管設備之間定義接口及其消息號和變量；步驟S514，被管設備通過至少一個SNMP代理向SNMP管理站發(fā)送消息，將消息的消息體按照約定的次序綁定在數據字段綁定列表中，并將數據字段的綁定列表中的最后一個變量綁定為消息號；以及步驟S516，SNMP管理站根據消息號進行處理，并從變量綁定列表中按照約定的次序取出消息體。
至少一個被管設備發(fā)送至SNMP管理站的消息通過SNMP v2Trap或Inform數據字段承載，并將其變量綁定列表中的第二個變量綁定為用于標識SNMP v2Trap或Inform數據字段承載的是消息的信息，并將變量綁定列表中的最后一個變量綁定為消息號。
本發(fā)明解決了目前SNMP交互模型較為簡單的問題，并且只通過一個變量的設置就可以讓網絡管理系統和代理端做出多種響應，實現了普通系統中的消息交互機制。有了消息交互，有效減少了網絡管理系統的負擔，很多輪詢的操作，都可以用代理端的主動上報來替代，也有效較少了網絡流量。擴展了SNMP協議的應用場景，可以方便的應用到有網絡管理但又有消息交互的環(huán)境中。
此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構成對本發(fā)明的不當限定。在附圖中圖1是SNMP報文格式的示意圖；圖2是SNMP V2基本PDU格式的示意圖；圖3是根據本發(fā)明的管理站與被管設備之間接口示例的示意圖；
圖4是根據本發(fā)明的采用SNMP協議的通信系統的框圖；圖5A和圖5B是根據本發(fā)明的采用SNMP的消息交互方法的流程圖；圖6是根據本發(fā)明的被管理設備接受管理站消息的流程圖；以及圖7是根據本發(fā)明的管理站接受被管理設備消息的流程圖。
具體實施例方式
下面參考附圖，詳細說明本發(fā)明的具體實施方式
。
本發(fā)明的目的就是解決現有SNMP交互模型功能比較有限的問題，以現有的技術在SNMP協議中實現消息交互的功能。
圖4是根據本發(fā)明的采用SNMP協議的通信系統的框圖。如圖4所示，根據本發(fā)明的采用SNMP協議的通信系統包括SNMP管理站402，用于與至少一個被管設備預先定義接口，并根據接口解析來自至少一個被管設備的消息并進行相應操作；SNMP代理404，用于轉發(fā)來自SNMP管理站或至少一個被管設備的消息；以及至少一個被管設備406，用于根據預先定義的接口解析來自SNMP管理站的消息并進行相應操作。
SNMP管理站可以發(fā)消息到SNMP代理，再由代理到被管設備，被管設備根據SNMP管理站與被管設備預先定義的接口解析消息，再執(zhí)行相應的操作，被管設備也可以通過SNMP代理發(fā)消息給SNMP管理站，SNMP管理站也可以通過其與被管設備預先定義的接口來解析消息，并且執(zhí)行相應的動作。
SNMP管理站到被管設備的消息由Set-Request PDU所承載，其變量綁定列表中的最后一個變量綁定為消息號，應為SNMP代理在接受Set-Request PDU時是按照其變量綁定列表的次序一個一個的設置變量的值，這樣當被管設備收到消息號時，整個消息體已經完全被收下，則此時可以根據消息號進行相應處理。
在上述SNMP通信系統中，被管設備到SNMP管理站的消息由SNMP v2 Trap或者Inform PDU所承載，其變量綁定列表中的第二個變量綁定為自定義的用來標識此SNMP v2 Trap或者Inform PDU所承載的是消息而不是陷阱的trap OID，其變量綁定列表中的最后一個變量綁定為消息號(此處不是必需，僅為了和SNMP管理站到被管設備的消息統一)，當整個PDU被管理站接受下來之后，管理站會去查其變量綁定列表中的第二個變量綁定的值來確定該PDU是普通的Trap或INFORM還是一條消息，是消息則從變量綁定列表中的最后一個變量中取出消息號，然后根據消息號進行相應處理。
圖5A和圖5B是根據本發(fā)明的采用SNMP的消息交互方法的流程圖。
圖5A是從SNMP管理站到至少一個被管設備的消息交互方法包括以下步驟步驟S502，SNMP管理站和至少一個被管設備之間定義接口及其消息號和變量；步驟S504，SNMP管理站通過至少一個SNMP代理向至少一個被管設備發(fā)送消息，將消息的消息體按照約定的次序綁定在數據字段綁定列表中，并將數據字段的綁定列表中的最后一個變量綁定為消息號；以及步驟S506，被管設備根據消息號進行處理，并從變量綁定列表中按照約定的次序取出消息體。
SNMP管理站發(fā)送至至少一個被管設備的消息通過設置請求數據字段SET-REQUEST PDU承載。
如圖5B所示，至少一個被管設備到SNMP管理站的消息交互方法包括以下步驟步驟S512，SNMP管理站和至少一個被管設備之間定義接口及其消息號和變量；步驟S514，被管設備通過至少一個SNMP代理向SNMP管理站發(fā)送消息，將消息的消息體按照約定的次序綁定在數據字段綁定列表中，并將數據字段的綁定列表中的最后一個變量綁定為消息號；以及步驟S516，SNMP管理站根據消息號進行處理，并從變量綁定列表中按照約定的次序取出消息體。
至少一個被管設備發(fā)送至SNMP管理站的消息通過SNMP v2Trap或Inform數據字段承載，并將其變量綁定列表中的第二個變量綁定為用于標識SNMP v2 Trap或Inform數據字段承載的是消息的信息，并將變量綁定列表中的最后一個變量綁定為消息號。
本方法提出的消息交互方法具體包含以下主要步驟步驟一，定義管理站和被管設備之間的接口(MIB文件)。
a，在Mib文件中定義消息號葉子節(jié)點，消息號的值用一個無符號整數表示，該葉子節(jié)點的OID就是消息號的OID。
b，定義出特殊trap OID，表示該Trap或Inform PDU為消息。
c，根據消息體定義其它變量。
步驟二，管理站向被管設備發(fā)送消息，見圖6。
管理站根據所要發(fā)送的消息生成Set-Request PDU，把該消息的消息體按約定的次序綁定在PDU的綁定列表中，把消息號的OID和消息號的值綁定為PDU的最后一個變量，并發(fā)送到指定代理(S602)。
代理收到Set-Request PDU，并根據其變量綁定列表來設置變量的值(S604)，如果最后一個變量不是消息號，則作為普通的Set-Request PDU進行處理(S610)。當發(fā)現需要設置的最后一個變量的OID是消息號的OID(S606)時，則將該變量的值設置完成之后，調用消息處理入口函數(S608)。判斷消息號是否合法(S612)，如果消息號合法，在消息處理例程中根據消息號調用消息處理函數(該函數一般由被管設備提供)(S616)，如果有，則從PDU的變量綁定列表中按照約定的次序取出消息體，如果沒有對應的消息號則進行錯誤處理。如果不合法，則進行異常處理(S616)。
步驟三，被管設備向管理站發(fā)送消息，見圖7。
被管設備根據消息生成Trap或Inform PDU，將該PDU變量綁定列表的第二變量設置為步驟一)中S602)所定義的特殊trap OID，然后把該消息的消息體按約定的次序綁定在PDU的綁定列表中，最后把消息號的OID和值綁定為該PDU綁定列表的最后一個變量，并由代理發(fā)送到管理站。
管理站收到Trap或Inform PDU(S702)，檢查其變量綁定列表的第二個變量，如果不是步驟一)中S602)所定義的第二個變量是否是特殊trap OID(S704)，如圖不是，則將該PDU作為普通的Trap或Inform處理(S706)，否則檢索該PDU變量綁定列表的最后一個變量(S708)，如果發(fā)現最后一個變量的OID不是消息號的OID時，進行錯誤處理(S712)，否則調用消息處理入口函數(S714)。在消息處理例程中根據消息號調用消息處理函數，如果沒有對應的消息號則進行錯誤處理。如果有，則從PDU的變量綁定列表中按照約定的次序取出消息體(S716)。
為了更好地說明本發(fā)明的目的、技術方案和有益效果，下面在WCDMA的基站中的主控單板和RDM射頻檢測板之間采用SNMP協議實現消息交互進行詳細描述(其中主控單板上有管理站，RDM射頻檢測板上有代理模塊)一，定義管理站和被管設備之間的接口(MIB文件)，見圖4。定義出消息頭為msgHeadDef，其中包含消息號為msgId，OID為1.3.6.1.4.1.1943.1.4.2，消息序號為sequenceNo。
定義出標識Trap或Inform PDU為消息的trap OID為1.3.6.1.4.1.1943.1.0.1，名稱為rdmInformMsgHead。
按照消息定義其它變量，這里用到的有1.3.6.1.4.1.1943.1.5.1cmFrequencyResponse初始配置請求，重配回應消息1.3.6.1.4.1.1943.1.5.2cmFrequencyResponse因為都為空消息，所以期下沒有掛葉子節(jié)點，1.3.6.1.4.1.1943.1.6.1cmFrequencyCfgHead初始配置請求回應(重配請求)，下面定義了消息體，是一個包含一張表(aTwrdmFreqInfoTable)的結構。
二，RDM射頻檢測板向主控單板發(fā)上電提示和初始配置請求。
外圍單板上電成功，發(fā)送冷啟動Trap到主控單板。
外圍單板構造初始配置請求的消息發(fā)送到RDM射頻檢測板的代理模塊，代理模塊將該消息轉化為SNMP PDU發(fā)出。
主控單板收到該PDU，檢查其變量綁定列表的第二個變量，如果不是1.3.6.1.4.1.1943.1.0.1rdmInformMsgHead，則將該PDU做為普通的Trap處理，否則檢索該PDU變量綁定列表的最后一個變量，如果發(fā)現最后一個變量的OID不是消息號的MsgId1.3.6.1.4.1.1943.1.4.2時，進行錯誤處理，否則調用消息處理入口函數。
在消息處理例程中根據消息號調用消息處理函數如果是初始配置請求消息，則構造初始配置回應消息，并通過SNMP發(fā)送到外圍單板。如果沒有該消息的處理函數，則進入錯誤處理。
三，主控單板回應初始配置請求。
代理收到Set-Request PDU，并更具其變量綁定列表來設置變量的值，當發(fā)現需要設置的最后一個變量的OID是消息號的OIDMsgId 1.3.6.1.4.1.1943.1.4.2時，則將該變量的值設置完成之后，調用消息處理入口函數，否則不進行處理。
在消息處理例程中根據消息號調用消息處理函數如果是初始配置回應消息，則將初始配置回音消息中攜帶的數據配到RDM射頻檢測板的模塊中去，RDM射頻檢測板進入正常工作狀態(tài)。如果沒有該消息處理函數，則進入錯誤處理。
從以上實施情況來看，本發(fā)明提出的技術方案可以在SNMP協議的基礎之上實現消息交互。
采用本發(fā)明方法，與現有技術相比，主要有以下優(yōu)點(1)解決了目前SNMP交互模型較為簡單的問題，并且只通過一個變量的設置就可以讓網絡管理系統和代理端做出多種響應，實現了普通系統中的消息交互機制。
(2)有了消息交互，有效減少了網絡管理系統的負擔，很多輪詢的操作，都可以用代理端的主動上報來替代，也有效較少了網絡流量。
(3)擴展了SNMP協議的應用場景，可以方便的應用到有網絡管理但又有消息交互的環(huán)境中。
(4)該方法可以和原先的SNMP協議共存，它是在SNMP協議的基礎上做的擴展。
以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。
權利要求
1.一種采用SNMP協議的通信系統，其特征在于包括SNMP管理站，用于與至少一個被管設備預先定義接口，并根據所述接口解析來自所述至少一個被管設備的消息并進行相應操作；SNMP代理，用于轉發(fā)來自所述SNMP管理站或所述至少一個被管設備的消息；以及所述至少一個被管設備，用于根據預先定義的接口解析來自所述SNMP管理站的消息并進行相應操作。
2.根據權利要求1所述的通信系統，其特征在于，所述SNMP管理站發(fā)送至所述至少一個被管設備的消息通過設置請求數據字段承載，并將所述設置請求數據字段中的變量綁定列表中的最后一個變量綁定為消息號。
3.根據權利要求2所述的通信系統，其特征在于，所述消息號被設置為所述SNMP代理在接收所述設置請求數據字段時按照所述變量綁定列表的次序設置變量的值。
4.根據權利要求1所述的通信系統，其特征在于，所述至少一個被管設備發(fā)送至所述SNMP管理站的消息通過SNMP v2 Trap或Inform數據字段承載，并將其變量綁定列表中的第二個變量綁定為用于標識所述SNMP v2陷阱或通知數據字段承載的是消息的信息，并將所述變量綁定列表中的最后一個變量綁定為消息號。
5.一種采用SNMP協議的消息交互方法，其特征在于，包括以下步驟步驟S502，SNMP管理站和至少一個被管設備之間定義接口及其消息號和變量；步驟S504，所述SNMP管理站通過至少一個SNMP代理向所述至少一個被管設備發(fā)送消息，將所述消息的消息體按照約定的次序綁定在數據字段綁定列表中，并將所述數據字段的綁定列表中的最后一個變量綁定為消息號；以及步驟S506，所述被管設備根據所述消息號進行處理，并從所述變量綁定列表中按照約定的次序取出消息體。
6.根據權利要求5所述的消息交互方法，其特征在于，所述SNMP管理站發(fā)送至所述至少一個被管設備的消息通過設置請求數據字段承載。
7.一種采用SNMP協議的消息交互方法，其特征在于，包括以下步驟步驟S512，SNMP管理站和至少一個被管設備之間定義接口及其消息號和變量；步驟S514，所述被管設備通過至少一個SNMP代理向所述SNMP管理站發(fā)送消息，將所述消息的消息體按照約定的次序綁定在數據字段綁定列表中，并將所述數據字段的綁定列表中的最后一個變量綁定為消息號；以及步驟S516，所述SNMP管理站根據所述消息號進行處理，并從所述變量綁定列表中按照約定的次序取出消息體。
8.根據權利要求7所述的消息交互方法，其特征在于，所述至少一個被管設備發(fā)送至所述SNMP管理站的消息通過SNMP v2陷阱或通知數據字段承載，并將其變量綁定列表中的第二個變量綁定為用于標識所述SNMP v2陷阱或通知數據字段承載的是消息的信息，并將所述變量綁定列表中的最后一個變量綁定為消息號。
全文摘要
本發(fā)明提供了采用SNMP協議的通信系統和消息交互方法，其中，消息交互方法包括步驟S502，SNMP管理站和至少一個被管設備之間定義接口及其消息號和變量；步驟S504，SNMP管理站通過至少一個SNMP代理向至少一個被管設備發(fā)送消息，將消息的消息體按照約定的次序綁定在數據字段綁定列表中，并將數據字段的綁定列表中的最后一個變量綁定為消息號；以及步驟S506，被管設備根據消息號進行處理，并從變量綁定列表中按照約定的次序取出消息體。本發(fā)明解決了目前SNMP交互模型較為簡單的問題，并且只通過一個變量的設置就可以讓網絡管理系統和代理端做出多種響應，實現了普通系統中的消息交互機制。
文檔編號H04L12/54GK101076028SQ200710126760
公開日2007年11月21日 申請日期2007年6月21日 優(yōu)先權日2007年6月21日
發(fā)明者司杰, 陶衛(wèi)軍 申請人:中興通訊股份有限公司