李丹鳳,張治中
(重慶郵電大學(xué) 通信網(wǎng)與測試技術(shù)重點實驗室,重慶400065)
LTE是3G的長期演進,改進并增強了3G的技術(shù),在20 MHz頻譜帶寬下能夠提供下行100 Mbit/s與上行50 Mbit/s的峰值速率[1]。隨著中國移動建設(shè)的TD-LTE演示網(wǎng)相繼在2010年的上海世博會、廣州亞運會上登臺亮相,基于TD-LTE網(wǎng)絡(luò)的即攝即傳系統(tǒng)、移動媒體采訪車運用在2011年8月的深圳大運會電視直播中,全球LTE商用網(wǎng)絡(luò)正在加速推進,整個產(chǎn)業(yè)鏈也在逐步走向成熟[2]?;谶@樣的現(xiàn)狀,為確保LTE網(wǎng)絡(luò)達到最佳運行狀態(tài),研發(fā)LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)具有重大意義。
LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)采用分布式、分層模塊化、可伸縮、可組合的架構(gòu)體系,針對不同用戶進行個性化設(shè)計,保證監(jiān)測系統(tǒng)高效、可靠、穩(wěn)定運行[3]。由于LTE是基于全IP的新一代通信網(wǎng)絡(luò),作為能動態(tài)獲取IP地址,租期內(nèi)使用IP的動態(tài)主機配置協(xié)議(Dynamic Host Configuration Protocol,DHCP)在LTE網(wǎng)絡(luò)中其優(yōu)勢顯得尤為突出。在LTE網(wǎng)絡(luò)中通過PGW(Packet Data Network)來管理DHCP協(xié)議,DHCP協(xié)議的前身是Bootstrap引導(dǎo)程序協(xié)議(BOOTP),DHCP不僅具有BOOTP的特性還對其進行了擴充。DHCP為改善IP地址短缺、充分利用網(wǎng)絡(luò)資源,新增動態(tài)分配IP、租期內(nèi)使用IP地址的機制。DHCP工作在OSI的應(yīng)用層,基于UDP應(yīng)用,DHCP CLIENT(DHCP客戶機)和DHCP SERVER(DHCP服務(wù)器)分別采用UDP端口號68和67來交接。該協(xié)議在協(xié)議棧中的位置如圖1所示。
圖1 DHCP協(xié)議棧結(jié)構(gòu)
由于不同的協(xié)議有不同的消息格式,所以在本監(jiān)測系統(tǒng)中采取以模塊化各個協(xié)議的處理辦法來應(yīng)對協(xié)議間功能和格式的差別,此方法可以推廣到LTE網(wǎng)絡(luò)中的其他協(xié)議[4]。本文研究的主要內(nèi)容就是如何利用模塊化思想,根據(jù)協(xié)議標準中規(guī)定的協(xié)議消息結(jié)構(gòu)進行DHCP協(xié)議的解碼并能在LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)中形象直觀地正確顯示解碼結(jié)果。
一次成功的DHCPv4流程包含DHCP Discover,DHCP Offer,DHCP Request,DHCP Ack和DHCP Release這5個階段,其流程如圖2所示。
圖2 一次成功DHCP的流程圖
DHCP Discover(發(fā)現(xiàn)階段):DHCP Client(DHCP客戶機)以廣播方式尋找DHCP Server(DHCP服務(wù)器)。
DHCP Offer(提供階段):DHCP Server響應(yīng)廣播信息,提供IP地址。
DHCP Request(選擇階段):DHCP Client確定選擇哪臺DHCP Server提供的IP地址及相關(guān)內(nèi)容。
DHCP Ack(確認階段):DHCP Server授權(quán)DHCP Client提供IP地址,并給出租借期限。
DHCP Release(釋放階段):DHCP Client釋放IP地址,告知DHCP Server回收IP地址。
DHCP保留登錄信息:對登錄過網(wǎng)絡(luò)的DHCP客戶機保留信息,以后再登錄無須再發(fā)送DHCP Discover發(fā)現(xiàn)信息,只需發(fā)送DHCP Request請求信息。不過當前次使用的IP地址無法再分配時(比如此IP地址已分配給其他DHCP客戶機使用),那就必須重新發(fā)送DHCP Discover發(fā)現(xiàn)信息來請求新的IP地址。
DHCP動態(tài)獲得的IP地址、租期內(nèi)使用IP地址:DHCP Client動態(tài)獲得IP地址的同時還會收到IP租借期限。當租期過50%時,DHCP Client就自動向DHCP Server發(fā)送更新其IP租約的請求,以延長租期。當租期滿后,DHCP Server便會收回出租的IP地址。
DHCP的報文格式,如圖3所示。
圖3 DHCP報文格式
圖3 中,各參數(shù)設(shè)置如下:若是Client送給Server的封包,OP設(shè)為1,反向為2;Htype為硬件類別,若為Ethernet,則設(shè)為1;Hlen為硬件長度,若為Ethernet,則設(shè)為6;若數(shù)據(jù)包需經(jīng)過Router傳送,Hops每站加1,若在同一網(wǎng)內(nèi),則設(shè)為0;Transaction ID為事務(wù)ID,是個隨機數(shù),用于客戶和服務(wù)器之間匹配請求和相應(yīng)消息;Seconds為由用戶指定的時間,指開始地址獲取和更新進行后的時間;Flags取0~15 bit,最左位為1時,表示Server將以廣播方式傳送封包給Client,其余尚未使用;Ciaddr為用戶IP地址;Yiaddr為客戶IP地址;Siaddr為用于bootstrap過程中的IP地址;Giaddr為轉(zhuǎn)發(fā)代理(網(wǎng)關(guān))IP地址;Chaddr為Client的硬件地址;ChCiHaddrPadd為用戶地址冗余位;Sname為可選Server的名稱,以0x00結(jié)尾;File為啟動文件名;MagicCookie為魔塊;Options為廠商標識,可選的參數(shù)字段(針對不同DHCP消息,Option有不同的參數(shù)字段)。
解碼設(shè)計框架如圖4所示。
圖4 DHCP的解碼設(shè)計框架圖
在LTE監(jiān)測系統(tǒng)中,保證網(wǎng)絡(luò)數(shù)據(jù)準確無誤的解碼是監(jiān)測系統(tǒng)進行后續(xù)的呼叫詳細記錄(CDR)合成、消息過濾、統(tǒng)計分析等功能的必備前提和基礎(chǔ)保證[5]。消息解碼由詳細解碼和簡單解碼2個部分組成。詳細解碼和簡單解碼都是對原始數(shù)據(jù)進行解析,不同之處在于詳細解碼是對數(shù)據(jù)中的每個字節(jié)、每個比特位解析,而簡單解碼只提取消息數(shù)據(jù)中的關(guān)鍵信息。詳細解碼結(jié)果經(jīng)封裝后在LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)界面上以樹形圖展現(xiàn),方便用戶快速理解消息數(shù)據(jù)代表的信息,而且本監(jiān)測系統(tǒng)的詳細解碼采用中英文雙語形式,適用于更多的用戶。簡單解碼結(jié)果經(jīng)封裝后用于在監(jiān)測系統(tǒng)界面上進行過濾消息和列表顯示消息,而經(jīng)合成解碼封裝后則是用于消息的呼叫詳細記錄(CDR)合成。協(xié)議解碼由低到高依次每層進行,只有在對下層協(xié)議進行準確無誤解析的同時成功提取上層協(xié)議PDU信息后才能對上層協(xié)議進行解析。由于DHCP協(xié)議基于UDP層,那么就需要依次進行Ethernet層、IP層、UDP層各層協(xié)議的解碼及獲取上層PDU才能最終成功解析DHCP。
由于監(jiān)測系統(tǒng)設(shè)計的要求,DHCP協(xié)議的簡單解碼部分只提取了DHCP消息類型(DHCPMSGType)和事務(wù)號(TransactionID)用于監(jiān)測系統(tǒng)界面中每條數(shù)據(jù)的概要顯示,方便快速準確地定位數(shù)據(jù)中的每條消息屬于哪一個信令流程。簡單解碼在LTE監(jiān)測系統(tǒng)的界面顯示結(jié)果如圖5所示。
圖5 簡單解碼在LTE監(jiān)測系統(tǒng)的界面顯示
特別是在LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)中對DHCPMSGType進行處理的時候,改掉了以前在TD_SCDMA監(jiān)測系統(tǒng)中使用的預(yù)先用宏定義消息類型,然后再用switch case匹配的方案:
switch(XXXXMSGTypeID)//XXXX消息類型號
{
Case1:
Case2:
………………
}
采用將DHCP消息的消息類型定義為一個結(jié)構(gòu)體類型DHCP_MESSAGE_TYPE的三維數(shù)組DHCPMsgeTyp
eTable:
typedef struct DHCP_MESSAGE_TYPE{
int value;
char*strptr[2];
}DHCPMessageType;
static DHCPMessageType DHCPMsgeTypeTable[]={
{1,_T("DHCP發(fā)現(xiàn)"), _T("DHCP DISCOVER")},
{2,_T("DHCP請求"), _T("DHCP REQUEST")},
{3,_T("DHCP選擇"), _T("DHCP OFFER")},
…………………………………………
};
最后再利用for循環(huán)來實現(xiàn)消息類型的匹配,不但節(jié)省了代碼空間,提高了代碼運行速度,而且便于測試和修改:
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;
}
}
在LTE監(jiān)測系統(tǒng)中對DHCP協(xié)議的詳細解碼做了一套完整的實現(xiàn)方案。DHCP協(xié)議詳細解碼設(shè)計方案如圖6所示。
圖6 DHCP協(xié)議詳細解碼設(shè)計方案圖
對采集到的DHCP消息數(shù)據(jù),首先進入?yún)f(xié)議判別函數(shù)ISMe,由UDP端口號為68或者67來辨別是否為DHCP的數(shù)據(jù),如果不是則結(jié)束解碼,如果是則進入詳細解碼函數(shù)bootpc_fdecode開始解析固定消息頭部分(即可選參數(shù)Option之前的部分)。由于DHCP是BOOTP的演進,所以筆者在設(shè)計監(jiān)測系統(tǒng)的時候仍然包含了BOOTP協(xié)議的特性。下面的圖7、圖8和圖9分別是wirshark和筆者所研究的LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)(中英文版)對DHCP協(xié)議消息固定頭部分詳細解碼的截圖。
根據(jù)協(xié)議規(guī)范中對DHCP消息頭固定部分的規(guī)定以及和wirshark的解碼結(jié)果對比可得出,LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)對DHCP固定頭部分的解碼完全正確。
當固定消息頭解碼完成之后,進入可選參數(shù)類型函數(shù)decode_bootp_op進行Option類型的匹配。先用while循環(huán)判斷消息數(shù)據(jù)解析到的位置是否為0xff,如果是則結(jié)束解碼,如果不是則開始匹配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相對的解碼函數(shù)
break;
case BOOTP_C_OP_SUBNET_MASK:
res=decode_op_subnet_mask(pData,pInfo,pDetail);
break;
…………………………….
}
當匹配到某個Option類型時,就進入相應(yīng)的Option解碼函數(shù)decode_op_xxxx進行解碼。解析完一個獨立的Option類型后,pData將自動增加該Option所占的字節(jié)長度,然后再進入while循環(huán)判斷、匹配。
下面是DHCP DISCOVER攜帶的Option(可選參數(shù))部分的詳細解碼結(jié)果圖如圖10所示。
圖10 DHCP協(xié)議里DHCP消息類型的詳細解碼(截圖)
解讀協(xié)議規(guī)范可知,可變參數(shù)項Option還可能會攜帶子Option。對這種攜帶了子Option項的解碼方法基本和沒有攜帶子Option項的相同,只是會多判斷在父option中何時開始和結(jié)束子Option的解碼。
這里以Relay Agent Information這個Option為例來闡述攜帶了子Option情況的詳細解碼格式。Relay Agent Information的報文格式如圖11[6]所示。
圖11 Relay Agent Information的報文格式
Code 82(父Option類型號為82)占1 byte,Len(Option參數(shù)的長度)占1 byte,N代表了整個Agent Information Field的長度,不包含Code和Len所占的2 byte。i1,i2,i3,…,iN是Relay Agent Information里面的具體參數(shù)信息,長度不定。
對于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里面具體的參數(shù)信息,長度不定。
在父Option的長度后面就是它所攜帶的子Option。父Option里面的1 byte就代表1個子Option,子Option和父Option有相同報文格式、子Option類型號、長度和值。因此子Option和父Option采用相同的解碼方式。因為1個父Option會攜帶多個子Option,故而必須對何時結(jié)束解碼做出判斷。在代碼中采用了下面這種方式來判斷所攜帶的子Option是否解完。在父Option中定義1個循環(huán)長度的統(tǒng)計數(shù)和1個子Option長度數(shù)。
int nCLength=0; //循環(huán)中的長度統(tǒng)計
int nSubLength=0; //子Option長度
……
while(nCLength<nLength)//nLength為父Option的長度
{
……
nCLength+=nSubLength+2;//2是子Option的編號,l長度所占的字節(jié)數(shù)
}
當nCLength統(tǒng)計長度比父Option的長度nLength小的時候,表明父Option里面還有子Option,那么就繼續(xù)解碼,否則就結(jié)束子Option的解碼。
由于LTE監(jiān)測系統(tǒng)中對DHCP模塊測試時采用的是現(xiàn)有3G和2G網(wǎng)絡(luò)數(shù)據(jù),所以無法從數(shù)據(jù)上在監(jiān)測系統(tǒng)中直接查看到帶有子Option型的可選參數(shù)結(jié)果圖形顯示,但是從前面的解碼結(jié)果圖中可以得出本研究方案改進了之前版本監(jiān)測系統(tǒng)中處理代碼的缺陷,而且實施有效可行,能方便更多用戶參照消息更好地理解和分析協(xié)議。
本文針對已經(jīng)開始商業(yè)試用的LTE網(wǎng)絡(luò)及現(xiàn)有國際環(huán)境,介紹了LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)的架構(gòu)與功能,分析了DHCP協(xié)議的信令流程及報文格式,提出了研究DHCP協(xié)議解碼的方案。此研究方案在LTE網(wǎng)絡(luò)監(jiān)測系統(tǒng)的軟件模塊中,采用VC++面向?qū)ο缶幊谭椒ǎ?]實現(xiàn)了DHCP協(xié)議解碼,該模塊通過大規(guī)?,F(xiàn)網(wǎng)測試論證了該研究方案的正確性、有效性、推廣性。在“重郵東電TD-LTE集中監(jiān)測系統(tǒng)”的應(yīng)用過程中穩(wěn)定、可靠,運維良好。
[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逢天時地利人和只待時間窗口之東風(fēng)[EB/OL].[2011-10-09].http://www.c114.net/topic/3017/a646820.html.
[3]謝金鳳,張治中,李紅華,等.TD-SCDMA網(wǎng)絡(luò)集中監(jiān)測系統(tǒng)3G-324M協(xié)議監(jiān)測方案研究[J].電視技術(shù),2010,34(11):53-57.
[4]魏輝,張治中.TD-SCDMA網(wǎng)絡(luò)測試儀中SCCP協(xié)議解碼及上層PDU獲取方案[J].重慶郵電大學(xué)學(xué)報:自然科學(xué)版,2007,19(1):51-56.
[5]陳玉花,張治中,杜西亞.TD-SCDMA網(wǎng)絡(luò)Iu-PS口CDR合成方案[J].電視技術(shù),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)技術(shù)原理與系統(tǒng)設(shè)計[M].北京:人民郵電出版社,2008.
[8]嚴蔚敏,吳偉民.數(shù)據(jù)結(jié)構(gòu)[M].北京:清華大學(xué)出版社,2003.