1 引言

过去电力系统的行政交换网以电路交换为主, 为日常行政办公提供优质的语音, 传输等通信业务. 随着业务的不断增加, 现有的程控设备已不能满足发展的需求, 国网公司近年来逐步在全国推广IMS技术^[1].

电力公司现有的IMS系统基本可以满足企业员工的正常通话的需求, 但是公司不能获取终端的详细通话记录和将通话记录保存到公司的后台数据库中, 无法提供给员工们查询来电信息^[2]. 对于传统的路由协议仍存在的传输时延长、路由发送成功率低、链路断裂频繁等问题, Sukdea Yu等^[3]提出了一种贪婪边界优势路由(GBSR). 当节点面向局部最大值时, 节点生成边界优越图而不是生成平面图, 恢复模式中的数据包可以使用图形尽可能快地从恢复模式中退出. 但其是在链路路由断裂的条件下, 再进行路由的恢复, 这样的恢复具有很大的时延性. Bilal等 ^[4]提出了 FMHR 算法, 该算法在基于贪婪算法选择最远的下一跳同时, 还考虑到下一跳节点的速度和方向, 增加了链路的相对稳定性. 但方向很难精确确定, 这也将大大增加计算负载和额外开销.

通过查阅相关资料, 能够完全适配于IMS体统的路由协议很少, 根据现有路由协议的缺点, 提出一种一种基于锚节点可靠路由协议(RRCP), 可以降低路由故障和数据丢失的频率, 同时保持较低的路由开销, 在源节点和目的节点之间建立更稳固的路由.

2 基于IMS的监控系统

如图1, 该系统首先将域外和域内的通话流量镜像到一个端口, 存储到流量捕获模块中; 然后把捕获的流量利用SIP协议进行解析处理, 获得一些必要的报文参数^[5]; 接着分析和处理呼叫数据记录, 生成通话记录; 最终可以将用户的通话记录保存到公司的后台数据库中, 便于提供给终端系统查询. IMS的监控系统架构如图2.

方法流程为:

S1: 将P-CSCF端口及AGCF端口的流量通过端口镜像技术保存到一个端口上. 域内的用户通过交换机连接到P-CSCF端口, 域外的用户通过交换机连接AGCF端口, 用户的通话流量存在各自对应的端口中, 流量不能同时保存到一个端口, 这样就不能很好地处理端口的流量. 所以将P-CSCF和AGCF端口通过交换机连接到镜像端口, 然后利用端口镜像技术监听流量的数据包, 并将网络数据流传递给流量捕获模块, 这时所需要处理流量可以同时保存到一个镜像端口中, 然后将其映射到IMS外的通话记录分拣服务其中, 可以方便地进一步处理数据.

S2: 依次剥离以太网帧、IP报文和udp报文, 将流量数据进行SIP协议解析.

S3: 根据呼叫状态获取所需的报文参数, 并通过参数整合出对应的通话记录, 保存到数据库中. 要想生成完整的呼叫通话记录(CDR), 使用SIP协议解析的字段信息较多, 并且呼叫状态的不同所需解析的报文字段也不一样.

当接收到Invite请求时, 并且有ACK进行响应请求, 表明该呼叫正常接通, 此时SIP协议会解析From字段的标签参数和To字段的标签参数, From和To标签参数是最小32位宽的真正随机数, 可以识别主叫方和被叫方, 然后通过获取calling Number和 called Number 提取到通话的主叫号码和被叫号码. 在这次呼叫应答过程中, 解析获取Call ID字段的值, Call ID是给定时间内IMS域内的唯一ID, 可以识别出此次会话的唯一连接. 当在这次Invite请求响应结束接收到Bye消息时, 表明这个会话正常结束, 利用SIP协议解析报文获得request Time、start Time 和 end Time 等标签. 其中, request Time、start Time 和 end Time分别记录通话的请求、开始和结束时间, start Time 仅在通话正常接通的情况下记录. 这时就会生成一条临时的通话记录存储到数据库中.

