51学通信

深度解析 3GPP TS 23.273：5.14 & 5.15 事件报告允许区与低功耗高精度定位 (LPHAP)

24分钟阅读

深度解析 3GPP TS 23.273：5.14 & 5.15 事件报告允许区与低功耗高精度定位 (LPHAP)

本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“5.14 Event Report Allowed Area”和“5.15 Support of Low Power and High Accuracy Positioning”的核心章节，旨在为读者提供一个关于5G物联网时代下，定位服务如何实现低功耗与高精度双重优化的全景视图。

1. 序章：物联网时代的“续航焦虑”与“精度挑战”

欢迎来到万物互联的深水区。随着5G技术渗透到可穿戴设备、资产追踪、智慧农业等海量物联网（IoT）场景，两个看似矛盾的终极挑战浮出水面：极致的续航能力与可靠的高精度定位。一个需要设备尽可能“沉睡”，另一个则需要设备频繁“唤醒”并进行复杂计算。

为了化解这一矛盾，3GPP的工程师们在TS 23.273规范中精心设计了一系列“鱼与熊掌兼得”的机制。本篇文章将聚焦于其中两大关键特性：事件报告允许区（Event Report Allowed Area）和低功耗高精度定位（LPHAP）。

为了将这些抽象的技术具象化，我们请出今天的主角——“守护之星-W01”智能安全手表。这是一款专为独居老人设计的穿戴设备，它的核心使命是在保障老人安全（如走失预警、摔倒检测）的同时，实现长达数周的续航。老人的子女（扮演LCS客户端）需要通过手机App随时了解老人的安全状况。

“守护之星-W01”所面临的每一个挑战，都将引导我们深入理解5G定位服务是如何在功耗与精度之间取得精妙平衡的。

章节合并说明：根据解读规则，由于5.14章节内容相对简短，且其核心目标（节电）与5.15章节的LPHAP（低功耗高精度定位）主题高度契合，我们将这两章合并在一篇文章中进行深度解读，以便读者能系统性地理解5G为物联网定位场景所构建的完整节能策略。

2. 事件报告允许区 (Event Report Allowed Area)：智能的“报告过滤器”

在探讨复杂的LPHAP之前，我们先来解析一个非常实用且巧妙的节电工具——事件报告允许区。这个机制主要应用于我们之前介绍过的延迟定位请求（Deferred Location Request），特别是针对区域、周期和移动这三类事件。

During the deferred 5GC-MT-LR procedure, when the UE detects the triggered or periodic event happens, if it is inside the event report allowed area, the UE is allowed to generate and send the event report to network to reduce UE power consumption.

这段原文揭示了该功能的核心逻辑：它就像在UE和网络之间加装了一个智能的“报告过滤器”。只有当UE处于某个特定的“允许区域”内时，它才被允许上报那些被触发的事件。

2.1 核心机制：GMLC的决策与UE的执行

让我们通过“守护之星-W01”的场景来拆解这个机制。

老人的子女通过App为手表设置了一项“每日定时平安报备”功能，即手表每天上午10点上报一次位置，这是一个周期性事件。

  1. GMLC的“加工”：当GMLC收到这个周期性定位请求后，它不仅仅是简单地将任务转发下去。规范指出：

    The event report allowed area is a list of cell(s) or TA(s) determined by GMLC based on the event report expected area provided by UE which is a geographical area and is sent to the UE during the deferred 5GC-MT-LR procedure.

    这里出现了两个关键概念：

    • 事件报告期望区 (Event report expected area): 这通常由UE或其应用场景决定。在我们的例子中，可以理解为老人通常活动的区域，比如他所在的社区。这个信息可能会作为UE隐私配置的一部分存储在UDM中。
    • 事件报告允许区 (Event Report Allowed Area): 这是GMLC基于“期望区”和其他信息（如用户的签约家庭地址、常用基站等）计算出的一个更具体的网络区域，它由一个或多个小区ID列表或跟踪区ID列表组成。例如，GMLC可以精确地将老人家中的那个小区定义为“允许区”。

    GMLC在启动延迟定位流程时，会将这个计算好的“允许区”（小区列表）下发给“守护之星-W01”。

  2. UE的“过滤”：手表收到这个带有“允许区”的指令后，便启动了智能过滤模式。每天上午10点，周期性事件的闹钟准时响起，但手表并不会立即上报位置。它会先进行一次自我检查：

    • 检查当前位置：我（手表）现在在哪个小区？
    • 比对“允许区”列表：我当前所在的小区，是否在GMLC下发的“允许区”列表里？
    • 执行决策：
      • 如果在：比如老人此时正在家看报纸，手表发现自己就在“允许区”内，于是它正常生成并发送“平安报备”的位置报告。
      • 如果不在：比如老人此时正在公园散步，手表发现自己不在“允许区”内，它就会抑制这次上报行为，什么也不做。

