WRNC系统中单用户跟踪的设计

      随着3G网络的迅猛发展，WCDMA系统正在大规模地商用。以前常用的一些定位手段，如断点调试、LogView等已经越来越难以符合外场的需求。与简单的实验室环境相比，外场定位问题会更加困难，目前针对HSDPA/HSUPA 业务速率不稳和PS业务（Packet Stream数据业务）不通等问题，普通的排查手段显得十分有限，定位难度很大。加上外场用户多、干扰数据大等特殊情况，传统的定位方法根本无法获取单一用户的相关统计信息及流量的跟踪信息，给问题的定位和解决带来了诸多难点。

      本文引入一定的机制，使无线网络控制器RNC（Radio Network Control）内部能够方便、准确地收集到单用户数据处理中各个环节的统计信息，便于快速地对单用户信息进行统计与核对，提高问题分析的效率。

      1 速率问题的产生及现象

      RNC内部速率问题的产生主要有3个原因：(1)用户面处理数据包不当，异常丢包；(2)控制面传递给用户面的接续参数有误，用户面与承载无法衔接；(3)用户面自身在处理各种接续关系时处理不当。

      在实际应用中几种不同情况的速率现象分别为：(1)HSDPA/HSUPA业务进行时上下行速率不稳定；(2)HSDPA/HSUPA业务进行过程中出现速率掉钩；(3)HSDPA/HSUPA PS业务无法达到签约的预期速率；（4） 速率正常。

      2 传统的定位方法及缺陷

      目前，传统的速率定位方法分为3种：SHELL命令定位、DSP打印定位和信令跟踪定位。

      但是对于外场定位来说，这些传统的定位手段却很难实现。首先，SHELL命令定位，外场接口板数量多，承载着不同的业务，需要在接口板之间轮流输入SHELL命令，显得极其麻烦，同时SHELL命令只能跟踪所有的业务流量信息，无法针对特定用户，缺少针对性。其次，外场对于打印有严格的要求，一般不允许开启内部打印，正式的商用局资源本来就比较少，开启内部繁多的打印，会影响整个系统的运行。最后，信令跟踪只是记录控制面的基本信息，对于用户面的检查无法起到真正的帮助作用。

      因此对于此类问题，需要有一个良好的定位方法将问题锁定在具体的接口或者FP层面上。单用户跟踪正是针对这个缺陷设计的，其优点是：(1)数据的上报通过后台信令跟踪来记载，利于观测；(2)数据跟踪以FP为单位，直接定位到业务通道，定位准确；(3)对正常的设备运行不会增加额外的开销，且不需要进行多余的手工操作，使用方便。

      3 单用户跟踪的设计及实现

      3.1 WCDMA系统的整体概述

      WCDMA系统主要由三大核心部分组成，分为核心网(CN)、无线网络控制器(RNC)和基站(NodeB)。RNC连接着CN和NodeB，在整个WCDMA中起着举足轻重的作用。RNC和RNC之间用IUR口连接。RNC分为CRNC(控制RNC)、SRNC(服务RNC)和DRNC(漂移RNC)三部分[5]。

      3.2 单用户跟踪的数据流

      RNC内数据流的路径分为两条，一条是通过IUB口直接进入SRNC，途经IU口到达CN；另一条是通过IUB口先到达DRNC，再由DRNC经IUR口到SRNC，最后到达CN[6]。如果能在每个结点处对各个FP的数据包进行统计，对比各个结点数据的流量，就能迅速定位出数据丢失的接口和FP。

      3.3 单用户跟踪的整体设计

      UTRAN各个接口的协议架构是按照一个通用的协议模型设计的，如图1所示。设计的原则是层间和平面间在逻辑上相互独立。从水平层面来看，协议结构主要包括两层：无线网络层和传输网络层。所有UTRAN相关问题只与无线网络层有关，传输网络层只是UTRAN采用的标准化的传输技术，与UTRAN的特定功能无关。从垂直平面来看，协议结构包括控制平面、用户平面、传输网络控制平面和传输网络用户平面[1]。

      本设计根据UTRAN的协议架构，分为以下几个模块：消息处理模块、控制面、用户面、承载管理模块和信令跟踪模块。

      整个单用户跟踪设计思路如图2所示，其中实线代表控制流，虚线代表数据流。

      对于控制信息来说，后台将媒体面跟踪的任务分配到消息处理模块（Daemon），Daemon通知控制面CP(Control Plane)和用户面UP（User Plane）。控制面在承载链路建立和删除时通知承载管理模块BM（Bear Management,BM）建立和删除相关的承载跟踪。从消息中提取相关信息，并发送消息通知接口板，接口板收到消息后，设置好过滤条件，对处理的报文进行过滤统计。

