1. 先别急着看信令标题里的NAS是什么不是什么打开这篇文章的读者我猜一多半是奔着“NAS”两个字来的但可能心里想的是群晖、绿联、飞牛那一类存储设备。这个开头我先把这个误区拆干净标题里的NAS和文件存储服务器没有半毛钱关系。在5G的协议栈里NAS是Non-Access Stratum非接入层。它指的是UE手机和核心网AMF接入和移动性管理功能之间的信令传输层不经过基站gNB的解析直接对核心网说话。接入层AS则是UE和gNB之间通过RRC无线资源控制协议交互的那部分。为什么要把这两层放在同一个标题里因为5G的Unified Access Control机制恰恰横跨这两个层面规则在NAS层生成和下发限制在执行层RRC兑现。如果只讲NAS不讲RRC你只知道规则长什么样不知道终端最后是怎么被拦下或放行的只讲RRC不讲NAS你只知道终端尝试接入被拒不知道背后的分类逻辑是谁定的、怎么下来的。这篇文章的目的就是把这条从核心网到终端的完整链路拉通讲清楚UAC这套机制到底是怎么在NAS规则和RRC行为之间协同工作的。适合看这篇文章的人有两类一类是做5G信令分析、网络优化、接入类问题排障的工程师平时抓包看到RRCSetupRequest被判了WaitTime或者终端压根不发Service Request但对根因链路不够清晰另一类是刚接触5G协议、想把Registration流程和Access Control机制串起来理解的学习者。前者可以在文章里找到排查路径和实操心得后者可以顺着NAS到RRC这条线建立整体框架。2. 一纵一横看整体UAC在5G协议栈里的精确落点2.1 三位角色各管一段UE、gNB、AMF的分工边界聊UAC之前得先把参与方对齐。一个终端要接入5G网络牵涉到三个主体UE终端发起接入请求执行接入控制判定。gNB基站无线侧的执行者收到UE的RRC连接请求后根据自身负载和小区状态决定接受还是拒绝。AMF核心网网元规则的制定者在NAS层下发接入控制配置。对应到协议栈UAC的链路是这样的核心网AMFNAS层生成ACL/接入规则 │ │ NAS消息Registration Accept / Configuration Update Command ▼ 终端UENAS层存储规则AS层执行判定 │ │ RRC消息RRC Setup Request / RRC Reject ▼ 基站gNB无线侧准入控制依据负载和ACL执行/拒绝这套流程里有个关键点容易被忽略AMF并不直接参与RRC的接纳判决它只是把“规则”通过NAS消息带到终端终端遵循规则决定“要不要发起接入尝试”只有在终端发起了RRC连接请求之后gNB才有机会做接纳控制。所以UAC的本质是“前置准入”在网络资源真正被占用之前先让终端自己判断“我现在该不该往这个小区发请求”。2.2 Access Category和Access IdentityUAC的两个核心维度3GPP在TS 24.501协议里定义了UAC的执行逻辑核心是两条轴Access Category接入类别下称AC和Access Identity接入身份下称AI。Access Category决定的是“这次接入属于什么类型”它有编号区间Category 编号用途说明0不适用保留1MT移动终止信令用于寻呼响应、网络侧触发的信令2紧急呼叫优先级最高的一类3除紧急呼叫外的语音业务如VoNR呼叫4运营商定义的业务子类需运营商在ACL中具体配置5-7运营商定义的业务类别如IMS信令、移动性管理、特定应用8-31运营商在标准里的扩展类须在ACL中显式定义32-63终端厂商/应用层的归属类由OS或应用根据业务需求自行映射Access Identity则是“谁来接入”的身份标签决定了这条接入尝试是否拥有豁免或优先待遇AI 0普通用户无特殊身份。AI 1被配置了高优先级接入的UE如关键任务通信用户。AI 2IOCIsolated Operation隔离运营场景下的UE。AI 3-5各类公共预警业务中需要特殊接入权限的UE。AI 11-15不同等级的运营商运维终端相当于网管专用通道。UAC的判定就是拿AC, AI这个二元组去查ACLAccess Control List接入控制列表里的规则。规则有两类一类是UE特定接入控制列表UE-specific Access Control List由AMF在NAS消息里单独下发给某个终端另一类是小区特定接入控制列表Cell-specific Access Control List随系统信息广播给小区内所有终端。2.3 为什么这个机制叫“Unified”用一句通俗的话解释3G时代接入控制靠网络侧“一刀切”的ACAccess Class Barring不能区分具体业务4G时代虽然有类似机制但和ACB、EABExtended Access Barring、SSACService Specific Access Control等多个方案并存各管一摊互不打通。5G的UAC把上述这些全部收拢统一成了一套以AC, AI为索引的规则表。终端不再需要分别判断“我在不在ACB的禁止名单里”“SSAC限制的是什么业务”只需要查ACL里对应分类的比特位就行。这个“统一”带来的直接价值是运营商可以在一个清单里同时实现紧急呼叫放行、VoNR优先、普通数据限流、运维终端豁免而不是维护多套互不相干的限制策略。网络高负载时gNB下发小区ACL终端自行判断能有效避免大量无效的RRC建立请求打爆无线侧。3. 网络下发“白名单”NAS层如何定义接入规则3.1 ACL是怎么通过NAS消息装进终端的AMF在终端完成注册流程后比如Registration Accept或者需要更新策略时比如Configuration Update Command会在NAS消息里携带uac-acl信息单元IE。这个IE里是一套完整的AC, AI - 准许/禁止映射关系。用抓包数据举例一条简化的Registration Accept里可以看到这样的字段结构uac-acl { uac-ACL-List { AccessCategory 1, AccessIdentity 0, Allowed 0 AccessCategory 1, AccessIdentity 1, Allowed 1 AccessCategory 3, AccessIdentity 0, Allowed 1 AccessCategory 5, AccessIdentity 0, Allowed 0 } }这段含义是普通用户发起的MT信令AC1, AI0被禁止但高优先级用户AI1的同类信令放行语音业务AC3放行运营商定义的IMS信令AC5被限制。这里有个实际工程里常见的坑ACL不是全量下发。AMF可能只下发部分类别的规则终端对没收到规则的那部分AC默认是“允许接入”还是“禁止接入”取决于协议里对“缺省行为”的定义。在TS 24.501里缺失规则通常按允许处理但这个前提在跨厂商组网时未必一致。我在实际项目里就见过核心网侧只下发了一条针对AC8的禁止规则结果某个型号的终端把没收到规则的AC3语音业务也一并拦了——终端协议栈对缺省值的实现有偏差。这个案例放到后面排查篇细说。3.2 规则在终端侧怎么被解析UAC判定逻辑终端侧拿到ACL之后并不是在NAS层直接拦截而是把规则交给AS层的接入控制模块。每次应用发起数据/信令业务时NAS层先做一次分类确定AC和AI然后把这个二元组交给AS层去查ACL。如果再细化一下判定流程的顺序大致是这样的应用发起业务比如打电话、发微信、触发MMS。NAS层根据请求来源和QoS需求把业务映射为AC比如VoNR映射为AC3。NAS层检查AI终端里配置了哪些高优先级身份默认是AI0。NAS层将AC, AI传递给AS层。AS层查看ACL中对应记录的“禁止/允许”位。如果允许终端直接发起RRC连接建立如果禁止启动对应的禁止定时器T390或T302派生值。这个流程里最容易被误解的点是UAC的判定发生在RRC建立请求发出之前而不是基站侧的统一准入控制。gNB的RRC层还有自己的一套接纳控制比如基于PRB利用率的准入和UAC不是一回事。前者是“终端自己检查入场券”后者是“检票员二次核验”。理解了这一层后面看信令流程时思路会清晰很多。3.3 NAS层规则更新的触发场景AMF下发ACL的时机不止注册流程以下几类场景在工程上都很常见注册接受终端初始入网时网络侧把策略一次性灌进去。配置更新网络侧通过Configuration Update Command在下一次周期性更新时调整规则。接入限制解除某些category从禁止置为允许时AMF会重新下发ACL终端重置相应的禁止定时器。TAU/Service Request后的即时更新当网络侧策略变化超过一段时间未被终端感知时AMF强制触发一次更新流程。实测里有个细节ACL的时效性与终端的省电策略有冲突。终端进入空闲态或省电模式后不主动监听NAS层的策略更新如果此时网络侧已经把某个AC从禁止改成允许终端仍会按照旧规则拦截。排除这类问题需要同时看核心网侧的下发时间和终端的实际行为时间如果两者有较大差距请优先怀疑终端的省电模式。4. 终端侧的最后一道闸RRC连接建立与拒绝的微观过程4.1 RRC建立请求里的“类别指纹”终端过了UAC自检决定“我可以尝试接入”接下来就轮到RRC层的动作了。UE向gNB发送RRCSetupRequest这个消息里有个字段叫establishmentCause建立原因它本质上就是UAC分类在无线侧的“指纹”。常见的establishmentCause映射关系如下establishmentCause触发场景对应的典型ACemergency紧急呼叫AC2mo-Signalling终端发起的信令比如Service RequestAC1或运营商定义的信令类mo-Data终端发起的用户面数据AC4~7中的特定类mt-Access响应寻呼的接入AC1MT信令highPriorityAccess高优先级用户发起AI非0时对应的类别gNB收到这个字段后结合本小区的配置是否允许紧急呼叫、当前是否处于高负载、该establishmentCause对应的AC是否被本小区禁止决定是回RRCSetup还是RRCReject。这里值得强调一下establishmentCause只是UAC判定后的“结果摘要”。终端已经在NAS/AS层查过ACL了如果被判禁止就根本不会发出RRCSetupRequest。所以你在抓包里看到某个终端频繁发RRCSetupRequest然后被拒不能简单地归因于UAC更多要往gNB接纳控制或核心网侧条件去查。4.2 RRCReject里的WaitTime为什么那么关键gNB拒绝终端时会在RRCReject消息里带一个waitTime以秒为单位。这个值直接决定了终端在收到拒绝后必须等多久才能再次发起接入尝试。从协议角度看这个等待机制是为了防止拒绝后的“羊群效应”——所有被拒终端立刻重试把小区信令风暴推得更高。具体到不同场景waitTime的意义不同UAC导致的拒绝NAS层触发的ACL禁止终端会基于ACL里的禁止时长启动T390定时器此时RRC层的waitTime是个附加限制。gNB侧接纳控制拒绝gNB因为资源不足拒绝时waitTime是RRC层强制的退避时间终端在这个时间内不能向该小区发起任何同类接入尝试。核心网附着拒绝如果拒绝发生在NAS层比如MME回Service Reject终端依据那条NAS消息里的定时器字段决定是否重新注册。T390和T302是两个和UAC高度相关的定时器很多人分不清T390NAS层收到AC prohibited信息后启用的禁止计时器时长由ACL里的bit位和特定配置表决定。在T390运行期间终端不会发起对应AC的接入。T302RRC层收到RRCReject后启动的退避计时器时长来自waitTime。T302在运行时终端能发起部分信令但对数据业务会有限制。工程上判断“这个终端为什么半天不发起业务”第一步就要区分是T390还是T302在跑。之前遇到一个现象某台测试终端在发出Service Request后极长时间没有后续动作抓底层日志发现T302在运行以为是基站给的waitTime太长后来看了AMF侧的配置才发现是核心网下发的ACL里把该类业务禁止了终端根本没走上RRC流程是我们抓包位置不对没看到被掐断的NAS信令。4.3 高优先级接入豁免在RRC层的表现前面提到AI接入身份会直接影响ACL判定结果在RRC层也有对应表现。当终端被配置了高优先级接入身份如AI1时即使该小区ACL中普通用户对应的AC是被禁止的它仍能发起RRCSetupRequest并且establishmentCause会置为highPriorityAccess。这个设计在应急通信和VIP用户保障里很关键。比如演唱会现场、体育赛事这类高密度场景运营商会给现场保障人员、应急指挥终端预配AI1身份同时把普通用户的数据业务AC设为禁止。普通用户在这种场景下发朋友圈会直接被终端拦截UAC前置判定而保障终端却能正常接入。从网络侧看这样的好处是RRC连接建立流程根本不会被普通用户请求淹没无线资源留给真正的保障业务。这个机制给了我们一个调优思路如果你负责的是一个高密度话务场景与其依赖gNB的接纳控制“硬扛”不如在核心网侧主动配置ACL让终端在源头上分流。两者配合能显著降低RRC建立失败率和信令面拥塞概率。5. 用一条真实信令把NAS和RRC串起来读5.1 从Service Request到RRC建立的30秒时间线前面把NAS层和RRC层的机制分开讲了这一节放在一起走一遍完整流程。假设场景是一部5G手机从飞行模式恢复重新注册入网后用户打开微信执行一次扫码支付触发数据业务。下面是一条典型的信令时间线从终端视角T0.0s 终端上电/恢复服务发起RRCSetupRequestestablishmentCausemo-Signalling T0.1s gNB下发RRCSetup完成RRC连接建立 T0.2s 终端发送NAS消息Registration Request初始注册流程 T1.0s 网络侧回Registration Accept其中携带uac-acl IEAC1/3/5等类别的允许/禁止位 T1.1s gNB下发RRCRelease终端回到空闲态IDLE ——以上是终端拿到UAC规则的过程—— T30s 用户打开微信发起扫码触发PDP/PDU会话建立 T30.1s NAS层把这次业务映射为AC4或AC7运营商定义的数据类 T30.1s AS层查ACL对应AC4, AI0的Allowed位1允许接入 T30.2s 终端发起RRCSetupRequestestablishmentCausemo-Data T30.3s gNB回RRCSetup建立RRC连接 T30.4s 终端发送Service RequestNAS层 T30.5s 网络侧接受服务请求建立用户面数据承载这条时间线把两个阶段的规则完全串起来了规则在注册流程里被“安装”到终端在具体业务触发时被“查询”和执行。很多人读信令只看抓包的某一段要么盯着RRC连接建立过程要么只看NAS注册流程结果对UAC规则“什么时候装的、什么时候用的”没有一个整体概念。这种做法在常规分析里问题不大但遇到“业务为什么发不起来”这类疑难杂症时就会到处碰壁。5.2 一种更隐蔽的情况ACL判定发生在PDU会话建立之前上面例子里业务数据的接入判定发生在Service Request阶段这是最常见的情况。但5G里还有一种场景某个业务会话已经建立、后续数据包切换时依然会发生UAC判定。比如一个终端正在用VoNR通话AC3通话过程中用户又开始下载大文件AC7。如果ACL里AC3是允许的、AC7是禁止的通话不会中断但下载流量会被限制。这种基于“业务类别”的动态切换在协议栈里也是走NAS层的分类逻辑再交到AS层查ACL的。实际测试中有个有意思的现象不同厂商的终端对同一ACL的“业务分类粒度”差异很大。有的终端把IMS注册信令映射为AC5有的映射为AC4还有的干脆映射成和普通数据一样的AC。这意味着同一个UAC策略在A品牌手机上能精确限制IMS信令在B品牌手机上可能会把IMS信令和普通数据一起限了。做多厂商终端兼容性测试时务必把UAC分类的映射规则差异列为专项检查点否则上线后容易冒出“为什么这家运营商的某品牌手机VoNR总是异常”的问题。5.3 遇到接入失败先区分三层原因把NAS和RRC串起来读最终目的还是为了定位问题。遇到终端无法建立业务信道的情况我日常习惯先按这个三分法缩小范围层级典型现象可能根因NAS层终端根本不发Service Request或发完就进入定时器等待UAC ACL禁止、核心网策略限制、终端定向映射错误RRC层RRCSetupRequest发出但反复被Reject或有 T302退避gNB接纳控制拒绝、小区负载高、establishmentCause被小区策略限制核心网RRC建立了Service Request被Reject如#7、#15签约数据限制、切片不可用、核心网侧接入控制策略这个表格看起来简单但实际排障时很多工程师第一步就栽了看到RRCSetupRequest被拒就一直盯无线侧参数调调了半天没用后来发现是核心网在NAS层下发的ACL把该类业务禁了终端的RRC流程根本没发出去。反过来也有终端发了RRCSetupRequestgNB也回了RRCSetup但Service Request石沉大海有人还把问题算在UAC头上其实压根不是。6. 调试UAC问题的实战排查路径与经验清单6.1 抓包位置决定你能看到什么UAC问题排起来麻烦有一个重要原因是它的判定发生在终端内部网络侧抓包不一定能看见。终端做了UAC自检后被拦截这个过程在网络侧零痕迹只有终端日志能反映。所以排查这类问题第一个动作是明确抓包位置如果怀疑NAS层下发规则不对抓N1/N2接口信令AMF与gNB之间重点看Registration Accept里的uac-acl字段内容。如果怀疑终端没按规则执行必须用终端侧日志如QC log、MTK log或各类测试终端的抓包工具看AS层查ACL的判定结果。如果怀疑gNB侧接纳控制导致RRC失败抓Uu接口的空口信令结合无线侧话统看RRCReject消息里的waitTime和回落原因。很多项目里三种抓包位置没有统一记录时间是最大痛点。我处理过一个跨省投诉怀疑某个片区的UAC策略下发改错了无线侧说“我们发了正确的RRCReject”核心网侧说“我们下发的是允许但终端没发RRC请求”两边扯了半周。最后通过对三份日志统一时间戳才定位到问题出在核心网MME/GN配置的ACL里有一个bit位写反了导致终端查询时把“允许”读成了“禁止”。时间戳不对齐这种问题根本没法查。6.2 排查UAC不上线的三个典型场景根据实际运维经验UAC问题最常出现在以下三类场景中每个都有对应的排查思路场景一某片区终端发不起业务但注册成功信令表现终端能完成注册流程能收到Registration Accept但一发起业务就停住不动。排查链路看终端日志确认AS层查询ACL时命中的是哪条规则、AC和AI的具体值。回看Registration Accept里的uac-acl确认网络侧是否下发了禁止该类业务的规则。如果规则确实禁止了看禁止时长T390和期望的业务建立时间是否冲突——比如规则禁止了30秒但用户发起业务刚好在禁止窗口内。确认gNB侧有没有额外的RRCReject补充限制。场景二语音业务VoNR总是建立失败数据业务正常这个场景非常有代表性。VoNR的AC通常是3语音的IMS信令AC可能是5。如果网络侧的ACL把AC5设为禁止终端就无法完成IMS注册自然打不了电话但普通数据AC4/7不受影响。排查链路先确认VoNR呼叫失败时终端是否发出了RRCSetupRequest。如果没发十有八九是UAC拦截。看ACL里AC3或AC5对应的允许位。如果发了但被Reject再判断是gNB对establishmentCausemo-Signalling或语音相关cause的限制还是无线环境问题。场景三切换后业务异常终端从小区A切换到小区B后发现某些业务发不起来。这个场景很多人会忽略一个链路因素切换后网络侧可能下发新的配置更新把ACL的规则重新下发一遍但终端的应用层还保留着旧业务的AC映射。如果新规则把原本允许的AC给禁了业务自然就断了。排查链路看切换完成后的RRCReconfiguration和NAS配置更新消息。对比新旧ACL里相同AC的允许/禁止位是否发生变化。如果有变化直接定位到“切换后UAC规则漂移”这一根因。6.3 网规参数与终端兼容性表格工程上做UAC参数配置时建议把以下关键配置项单独拎出来管理每一项都值得单独验证配置项作用常见错误建议值/验证方式uac-acl里的AC位掩码控制各类业务的允许/禁止位写反、AC编号对应错用测试终端逐类业务验证Access Identity配置决定特殊用户是否豁免普通用户误配AI1导致高优先级通道被占用严格控制配置范围审计放号缺省ACL规则处理未显式下发的AC部分终端把缺省视为禁止兼容性测试重点关注禁止时长T390派生值控制终端重试周期设置过短导致信令风暴结合RRC建立成功率调整gNB接纳控制的waitTimeRRCReject后的退避过大影响用户感知过小无保护效果参考业务建立时延要求设置终端兼容性方面不同厂商的协议栈实现差异主要集中在两点一是业务到AC的映射表前面提过二是对缺省规则的处理。建议在项目交付前做一张UAC专项测试用例表覆盖每种AC的强制禁止、每种AC的强制允许、部分AC禁止/部分允许混合场景、高优先级AI豁免场景、动态更新ACL场景。这套测试做扎实了能堵掉大部分上线后的接入类故障。6.4 一个被忽略的细节UAC和网络切片的交叉5G网络切片和UAC的联动是排障时容易漏掉的结合点。切片内的业务映射也会影响AC分类。比如NSA非独立组网锚点小区和SA独立组网目标小区切换时如果UE的切片信息没随切换流程正确传递终端选择的AC可能和实际业务不匹配导致被误禁或误放。遇到“切片里数据传输正常但语音业务异常”的场景除了切片本身也要看一眼切片关联的ACL规则是否和语音AC冲突。有些核心网套餐模板里为某个切片配置了高优先级的Access Identity但绑定的AC却把语音业务归到了普通数据类导致语音在切片内反而不如切片外稳定。写在最后调UAC问题的一点个人心得UAC这套机制理论框架并不复杂就是一张AC, AI查规则的ACL表。但实际工作中它牵涉的层级多、参与网元多、终端实现差异大导致这类问题往往披着“无线侧故障”的外衣出现在工单里。我个人排查的固定动作有三个先明确抓包位置再统一时间戳最后按NAS层规则-AS层执行-RRC层接纳的顺序逐级排查。每次遇到诡异的上线类问题只要严格走这三步基本都能在半小时内把责任网元锁定。最后分享一个小技巧做UAC规则验证时别总在实验室里构造理想环境一定要在现网的小区里做一次“真刀真枪”的ACL禁用测试。让终端在一个AC被禁止的小区里反复尝试多种业务看它到底会表现出什么样的失败现象记录日志。这些现象样本比协议文档有用得多——下次线上出了类似问题你一眼就能认出“哦这是ACL禁止后的典型症状”而不是对着抓包数据反复猜终端到底哪一步没走对。