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

深度解析 3GPP TS 28.552：5.1.1.14 & 5.1.1.15 Void & RRC Connection Establishment (接入之门：RRC连接建立测量)

本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中，关于“5.1.1.15 RRC connection establishment related measurements”的核心章节，旨在为读者提供一个关于5G网络“第一扇门”——RRC连接建立过程的性能测量全景解析。

引言：紧急救援无人机“信使-01”的生死时速

城市郊野公园，一场突发的山火正在蔓延。消防指挥中心急需一架无人机飞抵火场上空，实时回传火场态势、识别被困人员。紧急救援无人机“信使-01”临危受命，从待命状态被激活。它的首要任务，就是在最短的时间内，接入5G网络，建立起与指挥中心的生命通道。

“从开机到视频流回传，我们必须在5秒内完成！”指挥官下达了死命令。

在网络优化中心，老王和小林的表情也异常严肃。“小林，这次的任务，考验的是网络最基础、也最关键的能力——接入性。在所有花哨的业务开始之前，UE必须先敲开网络的第一扇大门。这扇门，就是RRC连接。”

老王将TS 28.552翻到了5.1.1.15节。“5.1.1.14节是Void（空），我们可以跳过。而5.1.1.15节，‘RRC connection establishment related measurements’，就是这扇大门的‘智能门禁系统’。它记录了每一次‘敲门’（尝试）、每一次‘成功开门’（成功）和每一次‘拒绝入内’（失败）的详细信息。对于‘信使-01’来说，能否快速、成功地建立RRC连接，是它完成任务的第一步，也是生死攸关的一步。”

“今天，我们就以‘信使-01’的这次紧急任务为线索，深入剖析RRC连接建立的三大核心测量项。我们将看到，网络是如何通过这些测量，来保障用户，特别是像紧急救援这样的关键任务，能够‘一敲即开’，顺利进入5G世界。”

1. 敲响网络之门：Attempted RRC connection establishments (5.1.1.15.1)

“信使-01”的电源被接通，它的通信模组立刻开始扫描周围的5G信号。锁定信号最强的运营商专网小区后，它在随机接入信道（RACH）上，发送了第一个上行信号——RRCSetupRequest消息。这声“你好，我想连接！”，就是敲响网络大门的第一声。

a) This measurement provides the number of RRC connection establishment attempts for each establishment cause.

b) CC.

c) Receipt of an RRCSetupRequest message by the gNB from the UE. Each RRCSetupRequest message received is added to the relevant per establishment cause measurement. … The possible establishmentCause are included in TS 38.331 (clause 6.2.2).

e) RRC.ConnEstabAtt.Cause where Cause identifies the establishment cause.

1.1 深度解析

RRC.ConnEstabAtt.Cause (RRC Connection Establishment Attempt) 是衡量网络“被敲门”频率的“门铃计数器”。

• 目标与触发 (a项 & c项): 统计gNB收到了多少次来自UE的RRCSetupRequest消息。这是所有RRC连接流程的起点，代表了总的接入尝试次数。

• 核心过滤维度——Cause (a项 & e项): 这个测量项最独特、最有价值的地方在于，它要求按照**establishmentCause (建立原因)** 进行细分。UE在敲门时，会告诉网络“我为什么而来”。根据TS 38.331的定义，这些原因主要包括：

  • emergency: 紧急呼叫。这是最高优先级的接入，如“信使-01”的紧急任务，或我们拨打110/120。
  • highPriorityAccess: 高优先级接入。如签约了特殊服务的VIP用户。
  • mt-Access: Mobile Terminating Access，移动终端接入。这是最常见的被动接入原因，即网络有下行数据要发给处于空闲态的UE（如收到微信消息），通过寻呼（Paging）将其唤醒后，UE发起的连接请求。
  • mo-Signalling: Mobile Originating Signalling，移动始发信令。UE有上行信令要发，如周期性位置更新。
  • mo-Data: Mobile Originating Data，移动始发数据。这也是最常见的主动接入原因，即用户主动打开App要上网。
  • mo-VoiceCall, mo-VideoCall: 5G语音或视频通话。

• 特殊情况 (c项): 规范还提到，对于AMF过载时收到的请求，可以不计入。这避免了因核心网问题导致的无线侧数据污染。

1.2 场景化举例：为“信使-01”开启绿色通道

当“信使-01”发送RRCSetupRequest消息时，其携带的establishmentCause就是emergency。 gNB收到后，其内部的RRC.ConnEstabAtt.Cause_Emergency这个子计数器立刻加1。

“小林，看到了吗？”老王指着实时数据，“这个子计数器的跳动，就是最高级别的告警信号。它告诉我们，有一个生命攸关的连接请求正在发生。我们的网络必须为它开启‘绿色通道’，无论如何都要优先保障它的接入。”

通过分析各个Cause的分布，网络运维人员可以清晰地洞察用户行为模型：

• 如果mo-Data占比最高，说明该区域以主动上网用户为主。
• 如果mt-Access占比很高，说明该区域用户行为偏被动，或寻呼策略可能过于频繁。
• emergency计数器的出现，则能触发特殊的保障流程和事后分析。