对于数据业务流来说，收集跟踪信息后，接口板和用户面直接将跟踪信息上报到Daemon。Daemon将消息的内容进行核对后上报给后台。[page]

      3.4 单用户跟踪的实现流程

      为了在现有体系的框架下顺利实现各个接口FP的流量上报，设计如下2个流程：任务的启动和数据的上报及核对。

      3.4.1 媒体面单用户跟踪的启动

      单用户跟踪的启动过程为：

      (1)后台向信令跟踪模块(ToolKit)发送EV_UE_MEDIA_START_REQ的请求消息。消息中携带需要跟踪的IMSI号和跟踪标志位给ToolKit。

      (2)ToolKit采取应答处理机制，收到消息后立马向后台回响应，告知消息已收到。ToolKit内部维护了一张关于UE各种跟踪任务的状态表（TraceUE）。根据消息中的IMSI号来判断，如果ToolKit模块中未能查询到保存的IMSI号，说明该流程错误，直接结束。若IMSI号存在，并且已处于跟踪状态，说明跟踪重复，直接结束。若IMSI号处于未跟踪状态，ToolKit将创建关于该UE的一个上下文，同时保存到TraceUE的信息中，以便将来查询使用。

      (3)ToolKit需要给消息处理模块（Daemon）发送消息EV_START_MEDIA_TRACE。由Daemon根据不同的消息来决定需要给哪些模块发送跟踪消息。

      (4)Daemon向用户面发送媒体面启动的消息EV_START_MEDIA_TRACE。用户面收到该跟踪指示消息后将跟踪信息记录下来，使得在调用承载接口建立连接表时，指示此承载链路上的数据需要跟踪，便于之后从用户面直接上报数据量信息。

      (5)Daemon向各个地面接口(IUB/IUR/IU)发送EV_START_MEDIA_TRACE消息，触发各个地面接口向各自的底层链路发送跟踪指示。

      (6)各个地面标准模块收到媒体面单用户跟踪消息后，根据IMSI号搜索各自保存的关于这个UE相关的传输层信息，启动消息发送机制，对和这个UE相关的承载，依次给承载管理模块发送EV_START_LINK_TRACE消息，触发关于这个UE的底层承载被标记成跟踪态。这条消息不仅需要携带该条承载链路建立时的所有信息(BearId、bindingID、TransportAddress等)，还要加上被媒体面跟踪的标志位。底层承载管理模块BM收到该消息后，需要对承载信息进行遍历和核对，对确实需要跟踪的承载链路进行相关字段的标记，便于以后统计时使用。

      3.4.2 媒体面单用户跟踪的上报时间及核对

      (1)上报时间对齐

      数据的上报都是在一定时间内累积的结果。为了保证业务数据统计的准确性，必须确保各个单板上系统时间的一致性。为了保证这一点，采取统计初始清零时间和统计上报时间对齐的策略。

      统计初始清零时间对齐：在承载链路建立的时候，接口板上对此链路对应的统计信息清零。在用户面处理板上也采用类似的方式对相关承载上的统计清零。

      统计上报的时间对齐通过两种方式实现：(1)约定好上报的粒度，例如15 s、30 s、60 s等。(2)通过单板上绝对时间来对齐。例如在时间对齐的前提下，在每分钟的15 s、30 s、45 s、60 s的时刻进行上报。为了将上报时间对齐，在DSP上新维护一个记录绝对时间的软时钟，软时钟的基准通过HOST同步，HOST可以定期对DSP上的时钟进行校正。

      (2)上报途径

      为使信息核对，设计了两条上报途径：(1)CP各个接口模块与UP之间都有保活消息，保活消息将触发UP上报用户在不同接口(IUB、IUR、IU)上的所有承载链路的统计。UP收到保活消息后，发现该用户被媒体面跟踪，则调用数据上报接口上报统计，这时用户面就会查询启动时被跟踪的承载信息。通过内部机制，将跟踪信息转发到Daemon，直至送给后台。(2)CP各个接口模块在给UP发送保活消息时，发现该用户被媒体面跟踪，则给BM模块发送数据上报请求消息EV_START_LINKTRACERPT_REQ，BM收到消息后，根据本地保存的跟踪用户信息，通知接口板。接口板将跟踪信息上报到Daemon，直至后台。

      (3)统计信息的核对

      用户面在调用承载接口发送报文时，会根据接口中承载被跟踪的信息进行过滤。在接收报文时，会根据承载连接表中的信息，对此报文进行过滤。

      对于接口板来说，承载管理模块需要对统计的信息设置过滤条件。对于不同的承载类型，过滤条件是不一致的。在ATM方式下，IUB、IUCS、IUR需要根据VPI、VCI、CID的信息来完成对出入网元信息的过滤，IUPS需要根据对端和本端的TEID来完成出入局的过滤。在IP方式下，IUB、IUCS、IUR根据本端IP地址和UDP端口号来完成出入网元的过滤，IUPS则需要本端和对端的TEID来判断。

      为了和用户面核对统计信息，对于每一条的承载链路，控制面还需告知承载管理模块过滤方向、接口类型、链路属性和用户的全局标识信息。

      Daemon通过对两种途径上报的数据进行汇总和核对，防止了统计信息的不一致，提高了信息上报的准确性。

      4 单用户跟踪的测试效果

      本设计在WRNC系统中进行了测试和验证。图3是业务上报消息中的Iu口的信令解析。

      其中包括单用户跟踪的一些统计信元。如：IuupUlPsRecvNum、IuupUlPsSendNum、IuupDlPsRecvNum和Iuup DlPsSendNum等，分别记录上下行PS域的收发数据量。从该图中可以看到IuUp的上行收发数据量都为21，代表此FP的数据收发正常，未出现异常情况。

      从图3中可以看到该方案成功地实现了业务数据的收集和上报。后台的信令跟踪清楚地记录了各个标准接口中各个FP的类型和数据的收发信息。

      该方案实现了在RNC内部各个接口用户数据的上报和统计，彻底解决了传统速率问题定位的复杂性和不准确性。定位准确、利于观测和便于操作使得该定位方法大大优于传统的定位方法。

      在商用局的应用中，单用户跟踪能大大缩短速率问题的定位时间，极大地降低了外场其他用户的干扰。这项设计为提高运营商的满意度和快速推进中国3G的部署起了重要的作用。