📚 课程目录第3章 EventReport发送流程

3. EventReport 发送流程：应用层触发、协议封装、发送队列管理、物理层发送

EventReport 的发送流程是理解其丢失与重传机制的基石。一个完整的发送路径需要经过四个核心阶段：应用层触发、协议封装、发送队列管理以及物理层发送。任何一个环节的异常都可能导致报文丢失或延迟，进而触发重传逻辑。本节将逐层剖析这一流程，并给出各阶段的调试关注点。

调试提示： 在排查 EventReport 丢失问题时，建议首先确认报文是否成功离开“应用层”并进入“协议栈”。大量丢失案例的根因并非无线环境恶劣，而是应用层触发条件未满足或队列溢出。

应用层是 EventReport 发送的起点。当终端设备检测到特定事件（如小区切换、测量报告触发、业务请求）时，应用层会构造事件数据并调用底层发送接口。

  关键调试指标：
  事件触发频率（次/秒）
应用层到协议栈的接口调用成功率
应用层缓冲区溢出计数

原始数据进入协议栈后，需要经过多层协议封装才能成为适合在空口传输的帧。以 3GPP NR/LTE 协议栈为例，典型的封装路径如下：

协议层	封装动作	添加头部长度（典型值）	调试关注点
PDCP	添加序列号（SN）、完整性保护、加密	2~4 字节	SN 连续性、加密配置
RLC	分段/级联、添加 RLC 头部	2~3 字节	分段偏移、重传计数
MAC	逻辑信道优先级处理、添加 MAC 子头	2~4 字节	逻辑信道 ID、缓存状态

常见陷阱： 协议封装阶段最容易出现的问题是 PDCP 序列号回绕（wrap-around）和 RLC 分段重组失败。当调试日志中出现“PDCP SN discontinuity”或“RLC reassembly timeout”时，应优先检查封装逻辑。

封装完成后的数据单元（PDU）会进入发送队列。队列管理机制直接决定了报文的发送顺序、优先级调度以及拥塞控制。常见的队列模型包括：

  队列溢出阈值： 当队列深度超过设定阈值（例如 100 个 PDU）时，新进入的报文将被直接丢弃。这是 EventReport 丢失的常见原因之一。建议将队列深度监控纳入调试工具。

物理层负责将 MAC PDU 最终映射到空口资源上发送。这一阶段涉及资源调度、编码调制、功率控制等关键操作。

调试建议： 物理层发送失败通常表现为“UL grant missing”或“HARQ NACK 持续增加”。在调试工具中重点关注：
① 上行授权（UL Grant）的分配频率；
② 物理层 HARQ 重传次数分布；
③ 发射功率是否达到 UE 最大功率限制。

将上述四个阶段串联起来，可以得到 EventReport 发送的完整链路。以下表格总结了每个阶段的核心调试要点：

阶段	核心调试日志关键字	典型异常	排查方向
应用层触发	EVENT_TRIGGER, APP_SEND	触发频率为 0、接口返回错误	检查事件条件配置、接口超时设置
协议封装	PDCP_TX_SN, RLC_SEG	SN 跳变、分段重组失败	检查 SN 回绕处理、RLC 窗口大小
队列管理	QUEUE_ENQUEUE, QUEUE_DROP	队列溢出、调度延迟	调整队列深度、优先级权重
物理层发送	UL_GRANT, HARQ_NACK	授权缺失、HARQ 连续 NACK	检查资源调度算法、MCS 选择、功率余量

综合调试建议： 当 EventReport 出现丢失时，不要直接定位到物理层。建议按照“应用层 → 协议栈 → 队列 → 物理层”的顺序逐层排查。在日志中为每个阶段添加唯一标识（如 Transaction ID），可以快速追踪报文在整条链路中的流转状态。