51学通信

深度解析 3GPP TS 38.410：5.19 Overload Control function (过载控制功能)

16分钟阅读

好的，我们继续跟随5G基站工程师小雷，深入探索NG接口的另一项关键稳健性功能。在上一篇中，我们学习了核心网侧AMF的“轮岗”与“急救”预案。现在，我们将视角切换到小雷的gNB自身，看看当gNB面对来自核心网的“信令洪流”时，它该如何自保并向上游发出“预警”。

深度解析 3GPP TS 38.410：5.19 Overload Control function (过载控制功能)

本文技术原理深度参考了3GPP TS 38.410 V18.2.0 (2024-06) Release 18规范中，关于“5.19 Overload Control function”的核心章节，并结合其在NGAP协议（TS 38.413）中的具体实现，为读者完整呈现5G网络中RAN到核心网的过载控制机制。

引言：基站的“自我保护”与“上游预警”

我们的主角，基站工程师小雷，正面临着一个严峻的考验。他所负责的gNB位于一个大型体育场馆附近，一场重要的足球赛即将开始。数万名观众涌入场馆，在同一时刻拿出手机，拍照、发朋友圈、刷短视频……海量的用户瞬间接入，导致gNB的CPU、内存等处理资源迅速飙升，濒临极限。

如果不加控制，这种由用户接入请求引发的“信令风暴”，很可能会压垮gNB的控制面，导致整个基站“死机”，所有用户的通信服务（包括已经建立连接的用户）都将中断。

小雷深知，一个设计精良的通信系统，必须具备在极端压力下的“自我保护”和“向上游反馈压力”的能力。第5.19节“过载控制功能”，正是3GPP为gNB设计的这样一套“智能熔断与预警系统”。它允许小雷的gNB在不堪重负时，能够智能地“拒载”部分新业务，并及时地通知上游的“指挥中心”（AMF），请求“减缓发包”，从而保证自身核心功能的稳定运行。

1. 过载的“警报”：gNB的过载控制机制

5.19 Overload Control function

The overload function provides means to enable AMF controls the load that the NG-RAN node(s) are generating.

深度解读：

这句话的表述非常精妙，值得仔细品味。它说“使能AMF控制gNB产生的负载”。这揭示了过载控制的一个核心哲学：gNB自身是过载的“感受者”和“报告者”，而AMF则是过载控制策略的最终“执行者”和“流量源头调节者”。

换句话说，gNB不能仅仅是简单粗暴地把用户请求丢掉，它必须通过NG接口，将自己的“痛苦指数”（过载程度）清晰地传达给AMF，由AMF来协同进行流量控制。这是一种闭环的、协同的过载保护机制。

在NGAP协议（TS 38.413）中，这个功能主要是通过OVERLOAD START和OVERLOAD STOP这两个关键信令流程来实现的。

2. “拉响警报”：OVERLOAD START 流程

场景设定： 体育场馆内，小雷的gNB检测到其控制面CPU占用率已超过90%的告警阈值。gNB的过载控制模块被激活。

第一步：自我诊断与“减负”策略制定

gNB首先需要“自我诊断”，确定是哪种类型的“信令洪流”导致了过载，并据此制定出不同的“减负”策略。NGAP协议定义了两种主要的过载行为（Overload Action）：

  1. REJECT_RRC_CR_SIGNALLING (拒绝RRC连接建立信令):

    • 诊断: 过载主要是由大量处于IDLE态的UE发起的**初始接入请求（RRC Setup Request）**造成的。这是最常见的过载场景，比如演唱会开场、新年钟声敲响的时刻。

    • 策略: gNB决定：“从现在开始，对于那些非紧急、非高优先级的新接入请求，我暂时不予理会，直接在空口拒绝，以节省处理资源。”

  2. PERMIT_EMERGENCY_SESSIONS_AND_MOBILE_TERMINATED_SERVICES_ONLY (仅允许紧急业务和被叫业务):

    • 诊断: 过载情况非常严重，不仅新用户接入处理不过来，甚至连为已连接用户建立新业务（如VoNR）的信令都快处理不过来了。

    • 策略: gNB决定采取更严厉的措施：“除了救命的紧急呼叫（如110/119）和别人打给我的电话（被叫），其他所有由用户主动发起的新业务请求，我一概拒绝。”

第二步：向上游AMF发出“过载预警”

在制定了本地的“减负”策略后，gNB必须立刻通过NG-C接口，向所有与它连接的AMF发送一个OVERLOAD START消息。

OVERLOAD START消息的内容：

NGAP PDU: Overload Start

  • Overload Response IE: (包含gNB制定的Overload Action)
  • Traffic Load Reduction Indication (可选): (一个百分比，如10%)
  • Overload Start NSSAI List (可选): (发生过载的切片列表)

  • Overload Response: 这是消息的核心。gNB会将它在第一步中决定的REJECT_RRC_CR_SIGNALLING或PERMIT_..._ONLY策略，明确告知AMF。

  • Traffic Load Reduction Indication: gNB可以给AMF一个更具体的“降压”建议，比如：“请将发往我这里的非紧急类下行信令（如下行NAS传输、PDU会话建立等）流量，减少10%。”

  • Overload Start NSSAI List: 如果过载只发生在某个特定的网络切片上（例如，体育馆为媒体直播专设的eMBB切片），gNB可以在这里指明，从而实现切片级的、精准的过载控制。

第三步：AMF的“流量管制”行动

