51学通信

深度解析 3GPP TS 23.273：6.6 & 6.7 物联网终极省电奥义：低功耗事件报告流程

22分钟阅读

深度解析 3GPP TS 23.273：6.6 & 6.7 物联网终极省电奥义：低功耗事件报告流程

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“6.7 Low Power Periodic and Triggered 5GC-MT-LR Procedures”的核心章节。本文旨在通过一个濒危野生动物追踪的场景，为读者系统性地揭示5G为物联网（IoT）定位所设计的终极省电秘籍，深入剖析UE如何在RRC_IDLE和RRC_INACTIVE等深度“休眠”状态下，高效、低耗地完成事件报告。

序章：雪山之巅的“隐形守护者”

在之前的篇章中，我们探讨了各种5G定位服务的流程，但它们大多运行在一个默认的前提下：UE的电量是相对充裕的。然而，当5G的触角延伸至广袤的物联网世界，面对数以亿计、散布在无人区的传感器、追踪器时，功耗便超越一切，成为决定技术能否落地的生死线。

今天，我们的主角是一枚肩负重任的智能追踪项圈——“追风者-S01”。它被佩戴在一只生活在高原雪山地区的珍稀雪豹身上。国家公园生态保护中心（扮演LCS客户端/AF）需要通过这个项圈，长期、不间断地追踪雪豹的活动轨迹，研究其习性，并在它靠近人类活动区时发出预警。

这个任务对“追风者-S01”提出了近乎苛刻的要求：

  1. 超长续航：一次部署，必须保证电池能持续工作数年。
  2. 按需精度：在广阔的栖息地内，每天报告几次位置即可；但当雪豹进入预设的“高风险区域”（如公路附近）时，需要更频繁、更精准的定位。
  3. 极端环境：雪山地区信号覆盖不稳定，设备必须能适应频繁的断连与重连。

传统的定位方式在这种场景下无异于“自杀”——频繁的唤醒和信令交互会在几周内就耗尽电池。为此，3GPP在6.7章节中，祭出了一系列专为蜂窝物联网（CIoT）优化的“黑科技”，将UE的功耗降到了极致。

章节合并与说明：关于6.6章节

在继续深入6.7章节之前，我们必须对6.6章节做出说明。根据解读规则，当一个章节内容极少时，我们会在相邻章节的解读中进行简述。

6.6章节的标题是“NG-RAN Location Service Exposure Procedure”（NG-RAN位置服务暴露流程）。其在规范中的内容仅有一句话：

The NG-RAN Location Service Exposure procedure is not supported in this Release of the specification.

解读：这意味着，在当前的Release 18版本中，3GPP标准并未定义一套允许外部应用直接从NG-RAN（即基站侧）获取位置服务的标准化流程。虽然基站自身拥有丰富的无线测量信息，具备一定的定位能力，但将其能力直接对第三方开放的接口和流程尚未标准化。所有的位置服务暴露，仍然需要通过核心网（如6.5章节定义的经由NEF）来进行统一、安全的管理。因此，我们跳过此节，直接进入技术细节极其丰富的6.7章节。

1. 低功耗流程的基石：CP CIoT 5GS优化与EDT (6.7.1)

6.7.1章节“Event Reporting with no change of LMF”为我们展示了最基础的低功耗事件报告流程。其核心魔法，源于一项名为“控制面蜂窝物联网5GS优化（Control Plane CIoT 5GS Optimisation）”的技术。

它的核心思想是：对于物联网设备上报的、数据量极小的事件报告（通常只有几十或几百字节），没有必要再走一遍“兴师动众”的标准RRC连接建立→数据传输→连接释放的完整流程。取而代之的，是利用一种“轻量级信令搭便车”的机制。

**早期数据传输（EDT - Early Data Transmission）**正是这一理念的体现。它允许UE在RRC连接建立的早期阶段，就将少量上行数据“塞”进初始的信令消息中，发送完毕后，网络可以立即释放连接，UE随即返回CM-IDLE深度睡眠状态。整个“唤醒-工作-睡眠”的周期被压缩到最短。

1.1 场景设定与流程启动

