MOshell (8) : 解码爱立信RNC的UETR/GPEH事件测量体系 - 实践

“在3G网络中，99%的问题不是‘发生了什么’，而是‘为什么发生’。而事件日志，就是那1%的答案。”
—— 爱立信 RNC 故障定位原则

---

引言：为什么大家得“事件”？

在传统性能监控中，大家依赖周期性计数器（如每15分钟统计一次RRC连接成功率）来评估网络健康。这类资料适合趋势分析，却难以回答关键问题：

• 某次呼叫为何失败？
• 某个用户为何频繁掉线？
• 某小区为何突发高干扰？

此时，事件驱动型测量（Event-Based Measurements）便成为不可或缺的“显微镜”。在爱立信RNC中，这一能力凭借UETR（UE Trace Record）、CTR（Call Trace Record） 和GPEH（General Purpose Event Handler） 三大事件扫描器实现，可实时捕获信令流程、内部状态变更与错误指示，为根因分析（RCA）献出原子级证据。

本文将带您深入RNC事件体系，从查看事件列表、提取与解码ROP材料，到动态配置扫描器过滤器，完整还原一套面向实战的事件诊断工作流。

---

一、事件类型概览：UETR、CTR 与 GPEH 的分工

在RNC CLI中，执行 emom 命令可列出所有可用事件：

RNC11> emom uetr

输出显示三类核心事件源：

1.1 UETR（UE Trace Record）

• 用途：跟踪特定UE（用户设备）的无线行为
• 典型事件：
  • MEASUREMENT_DOWNLINK_TRANSPORT_CHANNEL_BLER
  • MEASUREMENT_UE_TRANSMITTED_POWER
  • RNSAP_RADIO_LINK_SETUP_REQUEST
• 适用场景：用户级问题复现（如某IMSI频繁掉话）

1.2 CTR（Call Trace Record）

• 用途：记录完整呼叫流程（CS/PS）
• 典型事件：RAB建立、Iu释放、切换信令
• 适用场景：端到端呼叫失败分析

1.3 GPEH（General Purpose Event Handler）

• 用途：捕获RNC内部模块事件与错误
• 子类丰富：
  • RANAP_ERROR_INDICATION
  • INTERNAL_SOFT_HANDOVER_EXECUTION
  • INTERNAL_CONGESTION_CONTROL_CHANNEL_SWITCH_AND_TERMINATE_RC
• 适用场景：系统级故障、资源拥塞、算法异常

关键区别：

• UETR/CTR 聚焦用户/呼叫维度
• GPEH 聚焦架构/功能模块维度

---

二、事件列表查看：emom 命令详解