简介爱立信SA接入性能分析优化指导书是一份源自爱立信、面向新入职网络优化工程师的5G NR SA接入性能分析实战资料以空闲态终端发起接入的完整流程为主线覆盖随机接入、RRC连接建立、初始上下文建立及可选PDU会话建立/修改等核心阶段并围绕系统消息RACH参数、准入控制、AS安全算法配置等优化维度给出分析思路。资源包内为1个PDF文档大小约1.44MB结构紧凑适合具有基础NR知识、希望深入理解空口与核心网信令交互的优化人员阅读。目前已有296人浏览学习。文档按步骤拆解msg1重传与功率提升、RAR响应窗口、RRCSetupReject判定、终端能力查询、AS加密鉴权配置等关键环节同时梳理基站向5GC传递InitialUeMessage到接收InitialContextSetupRequest的完整链路的优化着眼点可帮助读者快速定位接入时延与成功率瓶颈形成从信令分析到参数调优的闭环方法提升5G SA网络优化效率。1. 5G SA接入成功率卡在99%上不去问题出在你看指标的方式上做爱立信5G SA接入性能分析优化最容易被误导的一件事就是只盯RRC建立成功率这一个数字。实际上一线优化的人都知道SA接入是一条从终端发起随机接入、RRC建立、NG链路建立到初始上下文激活完成的长链路任何一个环节抖动都会反映为“用户上不了网”的投诉但网管上的统计可能还是99%以上。这份指导书存在的意义就是把接入性能从“一个成功率”拆成“一条可分析的信号链”告诉你在爱立信的网管体系里哪个counter对应哪一段流程哪一段流程失败该去查哪个参数。适合的人群很明确正在做5G SA攻坚优化的无线网优工程师、爱立信设备维保项目的技术负责人以及刚接手SA指标日报、需要搞清楚“每天拉出来的数据到底在说什么”的从业者。2. SA接入性能分析三个关键流程阶段与信令锚点2.1 RRC建立阶段MSG1到MSG5的前导与竞争解决SA接入的第一段关键链路是RRC建立过程它在终端和基站之间完成不经过核心网。终端在空闲态RRC_IDLE发起业务时第一步是物理层随机接入也就是PRACH信道上发MSG1。爱立信小区级统计里这个阶段最直接的观察点是pRrcConnEstabReq和pRrcConnEstabSucc这两个counter前者记录RRC连接请求次数后者记录成功的次数两者相减就是RRC建立失败量。但要注意RRC建立失败本身还要拆两类一类是终端发了请求但基站没响应问题出在随机接入RA流程另一类是基站回了RRCSetup但终端没完成这种往往和无线环境、干扰或参数配置冲突有关。随机接入是RRC建立成功与否的第一道坎。在爱立信的参数体系里你主要看PRACH配置和 preamble重试逻辑。常见做法是先检查rachPreambleReceivedTargetPower这个参数的设置它决定基站期望收到的前导序列功率设置太高会导致终端加大发射功率加剧干扰设置太低则基站检测不到前导。另一个关键参数是rachPreambleRepetition它在爱立信NR里默认值一般是1但如果你覆盖的是远点小区或高频段如3.5GHz可以考虑适当增加到2到4次重发。调整之前先确认终端上报的TA时间提前量分布如果大量终端集中在远点说明覆盖半径不够这比单纯调重发次数更治本。RRC建立过程还有一个容易忽略的锚点竞争解决。SA接入里MSG3走的是PUSCH如果功控参数设置不合理多用户同时竞争时很可能互相压制成噪底的一部分。爱立信有个参数叫p0NominalPusch这直接影响PUSCH的开环功控点。我一般会建议在接通率出现“零星失败、无规律分布”时先看终端所在位置的SINR分布如果失败样本的SINR集中在0dB附近优先查这个参数是否被改过。RRC建立成功的标志是终端回了RRCSetupComplete也就是MSG5上来了这条信令没上来多半就是PUSCH链路的问题而非RRC配置本身。2.2 NG建立与上下文激活从RRC完成到初始上下文建立的信号链终端回了RRCSetupComplete之后接入链路进入第二段S1AP接口上的NG建立和上下文激活。这一段参与的不再是基站和终端而是基站gNB和核心网AMF之间的信令交互。在爱立信的统计体系里这一段对应的是pNgConnEstabSucc和pInitialCtxSetupSucc这两类counter。前者是NG接口上NGAP连接建立成功的次数后者是核心网下发Initial Context Setup Request后基站成功完成UE上下文建立的次数。这两者之间如果存在明显差值问题就出在基站和核心网的配合上而不是无线侧。最典型的失败场景是RRC成功率99.5%但Initial Context Setup成功率只有96%。这种差值意味着有将近3.5%的用户在RRC建立完成后没能等来核心网的上下文激活指令。排查方向要聚焦NG接口的拥塞和核心网AMF侧的状态。爱立信网管里可以查ngSignalingConn的计数如果接近上限比如配置了eNbNgcMaxUe但实际负荷高于预期就要扩容NG链路或调整核心网侧的流控参数。另一个必须检查的点是PLMN和TAC配置是否完整如果终端的USIM卡上只有一个PLMN而gNB广播的PLMN列表存在MCC/MNC不匹配核心网会直接拒绝建立NG连接成功率上不去且伴随大量UE Context Release。还有一种容易被误判为“无线差”的情况Initial Context Setup失败但原因值是“timeout”。这类失败在网管上归为无线侧超时但实际往往是核心网侧处理能力不足或者AMF和UPF之间的N3链路配置有问题。爱立信的eNodeB日志如enodeb内fx相关log里能看到NGAP Cause字段为radioNetwork:time-out的条目如果这类条目占比高别急着调无线参数先去和核心网侧对一遍接口配置。2.3 接入失败类型归类先分清是“进不来”还是“起不来”承接上面两段接入失败在优化逻辑上要先归成两大类“进不来”和“起不来”。“进不来”指终端连RRC都没有建起来对应的counter是pRrcConnEstabReq到pRrcConnEstabSucc之间的差值“起不来”指RRC建起来了但业务数据链路没有成功对应Initial Context Setup的差值。这两类失败的优化方向完全不同前者要查PRACH、覆盖和干扰后者要查NG链路、核心网配置和切片策略。如果只看总成功率就被黑匣子吞掉了定位能力。具体操作上建议在爱立信网管上做一张每天的分段统计表RACH成功率、RRC建立成功率、NG建立成功率、Initial Context Setup成功率、E-RAB建立成功率每段单独算。如果四段里只有某一段明显掉问题就锁定在那一段的范围。做过SA优化的人都清楚四段同时掉那是天灾大面积故障单段掉才是人祸参数或配置问题。按这个口径拉一周数据看趋势比盯一个综合指标有效得多。而且分段口径还能帮你在写日报周报时直接指出“本周接入主要受NG建立失败影响”这个结论比“接入成功率波动”有说服力。3. 核心指标定义与采集把接入成功率拆到可操作的粒度3.1 爱立信网管上该拉哪些counter与公式口径落地到爱立信的网管体系CommonBS或集中网管你要拉的counter需要按接入分段整理成一张固定表格。我给出的常用口径如下表这些counter在爱立信NR网管的Performance Management里都有标准定义拉取周期建议设置为15分钟粒度用于日常监控做攻坚分析时按小时粒度拉取因为15分钟粒度在大量失败时反而噪声太大。指标名称爱立信counter常用名计算公式说明RACH成功率prachAttempts / prachSuccessesrachSucc / rachReq物理层随机接入成功率RRC建立成功率pRrcConnEstabReq / pRrcConnEstabSuccrrcEstabSucc / rrcEstabReq不含因负荷拒绝的请求NG建立成功率pNgConnEstabReq / pNgConnEstabSuccngEstabSucc / ngEstabReqNGAP连接建立成功率初始上下文建立成功率pInitCtxSetupReq / pInitCtxSetupSuccinitCtxSucc / initCtxReq核心网上下文建立成功率E-RAB建立成功率pErabEstabReq / pErabEstabSuccerabSucc / erabReqQoS流建立成功率拉取时需要特别注意过滤条件。爱立信counter里有些是包含紧急呼叫和测试呼叫的优化分析的时候建议按标准业务的Establishment Cause过滤把emergency和mt-access这类特殊原因值排除掉否则数据会被平均掉。另外不要在多个小区聚合粒度上做成功率相除应该先分别求和再相除否则小小区的高失败率会被大小区的低失败率掩盖。3.2 用MR和Trace下钻从小区级指标定位到用户级异常网管counter只能告诉你“哪里失败了”不能告诉你“为什么失败”。要回答“为什么”需要下钻到MR测量报告和Trace信令。爱立信的MR数据在NR侧可以输出测量报告里面包含终端上报的RSRP、RSRQ、SINR三件套。接入失败样本和正常样本的这三项指标对比是最快的下钻方式。操作步骤很直接在网管上导出接入失败时间段的前后15分钟MR数据按RSRP区间做分桶统计然后看失败率是否在低RSRP区间集中。如果失败率在RSRP低于-100dBm的区间显著上升问题锁覆盖如果RSRP分布正常但SINR在0dB上下锁干扰两者都正常去查配置。Trace侧爱立信的UU口和NG口Trace可以关联到具体的IMSI做用户级追查。常见做法是按失败用户的IMSI过滤出完整的信令流程看失败在哪个信令步骤回原因值比如RRCSetup后没回RRCSetupComplete就要回到物理层看PUSCHInitial Context Setup失败原因值是“no-radio-resources-available”就要查小区容量配置。这种从指标下钻到信令的过程是接入性能分析里最核心的实操能力。新手最容易犯的错误是直接拿小区级RSRP均值去猜测原因这完全没用。正确的做法永远是把“失败样本”单独拎出来和“成功样本”做对比看它们在什么维度上有区别。没有对比就没有定位。3.3 典型基线一个健康SA小区的接入指标应该是多少判断一个SA小区接入是否健康需要先有基线。根据国内主流5G SA商用网络的运营经验各家设备商的统计口径不同但量级相近以下是我常用的参考基线。注意这是“参考”不是“标准”具体数值受频段、覆盖场景和终端比例影响但偏离这些区间超过1个百分点就值得排查。指标健康区间警戒区间异常区间RACH成功率≥99.5%98%~99.5%98%RRC建立成功率≥99%97%~99%97%NG建立成功率≥99.5%98%~99.5%98%初始上下文建立成功率≥99%96%~99%96%E-RAB建立成功率≥99%97%~99%97%这里有个容易被误解的细节RACH成功率不等于RRC建立成功率前导发送失败后终端会退避重试重试成功算RACH成功但时延已经上去了。所以即使计数器上RRC建立成功率在健康区间用户的入网时延可能已经高到影响体验了。优化接入不仅看成功率还要看时延分布尤其是RACH时延和RRC建立时延的P95分位数。爱立信的counter里有时延统计维度如rachDelay和rrcSetupDelay盯成功率的同事也建议一起盯这两项的P95趋势。4. 接入失败定位方法九步排查法找到真正根因4.1 前三步先排除覆盖与干扰的“物理层嫌疑”接入失败的定位不能一上来就调参数要按逻辑顺序排查。我把这个流程整理成九步前四步覆盖物理层中间两步覆盖配置与邻区后三步覆盖终端和核心网交互。第一步是确认SSB波束的覆盖情况。在爱立信网管上查小区的SSB RSRP分布如果接入失败样本集中在SSB RSRP低于-105dBm的区域先补覆盖而不是调接入参数。SSB的功率设置直接决定覆盖半径爱立信NR里ssbPower这个参数默认值是配在小区级发射功率基础上的调它之前先确认小区总功率余量够不够。第二步是查干扰重点看PRACH频段上有没有上行干扰。接入失败如果集中在特定时间段比如每天同一时段优先怀疑干扰源是周期性的比如其他系统的TDD配置不匹配。在爱立信系统里可以通过上行RB级的干扰统计来看PRACH所在时频资源上是否噪声抬升如果IoTInterference over Thermal抬升超过-110dBm说明存在底噪污染。第三步查参数一致性问题即prachConfigurationIndex是否与邻区和其他同频段小区冲突。这个参数控制PRACH时频资源的密度如果邻区之间配置不一致会造成前导干扰表现为RACH成功率尚可但时延偏高。这三步做下来至少能筛掉60%以上被误判为“参数问题”的接入失败。物理层没查清楚就去动RRC参数结果往往是改了参数成功率还是那样然后你开始怀疑统计数据不可靠最后发现是干扰早就存在了。我自己刚做SA那会儿就吃过这个亏上来就改前导目标功率改完没用后来拉干扰统计才看到PRACH的IoT异常。4.2 第四步到第六步查配置冲突与邻区关系物理层排查完进入配置域。第四步是查小区的TAC和PLMN配置。爱立信NR网管上TAC配置错误会导致位置更新失败终端在接入后会立刻被释放这种情况在counter上表现为RRC建立成功但Initial Context Setup成功率上不去。PLMN配置的关注点是MCC和MNC必须与核心网侧完全一致国内运营商的PLMN一般是两位MNC如00或01配置终端网络选择时会精确匹配MNC长度多配一位或少配一位都不行。第五步是查邻区关系是否完整。SA接入失败很多时候不是本小区配置问题而是终端在接入过程中发生了重选或后来切换失败。注意接入阶段终端还没进入RRC连接态不会发生切换但重选是在空闲态发生的如果邻区配置的重选参数sNonIntraFreq和qHyst设置不合理终端可能在随机接入前就重选到了信号更差的小区导致接入失败率升高。这个现象在网管上看起来是本小区接入失败但根因在邻区的重选参数上很多优化人员在这里会绕一大圈。第六步是查小区的接入门限。爱立信NR里小区选择和重选的门限对应参数是qQualMin和qRxLevMin。如果qRxLevMin配得太高比如-110dBm那在远点覆盖区RSRP低于门限的终端根本不会发起接入不是失败而是不尝试这种情况在成功率上不会反映为失败但会表现为小区忙时话务量低、用户投诉“有信号但连不上”。要区分这两者拉终端接入尝试次数分布来看如果尝试次数在低RSRP区间断崖式下跌且成功率正常就是门限问题。4.3 第七步到第九步终端的“黑匣子”与核心网侧交互第七步是查终端类型分布。SA接入失败如果只在某一种终端型号上集中出现比如某芯片平台的老版本基带这是终端协议栈实现差异导致的。常见做法是在Trace里按IMEI/TAC维度做失败占比分析如果在特定TAC上失败率是平均值的5倍以上那基本可以定位为终端问题。这种案例在商用网络中不少见优化侧的应对方案往往不是等终端升级而是先配置临时性的差异化参数比如对该类终端的接入禁止概率调整来对冲风险。第八步是查核心网侧对SA终端的注册策略和切片选择。如果核心网为特定切片配置了接入限制而终端请求的URSP规则指向了受限切片核心网会导致接入流程失败。在爱立信和华为混合组网的现网里基站侧看不到切片配置明细但能通过Initial Context Setup失败的原因值来推断如果原因值是“slice-not-supported”或“insufficient-resources-for-specific-slice”直接找核心网侧确认切片策略即可。这里不建议在基站侧做任何规避动作因为配置了错误的切片重定向规则会引发更大范围的接入异常。第九步是查传输链路和接口配置。回传链路丢包或抖动会导致NGAP信令重传甚至超时表现就是接入成功率在忙时突然掉点。操作上在传输侧做ping测或查看传输误码率同时对比基站侧的SCTP重传计数。这一步很多人会漏掉因为优化工程师习惯性认为“接入成功率低就是无线问题”但SA接入的信令面是走IP承载网的一段拥塞的传输路径就能让成功率掉三五个点无线侧指标干干净净。5. 爱立信SA接入优化避坑指南五条实际踩坑记录5.1 现象RRC成功率99.2%但用户感知极差问题出在核心网限速某个站点RRC成功率在99%以上按基线算健康但用户投诉频繁说“数据老断”后台查Initial Context Setup成功率只有94%NG建立成功率98%。最开始怀疑无线侧翻遍功率和波束配置都没发现问题后来查NG信令发现AMF侧对该基站配置了最大同时上下文数限制超过限制的请求直接返回“insufficient-resources”。原因是这个基站的业务模型从传统FDD搬迁过来核心网侧没有同步调整容量属性。解决方式很简单请核心网侧扩大该gNB的上下文容量上限成功率立刻回升。这个坑的教训是分段指标必须一起看别被单一指标迷惑。5.2 现象波束权值调完接入率不升反降原因在于SSB功率与PDCCH的功率配比失衡现网为了增强覆盖把SSB的波束权值从广播窄波束改成了宽波束之后RRC建立成功率掉了1.8个百分点。排查后发现问题在于SSB覆盖增强后PDCCH的功率没有同步调整终端在RRC建立后收不到后续的下行调度信令DCI信息导致MSG5丢失。SSB和PDCCH在爱立信NR的功率配置里不是完全独立的ssbPower提高后如果需要保持PDCCH解调性能pdcchPower也需要相应调整。这个案例提醒我们调波束权值时要同步验证PDCCH覆盖能力光看SSB的RSRP只能说明“信号能被看到”不能说明“控制信道能解调”。5.3 现象同站异频切换后必然掉线排查下来是接入禁止参数“抄作业”抄出的问题某个连片优化项目里一批同站异频小区批量配置了新的接入禁止参数barring参数之后出现“切换进来必掉线”的现象。核查发现这批小区的接入禁止参数是从室外宏站模板复制过来的其中acBarringFactor设置为0意味着该小区会拒绝部分接入请求而切换进小区的终端不受这个参数影响切换不检查ACB但接入后立刻被系统判定为“该终端不应该在此小区存在”导致释放。解决方式是恢复该参数的合理值。这事的教训是不同场景室外覆盖/室内分布/高铁的参数模板不能直接复制ACB参数尤其要检查。5.4 现象优化参数“抄作业”后成功率暴跌基带版本差异导致的参数边界借助网上流传的某爱立信SA优化参数模板将rachPreambleReceivedTargetPower从-100调整为-96RACH成功率反而从99.5%掉到97.2%。回查发现该模板对应的是爱立信较新的基带版本处理器而现网是上一代基带版本两者对前导目标功率的映射范围和增益计算方法不一致。老版本基带在这个参数上存在取值边界超过阈值后功控环路的收敛速度变慢前导检测性能反而下降。这个坑非常隐蔽参数模板本身没错但它不是“通用的”。在参考任何参数模板之前先确认现网基带版本、软件版本和目标场景是否匹配不匹配的参数配置比不配置风险还大。5.5 现象凌晨接入正常、白天成功率掉三个点问题出在RACH时域资源密度上一个大学城站点白天接入失败率高凌晨恢复正常。初始怀疑是用户量大导致RACH拥塞但查看RACH尝试次数后发现白天只有凌晨的两倍并没有到拥塞的程度。后来拉前导检测时延分布发现白天前导平均时延明显增大进一步检查发现该站点的prachConfigurationIndex配置的是稀疏的时域图样前导机会间隔过长。在用户并发量并未达到容量上限时前导冲突概率已经显著升高因为稀疏图样下同一时刻可用的前导签名数量不足。解决方式是改用更密集的PRACH时域配置比如增加每个时隙的前导机会频率参数调整后白天成功率回升到正常水平。这类问题白天忙时才会暴露除非做分时段的失败率分析否则很容易把原因归到“用户多了”的概数上。6. 从指标分析到参数落地构建SA接入优化的验证闭环6.1 参数修改的最小集与验证周期接入优化最容易失控的操作就是“一次改很多参数”。网优行业有个默认规则一次参数修改能定位问题的数量只能是一个或同一功能的组合。你在爱立信网管上做参数调整时建议把每次修改控制在“一个功能域内的2到3个相关参数”同时记录修改前后的基线。验证周期要以小时为单位不要改完1小时没变化就觉得“参数无效”。无线参数生效通常需要等终端的行为重新收敛比如重选参数调整后终端需要至少一个重选评估周期Treselection后才开始切换行为这个周期一般在1到10秒量级但终端侧的缓存和网络侧指标统计的时延会拉长整体反映周期。我一般会等至少4小时收集数据并且要求指标恢复稳定后再做下一步修改。如果改了参数后4小时内指标没有改善先回滚再查原因不要继续叠加新的参数变更否则以后出问题完全没有后悔药可吃。6.2 用“对照实验”验证优化效果而不是主观判断验证优化效果最可靠的方法是做“前/后对比”加“小区分组对照”。把站点按配置版本分成两组一组用新参数实验组一组保持原参数对照组然后对比同一时间段内两组的接入失败率变化。这种做法的好处是能排除掉环境因素比如天气、干扰源变化对判断的干扰。如果实验组改善了但对照组也改善了那说明是环境在变好不是你的参数在起作用如果实验组提升了对照组不变那才是参数的真实收益。这个逻辑在现网优化里非常重要因为无线环境永远在变没有对照实验你就分不清运营效果和运气成分。在爱立信网管上操作时可以通过小区级参数模板实现分组下发比如将某个参数模板应用到一组小区另一组保持默认然后在PM统计里按模板维度聚合对比。对比指标的窗口建议取“调整前一周”和“调整后一周”的同期数据比如都是工作日的上午9点到11点这样可对比性更强。整个分析周期下来再将验证有效的参数逐步推广到全网推广时仍然保持分批进行的节奏避免一次性全网变更引发突发问题。这套闭环流程走下来每次参数优化的结论都是可追溯的项目交付时的报告也有底气写清楚“每个参数调整带来了多少收益”。最后说一个这些年养成的习惯每次做接入性能优化先建一张参数修改登记表把时间、修改的参数、修改理由、修改前基线、修改后观测值、是否回滚都记下来。不带登记表的优化就是凭感觉开车出了问题查无可查。经过几次踩坑之后我都要求自己严格按这个表格来别急着证明自己能行先把过程做扎实。希望帮到你。本文还有配套的精品资源点击获取