上周处理一个演唱会现场的网络投诉后台指标看起来很有意思随机接入成功率正常RRC建立成功率也过得去但实际在线用户数一直上不去好多5G手机显示有信号业务就是起不来。信令一抓才发现大量终端在发RRC建立请求前就被拦住了拦它们的不是拥塞不是覆盖而是很多人平时不怎么关注的Unified Access ControlUAC。这篇文章就把这条从NAS到RRC的5G接入控制链路完整梳理一遍顺便把SIB1参数、判定算法、排障手段这些实操内容一并讲透。先提醒一句很多对网络存储感兴趣的朋友看到NAS两个字就以为是群晖、飞牛、玩客云刷机那类设备这里完全是两码事。5G协议栈里的NAS是Non-Access Stratum非接入层负责注册、鉴权、会话管理等核心网信令UAC要从这一层开始说起。文中涉及的配置思路和排查手法主要基于5G SA独立组网NSA场景的接入控制落在LTE侧逻辑有差异后文会单独说明边界。1. 为什么5G一定要把接入控制统一起来1.1 LTE时代接入控制机制的碎片化LTE时期的接入控制叫法很多ACBAccess Class Barring、EABExtended Access Barring、ABOAccess Barring for Operator、SSACService Specific Access Control、ACDCApplication specific Congestion control for Data Communication等等各有各的参数各有各的触发条件。网优工程师调一个小区拥塞策略往往要在几个功能之间反复权衡普通语音业务走SSAC机器类终端走EAB入口拥堵了再叠加ACB哪一层没配合好要么该拦的没拦住要么正常用户被误伤。这些机制还有一个共性问题就是终端实现复杂度太高。每个功能都是独立的一套信令流程和判定逻辑芯片厂商要分别适配、分别测试运营商每引入一个新功能都要拉着终端、网络、仪表反复联调。我见过不少项目一个SSAC的验证就能拖两三个月还经常出现某个终端型号在特定版本下触发条件不对的诡异问题。1.2 UAC的设计目标一个框架适配所有场景3GPP在5G设计之初就打算从根上解决这个局面UAC的目标非常明确用一套统一的接入类别Access Category和接入身份Access Identity二维模型替代原先七七八八的多个独立机制。规范层面由三份标准共同支撑TS 22.261定义业务需求TS 24.501负责NAS侧的类别判断和参数映射TS 38.331负责RRC侧的广播参数和最终判定算法。从网络运维的角度看UAC带来最直接的好处是配置入口统一了。以前调ACB找一套参数调SSAC又找另一套参数现在只需要在SIB1里维护一张接入类别→限制策略的对应表普通用户、漫游用户、语音业务、运营商内部服务、紧急通信都能在这一张表里表达清楚。参数的粒度也从按接入等级细化到了按接入类别×接入身份精细化程度显然更高。1.3 UAC和传统ACB的本质区别打个比方LTE的接入控制像是小区门卫根据你是几号楼业主来决定放不放行UAC则是先看你来办什么事再看你有没有特殊身份两重条件一起决定。前者只有一维后者是二维的表达能力和灵活性完全不同。还有一个容易被忽略的差异LTE的ACB参数在SIB2里广播一些特定机制还要靠寻呼消息里的bit指示来配合终端要拼凑多个消息才能完成一次完整的接入判断。UAC的参数集中在SIB1里终端在驻留小区之后只需解析这一个系统消息就能拿到当前PLMN下所有接入类别的限制信息逻辑上干净很多。2. UAC的核心坐标系接入类别与接入身份2.1 标准接入类别0~7的划分UAC定义了两套最基本的标签第一套叫接入类别Access Category描述这次接入要干什么。TS 24.501里把常见的接入行为划成了以下几类日常排障时看到的大部分问题最终都能归结到这些类别上。接入类别含义典型触发场景0未被其他类别覆盖的信令和数据普通上网、默认数据业务1紧急呼叫未被其他类别覆盖拨打紧急号码、IMS紧急呼叫2漫游用户发起的未被其他类别覆盖的数据外地用户漫游入网时的MO数据3通过非3GPP接入发起的业务WLAN接入、卫星接入等场景4运营商特定服务非PS会话运营商自有增值业务、特定测试5未被其他类别覆盖的移动终止服务被叫、网络下发的推送服务6非语音为主的IMS服务IMS信令、IMS视频等7语音相关服务VoNR/VoLTE呼叫建立2.2 运营商特定类别32~63的用法除了0~7之外规范还留了32~63这32个运营商特定接入类别给PLMN自己定义。这部分非常灵活网络可以根据业务类型、切片标识、用户群、位置区域等任意维度组合来设置只要在SIB1里把对应的类别映射到一套限制参数上。比如运营商希望在某片区域内限制某个大视频APP的流量可以给这个APP定义类别40在网管上把类别40的禁止因子调高终端解析SIB1后自然就按新参数执行。需要注意的是运营商特定类别虽然有32个之多但终端侧是通过USIM或网络配置来识别自己应该使用哪种类别的并不是所有终端都会支持任意类别的映射。实际部署中我建议先挑一两个商用终端验证终端厂商对特定类别的实现是否到位再大规模配置否则很容易出现参数配了但终端不认的情况。2.3 接入身份11~15特殊群体的绿色通道第二套标签叫接入身份Access Identity描述这次接入的用户/设备属于哪类特殊群体。接入身份0表示普通用户没什么特殊待遇接入身份11~15用于网络管理和紧急通信场景。接入身份含义典型使用者1~4运营商自定义身份特定测试、运营商内部维护用户11PLMN管理网络运维人员、设备维护12安全服务警察、消防等应急通信队伍13公用事业电力、水务、燃气等基础保障14紧急服务急救中心、灾害救援通信15高优先级访问公共预警系统、MPS用户接入身份和接入类别同时参与判定。网络在SIB1里针对每个接入类别配置一个8位的bitmap每一位对应一个接入身份bit为0表示这个身份不受该类别的禁止限制bit为1表示该身份也要参与普通因子随机判定。正是通过组合这两套标签UAC才能在同一个小区里做到普通用户限制、紧急通信放行数据业务限制、语音放行这种差异化控制。2.4 二维判定逻辑的实际场景演示用演唱会现场的场景来推演一遍某小区开了UAC接入类别0普通数据的禁止因子设为0.3意味着约七成的普通数据接入会被拦同时给接入身份14紧急服务对应的bit位设成0表示紧急呼叫不受这个禁止因子影响。当普通用户发起视频分享时终端按类别0做随机判定大概率被拦当有人拨打紧急电话时NAS上报接入身份14RRC识别到位图对应位为0直接放行不参与随机数博弈。这个机制看起来简单但实际排障时很多人会忽略一个细节终端可能同时具备多个接入身份。比如一个警务人员的终端可能同时配置了身份12安全服务和身份14紧急服务网络侧如果不查清楚该终端实际上报的是哪个身份很容易在UAC统计中误判紧急服务也被拦截了。3. NAS层的贴标签动作从业务到接入参数的映射3.1 一个业务会话如何确定接入类别要理解UAC的完整链路必须看明白NAS层在其中的角色。简单说接入类别和接入身份的最终确定者在NAS层不在RRC层。当应用层的业务请求到达NAS时NAS会根据业务类型、是否漫游、是否紧急呼叫、是否IMS信令等条件在TS 24.501定义的映射逻辑中找到对应的接入类别和接入身份。举个例子一部手机在通话的同时打开一个网页。VoNR呼叫触发IMS语音相关流程NAS把这次接入标成类别7网页流量如果走默认数据承载则标成类别0。两个业务各自独立走UAC检查互不干扰。这也是UAC比LTE更精细的地方——同一个终端并发的业务可以归类到不同的接入类别网络可以只限制其中某一种。3.2 NAS向RRC传递参数的底层交互NAS确定好标签之后要通过层间原语把参数传给RRC层。实际信令流程中能看到的关键参数主要有三个accessCategory、accessIdentity、establishmentCause。前两个决定按什么规则做UAC检查第三个决定RRC建立请求里填的建立原因。这里有句话要重点说NAS把参数传给RRC之后这一层的工作就算告一段落了真正执行随机判定、决定是否发起RRC建立请求的是RRC层。很多初学者容易把UAC理解成NAS做的事其实NAS只负责贴标签RRC才是现场执法。从NAS的角度看它能做的就是等RRC的检查结果如果RRC反馈某个接入类别被禁止NAS就要决定是延迟重试还是直接拒绝上层业务。3.3 与注册、服务请求流程的结合点UAC并不是只发生在终端要发起数据业务的时候。注册流程Registration Request、服务请求流程Service Request、去注册流程Deregistration Request发起时如果终端处于RRC_IDLE或RRC_INACTIVE状态都需要先做UAC检查。这里有个实用的判断技巧通过信令里的establishmentCause和NAS消息类型基本能反推出终端当时用了哪个接入类别。比如终端做周期性注册更新NAS消息是Registration RequestestablishmentCause通常是mo-Signalling接入类别大概率是0拒绝寻呼响应时establishmentCause是mt-Access接入类别会落到5或其他MT相关类别。反向排查时把这些信息抓出来和SIB1里的配置比对很容易定位是哪一类业务被限了。3.4 NAS的重试控制与T390的配合当RRC告知NAS某个接入类别被禁止后NAS层不会立刻重试而是要等T390定时器超时。T390是RRC层启动并维护的时长来自SIB1里的uac-BarringTime参数。定时器运行期间终端对该接入类别的所有后续触发都会被视为禁止状态不能侥幸反复尝试否则UAC就失去限流意义了。在现网中值得留意的现象是NAS层自身的重传定时器比如注册请求的T3517可能比T390先超时终端上层认为注册超时会再次发起请求但底层的T390还没释放。这种定时器打架会导致用户感受到的恢复时间比配置的T390更长。如果发现某类终端被UAC拦截后恢复明显偏慢建议检查一下终端NAS层的重传策略是否和网络的T390合理配合必要时在网管上适当调小禁止时间。4. RRC层的现场执法UAC检查的判定与执行细节4.1 SIB1中的UAC参数结构RRC层要执法依据就得先准备好。UAC的广播参数在SIB1里核心结构是uac-BarringInfoSetList和uac-BarringForAccessCategoryList的配合。前者定义了一批限制策略集每个策略集包含禁止因子uac-BarringFactor、禁止时间uac-BarringTime、禁止身份位图uac-BarringForAccessIdentity后者把不同的接入类别映射到某个策略集索引上。以下是SIB1里UAC相关参数的一个示意结构实际ASN.1细节以TS 38.331为准SIB1 :: SEQUENCE { uac-BarringInfoSetList SEQUENCE (SIZE (1..8)) OF UAC-BarringInfoSet, uac-BarringForAccessCategoryList SEQUENCE (SIZE (1..64)) OF UAC-BarringForAccessCategory, ... } UAC-BarringInfoSet :: SEQUENCE { uac-BarringFactor ENUMERATED { p00, p05, p10, ..., p95 }, uac-BarringTime ENUMERATED { s4, s8, s16, s32, s64, s128, s256, s512 }, uac-BarringForAccessIdentity BIT STRING (SIZE (8)) } UAC-BarringForAccessCategory :: SEQUENCE { accessCategory INTEGER (0..63), uac-BarringInfoSetIndex INTEGER (1..8) }uac-BarringFactor的取值范围是从0到0.95步长0.05最大只有0.95而不会到1.0也就是说网络很难完全放开某个类别通常用0.95表示基本放行但留一点点随机拒绝用0.0表示彻底禁止。uac-BarringTime按秒枚举可从4秒到512秒取值越大终端被拦后的冷却时间越长。4.2 UAC判定算法的逐步拆解RRC层拿到NAS传来的接入类别和接入身份后按以下流程执行判定这个流程也是终端侧实现UAC的核心逻辑先看SIB1里有没有配置uac-BarringForAccessCategoryList如果整个列表都不存在那所有类别都不限制直接放行。在列表中查找NAS上报的接入类别对应的限制条目如果找不到该类别同样视为不受限。找到对应条目后读取uac-BarringForAccessIdentity位图。如果终端上报的接入身份在位图中对应的bit为0说明这个身份被豁免直接放行。如果终端上报的接入身份对应bit为1或者终端上报的就是接入身份0普通用户进入禁止因子随机判定生成一个0到1之间的均匀随机数与uac-BarringFactor比较。随机数小于禁止因子则放行大于等于则判定为禁止。一旦判定为禁止启动T390定时器时长取uac-BarringTime并且在T390运行期间同一小区的后续接入请求都认为该类别仍被禁止不再重复随机判定。这个算法用伪代码看更直观if (sib1 has uac-BarringForAccessCategoryList) { categoryEntry find(accessCategory); if (categoryEntry NULL) { // no entry for this category, allow return ALLOW; } bitmap categoryEntry.uac-BarringForAccessIdentity; if (accessIdentity ! 0 bitmap[accessIdentityIndex] 0) { // special identity is exempted return ALLOW; } rand generateUniformRandom(0, 1); if (rand categoryEntry.uac-BarringFactor) { return ALLOW; } else { startT390(categoryEntry.uac-BarringTime); return BARRED; } } else { return ALLOW; }4.3 紧急呼叫的豁免规则紧急呼叫在UAC里的地位比较特殊这也是网优工程师最关心的场景之一。一般商用网络即使在拥塞状态下也希望紧急呼叫能通。实现手段有两种一种是把紧急呼叫对应的接入类别1的禁止因子配得很高比如0.95并在uac-BarringForAccessIdentity位图中把接入身份14紧急服务的位置清0这样紧急呼叫基本不会被拦。另一种更彻底直接把接入类别1对应的限制条目从SIB1里去掉等于该类别完全不受限。实际测试时要注意不同终端对紧急呼叫的接入身份上报行为不完全一致。有的终端在EPS Fallback场景下会走LTE侧的紧急接入流程不再受NR侧UAC控制有的终端即使网络只配置了接入类别1的限制也会因为内部实现差异不按预期走。所以紧急呼叫的UAC验证必须结合具体终端型号做专项测试不能只看协议文档。4.4 IDLE与INACTIVE状态下的执行差异终端在RRC_IDLE状态下发起RRC建立请求前UAC检查是强制性的这一点没什么争议。到了RRC_INACTIVE状态终端通过RRCResumeRequest尝试恢复连接同样也要先做UAC检查通不过就不会发起Resume流程而是可能在RNARAN-based Notification Area内等待或触发后续动作。这一块在排障中常被忽视。有些终端在INACTIVE状态下做小包业务时上下行数据触发Resume如果刚好被UAC挡住表面看像连接建立不了实际是被接入控制挡住了。排查时不能只盯着RRCSetupRequest这条消息还要看终端是否连RRCResumeRequest都没发出来。两种状态下的UAC参数来源都是SIB1但如果网络配置了按小区或按PLMN差异化下发INACTIVE和IDLE场景落在不同小区时判定结果可能不一致。5. 通过信令与日志还原一次真实的UAC拦截过程5.1 终端侧modem日志怎么看处理UAC相关问题时我习惯先抓终端侧日志因为终端侧能看到NAS和RRC之间的原语交互这是网络侧trace看不到的。常用的手段是用QCAT或者QXDM连接高通平台手机抓FTP日志或DIAG日志然后过滤关键字。不同modem的信息叫法不太一样常见的关键字有UAC、Access barring、BARRED、T390、access category。如果抓到了modem内部日志用以下顺序比对就能快速定位确认NAS层上报的accessCategory和accessIdentity是什么找准业务归属。看RRC层有没有执行UAC检查查SIB1解码后的uac-BarringFactor和uac-BarringForAccessIdentity。看判决结果如果被禁止日志里会有明确的barred原因同时能看到T390启动的痕迹。看T390超时后终端是否重新发起RRC建立流程。这里有个常见的误区SIB1里即使配置了UAC参数RRC层也会在某些异常情况下跳过检查比如终端处于连接态发起新业务、信令流程触发的紧急恢复等。所以不要看到SIB1有UAC参数就认为所有接入都会执行一定要结合业务触发场景判断。5.2 网络侧gNB trace怎么确认判决网络侧看UAC重心不在具体哪个终端被拦而在哪些小区、哪个类别、拦了多少。主流设备厂商的trace工具在信令跟踪里都能看到RRC建立请求被拒绝或未收到的统计。普通的信令跟踪能看到两类关键信息一类是RRC层的UAC参数下发了什么一类是终端实际有没有发RRCSetupRequest。假如后台统计显示某小区RRC Setup Request到达率偏低但RACH成功率正常排查方向就要往UAC靠。反过来如果RRC Setup Request到达率正常但RRC建立失败率高那问题就不在UAC而更像资源分配或干扰问题。还有一个实用的分析角度把SIB1广播的UAC参数和该小区实际话务模型做关联。如果某小区在演唱会、赛事这类大流量场景下配置了UAC可以观察T390禁止的中断服务时长是否影响到了感知再结合投诉判断参数是否需要下调。5.3 案例复盘手机显示5G却上不了网去年处理过一起比较典型的UAC投诉用户反馈在某写字楼区域手机信号显示满格但打开网页转圈微信消息也发不出去。信令抓取后发现几个关键点终端已成功驻留小区SIB1正常解析RSRP在-85dBm左右覆盖没问题。用户发起网页浏览NAS上报的接入类别是0接入身份是0。SIB1中类别0对应的uac-BarringFactor为0.05uac-BarringTime为128秒。终端随机数大于0.05判定为禁止启动T390不发RRCSetupRequest。T390运行期间用户多次刷新网页每次都被同一限制挡住。问题根源很快定位该写字楼小区在某次割接调整中把UAC参数误配成了接近全拦截的状态。网管上改成0.95之后用户业务立即恢复。整个排查过程不到半小时关键就是抓住信号满格但RRC建立前就被停住这个典型特征把排查范围缩小到了UAC而不是在覆盖和干扰上绕圈子。5.4 别把UAC拦截和RRC Reject混为一谈平时排障经常有人把两种场景搞混UAC拦截发生在终端发起RRCSetupRequest之前网络侧根本收不到这条消息而RRC Reject是终端确实发出了RRC建立请求但网络因为资源不足等原因在RRC Setup阶段直接回复了RRCReject。两者在信令上的表现完全不同前者在gNB侧看不到终端的建立请求后者能看到完整的建立尝试记录。判断时可以用一个简单方法gNB的UAC拦截统计会体现在因接入控制未发请求的计数里而RRC Reject则会增加RRC建立失败次数。打开后台指标先看这两类计数器就能在第一轮判断中把问题分流到对应方向。这个思路不仅适用于UAC也适用于很多接入侧问题。6. 网络参数配置调优与排障实战经验6.1 一份可用于模拟验证的配置示例做实验室验证或外场测试时一份完整的UAC相关配置能省很多事。以下是一个适用于外场临时验证的参考配置思路注意不同设备商的参数命名有差异这里只描述参数逻辑接入类别0普通用户数据禁止因子uac-BarringFactor0.3禁止时间uac-BarringTime32秒接入身份位图全1表示普通用户和特殊身份都参与随机判定不做豁免。接入类别7语音禁止因子0.9禁止时间16秒接入身份14对应bit为0紧急语音可豁免。接入类别32运营商自定义测试类别禁止因子0.0禁止时间64秒用于模拟完全禁止某类特定业务。未配置限制条目的接入类别如类别6用于IMS信令视为不限制。配置生效后用测试终端分别发起普通上网、VoNR呼叫、紧急呼叫逐一确认不同业务的判定结果是否符合预期。这个过程建议至少覆盖3个主流终端芯片平台因为不同平台对多接入身份的处理存在实现差异。6.2 和切片、QoS、RACH拥塞的联动关系UAC并不是独立的一座孤岛它和切片拥塞控制、QoS流调度、RACH拥塞控制都有配合关系。比如某张mMTC切片上的终端大量上报数据导致RACH过载可以在RACH侧配置Backoff或Prefix限制也可以在上层通过UAC限制类别32/33等运营商特定类别来减少终端发起建立请求两者效果不同但可以叠加使用。在配置调优时建议明确每种手段的定位UAC负责的是不让终端建立RRC连接属于第一道闸门RACH Backoff影响的是终端发起随机接入的频率QoS调度影响的是连接建立后的资源分配。如果小区拥塞主要体现在RRC建立请求风暴上优先考虑UAC如果主要体现在RACH竞争冲突上应该先调RACH相关参数。很多项目一拥塞就调UAC结果建链请求少了但随机接入前导冲突率还是居高不下就是因为没分清拥堵层级。6.3 运维实测中的几个高频坑第一紧急呼叫被误拦。原因是接入身份14对应的bit位没有精心配置或者某些终端上报的紧急接入类别不是1而是0导致走了普通类别的限制。处理办法是在验收测试中把紧急呼叫作为必测项并且要测试不同号码、不同场景下的行为。第二T390配置过大导致恢复慢。有的小区为了让拥塞快速缓解把uac-BarringTime配到512秒结果拥塞解除之后用户还要等好几分钟才能重新发起业务。正确做法是配合网络负载预测动态调整禁止时间紧急场景用短时间高禁止因子的组合比长时间低禁止因子更灵活也更不容易积压用户投诉。第三终端对该功能的支持不完整。部分老旧终端或行业定制终端对运营商特定类别32~63不理解收到相关配置后直接跳过检查相当于参数配了但没效果。这种问题只能靠终端兼容性测试提前发现没有太好的网侧规避办法。第四PLMN差异化参数与公共参数混用出错。SIB1里既可以配置多个PLMN各自的UAC参数也可以配置对所有PLMN生效的公共参数。如果某局点是多PLMN共享小区配置时没分清作用范围可能出现A网用户被B网的UAC参数误限的情况。6.4 建议纳入日常监控的指标UAC是否工作正常、是否对用户感知造成影响建议从以下指标做长期监控指标观察目的UAC禁止次数按小区、按类别判断限制策略是否真正生效UAC禁止导致的RRC建立请求减少量与业务量趋势对照评估限流效果T390运行时长分布评估用户被拒后的恢复周期是否合理紧急呼叫接通率UAC配置前后对比验证特殊身份豁免是否被正确执行不同终端平台的UAC执行差异识别兼容性问题提前发现隐患有一次我们做过一次全网UAC参数巡检发现某个地市有大量小区的uac-BarringFactor被配成了0。后来查下来是割接时把模拟验证的配置同步到了现网。从那以后凡是涉及UAC的参数修改我都会在变更前后各取一小时的话务指标和UAC计数做对比确保没有把测试参数带进现网。最后分享一个个人体会UAC这类接入控制机制平时在网络平稳运行时很容易被无视等到拥塞发生时才发现配置一团糟。建议在日常优化中就把UAC参数的基线版本管起来每张小区表格里明确哪些类别默认放行、哪些类别预留给特殊场景并且定期做一次验证呼叫。这样真正遇到高负荷场景时只需要微调禁止因子和禁止时间就能快速生效而不是火线上研究参数含义。