2.2 节电效果：为何有效？

这个机制的节电效果立竿见影。对于“平安报备”这类非紧急、容忍度较高的报告，将其限制在特定区域（如家中），可以避免UE在外出时（通常信号条件更复杂，发射功率更高）进行不必要的网络通信。一次被抑制的事件报告，就意味着节省了一次RRC连接建立、NAS信令交互以及可能的定位测量所带来的全部功耗。日积月累，对手表的续航能力是巨大的提升。

2.3 机制的“反转”：区域使用指示 (Area Usage Indication)

规范还设计了一种更为灵活的模式，让“过滤器”的行为可以反转。

The event report allowed area can also be used differently if an area usage indication is provided together with the event report expected area by the UE. A reporting indication that is determined by GMLC based on the area usage indication means when the UE detects the triggered or periodic event happens, if it is outside the event report allowed area, the UE is allowed to generate and send the event report…

这意味着，通过设置一个**“区域使用指示”**，规则可以从“仅在区域内上报”反转为“仅在区域外上报”。

应用场景： 假设子女为“守护之星-W01”设置了一个“安全在家”的电子围栏，这个围栏就是老人的家，被定义为“事件报告允许区”。同时，他们设置了“区域使用指示”为“区域外报告”。

  • 老人在家时：手表处于“允许区”内，即使有周期性检查的触发，手表也不会上报任何信息，因为它不满足“区域外报告”的条件。这最大限度地保证了静默和省电。
  • 老人外出时：一旦老人走出家门，手表进入了“允许区”之外。此时，区域事件（离开区域）被触发，并且满足了“区域外报告”的条件。手表会立刻生成并上报一次位置报告，App会立即通知子女：“老人已出门”。

这种“反转”机制非常适合异常检测和边界穿越类应用，实现了从“常态化轮询”到“异常驱动”的转变，是更高级的节电策略。

3. 低功耗高精度定位 (LPHAP)：系统级的节能组合拳

如果说“事件报告允许区”是一个精巧的“战术级”节电工具，那么LPHAP (Low Power and High Accuracy Positioning) 则是一套“战略级”的解决方案。它不是一种新的定位技术，而是一个功能特性，一旦被激活，就会引导整个5G网络在执行定位任务时，优先采用一系列旨在降低UE功耗同时保证精度的策略和流程。

Service requirements for low power and high accuracy positioning (LPHAP) is defined in TS 22.261 and TS 22.104. Support of low power and high accuracy positioning is optional in this release of specification.

3.1 激活LPHAP：从源头开启节能模式

如何告诉网络，“守护之星-W01”需要LPHAP的特殊关照？规范提供了两种途径：

  1. 通过用户签约 (via subscription):

    Low power and high accuracy positioning is supported via subscription and in the LCS related subscriber data in the UDM, an LPHAP indication may be included.

    这是最主要的方式。运营商可以在“守护之星-W01”的SIM卡签约数据（存储在UDM中）里，永久性地打上一个LPHAP的“标签”。这意味着，只要是针对这款手表的定位请求，网络都会默认启用LPHAP优化。

  2. 通过定位请求 (during positioning procedure):

    During the positioning procedure, AMF provides the LPHAP indication to the LMF. The LPHAP indication is either obtained from the GMLC, or stored in the UE LCS context received during UE registration procedure.

    当LCS客户端（子女的App）在发起定位请求时，可以在请求中临时加入LPHAP指示。GMLC在收到后，会通过AMF将这个指示一路传递给最终执行定位的LMF。