核心网的AMF收到了来自小雷gNB的OVERLOAD START消息后，它会立即采取相应的“流量管制”措施，以减轻gNB的压力。

  • 如果gNB要求REJECT_RRC_CR_SIGNALLING:

    • AMF会启动一个定时器。在此期间，对于那些需要经过这个gNB的下行业务（如电话呼入），如果UE处于IDLE态，AMF会推迟发送Paging消息，或者减少寻呼的频次，从而减少由寻呼引发的UE接入，从源头上降低了gNB的负载。

  • 如果gNB要求PERMIT_..._ONLY:

    • AMF会采取更严格的措施。它会拒绝所有发往该gNB的、非紧急、非被叫的下行业务请求。

  • 如果gNB建议了“流量减少10%”:

    • AMF会根据这个百分比，通过内部的节流算法，相应地减少发往该gNB的下行信令数量。

通过gNB的“上报”和AMF的“管制”，形成了一个有效的闭环，共同抵御信令风暴的冲击。

3. “警报解除”：OVERLOAD STOP 流程

场景设定： 足球赛进入了平淡的中场休息时间，大部分观众停止了刷手机，网络负载开始下降。小雷的gNB检测到其CPU占用率已回落到50%的安全水平。

第一步：gNB发送“警报解除”通知

gNB会立即通过NG-C接口，向所有之前收到过OVERLOAD START的AMF，发送一个OVERLOAD STOP消息。

这个消息的含义非常简单：“我这里压力已经缓解，你们可以恢复正常的流量了。”

第二步：AMF恢复正常操作

AMF收到OVERLOAD STOP消息后，会立即停止所有之前启动的“流量管制”措施（如停止推迟寻呼、取消下行信令节流等），恢复与该gNB之间的正常信令交互。

至此，一次完整的过载控制事件处理完毕。小雷的gNB凭借这套“智能熔断与预警系统”，成功地扛住了一次业务高峰的冲击，保证了在极端压力下，依然为紧急业务和已连接用户提供了连续、稳定的服务。

总结：从“被动崩溃”到“主动防御”

通过对5.19节“过载控制功能”的深度剖析，我们看到了5G RAN在面对极端负载时的智能生存法则。它不再是传统网络中那个面对信令洪流只能“被动崩溃”的脆弱节点，而是一个具备主动防御能力的“弹性壁垒”。

  • 分级的过载策略: 提供了从“轻度限流”到“严格准入”的多种过载动作（Overload Action），使得gNB可以根据过载的严重程度，采取不同粒度的“减负”措施。

  • 精准的过载范围: 支持**基于切片（NSSAI）**的过载上报，实现了“哪里着火，灭哪里火”的精准控制，避免了因单个切片的过载而影响整个基站的服务。

  • 闭环的协同机制: 通过OVERLOAD START/STOP信令流程，在gNB（过载感知者）和AMF（流量源头）之间，建立了一个实时的、闭环的负反馈调节系统，从根本上提升了整个网络控制面的稳健性。

对于基站工程师小雷来说，过载控制功能就像是他手中的“泄压阀”。在业务洪峰来临之际，这个自动化的“泄压阀”能够保护他最宝贵的资产——gNB的稳定运行，确保在最繁忙的时刻，生命线业务（如紧急呼叫）的绝对畅通。这正是电信级网络“可靠性”的精髓所在。

FAQ

Q1：gNB发生过载时，对正在通话或上网的用户有影响吗？

A1：基本没有直接影响。过载控制主要针对的是新发起的信令流程，特别是IDLE态用户的初始接入和新业务的建立。对于那些已经处于CONNECTED状态、并且正在进行数据传输的用户，他们的用户面通道（NG-U）和已建立的控制面连接通常是受保护的。过载控制的核心目标，就是牺牲一部分“新生”业务，来保障“存量”业务的稳定，这是一种典型的“丢车保帅”策略。

Q2：gNB如何区分“高优先级”和“非高优先级”的接入请求？

A2：UE在发起RRC连接建立时，会在请求中包含一个建立原因（Establishment Cause）。这个原因有很多种，例如mo-Signalling（普通信令）、mo-Data（普通数据）、mps-PriorityAccess（多媒体优先服务）、emergency（紧急呼叫）等。当gNB处于REJECT_RRC_CR_SIGNALLING过载状态时，它会检查这个建立原因。对于“emergency”和“mps-PriorityAccess”等高优先级的原因，gNB会优先处理；而对于“mo-Data”等普通原因，则可能会暂时拒绝。

Q3：如果AMF自身发生过载，它会如何通知gNB？

A3：这是一个很好的问题，它对应了反方向的过载控制。是的，AMF也会发生过载。当AMF过载时，它会向所有连接的gNB发送一个AMF OVERLOAD START消息。这个消息中，AMF可以要求gNB：1. 拒绝所有发往该AMF的新UE（即gNB的NAS节点选择功能需要避开这个AMF）。2. 拒绝所有发往该AMF的、非紧急业务的NAS信令。这套机制与gNB的过载控制形成了互补，共同保障了整个NG-C接口的双向稳定。

Q4：Traffic Load Reduction Indication（流量减少指示）是一个强制指令吗？

A4：它是一个建议值。AMF会尽力去匹配gNB提出的这个减少百分比，但它不是一个硬性的、必须精确达到的指标。AMF会根据自己的流量调度算法，来 приблизить这个目标。这个百分比为AMF的流量节流策略，提供了一个非常有价值的量化参考。

Q5：过载控制是否会影响V2X业务？

A5：会，但会优先保障高优先级V2X业务。V2X业务同样需要通过RRC连接建立来发起Uu通信。当gNB过载时，如果V2X业务被映射为普通的接入等级，它也可能被拒绝。然而，对于与安全相关的V2X业务，可以通过配置更高的接入等级（例如，使用特定的接入类别AC，或者在未来通过特定的建立原因）来获得优先接入权，从而在gNB过载时，依然能够成功接入网络。这需要端到端的QoS配置和策略协同。

关系图谱