2. 大门顺利敞开：Successful RRC connection establishments (5.1.1.15.2)

gNB收到了“信使-01”的紧急请求，调度器立刻为其分配了最高优先级，并向其回复了RRCSetup消息，完成了资源配置。无人机收到后，正确应用了配置，并向gNB发送了最后一条确认消息——RRCSetupComplete。至此，RRC连接建立成功，大门已经为它敞开。

a) This measurement provides the number of successful RRC establishments for each establishment cause.

c) Receipt by the gNB of an RRCSetupComplete message following a RRC connection setup request. Each RRCSetupComplete message received is added to the relevant per establishment cause measurement.

e) RRC.ConnEstabSucc.Cause where Cause identifies the establishment cause.

2.1 深度解析

RRC.ConnEstabSucc.Cause (Success) 是衡量网络“开门成功率”的“分子”。

• 目标与触发 (a项 & c项): 统计gNB收到了多少次来自UE的RRCSetupComplete消息。这是RRC三步握手的最后一步，是连接成功的唯一标志。
• 过滤维度 (Cause): 与尝试计数一样，成功计数也必须按照establishmentCause进行细分。这使得我们可以计算出不同优先级、不同业务类型的接入成功率。

2.2 场景化举例：计算紧急业务接入成功率KPI

“信使-01”的RRCSetupComplete消息被gNB收到，RRC.ConnEstabSucc.Cause_Emergency子计数器加1。

“王哥，有了这两个数据，我们就可以计算RRC连接建立成功率 (RRC CSSR) 了！”小林抢先说道。 RRC CSSR (Emergency) = (RRC.ConnEstabSucc.Cause_Emergency / RRC.ConnEstabAtt.Cause_Emergency) * 100%

“没错！而且这是一个分业务的成功率，”老王补充道，“对于普通mo-Data业务，我们的KPI目标可能是99%。但对于emergency业务，KPI目标必须是100%！任何一次失败都意味着严重的事故。通过这个精细化的测量，我们可以严格地考核网络对关键业务的接入保障能力。”

3. 被拒之门外：Failed RRC connection establishments (5.1.1.15.3)

我们再设想一个失败的场景。在火场的另一侧，一架民用无人机也想飞近拍摄，它向同一个基站发起了RRCSetupRequest(cause=mo-Data)。但此时，由于网络为保障“信使-01”已经预留了大量资源，且存在其他高优先级业务，gNB的准入控制（Admission Control）算法判断，如果再接受这个新的连接请求，可能会影响到关键业务的QoS。于是，它向这架民用无人机发送了RRCReject消息。

a) This measurement provides the number of failed RRC establishments, this measurement is split into subcounters per failure cause.

c) On transmission of RRCReject message from the gNB to UE or the expected RRCSetupComplete message was not received by the gNB from UE after the RRCSetup message…

e) RRC.ConnEstabFailCause.NetworkReject RRC.ConnEstabFailCause.NoReply RRC.ConnEstabFailCause.Other

3.1 深度解析

RRC.ConnEstabFailCause (Failure) 是故障诊断的起点，它将失败的原因归结为三大类。

• NetworkReject (网络拒绝): gNB明确地向UE发送了RRCReject消息。这通常是由于网络侧的原因，如无线准入控制（资源不足、拥塞）、核心网拒绝等。这是一个“主动”的失败。

• NoReply (无响应): gNB向UE发送了RRCSetup消息后，启动了一个定时器，但在定时器超时前，没有收到UE的RRCSetupComplete消息。这通常是由于UE侧的原因，如UE突然掉电、UE移动出覆盖区，或者UE与gNB之间的下行链路质量极差导致RRCSetup消息丢失，或上行链路质量极差导致RRCSetupComplete消息丢失。这是一个“被动”的失败。

• Other (其他): 用于统计其他未明确分类的失败场景。

3.2 场景化举例：从失败原因看优化方向

民用无人机被拒的案例中，gNB的RRC.ConnEstabFailCause.NetworkReject计数器会加1。

在复盘火场保障时，小林发现普通数据业务的RRC CSSR有所下降。他调出失败原因分布：

• RRC.ConnEstabFailCause.NetworkReject: 占失败总数的80%
• RRC.ConnEstabFailCause.NoReply: 占失败总数的18%
• RRC.ConnEstabFailCause.Other: 占2%

“王哥，数据很清晰，”小林分析道，“绝大部分失败是网络主动拒绝的。这说明我们为了保障紧急业务，设置的准入控制策略过于严格，‘误伤’了部分普通用户。下一步优化，我们可以在保障紧急业务的前提下，适当放宽对普通用户的接入限制。”

老王点头：“分析正确。如果反过来，是NoReply占比很高，那优化方向就完全不同了，说明我们需要去排查小区的覆盖或干扰问题。”

4. 离开大门：Number of Idle-state RRC release messages (5.1.1.15.4)

当“信使-01”完成任务返航，或者一个普通用户刷完短视频后锁屏，它会从RRC Connected状态释放，回到RRC Idle（或Inactive）状态，让出宝贵的无线资源。