保护中心为“追风者-S01”设置了一个简单的延迟定位任务：周期性事件，每6小时上报一次位置，用于常规轨迹记录。

  1. Steps 1-23 for the deferred 5GC-MT-LR procedure for periodic or triggered location events in clause 6.3.1 are performed with the following exceptions.

流程的第一步，是复用6.3.1中的任务建立过程。但有两个关键的“例外”：

  • AMF的“授权”：在Step 14，AMF向LMF发起DetermineLocation请求时，会附带一个重要信息：“这个UE（项圈）支持并被允许使用CP CIoT 5GS优化”。
  • LMF的“许可”：在Step 16，LMF向项圈下发“守护契约”（LCS Periodic-Triggered Invoke Request）时，会明确地“许可”它：“你可以使用CP CIoT 5GS优化来发送后续的事件报告”。

这份“授权”和“许可”，就是项圈能够使用EDT这条“VIP快速通道”的通行证。

1.2 一次“轻声的耳语”：EDT事件报告流程 (Steps 2-14)

6小时后，项圈的闹钟响起。它从CM_IDLE状态短暂唤醒，发现需要上报位置。此时，它并没有发起标准的服务请求，而是启动了EDT流程。

  1. The UE determines whether to report the event detected … using Control Plane CIoT 5GS Optimisation or using a NAS signalling connection.
  2. If the UE and ng-eNB node both support EDT, the UE sends an RRCEarlyDataRequest message … and includes a NAS control plane service request.

  1. UE决策与发送 (Step 2-3)：项圈决定使用CP CIoT优化。它执行一次本地定位，然后将包含位置信息的事件报告打包成一个NAS消息，再将这个NAS消息“塞”进一条名为RRCEarlyDataRequest的RRC信令中，直接发送给基站。这就像一次“轻声的耳语”，言简意赅。

  2. 网络侧的快速传递 (Step 4-5)：基站收到这个特殊的请求后，立即将其中的NAS消息解出来，通过N2接口上报给AMF。AMF再根据报告中的“延迟路由标识符”，通过N1MessageNotify服务，将报告精准地投递给LMF。

  3. “单程票”的确认 (Steps 6-12)：由于EDT追求的是极致效率，整个确认流程也被高度简化。

    • LMF处理完报告后，向AMF返回一个简单的确认Ack。
    • AMF将这个Ack打包成一个NAS消息，并通过N2接口下发给基站。关键在于，AMF会附带一个“结束指示（end indication）”，告诉基站：“事情办完了，你可以让他回去了”。
    • 基站将Ack通过RRC消息传给项圈，然后立即释放RRC连接。项圈收到确认后，心满意足地再次进入深度睡眠。

整个过程，没有传统流程中繁琐的上下文建立、能力协商、安全模式命令等步骤。一次唤醒，一次上行，一次下行，任务完成。功耗被降到了最低。

2. 跨越山脊的低功耗交接 (6.7.2 Event Reporting with change of LMF)

现在，让我们引入移动性。雪豹“追风者-S01”活动范围巨大，它从A山谷（由LMF1服务）翻越山脊，进入了B高原（应由LMF2服务）。此时，它的下一次周期性报告被触发了。

Figure 6.7.2-1 shows a procedure to enable change of the serving LMF when a UE sends an event report as at steps 3 and 4 in clause 6.7.1.

这个流程巧妙地将6.7.1的低功耗上报与6.4的LMF变更无缝地结合在了一起。

  1. 低功耗上报 (Step 1)：项圈依然按照6.7.1的EDT流程，将带有LMF1“回邮地址”的事件报告，发送给了当前服务它的新AMF（AMF-B）。

  2. LMF变更的触发 (Step 2)：AMF-B收到报告后，启动了6.4中的智能决策。它发现LMF1“不适任”，并找到了新的LMF2。于是，它将报告转发给LMF1，并附上了“请移交案件给LMF2”的建议。LMF1随即与LMF2进行上下文转移。

  3. 携带“新名片”的低功耗确认 (Step 3)：现在，轮到新的LMF2来返回确认Ack了。这个Ack同样被简化，但其中包含了LMF2的“新回邮地址”。它沿着LMF2→AMF-B→基站→项圈的路径被传回。

