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.