5G接入控制：UAC统一拦门的底层逻辑

从一个春节红包说起

想象一下除夕夜零点，你和小伙伴们同时打开手机抢红包——数百万人在同一秒向基站发起连接请求。如果没有"门卫"，基站会在瞬间被请求洪流淹没，结果谁都连不上。这个"门卫"就是接入控制（Access Control）。

在4G时代，这个门卫体系是一堆零散的"临时工"——ACB管数据、SSAC管语音、EAB管物联网、ACDC管应用，各管各的，协调困难。5G来了之后，3GPP做了一个重要决策：把所有门卫整合成一个"大总管"，统一接入控制（UAC，Unified Access Control）应运而生。

为什么非得统一？因为5G要同时服务手机、车联网、工业机器人、智能水表——它们对"能不能进"的判断标准完全不同。一套统一的框架，才能做到精细化管理。

一、接入控制的本质：一场概率游戏

接入控制的核心思想极其朴素：当网络负载过高时，用概率方法随机拒绝一部分接入请求，保留资源给高优先级业务。

它不是"一刀切"地关大门，而是像地铁限流——不是不让进，而是让你等一等、分批进。关键参数只有两个：

判断逻辑用一行伪代码就能说清：

rand = random(0, 1)  // 生成0~1之间的随机数
if rand < barringFactor:
    允许接入  // 发起RRC连接
else:
    禁止接入  // 等待barringTime后重试

这就是UAC最底层的判断逻辑。但问题来了：谁该被拦？谁该被放？ 这就需要两套标签系统——接入标识和接入类别。

二、两套标签：接入标识与接入类别

2.1 接入标识（Access Identity, AI）——"你是谁"

接入标识描述的是用户的身份属性，写入USIM卡中。它回答的是"你是谁"的问题：

关键设计理念：AI越高，越不容易被拦。 紧急呼叫（AI层次中的特殊处理）和任务关键用户几乎不会被禁止。这就像医院的绿色通道——危重病人优先就诊。

2.2 接入类别（Access Category, AC）——"你要干什么"

接入类别描述的是业务类型，由UE根据NAS请求类型自动映射。它回答的是"你要干什么"的问题：

最关键的设计：AC将"业务类型"从"用户身份"中解耦出来了。 在4G中，ACB的Access Class把身份和业务混在一起（0-9是普通用户随机分配，10是运营商员工，11-15是特殊服务），不够灵活。5G把它们拆成两个维度，排列组合后就能做到极细粒度的控制。

2.3 映射逻辑：NAS请求如何变成AC

当手机的NAS层产生一个请求时，UE需要自动决定对应的AC。映射规则如下：

flowchart TD
    A[NAS请求产生] --> B{请求类型判断}
    B -->|被叫/寻呼响应| C[AC = 0<br/>MO/MT access]
    B -->|注册/去注册| D[AC = 1<br/>MO Signaling]
    B -->|MO数据/PDU会话| E[AC = 2<br/>MO Data]
    B -->|SMS相关| F[AC = 4<br/>MO SMS]
    B -->|IMS语音呼叫| G[AC = 5<br/>MO IMS Voice]
    B -->|IMS视频呼叫| H[AC = 6<br/>MO IMS Video]
    B -->|紧急呼叫| I[AC = 8<br/>Emergency]
    B -->|运营商自定义| J[AC = 32~63<br/>Operator-specific]

    C & D & E & F & G & H & I & J --> K[结合USIM中的AI<br/>生成 AI+AC 组合]
    K --> L[进入UAC禁止检查]

    style I fill:#ff6b6b,color:#fff
    style L fill:#4ecdc4,color:#fff

为什么紧急呼叫特殊？ AC=8（紧急呼叫）在UAC中享有最高豁免权。即使基站在做接入禁止，紧急呼叫也必须放行——这是生命安全的基本保障，也是各国电信法规的强制要求。

三、UAC禁止检查的完整流程