项圈在一次极低功耗的交互中，不仅成功地上报了事件，还“顺便”完成了LMF的更换。下一次报告，它就会直接使用LMF2的地址，实现了服务的无缝、低耗迁移。

3. “打个盹”而非“睡大觉”：RRC_INACTIVE状态下的报告 (6.7.3-6.7.5)

对于某些需要更快速响应的场景（例如，雪豹进入了预警区，需要更频繁的报告），让UE每次都从CM_IDLE深度睡眠中唤醒，依然显得“太慢、太耗电”。为此，5G引入了一种更“轻”的睡眠状态——RRC_INACTIVE。

  • RRC_INACTIVE vs CM_IDLE：
    • CM_IDLE：UE与网络“失联”，上下文主要保存在核心网AMF中。唤醒需要完整的RRC连接重建，耗时较长（数百毫秒级）。
    • RRC_INACTIVE：UE与网络“暂别”，其大部分RRC上下文被保存在最后一个服务的基站中。唤醒只需简单的“握手”即可恢复连接，耗时极短（几十毫秒级）。

6.7.3到6.7.5章节，正是定义了UE在RRC_INACTIVE这种“打盹”状态下，如何利用**小数据传输（SDT - Small Data Transmission）**技术，实现比EDT更快速、更轻量的事件报告。

3.1 场景：雪豹进入预警区

保护中心为公路沿线5公里范围设置了一个“预警地理围栏”。当LMF下发这个任务时，它可能会指示UE：在此区域内，请保持RRC_INACTIVE状态，并每5分钟报告一次位置。

当雪豹进入该区域，其项圈便切换到了这种新的工作模式。5分钟后，事件触发。

3.2 不同定位方法下的SDT流程

根据LMF在“契约”中预设的定位方法，项圈的行为会有所不同：

Case 1: 下行定位 (6.7.3 DL Positioning)

  • “带回家的作业”：LMF在下发契约时，就已经将一个LPP（定位协议）消息（例如，请求UE测量周围基站的下行参考信号RSRP/RSRQ）作为“作业”布置给了项圈。
  • 触发与上报：事件触发后，项圈在本地完成测量，然后通过RRC Resume Request with SDT，将包含了测量结果的事件报告，快速发送给基站→AMF→LMF。
  • 快速闭环：LMF收到结果后，快速返回Ack，基站通过Subsequent DL SDT将Ack传给项圈，并立即发送RRC Release消息，但指示UE返回 RRC_INACTIVE状态，而非IDLE。

Case 2: 上行定位 (6.7.4 UL Positioning)

  • “发出信号，请求测量”：契约要求网络侧进行上行定位。
  • 两阶段交互：
    1. 第一阶段：事件触发后，项圈先通过SDT发送一个简单的事件报告（不含测量值），告知LMF“我触发了，请准备测量”。
    2. 第二阶段：LMF收到通知后，立即通过网络，指令基站准备接收上行信号，并向项圈下发一个包含UL配置（如SRS发送参数）的RRC Release消息，指示其返回INACTIVE状态。项圈收到后，会按照该配置，短暂地发送一个上行定位信号，然后继续“打盹”。
  • 网络侧完成工作：基站网络完成测量后，将结果上报给LMF进行计算。

Case 3: 上下行混合定位 (6.7.5 UL+DL Positioning)

  • 最复杂的协同：这是上述两种模式的结合，常用于最高精度的定位。
  • 多步舞：
    1. 项圈先发送第一个SDT，其中包含一个请求UL配置的LPP消息。
    2. 网络侧准备好UL定位，并通过第一个RRC Release消息将UL配置下发给项圈，项圈返回INACTIVE。
    3. 项圈执行UL信号发送和DL信号测量。
    4. 项圈发送第二个SDT，其中包含了DL测量结果。
    5. 网络侧返回最终的Ack，并通过第二个RRC Release让项圈继续保持INACTIVE。

尽管复杂，但整个过程都被精心设计，以确保UE的“活动窗口”被压缩到最短，最大化RRC_INACTIVE状态的停留时间，从而实现“准实时”响应与低功耗的兼得。

