深度解析 3GPP TS 28.552：5.1.1.16 & 5.1.1.17 UE Associated Logical NG Connection & RRC Connection Re-esta...

好的，我们继续进行系列的下一篇深度解读。

深度解析 3GPP TS 28.552：5.1.1.16 & 5.1.1.17 UE Associated Logical NG Connection & RRC Connection Re-establishment

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.16 UE-associated logical NG-connection related measurements”和“5.1.1.17 RRC Connection Re-establishment”的核心章节，旨在为读者提供一个关于5G网络连接“鲁棒性”与“恢复力”的性能测量全景解析。

引言：隧道“惊魂一刻”，视频会议的自愈之路

商务精英李杰正驾车穿过一条长长的跨江隧道。他车内的5G CPE设备，正稳定地支撑着一场他与董事会的重要视频会议。突然，前方一辆大货车挡住了他的车道，也短暂地屏蔽了5G信号。李杰的屏幕上，视频画面卡住了一瞬。

“糟了！”李杰心中一紧。然而，仅仅一秒钟后，在他绕过货车的瞬间，画面奇迹般地恢复了流畅，会议无缝地继续了下去。他甚至没有听到“您已掉线”的提示音。

“王哥，刚才李杰的CPE上报了一次RLF（无线链路失败）！但我没收到掉线告警，业务恢复得非常快！”在网络优化中心，小林紧盯着信令追踪，既紧张又兴奋。

老王指着屏幕上跳动的几个不常见的计数器， calmly说道：“小林，这就是5G网络的‘恢复力’，或者叫‘鲁棒性’。在移动通信的世界里，短暂的信号中断在所难免，就像人偶尔会摔一跤。关键不在于会不会摔倒，而在于摔倒后能不能立刻爬起来。我们今天要学习的，就是衡量网络‘快速自愈’能力的两大‘急救包’——RRC连接重建 (RRC Connection Re-establishment) 和UE相关的NG连接 (UE-associated logical NG-connection)。”

他将TS 28.552切换到5.1.1.16和5.1.1.17节。“5.1.1.15节讲的是‘从零开始’建立连接。而5.1.1.17节的RRC重建，则是‘摔倒后原地复活’的机制，它试图在不麻烦核心网的情况下，快速恢复空口连接。5.1.1.16节的NG连接，则是RAN和核心网之间的‘生命热线’，它的建立成功与否，决定了UE是否能真正被5G核心网所接纳和管理。”

“李杰的这次‘惊魂一刻’，正是这两个机制完美配合的结果。今天，我们就来解剖这个‘自愈’过程，看看规范是如何量化网络的坚韧与智慧的。”

1. RAN与核心网的“握手”：UE-associated logical NG-connection (5.1.1.16)

当UE（如李杰的CPE）成功建立RRC连接后，它还只是gNB的“临时访客”。gNB必须立刻将这位访客的信息“通报”给核心网的“户籍管理员”——AMF。这条gNB与AMF之间、为特定UE建立的信令通道，就叫做“UE相关的逻辑NG连接”。这个过程的成功，标志着UE被正式纳入了5G核心网的管理体系。

1.1 “通报”的尝试与成功：Attempted/Successful ... NG-connection establishment (5.1.1.16.1 & 5.1.1.16.2)

5.1.1.16.1 Attempted UE-associated logical NG-connection establishment from gNB to AMF a) This measurement provides the number of attempted UE-associated logical NG-connection establishments from gNB to AMF, for each RRCSetupRequest establishment cause. c) On transmission of an INITIAL UE MESSAGE by the gNodeB to the AMF (See 38.413), the relevant per RRCSetupRequest establishment cause measurement is incremented by 1. e) UECNTX.ConnEstabAtt.Cause where Cause identifies the establishment cause.

5.1.1.16.2 Successful UE-associated logical NG-connection establishment from gNB to AMF c) On receipt by the gNB of first message from AMF which succeeds INITIAL UE MESSAGE message… the relevant per RRCSetupRequest establishment cause measurement is incremented by 1. e) UECNTX.ConnEstabSucc.Cause where Cause identifies the establishment cause.

