LTE網絡監測系統中DHCP協議的解碼方案研究

李丹鳳，張治中

(重慶郵電大學 通信網與測試技術重點實驗室，重慶400065)

LTE是3G的長期演進，改進并增強了3G的技術，在20 MHz頻譜帶寬下能夠提供下行100 Mbit/s與上行50 Mbit/s的峰值速率［1］。隨著中國移動建設的TD-LTE演示網相繼在2010年的上海世博會、廣州亞運會上登臺亮相，基于TD-LTE網絡的即攝即傳系統、移動媒體采訪車運用在2011年8月的深圳大運會電視直播中，全球LTE商用網絡正在加速推進，整個產業鏈也在逐步走向成熟［2］。基于這樣的現狀，為確保LTE網絡達到最佳運行狀態，研發LTE網絡監測系統具有重大意義。

LTE網絡監測系統采用分布式、分層模塊化、可伸縮、可組合的架構體系，針對不同用戶進行個性化設計，保證監測系統高效、可靠、穩定運行［3］。由于LTE是基于全IP的新一代通信網絡，作為能動態獲取IP地址，租期內使用IP的動態主機配置協議(Dynamic Host Configuration Protocol，DHCP)在LTE網絡中其優勢顯得尤為突出。在LTE網絡中通過PGW(Packet Data Network)來管理DHCP協議，DHCP協議的前身是Bootstrap引導程序協議(BOOTP)，DHCP不僅具有BOOTP的特性還對其進行了擴充。DHCP為改善IP地址短缺、充分利用網絡資源，新增動態分配IP、租期內使用IP地址的機制。DHCP工作在OSI的應用層，基于UDP應用，DHCP CLIENT(DHCP客戶機)和DHCP SERVER(DHCP服務器)分別采用UDP端口號68和67來交接。該協議在協議棧中的位置如圖1所示。

圖1 DHCP協議棧結構

由于不同的協議有不同的消息格式，所以在本監測系統中采取以模塊化各個協議的處理辦法來應對協議間功能和格式的差別，此方法可以推廣到LTE網絡中的其他協議［4］。本文研究的主要內容就是如何利用模塊化思想，根據協議標準中規定的協議消息結構進行DHCP協議的解碼并能在LTE網絡監測系統中形象直觀地正確顯示解碼結果。

1 DHCP協議的工作流程

一次成功的DHCPv4流程包含DHCP Discover，DHCP Offer，DHCP Request，DHCP Ack和DHCP Release這5個階段，其流程如圖2所示。

圖2 一次成功DHCP的流程圖

DHCP Discover(發現階段):DHCP Client(DHCP客戶機)以廣播方式尋找DHCP Server(DHCP服務器)。

DHCP Offer(提供階段):DHCP Server響應廣播信息，提供IP地址。

DHCP Request(選擇階段):DHCP Client確定選擇哪臺DHCP Server提供的IP地址及相關內容。

DHCP Ack(確認階段):DHCP Server授權DHCP Client提供IP地址，并給出租借期限。

DHCP Release(釋放階段):DHCP Client釋放IP地址，告知DHCP Server回收IP地址。

DHCP保留登錄信息:對登錄過網絡的DHCP客戶機保留信息，以后再登錄無須再發送DHCP Discover發現信息，只需發送DHCP Request請求信息。不過當前次使用的IP地址無法再分配時(比如此IP地址已分配給其他DHCP客戶機使用)，那就必須重新發送DHCP Discover發現信息來請求新的IP地址。

DHCP動態獲得的IP地址、租期內使用IP地址:DHCP Client動態獲得IP地址的同時還會收到IP租借期限。當租期過50%時，DHCP Client就自動向DHCP Server發送更新其IP租約的請求，以延長租期。當租期滿后，DHCP Server便會收回出租的IP地址。

2 DHCP的報文格式

DHCP的報文格式，如圖3所示。

圖3 DHCP報文格式

圖3 中，各參數設置如下:若是Client送給Server的封包，OP設為1，反向為2;Htype為硬件類別，若為Ethernet，則設為1;Hlen為硬件長度，若為Ethernet，則設為6;若數據包需經過Router傳送，Hops每站加1，若在同一網內，則設為0;Transaction ID為事務ID，是個隨機數，用于客戶和服務器之間匹配請求和相應消息;Seconds為由用戶指定的時間，指開始地址獲取和更新進行后的時間;Flags取0～15 bit，最左位為1時，表示Server將以廣播方式傳送封包給Client，其余尚未使用;Ciaddr為用戶IP地址;Yiaddr為客戶IP地址;Siaddr為用于bootstrap過程中的IP地址;Giaddr為轉發代理(網關)IP地址;Chaddr為Client的硬件地址;ChCiHaddrPadd為用戶地址冗余位;Sname為可選Server的名稱，以0x00結尾;File為啟動文件名;MagicCookie為魔塊;Options為廠商標識，可選的參數字段(針對不同DHCP消息，Option有不同的參數字段)。

