4、测量值的采集上报流程
 图3 测量值的采集处理流程 测量值的采集上报流程如图3所示，方案设计了2种方式（物理层周期性上报和事件触发测量上报）的处理流程，实际系统一般都把这两种方式相结合使用。
物理层周期性上报方式是OAM发起测量请求。RRM处理请求并发起测量，物理层周期上报的流程。
事件触发测量值上报方式不涉及OAM测量的请求发起，是当触发事件出现时，物理层主动将测量报告上报给RRM的测量模块。
4.1 RRM测量值采集上报
4.1.1 RRM发起测量
RRM发起测量流程见图4，图中AM表示算法模块，MCM表示测量模块。
 图4 RRM测量发起流程
各个算法模块根据需求发测量请求消息（MEAS_REQ）给测量模块，启动定时器等待应答，测量模块在定时器设定的时间内收到MEAS-REQ随即发测量请求消息应答（MEAS_ACK）。如果在定时器设定时间内没有收到MEAS_ACK则丢弃这个测量请求消息并重发。
测量模块解析消息MEAS_REQ，根据测量算法判断是Uu口测量还是Iub口测量。根据解析后的信息查找数据库中对应的字段信息，如果其对应的测量字段设置为允许，则可以进行以下步骤。
测量模块查找数据库，获取测量方案和测量参数配置，连同算法模块所发的测量请求消息一起组合成测量控制消息（MEAS_CTR）发给相应的测量进程（Uu或Iub测量进程）发起测量。
4.1.2 物理层测量上报到RRM
测量结果的上报可以是周期性的，也可以是基于一些特定事件触发的。上报流程（见图5）如下：
 图5 RRM测量值上报流程 Uu或Iub口测量进程在收到测量控制消息（MEAS_CTR）后，定时器定时时间到（周期性测量报告）或触发事件出现（事件触发测量报告）时将测量报告组织成测量报告消息（MEAS_REPORT）发给RRM的测量模块。测量报告包括UE部分和小区部分。 测量模块收到MEAS_REPORT首先按照事先定义的接口数据结构进行解码。 测量模块再根据测量报告类型的不同，查找对应的算法模块。 各个对应的算法模块根据解码后的MEAS_RE_PORT进行事件触发处理，在UE部分包括：给用户分配或重配专用物理信道，重配置、小区切换等；在小区部分包括：判断小区负载状态变化，判断码表信息变化，接纳／释放一个新用户。 各个算法模块再调用OAM中Agent的接口函数，输出所需要的测量信息。 4.2 OAM测量采集上报
OAM采集发起流程是：Server发送测量任务消息MEAS_REQ给OMP板上的Manager进程，Manager进程根据任务消息查询数据库，找到相应的CMP板，转发给该板上的Agent进程，Agent进程接收到测量任务消息后，判断消息是否有效。如果有效则返回成功应答MEAS_ACK给Manager进程；如果判断无效，则返回参数错误应答MEAS_ACK给Manager进程。Manager进程将应答MEAS_ACK转发给Server，如图6所示。
 图6 OAM采集流程 测量值上报由RRM调用0AM提供的函数来实现的，Agent读取RRM上报UE或小区测量信息，发送给Manager。Manager收到RRM发来的测量信息数据后，加上时间信息发给Server，如图7所示。
图7 OAM上报流程 5、结束语
上述的TD-SCDMA测量采集上报方案已得到实际验证。是可行的，处理效率也较高，这种方案的优势主要有： 测量采集上报方案划分为OAM模块和RRM模块，结构清晰，易于实现。同时，RRM划分为测量模块和算法模块，当测量值上报后处理分发到各个算法模块。各个算法模块就可以做相应的事件触发。各模块间耦合性小，方便功能扩展。 框架各模块间以请求-应答的消息传递方式进行交互，通过合理设计交互数据结构和通信流程，可以简化流程。 在OAM部分，将前台处理流程划分为Manager总控部分和Agent执行部分是一个创新。任务由总控分成驻留于CMP板上的各个子任务，便于控制不同的驻留于CMP板的子任务。同时，这种结构便于扩展，对于子任务的增加只需要增加CMP单板和接口函数。对其他CMP板及其驻留其上的子任务没用任何影响。 OAM和RRM之间通过驻留于CMP板上的接口函数调用关系来获取测量结果，这是对请求-应答消息传递通信机制的一种补充，也是一个创新。这种处理方式方便各个算法模块在事件触发的时候灵活地将测量结果发给0AM，而不是单纯地统一处理，屏蔽了算法模块处理机制千差万别造成的处理麻烦。不需要定义统一的接口数据、消息体结构，而是一对一的处理，方便了算法的优化。
| | | | |
