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将消息的内容进行核对后上报给后台。

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的部署起了重要的作用。