理解了AI和AC，我们来看UAC的完整判断流程。这个过程完全在UE侧执行，不需要向网络发送任何信令——这是5G的一大优化，减少了不必要的空口开销。

flowchart TD
    Start([UE发起接入请求]) --> Map[1. NAS层映射<br/>确定 Access Category]
    Map --> ReadSIM[2. 读取USIM<br/>确定 Access Identity]
    ReadSIM --> ReadSIB[3. 读取SIB1中的<br/>uac-BarringInfo]
    ReadSIB --> Check1{4. 检查AI是否<br/>在豁免列表中?}

    Check1 -->|是: AI豁免| Pass1[✅ 允许接入<br/>直接发起RRC]
    Check1 -->|否: AI未豁免| Check2{5. 该AC是否<br/>被配置禁止?}

    Check2 -->|未配置禁止| Pass2[✅ 允许接入<br/>直接发起RRC]
    Check2 -->|已配置禁止| Factor{6. 概率检查<br/>rand < barringFactor?}

    Factor -->|是| Pass3[✅ 允许接入<br/>发起RRC]
    Factor -->|否| Barred[❌ 禁止接入<br/>启动定时器T309]

    Barred --> Wait[等待barringTime<br/>+ 随机抖动]
    Wait --> Retry[重新执行<br/>禁止检查]

    style Pass1 fill:#2ecc71,color:#fff
    style Pass2 fill:#2ecc71,color:#fff
    style Pass3 fill:#2ecc71,color:#fff
    style Barred fill:#e74c3c,color:#fff
    style Factor fill:#f39c12,color:#fff

关键步骤解读

步骤4——AI豁免检查： SIB1中的 uac-BarringForAccessIdentity 是一个位图（bitmap），每一位对应一个AI值。如果某位设为"1"，表示该AI被禁止；如果是"0"，表示该AI被豁免。

例如，如果位图是 111111111101，只有AI=2（MCS用户）对应的位为0，意味着只有任务关键用户（消防、警察）被豁免，其他所有用户都可能被禁止。

步骤6——概率判定： 这是最精妙的设计。barringFactor 不是简单的开关，而是一个概率阈值。当它被设为0.3时，意味着只有30%的请求能通过——但这30%是随机的，每个UE独立判定，自然实现了负载的均匀分散。

等待时间的随机化： 被禁止的UE不是同时重试。实际的等待时间为：

$$T = \text{barringTime} \times (0.7 + 0.6 \times \text{rand})$$

其中rand是0~1的随机数。这个公式确保被拒绝的UE不会在同一时刻集体重试，避免了"惊群效应"。

四、SIB1中的UAC参数结构

gNB通过SIB1广播UAC配置，这是整个系统的"控制面板"。参数结构如下：

graph LR
    SIB1["SIB1<br/>uac-BarringInfo"] --> A["uac-BarringForAccessIdentity<br/>位图: 哪些AI被禁止"]
    SIB1 --> B["uac-BarringForCommon<br/>公共禁止参数"]

    B --> B1["每个AC的禁止参数:<br/>• barringFactor<br/>• barringTime"]

    SIB1 --> C["uac-BarringInfoPerPLMN<br/>按PLMN区分<br/>（漫游场景）"]

    B1 --> D["barringFactor<br/>取值: 0.05~0.95<br/>步进0.05"]
    B1 --> E["barringTime<br/>取值: 4s~512s<br/>指数增长"]

    style SIB1 fill:#3498db,color:#fff
    style B fill:#e67e22,color:#fff

一个实际的SIB1配置示例

假设某大型赛事场馆的基站配置如下：