当接收到Invite请求时, 若没有ACK响应请求, 会通过SIP解析出响应消息状态码, 若是480、486、487, 则表示对方没有接听电话. 此时解析出From字段的标签参数和To字段的标签参数, 依然可以判断出主叫方和被叫方, 然后通过获取的calling Number和 called Number 提取到发起会话的主叫号码和被叫号码, 最后利用SIP协议解析报文获得request Time标签, 可以获知主叫方发起会话请求的时间. 此时也会生成一条临时的通话记录保存到数据库中.

S4: 通过在IMS核心网集中分拣一个用户下的所有终端电话呼叫SIP信令, 合并同一身份对应的多终端来电信息后生成的呼叫数据记录. 进行剔重处理, 并根据request-uri规整短号. 上一步中生成的通话记录临时保存到数据库中, 当同一个用户再次向一个用户发起同样的请求时, 首先通过From和To标签判断主被叫, 然后利用Call ID进行强识别, 若Call ID相等的话, 则该条通话记录不会被保存到数据库中, 以达到剔重的效果. 如果sip header中的From标签和To标签中都是短号的话, 则会从request-uri头域取长号前缀, 来补齐短信.

S5: 合并同一身份对应的多终端来电信息后生成的呼叫数据记录, 生成呼叫详细通话记录, 并将生成的记录存储到终端. 经过上述步骤, 本系统利用表格将生成的呼叫详细通话记录存储到终端, 以方便用户可以查询通话记录.

3 基于锚节点的可靠路由优化算法

在上一节基于IMS的监控系统S3流量捕捉模块中, 流量当前IP报文通过预测链路生命期之后的候选中继节点的存在来识别更可靠的链路进行转发.

因此本章提出路由优化的协议(RRCP)主要包括3个方面: 路径选择、下一跳转发机制和预测中继节点的优化. 首先是路径选择方面, 在实际数据转发之前增加一个选择路径的过程, 将端到端的连通概率作为转发路径的依据. 其次是下一跳转发机制的优化, 不采用基于贪婪算法选择最远下一跳, 而是选择最靠近下一个锚点的邻居节点作为下一跳节点. 最后是预测中继节点方面, 先确定下一个中继节点并计算出链路生命期. 再对当前中继节点的邻居节点进行位置预测, 随后判断邻居节点在链路生命期内是否离开了当前中继节点的通信范围, 若离开了当前中继节点的通信范围, 则当前中继节点发送阻塞的消息给起始锚节点, 锚节点立刻选择另一条最短路径.

3.1 路径选择机制

当源节点S开始发送数据分组之前, 首先要进行转发路径的选择, 即构建通往目的地节点D的路由路径. 因此源节点S首先发送路径发现请求的报文信息, 源节点的速度向量以及目的节点的位置等均被记录到广播报文的报头中^[6]. 接收到广播报文的邻居节点, 计算离上一跳节点的连接概率.

假设n条路径中的某一条路径 $Path(i)$ 由k条链路构成, 每条链路的协助连通概率为 ${P_l}$ ,其中 $l = 1,2, $ $3, \cdots, k$ , 则该 $Path(i)$ 的连通概率为:

$ {P_{path(i)}} = \prod\limits_{i = 1}^k {{P_i}} $

(1)

转发路径发现请求的每个节点通过其自己的数据重写报文分组中的“前节点的速度向量”字段. 如果节点的速度向量的方向与“前节点的速度向量”字段不同(即非平行), 则节点将锚点添加到广播包, 锚节点包含当前节点的坐标和先前节点的坐标以及它们各自的速度矢量^[7]. 当广播路径通过新的交叉时, 则将另一个锚节点添加到分组^[8]. 最后, 当广播到达目的地时, 目的地节点到源节点的整个路径被记录为一组中间锚节点.

