
简介5G NR SA系统内切换优化指导书docx2.9MB是一份面向5G网络优化人员的专题技术文档聚焦SA独立组网模式下系统内同频切换的信令流程、测量事件与参数调整适用于SA宏站、微站的外场切换问题排查与优化。文档围绕A1A5测量事件、多波束下的测量机制、基于覆盖的同频切换流程以及站内、站间XN、站间NG三类切换场景展开系统性拆解从测量控制下发、测量上报、目标小区判决到切换执行完成的全链路信令交互并提供前后台信令分析思路帮助读者理解切换触发逻辑、快速定位失败原因并优化切换参数。包体为单个docx文件压缩后约2.9MB目录结构涵盖切换基本知识、基于覆盖的切换流程、前后台信令解析三大模块便于按章节查阅也可作为日常排障的速查手册。目前已有1690人学习下载适合需要系统掌握NR SA同频切换原理与排障方法的网优工程师参考。1. 5G NR SA系统内切换优化指导书这份文档到底在优化什么我在NSA和SA共模区域接过切换专项。最典型的一幕是同一条城市快速路NSA终端一路不掉线SA终端刚到小区边缘就RLF随后跑到邻区重建VoNR通话中断近半分钟。后台KPI一切正常切换成功率99%以上但“切换过晚”类事件占比明显偏高。5G NR SA系统内切换解决的正是终端在连接态从一个gNB切到另一个gNB、全程不依赖4G锚点的这一跳。优化对象不光是A3/TTT/CIO这几个参数还有测量事件选型、SMTC窗口与测量gap对齐、Xn/N2流程选择这一整条链路。这份指导书对应的落地内容是一套从测量配置、MR数据定位、参数调整到复测验证的闭环方法适合正在做5G基站参数维护和切换专项的网优工程师也适合刚接手SA优化、想把第一轮参数调明白的新人。2. SA系统内切换的机制从测量事件到Xn/N2信令链路系统内切换在SA里不是“闭眼用默认参数”就能做好的事。NR没有CRS测量基于SSB测量节奏、测量对象和切换流程都比LTE多出不少变量。要把这份指导书用起来先理顺切换链路的三件事触发用什么测量事件、测量配置怎么下、切换流程走Xn还是N2。2.1 A3/A4/A5事件怎么选连片覆盖和多频段场景的取舍SA里的所有切换都始于测量报告而测什么、满足什么条件才报由RRC重配置里的measConfig决定具体就是reportConfig里的eventId。现网最常见的三类事件A3是邻区比服务区好一个偏置就上报A4是邻区绝对电平超过一个门限就上报A5是服务区低于门限1、同时邻区高于门限2才上报。写成公式就是A3Mn Ofn Ocn - Hys Ms Ofs Ocs OffA4Mn Ofn Ocn - Hys ThreshA5Ms Ofs Ocs Thresh1且Mn Ofn Ocn - Hys Thresh2其中Mn/Ms是邻区/服务区测量量Ofn/Ofs是频率偏置Ocn/Ocs是小区个体偏置CIOHys是磁滞Off就是A3偏置。这串公式看着抽象实际调参时就两个结论抬高Off或Hys会让切换“更晚、更稳”调Ocn只影响特定邻区方向。事件触发条件典型用途注意点A3邻区优于服务区一个偏置同频连片覆盖下的默认切换事件参数多调错容易乒乓A4邻区超过绝对门限异频层间切换、MLB负荷均衡门限要按目标层实际覆盖定A5服务区差且邻区好覆盖层到容量层的精准切入双门限能省异频无效测量选型上我的经验是同频城区连片覆盖A3是主力简单直接异频层间切换比如700M覆盖层到2.6G或3.5G容量层用A4或A5。A5比A4多了一个“服务区先变差”的前提在服务区信号还很好时不会触发异频上报省测量gap开销也减少终端功耗。负荷均衡MLB场景多半用A4因为它不要求服务区变差纯粹以邻区负载和信号为条件。还有一点值得注意异频层间门限不能拍脑袋我一般取目标层同路段实测SSB覆盖的第20百分位作为A4/A5门限起点再按切换失败率微调。2.2 测量配置下发SSB、SMTC窗口和测量gap的联动关系NR没有CRS小区测量以SSB为主高层可选CSI-RS。gNB在measObjectNR里下发SSB频率、子载波间隔以及measTimingConfig——也就是SMTC窗口。SMTC决定终端“什么时间窗内去找SSB突发”周期可选5、10、20、40、80、160ms窗口长度一般配5ms。同频SA现网SMTC周期大多配20ms让终端测得更勤切换判决更及时终端节电不敏感的场景不用拉长。异频邻区的SMTC周期或偏移如果和服务小区不一致就需要测量gap去“跳出”当前频点抓异频SSB。测量gap是5G协议栈里一个特别容易出问题的点。常见的gap周期有20/40/80/160ms窗口长度1.5ms到6ms。关键不是gap本身配多大而是gap的偏移位置和异频SMTC窗口必须对齐。终端只有在gap打开的那个短窗口里才能去异频频点测量如果gap offset对准了SMTC窗口一个gap周期就能抓到一次SSB突发错开了可能连续好几个周期都测不到然后A3/A4事件怎么都等不来。提示异频邻区信号很强但一直不触发切换优先核对“异频SMTC偏移 测量gap偏移”是否对齐再怀疑门限高低。还有一个容易被忽略的变量是L3滤波系数。它直接影响上报的RSRP平滑程度系数越大曲线越平滑但对真实信号变化的响应越慢。城区慢速场景系数大一点问题不大高速或高架场景系数过大就会把A3上报时机拖后造成切换过晚。排查切换过晚时先看这个系数再看TTT。2.3 Xn切换与N2切换两条路时延差在哪、参数受谁控制SA系统内切换在流程上有两条路。一条是Xn切换源、目标gNB之间的Xn接口直接传UE上下文不经过5GC端到端时延短。另一条是N2切换Xn不可用或跨AMF池时切换准备信令走AMF转发多出两跳时延大约是Xn的1.5到2倍。切换优化上手前我习惯先查一遍区域内Xn链路状态——有些切换“慢”不是参数问题是Xn根本没建全部绕行N2。标准流程七步大部分优化动作都围绕这几步展开源gNB通过RRCReconfiguration下发measConfig配置测量对象和上报事件。UE满足A3/A4/A5后上报MeasurementReport。源gNB切换判决向目标gNB发XnAP HANDOVER REQUEST。目标gNB做准入返回HANDOVER REQUEST ACK其中带reconfigurationWithSync信息。源gNB把RRCReconfiguration转给UEUE在目标小区发起随机接入。UE发RRCReconfigurationComplete给目标gNB。目标gNB完成路径切换通知源gNB释放UE上下文。管这几步的定时器核心是T304和T310/T311。T304是UE在目标小区完成随机接入的定时器超时直接判切换失败T310管源小区的RLF检测源侧信号恶化太慢上报时往往先触发T310 RLF而不是正常切换。在gNB-CU/DU分离架构下这些切换判决都发生在CU-CPDU负责测量量上报和波束层处理。排查时先分清问题是出在CU侧参数还是DU侧测量链路——经常有人在CU-CP调半天门限最后发现是DU的波束配置把SSB调度改了。3. 把切换优化做成闭环参数调整与MR数据定位实操切换优化不是“调一个参数看一个指标”而是一条循环基线配置、MR/路测定位、单参数调整、复测验证、更新基线。下面按这个顺序给出一套可以直接落地的做法。3.1 初始参数表A3偏置、TTT、Hys、CIO怎么配第一轮第一轮优化前先把基线参数拉齐。下面这张表是我在SA现网项目里常用的初始配置和步长不同设备商参数名略有差异按厂家文档对号入座参数常见初始值建议调整步长说明a3Offset2~3 dB±0.5~1 dBA3事件里的Off越大越难触发切换越晚磁滞Hys0.5~1 dB±0.5 dB防测量量抖动造成的反复触发TTTtimeToTrigger160~320 ms按档位调320→160→80事件满足后需持续多久才上报CIO0 dB±0.5~1 dB只作用于指定方向/指定邻区L3滤波系数按厂家默认0~4档每次1档越大越平滑、越滞后第一轮的原则是“稳开局”城区慢速场景用TTT320ms、a3Offset3dB起步MR跑几天再动快速路、高架等中高速场景TTT降到160msa3Offset降到2dB像室外远程驾驶无人车这类5G专网场景车速不一定很高但对中断时延敏感TTT宁可短一点因为切换中断会直接打断控制链路。CIO第一轮一律设0等MR问题簇定位到具体小区对之后再动避免一上来就把参数带偏。3.2 用MRO和切换统计定位问题簇三类切换失败怎么看定位阶段的核心数据是两样MRO测量报告原始数据和切换统计计数器。MRO里记录了每次A3/A4事件上报时的服务区/邻区RSRP、RSRQ和UE位置信息按小区对聚合后能看出问题簇的空间分布。切换统计则给出尝试次数、成功/失败次数和失败原因T304超时、准入拒绝、Xn失败等。从MRO里看三类典型问题切换过晚A3事件触发点的服务区RSRP已经很低比如低于-110dBm且源小区RLF率偏高UE经常在邻区重建。对应参数嫌疑TTT偏大、L3滤波系数偏大、a3Offset偏大。切换过早切换成功后很短时间内目标小区发生RLFUE又切回源小区。对应参数嫌疑TTT偏小、a3Offset偏小、CIO被调成“激进”。乒乓/错切同一终端几秒内A→B→A连续成功切换或切换后短时间内去了第三个小区。这种情况要单独把CIO拿出来查。我一般先用一段小脚本把失败簇和乒乓簇从MR文件里筛出来。MRO文件解出来通常是csv或parquet字段类似下面这样import pandas as pd # 字段说明time测量时间, ue终端标识, src/tgt源/目标小区, # rsrp_src/rsrp_tgt测量电平, result切换结果(success/fail), fail_reason失败原因 df pd.read_csv(mro_a3_report.csv, parse_dates[time]) df df.sort_values([ue, time]).reset_index(dropTrue) # 用前一条记录判断“反向且快速”的切换当前源小区 上一条目标小区间隔5秒 df[prev_tgt] df.groupby(ue)[tgt].shift(1) df[prev_time] df.groupby(ue)[time].shift(1) df[gap_s] (df[time] - df[prev_time]).dt.total_seconds() pingpong df[(df[src] df[prev_tgt]) (df[gap_s] 5) (df[result] success)] # 聚合输出乒乓最严重的前20组小区对 print(pingpong.groupby([src, tgt]).size().sort_values(ascendingFalse).head(20)) # 切换失败簇按源小区-目标小区-失败原因聚合 fail df[df[result] fail] print(fail.groupby([src, tgt, fail_reason]).size() .sort_values(ascendingFalse).head(20))这个脚本的思路是按UE分组、按时间排序用“上一条记录的目标小区等于当前记录的源小区”来识别反向切换再加上5秒窗口过滤出乒乓。真实项目里不能只看这一个条件要叠加两次切换的RSRP差值、是否携带重建立信息一起判断否则会把正常的往返移动误判成乒乓。失败聚类的结果则直接指向“哪个小区对、什么原因失败”下一步的CIO和TTT调整就围绕这些簇展开而不是全网平均调。3.3 一轮优化迭代怎么跑调参步长、验证窗口和回退机制定位到问题簇之后迭代节奏比参数本身更重要。我的做法是一次只动一个维度。第一轮先动TTT或a3OffsetCIO放到第二轮动CIO时只动定位出的那一个小区对不动全网。步长从小的开始。a3Offset每次±0.5~1dBTTT按档位320→160→80CIO每次±1dB。一次调3dB以上的都属于冒险翻车概率很大。验证窗口要够长。MR维度看调整后3~7天的均值路测维度至少同路线跑两轮。当天调完当天判断“没效果”是不成立的终端测量、滤波和统计本身有滞后。设定回退条件。切换成功率下降、乒乓率上升、或目标小区负荷短时间内明显抬高都触发回退。回退不是把参数改回去就行而是把这一轮的变更记录完整留档下一轮复盘时能说清“为什么改、为什么退”。提示动参数前先把当前配置导出存档。这个习惯能避免“换了个人就没人记得两年前为什么把TTT设成640ms”的拉扯。4. SA切换优化避坑手册五个高频翻车场景与处置切换专项里翻车最多的不是不会调参数而是没定位对问题类型。下面五个场景是我在SA现网里反复见过的按“现象→原因→解决”梳理照着排查能省不少弯路。4.1 切换过晚UE在边缘RLF后去邻区重连现象高速路测中SA终端到源小区边缘RSRP已低于-110dBm仍不触发A3上报随后RLF在邻区重建VoNR中断十几秒到半分钟。后台看切换成功率仍然很高但源小区RLF率和邻区入向重建次数明显上升。原因A3上报时机被拉得太晚。多数情况是TTT偏大640ms级或L3滤波系数偏大导致上报滞后少数情况是a3Offset设得过高邻区得比服务区好很多才触发。解决先查L3滤波系数再动TTT。滤波系数从4档降到1~2档TTT从320ms降到160ms一次只动一个。如果确认Xn未建立导致切换准备绕行N2先把区域Xn链路补齐再调参数否则时延问题会继续累积。4.2 乒乓切换TTT太短让信令面翻倍现象商圈沿街路段同频两个小区边界一辆车200米内往返切换4次Xn信令面负荷翻倍某次切换因为目标侧信令过载失败。MRO里能筛查出明显的高频反向切换小区对。原因TTT过短小于80ms加上a3Offset过小1dB以下测量量一抖就触发上报如果前一轮还调过双向CIO问题会被放大。解决TTT回到160~320msa3Offset抬到2~3dB然后单独处理乒乓簇。我一般是把频次最高的那对小区单向CIO减1dB让某一边更难反向触发观察一周再决定是否动另一边。4.3 测量gap与SMTC错位异频邻区“测不到”的玄学现象扫频仪在某个异频频点测到很强的SSB后台切换统计里这个邻区却没有一次测量上报切换根本不发起。参数查了几遍都正常看起来像玄学。原因异频邻区需要测量gap才能测量而gap偏移没有对准异频SMTC窗口。终端在gap窗口里等不到SSB突发连续错过多个周期测量永远起不来。另一种常见原因是gap周期设了160ms而SMTC周期5~20ms两者错开导致采样本就稀疏。解决把异频邻区的SMTC周期、偏移拉出来和测量gap的offset对齐。优先把gap周期设在80ms以下窗口长度按异频SSB实际占用时间留余量。这个场景在FR1异频和FR2异频都出现过排查顺序永远是SMTC对齐先于门限调整。4.4 CIO单边调整优化了一个方向反向切换却崩了现象为疏导某高负荷小区把它“入向”的CIO调大吸引切换。负荷确实降了但反向切换成功率掉了2个百分点原本服务良好的用户切不回来在目标小区边缘RLF。原因CIO是按“小区对方向”配置的。只调一个方向的CIO等于让这个方向的A3上报明显提前而反向机制没变结果就是制造了覆盖缺口——切过去的回不来。解决CIO必须成对考虑。调大入向CIO前先看反向切换成功率是否在安全线以上如果要靠CIO做负荷均衡两边CIO同时微调并配合a3Offset整体抬高来避免“提前切”。4.5 共模站点的NSA残留配置SA切换绕道4G现象某个区域的SA终端始终以“重定向/盲切”的方式坠到4G再由4G切回NR整个过程秒级时延业务中断明显。后台查SA系统内切换统计该区域尝试次数为0。原因NSA/SA共模站点的邻区关系库里残留了NSA时代的老PCI邻区NR侧邻区关系不完整或Xn没衔接上。切换判决时找不到合法NR邻区直接走了inter-RAT重定向。这是老站改SA后最容易踩的坑。解决全量核查邻区关系用ANR自动邻区合并清理失效PCI确认Xn链路建立、AMF上的相邻gNB ID配置正确。删除“看似多余”的邻区前先拉该邻区最近一周的MRO触发次数确认它真的没再用避免误删造成新的覆盖空洞。5. 验证与产出切换优化效果怎么量化、报告怎么落优化做完了最大的问题往往是“怎么证明有效”。量化口径不统一之前调的参数到下一轮就会被推翻。这一章给出我常用的验证指标和报告结构。5.1 盯哪几个KPI切换成功率、切换时延、乒乓率的统计口径切换优化不是只看一个成功率。下面是现网常用的一套口径缺一不可KPI定义关注口径切换成功率成功次数 / 尝试次数按小区对看也按Xn、N2分开看切换时延测量报告到RRCReconfigurationComplete看P90/P95别只看均值乒乓率5秒内反向成功切换次数 / 总切换次数按小区对定位不按全网均摊RLF率RLF次数 / 连接次数作为“切换过晚”的结果指标VoNR掉话率VoNR通话中断占通话比例切换专项必查用户感知最直接切换时延这个指标特别提醒一句平均值在优化前后差别不大但P95时延能暴露少数极端切换路径的问题。Xn和N2分开统计不然慢的那条路会被快的平均掉。乒乓率的口径各家可能不同只要报告里写明“同UE 5秒内反向成功切换”这个定义前后对比就是自洽的。5.2 路测对比法同路线同时段的前后复测路测是验证切换优化最直接的手段但对比条件必须苛刻同一条路线、同一个终端型号、同一套软件版本、同一个时段避开早晚高峰。优化前至少跑两轮取基线优化后至少复测两轮每轮在问题点经纬度打点记录切换次数、切换时延和RLF点位置。复测时如果问题点只是从A点挪到了B点那不算解决要重新回到参数定位。路测数据里还有一项容易看漏的终端modem日志里的A3上报时间和gNB下发重配置时间差。这个差值能用来判断“是UE上报慢”还是“gNB判决慢”能把问题从射频侧切到处理侧。实践里我见过RSRP都合格、但gNB侧处理板负荷高导致判决延迟的案例这类问题调参数没用得查基站侧资源。5.3 优化报告的关键板块参数变更清单和前后对比表一份能交接给下一任工程师的优化报告至少要有四个板块参数变更清单小区、参数名、旧值、新值、变更时间、操作人。每一行都要能追溯到当时的问题簇编号。前后对比表按小区对列出切换成功率、时延P90、乒乓率、RLF率的before/after。问题点闭环表每个问题点的经纬度、问题类型、处理动作、复测状态。遗留问题哪些簇还没处理下一轮优先做什么为什么暂缓。报告里的每个“调整了A3偏置”都需要配一句“因为某簇切换失败定位到过晚所以减了a3Offset”的逻辑链。没有逻辑链的参数变更到下一轮就是纯噪音。6. 往纵深走波束级切换与切片场景下的进阶调优基础参数调顺之后SA切换还有两个值得深挖的方向。6.1 FR2波束级移动性把参数从小区粒度下沉到波束粒度FR2高频场景的SSB是波束轮发的同一小区不同SSB index对应不同覆盖方向。现网FR2切换表面上还是小区级事件触发但测量样本是波束级的。调TTT和CIO之前要先看UE测到的是哪个SSB index、各波束RSRP分布是否正常。常见问题是某个波束方向弱导致该方向上所有UE的A3上报都滞后——这在小区平均指标上看不出来。排查时要打开波束级测量统计确认弱波束是真覆盖空洞还是SSB调度周期拉得太长导致测量样本不足。FR2下还会遇到beam failure恢复和切换并发的情况优先保证beam failure instance的快速响应不要让UE等到RLF才动。6.2 切片场景的差异化切换参数同一张网两套逻辑SA网络切片商用后同一张gNB上的不同切片对切换要求完全不同。URLLC类切片工业控制、远程驾驶无人车这类对切换中断时延极其敏感TTT不能按默认值走需要为该切片单独配更激进的A3参数和更短的T304eMBB切片则继续保留防乒乓的大TTT。好在CU-CP的切换判决是按UE粒度下行的可以为不同S-NSSAI下发不同的测量配置和定时器集合。调参时注意切片参数的变更要同步到AMF侧准入策略否则目标小区接纳判断和源小区判决逻辑会打架。6.3 从手动调参到MR驱动的自动巡检切换参数不会一劳永逸。城区天面变化、邻区负荷波动、RF优化调整都会让基线漂移。我现在的习惯是每月跑一次MR健壮性分析用类似3.2节的脚本把全网切换失败簇、乒乓簇、过晚/过早事件自动统计出来超过阈值就进下一轮人工判断。如果有实验室条件旁路用OAI这类开源5G协议栈复现某个信令异常行为能帮助确认是参数问题还是协议栈实现问题——但现网调参的基准永远来自现网MR和路测开源栈只做行为验证不做参数基准。做切换优化这几年我给自己定了一条规矩改任何参数前先把当前配置导出存档变更理由写进报告不写“感觉应该这样”。因为参数表会说话——三个月后回看一行变更记录能不能讲清当时为什么这么改决定了这个专项是越做越明白还是越调越乱。希望帮到你。本文还有配套的精品资源点击获取