3 DHCP的解碼實現

解碼設計框架如圖4所示。

圖4 DHCP的解碼設計框架圖

在LTE監測系統中，保證網絡數據準確無誤的解碼是監測系統進行后續的呼叫詳細記錄(CDR)合成、消息過濾、統計分析等功能的必備前提和基礎保證［5］。消息解碼由詳細解碼和簡單解碼2個部分組成。詳細解碼和簡單解碼都是對原始數據進行解析，不同之處在于詳細解碼是對數據中的每個字節、每個比特位解析，而簡單解碼只提取消息數據中的關鍵信息。詳細解碼結果經封裝后在LTE網絡監測系統界面上以樹形圖展現，方便用戶快速理解消息數據代表的信息，而且本監測系統的詳細解碼采用中英文雙語形式，適用于更多的用戶。簡單解碼結果經封裝后用于在監測系統界面上進行過濾消息和列表顯示消息，而經合成解碼封裝后則是用于消息的呼叫詳細記錄(CDR)合成。協議解碼由低到高依次每層進行，只有在對下層協議進行準確無誤解析的同時成功提取上層協議PDU信息后才能對上層協議進行解析。由于DHCP協議基于UDP層，那么就需要依次進行Ethernet層、IP層、UDP層各層協議的解碼及獲取上層PDU才能最終成功解析DHCP。

3.1 DHCP協議簡單解碼界面的實現

由于監測系統設計的要求，DHCP協議的簡單解碼部分只提取了DHCP消息類型(DHCPMSGType)和事務號(TransactionID)用于監測系統界面中每條數據的概要顯示，方便快速準確地定位數據中的每條消息屬于哪一個信令流程。簡單解碼在LTE監測系統的界面顯示結果如圖5所示。

圖5 簡單解碼在LTE監測系統的界面顯示

特別是在LTE網絡監測系統中對DHCPMSGType進行處理的時候，改掉了以前在TD_SCDMA監測系統中使用的預先用宏定義消息類型，然后再用switch case匹配的方案:

switch(XXXXMSGTypeID)//XXXX消息類型號

{

Case1:

Case2:

………………

}

采用將DHCP消息的消息類型定義為一個結構體類型DHCP_MESSAGE_TYPE的三維數組DHCPMsgeTyp

eTable:

typedef struct DHCP_MESSAGE_TYPE{

int value;

char*strptr［2］;

}DHCPMessageType;

static DHCPMessageType DHCPMsgeTypeTable［］={

{1，_T("DHCP發現")， _T("DHCP DISCOVER")}，

{2，_T("DHCP請求")， _T("DHCP REQUEST")}，

{3，_T("DHCP選擇")， _T("DHCP OFFER")}，

…………………………………………

};

最后再利用for循環來實現消息類型的匹配，不但節省了代碼空間，提高了代碼運行速度，而且便于測試和修改:

int32 nDHCPMsgType=pResult-＞uDHCPMsgType;

m_DecResultItem［DHCPMSGType］.ItemValue.nenumValue=nDHCPMsgType;

for(int i=0;i＜sizeof(DHCPMsgeTypeTable)/sizeof(struct DHCP_MESSAGE_TYPE);i++)

{

if(DHCPMsgeTypeTable［i］.value==nDHCPMsgType)

{

_stprintf(m_DecResultItem［DHCPMSGType］.chNotes，_T("%s")，

DHCPMsgeTypeTable［i］.strptr［1］);

break;

}

}

3.2 DHCP協議詳細解碼的實現

在LTE監測系統中對DHCP協議的詳細解碼做了一套完整的實現方案。DHCP協議詳細解碼設計方案如圖6所示。

圖6 DHCP協議詳細解碼設計方案圖

對采集到的DHCP消息數據，首先進入協議判別函數ISMe，由UDP端口號為68或者67來辨別是否為DHCP的數據，如果不是則結束解碼，如果是則進入詳細解碼函數bootpc_fdecode開始解析固定消息頭部分(即可選參數Option之前的部分)。由于DHCP是BOOTP的演進，所以筆者在設計監測系統的時候仍然包含了BOOTP協議的特性。下面的圖7、圖8和圖9分別是wirshark和筆者所研究的LTE網絡監測系統(中英文版)對DHCP協議消息固定頭部分詳細解碼的截圖。

根據協議規范中對DHCP消息頭固定部分的規定以及和wirshark的解碼結果對比可得出，LTE網絡監測系統對DHCP固定頭部分的解碼完全正確。

當固定消息頭解碼完成之后，進入可選參數類型函數decode_bootp_op進行Option類型的匹配。先用while循環判斷消息數據解析到的位置是否為0xff，如果是則結束解碼，如果不是則開始匹配Option類型:

while(*((pInfo-＞pHeader)+(pInfo-＞nCurPos))!=0xff)