1.1.1 深度解析

• 测量对象: 测量族UECNTX (UE Context) 表明，这组测量关注的是UE上下文在gNB和AMF之间的交互。ConnEstabAtt (Connection Establishment Attempt) 和 ConnEstabSucc (Success) 分别统计NG连接的尝试与成功。
• 触发条件:
  • 尝试 (Att): 当gNB向AMF发送INITIAL UE MESSAGE时，UECNTX.ConnEstabAtt计数器加1。这是gNB为新接入的RRC用户向核心网发出的第一声“报到”。
  • 成功 (Succ): 当gNB收到AMF针对INITIAL UE MESSAGE的第一条成功响应消息（如INITIAL CONTEXT SETUP REQUEST或DOWNLINK NAS TRANSPORT）时，UECNTX.ConnEstabSucc计数器加1。这表示AMF已经“认识”了这个UE，并开始对其进行管理。
• 关联Cause: 这组测量与RRC连接建立一样，也按establishmentCause进行细分。这使得我们可以计算出，例如emergency业务的NG连接建立成功率，从而评估网络对高优先级业务的端到端（RAN+CN）接入保障能力。

1.1.2 场景化举例：NG连接建立成功率 KPI

小林查看隧道入口基站的数据，他可以看到： NG连接建立成功率 = (UECNTX.ConnEstabSucc / UECNTX.ConnEstabAtt) * 100%

“王哥，这个KPI和RRC连接成功率有什么区别？看起来流程上是紧挨着的。”

“区别很大，”老王解释道，“RRC连接成功率衡量的是空口的稳定性和RAN的接入能力。而NG连接建立成功率，衡量的是RAN与核心网之间接口（NG-C接口）的连通性以及AMF的处理能力。如果RRC成功率很高，但NG连接成功率很低，那问题几乎可以肯定出在承载网或者AMF上，我们无线侧就可以‘甩锅’了。”

2. “摔倒后原地复活”：RRC Connection Re-establishment (5.1.1.17)

当李杰的车被大货车遮挡时，CPE与基站的无线链路中断，触发了RLF（无线链路失败）。此时，CPE不会立即放弃，而是会启动一个短暂的定时器，并尝试在同一个或邻近的小区，发起一个特殊的流程——RRC连接重建。

这个流程的优点是：快，且对核心网透明。UE和gNB会利用之前保存的上下文信息（如安全密钥），跳过复杂的认证和能力协商，直接恢复RRC连接。只要成功，核心网甚至不知道UE“摔了一跤”。

2.1 重建的尝试与结果：attempts, successful, failed

2.1.1 尝试次数：Number of RRC connection re-establishment attempts (5.1.1.17.1)

c) On Receipt of RRCReestablishmentRequest message from UE (see TS 38.331). e) The measurement name has the form RRC.ReEstabAtt.

深度解析： 这是RRC重建流程的起点。当gNB收到UE发来的RRCReestablishmentRequest消息时，RRC.ReEstabAtt计数器加1。这个指标衡量了网络中发生了多少次“尝试自愈”的事件。

2.1.2 两种成功模式：successful ... with/without UE context (5.1.1.17.2 & 5.1.1.17.3)

重建的成功分为两种情况：

5.1.1.17.2 Successful RRC connection re-establishment with UE context c) On Receipt of a RRCReestablishmentComplete message… e) RRC.ReEstabSuccWithUeContext.

深度解析： 这是最理想的成功。UE在原小区或已准备好的邻小区发起重建，gNB成功找到了该UE之前保存的上下文，快速恢复了连接。触发点是gNB收到了UE的RRCReestablishmentComplete消息。RRC.ReEstabSuccWithUeContext的计数值，代表了5G网络真正的快速自愈能力。

5.1.1.17.3 Successful RRC connection re-establishment without UE context c) On Receipt of a RRCSetupComplete message from UE for RRC connection re-establishment… e) RRC.ReEstabSuccWithoutUeContext.