目的节点D在接收到多条路径的信息后, 目的地节点D选择一条协助连通概率最高的路径作为最优路径^[9]. 随后路由答复从目的地节点D发送回源节点S. 路由答复是单播分组, 其包含目的地的坐标和速度向量、一组锚节点信息以及其他一些到达目的地的路上路由请求收集到的信息. 当源节点S接收到路由答复后, 记录下路径信息并可以开始发送数据分组.

3.2 下一跳转发机制

该路由方案采用了锚节点, 源节点接收到目的地节点关于这组锚节点的速度矢量、位置等信息. 当前中继节点在选择下一跳的时候, 并不采用传统的贪婪算法将数据分组转发到地理上更接近目的地的邻居节点, 而是选择最靠近下一个锚点的邻居节点.

为了避免多次尝试逐渐接近下一个锚节点, 每次转发的节点检查其位置和下一个锚点的位置是否分开小于节点覆盖范围的一半. 如果是, 则标记该锚点, 并且选择下一个锚节点作为下一个转发节点; 如果不是, 则继续该过程, 寻找下一个邻居节点直到分组到达其目的地节点^[10].

3.3 预测候选中继节点方法

假设锚节点为在报文传输途中路径的交点处, 定义两个锚节点之间的路段为链路^[11]; 在传输过程中, 锚节点接收到数据分组, 选择最靠近的链路, 将分组转发给此链路; 如果锚节点发现所选择的链路阻塞, 则选择最接近下一个锚点的链路^[12,13]. 如图3所示, 在最接近下一个锚节点的链路(即链路1)上出现阻塞的示例场景. 在这种情况下, 锚点节点A在从中继节点接收阻塞消息之后, 将重新规划路由到的下一个最接近下一个锚节点的链路2.

具体算法的实施方法流程可以分为以下4个步骤:

步骤1. 当前中继节点将最接近下一个锚节点的目的地确定为下一个中继节点, 并计算出此链路的生命期. ${P_n}$ 和 ${P_c}$ 分别表示新选择的中继节点和当前中继节点. 使用邻居表中的信息, ${P_c}$ 将最接近下一个锚节点的节点确定为下一个中继节点 ${P_n}$ , 根据 ${P_c}$ 和 ${P_n}$ 的位置及速度信息可以估计出此链路的生命期 $it\_exp ire$ .

$it\_exp ire = \dfrac{{R - \sqrt {{{({x_n} - {x_c})}^2} + {{({y_n} - {y_c})}^2}} }}{{\left| {\left| {{{\overset{\lower0.5em\hbox{$\smash{\scriptscriptstyle\rightharpoonup}$}} {V} }_n}} \right| - \left| {{{\overset{\lower0.5em\hbox{$\smash{\scriptscriptstyle\rightharpoonup}$}} {V} }_c}} \right|} \right|}}$

(2)

步骤2. 对当前中继节点的邻居节点进行位置预测.

$\begin{split} n{x_i} = nb\_{x_i} + nb\_d{x_i} \times lt\_exp ire \\ n{y_i} = nb\_{y_i} + nb\_d{y_i} \times lt\_exp ire \end{split} $

(3)

$D = \sqrt {{{({x_c} - n{x_i})}^2} + {{({y_c} - n{y_i})}^2}} $

(4)

步骤3. 通过式(3)对 ${P_c}$ 的邻居节点 $i$ 的位置进行预测: 通过式(4)计算此时邻居节点 $i$ 与 ${P_c}$ 的位置之间的距离. 若 $D < R$ , 则选择的这条链路并无阻塞, 因此节点 ${P_c}$ 发送一个无链路断裂的消息给起始锚点, ${P_c}$ 继续正常接收数据和发送数据; 若 $D \ge R$ , 则选择的这条链路有阻塞, 则表示当链路生命期结束时, 在所选的链路上有链路断裂, 节点 ${P_c}$ 接收到这样的信息后, 立刻发送包含的阻塞消息以及 ${P_n}$ 的位置给起始锚节点, 起始锚节点在高速缓冲区中保存 $it\_exp ire$ 的信息, 并选择另一条最短的链路来传递信息.

