协议监测（精选八篇）
协议监测 篇1
伴随着国际范围内LTE-A技术的商用,新型的无线网络分析和优化仪表日益得到人们的广泛重视和大力发展。在移动通信测试仪器仪表领域,市场主要被罗德与施瓦茨、安捷伦、安立、捷迪讯、艾法斯五大公司主导,国内虽然在TD-LTE终端测试产品方面具备一定的技术积累和产品实力,但是测试仪表方面和国际先进厂商相比仍存在着差距,并不能满足市场的要求［4］,因此研发出新型LTE-A空口监测和分析仪表刻不容缓［5－6］。NAS协议监测方案是LTE-A空口监测仪表中的重要组成部分,本文重点介绍了针对LTE-A空口NAS协议监测方案的设计和实现。整个NAS协议的监测方案设计包括了3 个组成部分: 整体方案、协议解码、CDR合成,文章最后通过所采集的LTE-A现网中的数据对所设计NAS协议监测方案进行了测试。
1 NAS协议监测方案设计
1. 1 NAS协议介绍
Uu接口是LTE - A网络中用户设备( User Equipment,UE) 与演进的通用陆地无线接入网( Evolved Universal Terrestrial Radio Access Network,E-UTRAN) 之间的接口,又被称为空中接口,简称空口。NAS协议［7］作为控制面最高层协议,主要作用是支持移动性管理( EPS Mobility Management,EMM) 功能和会话管理( EPS Session Management,ESM ) 。EMM过程主要是对用户当前所处的状态以及位置信息进行管理; ESM过程则主要是负责用户面承载的激活、修改和去激活,以及NAS信令的加密和完整性保护。NAS层协议栈的结构如图1 所示。
1. 2 NAS消息结构
根据3GPP协议可知,NAS消息结构分为两类: 明文消息结构和被安全保护的消息结构。明文消息的消息头由4 部分组成: 长度为1 /2 byte的安全头类型或EPS承载标识、长度为1 /2 byte的协议鉴别器、长度为1 byte的消息类型、需要情况下长度为1 byte的过程传输标识,明文消息结构如图2所示。
安全保护消息头由6 byte共4 部分组成: 长度为1 /2byte的安全头类型、长度为1 /2 byte的协议鉴别器、4 byte的消息认证码MAC以及1 byte的序列号SQN。消息结构如图3 所示。
1. 3 NAS协议监测方案设计
LTE- A空口监测仪表的主要构成单元有: 数据采集单元、信令处理单元以及应用分析等［8］。数据采集单元主要完成信令数据的采集和转发; 信令处理模块主要完成协议消息的识别、基础解码、详细解码以及合成,应用分析系统主要是在监测仪表中显示信令流程［9 － 11］。根据设计需求,NAS协议监测模块应该主要包括协议简单解码、详细解码和CDR合成等部分［12］,整个协议监测流程如图4 所示。
2 NAS协议解码
2. 1 解码模块介绍
在监测系统中,NAS协议解码模块主要目的是负责按照3GGP标准协议中所规定的NAS消息类型和数据格式对原本为二进制流的信令数据进行翻译,使其转化为直观且具有逻辑意义的信息［13］。所谓的详细解码是对NAS消息的原始数据进行以字节或者比特为单位的完全解码,能够在提取出NAS消息每个字段的详细信息的基础上对每个字段做简单说明,并且能够将解码结果和原始数据进行相关关联; 合成解码则主要是在原始消息数据中提取关键特征信息,为后续CDR合成调用做准备。
2. 2 解码流程设计
2. 2. 1 解码函数接口设计
针对NAS消息结构的特点设计NAS消息详细解码函数以及合成解码接口函数如下:
如表1 所示为解码过程中所需要的输入参数,以及解码输出参数。
2. 2. 2 解码流程
解码线程启动后,首先由解码模块从消息缓存中取出消息,然后由解码函数通过判断输入数据p Data、p Context、n Bit Len是否为空,以及n Bit Len是否为完整字节来判断待解码消息内容是否有效,如果输入数据为空值或者待解码原始数据比特长度不是完整的字节,则带解码数据无效。
详细解码和简单解码过程中分别需要结构体nas_detail_context和结构体nas _ summary _ context。 结构体nas _ detail _context中主要携带详细解码过程中所需要的位偏移量、承载消息类型、安全头类型、消息方向以及消息序列号等字段值,结构体nas_summary_context中主要携带NAS-PDU头指针、NAS-PDU长度、承载消息类型、安全头类型、消息方向以及消息序列号等参数。在解码进行的过程中,通过取首地址所指向字节的低4 比特值来判断消息类型,代码如下( 其中p Head为中间参数) :
当消息类型值为0x02 时,则该消息为ESM消息,执行函数NASFe Session Manage Decode( ) 对其进行解码; 当消息类型值为0X07 时,则该消息为EMM消息,对该消息进行解码需要执行函数NASMobile Manage Decode( ) 。在解码过程中,当消息为EMM消息时,则需要提取消息头中的字段: 安全头类型security header type和SQN,然后根据安全头类型的值来确定该消息是否被安全保护。对于EMM消息,需要根据安全头类型不同,分别对其进行处理( 若安全头类型为0xc0 表明当前消息为Service Request消息,协议显示其为非标准的层三消息,应该调用相应解码函数完成解码) 。NAS解码具体流程如图5 所示。
3 NAS协议CDR合成
CDR合成操作是对合成解码后得到的关键字段进行关联,然后对同一个用户的不同消息进行处理,以得到一个从信令建立到结束的完整通信业务流程的操作。对CDR合成操作后得到的指标进行统计,能够给上层应用监测提供可靠的依据。
3. 1 选择存储CDR缓存的数据结构
在CDR合成处理中,同一业务CDR的查找操作算法［14］非常重要。哈希表的思想是: 取关键字Key为自变量,通过设计特定的哈希函数f( ) ,然后计算出与其相对应的函数值f( Key) ,该值即关键字Key对应节点的存储地址,即哈希地址。查询操作过程是依据所取关键字Key,通过哈希函数f( Key) 计算得到对应节点在哈希表中的存储地址,从该地址取得其所存储的节点。对哈希表进行查询、插入和删除只需要对哈希链表中相应的节点进行,这样的查找方法快于大多数查找方法,因此在本课题中采用了哈希合成算法。
3. 2 超时检查设计
从消息缓存取到的一个通信流程的消息,从时间上来说应该是紧邻的。但是在现网中所采集的数据,往往会存在通信异常、采集遗漏或采集后处理不及时等情况而导致通信流程非正常结束。如果不对这些不完整流程的数据进行处理,则会导致哈希表中节点的冗余、资源浪费以及因为内存泄漏给系统带来不稳定性。
基于以上原因,在读取一条消息的时候,首先要对其做超时检查处理,若当前消息超时,则删除哈希表中存储的超时节点,以避免因查询不必要的Key值而导致的低效率问题,以及Hash表内存空间的浪费和冗余而导致内存泄漏。
3. 3 CDR合成实现
CDR合成的基础是简单解码,CDR合成的关键信息由简单解码所提供。合成模块触发以后首先在简单解码结果表中获取关键字段值; 然后再检查缓存中的CDR超时情况,如果存在超时,则对超时的CDR进行处理。
进行超时检查以后,需要在合成模块的CDR buffer中查找是否有与当前Key值所对应的CDR存在; 如果该CDR存在,则在合成buffer区域中找到与当前CDR ID值相对应的CDR,然后利用简单解码的结果来更新该CDR; 如果该CDR不存在,则需要在合成buffer区域内插入对应的Key值,并创建新的CDR,然后再为新的CDR分配一个CDR ID值,同时在对应的CDR属性表中填入简单解码结果。完成更新以后,对CDR是否结束进行判断; 如果当前CDR合成已经结束,则关闭当前CDR,然后删除超时节点,结束当前流程; 如果合成没有结束,则重新设置CDR超时时间并将所设置的时间放入合成模块的CDR buffer中,然后重复下一条消息。合成流程如图6 所示。
4 测试结果及分析
4. 1 解码结果分析
详细解码结果以树形结构呈现。每个解码结果项的内容包括了字段名称、字段值、具体含义解析、位掩码值等4 项内容。在此以安全模式命令消息SECURITY MODE COMMAND为例,展示了如图7 所示的中文解码结果。
通过截图可以看见,当前NAS消息长度为13 byte,具体内容为: 安全头类型Security header type值为3,表示当前消息的安全类型为新EPS安全上下文完整性保护( 此码位值仅用于SECURITY MODE COMMAND消息) ; 协议鉴别器Protocol discriminator值为7,表示消息为EMM消息; 消息类型Message type为0x5d表示当前消息为安全模式命令SECURITY MODE COMMAND消息; 通过图中的解码结果还可以知道,该UE支持EPS加密算法以及EPS完整性保护算法,而且前加密算法类型为128-EEA1、完整性保护算法类型为128-EIA1。
利用3GPP标准协议将原始数据和解码结果进行比对,发现解码结果完整且正确。同时通过详细解码结果( 见图7) 可以看到原始NAS PDU为37BC31F1A100075D1100024060,这与图8 中所示的Wireshark解码结果一致。
4. 2 合成结果分析
图9 所示为一次成功的鉴权过程。鉴权过程首先由网络侧向用户侧发起,当用户侧收到网络端发起的鉴权请求以后,给网络侧返回一个鉴权响应。实际通信流程合成如图9 所示,由IP: 192. 168. 124. 128 向IP: 192. 168.124 . 131 发起鉴权请求AUTHENTICATION REQUEST消息,当IP: 192. 168. 124. 131 收到IP: 192. 168. 124. 128发送的AUTHENTICATION REQUEST消息以后,返回给IP: 192 . 168 . 124 . 128 AUTHENTICATION RESPONSE鉴权响应消息。
5 小结
锅炉水质监测协议 篇2
乙方：_________
根据国家质量技术监督局[1999]号文《锅炉水处理管理规则》和_________有关要求，为进一步落实水质监测工作的正常运行，确保锅炉安全经济运行。经双方协商，甲方同意委托乙方对甲方锅炉水质开展监测工作，订立以下协议，双方应严格遵守执行。
一、甲方责任
1、锅炉水处理（包括设备，人员和管理）应能保证水质符合gb1576《工业锅炉水质》的规定，确保锅炉无垢或薄垢运行。
2、甲方应根据锅炉相关法规要求，配备相应的水处理设备，锅水取样器，持证水处理操作人员。
3、根据乙方出具的水质监测报告，对不合格水质立即整改，处理，直至合格。在整改处理期间采用炉内加药处理，确保水质达标。配合乙方做好取水样工作。
二、乙方责任
1、乙方每月到甲方取水样一次，并在24小时内化验，出具水质监测报告。
2、对水质不合格的单位，派人现场指导，分析原因，提出整改措施。每年免费调试2次，超出次数只收取调试人员交通费（按往返里程_________元／公里）及旅差补助（_________元／人·天）。如属甲方水处理设备陈旧或严重损坏，由甲方维修或更换设备后，再进行调试。
3、如甲方需要，乙方可对不合格水处理设备进行维修，维修另签合同。
三、监测收费
1、乙方向甲方收取水质化验费_________元／次，取水样交通费_________元／次，取水样人员旅差费_________元／次，全年费用按11个月一次性收取，全年收费共计_________元（_________元）。
2、合同签订时支付水质监测费（收款单位：_________，开户行：_________，账号：_________）
四、其他
1、本合同一式二份，甲，乙双方各执一份。
2、本合同自签订之日起生效，有效期自_________年_________月_________日至_________年_________月_________日止。
甲方（公章）：_________乙方（公章）：_________
代表（签字）：_________代表（签字）：_________
协议监测 篇3
随着IP网络的快速发展,IP网提供的业务越来越多, 用户对业务需求也逐渐增加。同时,原有的电路交换网仍然拥有大量的用户,为了能让这些用户使用IP网络提供的服务,需要提供不同网络之间互通的网关设备[1~2]。然而,原始的集中型网关结构在可扩展性、安全性方面及组网的灵活性上都存在极大的限制。因此,将业务、控制和信令分离的概念提出,即将IP电话网关分离成三部分: 信令网关SG、媒体网关MG和媒体网关控制器MGC。其中,SG负责处理信令消息,将其终结、翻译或中继;MG负责处理媒体流,将媒体流从窄带网打包送到IP网或者从IP网接收后解包后送给窄带网;MGC负责MG的资源的注册和管理,以及呼叫控制。其中,媒体网关控制器 (MGC)和媒体网关(MG)之间的通信我们采用H.248/ Megaco协议(Media Gateway Control Proocol),简称H.248协议[2]。H.248协议为保证RTP语音流顺利进行通信起着关键作用,因此对该协议进行监测显得尤为重要。通过对H.248协议数据的监测,我们能实时了解媒体网关控制器(MGC)和媒体网关(MG)之间的通信,同时对发生的通信故障进行及时排查和分析。本文在对H.248协议进行监测的同时,也实现了对合成算法的优化。
2 H.248协议概述
2.1 H.248协议特点
H.248协议是由IETF、ITU-T制定的媒体网关控制协议,是一个非对等的协议[2]。H.248信令消息承载主要分为两种类型:IP网络承载和ATM承载。本文是基于IP网络承载的监测,协议栈及通信如图1。
如图1,H.248协议之间的通信建立在MSC Server与MGW之间。其中,H.248协议的承载协议依次为:层1 (Physical Layer),MAC层(Link Layer),IP层,SCTP层。解码将根据承载协议顺序进行,逐层解码。
2.2 H.248协议消息格式
H.248的消息都有相同的结构,消息有一个消息头,消息头里面包含一个消息的MID(Message ID) 和一个协议版本号。一个消息(Message)包含多个事务 (Transaction),消息中的事务相互没有关系,可以单独处理;事务由多个行动(Action)构成,事务里面的行动必须按照顺序执行。行动由一系列局限于一个上下文的多个命令组成[3]。具体消息格式如图2。
消息:从消息头(Header)开始,后面是若干个事务。消息头中包含消息标识符(MID,Message Identifier)和版本字段:MID标识消息的发送者,可以是域地址、域名或设备名,一般采用域名;版本字段用于标识消息遵守的协议版本,版本字段有1位或2位数,目前版本为1。一个消息(Message)包含一个或多个事务 (Transaction),消息内的事务是相互独立的,当多个被独立处理时,消息没有规定处理的先后次序。
事务:包括请求和响应两种类型,而响应也有两种:Transaction Reply和Transaction Pending。由于命令封装在Transaction Request事务中,我们在此仅对请求事务结构进行介绍。响应事务结构我们将在下一节介绍。每个Transaction Request请求激发一个事务。一个事务包含一个到多个动作,每个动作包含一系列与同一个Context相关的一个到多个命令。
动作:动作与关联(Context)是密切相关的,动作由ContextID进行标识。在一个动作内,命令需要顺序执行。一个动作从关联头部(CtxHdr)开始,在CtxHdr包含ontextID,用于标识该动作对应的关联。ContextID由MG指定,在MG范围内是唯一的。MGC必须在以后的与此关联相关的事务中使用相同的ContextID。在CtxHdr后面是若干命令,这些命令都与ContextID标识的关联相关。
命令:命令是H.248消息的主要内容,实现对关联和终端属性的控制,包括指定终端报告检测到的事件,通知终端使用什么信号和动作,以及指定关联的拓扑结构等, 命令由命令头部(CMDHdr)与命令参数构成,在H.248协议中,命令参数被组织成“描述符”(Descriptor)。
3 H.248协议解码
通过对原始数据的分析,H.248协议中的消息字段为TLV格式,如图3:
其中,Tag表示消息字段标识;Length表示本字段值长度;Value为本字段具体内容,Value的长度在Length部分已经给出。
H.248协议承载于SCTP协议之上,如图2。我们采用逐层解码的方式对包含H.248的数据包进行解码。各层协议之间我们通过端口号进行关联,这保证了解码H.248消息的可靠性。在解码的同时,我们将IP层中的源、目的IP,UDP中的源、目的端口号均传入H.248中,为合成建立哈希表做准备工作。解码主要分为简单解码,详细解码以及合成解码[4]。简单解码主要实现的是监测系统过滤, 关键信息显示等功能;详细解码的作用是列表实现全字段信息显示;合成解码的作用是将解码中的关键信息提交给CDR合成做操作。基础解码为静态链接库,其实现需要靠解码器调用。在H.248协议层,由于H.248协议里面的消息字段为TLV格式,我们可以对比原始数据,按照字段的标准格式将数据解码出来。Tag表明了一个新的字段开始;Length说明了后面Value的长度,占一个字节;Value则说明了该字段的数值。具体解码流程如图4:
4 CDR合成基本原理及实现方法
4.1 H.248合成原理及流程
CDR合成主要是根据一些关键参数的查找、匹配来确定是否属于同一个消息流程,通过对关键参数的判断得到传入的消息是否属于同一个CDR,然后建立关联[5]。CDR合成是实现通信监测结果统计以及网络性能测试的基础,对网络中的消息按归属不同的呼叫流程进行归类,并用哈希索引将属于同一个呼叫的消息关联到一起,以便于完成诸如呼叫合成和呼损统计等各项高级功能。合成过程中,需要对采集到的每条消息进行分类,得到完整的CDR。
在进行CDR合成处理时,我们首先通过回调函数Handle获取解码的协议类型,接着定义了一个Callinfo类对象,用来存放从解码器中所取得的对应消息字段和协议类型;通过调用BuildCallInfo函数,将解码器中的合成所需字段填入到CallInfo中;在调用成功的前提下,将该条CDR的时间及消息号填入CallInfo中;然后再进行判断线程操作,如果是多线程,将CallInfo中的消息字段排队,等候入队;若是单线程,提取CallInfo中的协议类型,调用不同协议的处理函数。协议的处理函数通过判断CallInfo中取到的MsgType来判断为该协议的何种类型消息,最后再调用对应的处理函数HandleH248,此函数存储CDR数据和触发出表。具体流程如图5。
由于现网测试时,接收到的数据量很大,要保证实时性监测就必须使用一种快速有效的算法。
4.2 H.248协议的合成算法
随着通信网络的发展,CDR合成处理效率的提高显得尤为重要。为达到提高CDR合成效率的目的,我们需要根据协议及消息类型构造合适的哈希函数。在构造哈希散列函数时,我们需要考虑的是以下三方面问题:第一,哈希桶大小的设置;第二,哈希码值key如何选取更易构建哈希散列函数;第三,哈希散列函数的构造。本文针对这三个问题提出了适用于本监测的解决方法。
设置一个合适的哈希桶个数,这样既能保证不浪费内存空间,又能尽量减少哈希冲突。哈希桶的选取主要取决于小区同一时刻的下载人数,由于同一个小区的下载人数在变化,我们无法得出哈希桶的大小,故在本文中,我们选取的方法为:首先根据数据量(即抽查多个时刻得到的下载人数)来设置一个哈希桶个数,然后在监测过程中,通过当前众数(下载人数出现次数最多)与平均数最接近时刻的数据量来设置哈希桶的容量。
设小区在n个不同时刻的下载人数分别为x1 ,x2 ,…, xm ,…,x n, 其中xm为本组数据的众数,本组数据的平均数为
若xm趋于则此时的哈希桶容量为H(s)= xm ,否则,去除包含xm的数据后,重新选择一个众数,进行上述操作的判断;最后选取一个最优的数据值设置为哈希桶容量。
哈希散列函数的构造为CDR合成起着关键作用。哈希散列函数的构造主要有直接寻址法、数字分析法、平方取中法、折叠法、随机数法、除留余数法[6]等,本文选取除留余数法,通过哈希散列函数的构造以提高数据处理的效率。
在H.248协议中,为实现一个完整的消息流程,我们需要建立多张哈希表,建立多个哈希关联。主要有关联 (Context)哈希,终端(Terminate)哈希和事务(Trasaction)哈希。
对于关联哈希,我们建立的哈希关联为:
H(key)=((key.m_unDstIP^key.m_unSrcIP) + key.m_ unContextID) mod m (2)
对于终端哈希,我们建立的哈希关联为:
H(key)=((key.m_unDstIP^key.m_unSrcIP) + (nValue << 5) - nValue + key.m_chTerminID) mod m (3)
对于事务哈希,我们建立的哈希关联为:
H(key)=((key.m_unDstIP^key.m_unSrcIP) + key.m_ unTransactionID) mod m (4)
Addr = H(Key) (5)
其中m为认证哈希表容量,Addr为消息存储地址。
通过构造哈希散列函数公式,将进入的每一个消息尽量发散地分布至各哈希桶中。减少了哈希冲突,提高了CDR处理效率。
5 监测结果图
此研究方案已应用于重庆重邮汇测通信技术有限公司的NGN监测系统中,部署于北京瑞安公司的IP承载网项目语音信令解析设备监测系统中,取得了良好的效果, CDR合成结果如图6。
图6显示了一个完整的H.248消息流程。其中10.208.145.13为MSC Server,10.208.145.148为MGW。
6 结论
协议监测 篇4
根据矿井下的环境参数, 构建无线传感器监测网络, 将其与有线监测网络相结合, 形成矿井安全监测信息综合系统, 这将有效地提高矿井安全监测的覆盖范围, 完善监测数据的准确性[4,5]。路由协议作为无线传感器网络的重要环节, 关系着数据能否有效传输。而能量约束一直是无线传感器网络存在的一个问题[6,7], 为了延长网络生命周期和提高监控质量, 设计适用于矿井下环境的能量高效的路由协议十分必要。井下无线传感器网络拓扑呈长距离带状存在, 存在各节点能耗不均、数据冗长和延迟的问题。随着工作面的不断推进, 网络结构会发生变化。针对矿井这种特殊环境, 根据无线传感器监测网络的网络特点和通信需求, 提出一种适合矿井安全监测的路由协议—基于虚拟栅格的簇头多跳路由协议CHM-VG (cluster heads multi-hops protocol based on virtual grid) 。
1 协议模型
1.1 矿井结构模型
矿井是在地底下开采的矿山, 有时把矿山地下开拓中的斜井、竖井、平硐等也称为矿井。矿井开拓中会从地面向地下开掘一系列井巷, 最终通至采区, 即综采工作面。在此过程中, 需要正确划分井田, 选择合理的开拓方式, 确定矿井的生产能力, 按标高划分开采水平, 选择适当的通风方式, 进行采区部署以及决定采区开采的顺序等[8]。最终整体矿井结构可以描述为矿井巷道联通几个综采工作面, 如图1所示。图中是某矿井的三维立体图, 可以看出1057和1068两个综采工作面由纵横交错的黄、绿、蓝巷道连接通往地面。
这些巷道均呈长距离带状形态, 因此根据巷道的分布特点构建出如图2的模型。本文将巷道模拟成宽很小而长很长的矩形, 每个综采工作面都与若干这样的矩形相连, 最终通向地面。在这些巷道中布置传感器节点, 这些节点连接成网络, 从而可以对矿井下的工作环境进行检测, 将检测的信息及时准确地传送到地面主控机。
1.2 能量损耗模型
在无线传感器网络中, 能量约束是需要首要考虑的一个问题。路由算法的设计与信道能量损耗模型有着密不可分的关系[9]。通用信道损耗模型如图3所示。其中功率放大器是补偿路径损耗的, 用来保证信号到达目标节点时的信噪比达到接收机达到接收的值。因此当发射a bits数据, 传输距离为d时, 发射机消耗的能量为:
式 (1) 中, ETx-elec (a) 表示发射a bits数据时发射电路的能量消耗, ETx-amp (a, d) 表示发射a bits数据, 传输距离为d时功率放大器的能量消耗。可以看出能量损耗是与传输距离有关的。传输距离的门限值do为
式 (2) 中, Efs表示自由空间传输的能量, Emp为多路径衰落传输的能量。这里设定参数Efs=10 p J/ (bit·m-2) , Emp=0.001 3 p J/ (bit·m-4) 。当数据传输距离d
接收机接收a bits数据消耗的能量为
簇头节点进行数据融合时, 处理1 bit数据消耗的能量为EDA。这里设定参数EDA=5 n J/ (bit·sigal-1) , Eelec=50 n J/bit。
2 Leach协议局限性
在Leach[10,11]中, 被选为簇头的节点将直接与基站通信, 而由于矿井巷道长距离带状分布的特点, 离地面基站距离较远的簇头节点会消耗过多能量, 造成远距离的节点容易死亡, 整个网络的能量消耗不平衡, 从而减少了网络的生命周期。而当簇头节点与基站距离超过传感器节点的通信半径时, 簇头节点无法将数据传送到基站, 这样会造成无法监控离基站较远的矿井环境[12]。
我们选取一个100 m×1 000 m的长矩形区域对Leach协议进行仿真, 在区域内分别布置总数为100个、200个和300个传感器节点, 观察Leach协议的性能, 结果如图4所示。
从图4中可以看出, 无论节点总数是100个、200个还是300个, 前10轮的节点死亡率都在50%左右, 到第100轮, 节点的死亡率都超过了80%。由于节点能量消耗不平衡, 剩余节点即使还有能量, 也无法正常将数据传送到基站。因此Leach协议不适用于矿井巷道这种长矩形的区域。
3 CHM-VG协议工作过程
3.1 簇的划分
从公式 (3) 可以看出, 当节点间传输距离大于do时, 路径损耗指数n=4, 能量消耗会比较大。所以为了减少能量消耗, 延长整个网络的生命周期, 我们应该使节点间传输距离小于do。因此首先我们设置一个距离参数r (r
3.2 簇头的选举
在簇头的选举中我们综合考虑以下两个方面内容:一是选择剩余能量大于簇内平均剩余能量的节点, 二是选择离簇内节点质心最近的节点。
我们首先规定质心的定义。设质心坐标为 (x, y) , 一个簇内有N个节点, 各节点坐标为 (xi, yi) , i=1, 2, …, N。令取最小值, 解得。则簇内节点质心坐标为。选择离簇内节点质心最近的节点为簇头, 则簇内各节点到簇头距离和最小, 使得簇内整体消耗能量最小。
地面基站向巷道内节点广播完距离参数r和每个簇内节点质心, 所有节点依据自己位置找到所属区域, 识别了所属区域簇内节点质心后, 这时离该簇内节点质心最近的节点当选为该簇的簇头节点。簇内节点在向簇头发送数据的同时一并发送自己的剩余能量和坐标信息。在新一轮的簇头选举时, 簇头计算簇内平均剩余能量, 在簇内剩余能量大于平均剩余能量的节点中选取离簇内节点质心最近的节点, 之后通知该节点成为新的簇头节点。这样选取的簇头平均了簇内节点的能量消耗, 同时保证了簇内整体消耗能量最小。
4 实验仿真与分析
4.1 实验参数设置
在仿真实验中, 模拟一个100 m×1 000 m的长矩形巷道, 分别分配100个、200个和300个传感器节点, 随机分布在巷道中。每个传感器节点的初始能量为0.25 J。设定地面基站的坐标为 (0, 50) 。用MATLAB仿真巷道模型如图5所示。该图为100个传感器节点随机分布在100 m×1 000 m长矩形巷道的结果, 共分成了13个虚拟栅格, 其中距离参数r=80 m。
设定各传感器节点每次传输4 000 bit大小的数据包。簇头节点能量消耗包括数据接收, 数据融合以及将融合后数据发送至其他簇头节点。其中, 用于数据接收的能耗为50 n J/bit, 用于数据融合处理的能耗为5 n J/bitsignal-1, 用于远距离传输的功率放大系数为100 p J/ (bit·m-2) 。普通节点能量消耗是将收集到的数据传送到簇头节点的能耗[13]。
4.2 网络生命周期
第一个节点死亡 (电量耗尽) 时间和节点全部死亡时间这两个关键参数体现着网络的生命周期;而网络的生命周期正是衡量网络质量的一个重要标准[14]。利用MATLAB平台仿真模拟, 结果证明:与原有Leach协议相比较, CHM-VG协议更加适合矿井下的无线传感器监测网络。首先, 依据能量损耗模型, 设定距离参数划分虚拟栅格, 使簇内传输距离限定在门限值内, 降低节点传输能量损耗。其次, 综合考虑平均能量和簇内其他节点传输距离两方面因素选取簇头节点, 平衡了簇内节点的能量消耗。最后, 簇头间采取多跳方式传输数据, 平衡了整个网络的能量消耗, 从而使网络的生命周期有效地延长。图6~图8分别为模拟100 m×1 000 m的长矩形巷道中布置100个、200个和300个传感器节点的仿真结果。从图中可以看出, 在这三种场景下, Leach协议在前100轮节点死亡数急剧上升, 而CHM-VG协议在前100轮内没有节点死亡, 网络性能十分良好。
两个关键参数第一个节点死亡 (电量耗尽) 时间和节点全部死亡时间的对比结果如图9所示。在布置100个传感器的场景一中, Leach协议第一个节点的死亡时间为7轮, 而CHM-VG协议第一个节点的死亡时间为503轮, Leach协议节点全部死亡的时间为602轮, 而CHM-VG协议节点全部死亡的时间为1 237轮。在布置200个传感器的场景二中, Leach协议第一个节点的死亡时间为9轮, 而CHM-VG协议第一个节点的死亡时间为534轮, Leach协议节点全部死亡的时间为798轮, 而CHM-VG协议节点全部死亡的时间为1 243轮。在布置300个传感器的场景三中, Leach协议第一个节点的死亡时间为14轮, 而CHM-VG协议第一个节点的死亡时间为600轮, Leach协议节点全部死亡的时间为824轮, 而CHM-VG协议节点全部死亡的时间为1 250轮。从对比结果可以看出, CHM-VG协议相对于Leach协议, 第一个节点的死亡时间和节点全部死亡时间都明显增加, 对于网络的生命周期, 这些数据正是衡量的重要指标, 说明CHM-VG协议使得网络的生命周期稳定增加。
4.3 信息传输的有效性
Leach协议中簇头节点的选择是概率随机的, 没有考虑到与地面基站的距离。由于矿井巷道的特殊环境, 当簇头节点距离基站较远时, 容易与外界失去联系, 造成数据不能正常传输。而CHM-VG协议选择簇头多跳的方式进行数据传输, 可以保证数据有效地传输到基站。实验结果表明, 在场景一中的网络生命周期内, 所有簇首节点共接收到430 476 000 bit大小的数据, 每个簇首节点经过数据融合后利用多跳的方式传送到基站, 基站共接收到64 324 000 bit大小的数据, 数据传输比较稳定。
5 小结
协议监测 篇5
利用成熟的视频监控技术, 对车站的站场、机房、关键设备进行实时监控, 当设备发生故障的时候, 能够自动控制摄像头指向故障设备, 利用互联网将有关故障信息和报警信息上传至控制中心, 大大减轻日常人员巡视的工作量, 便于及时发现危险隐患、远程指挥处理故障, 保障列车运行安全, 提高运输效率。
1 信号微机监测系统发展简史
信号微机监测系统的发展可以追溯到1985年。当时, 计算机和通信技术都有了长足的发展, 计算机在现场的应用也比较广泛。在计算机技术的支持下, 有些铁路局将微机监测系统开发提到议事日程上来, 并很快付诸了实践。短短的一年之后, 已有20多家单位开始研制, 一些车站认识到了微机监测系统的先进性, 也先后配备了该系统。截止1996年底, 有200多个车站拥有自己的微机监测系统。
相比较, 最初的微机监测系统, 由各铁路局自行研制, 缺乏统一标准, 技术差异较大, 另外, 受技术、经济等方面的限制, 系统精度不高, 可靠性差, 运行状况不佳, 各站之间处于独立状态, 几乎没有集中联网。
经过一年的发展, 信号微机监测技术发展很快, 铁路上级部门也高度重视其发展。1997年, 原铁道部两次对信号微机监测系统进行了大规模调研, 并制定了技术原则, 组织专家和技术人员联合攻关, 研制开发了第一代TJWX-97型信号微机监测系统, 这一系统最初推广应用的范围是五大干线, 为监督、衡量电务设备运行状况和维护铁路运输安全做出了贡献。
第一代信号微机监测系统在五大干线推广应用后, 原铁道部和各铁路局对信号微机监测系统的重要性有了新的认识。因此, 原铁道部在2000年初明确提出:信号微机监测系统是保证铁路运输安全的首要措施, 并将其按行车安全设备对待。因此, 微机监测系统也有电务系统的“黑匣子”之称。
原铁道部2006年3月新公布的《信号微机监测系统技术条件》, 对微机监测系统有了更高要求。对微机监测系统的测试精度、稳定性都重新做了规定。2006年TJWX-2006型信号微机监测系统问世。该系统采用DSP数字信号处理技术, 提高了测试精度和稳定性, 增加并完善了监测内容, 增强了可靠性。
随着铁路运营规模的不断扩大和互联网技术的迅速发展, 信号微机监测系统向智能化、网络化、专家系统方向不断完善和发展, 并同调度集中系统、列车运行控制系统和运输信息管理系统汇接合成, 更好地为铁路运输服务。
2 微机监测系统的结构
2.1 总体结构
微机监测系统结构采用基于TCP/IP协议的广域网模式, 层次化和结构化的系统配置和数据通信是微机监测系统的结构特点。微机监测系统是铁路总公司、铁路局、电务段;铁路总公司电务监测中心、铁路局电务监测中心、电务段监测中心、车站监测网的“三级四层”的结构。这是完全按照电务部门监测、维修、维护、管理的实际需要划分的, 其结构如图1所示。
2.2 电务处调看中心
电务处调看中心配置远程调看终端, 用于查看车站信息。电务处调看中心终端可以调看全局的联网车站, 实时查看车站信号设备的工作状态及视频信息, 回放站场存储信息、视频信息和报表信息, 显示车站设备故障信息, 远程进行故障诊断分析查看。
2.3 电务段中心
电务段监测中心是整个网络系统的中枢部分, 是电务段管内各站的数据和网络通信的管理中心。整个系统以电务段中心为集中管理、监控的中心, 包括应用服务器和网络设备。
2.4 车间终端和段终端
车间终端、段终端可以调看权限范围内的联网车站, 实时查看车站信号设备的工作状态及视频信息, 回放站场存储信息、视频信息和报表信息, 显示车站设备故障信息, 远程进行故障诊断分析查看。
2.5 车站系统
车站系统是微机监测系统的基础部分, 可实现采集数据、分析数据、处理数据和存储数据的功能。车站、区间信号设备的状态监测、故障数据和曲线显示、查看、分析、人机对话也都依靠车站系统。车站系统包括站机、采集机、视频服务器、视频监控终端、网络视频编码器、无线网桥、摄像机、网络设备等。
采集机和站机是整个微机检测系统的基础, 所有信号设备的原始数据均来自于采集机、站机, 所以对它们的要求是相当高的。最低要求是, 系统主机能够稳定、可靠的工作;采集机必须精确地从各信号设备处采集信息。视频服务器接收室外固定摄像机、室内固定摄像机和移动摄像机的视频信息, 对信息进行处理和存储, 向远程终端提供视频信息。并通过与站机共享设备故障信息, 进行报警联动, 实现摄像头的自动控制。
3 通信网络技术要求
3.1 局域网
在统一、安全、可靠、方便管理的原则下设计局域网。标准采用以太网技术标准, 并采用TCP/IP协议、RJ45接口标准, 有线传输介质为5类或超5类非屏蔽双绞线。受地理条件等外界因素影响的地方, 可采用标准为802.11/b/g/n无线局域网标准, 通过无线或有线与无线相结合的局域网方式进行连接。
3.2 广域网
广域网利用铁路基础通信平台, 采用TCP/IP协议, 为防止地址冲突, IP地址分配时全路统一编码, 以便微机监测全路联网。广域网传输通道的传输速率不低于2Mbps, 误码率≤10-7。
4 系统功能
4.1 常规监测数据采集
系统具有常规的监测功能, 集中处理从各种采集机采集的实时信息, 并进行显示和存储, 同时又为操作人员提供人机界面。根据对信号设备监测的结果, 人机界面实现车站作业状态及设备运行状态的实时显示和各种数据的查询功能。
常规监测通过接口与其他系统互通信息, 可以通过接口采集其他智能设备信息, 也可以通过接口向其他系统提供微机监测的信息。
4.2 实时、可靠、高精度信息采集
实时可靠的数据是微机监测系统能够发挥作用的基础, 如果没有实时可靠的数据, 再先进的系统都无法做出正确地分析和诊断。因此微机监测系统在采集数据时保证监测数据的实时、可靠和高精度。通过对开关量信息的高速、动态采样保证开关量数据的实时和可靠, 通过提高传感器和采集电路的精度, 使用DSP技术对采集数据进行高速处理, 保证采集信息的实时和高精度。
4.2.1 开关量采集
开关量采集中采取了高速动态信号采样的方法, 每3毫秒对采集信号作一次采样, 连续10次采样作为一个周期, 如果在一次周期内所采的信号既有高电平也有低电平, 说明这个信号是处于动态变化中, 这时才认为这个信号是有效地。每个采集板包括两套独立的采样电路, 即每一路信号通过两套采样电路分别采集, CPU通过对两套采样电路采集信息的比较来确定采样信息的有效性。
4.2.2 常规模拟量采集
监测系统对模拟量采集精度的要求越来越高, 为满足这一要求采取了以下几个主要措施:
(1) 选用高精度低漂移的传感器;
(2) 提高调整电路中的元件精度, 如选用高精度 (+0.5%) 低温漂 (50ppm) 电阻器;
(3) 对于传输距离较远的信号采用4~20m A电流环传输;
(4) 对容易受到干扰的小信号采用屏蔽双绞线传输信号。
采取以上措施, 保证模拟量采集过程中获得预期的模拟量精度。
4.3 显示及存储
显示和存储的主要信息包括:可实时显示与回放站场运用状态图;可以查看开关量的实时和历史状态;转辙机动作电流、功率、转换力曲线;道岔表示电压变化曲线;电源屏电压、电流、功率等实时值和曲线;控制台按钮操作记录;关键设备动作次数及时间表;测试电缆绝缘和电源对地漏泄电流;轨道电路分路残压测试报表记录等。
模拟量数据可以通过实时测试值表格、历史值表格、日报表、实时曲线、日曲线、月曲线、年趋势线等表现形式。
所有数据存储以滚动方式进行, 存储时间要求为大站不少于3天, 小站不小于10天。
4.4 数据处理及控制
微机监测系统的数据通过优盘、移动硬盘等移动存储工具进行导出和存储。系统本身提供的回放工具可以多历史数据进行回放。通过回放功能用户可以很方便的调阅历史数据进行分析。同时, 用户对存储的再现文件可以进行管理。微机监测系统对数据以曲线和报表2种方式进行输出。无论曲线还是报表都可以进行打印。除此之外, 曲线可以bmp、jpg的格式导出为图形文件。报表可以excel的文件形式导出方便用户资料的采集及调阅以及上级部门的管理。另外, 通过系统功能可以对用户权限、密码进行管理, 授权用户可以对电气特性参数和报警上下限进行调整, 还可以根据个人偏好和使用习惯对菜单栏和工具栏进行设置。
4.5 智能诊断
系统具有智能诊断功能, 能够利用实时采集的控制台状态数据、开关量和模拟量测试数据进行综合分析, 加强对信号设备的运行质量分析、设备故障分析定位功能, 充分发挥计算机强大的数据运算分析能力。大幅度提高了信号设备管理的针对性、准确性、时效性和管理效率[4]。
摘要：铁路信号微机集中监测系统可以保证行车安全、管理信号设备的结合部分。新技术条件下的微机监测系统采用“三级四层”的网络架构, 各层之间以基于TCP/IP协议的广域网连接。可以实现对信号设备运行状态的监测, 发现信号设备存在的隐患, 并分析信号设备产生故障的原因, 在故障处理时起到辅助作用。在现场可以在微机监测系统指导下进行维修, 并通过微机监测系统衡量信号设备运用质量, 最终提高信号设备的维护水平和维护效率。
关键词：微机监测,行车安全,三级四层结构,TCP/IP协议
参考文献
[1]夏国生.TJWX-2000型微机监测系统故障分析[J].电子科技, 2012 (7) :35-36, 42.
[2]陈关喜.信号微机监测信息系统平台的应用[J].铁道通信信号, 2008 (2) :29-31.
[3]俞鹏.网络话务控制[J].中国新通信, 2007 (1) :41-43.
协议监测 篇6
关键词：RMTP,无线电监测,台站互连,数据共享
0 引言
当前我国各地均建设了一定数量的无线电监测台站和监测网。由于建设时间、站点规划、配套资金等多方面原因, 台站设备不可避免地采购自国内外多个厂家。不同厂家集成的监测系统自成体系, 自行组网, 相互之间无法互连互通, 监测数据无法共享通用和融合处理, 严重制约了监测台站的效能发挥和频谱管理的有效性。
为了解决这一问题, 国家无线电监测中心组织编写了RMTP协议, 即无线电监测网传输协议 (Radio Moni-toring Transfer Protocol) 。通过适配该协议, 不同的无线电监测台站可以接入同一个无线电监测网, 各级监测控制中心可以管理控制网内所属各型监测台站, 从而实现不同的监测台站间的联合监测和数据共享, 达到装备最大化使用效益。
1 当前的无线电监测台站组网情况
当前的无线电监测台站组网情况如图1 所示, 各厂家集成的监测台站自行组网, 各有自己的监测控制软件, 各监测子网之间相互不能联通, 监测数据不能共享互用。
2 RMTP协议
目前RMTP协议的最新版本是RMTP:VERSION:01.01[1], RMTP协议通常包括服务端软件和客户端软件。RMTP服务端软件一般安装在各类监测执行站上, RMTP客户端软件通常部署在各级监测控制中心, 也可以安装在任何一台联网的可发出RMTP指令的计算机上。客户端通过RMTP指令向服务端下达监测任务, 服务端根据收到的监测指令控制监测接收机执行相应的监测任务, 并将接收机送来的监测数据打包成RMTP数据报再发往客户端。
RMTP指令包括业务功能指令和非业务功能指令两大类。业务功能指令指客户端发出连接请求、服务端能返回业务数据的指令, 又可分为监测指令和非监测指令。监测指令由客户端发往服务端, 服务端在收到一条监测指令后, 启动具体的监测接收机进行一次监测活动, 并将取得的监测数据打包成RMTP数据报发往客户端。非监测指令主要用于客户端查询监测接收机的运行状态、经度纬度、时间统计等状态值。非业务功能指令不需要发起连接, 在测量过程中发出有效指令即可。常用的RMTP协议指令见表1。
在RMTP协议通信过程中, 服务端必须先于客户端启动。任何符合RMTP协议的客户端都可以向网内任一服务端发出RMTP指令, 并通过RMTP协议接口获得相应的数据和结果。
3 基于RMTP协议的监测台站互连
各设备厂家集成的监测台站都包括监测接收机、监测服务端、监测控制软件和监测数据库[2]。为了实现各型监测台站的互连互通, 必须对各监测台站的监测服务端进行RMTP协议适配, 使之能够接收RMTP指令并控制监测接收机执行相应操作。为了实现对各型监测台站的集中控制和监测数据的融合处理, 必须开发全新的监测控制中心软件和监测数据库。该监测控制中心软件和监测数据库可以安装在网内任一台计算机上, 并可通过局域网控制连网的任一监测台站, 取得监测数据[3]。
以中星世通固定监测站和九华圆通车载监测站为例, 两型监测站通过RMTP协议进行网络连接的方式如图2 所示。
监测控制中心软件是整个无线电监测网的核心和枢纽, 可以对全网的监测台站进行集中统一的控制和调用, 并采集全网各台站的监测数据入库, 建立统一的频谱监测数据库[4]。监测控制中心软件并可设计监测任务管理、频谱实时显示、频谱占用度统计、监测数据查询统计等常用功能。
通过RMTP协议, 各监测台站实现互连互通, 整个监测网络受统一的监测控制中心软件控制调用, 监测数据共享通用, 便于融合处理[5], 其组网情况如图3 所示。
4 结语
随着无线电技术的飞速发展和无线电业务的广泛应用, 无线电频率资源的供需矛盾日益突出, 无线电监测的重要性越发凸显。如何充分利用RMTP协议, 构建台站互连、数据共享、信息融合的无线电监测网, 是值得深入研究并大力践行的。
参考文献
[1]国家无线电监测中心.无线电监测网传输协议 (RMTP:VERSION:01.01) [M].北京:国家无线电监测中心, 2008.
[2]成都九华圆通科技发展有限公司.圆通综合频谱监测车技术说明书[M].成都:成都九华圆通科技发展有限公司, 2007.
[3]成都中星世通电子科技有限公司.中星世通宽带快速扫描频谱监测系统技术说明书[M].成都:成都中星世通电子科技有限公司, 2007.
[4]钟浩.RMTP规范在地级市无线电监测网中的应用与测试[J].中国无线电, 2010 (4) :20-22.
[5]杜勇.基于RMTP联网协议的多站点协同监测[J].中国无线电, 2008 (3) :12-13.
协议监测 篇7
1 MM4+协议及过程
作为CDMA2000运营商自定义的网关间多媒体消息业务交互协议, MM4+协议主要提供了点对点多媒体消息的前转功能。互联网关作为双方网络之间的接口网关, 为双方的多媒体消息系统之间进行数据交换提供了一条安全、快捷的通道。互联网关之间采用直接连接或经过第三方网关转接, 双方网络通过互联网关实现多媒体消息系统之间的互联[3]。其主要协议层次及具体消息流程如图1所示。
图1直观地展现了MM4+协议的承载协议层次。MM4+协议通过Ethernet II (Physical Layer, Link Layer) 、IP、TCP协议承载。在一条MM4+消息中, 协议栈解码的先后顺序依次为Ethernet II层、IP层以及TCP层, 最后是MM4+层。MM4+协议是SMTP协议的一个演进, 其在传统的SMTP上新增了多媒体信息功能[4]。在本文中, 将SMTP也视为MM4+消息, 统一做监测操作。
图2呈现了MM4+协议的消息流程。MM4+协议的消息主要包括路由前转消息、路由前转递送报告消息以及路由前转阅读报告消息。每一种类型的消息都包含有请求和响应2个过程。其中, MM4+_forward.REQ为路由前转请求, MM4+_forward.RES为路由前转响应;MM4+_delivery_report.REQ为路由前转递送报告请求, MM4+_delivery_report.RES为路由前转递送报告响应;MM4+_read_reply.REQ为路由前转阅读报告请求, MM4+_read_reply.RES为路由前转阅读报告响应。其中, MM4+协议的消息格式为基于文本编码的格式, 类似于SMTP[5], 如图3所示。
如图3所示, 所有被采集到的数据为二进制比特流形式。通过解码, 可以将需要的数据直观地呈现出来。其中在承载协议数据里面, 需要提取的数据有:以太层的grekey参数;IP层的源、目的IP地址以及TCP层中的源、目的端口号。这些参数的提取为判断是否为MM4+协议消息以及后面的合成起着至关重要的作用。
2 MM4+协议监测功能整体设计
根据相关测试规范的要求, CDMA2000 1x EVDO网络MM4接口的MM4+协议监测模块需要实现如下基本功能:协议数据单元的解码与分析、MM4+CDR的合成、消息分类统计以及对统计分析结果的输出等。MM4+协议监测过程中数据消息处理流程如图4所示。
首先, 通过相应接口的数据采集卡将捕获到的数据保存到消息缓存中, 此数据包含有MM4+的相关数据。然后将消息缓存中的数据取出来, 通过解码器逐层解码 (就本协议而言, 即依次调用Ethernet II解码器、IP解码器、TCP解码器, 最后调用MM4+解码器) 。MM4+协议解码主要分为合成解码和详细解码。详细解码Fdecode则是使MM4+消息内的信息单元能显示到信令工具中。在详细解码中, 首先对传入数据的长度、字节大小等参数进行判断, 如果满足条件, 则向协议栈申请一张数据表, 然后逐字节、逐比特进行解码, 并将解码结果填入该数据表中, 记录解码结果。最后将数据表添加到链表中, 并取出上层数据单元, 详细解码操作结束;合成解码parse的作用是为合成代码做提取字段的准备, 通过合成解码将到达MM4+解码器的各条消息得到每条消息的呼叫相关信息, 上传至协议分析器进行消息合成与统计[6]。由图2可知, MM4接口上的MM4+协议主要有3种CDR, 即路由前转消息CDR、路由前转递送报告CDR以及路由前转阅读报告CDR。路由前转消息CDR主要用来记录多媒体消息前转时的类型、方向以及涉及的摘要消息;路由前转递送报告CDR主要用于记录递送报告从接收方互联网关路由前转至始发方互联网关, 在MMS用户代理提取MM以后要求接收方互联网关必须给始发方互联网关返回路由前转递送报告;路由前转阅读报告CDR用于记录从接收方互联网关到发送方互联网关阅读报告的路由前转时的类型、方向及其涉及的摘要消息。首先, 将底层 (主要为Ethernet II、IP层、TCP层以及MM4+层) 解码器中合成解码提取到的合成所需字段传入合成代码, 开始CDR合成。一条MM4+消息进入合成后, 首先通过GREkey, 源、目的端口号, 源、目的IP来确定key值。再通过哈希索引, 找到哈希表里生成的CDRID, 根据CDRID判断CDRBuf是否存在;若存在, 则取出CDR, 并修改CDR属性;判断CDR是否结束, 若结束, 则合成完成;若未结束, 则修改CDR状态, 再将CDR存盘。若不存在, 创建新的CDR, 设置CDR属性值, 并将新的CDR存盘, 合成完成。再将得到的呼叫合成结果记录组成的CDR集合与自定义的呼叫统计结果, 以文件形式保存在磁盘中。最后, 根据用户的需要显示合成统计的结果。
3 哈希索引合成算法
CDR合成主要是根据一些关键参数的查找、匹配来确定是否属于同一个消息流程, 通过对关键参数的判断得到传入的消息是否属于同一个CDR, 然后建立关联[5]。因此在这个过程中, 需要提取一些协议内和协议间进行关联的关键参数。另外, CDR合成涉及大量的查找、匹配, 需要建立许多方便查找的索引, 所以选取一个较好的建立索引的方法对提高CDR合成效率至关重要。本方案主要采用了Hash索引的方法。哈希算法的本质是构造一个哈希函数, 而哈希函数就是关于查找元素与其对应位置的一个具体映射关系。哈希函数的设计很灵活, 选取合适的关键字使得哈希函数值都落在允许的范围内即可[6]。不同关键字可能会出现落在同一范围内, 这将会出现冲突。最理想的情况是建立查找函数与对应位置一一映射关系。下面针对本协议如何构建哈希函数以及如何选取key值才能使得冲突最小做相关介绍。
本设计构建哈希函数的做法是先将构成key值的关键字 (源、目的IP和源、目的端口) 做位或运算, 然后再将结果与字段grekey相加。具体函数代码如下:
为避免冲突, 本设计采取的的方法为将IP层的源、目的IP和TCP中源、目的端口以及GRE中的GREKey建立1个key类, 通过将key与CDRID做关联, 即CHash
4 一种新的CDR存储方法
一个完整的CDR合成流程包括了请求和响应。CDR合成算法主要是根据一些关键参数进行查找、匹配来确定是否属于同一个消息流程, 因此在这个过程中, 需要一些临时存储方式来保存没有匹配到的消息, 在内存分配上比较复杂, 涉及动态分配内存[7]。在CDR合成结束后, 所有内存会释放。但是有时候需要在CDR释放后再次查询相应的CDR (统称消息回放) 用于分析用户信息以及通信网络。故保存CDR显得极为重要。
4.1 CDR合成存储原始操作
原始CDR存储的主要思想为:在合成处理消息时, 当一条消息进入合成时, 该条消息有一个单独的key, 先通过哈希表索引出key对应的CDRID, 然后通过CDRID查到对应的CDRBuf, 并将该消息保存至CDRBuf中。如果后面进入一条消息为相同CDRID的消息时, 即继续添加到相应索引的CDRBuf中;如果进入合成中的消息经哈希索引到一个新的CDRID时, 则在CDRBuf中查找对应的CDR, 并在CDRBuf中存储。具体流程图如图5所示。
CDRBuf存盘的优点在于在原始数据很大但服务器内存有限的情况下, 起一个缓存的作用, 避免了数据“拥塞”, 同时为消息回放流程提供了条件。但是在CDR合成中, 若需添加、修改字段时, 必须先修改CDR, 然后通过哈希表查到CDRBuf, 修改CDRBuf内CDR的值, 才能保证用户从CDRBuf中查到最准确的信息。这样做的缺点是信令处理效率低下。随着当代网络的日益强大, 用户对效率的更高追求, 提出了一种新的CDR存储方案。
4.2 一种新的CDR合成存储操作
为了提高效率, 提出了一种新的解决方案, 即舍弃CDRBuf, 直接通过哈希表获取CDR, 然后通过一个写文件操作进行存盘, 这样使处理速度变快, 为与日俱增的现网数据处理提供极大的好处。流程图如图6所示。
本设计不再使用CDRBuf, 而是通过key值索引, 直接将CDR存入哈希表中。在1个CDR合成操作完成后, 直接通过写文件操作将CDR写入MR文件中。这样做的好处是:在查找、修改流程的具体内容时, 不再需要修改完CDR后, 还需通过CDRID关联查找到CDRBuf再做修改, 然后才能完成的状态。这样使得实时数据的处理速度得到了很大提高, 这也与新网络时代对通信效率的高要求相吻合。
4.3 新旧CDR合成存储的比较
在原始的CDR合成存储中, 通过CDRBuf存储CDR。其作用在于在硬盘文件存取慢的情况下, 起一个缓存的作用, 这样做的好处是避免了数据“拥塞”。CDRBuf为消息回放流程提供了条件。但是, 在CDR合成中, 因为用户是从CDRBuf文件中查询消息流程, 所以在合成操作中, 若需要修改、添加CDR, 必须从CDRBuf中取出对应的CDR, 对它进行相应的操作, 操作完成后, 还需要再将修改后的CDR放回CDRBuf中。很明显, 这样的操作使得监测效率变低, 与当代高效率需求相悖。
新的CDR存储舍弃了CDRBuf, 直接通过哈希表获取CDR, 然后通过一个写文件操作进行存盘, 这样做的好处是:在添加、修改流程的具体内容时, 不用再从CDRBuf文件中取和存CDR, 而是直接在哈希表里面做相应操作后再统一存盘, 这样使监测效率提高, 为与日俱增的现网数据处理提供极大的便捷。这也与新网络时代对通信效率的高要求相吻合。
5 实测数据及结果分析
图7为一个正常消息流程的监测结果图。其右侧位置为详细解码结果。详细解码能将MM4+协议栈中的各层不同协议的具体字段及对应值清晰地呈现给用户以及运营商, 让其对MM4+协议栈结构及信息单元有了更加深入的了解, 为点对点多媒体消息业务监测技术的发展提供了基础。MM4+协议合成模块监测结果及流程图如图7原始数据上面部分所示。以路由前转消息为例 (另外2种消息类似) , 此为1个完整的路由前转消息CDR, 其中, 10.137.17.55和10.137.19.130分别代表2个互联网关地址, 本条CDR一共包含2条消息。第1条为前转请求消息;第2条为前转响应消息。第2条消息表明针对IWGW1向IWGW2的前转请求, IWGW2给予了1个回复, 即不同运营商间的多媒体消息发送成功。
6 小结
通过对CDMA2000网络MM4+协议模块的监测研究, 结合协议内和协议间的关联, 利用高效的哈希索引算法以及一种新的CDR存储方案, 极大提高了协议关联以及CDR合成及统计效率。本设计已应用到“重邮汇测CDMA2000网络增值业务监测系统”中, 并通过了现网数据的测试, 验证了本设计理论的有效性和可靠性。
摘要：首先对CDMA2000 1x EVDO网络中的增值业务进行了介绍, 然后针对增值业务中不同网络间的多媒体消息互通问题, 对关键接口MM4接口中的MM4+协议进行了介绍与监测。最后, 借助哈希索引算法提出了一种新的CDR存储方案, 并通过现网数据测试, 验证了相关方法的可行性。
关键词：增值业务,MM4+协议,哈希索引,CDR存储
参考文献
[1]陶蒙华.电信增值业务平台的体系架构极其发展趋势[J].移动通信, 2005 (6) :40-43.
[2]QB-W-XXX-2011, 中国电信业务网络设备技术规范——移动增值业务信令监测 (全国) 技术规范[S], 2011.
[3]Q/CT 2052—2008, 中国电信CDMA业务网络接口协议技术规范M1/M4/M7接口协议规范[S].2009.
[4]IETF STD 0010 (RFC 2821) :“简单邮件传输协议” (Simple Mail Transfer Protocol) [EB/OL].[2013-02-10].http://www.ietf.org/rfc/rfc2821.txt.
[5]IETF RFC 2046:“多用途因特网邮件扩展 (MIME) 第2部分:媒体类型” (Multipurpose Internet Mail extension (MIME) Part Two:Media Types) [EB/OL].[2013-02-10].http//www.ietf.org/rfc/rfc2046.txt.
[6]宋光秀, 张治中, 王玮, 等.TD-SCDMA网络Iub接口RRC协议监测研究与实现[J].电视技术, 2010, 34 (11) :124.
协议监测 篇8
以多钢箱梁的桥梁应用场景为例,图1所示的混合组网方式更为合理。但是现有的异构网络并不支持混合组网,无法满足传输方式灵活转换的需求。文献[2]中提出的有线与无线通过后端的数据中心进行组网是不可行的; 文献[3]中将有线作为传输总线,无线为分支的结构需要在桥底部连接总线,会给船只车辆通行埋下安全隐患,如果将传输线路进行埋设,不仅会对桥体进行损伤还会增加施工成本和后期维护的难度; 文献[4]将Zigbee网络作为主干网络,但是由于桥梁多为长条型的结构,对于多用于网状网络的Zigbee来说,太深的网络跳数使整体系统的稳定性指数下降[5]。现有的监测网络,由于应用背景简单,并没有考虑混合组网的需求,异构网络一般会确定一种传输形式为主干网络,其他为分支网络,通过网桥将数据由分支网络传递到主干网络,而不支持多次转换。
实现有线与无线灵活转换的异构网络的设计思路是为了保持无线网络的多根自主网的特性,对有线部分进行修改,增加有线的网络层部分,通过统一的串口接口将有线与无线两种传输形式进行连接,并针对有线以及串口的引入对无线传感网的路由协议进行修改,以实现有线与无线灵活转换的功能。
CAN总线是现场控制总线,具备通信模型结构简单、节点故障不会影响整个网络以及为多主网络的优点。所以有线部分选用了CAN总线并对其进行Tiny OS平台下的移植。
Tiny OS是应用于传感器网络的操作系统,可以提供对无线通信、CTP路由协议以及串口通信的支持,CAN总线移植成功后,CAN节点与无线节点在串口上都使用Tiny OS提供的统一的串口发送接收的接口,不需要再进行协议的转换,实现了以串口为桥梁,有线节点与无线节点的无缝连接。
CTP协议是应用于无线传感网的路由协议,具备多根自主网的优点。通过变频的发送beacon包计算出入丢包率,来得到各邻居节点间的传输期望( expected transmissions,ETX) ,如果beacon包中还包含路由信息( 节点到根节点的ETX值) ,则接收到beacon包的节点可以根据路由信息来计算自身到根节点的ETX值。以此为标准建立路由梯度实现组网,确定自身的父亲节点。每个节点将收到的数据包发送给自己父亲节点以实现网络到根节点的数据收集。
由于有线与串口传输的引入,CTP协议需增加对传输方式选择的判断。同时如果仍然使用原有的无线信道评估机制,会造成有线以及串口上发送过多无用的beacon包,导致总线利用率降低。而且原有的无线ETX值复杂的计算方式在有线与串口传输上也没有了实际意义,所以CTP协议需要解决以下几个新问题:
1 ) 有线beacon包与串口beacon包的发送机制;
2) 有线ETX与串口ETX的计算方式;
3) 如何判断父亲节点所在的发送接收接口( 无线、有线或者串口) 。
本文合理地解决了以上的问题,在完成CAN总线在Tiny OS下成功移植的基础上,通过对CTP主要三个模块的修改,对有线与串口ETX提前进行数值的设定,有线与串口beacon包改为事件发送的机制并进行优化,同时增加serial_node_id属性作为判断父亲节点接口类型的依据。完成了原有CTP进行功能的扩展,设计并实现了可以根据信道情况以及实际工程需要,灵活地选择传输形式的低功耗的异构网络,不仅保持多根自组网的特性,同时具备传输线在非关键位置断开不影响网络的数据收集的优点。
1 汇聚树协议
CTP是以收集数据为目的的路由协议,每个节点都将数据发给自己的父亲节点而不关心其他[6],在文献[7]中对CTP的架构进行了说明,文献[8]对其中链路估计的计算以及ETX值的得到过程作了详细的讲解,这里不再重复。
CTP的实现主要包含3个模块: 链路估计器( Estimator) 、路由引擎 ( Router) 和转发引擎 ( Forwarder)[7]。
链路估计器主要负责维护链路估计表、计算单跳ETX值以及提供发送接受beacon包接口[7]。通过发送beacon包来初步 判断周围 邻居的ETX值[9],通过数据包发送接收的ACK来实时的修正与父亲的ETX值。
路由引擎主要是负责维护路由表,通过链路估计提供的接口更新路由表的信息,确定父亲节点,并确定beacon包发送的时机[7]。
转发引擎主要的责任是维护发送数据包队列,决定是否发送和发送的时机[7]。转发引擎不仅要转发从其他节点接收过来的数据包,同时也要发送自己产生的数据包[7]。这三个模块共同完成了CTP组网以及数据包发送的过程,如图2所示。
本着保留原有CTP优点,减少有线与串口不必要beacon包发送的原则。对三个模块进行修改,修改后组网以及数据包发送的过程,如图3所示。增加了判断自身是否为转换节点以及如何判断向父亲节点传输数据包选用哪种传输形式的过程。同时根据节点类型增加了有线、串口两种传输方式接收发送beacon包的时机以及与其相对应的ETX值的获取方法,在下面将会对各模块的修改进行详细的介绍。
2 链路估计器的修改
在此模块中主要对有线与串口ETX值进行了定义,并设置了serial_node_id属性作为父亲节点传输方式判断的依据,并向其他两个模块提供获得serial _ node _ id的Link Estimator. getS erial Node Id ( )接口。
2. 1 提供串口 beacon 包的发送接收接口
Beacon包为广播包,但是仅是在原有的传输方式中进行广播。串口并不会发送,CTP也没有串口发送的接口。所以要让串口成为有线与无线的桥梁,需要在模块中加入串口发送的接口。
2. 2 串口 ETX 值的定义
beacon包是为评估无线通信信道质量而发送的带有路由信息的广播包,没有确认机制,丢包率是根据接收到的beacon的序列号之差来判断应该接受到的总数,再与实际接收到的beacon数进行计算获得的。如果使用同样的机制,串口发送也将使beacon包的序列号增加,导致ETX的计算值比实际的偏大,影响了对无线通信信道的评估。同时由于串口通信的高可靠性以及希望实现转换节点的转换功能,所以将串口的ETX值设为最小的定值1。
2. 3 有线 ETX 值的定义
有线传输环境比较稳定并不需要实时的发送beacon包来评估信道质量,而且发送过多beacon包必然会影响到总线的利用率。但是因为只有在收到足够数量的beacon包后才会计算初始的ETX值。如果按照裁剪后的有线beacon包的发送机制,并不能满足初始路由建立时的需求。所以对于初始ETX值进行了提前的赋值,当收到邻居发来的beacon包,建立链路估计表时直接写入初始ETX值为1。提前赋值并不会影响对链路的评估。在之后的通信中,节点也会通过数据包的发送来不断的修正ETX值。
2. 4 增加 serial_node_id 属性
当串口接收到beacon包时,将此邻居的地址赋值给serial_node_id,怎样区分和邻居节点的连接形式是功能实现的关键点,以此为基础才能进行不同传输模式ETX值得计算以及使用何种方式进行数据包的传输。对于单个节点来说,本属性的邻居可能有很多,但是串口的邻居只有一个。当serial _node_id为无效地址时,说明此节点仅为单纯的有线或无线节点,不涉及串口通信的功能,不是转换节点。
2. 5 提供 LinkE stimator. getS erial Node Id( ) 接口
此接口为其他模块提供获得串口邻居地址的功能,为选择ETX计算方式和传输方式提供依据。
3 路由引擎的修改
在此模块中主要对不同类型节点有线与串口beacon包发送的机制进行了设计,以减少过多beacon包对有线传输的影响。
3. 1 确定无线节点串口发送 beacon 包的时机
原有beacon包的发送是变频的发送机制,用于实时对无线的链路质量进行评估,在串口上,是没有必要的。但是由于beacon包包含了路由信息,是各节点交换路由信息的关键。所以将串口上的beacon包发送改为事件触发发送的机制,只有当路由表为空、收到请求广播路由信息的路由包以及父亲节点变更时才会在串口发送beacon包。
3. 2 确定 CAN 节点有线方式 beacon 发送的时机
对于有线节点,如果它不为根节点,或者转换节点,那么他必将处于网络的最底层,只会向其他节点发送自身数据包,而不会转发其他节点的数据包,不会成为任何节点的父亲。根据CTP的机制,每个节点通过选择邻居节点作为父节点,来进行的汇聚树的组建,那么对于明确是最底层的节点,告知自身的存在是没有意义的。这些节点只需要知道可以作为父亲的节点的存在,所以这里规定,如果CAN节点本身不为根,或者serial_node_id为无效地址时,将不会发送beacon包。如果不是以上两种情况,beacon包的发送时机与无线节点串口发送的时机相同。
3. 3 确定 CAN 节点串口发送 beacon 包的时机
与CAN节点有线 方式beacon发送的时 机相同。
4 转发引擎的修改
在此模块中添加串口发送的接口,并根据链路估计器模块提供的接口获得serial_node_id和路由引擎模块提供的父亲节点是否是同一节点来判断传输的方式。如果相同,通过串口来发送数据包给父亲节点,如果不相同,则通过本属性发送数据包给父亲节点。
5 实验验证
在Tiny OS平台下编写简单的例程,功能为使用修改后的CTP路由向1节点( 根节点) 传输数据AAAA,并对发送的数据包进行编号,进行各节点烧写以及测试台的搭建。
5. 1 有线与无线随需转换功能的验证
如图4设置节点的连接关系,为了在现实中模拟图中情况,将3、4节点和5、6节点分别在一个密闭环境中,阻止其与其他无线节点通信,影响实验的结果。
组网一段时间后,利用监听节点听取网络中的无线数据包,判断根节点的数据接收情况。发现2号节点转发3到10号节点的数据给1号节点。
实验现象证明此异构网络实现了自组网络以及有线与无线间的灵活转换的功能。同时统计6号节点的数据包个数并与最后收到的6号节点数据包序号进行比较,发现最远端6号节点的数据包的丢包率趋近于0。
5. 2 有线传输的高可靠性的验证
如图5所示设置节点间连接关系,摘去3、4号节点天线,在1号节点与3号节点之间放置金属版以及障碍物以降低两者之间通信的可能。组网一段时间后,监听无线数据包。发现2号节点转发3、7、8、9、10号节点的数据,4号节点不转发其他节点的数据给1号节点。
断开8、9节点间的连接线。一段时间后,监听无线数据包,发现2号节点转发7、8号节点的数据,4号节点转发3、9、10号节点的数据给1号节点。
实验现象证明此异构网络具备如果传输线受到损伤,可以通过重新的路由选择,实现有线高可靠性的数据传输的优点。
5. 3 网络性能仿真
使用Tiny OS自带的仿真工具TOSSIM对网络性能进行仿真[10],如图6所示,根据无线节点所处位置进行传输代价的设定,得到路由表如图8,网络深度为11,网络最低层节点到根节点的传输成功率为34. 86%
如果在无线网络中加入有线传输的形式,如图7所示,分别将8、14节点,9、13节点之间增加有线连接。修改网络中各节点传输代价的设置,因为串口传输的可靠性高,丢包率低,并为电路板内的传输,所以在路由表中将有线节点忽略,得到的路由表如图9所示,网络深度为7,最底层节点到根节点的传输成功率为59. 04% ,提高了近一倍。
仿真结果表明,无线与有线传输的灵活使用,将大幅度降低网络的最大路由跳数,提高网络最底层节点到根节点的传输成功率,使网络的稳定性得到提高。
6 总结
利用修改后的CTP协议,组成的混合网络能够很好地支持有线与无线之间的随意转换。在实际工程中,可以更好地根据信道情况、工程要求,选择最为合理的组网方式。同时保留了无线传感网原有的优点,具备多根自组的特性,并且增加了有线传输的可靠性,降低了工程的成本。
摘要：桥梁健康监测由于桥梁结构的多样性和复杂性,需要搭建具备有线与无线灵活转换的异构网络,才能满足实际工程需要以及降低工程成本。设计并实现了有线与无线灵活转换的异构网络,在完成CAN总线移植到Tiny OS的基础上,对原应用于无线传感网的汇聚树协议(collection tree protocol,CTP)进行了功能的扩展,使其可以应用于混合网络,实现了有线传输与无线传输可以随意转换的异构网络,在保留了无线原有的优点的同时,提高了传输的可靠性,显著降低了工程的成本。
关键词：CTP,混合网,桥梁健康监测
参考文献
[1] 贾亚平,浣石.大型桥梁健康监测研究动态与发展趋势.四川建材,2013;39(4):1—2Jia Y P,Huan S.Development of long-span bridge health mordtoring.Sichuan Buildine Materials,2013;39(4):1—2
[2] 申云海,马千里,卞春华,等.基于有线无线异构网络融合的桥梁健康监测系统.现代计算机,2011;10:65—69Shen Y H,Ma Q L,Bian C H,et al.Bridge health monitoring system based on integration of heterogeneous structural network for wireless and wired.Modem Computer,2011.10:65—69
[3] Jaman G,Hussain S.Structural monitoring using wireless sensors and controller area network.Fifth Annual Conference on Communication Networks and Services Research.Fredericton,New Brunswick,Canada:Michael Ley,2006:26—34
[4] Gomes R P N,Faria S P S,Oliveira J E G,et al.A hybrid sensor network for the real-time condition monitoring of rotating machiner.2010 6th IEEE International Conference.Santa Barbara,CA:IEEE,2010:1—2
[5] Cervenka V,Mraz L,Komosny D.Comprehensive performance analysis of lightweight mesh and its comparison with zigbee pro technology.Wireless Personal Communications,2014;Vol.78(2),pp.1527—1538
[6] Fonseca R,Gnawali O,Jamieson K,et al.The collection tree protocol(CTP).2006.http://www.tinyos.net/tinyos-2.1.0/doc/html/tep123.html.2014-09
[7] 何朝娟.Tiny OS的汇聚树协议研究.单片机与嵌入式系统应用,2011;11(1):3—5He C J.Study of collection tree protocol in Tiny OS.Microcontrollers&Embedded Systems,2011;11(1):3—5
[8] 陈健,杨志义,王敏.无线传感器网络数据汇聚协议CTP的仿真与研究.现代电子技术,2011;34(6):89—93Chen J,Yang Z Y,Wang M.Research and simulation of ctp protocol for wireless sensor network.Modern Electronic Technique,2011;34(6):89—93
[9] Gnawali O.The link estimation exchange protocol(LEEP).2006.http://www.tinyos.net/tinyos-2.1.0/doc/html/tep124.html.2014-09
