简介《SDCU NSA移动性能分析优化指导书》面向5G网络优化工程师与移动性能分析人员聚焦NSA非独立组网场景下的切换与移动性优化问题。文档由爱立信专家Cassie Song编制系统梳理3GPP NSA切换信令流程与爱立信实现机制并深入讲解切换KPI定义、NR侧counters打点机制、锚点关系与NR邻区关系参数配置以及前台空口信令解析、常见问题解决措施和网管切换性能分析流程帮助读者掌握从信令到参数的完整优化思路。资源为1个PDF文件压缩包约5.07MB内容结构清晰涵盖修订记录、切换信令、指标定义、参数配置、前台分析与网管分析等模块便于按章节查阅。目前已有203人学习适合需要提升NSA切换问题定位与参数调优能力的中高级网优人员参考。1. SDCU NSA移动性能分析优化指导书一份让网优人少走弯路的实战拆解NSA组网下SDCU这个网元在移动性能问题里扮演的角色很多干了几年网优的人其实说不清楚。日常遇到的现象是用户投诉5G信号满格但网速上不去后台看gNB侧指标正常核心网侧也没告警问题就卡在SDCU这一层——它既管用户面数据转发又涉及切换过程中的路径更新一旦参数配置和实际无线环境不匹配掉线、速率掉坑、切换失败就全来了。这份指导书要解决的核心问题就一个把SDCU相关的移动性能问题从“玄学”变成可量化、可复现、可优化的工程流程。适合已经接触过NSA基础架构、能看懂信令流程但面对SDCU性能劣化时缺乏系统排查思路的中高级网优工程师也适合需要建立SDCU维度KPI监控体系的运维人员。接下来按“先搞清楚SDCU在NSA里到底管什么、再动手采集和分析、最后落到参数调整和验证”的顺序展开每一步都给到能直接抄的配置和命令。2. SDCU在NSA架构里的真实角色从协议栈到性能瓶颈点2.1 SDCU拆分后用户面和控制面各走了哪条路NSA架构下SDCU的本质是把gNB的CU和DU功能做了分离CU负责RRC、SDAP和PDCP层DU负责RLC、MAC和PHY高层。SDCU这个叫法在不同设备商实现里有细微差异但核心逻辑一致它承载了PDCP实体用户面数据从核心网UPF下来后经过SDCU的PDCP层再做加密和头压缩然后通过F1接口送到DU侧。控制面信令走SDCU的RRC层切换命令的生成和路径更新都绕不开它。这个拆分带来的直接后果是以前gNB内部一个板卡搞定的事现在跨了两个网元。F1接口的传输时延、SDCU的PDCP处理能力、CU和DU之间的流控参数任何一个环节出问题都会在移动性能上放大。常见表现是切换准备阶段SDCU侧RRC重配消息下发延迟导致切换成功率下降或者PDCP的丢弃定时器设得太短高速移动场景下乱序包被提前丢弃用户感知就是视频卡顿。2.2 移动性能问题在SDCU侧的四类典型表征从实操角度看SDCU相关的移动性能劣化基本落在四个维度第一类是切换类包括切换成功率、切换时延、乒乓切换比例。SDCU侧要关注的是RRC重配下发到收到重配完成之间的时间差以及切换准备阶段目标小区资源预留是否及时。第二类是掉线类核心看SDCU发起的UE Context Release原因值分布。如果大量释放原因是“Radio Connection With UE Lost”说明空口已经失步但SDCU还在等这时候要查T310定时器和N310计数器。第三类是速率类表现为PDCP层吞吐量远低于PHY层调度速率。SDCU侧要查PDCP SDU丢弃计数、头压缩效率、以及F1接口用户面GTP-U隧道的丢包率。第四类是时延类用户面单向时延在SDCU PDCP层排队时间过长。需要看SDCU的PDCP重排序定时器配置和F1接口的QoS映射是否合理。这四类问题不是孤立的切换失败往往伴随掉线和速率掉坑排查时要按信令流程顺序逐段定位。2.3 一份可复用的SDCU性能数据采集清单动手分析之前先把数据采全。以下是我在实际项目里固定会拉的几组数据缺一项后面分析就容易断链数据类别具体内容采集方式采集周期信令面RRC重配、UE Context Release、Path Switch RequestSDCU侧信令跟踪按问题时段用户面PDCP SDU丢弃数、PDCP PDU吞吐量、F1 GTP-U丢包SDCU性能计数器15分钟粒度资源面SDCU CPU利用率、PDCP实体数、F1接口带宽网管性能查询5分钟粒度无线侧切换成功率、RRC连接建立成功率、掉线率DU侧MR数据15分钟粒度参数面T310/N310/N311、PDCP丢弃定时器、F1流控门限参数核查脚本按需采集时注意时间同步SDCU和DU的时钟偏差超过500ms就会导致信令关联错误。我一般会在采集前先跑一遍NTP状态检查确认偏差在可接受范围内再开始。3. 用信令跟踪定位SDCU切换类问题的完整操作流程3.1 开启SDCU侧信令跟踪的最小命令集不同设备商的命令有差异但逻辑一致。以下以常见Linux平台网元为例给出通用操作框架# 进入SDCU信令跟踪模块 sdcu_cli --mode trace --interface f1c # 设置跟踪过滤条件按UE的临时标识过滤 trace filter set ue-id-typegNB-CU-UE-F1AP-ID ue-id-value12345 # 开启RRC和F1AP信令同时跟踪 trace start --protocol rrc,f1ap --direction both # 设置跟踪持续时间避免长时间占用资源 trace duration set 300 # 导出跟踪结果到指定目录 trace export --format pcap --output /tmp/sdcu_trace_ue12345.pcap这段命令的核心逻辑是先锁定单个UE的F1AP标识避免全量跟踪导致数据量爆炸然后同时抓RRC和F1AP两个协议层因为切换问题往往需要交叉看RRC重配和F1AP的UE Context Modification最后设置300秒超时防止忘记关闭跟踪影响网元性能。参数说明ue-id-value必须从DU侧或核心网侧先查到不能随便填。--direction both表示上下行都抓如果只关心下行切换命令可以改成--direction dl减少数据量。导出格式选pcap是为了后面用Wireshark做关联分析。3.2 从信令流里识别切换失败的三个关键节点拿到跟踪文件后用Wireshark打开过滤表达式用f1ap || rrc。重点看三个节点节点一RRC Reconfiguration下发时间戳。如果这个时间戳和DU侧收到的切换请求时间差超过50ms说明SDCU内部处理有排队。节点二UE Context Modification Request/Response的往返时延。正常应该在10ms以内超过30ms就要查F1接口传输质量。节点三Path Switch Request的触发时机。如果UE已经接入目标小区但Path Switch还没发说明SDCU的路径更新逻辑有延迟会导致用户面数据短暂中断。我一般会在Wireshark里加一列自定义时间差frame.time_delta_displayed然后按这个列排序快速找出耗时最长的信令交互。3.3 切换参数与SDCU处理能力的匹配原则切换类问题调参不能只看无线侧SDCU的处理能力是硬约束。以下三个参数必须联动调整T310定时器这个定时器在SDCU侧启动等待UE的RRC重建立。设得太短UE还没来得及重建立就超时释放设得太长SDCU资源被无效占用。经验值低速场景1000ms高速场景2000ms但前提是SDCU的CPU利用率低于70%。PDCP丢弃定时器控制PDCP SDU在缓冲区等待重排序的最长时间。NSA场景下建议设150ms如果F1接口时延抖动大可以放宽到200ms但会牺牲部分时延敏感业务体验。F1接口流控门限SDCU向DU发送数据的速率门限。这个值要参考F1接口的实际带宽和DU侧缓存深度。我一般会先跑一周的F1接口带宽利用率基线然后按峰值的80%设门限。调整顺序建议先调T310观察一周切换成功率变化再调PDCP丢弃定时器看用户面时延和丢包最后动F1流控因为影响面最大。4. 速率类问题的PDCP层排查从计数器到参数调优4.1 PDCP吞吐量计数器解读与异常判定SDCU的PDCP层性能计数器是速率问题的第一手证据。重点看这几个pdcp_sdu_discard_totalPDCP SDU丢弃总数。如果这个值持续增长说明重排序定时器太短或者空口乱序严重。pdcp_pdu_tx_throughputPDCP PDU发送吞吐量。要和PHY层调度速率对比如果只有PHY的60%以下说明SDCU处理有瓶颈。pdcp_reorder_delay_avg平均重排序时延。正常应该在20ms以内超过50ms用户感知就明显了。查询命令示例# 查询SDCU PDCP层性能计数器 sdcu_perf query --module pdcp --counter sdu_discard,pdu_tx_throughput,reorder_delay --granularity 15min --start 2025-01-01 00:00 --end 2025-01-01 06:00 # 输出示例CSV格式 # timestamp,pdcp_sdu_discard_total,pdcp_pdu_tx_throughput_mbps,pdcp_reorder_delay_avg_ms # 2025-01-01 00:00,120,450,18 # 2025-01-01 00:15,135,430,22如果pdcp_sdu_discard_total每15分钟增长超过50同时reorder_delay_avg超过30ms基本可以判定是重排序定时器配置偏短。4.2 头压缩参数对SDCU吞吐量的实际影响ROHC头压缩在SDCU的PDCP层实现压缩效率直接影响用户面有效吞吐。NSA场景下常见配置是ROHC profile 0x0001和0x0002。如果配置了不匹配的profile压缩率会大幅下降。检查命令# 查看当前ROHC配置 sdcu_cli --mode config --show rohc # 输出示例 # rohc_profile: 0x0001 # rohc_max_context: 16 # rohc_mrru: 1500rohc_max_context决定同时支持的压缩上下文数每个UE占用一个。如果这个值设得太小新接入的UE无法启用头压缩速率直接掉一截。建议按SDCU最大用户数的1.2倍配置。rohc_mrru是最大重建单元设得太小会导致大包被丢弃。NSA场景建议不低于1500字节。4.3 F1接口用户面丢包与SDCU流控的联动排查F1接口的GTP-U隧道丢包会直接反映为PDCP层重传增加。排查步骤第一步在SDCU侧查F1接口GTP-U统计# 查询F1接口用户面统计 sdcu_perf query --module f1u --counter tx_pkt,rx_pkt,tx_drop,rx_drop --granularity 5min第二步如果tx_drop持续增长检查SDCU的F1接口流控门限是否设得太低。流控门限的调整命令# 调整F1接口用户面流控门限单位Mbps sdcu_cli --mode config --set f1u_flow_control_threshold800第三步如果流控门限已经很高但丢包依旧要查底层传输。用ping测SDCU到DU的时延和丢包# 从SDCU侧ping DU的F1接口地址发1000个包 ping -c 1000 -s 1400 -i 0.01 DU_F1_IP如果时延抖动超过5ms或者丢包率超过0.1%问题在传输网络不在SDCU本身。5. SDCU移动性能优化避坑指南五条血泪经验5.1 坑一T310设得太短导致切换成功率虚降现象切换成功率从99.5%掉到97%但无线侧RSRP和SINR都正常。原因SDCU侧T310定时器设了500msUE在切换过程中短暂失步后还没来得及重建立就超时释放。解决把T310调到1000ms同时观察SDCU CPU利用率。如果CPU超过80%需要先扩容再调定时器否则延长定时器只会加重处理负担。5.2 坑二PDCP丢弃定时器与F1时延不匹配现象用户面时延正常但视频业务卡顿PDCP SDU丢弃计数持续增长。原因PDCP丢弃定时器设了100ms但F1接口实际时延抖动达到80ms导致乱序包在定时器超时后才到达被提前丢弃。解决先用ping测F1接口的时延分布取95分位值加50ms作为丢弃定时器下限。如果F1时延抖动本身过大先解决传输问题再调参数。5.3 坑三ROHC上下文数不足导致新用户速率掉坑现象小区内用户数增加到一定量后新接入用户速率明显低于老用户。原因rohc_max_context设了200但小区实际用户数峰值达到250新用户无法分配压缩上下文。解决按峰值用户数的1.2倍调整rohc_max_context同时监控SDCU内存占用。每个ROHC上下文约占用2KB内存调整前先确认内存余量。5.4 坑四F1流控门限照搬默认值导致吞吐受限现象PHY层调度速率能达到800Mbps但PDCP层吞吐只有400Mbps。原因F1接口流控门限用了设备默认的300Mbps成为瓶颈。解决先跑一周F1接口带宽利用率基线按峰值的80%设门限。调整后观察一周如果tx_drop没有增长且PDCP吞吐提升说明门限合理。5.5 坑五信令跟踪忘记关导致SDCU性能劣化现象开启信令跟踪后SDCU CPU利用率从40%飙升到85%切换成功率下降。原因跟踪命令没有设置自动停止持续跑了几个小时大量信令数据写入磁盘和内存。解决每次开启跟踪必须带trace duration set参数建议不超过300秒。跟踪结束后用trace stop显式关闭并检查/tmp目录下的跟踪文件是否清理。6. 把SDCU性能分析做成可复用的自动化脚本手动查计数器、抓信令、调参数做一两次可以长期运维必须自动化。我现在的做法是写一个Python脚本每天定时拉取SDCU性能数据自动比对基线并输出异常报告。import paramiko import csv from datetime import datetime, timedelta # SDCU网元连接信息 SDCU_IP 192.168.1.100 SDCU_USER perfuser SDCU_PASS ****** # 基线阈值根据历史数据设定 THRESHOLDS { pdcp_sdu_discard_total: 50, # 15分钟增量超过50告警 pdcp_reorder_delay_avg_ms: 30, # 平均重排序时延超过30ms告警 f1u_tx_drop: 10, # F1接口丢包超过10告警 sdcu_cpu_usage: 75 # CPU利用率超过75%告警 } def fetch_sdcu_counters(): 通过SSH登录SDCU执行性能查询命令 ssh paramiko.SSHClient() ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) ssh.connect(SDCU_IP, usernameSDCU_USER, passwordSDCU_PASS) # 查询最近15分钟的性能计数器 cmd sdcu_perf query --module pdcp,f1u,system --granularity 15min --last 1 stdin, stdout, stderr ssh.exec_command(cmd) output stdout.read().decode() ssh.close() return output def parse_and_check(raw_output): 解析输出并比对阈值 alerts [] lines raw_output.strip().split(\n) # 假设输出格式为CSV第一行是表头 reader csv.DictReader(lines) for row in reader: for key, threshold in THRESHOLDS.items(): if key in row: value float(row[key]) if value threshold: alerts.append(f[告警] {key}{value}超过阈值{threshold}) return alerts def main(): raw fetch_sdcu_counters() alerts parse_and_check(raw) if alerts: # 输出告警到日志文件 with open(/var/log/sdcu_perf_alert.log, a) as f: timestamp datetime.now().strftime(%Y-%m-%d %H:%M:%S) for alert in alerts: f.write(f{timestamp} {alert}\n) print(f发现{len(alerts)}条告警已写入日志) else: print(所有指标正常) if __name__ __main__: main()脚本逻辑说明fetch_sdcu_counters通过SSH连到SDCU执行性能查询parse_and_check把输出按CSV解析后逐项比对阈值main负责调度和写日志。阈值THRESHOLDS里的数值需要根据自己网络的基线调整不能直接抄。我一般会先跑两周只记录不告警观察数据分布后再定阈值。参数调整上--granularity 15min和--last 1表示查最近一个15分钟粒度的数据适合做准实时监控。如果要看趋势改成--last 96拉最近24小时的数据。这个脚本部署后SDCU相关的性能问题基本能在15分钟内发现不用等用户投诉再被动响应。我自己的习惯是每周五下午花半小时看一遍告警日志把反复触发的阈值重新校准一次。希望帮到你。本文还有配套的精品资源点击获取