步骤4. 在 $it\_exp ire$ 到期前, 定义一个预定间隔, 每过一次预定间隔, ${P_c}$ 便重新检测阻塞的链路上是否依旧是D≥R, 若发现D<R, 则向起始锚节点发送无阻塞消息, 此时起始锚节点可从高速缓冲中去掉 ${P_c}$ 的 $it\_ $ $exp ire$ 消息, 并恢复该阻塞链路的非阻塞状态.

4 性能分析与评价 4.1 路由算法仿真实验

本文利用的网络仿真工具是OMNeT++软件. 实验设置基于3 km×3 km的数据传输情景: 5条横向和5条垂直的数据传输通道. 数据沿着给定的传输路径行进, 直到它们到达交叉传输口, 然后以相等的概率随机地在可用方向之一(直行, 向右或向左)中继续传输. 实验的参数设置如表1所示.

此算法由路由故障数、丢包率、数据交付延时、平均跳数这4个度量衡量, 并根据GBSR和FMHR路由协议来评价所提出的基于锚节点的可靠路由优化协议的性能^{[14, 15]}. 根据实验参数设置完毕后, 接下来分别对GBSR和FMHR路由协议以及RRCP协议进行仿真, 仿真的变量是节点密度, 用recordScalar函数输出程序中4种度量参数的值. 根据仿真结果在Matlab中画出节点密度与4种度量参数的关系.

图4显示路由故障的数目随着节点密度的增长而减小, 当节点密度小于20个/km时, RRCP协议与GBSR和FMHR协议相比有更低的路由故障. 在更密集部署的网络的情况下, 这3种协议的性能在路由故障方面相似. 图5显示丢包率随着节点密度的增长而减小. 当节点密度小于30个/km时, RRCP协议与GBSR和FMHR协议相比有更低的丢包率, 在更密集部署的网络的情况下, 这3种协议的性能在丢包率方面无太大差别. 图6显示平均跳数随着节点密度的增长而减小. 也就是说, 当网络密集节点密度对GBSR、FMHR协议或RRCP协议没有显著的影响. 但是当节点大于30个/km时, GBSR和FMHR路由协议显示出比RRCP协议稍微更小的平均跳数. 图7显示数据分组的延时主要取决于数据包传输过程中的跳数. 对于GBSR、FMHR协议和RRCP协议, 数据交付延时随着节点密度的增加而减小. 也就是说, 当网络密集, 节点密度对GBSR、FMHR协议或RRCP协议没有显著的影响. 但是当密度大于30个/km时, GBSR和FMHR协议显示出比RRCP协议稍微更小的数据交付延时.

4.2 IMS监控系统的测试

以上验证了本文算法的优越性, 还需对监控系统进行功能性测试. 如图8所示, 使用RRCP协议后, 较传统的IMS监控系统, 在监控响应时长上有较大改善. 实验组与对照组同时对相同的信息量进行监控, 分别记录系统在处理10、15、20、25、30、35 TB数据量后, 系统监控的响应时长,实验中保证实验组与对照组处理参数相同, 其结果如图8所示.

分析图8可知, 在对监控响应时长对比中, 信息处理数据量的不断增加, 实验组与对照组的监控响应时长也都不断增加, 而当数据量达到35 TB时, 实验组最高时长为0.85 s, 对照组最高时长为1.25 s. 因此可以看出, 优化了路由协议后, 监控响应时长得到有效降低.

5 结论与展望

本文研究电力物联网IMS和路由协议的网络特性, 提出了一种基于锚节点可靠路由的电力IMS电话终端呼叫记录集中分拣方法, 此方法一方面给员工带来便利, 提高了工作效率, 另一方面该系统IP报文传输中所采用的RRCP路由协议, 具有开销少、传输数据丢包率低、通信链路稳定的优点, 最后我们还利用OMNeT++软件对改进的路由协议进行验证, 实验证明提出的路由优化协议在路由的故障数, 丢包率, 数据交付延时, 平均跳数上显示出更好的性能, 并在实际的监控系统测试中监控响应时长有效降低.