3.2 LMF的智能决策：LPHAP如何改变定位行为

当LMF（定位管理功能）在其收到的定位请求中看到了LPHAP这个“圣旨”后，它的行为模式将发生显著变化。它会像一个精明的能源管家，开始在精度和功耗之间做精细的权衡。

If LMF receives from AMF of the LPHAP indication in the location request, LMF determines appropriate positioning method, e.g. network-based positioning method, or may determine to trigger the low power periodic and triggered 5GC-MT-LR procedures in clause 6.7 by taking into account the LPHAP indication.

这段原文揭示了LMF的两个主要优化方向：

3.2.1 优化方向一：优选“网络侧负荷”的定位方法

LMF会优先考虑那些能将计算和测量负荷从UE转移到网络侧的定位方法。

  • 例如：网络辅助定位 (Network-based positioning method) 最典型的就是我们上一章讲到的UL-TDOA（上行到达时间差）。在这种模式下，“守护之星-W01”只需要按照网络指令，发送一个简短的、功耗极低的上行探测信号（SRS）。而复杂的测量工作（由多个基站完成）和最终的位置解算（由LMF完成），全部在网络侧进行。手表本身几乎不消耗额外的计算资源。

    这与传统的UE辅助或UE自持的GNSS定位形成了鲜明对比。在后者中，UE需要持续接收卫星信号，并运行复杂的算法来计算位置，这是一个非常耗电的过程。LPHAP策略下，LMF会尽可能避免让UE去做这种“重活累活”。

3.2.2 优化方向二：触发更深度的低功耗流程

LMF会利用规范中定义的更高级、更省电的信令流程。

  • 例如：触发 Clause 6.7 中定义的流程 Clause 6.7 描述了UE在RRC_INACTIVE状态下如何进行事件报告。这是一种比CM_IDLE更“浅”的休眠状态，UE可以更快地被唤醒并发送少量数据，且之后能迅速返回休眠，整个过程信令开销和功耗都极低。它利用了CIoT 5GS Optimisation（蜂窝物联网5GS优化）中的技术，如早期数据传输（EDT）。

    当LPHAP被激活时，LMF在下发延迟定位任务时，就会在指令中“授权”UE可以使用这些更高级的低功耗上报流程。

3.2.3 优化方向三：协同RAN进行节能调度

In addition, LMF may also send LPHAP Assistance Information defined in TS 38.455 to RAN in the positioning procedure, as defined in clause 6.11.2.

LMF还可以向RAN（基站）发送LPHAP辅助信息。这可能包含一些特殊的调度建议，比如，告诉基站尽可能利用UE已有的上行传输机会来“搭便车”发送定位测量报告，而不是为其发起一次新的、独立的传输，从而减少无线状态转换带来的额外功耗。

4. 场景融合：LPHAP与允许区的协同守护

现在，让我们将两个特性融合到“守护之星-W01”的守护任务中，看它们如何协同工作。

  1. 基础设定：手表的UDM签约数据中已包含LPHAP标志。

  2. 日常守护：子女设置了一个覆盖老人整个小区的地理围栏（Area Event），并设置了“离开区域即上报”的规则。同时，网络根据老人的家庭住址，将他家所在的小区定义为“事件报告允许区”，并设置了“区域外报告”的指示，用于一个低优先级的“每日活动状态”检测。

  3. 协同工作流：

    • 老人在家时：手表处于“允许区”内。此时，即使“每日活动状态”的周期性事件被触发，手表也不会上报，因为它不满足“区域外报告”的条件。手表处于最低功耗的待机状态。
    • 老人出门散步（仍在小区内）：手表进入了“允许区”之外。此时，“每日活动状态”的触发条件满足了，手表会上报一次位置。由于LPHAP的激活，LMF会选择一种低功耗方式（如利用UL-TDOA）获取一个中等精度的位置，让子女知道老人出门了。
    • 老人走出小区：此时，高优先级的“地理围栏”事件被触发了！网络需要一个高精度的位置来确认老人的去向。LPHAP机制再次生效，LMF会立即启动高精度的UL-TDOA流程，在手表用户无感知的情况下，获取一个精确到米级的坐标，并立刻推送到子女的App上，同时可能触发告警。