uac-BarringInfo:
  uac-BarringForAccessIdentity: '111011111111'
  //                    AI: 0 1 2 3 4 5 6 7 8 9 10 11
  // AI=2(MCS)被豁免（位=0），其余被禁止

  uac-BarringForCommon:
    AC=1 (MO Signaling):
      barringFactor = 0.5   // 50%放行
      barringTime = 16s     // 被拦后等16秒

    AC=2 (MO Data):
      barringFactor = 0.3   // 30%放行
      barringTime = 32s     // 被拦后等32秒

    AC=5 (IMS Voice):
      barringFactor = 0.7   // 70%放行（语音优先）
      barringTime = 8s

    AC=8 (Emergency):
      未配置 → 永远放行

从这个配置可以看出运营策略：语音通话优先于数据业务，信令优先于数据，紧急呼叫无条件放行，任务关键用户全权豁免。 UAC的参数配置本质上就是运营商的业务优先级策略。

五、4G vs 5G：接入控制的代际演进

为什么4G的方案不行了？ 4G的ACB机制最大的问题是"身份和业务不分"。Access Class 0-9是随机分配给普通用户的，10-15是特殊身份。但当你拨打110时，你的Access Class还是那个随机数——系统无法区分你是在看抖音还是在报火警。5G把身份和业务拆开，才真正实现了"因事制宜"的精细控制。

六、核心网侧的补充：AMF过载控制

UAC是无线侧的第一道防线，但核心网也有自己的过载保护机制——N2接口的OVERLOAD信令。当AMF检测到信令负荷过高时，会向gNB发送OVERLOAD START消息：

sequenceDiagram
    participant UE as UE (手机)
    participant gNB as gNB (基站)
    participant AMF as AMF (核心网)

    Note over gNB,AMF: 正常运行阶段
    AMF->>gNB: OVERLOAD START<br/>(告警+限制策略)
    Note right of AMF: AMF检测到<br/>信令负荷>阈值

    Note over gNB: gNB调整UAC参数:<br/>降低barringFactor<br/>增加barringTime

    UE->>gNB: RRC Setup Request
    gNB->>UE: RRC Reject (部分被拒)
    Note left of UE: UE侧UAC检查<br/>概率性拒绝

    Note over gNB,AMF: 负荷恢复正常
    AMF->>gNB: OVERLOAD STOP
    Note over gNB: gNB恢复UAC参数<br/>正常放行

这是一个负反馈闭环： 1. AMF检测过载 → 发OVERLOAD START 2. gNB收紧UAC参数 → 减少接入请求量 3. AMF负荷下降 → 发OVERLOAD STOP 4. gNB放宽UAC参数 → 恢复正常接入

这个闭环非常高效，从检测到生效只需毫秒级——因为gNB只需要修改SIB1中的barringFactor，UE在下一个SIB1读取周期（默认160ms）就能感知到变化。

七、实战场景与调优指南

场景1：大型赛事/演唱会

问题： 5万人同时涌入体育场，PRACH preamble冲突率飙升，RRC建立成功率暴跌。

调优策略： - AC=2（数据业务）barringFactor降到0.1~0.2，只放行10-20% - AC=5（语音）barringFactor保持0.7以上，保障通话 - AC=0（被叫）保持高barringFactor，保障下行可达性 - barringTime设为16-32秒，拉长重试间隔 - AI=2（MCS用户）设为豁免，保障安保通信

场景2：物联网海量接入

问题： 智能水表/电表集中在凌晨2点上报数据，数万终端同时发起连接。

调优策略： - 为IoT终端配置专用的AC（32-63运营商自定义） - 该AC的barringFactor设为0.05（5%放行率） - barringTime设为64-128秒 - 普通手机用户不受影响（不同AC独立控制）

场景3：紧急事件（地震/火灾）

问题： 突发事件导致大量用户同时拨打电话，网络面临过载。

调优策略： - AC=1（信令）barringFactor降到0.3 - AC=2（数据）barringFactor降到0.05 - AC=5（语音）barringFactor保持0.5 - AC=8（紧急呼叫）不配置禁止，永远放行 - AI=2（MCS用户）豁免，保障救援通信

常见调试陷阱