深度解析： 这是次优的成功。UE可能跑到了一个gNB完全“不认识”它的小区（例如，切换准备失败，但UE自己跑过去了）。目标小区收到了重建请求，但找不到UE的上下文。此时，它无法“原地复活”，只能将这个重建请求降级为一个全新的RRC连接建立流程，并最终收到RRCSetupComplete消息。虽然连接也恢复了，但速度更慢，且对核心网来说相当于一次新的接入。RRC.ReEstabSuccWithoutUeContext的计数，反映了那些“自愈失败，但抢救成功”的案例。

2.1.3 场景化举例：李杰的“无感”恢复

在隧道中，李杰的CPE在信号恢复的瞬间，向新的小区发送了RRCReestablishmentRequest。幸运的是，这个小区正是gNB已经为其准备好的切换目标小区。

1. 新小区gNB收到请求，RRC.ReEstabAtt加1。
2. gNB成功找到了为它准备的上下文，立刻恢复了连接。
3. UE回复RRCReestablishmentComplete。
4. 新小区gNB的RRC.ReEstabSuccWithUeContext加1。

整个过程在几百毫秒内完成，对上层业务的影响被降到了最低。这就是李杰几乎“无感”的原因。

2.2 走向失败的岔路：attempts followed by RRC Setup (5.1.1.17.4)

a) This measurement provides the number of RRC connection re-establishment attempts where no UE context could be retrieved and therefore fallback to RRC Setup procedure was attempted. c) On transmission of RRCSetup message to UE, after first having received RRCReestablishmentRequest message from that UE… e) RRC.ReEstabFallbackToSetupAtt.

• 深度解析： RRC.ReEstabFallbackToSetupAtt这个计数器，精确地捕捉了从“重建”降级到“新建”的那个转折点。它的触发条件是：gNB先收到了RRCReestablishmentRequest，但因为找不到上下文，然后向UE发送了RRCSetup消息。这个指标与RRC.ReEstabSuccWithoutUeContext（最终成功）结合，可以分析出降级流程本身的成功率。

3. “原地复活”后的状态同步：RRC Connection Resuming (5.1.1.18)

（由于5.1.1.18 RRC Connection Resuming的内容与5.1.1.17在逻辑上紧密关联，且通常与Inactive状态的恢复相关，这里将其作为RRC连接恢复能力的延伸进行简述，以保持文章的逻辑连贯性。）

RRC连接恢复 (Resuming) 是UE从RRC Inactive状态回到RRC Connected状态的过程。它比重建更轻量，因为UE和gNB双方都明确地保存了上下文。

5.1.1.18.1 Number of RRC connection resuming attempts (RRC.ResumeAtt.cause) 5.1.1.18.2 Successful RRC connection resuming (RRC.ResumeSucc.cause) 5.1.1.18.3 Successful RRC connection resuming with fallback (RRC.ResumeSuccByFallback.cause)

• 深度解析: 这组测量与RRC重建的测量逻辑高度相似：
  • ResumeAtt: UE发送RRCResumeRequest时计数。
  • ResumeSucc: gNB收到RRCResumeComplete时计数。
  • ResumeSuccByFallback: 恢复失败，降级为RRC连接建立（收到RRCSetupComplete）后成功。 它们共同衡量了5G Inactive模式的“快速唤醒”能力，这对于需要频繁、快速收发小包数据的物联网业务至关重要。

结论：坚不可摧的连接——鲁棒性的量化

李杰的隧道惊魂一刻，最终成为了5G网络强大鲁棒性的最佳证明。通过对5.1.1.16和5.1.1.17节的学习，我们掌握了衡量网络“恢复力”的关键指标。