在这个流程中，5.14的“允许区”机制负责过滤掉大量不必要的、低价值的报告，实现了宏观的功耗控制。而5.15的LPHAP机制则在每一次需要定位时，从方法选择到信令流程上都进行微观的功耗优化，确保在满足精度要求的前提下，UE的消耗最小。二者结合，构成了5G定位服务应对物联网时代挑战的坚实技术底座。

FAQ - 常见问题解答

Q1：“事件报告允许区”和我们通常说的“地理围栏”有什么区别？ A1：它们是两个不同层面、不同用途的概念。地理围栏是业务逻辑层的概念，由LCS客户端（应用）定义，用于触发业务事件（如“进入/离开”某个区域）。而事件报告允许区是网络优化层的概念，由网络侧（GMLC）定义，其唯一目的是为了节省UE功耗，通过过滤掉在某些区域内不必要的事件报告来实现。一个地理围栏可以很大，而一个允许区可能只是一个或几个小区。

Q2：LPHAP（低功耗高精度定位）听起来有些矛盾，高精度通常不都意味着高功耗吗？它是如何解决这个矛盾的？ A2：LPHAP解决这个矛盾的核心思想是**“负荷转移”。传统上，UE端的高精度定位（如GNSS）确实非常耗电，因为它需要自己完成信号接收、测量和复杂计算。LPHAP策略下，LMF会倾向于选择网络侧定位方法**（如UL-TDOA）。在这种模式下，UE只负责发送一个简单的上行信号，几乎不消耗计算资源，而将耗电的、复杂的测量和计算任务转移给了拥有稳定供电的多个基站和核心网LMF。这样，对于UE来说，就实现了“低功耗”获取“高精度”位置的神奇效果。

Q3：谁来决定和定义“事件报告允许区”？应用开发者可以控制吗？ A3：最终定义“事件报告允许区”（即具体的小区/TA列表）的是网络侧的GMLC。但是，GMLC的决策依据之一是“事件报告期望区”，这个信息可以由UE侧提供。因此，应用开发者可以通过UE向网络传递期望的报告行为区域，间接影响GMLC的决策，但最终的解释权和执行权在网络侧。

Q4：如果我的设备不支持LPHAP特性，它还能在5G网络里定位吗？ A4：当然可以。LPHAP是规范定义的一个**可选（Optional）**特性。如果设备或网络不支持LPHAP，定位请求会回退到标准的定位流程。这意味着网络依然可以为设备提供定位服务，只是无法享受到LPHAP带来的一系列针对性的低功耗优化。对于那些对续航要求极高的物联网设备来说，是否支持LPHAP就成了一个重要的差异化特性。

Q5：“事件报告允许区”的“区域外报告”模式，除了老人走失预警，还有什么典型的商业应用场景？ A5：这是一个非常有用的特性，尤其适合“异常管理”类应用。一个典型的商业场景是贵重资产/货物追踪。比如，一家公司将一批贵重货物存放在一个有严密安保的仓库里。他们可以将这个仓库定义为“事件报告允许区”，并设置“区域外报告”。这样，只要货物在仓库里，追踪器就保持静默，不产生任何通信费用和功耗。一旦货物未经授权被移出仓库，追踪器会立刻触发定位并上报告警，实现了高效、低成本的安全监控。

关系图谱