{

uint8*pData=(pInfo-＞pHeader)+(pInfo-＞nCurPos);//*pData從消息頭開始到解碼所解析的位置

switch(*pData)

{

case BOOTP_C_OP_PAD://option的類型

res=decode_op_pad(pData，pInfo，pDetail);//與Option相對的解碼函數

break;

case BOOTP_C_OP_SUBNET_MASK:

res=decode_op_subnet_mask(pData，pInfo，pDetail);

break;

…………………………….

}

當匹配到某個Option類型時，就進入相應的Option解碼函數decode_op_xxxx進行解碼。解析完一個獨立的Option類型后，pData將自動增加該Option所占的字節長度，然后再進入while循環判斷、匹配。

下面是DHCP DISCOVER攜帶的Option(可選參數)部分的詳細解碼結果圖如圖10所示。

圖10 DHCP協議里DHCP消息類型的詳細解碼(截圖)

解讀協議規范可知，可變參數項Option還可能會攜帶子Option。對這種攜帶了子Option項的解碼方法基本和沒有攜帶子Option項的相同，只是會多判斷在父option中何時開始和結束子Option的解碼。

這里以Relay Agent Information這個Option為例來闡述攜帶了子Option情況的詳細解碼格式。Relay Agent Information的報文格式如圖11［6］所示。

圖11 Relay Agent Information的報文格式

Code 82(父Option類型號為82)占1 byte，Len(Option參數的長度)占1 byte，N代表了整個Agent Information Field的長度，不包含Code和Len所占的2 byte。i1，i2，i3，…，iN是Relay Agent Information里面的具體參數信息，長度不定。

對于Relay Agent Information里面的Suboption(子Option)的報文格式如圖12［6］所示。

圖12 Relay Agent Information的Suboption的報文格式

1是Suboption的編號，占1 byte。N是Suboption的長度，占1 byte，不包含SubOpt和Len所占的2 byte。s1，s2，s3，…，sN是Suboption里面具體的參數信息，長度不定。

在父Option的長度后面就是它所攜帶的子Option。父Option里面的1 byte就代表1個子Option，子Option和父Option有相同報文格式、子Option類型號、長度和值。因此子Option和父Option采用相同的解碼方式。因為1個父Option會攜帶多個子Option，故而必須對何時結束解碼做出判斷。在代碼中采用了下面這種方式來判斷所攜帶的子Option是否解完。在父Option中定義1個循環長度的統計數和1個子Option長度數。

int nCLength=0; //循環中的長度統計

int nSubLength=0; //子Option長度

……

while(nCLength＜nLength)//nLength為父Option的長度

{

……

nCLength+=nSubLength+2;//2是子Option的編號，l長度所占的字節數

}

當nCLength統計長度比父Option的長度nLength小的時候，表明父Option里面還有子Option，那么就繼續解碼，否則就結束子Option的解碼。

由于LTE監測系統中對DHCP模塊測試時采用的是現有3G和2G網絡數據，所以無法從數據上在監測系統中直接查看到帶有子Option型的可選參數結果圖形顯示，但是從前面的解碼結果圖中可以得出本研究方案改進了之前版本監測系統中處理代碼的缺陷，而且實施有效可行，能方便更多用戶參照消息更好地理解和分析協議。

4 小結

本文針對已經開始商業試用的LTE網絡及現有國際環境，介紹了LTE網絡監測系統的架構與功能，分析了DHCP協議的信令流程及報文格式，提出了研究DHCP協議解碼的方案。此研究方案在LTE網絡監測系統的軟件模塊中，采用VC++面向對象編程方法［7］實現了DHCP協議解碼，該模塊通過大規模現網測試論證了該研究方案的正確性、有效性、推廣性。在“重郵東電TD-LTE集中監測系統”的應用過程中穩定、可靠，運維良好。

［1］STEFM A S，TOUFIK L.MATI＇HEW B.LTE—the UMTS long term evolution from theory to practice［EB/OL］.［2010-03-15］.http://download.csdn.net/SOLlrce/l941542.

［2］于藝婉.TD-LTE逢天時地利人和只待時間窗口之東風［EB/OL］.［2011-10-09］.http://www.c114.net/topic/3017/a646820.html.

［3］謝金鳳，張治中，李紅華，等.TD-SCDMA網絡集中監測系統3G-324M協議監測方案研究［J］.電視技術，2010，34(11):53-57.

［4］魏輝，張治中.TD-SCDMA網絡測試儀中SCCP協議解碼及上層PDU獲取方案［J］.重慶郵電大學學報:自然科學版，2007，19(1):51-56.

［5］陳玉花，張治中，杜西亞.TD-SCDMA網絡Iu-PS口CDR合成方案［J］.電視技術，2009，49(11):53-56.

［6］PATRICK M.DHCP relay agent information option［EB/OL］.［2011-10-09］.ftp://ftp.rfc-editor.org/in-notes/rfc3046.txt.

［7］沈嘉，索士強，全海洋，等.3GPP長期演進(LTE)技術原理與系統設計［M］.北京:人民郵電出版社，2008.

［8］嚴蔚敏，吳偉民.數據結構［M］.北京:清華大學出版社，2003.