最重要的区分： cellBarred（MIB中）和UAC（SIB1中）是两个完全不同层面的控制。cellBarred=true表示整个小区禁止接入，所有用户都无法驻留；UAC是概率性的，可以做到"部分放行"。很多新手把两者混淆，导致排障方向错误。

八、为什么5G要如此设计？——设计哲学的三个洞察

洞察一：分布式决策优于集中式。 4G的ACB部分判定也在UE侧，但5G把所有判定逻辑都放在UE侧。好处是：UE被拒绝后根本不发送RRC请求，省下了宝贵的空口资源和基站的CPU处理能力。这是一种"把计算推向边缘"的设计思想——在移动通信领域早有体现。

洞察二：二维标签优于单维分类。 身份和业务分离后，运营商可以用一个N×M的矩阵来定义策略，而不是4G中的一维线性表。32个运营商自定义AC，意味着运营商可以为不同业务（甚至不同APP）配置不同的接入策略——这在物联网时代尤其重要。

洞察三：概率控制优于硬开关。 barringFactor的设计让接入控制变成一个"软阀门"而非"硬开关"。网络可以平滑地调节接入流量，从100%放行（barringFactor=0.95）到几乎全部拒绝（barringFactor=0.05），步进仅5%。这种细粒度控制避免了"全开/全关"带来的流量突变。

常见问题

Q: UAC和RRC Reject有什么区别？

A: UAC发生在RRC建立之前。UE在发起RRC之前先做UAC检查，如果被禁止，根本不会发送RRC Setup Request。而RRC Reject是gNB收到RRC请求后、因为资源不足等原因拒绝的。两者的时机完全不同：UAC是"自己拦自己"（UE侧），RRC Reject是"被网络拒绝"（网络侧）。

Q: 紧急呼叫真的永远不会被拦吗？

A: 在标准设计中，AC=8（紧急呼叫）享有最高优先级，通常不会被UAC禁止。但有两种例外：(1) MIB中cellBarred=true时，整个小区被禁止，紧急呼叫也无法接入（但UE会搜索其他小区）；(2) 在某些国家法规允许的特殊场景下，运营商可以限制紧急呼叫。不过在实际部署中，紧急呼叫几乎总是被保障的。

Q: barringFactor=0和没配置有什么区别？

A: bearingFactor=0意味着该AC的禁止检查通过率为0——即该AC的所有请求100%被拒绝。而"没配置"（SIB1中不包含该AC的barring参数）意味着该AC不需要做禁止检查，100%放行。两者是完全相反的效果，调参时千万别搞反。

Q: 运营商自定义AC（32-63）怎么用？

A: 运营商可以在USIM中配置URSP（UE Route Selection Policy）规则，将特定的应用流量映射到运营商自定义AC。例如，把视频流媒体APP映射到AC=33，物联网传感器映射到AC=34。当网络拥塞时，可以只禁止AC=33（视频），而不影响AC=34（传感器）。这在4G中是做不到的。

Q: 5G的UAC能完全替代4G所有接入控制机制吗？

A: 是的。3GPP在设计UAC时明确要求它能覆盖4G中ACB、SSAC、EAB、ACDC的全部功能。UAC通过二维的AI+AC标签，结合概率判定，实现了所有4G接入控制场景的超集。这也是为什么叫"统一"接入控制——一个框架统一了所有场景。

参考来源

1. ShareTechnote - 5G UAC (Unified Access Control) — 5G UAC技术详解，含参数说明和信令分析
2. TelecomGurukul - Advanced Access Control Mechanisms in LTE and 5G NR — LTE与5G接入控制机制的演进对比
3. 3GPP Explorer - UAC Glossary — UAC术语定义和关键特性总结
4. 知乎 - 5G网络中的接入控制技术解析 — 中文5G接入控制原理与实战解析
5. IEEE - An Overview of 5G System Accessibility Differentiation and Control — 学术论文，5G系统接入控制差异化设计综述

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。