关键词：
信令接口（精选四篇）
信令接口 篇1
E&M接口是一种常用的语音通信接口。在E&M接口中, 信令通道与语音通道是分开的。E&M通常被形象地称为“耳朵和嘴 (Ear&Mouth) ”。E&M接口有多种信令方式, 由于V类信令与民航VHF设备的传输机制类似, 所以, 通常使用V类信令实现对VHF信号的传输。
表1列举了Vanguard传输设备的E&M线序定义。
当本端的用户设备需要发送1个控制信号给远端的用户设备时, 发送过程为: (1) 本端用户设备的发送控制模块接地, 与传输设备E&M接口M线内部的电压源 (约-48 V) 形成电势差, 产生电流。 (2) 当电流被传输设备内部的检测模块检测到后, M线被激活。 (3) 本端E&M接口的M线激活后, 远端E&M接口的E线也立即被激活。E线内部接地, 与远端用户设备接收控制模块内部的电压源形成电势差, 产生电流。 (4) 电流被远端用户设备接收控制模块内部的检测模块检测到后, 远端用户设备将会成功接收到控制信号。
从理论上讲, E&M V类信令仅使用了RJ45中的6根针脚。另外, 还需要将SG针脚与后接设备的地线相接, 使两端设备共地。所以, 在E&M接口与后接VHF设备连接时, 不使用“第8根针脚”——SB针脚, 应当将其悬空。但是, 在实际的应用过程中发现, 很多VHF电台在施工时, 误将SB针脚与地线相接, 这可能会对E&M接口的正常使用造成一定的影响。
2 SB针脚的研究
在E&M接口中, SB针脚应用于II, III, IV类信令, 作用是将其作为1个电压源提供电压, 但是, 在E&M接口V类信令中未使用。实际上, 即使将传输设备的E&M端口设置为V类信令, SB针脚仍然能测量出电压 (-48 V左右) 。如果将SB针脚接地, 也许会影响M线的电压。
Vanguard路由器和MICOM复用器是民航使用较多的VHF传输设备, 这两种设备的同一块板卡有2个E&M接口。将2个E&M接口的SB针脚分别接地, 测量其中某一端口的M线电压。
对Vanguard同一块板卡两端口P13, P14进行实验, 数据如表2所示。
对MICOM同一块板卡两端口C1, C2进行实验, 数据如表3所示。
由表2、表3可知, 如果将SB针脚接地, 对本端口和同一板卡上的另外一个端口都是有影响的。其中, Vanguard设备SB针脚接地对M线的影响较大, 而MICOM设备SB针脚接地对其的影响则很小。
3 SB针脚接地存在的隐患
根据民航对VHF通信的保障要求, 1个VHF信道的主、备信号需要通过地、空两种不同的路由进行传输, 并且要使用不同的传输设备。对某些VHF电台来说, 其无法提供2个独立的主、备信号, 主、备两路信号只能在配线架上通过并线的方式实现。假如主用信号使用的是Vanguard设备, 备用信号使用的是MICOM设备, 由于并线的原因, Vanguard的M线与MICOM的M线、Vanguard的SB针脚与MICOM的SB针脚都是连通的。如果施工人员误将SB针脚接地后, Vanguard和MICOM的M线电压都将被改变。由于Vanguard的M线电压提升得较大, 而MICOM的较小, 所以, 在2个设备的M线之间形成了电势差。如果产生的电流大于其中某一设备检测模块的阈值, 就会触发该设备的M线, 导致传输设备产生“长发”现象。“长发”现象将导致后接VHF设备发生警报, 无法正常使用。
4 总结
综上所述, 在施工人员安装设备时, 应确认E&M的SB针脚悬空, 以防类似“长发”的现象发生。例如, 2014-01, 徐州VHF遥控台传输设备出现“长发”现象, 导致VHF信号无法正常使用, 技术人员赶赴徐州排查故障, 最后发现故障的原因是徐州端传输设备的SB针脚接地, 将SB针脚悬空后, 故障排除。另外, 应尽量避免以并线的方式产生多路信号, 以防因后接设备的电压不同而使设备之间相互影响。
摘要：针对E&M接口中的SB针脚进行实验, 研究在SB针脚接地的情况下对接口造成的影响。
关键词：甚高频,E&,M接口,SB针脚,信号
参考文献
信令接口 篇2
随着移动通信网络的发展, 3G网络建设得已经越来越成熟, 用户数量每年也急剧增加, 网络优化的需求也越来越大。目前的方法主要是采集通信网络接口中的信令数据, 然后解码分析优化网络。Iub接口作为RNC和Node B之间的逻辑接口, 承载着大量的信令消息, 为了能更好的优化网络必须采集解析Iub接口的信令数据。Iub接口在网络中的位置如图1所示。
Iub接口数据使用PER非对齐编码, 这种编码方式相对BER编码效率要高很多, 但是解码过程会复杂很多。BER传输语法的格式是TLV三元组
1 解码器总体设计
目前世面上PER非对齐编码的解码库没有开源的, 而且部分非开源的库是一整套的编解码体系, 对于网络分析优化来说, 只需要解码器, 这些库都不适用。本文设计的解码器是专门针对Iub接口数据的, 可以直接生成一个C++类的源代码, 该类包含所有信源的解码函数, 如果协议有所升级, 直接将新增加信源的ASN1结构添加到要解析的文本文件并重新运行程序即可得到最新的解码程序源代码。这些源码是纯C++程序, 可以拿到任何平台上编译使用, 扩展性极强而且更加经济实用。
首先将协议文档中将Iub接口所有的信源ASN1描述复制到文本文件RRC_ASN.txt中, 然后调用ASN结构解析模块解析RRC_ASN.txt文件, 获取所有信源的具体结构, 存入一个map结构中。Map的键为信源的名称, 值为一个vector结构, 里面保存该信源包含的所有子信源的结构信息。然后调用代码生成模块, 通过对map中各个信源的结构生成C++代码的头文件和源文件。
主要实现的功能模块如下:
信令数据处理模块:PER非对齐编码中的数据是按位紧凑排列的, 为了方便对信令数据的提取, 将所有的信令数据的每一位数据提取出来按顺序存入一个unsigned char的缓存区中, 每一位数据用一个unsigned char类型来保存, 虽然在内存空间上有一定的牺牲, 但是数据的提取和解码效率将大大提高。
ASN1结构解析模块:解析ASN1结构获取每种信源的具体结构信息。
代码生成模块:通过上一步获取的结构信息生成每个信源的PER非对齐编码的解码函数, 生成C++源代码。
将解码器分成两个模块的目的是为了方便调试。由于RRC_ASN.txt文件多达1万三千多行, 不可能人为地去检测解析结果是否正确, 所有可以在解析完ASN1文本文件后, 可以通过统计保存解析结构的map结构数据中各种类型数据的个数和ASN1文本文件中各种类型数据的个数对比来判断解析模块的正确性。
信令数据解码器原理框图如图2所示。
ASN1结构解析模块是解码器的最重要也是最复杂的模块, 需要分析ASN1全面语法, 才能得到正确完整的信源数据结构, 最后需要使用多种方式验证解析结构的正确性。
2 解码器模块化设计
(1) 信令数据处理模块
Iub接口的信令数据全部使用的是PER飞对齐编码为了方便提取一定数量比特位数的值, 将没原始信令数据转换, 即将原始数据的每一位数据提取出来赋值给一个unsigned char变量, 这样信令数据所占的内存会是原来的8倍, 但是在解码过程中指针的偏移会变得容易控制, 这样可以大大提高解码的效率, 降低解码难度。实现方法如下:
参数一为待转换的数据指针的首地址, 参数二位带转换数据的参数, 参数三为接收转换后数据的存储区, 返回值为转化后数据的大小。
(2) ASN1解析模块
ASN1是一种数据结构描述语言, 针对Iub接口信源类型, 进行编号。
INTEGER (0..99) :整形数, 记为类型1, 括号中的描述代表这个数的范围。
BIT STRING (SIZE (16) ) :位串, 记为类型2, 括号中的描述代表这个位串的长度。
OCTET STRING (SIZE (2..17) ) :字节串, 记为类型 (3) 括号中的描述代表这个字节串的长度。
ENUMERATED{}:枚举型, 记为类型4, 该类型携带的数据只可能是大括号中的一种。
SEQUENCE{}:一种符合类型, 记为类型6, 它可以包含任何类型的数据, 类似于结构体。
SEQUENCE (SIZE (1..maxRAT) ) OF A:代表类型A的序列, 就是A类型的数组, 括号内的描述代表数组大小的范围。
CHOICE{}:一种符合类型, 记为类型7, 它可以包含任何类型的数据, 类似于联合体, 最终它只携带一种类型。
NULL:空类型, 记为类型8, 它不含任何内容。
BOOLEAN:布尔类型, 记为类型9, 只占一位, 1为真, 0为假。
0类型:没有用以上的方法给出定义而是直接给出一种类型名的类型, 记为0类型, 这种类型会在其他地方有具体定义。
其中类型5, 6, 7为符合类型, 其他的为基本类型。
首先读取ASN1描述文本的所有内容存入内存, 按行读取, 每行文本作为一个字符串变量存入vector1中。然后进入循环, 在vector中找出第一个使用“::=“定义的大类型数据, 得出该类型的名称, 类型, 和它包含数据的上下界 (在vector中的下标位置) 。然后调用解析函数解析这个信源结构。算法如下:
FindMessageIE方法通过字符串“::=”找到信源结构定义的起始行得出信源名称DL-ChannelisationCode, 类型6, 通过{和}的匹配得出他包含内容的起始行和结束行。
ParseIE函数是解析的关键, 它将完成结构解析并将结果写入map结构。ParseIE使用递归的方法解析信源结构, 算法和存储结构如下:
(3) 代码生成模块
代码生成模块通过ASN1模块解析后得到的map结构数据来生成每种信源的解码函数。信源DL-ChannelisationCode的在map中的结构描述如图3所示。生成信源解码函数的方法如下:
将map中所有的信源名称中的-替换_;
使用迭代器遍历map, 对每一个信源生成解码函数信源名称做函数名, 格式为void信源名称 (unsigned char*cData, int&nPtr) 参数1为转换后的带解码数据的起始指针, 参数2使用引用的方式传递形参, 它会不断地自加, 始终下一个待解码信源的起始位置。
生成函数体, 方法为:
(1) 如果该信源的类型是1, 2, 3, 4, 通过map中的数据得出该信源所占的位数 (在这里就是字节数) , 输出信源名称, 信源的二进制值和十六进制值。然后nPtr跳过这几个字节指向下一个待解码信源的首位置。
如果该信源的类型是5, 就是类型6的数组如SE-QUENCE OF SIZE (n) A, 首先获取这个数组的大小n, 然后通过for循环调用n次函数A。
如果该信源的类型是6, 首先统计该信源中可选项OPTIONAL的个数n, 那么数据开头的n个字节的值就依个代表该信源是否含有这个信源。依次调用这些存在的信源的解码函数。
如果该信源的类型是7, 首先统计该信源中可选项OPTIONAL的个数n, 由于choice类型只含其中一个子信源。读取前log2 (n) 个字节 (向上取整) 的值得出该choice类型信源包含的是哪一个子信源, 调用该信源的解码函数。
总的来说只用直接类型的信源才会有具体的解码过程, 因为符合型信源最终包含还是基本的直接类型。
3 调试验证的基本原理
ASN1解析模块的验证方法为统计ASN1描述文本中各种类型的数量和得出map中的各种类型的数量对比, 可以得知解析过程是否出错。将map中的数据以图3的格式写入到csv文件中, 使用excel打开通过筛选功能很容易看出各个类型是否分析错误。
代码生成模块的验证方法是将生成的代码的h和cpp文件添加到工程参加编译, 编译器可以检测生成代码的语法错误, 方便该模块的调试。
最后生成的C++代码只是解码程序的一个模块, 可以和主程序一起重新编译, 或者编译成一个动态库, 这样可以方便的让其他的程序中。一般通信网络数据采集后会通过采集网关统一传入存储服务器, 网优人员可以直接通过程序调用该模块对想要分析的数据解码, 然后根据解码结果分析网络状态。一旦接口数据升级或者同类型的新项目开发, 解码程序开发人员可以迅速的开发出同类型编码方式协议的解码模块, 通信网络采集的大量的信令数据就不必长时间的保留在服务器中, 分析完后就可以清楚, 缩短开发周期的时候也大大的减少了运营成本。
4 结论
从本设计的基本原理可以看出, 它相比一些只支持单一平台的PER非对齐编码解码库的非开源库相比, 本文设计的解码器拥有十分强大的灵活性, 开发人员可以根据项目需求改写代码, 使其可以适于与移动通信网络中使用PER编码的其他接口信令数据的解码, 当接口协议更新后, 直接通过更新ASN1描述文本变生成最新的解码程序, 重用性强, 十分适用于移动通信网络的信令解码。
摘要：Iub接口的信令数据使用PER非对齐编码, 这种编码方式的效率很高但大大增加了解码的复杂度。本设计采用解析Iub接口信令ASN1结构的文本的方式提取每种信源数据的具体结构信息, 然后直接生成对应的C++解码程序的源代码, 具有稳定性好, 重用性强, 易于扩展的特点, 适用于多种平台的开发。
关键词：Iub,信令解码,PER,ASN1
参考文献
[1]夏鞑, 雒江涛, 张治中.TD-SCDMA测试仪中Iub接口CDR的合成方案[J];重庆邮电大学学报 (自然科学版) ;2007年01期
[2]蒋荣.TD-SCDMA网络传输接口Iub的分析[J].信息技术与标准化;2008年09期
[3]李贺禄, 蒋凡, 杨敬峰, 高翔.基于面向对象的ASN.1编解码的设计与实现[J];计算机工程2002年12期
信令接口 篇3
随着不同网络融合以及互联网本身的发展,传统的面向PPP服务而设计基于AAA协议的Radius已经不能完全满足网络需求,因此Diameter协议应运而生,在未来移动通信网逐渐向全IP过渡的过程中,Diameter协议得到了广泛的应用。AAA是指Authentication(鉴别),Authorization(授权),Accounting(计费)。其中,鉴别(Authentication)指网络系统对使用其资源的用户身份的确认,授权(Authorization)决定一个提出请求的用户能否被允许访问某种网络资源,计费(Accounting)是网络系统收集、记录用户对网络资源的使用,借以向用户收取网络资源的使用费用及审计等[1]。Diameter包含基础协议、传送协议和不同的应用扩展协议,如NASREQ和移动IP[2],所有应用和服务共用的基本功能都在基础协议中实现,而应用特定的功能则会在不用的应用中实施[3]。LTE(Long TermEvolution长期演进)中S6a接口位于MME(移动性管理实体)和HSS(归属用户服务器)之间,用于实现用户相关数据的传输,可以实现用户接入LTE系统时的鉴权、认证功能。
2 Diameter解码模块功能分析
本解码模块包含解码器和基础解码两个模块,如图1所示。首先,在基础解码器模块中定义一个diameter_summary_result结构体,用来存放从原始数据中解析的消息字段;在解码器模块中定义了一个Diameter_CALL_INFO结构体,用来存放从基础解码模块中所解析的对应消息字段,通过调用基础解码模块中的diameter_sdecode函数,将基础解码中解码成功后的字段填入到该结构体中;
为了更好地呈现数据和后续分析,该系统将解码模块分为-详细解码模块和简单解码模块。其中,详细解码模块主要以中英文双语的形式通过树形图形界面将解码结果呈现给用户[4]。为了LTE检测系统后续的消息处理、合成呼叫详细记录、统计分析等功能准确、高效的实现,该监测系统通过简单解码接口解析所需的关键信息[5]。
协议解码由低到高逐层进行,由S6a接口协议栈结构可以看到只有在对下层协议进行准确无误解析的同时成功提取上层PDU信息后才能对上层协议进行正确的解析。由于MME和HSS之间S6a接口采集的原始数据对应如图二所示接口协议栈,所以在进行Diameter协议解码之前,先调用S6a接口解码器对采集的原始数据进行预先解码。当原始数据以实参的形式传入解码器Diameter_Sdecode函数后首先调用Reset函数进行Diameter_CALL_INFO结构体的初始化,然后分别调用EthernetII、IP、SCTP协议解码器,提取包含与各协议中的关键信息和所需字段,最后调用基础解码模块中的diameter_sdecode函数进行Diameter协议解码。
2.1 Diameter消息结构
2.1.1原始消息格式如表1:
2.1.2 Diameter消息结构:
Diameter协议是由一个Diameter协议头和一到多个属性值对(AVP)构成。每个AVP又由一个AVP头和相应的字段信息值构成。该字段信息值一般表示字段内容(例如,路由信息),以及认证、授权或计费等信息。其结构示意图如表2所示[6]:
各字段设置如下:Diameter header部分:Version:代表该协议的版本号,目前置为1。Message length:表示该消息的长度,即头长度和各AVP长度之和。Flags:R(equest):当该位被置为1时表示该消息为请求消息,为0时表示响应消息。P(roxiable):如果该位被置为1时代表该消息可以被转发,若为0表示消息必须在本地处理。E(rror),该位若在响应消息中被置为1,则表示产生了一个协议错误。r:表示保留位。Code:消息命令码,表示各种Diameter消息,如316-3GPP-Update-Location3233GPP-Notify等,其值在同一消息的请求和响应中是相同的。Application ID:用来表示不同的Diameter应用。Hopby Hop ID:逐跳标识,用来匹配同一消息的Request和Answer,在一特定的Connection上总是唯一的,其值在转发时会被Agent修改。End to End ID:端到端标识,用来鉴别重复消息。
AVP header部分:AVP code:标识一个AVP。AVP flags:共占一个字节,其中V、M、P、r各占一位。V(Vendor specific):若被置为1,表明该AVP中含有Vendor ID(制造商ID),如果该位为0,则表示该AVP缺失Vendor ID,即暗示该AVP不是制造商定义的;M(Mandatory):如果此AVP是这条Diameter消息所必须的,则该位要被置为1;P:若此位置为1表明需确保该AVP End to End的安全性。AVP length:整个AVP长度,即AVP header部分和Data部分的长度之和。
2.2 Diameter解码模块功能设计与实现
2.2.1 Diameter详细解码模块设计及实现
通过对该监测系统需求分析,在详细解码模块中,实现对Diameter协议每个字节、每个比特位的详细信息解析。详细解码结果经封装后在LTE信令监测系统界面上以树形图展现,方便用户快速理解消息数据代表的信息,而且本监测系统为适应不同语言用户的需求,详细解码采用中英文双语形式[7]。
在本模块中由于Diameter协议自身的特点,其所携带的消息格式比较清晰,层次性较强,针对这一特点我们采用函数递归的思想进行详细解码的实现,这种解码方案的优点是模块简单化、代码冗余度小、维护性强。首先,将只包含Diameter净荷的数据头指针pData和该数据的长度nBitLen以实参的形式调用基础解码库中的diameter_fdecode函数。然后,判断数据长度和协议版本是否有效。其次,根据客户要求对Diameter协议的头部进行中文或英文的详细解析,最后,采用decode_diameter_avp函数递归的方法对Diameter协议的AVP消息部分进行详细解析。其伪代码如下:
其中p B y t e表示下一 消息的数 据头指针 ,nSurplusMsgLength代表剩余消息的总长度。
整个过程的流程图如图3所示:
值得一提的是:基于对Diameter协议消息格式的分析,在Diameter协议详细解码中并没有采用诸如S1ap、Gtpv2等协议解码时将每个消息的解码进行封装,然后静态调用的方法。而是采用了decode_diameter_avp函数递归的方法。采用这种设计方法,不仅大大减少了代码冗余度,提高了代码的执行效率,并且使代码在结构上清晰明朗、便于阅读。
2.2.2 Diameter简单解码模块设计及实现
基于整个监测系统的需求分析和解码器模块对简单解码的需求,在该模块中我们只对Diameter协议关键消息进行解码。简单解码这种设计主要是将每条数据概要在监测系统界面中显示出来,这样做的好处是,我们可以迅速精确的定位每条数据属于哪一个信令流程[8]。简单解码的框架设计和详细解码有异曲同工之处,不同之处在于,简单解码diameter_sdecode函数作为在解码器中调用的函数,其调用后的结果用于合成时给CDR(呼叫详细记录)进行赋值,所以它主要解析一些CDR所需的关键消息和字段。因为简单解码对代码执行要求较高,所以本方案尽量避免在diameter_sdecode函数中调用其他函数和递归的方式,而是采用While循环、AVP类型匹配的方式对每个AVP消息进行解析,由于每个AVP携带有相同格式的AVPheader,所以在循环开始共用一套代码实现对头部的解析,其伪代码如下:
这样做的好处是忽略了不必要的AVP的解析,不但节省了代码空间,提高了代码运行速度,而且便于测试和修改。简单解码流程图如图4所示:
3测试结果与分析
3.1解码结果与分析
该设计方案通过LTE信令监测系统对数据实时采集、分析,得到了有效验证。图5是Diameter协议UpdateLocation-Request消息的简单解码结果,从结果中我们可以清晰地看到Diameter协议所在的协议栈的结构,依次为Ethernet、IP、SCTP、Diameter协议,并且显示出了每个协议所携带信息的概要。
图6是该消息详细解码中文显示结果图,该结果以树形结构显示了Update-Location这条消息所携带的信息,并且对每个字段值进行中文注释。该结果清晰地显示了整个S6a接口协议栈和Diameter协议结构以及每个AVP的格式。
对以上简单解码和详细解码结果分析可知,同一Update-Location-Request消息简单解码中的srcMac、dstMac、srcIP、dstIP、srcPort、dstMacPort、MsgType等字段与详细解码中源地址、目的地址、源IP、目的IP、源端口、目的端口、命令码等字段解码结果相同,这说明本文设计的详细解码模块和简单解码模块对原始数据解析的结果保持了一致性。准确有效的简单解码结果为快速过滤有效消息提供了最直接的,最便捷的方法。
3.2解码性能与分析
通过在32G内存配置的Linux下LTE监测系统的测试和运行,上文设计的解码方案在空间和时间效率上得到了优化。通过监测发现整个监测系统在持续运行情况下内存维持在0.5%左右,空间性能结果如图7所示。在Diameter协议数据为总采集数据5.02%的比列下,时间仅为整个监测系统总耗时的0.94%。时间性能结果如图8所示。
4结论
在LTE信令监测系统中完成了对S6a接口所遵循的Diameter协议数据的解码分析,并通过LTE信令监测系统成功的实现了Update-Location-Request(位置更新请求)过程的解码,证明了解码方案的可行性和高效性。该方案已应用到运营商的现网监测中,测试效果良好,验证了该方案的稳定、有效和可靠性。
摘要：通过对LTE网络中S6a接口所遵守的Diameter协议研究和分析,设计并实现了其解码模块。为了满足不同功能模块对解码结果的调用,在解码模块中设计和实现了两种不同接口-详细解码接口和简单解码接口。针对传统解码实现中执行速度慢、效率低、代码冗余度大、不易维护等缺点,创新性的提出了分层解码、递归解码等多个解决方案。并通过LTE信令监测系统成功实现了Diameter协议中位置更新请求(Update-Location-Request)过程的解码,证明了设计方案的可行性。此方案已应用于LTE信令监测系统中,效果良好,达到了对Diameter协议解码的目标。
信令接口 篇4
当前的移动网络处于高速的发展阶段，越来越多的用户从2G网络转移到3G网络的使用之中，业务的重心也逐步体现出由语音业务向数据业务偏移的趋势，由此导致移动网络的数据业务量的逐步增大，而移动用户对于数据业务的服务质量也有了新的要求。
EV-DO信令监测系统旨在为端到端的网络运营和维护提供优良的分析平台，而网络结构中的R-P接口作为分组控制功能PCF(Packet Control Function)和分组数据服务节点PDSN(Packet Data Service Node)交互的通道，该接口间信令监测的精准性和实效性对于整个系统的实时监控，流程追踪和故障定位都极为重要。监测系统的重点主要集中在实时的信令流程追踪分析上，而这都要借助采集而来的现网数据合成呼叫详细记录CDR加以分析说明。目前的信令合成方法主要是根据各条信息的标识建立不同的接口，不同协议的业务CDR，但是在复杂的网络接口信息中，各个协议和接口消息以及信令流程并不是完全独立，因此单独建立的多业务CDR之间的关联往往比较复杂，而且降低了系统的运行效率，对超大流量接口R-P接口的实时监控结果不够精准。针对上述问题，本文提出了一种高效的CDR关联方法，通过对R-P接口中两个协议栈A11,PPP消息的联合分析完成对该接口的CDR合成，并且针对不同的业务流程生成不同的业务CDR，即寻呼CDR以及主叫CDR。该过程中通过建立全局的散列表来关联不同的消息并且实时统计用户的业务使用状态。最后通过结合现网数据，对该方案进行了测试和验证，运行结果表明该方案可行，效果良好。
1 R-P接口中的信令和业务消息
采用R-P接口是无线网络RN(Radio Network)和PDSN之间的逻辑接口，其接口两端的实体分别是PCF和PDSN。另外它包括了A10和A11接口，所以也可以称为A10/A11接口。
A11接口为信令传输通道，它主要负责传送建立、拆除和更新A10连接的信令。当用户使用数据网络上网时，需要通过PDSN来分配相应的移动网IP才能正常服务，而且这期间需要建立唯一的数据通道来与网络资源交互数据，而A11信令就为建立相应的协商和调配无线资源进行了准备工作。其中具体的消息主要包括A11注册请求，响应以及A11更新请求，响应。参见3GPP2提供的官方接口文档[1]，特定字段的不同取值，其相应的A11消息的作用也不尽相同，这其中就包括了本文中的A11寻呼业务和主叫业务的区分。
A10接口为数据传输通道，其消息都经过了通用路由封装GRE(Generic Routing Encapsulation)层进行了封装。在此之前，需要通过点对点协议PPP(Point To Point Protocol)协商建立PPP通道，借助PPP连接来传递用户的业务数据，具体的业务内容消息可以从A10接口[2]中获取并提炼。
在使用数据业务的时候，用户的状态一般按照PPP链接的状态来区分[2]:休眠、激活、未激活。此过程中值得注意的是不同R-P接口上的数据服务流程，现可以大致归纳出以下三类:
(1)AT主叫业务+无重激活过程;
(2)AT主叫业务+重激活过程;
(3)AN寻呼过程。
对于过程(1)，用户属于开机第一次使用数据网络，此过程中PPP连接尚未建立因此，其PPP的状态为未激活态，因此在使用分组业务之前，还需要通过A11的注册消息为该用户分配无线资源并建立相应的PPP链接。对于过程(2)，用户在之前已经使用了数据网络，因此PPP连接已经建立了，但是出于对资源的合理利用，当该用户没有发生网络交互流量时，PPP连接的状态切换到了休眠态，因此需要通过重激活过程为用户分配无线资源，并激活PPP的链路状态。相比于过程(1)和(2)，它们交互建立的主要来自于AT的主动请求，但对于过程(3)，网络侧成为了主动的一方，其PPP连接状态的切换都受网络侧发起的下行包影响。
以上的三个过程，基本囊括了用户在使用EV-DO数据网络时的各种情况。追踪上述流程有助于了解用户的总体使用情况和网络的运行状态。
2 动态哈希表的设计
在以往的A11信令合成过程中，对于每个信令过程仅仅建立了一张静态哈希表用于存储信令交互过程中的所有消息且没有区分具体的信令即主叫和寻呼。如此在最后输出统计结果上浪费了大量的硬盘存储空间并影响了一定的统计输出效率。
为了解决这个问题，结合对分布式哈希表[3]的理解，在本文的方案中设计了一种动态可变的哈希表维护机制。针对现网数据的多维复杂性，合成过程中的哈希表通过选取关键字key被某个不大于哈希表长度n的数m除后得到的余数结果作为哈希地址，从而减少了发生哈希冲突的可能性。结合本合成过程的选取了关键字段PCFIP,PDSNIP,GREKEY，即:
3 寻呼与主叫业务的信令追踪
在第1节中，主要介绍了R-P接口间主要的三个流程，通过了解和追踪这三个不同的流程，可以帮助网络维护者及时的发现用户在上网过程中所遇到的问题。而追踪的关键就在于根据R-P接口间采集而来的消息合成CDR[4]，为了区分主叫和寻呼流程，本文对R-P接口间的消息流程细分为了A11注册、A11更新、PPP链路的建立、PPP拆线，以及AT主叫和AN寻呼CDR。与其他几个CDR单纯依靠信令消息或者业务消息合成流程不同，AT主叫CDR和AN寻呼CDR的流程建立夹杂着信令和业务消息，如何为二者建立关联为本文的研究重点。
3.1 AT主叫CDR合成的原理及方法
3.1.1 无重激活的主叫过程
对于用户上网的主叫过程，主叫业务连接成功率，AT重激活成功率和AT主叫网络的时延分析是分析该流程所要获取的重要信息。下面以AT开机后发起的第一次主叫请求为例进行说明(见图1所示)。
如图1所示，由PCF发出第一条A11注册请求和PDSN下发第一条下行包这之间的交互归纳为A11主叫的过程。由于AT开始处于空闲态，该过程需要首先就需要建立无线的业务通道(虚线部分表示连接还未建立)，及通过MS与BTS间的交互建立业务信道，并通过BSC与PCF间的A8,A9信令分配无线资源，该部分的信令信息在对R-P接口进行分析的时候可以不采集，主要采集的是PCF与PDSN之间的信令和业务信息。
由图1中可知，通过两条A11-Registration-Request消息，完成了对业务连接无线资源的分配，而对该条消息的解码，其厂家重要扩展CVSE(Critical Vendor/Organization Specific Extension)字段中所携带Airlink字段可以提取出统计所需的空中链路的状态，并可以对PPP连接的使用情况进行分析，如该例中，空中链路状态经过了两次变化:第一次是Setup阶段，它用于在A10业务连接建立阶段发送连接的初始化消息;第二次则是Active阶段，它包含了业务连接中无线侧的信息，之后经历PPP协商成功之后，MS与PDSN间的业务连接就建立了并处于激活态。当此期间，再无业务连接状态的切换且收到第一个业务数据包(图中，1st Downlink Traffic Data)，就可以记为一次无激活过程的AT主叫连接。
3.1.2 存在重激活的主叫过程
在移动网络中，无线资源是非常有限的，因此为了节约无线资源，在用户使用业务数据后一段时间内没有数据交互，则PCF会主动发送空中链路消息为Stop的A11-Registration-Requst消息，此时无线资源是没有释放了的，业务链路将会处于休眠态。而当用户重新请求业务数据，会通过PCF发送空链路消息为Active Start的A11-Registration-Requst消息重新请求无线资源，业务链路则回到了激活态。
3.1.3 AT主叫CDR[5]合成方法
通过上面的原理分析，可以看出在CDR合成过程[6]中主要关联的是A11-Registration-Requst与第一个业务下行包之间。由于这两条消息，处于不同的协议消息中，所以借助按协议区分的CDR合成方法是无法轻易解决的。
因此本文提出一种将A11与PPP部分的合成合并的方法，统称为R-P接口的合成，程序的模块结构如图2所示。在R-P接口合成模块中包含了A11与PPP(包括PPP的协商消息和业务数据的消息)中各条消息的合成过程，由于处于同一个合成模块中，将属于A11和PPP的消息经过筛选送入到该合成模块进行处理，其中除了A11注册的CDR合成和PPP协商CDR合成外，更重要的是AT主叫和AN寻呼CDR的合成，这里先介绍AT主叫CDR的合成过程，过程中为了挺高的加强关联效率，设立一张名Global R-P Info的关联全局的哈希存储表作为全局的管理维护表，并记录相应的PPP连接状态。图3为AII主叫CDR合成流程。
通过图3的流程分析，AT主叫CDR流程的建立消息应该为A11-Registration-Request消息[7]，其携带的空链路状态应该为Setup，由于此时全局哈希表中还没有该条记录的存在，所以应该提取当前A11消息中会话特定扩展字段所携带的Gre Key和PDSN的IP以及PCF的IP作为当前全局维护表的索引Key值，并建立索引的记录信息，对Global R-P Info中的关键字段业务连接状态(PPP＿Status)进行修改。下一条A11-RegistrationRequest(Active Start)消息既可以通过Gre Key关联到流程的维护记录，并修改业务连接的状态。A10的下行业务包需要通过对PPP连接上的TCP数据包分析得到，由于业务数据包都需要通过GRE层进行数据传送的承载，可以提取出相应的Gre Key用来匹配全局维护表中的流程记录，在匹配之前先查询PPP连接的状态，若为激活态则进行之后的操作添加相应的业务包到达时间，至此一次AT主叫的过程就完成了即可以生成一条主叫记录。
3.2 AN寻呼CDR合成的原理及方法
3.2.1 AN寻呼过程
在社交聊天类软件流行的今天，AN寻呼过程在数据网络中频繁的发生着，与上述AT主叫过程不同的，其业务交互的过程往往是由服务端发起的，比如说某移动用户收到好友发来的留言或者消息。其实际流程图如图4所示。
在移动网络中为了更合理的利用，当移动用户一段时间内没有业务请求，则用户的PPP连接会自动释放掉其所占用的无线资源以达到节约资源的目的，而这时PCF会向PDSN发送一条A11-Registration-Request消息，其携带的空链路信息为Active Stop，表示PPP连接进入了休眠态即不占用无线资源。寻呼过程的发生主要是在PCF收到了由网络服务端发来的下行包，此时若寻呼AT成功，则PCF发出重激活消息，带有空链路消息为Actve Start的A11-Registration-Request消息，若请求成功，则AN寻呼过程完成，记为一次寻呼。
3.2.2 AN寻呼CDR合成方法
4 现网数据测试方法及测试结果
结合流程分析，通过VS2010编写成独立的功能模块加入到原有的监测系统中系统，利用现网R-P接口采集而来的数据进行了测试，其相关的测试结果如下。
AT主叫CDR合成流程如图6所示，其中省略了PPP链路建立消失的显示。时间统计信息[8]如表1所示，CDRID记录了当前连接的时间以及流程数，如第一列表示的是2013年1月30日12时的第一条流程CDR数据统计。表2列出了主叫的时延及请求计数。通过以下的统计数据可以计算出主要服务的延迟率，以及相应的失败次数，两个表格中根据统计的时间和Grekey可以根据全局Hash表索引相应的IMSI，进而最终当次失败的A11主叫。
比如表1中的第5条消息，就出现了超时出表的状况，这属于A11主叫失败的一种情况，相当于在AT发出了A11注册请求之后，依旧没有响应的业务数据到来，如果该条连接失效出现多次，此时通过对该条消息的分析，借助其GREKEY搜寻对应的Global哈希表找到其服务的小区和网络以检查排除问题。
为了更直观地表现用户分组数据的服务质量，根据输出的统计数据，结合数据库的统计技术[9]，按照业务开始时间与业务完成的延迟两个维度，输出实时的延迟变化曲线，如图7所示。
图7中记录的是AT主叫过程从系统运行时10点2秒之后的主叫业务延迟变化[10]，图中较大的突起，表明有可能出现了AT主叫业务发起失败的现象。
AN寻呼连接时间统计如表2所示，同样根据寻呼的延迟，可以判断特定片区内用户数据业务的体验状况。结合A11的主叫延迟分析，可以对某片区内的数据业务体验进行综合的分析。比如某条CDR记录，其延迟相比其他连接略显异常，可以推断其用户的重激活过程不顺畅，造成的原因可能用户所在片区网络堵塞等等。这里仅仅为定位故障的一个小例子，根据程序统计，目前已经总结出多种推断原因，为监测系统的管理者提供参考。
图8记录的是10点01分40秒之后系统运行的实时寻呼业务延迟变化，可见延迟的波动较大，这是因为在寻呼过程中，用户所处网络环境优劣有可能不稳定造成多次重发寻呼信息，从而增加了寻呼业务的延迟。
5 结语
相关文章：
最新高考心理讲座主持词(五篇)01-23
联网接口01-23
高考报名工作会议上的讲话 高考报名会上的讲话(4篇)01-23
在全市公务员考试工作会议上的讲话五篇01-23
总线接口01-23
2025年高考讲座主持词开场白和结束语 高考讲座主持人主持词(通用12篇)01-23
接口优化01-23
交换接口01-23
数字接口01-23
算法接口01-23
