<!-- title: 5G接入控制：UAC统一拦门的底层逻辑 -->

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

## 从一个春节红包说起

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

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

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

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

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

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

| 参数 | 含义 | 典型值 |
|------|------|--------|
| **barringFactor**（禁止因子） | 通过概率，0.05~0.95 | 0.7表示70%的请求放行 |
| **barringTime**（禁止时间） | 被拒后等多久再试 | 4s、8s、16s...512s |

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

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

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

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

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

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

| AI值 | 身份 | 典型场景 |
|------|------|----------|
| 0 | 普通用户 | 你我日常使用 |
| 1 | 多媒体优先服务（MPS）用户 | 政府高管、重要客户 |
| 2 | 任务关键服务（MCS）用户 | 消防、警察、急救 |
| 3-10 | 运营商特殊配置 | 安保、公用事业、紧急呼叫 |
| 11 | 接入类别降级（ACDC） | 特定应用的拥塞控制 |

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

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

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

| AC值 | 业务类型 | 说明 |
|------|----------|------|
| 0 | 被叫/寻呼响应 | 手机被叫、响应寻呼 |
| 1 | 移动始发信令 | 注册、去注册等 |
| 2 | 移动始发数据 | 上网、看视频等 |
| 3 | 辅助信令 | 会话管理相关信令 |
| 4 | 短信 | MO SMS |
| 5 | IMS语音 | VoNR/VoLTE语音呼叫 |
| 6 | IMS视频 | 视频通话 |
| 7 | IMS短信 | IMS上发送短信 |
| 8 | 紧急呼叫 | 拨打110/120/119 |
| 9-14 | 保留 | 未来扩展 |
| 15-31 | 标准化预留 | 标准预留 |
| 32-63 | 运营商自定义 | 运营商按需配置 |

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

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

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

```mermaid
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的一大优化，减少了不必要的空口开销。

```mermaid
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配置，这是整个系统的"控制面板"。参数结构如下：

```mermaid
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 LTE | 5G NR |
|----------|--------|-------|
| **控制框架** | 多种机制并存（ACB/SSAC/EAB/ACDC） | UAC统一框架 |
| **判断维度** | Access Class（身份+业务混合） | AI（身份）+ AC（业务）二维分离 |
| **类别数量** | 16个Access Class（0-15） | 64个Access Category（0-63） |
| **自定义能力** | 非常有限 | AC 32-63运营商自定义 |
| **参数广播位置** | SIB2 | SIB1（更早获取） |
| **执行位置** | 主要在UE侧 | 完全在UE侧 |
| **切片感知** | 不支持 | 支持按切片区分控制 |
| **PLMN区分** | 不支持 | 支持按PLMN配置不同策略 |
| **VoWiFi相关** | 需额外机制 | 集成在UAC中 |

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

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

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

```mermaid
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用户）豁免，保障救援通信

### 常见调试陷阱

| 现象 | 可能原因 | 排查方法 |
|------|----------|----------|
| UE反复发起RRC失败 | UAC barringFactor=0 | 检查SIB1中uac-BarringForCommon |
| 特定用户无法注册 | AI在禁止位图中 | 检查USIM中的AI配置+SIB1位图 |
| 所有用户无法接入 | cellBarred=true（MIB层面） | 这不是UAC问题，是MIB中的小区禁止 |
| 漫游用户被拒 | uac-BarringInfoPerPLMN配置 | 检查HPLMN/VPLMN的UAC策略差异 |

**最重要的区分：** `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)](https://www.sharetechnote.com/html/5G/5G_UAC.html) — 5G UAC技术详解，含参数说明和信令分析
2. [TelecomGurukul - Advanced Access Control Mechanisms in LTE and 5G NR](https://www.telecomgurukul.com/post/advanced-access-control-mechanisms-in-lte-and-5g-nr-networks) — LTE与5G接入控制机制的演进对比
3. [3GPP Explorer - UAC Glossary](https://3gpp-explorer.com/glossary/uac/) — UAC术语定义和关键特性总结
4. [知乎 - 5G网络中的接入控制技术解析](https://zhuanlan.zhihu.com/p/1948731719210497208) — 中文5G接入控制原理与实战解析
5. [IEEE - An Overview of 5G System Accessibility Differentiation and Control](https://ieeexplore.ieee.org/document/9696270) — 学术论文，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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)