a) This measurement provides the number of idle-state RRC release messages (not including suspendConfig in RRCRelease) for RRC connections established within the existing NRCellCU.

c) On transmission of a “RRCRelease” message to UE not including suspendConfig.

e) RRC.RelWithoutSuspendConfig

• 深度解析: RRC.RelWithoutSuspendConfig 统计的是gNB发送的、用于将UE引导至RRC Idle状态的RRCRelease消息的数量。它特意排除了那些将UE引导至RRC Inactive状态的释放消息（带有suspendConfig）。这个指标反映了一个小区连接的“周转率”，即有多少连接是彻底释放、需要重新完整建立的。它与RRC.ConnEstabAtt一起，构成了评估小区信令负荷的完整视图。

结论：RRC连接测量——网络可达性的第一道生命线

“信使-01”的紧急任务，让我们深刻理解了RRC连接建立测量的核心价值。它不仅仅是统计成功与失败，更是一套精细化的诊断体系。

1. 按原因细分的尝试计数 (Att.Cause)：提供了用户行为和业务优先级的洞察，是差异化服务保障的起点。
2. 按原因细分的成功计数 (Succ.Cause)：使得计算分业务的接入成功率（CSSR）成为可能，是SLA考核的关键。
3. 按类型细分的失败计数 (Fail.Cause)：将失败原因清晰地划分为“网络侧”和“UE/空口侧”，为故障定位提供了最直接的线索。

这套测量体系，共同守护着5G网络的“第一扇门”。确保这扇门对需要的人（特别是紧急业务）永远敞开，同时又能智能地将非必要的请求拒之门外以保护系统稳定，这正是RRC连接建立测量的核心使命，也是保障网络可达性的第一道生命线。

---

FAQ 环节

Q1：RRC connection establishment（RRC连接建立）和UE-associated logical NG-connection establishment（UE相关的逻辑NG连接建立，5.1.1.16节）有什么区别？ A1：这是两个紧密相连但不同层面的过程。RRC connection establishment是UE和gNB之间的空口信令连接的建立，是纯粹的无线接入网（RAN）内部流程，对应我们说的“三步握手”。一旦RRC连接成功，UE就处于RRC Connected状态。而UE-associated logical NG-connection establishment是gNB和核心网AMF之间的信令连接的建立，对应的是NGAP协议中的INITIAL UE MESSAGE流程。通常，在RRC连接建立成功后，gNB会立刻发起这个流程，将UE的初始信息上报给AMF。前者是“UE-gNB”通路，后者是“gNB-AMF”通路。

Q2：如果一个区域RRC建立成功率很低，主要排查方向有哪些？ A2：首先要看RRC.ConnEstabFailCause的分布。

• 如果**NetworkReject** 占比高：说明是网络主动拒绝。需要检查：1）小区的无线准入控制参数是否过于严格？2）小区的PRB、CCE等资源是否利用率过高，导致拥塞？3）核心网AMF是否过载？
• 如果**NoReply** 占比高：说明是UE或空口问题。需要检查：1）小区是否存在弱覆盖或空口干扰，导致下行RRCSetup或上行RRCSetupComplete消息丢失？2）PRACH（物理随机接入信道）参数配置是否合理，是否存在严重的随机接入冲突？3）是否是特定终端类型的问题？

Q3：为什么Attempted RRC connection establishments要按establishmentCause细分，这对网络有什么好处？ A3：好处巨大，这是实现5G差异化服务和智能运维的基础。通过这个细分，网络可以：1）识别并优先保障高优先级业务，如emergency和highPriorityAccess，在资源紧张时优先为它们服务。2）分析用户行为，了解一个区域的用户主要是主动发起业务（mo-Data）还是被动接收（mt-Access），这对于寻呼策略、非激活定时器等参数的优化至关重要。3）实现更智能的准入控制，例如，在网络轻载时对所有Cause都接纳，在重载时优先拒绝低优先级的mo-Data请求，从而在保障关键业务的同时最大化系统容量。

Q4：一个RRC连接可以持续多久？什么情况下会被释放？ A4：RRC连接的持续时间由用户活动和网络配置共同决定。只要用户有持续的数据传输，RRC连接就会一直保持。当用户一段时间没有数据活动后，gNB会启动一个“RRC非活动定时器”（Inactivity Timer）。定时器超时后，gNB会发送RRCRelease消息，将UE释放到RRC Inactive或RRC Idle状态以节省资源。此外，切换、无线链路失败、核心网请求等也会导致RRC连接的释放。

**Q5：5.1.1.15.4节测量的RRCRelease (not including suspendConfig) 和将UE释放到Inactive状态有什么不同？** A5：RRCRelease消息本身可以有两种功能。如果消息中**不包含**suspendConfig（挂起配置）信息，那么UE收到后会进入**RRC Idle**状态，它在gNB侧的上下文会被完全删除，下次通信需要走完整的RRC连接建立流程。如果消息中**包含**suspendConfig，UE则会进入**RRC Inactive**状态，gNB会为其保留上下文，下次通信可以快速恢复连接。5.1.1.15.4`这个测量项专门统计前者，即“彻底释放”的次数，这对于评估需要完全重建的信令负荷有重要意义。