1. UE-CN连接 (UECNTX测量): 它衡量了**RAN与核心网之间的“握手”**是否顺畅，是评估端到端接入性能、进行RAN与核心网问题定界的关键。
2. RRC连接重建 (ReEstab测量): 它量化了网络在遭遇无线链路失败后的**“自愈”能力**。with UE context的成功率是衡量快速恢复能力的核心，而without UE context和Fallback的计数则揭示了移动性管理中可能存在的配置问题。
3. RRC连接恢复 (Resume测量): 它评估了Inactive模式的效率，是保障海量物联网设备低功耗、快响应的关键。

这些测量项共同构成了一道坚实的防线，它们所衡量的，不再是网络“有多快”，而是网络“有多稳”。在一个永远充满不确定性的移动世界里，正是这种快速发现问题、快速从中恢复的强大鲁棒性，才构成了5G网络真正值得信赖的基石。

---

FAQ 环节

Q1：RRC连接重建（Re-establishment）和RRC连接恢复（Resuming）有什么根本区别？ A1：根本区别在于触发场景和预期状态。RRC重建的触发场景是非预期的无线链路失败（RLF），它是一个“事后补救”的异常流程。而RRC恢复的触发场景是UE主动或被动地需要从RRC Inactive这个正常状态回到Connected状态，这是一个“按计划唤醒”的正常流程。简单来说，重建是“急救”，恢复是“叫醒”。

Q2：RRC.ReEstabSuccWithUeContext（带上下文的重建成功）比率低，通常意味着什么？ A2：这个比率低，意味着UE发生RLF后，网络无法快速地在本地恢复其连接，这通常指向移动性管理配置的问题。可能的原因包括：1）UE移动速度过快，发生RLF时已经远离了原小区和任何已准备好的邻区，导致上下文找不到。2）邻区关系配置缺失或错误，UE掉到了一个“未知”的小区。3）切换参数不合理，例如切换门限设置过低导致“掉话（切换太晚）”，UE在发起切换流程前就已经失联。这个指标是衡量切换参数健壮性的重要参考。

Q3：UECNTX.ConnEstabAtt这个测量项，为什么它的测量族是UECNTX而不是RRC？ A3：这是一个很好的关于规范逻辑的问题。虽然NG连接建立紧跟在RRC连接建立之后，但它的核心交互内容是**UE的上下文（Context）**在gNB和AMF之间的同步。INITIAL UE MESSAGE中携带了UE的安全能力、GUTI等核心身份信息。AMF的响应消息INITIAL CONTEXT SETUP REQUEST则会把UE的签约数据、安全上下文、PDU会话列表等下发给gNB。整个过程的核心是“上下文”，而非“无线资源控制”（RRC）。因此，将其归入UECNTX测量族，更能准确地反映其功能本质。

Q4：如果一次RRC重建失败，最终降级为RRC新建并成功了，用户会有什么感受？ A4：用户会感受到一次明显的业务中断。一次成功的“带上下文重建”可能只需要几十到几百毫秒，上层业务（如VoNR）或许能通过自身的抖动缓冲机制扛过去，用户感知不强。但如果降级为RRC新建，整个流程就需要重新进行鉴权、安全激活、能力协商等，耗时可能达到1-2秒甚至更长。对于视频会议、语音通话等实时业务来说，这通常意味着一次不可恢复的掉线。

Q5：监控这些“恢复力”指标，对于网络自动化运维（SON/OAM）有什么意义？ A5：意义巨大。这些指标是实现网络“自愈”和“自优化”的基础数据输入。例如：

• 一个自动化平台可以持续监控小区的RRC重建成功率。如果发现某个小区的重建成功率持续偏低，且失败原因主要是UE跑到了未配置的邻区，SON功能就可以自动触发ANR（自动邻区关系）流程，为该小区添加新的邻区。
• 如果平台发现某个区域的RRC重建尝试次数(RRC.ReEstabAtt)在特定时间（如上下班高峰）异常增多，就可以判断该区域存在覆盖空洞或严重的切换问题，并自动生成优化工单，或调整切换参数尝试优化。
• 监控NG连接成功率，可以帮助自动化系统快速判断故障域，当成功率下降时，自动触发对承载网或AMF的诊断流程。