4. 总结：分层递进的“省电金字塔”

通过对6.7章节的完整解读，我们可以构建一个清晰的5G物联网定位“省电金字塔”：

  • 塔基 (最省电，响应最慢) - CM_IDLE + EDT (6.7.1)：适用于对实时性要求最低的场景，如一天一次的资产盘点。通过CP CIoT优化，实现“耳语式”报告，功耗最低。
  • 塔中 (功耗与响应均衡) - RRC_INACTIVE + SDT (6.7.3-6.7.5)：适用于需要较快响应的场景，如数分钟一次的轨迹跟踪。通过保持“浅睡眠”和利用小数据传输，在功耗和响应速度之间取得了绝佳平衡。
  • 塔尖 (最不省电，响应最快) - RRC_CONNECTED：适用于需要秒级实时定位的场景，如紧急避障。此时UE保持长连接，功耗最高，但能提供不间断的实时数据流。

而LMF变更流程（6.7.2）则像是贯穿金字塔的“垂直电梯”，确保了无论UE处于哪一层，当它发生大范围移动时，其服务都能被平滑地交接到最合适的后台专家手中。

对于“追风者-S01”而言，这套分层、智能的低功耗机制，正是它能够作为雪山“隐形守护者”，持续工作数年的技术密码。

FAQ - 常见问题解答

Q1：CP CIoT 5GS优化和UP CIoT 5GS优化有什么区别？为什么这里用的是CP？ A1：CP代表控制面（Control Plane），UP代表用户面（User Plane）。CP CIoT优化（如EDT）是将少量数据“搭便车”在信令消息中传输，无需建立承载数据的用户面通道（DRB）。UP CIoT优化则是为少量数据传输，快速建立一个轻量级的用户面通道。对于定位事件报告这种信令属性强、数据量极小的应用，通过控制面传输是最高效、最省电的方式，因此本章节主要采用CP优化。

Q2：RRC_INACTIVE状态相比CM_IDLE，省电效果会差很多吗？ A2：是的，理论上RRC_INACTIVE状态下的功耗会略高于CM_IDLE，因为它需要维持与基站的“若即若离”的联系。但它的核心优势在于状态转换能耗极低。从IDLE唤醒到CONNECTED是一次“大启动”，而从INACTIVE恢复到CONNECTED是一次“快速唤醒”。对于需要频繁、快速上报小数据的场景，采用INACTIVE模式，避免了反复的“大启动”，其总功耗反而可能更低。

Q3：什么是SDT（小数据传输）？它和EDT（早期数据传输）是什么关系？ A3：两者都是CIoT优化的核心技术，目标都是传输小数据包，但应用的UE状态不同。EDT用于UE在CM_IDLE状态下发起上行传输。SDT则用于UE在RRC_INACTIVE状态下发起上行或接收下行传输。可以理解为，它们是针对两种不同“睡眠深度”的、定制化的“快速通话”机制。

Q4：谁来决定UE应该进入CM_IDLE还是RRC_INACTIVE状态？ A4：这个决策权主要在网络侧（RAN/AMF）。网络会根据UE的能力、签约信息（是否是IoT设备）、业务类型以及网络负载等情况，来决定在一次数据交互结束后，是让UE进入IDLE深度睡眠，还是INACTIVE浅度睡眠。LMF可以在下发延迟定位任务时，通过参数来“建议”或“影响”这个决策，以匹配业务对响应速度和功耗的要求。

Q5：这些复杂的低功耗流程，对手机或物联网模组的实现有多大挑战？ A5：挑战是显著的。实现这些流程，要求终端的协议栈（特别是RRC和NAS层）必须完整地支持CP CIoT优化、EDT、RRC_INACTIVE状态管理、SDT等一系列Rel-15及之后引入的新特性。终端的软硬件设计都需要进行深度优化，以确保能够正确地进入和退出这些低功耗状态，并高效地处理相关的信令。因此，是否支持这些高级低功耗特性，也成为了衡量5G IoT模组先进性的一个重要标准。

关系图谱