尧图网站建设 
简介面向5G网络优化工程师与通信从业者的信令流程详解PPT聚焦NSA组网下从4G到5G接入、测量、辅小区添加及切换等核心信令环节。资源以单份PPTX呈现大小仅1.54MB内容涵盖2.6GHz频段60M/100M小区SSB对齐与GSCN配置、SIB1/SIB2系统消息解读PLMN选择、ENDC指示、UE双连接能力识别Band3N41/N77/N78/N79组合、B1/A2/A3事件测量控制并详解辅小区添加失败引发的RRC重建如RLC模式不一致、256QAM支持、SRS端口轮发、线性功率超限等根因同时结合SS-RSRP评估服务质量。附带NSA状态下NR满足A2删腿、带SN的MN切换、SN变更等关键信令流程。已有419人学习下载适合需要深入理解空口信令交互、快速定位接入与切换问题的初级至中级优化人员可作为日常排障、参数调优与网优培训的实用参考。1. 为什么 5G 网优要先把信令流程啃透现场做了两轮簇优化RRC 建立成功率已经到 99% 以上但用户投诉还是集中在“视频卡顿、语音接不通、切小区掉线”。指标面板看不到原因把 UE 和基站之间的交互过程放出来才看得见是随机接入冲突是 RRC 重建还是切换目标侧接入超时是 NGAP 上下文建立慢还是 QoS flow 没有把语音承载映射到对应 5QI。5G 网络优化信令流程详解这件事讲的不只是消息名是把 RRC、NAS、NGAP 各层消息串成一条完整时间线再跟参数和计数器挂钩。适合 RAN 优化工程师、核心网运维和搞 VoNR 排障的人看。下面按“分层理解 — 逐流程拆解 — 故障定位 — 沉淀基线”四步展开。2. 5G 网络优化信令流程的分层结构从 RRC 到 NGAP 的消息地图2.1 信令看哪里空口与地面接口的分工网优人员手里的信令跟踪来源通常有两类路测前台软件导出的 L3 空口消息以及基站的 NGAP/Xn 接口跟踪。空口侧核心是 RRC 和 NASRRC 管连接建立、重配、释放NAS 管注册、鉴权、业务请求。5G 和前几代最大的差异是多了 RRC_INACTIVE 状态UE 从 INACTIVE 恢复连接时走的是 RRCResume 流程而不是完整的 RRCSetup这个状态设计直接影响寻呼量和接入时延。地面接口侧主要是 NG 口gNB 到 AMF和 Xn 口gNB 到 gNB。NG 口上跑 NGAP负责 UE 上下文管理、PDU Session 资源管理、寻呼、切换信令。Xn 口上跑 XnAP负责基站间切换和小区激活。优化时常常把 RRC 消息和 NGAP 消息放在同一时间轴上看因为端到端业务时延往往不是空口慢而是 N2 口上 AMF 往回下发 InitialContextSetupRequest 的动作迟了。从信令层看一个“流程”可以很窄比如只看 RRC 建立也可以很宽比如把注册、鉴权、Default QoS Flow 建立、PDU Session 更新全部串起来。5G 网络优化信令流程的读法建议从“状态 接口 消息”三个维度同时展开否则看到的只是一堆 16 进制载荷。2.2 重点接口与消息抓手下表是日常优化中最常看的信令对象列出的消息每条都有明确网络优化动作可以对应。接口协议典型消息优化时盯什么常见故障落点NR-UuRRC/NASRRCSetupRequest、RRCSetupComplete、RRCResumeRequest、 RRCReconfigurationRRC 建立时延、重配成功次数、释放原因接入禁止、定时器超时NGNGAPInitialContextSetupRequest、UEContextReleaseRequest、PDUSessionResourceSetupRequest上下文建立时延、PDU Session 建立成功率、释放原因AMF 未响应、切片不匹配XnXnAPHandoverPreparation、HandoverSuccess、UEContextRelease切换时延、失败原因、过早/过晚切换T304 超时、邻区漏配N2/NASNAS 5GSRegistrationRequest、ServiceRequest、PDUSessionEstablishmentRequest注册成功率、业务请求成功率核心网配置错误、TA 更新失败读信令时先分主从。RRC 流程的判断标准是 UE 到了哪个 RRC 状态NGAP 流程的判断标准是 UE 上下文在 AMF 和 gNB 上是否被正确建立、修改和释放。两边的消息描述同一个 UE却可能由不同网元打点时间戳同步是前提。2.3 用 tshark 把抓包文件切成可读的流程片段现网没有图形化跟踪工具时用 Wireshark 的命令行版 tshark 过滤 NGAP 消息是最直接的读法。假设手里有一份基站侧镜像口抓包5g_sig.pcapng先看里面到底有哪些流程tshark -r 5g_sig.pcapng -Y ngap -T fields \ -e frame.number \ -e frame.time_relative \ -e ngap.procedureCode \ -e ngap.criticality \ -e ngap.value 2/dev/null | head -30这段命令的意思是-Y ngap按显示过滤器只留 NGAP 消息-T fields指定输出字段frame.time_relative给出相对抓包起点的秒数方便计算两条消息间的时间差ngap.procedureCode对应 TS 38.413 里定义的流程编号比如 InitialContextSetup 是 10UEContextRelease 是 26HandoverPreparation 是 15。ngap.criticality能看到该消息对错误处理的等级。如果只看某一次 UE 的注册流程可以按 IMSI 或临时标识过滤。5G 核心网接口消息里通常有 UE NGAP ID可以写更精确的条件tshark -r 5g_sig.pcapng -Y ngap.procedureCode 1 nas_5gs message type 65 \ -T fields -e frame.time_relative -e ngap.ngap_IE_UL_UE_NGAP_ID \ -e nas_5gs.message_type5G NAS 消息类型中65 代表 Registration request66 是 Registration accept。把过滤条件、时间戳、临时标识打印出来后就能和前台路测的空口消息一一对上。这里要留意不同 Wireshark 版本的 NGAP 字段名略有差异老版本可能叫ngap.ProcedureCode大小写不同写脚本前先用tshark -G fields | grep ngap确认当前环境的字段名。3. 从接入到上下文建立拆解 5G 信令流程的参数挂钩3.1 随机接入阶段preamble 格式先决定时延上限5G 网络优化信令流程里的第一步往往是 UE 在目标小区发起随机接入。NR 的 preamble 序列分长格式和短格式长格式覆盖好、抗噪声强但占用时隙多短格式时延低适合高频段和中近点用户。按 3GPP TS 38.211长格式有 4 种format 0 到 3短格式有 9 种A1、A2、A3、B1、B2、B3、B4、C0、C2。优化人员不用全记但要会从基站配置里看到底配了哪种。格式类型前导码长度典型场景优化影响长格式 0-3较长占用多符号低频广覆盖、远点用户覆盖增加但接入时延变大短格式 A/B/C较短单时隙可完成中近点、高频、URLLC时延低对 SINR 敏感度高如果发现某小区远点用户随机接入失败率偏高优先查prach-ConfigurationIndex和preambleReceivedTargetPower是否匹配上行覆盖半径。错误的 configurationIndex 会让 preamble 落在错误的有效时间窗口内基站收不到UE 反复增大发射功率表现就是 RSSI 高但接入失败。3.2 RRC 建立与 NAS 服务请求流程拆解RRC 连接建立是 5G 信令流程里最常被考核的指标。标准流程是UE 发RRCSetupRequest基站回RRCSetupUE 回RRCSetupComplete。建立完成后如果 UE 此前没有注册会在空口上继续发 NAS 层的RegistrationRequest如果只是从空闲态恢复业务发的是ServiceRequest。基站端把 NAS 消息封装在InitialUEMessage里通过 NG 口送给 AMFAMF 回复DownlinkNASTransport再触发上下文建立。从网络优化角度这里的核心 KPI 不是单条消息的成功率而是RRCSetupRequest → RRCSetupComplete的时延分布。建议按 P50、P95、P99 统计而不是只看平均。平均时延容易被大量近点快业务拉低P95 才是用户真实感知。# 假设前台导出的 L3 消息为每行一条字段为 # 时间戳|消息类型|小区ID|IMSI|结果 awk -F| $2RRCSetupRequest {begin[$3 FS $4]$1} $2RRCSetupComplete begin[$3 FS $4]! {split($1,a,.); split(begin[$3 FS $4],b,.); print $3,$4,a[1]-b[1]} l3_dump.txt这段 awk 按“小区 ID IMSI”做关联把同一 UE 的 RRCSetupRequest 和 RRCSetupComplete 配对输出建立时延。FS设为竖线分隔split处理秒和毫秒输出结果可以直接导入 Excel 做百分位统计。要特别注意原始日志的时间格式必须统一否则会出现负数。3.3 NGAP 初始上下文建立和 QoS 流绑定RRC 建立只是“拉通了通道”真正让业务可用的是 NGAP 侧的 InitialContextSetup 流程。AMF 收到 ServiceRequest 后会向 gNB 下发 InitialContextSetupRequest里面带上要建立的 PDU Session、S-NSSAI、QoS flow 与 QFI 的映射。gNB 再把 QoS flow 映射到 DRB 上通过 RRCReconfiguration 配置给 UE。这段信令流程里最容易出现的问题有三个一是 UE 请求的网络切片和 AMF 允许的切片不匹配导致 PDU Session 建立被拒绝二是 QFI 分配冲突两个业务流用了同一个 QFI三是核心网侧 5QI 参数与无线侧配置不对齐例如语音用了 5QI1但 gNB 侧 RB 配置里没有对应的保证速率参数。下面这个 Python 脚本可以从 NGAP 跟踪文本中提取 QFI 和 5QI 组合# parse_qos_from_trace.py # 输入基站导出的 NGAP 文本跟踪按行包含 qosFlowIdentifier 和 fiveQI import re from collections import defaultdict qos_map defaultdict(set) pattern re.compile( rngap\.qosFlowIdentifier(\d).*?ngap\.fiveQI(\d) ) with open(ngap_trace.txt, encodingutf-8) as f: for line in f: m pattern.search(line) if m: qos_map[int(m.group(2))].add(int(m.group(1))) for t, qfis in qos_map.items(): print(f5QI{t}: QFI{sorted(qfis)})代码思路是正则匹配每条 NGAP 消息里的 QFI 和 5QI聚合后输出当前网元实际用到的 QoS 流组合。5QI 相同时 QFI 不应重复重复就说明配置下发阶段已经出错。脚本只做文本扫描不依赖额外第三方库适合在堡垒机上直接运行。3.4 关键定时器参数T300、T302、T304 的作用域定时器是信令流程和现网参数之间的桥。T300 是 UE 发出 RRCSetupRequest 后等待 RRCSetup 的时长超时则 UE 认为接入失败T302 控制被拒绝后的退避时间T304 则用在切换流程中UE 收到带同步的 RRCReconfiguration 后等待目标小区随机接入成功的最大时间。3GPP 为每个定时器定义了取值范围但现网取值直接决定用户的失败耐心。定时器流程位置超时后果常见初始值T300RRCSetupRequest → RRCSetupUE 重建或直接回到空闲态1000 msT302RRCSetup 被拒绝后UE 延后再次接入可配为 160~3000 msT304切换后随机接入切换失败UE 回到源小区1000~2000 msT304 调大并不总是好事。现网切换失败定位时如果目标小区空口质量差但信号不弱T304 调大只是让用户多等一会儿最终失败了感知更差。常见做法是先看切换准备阶段的目标小区是否来得及完成资源授权再看 preamble 是否碰撞最后才动 T304。调整后至少观察一个高话务时段的切换失败原因统计。4. 5G 网络优化中的信令故障率VoNR 与切换、寻呼的现网处置4.1 VoNR 信令流程里的 QoS 承载检查VoNR 是 5G 网络优化信令流程里最典型的跨层流程涉及 RRC、NAS、NGAP、PFCP、HTTP/2 多个环节。语音业务建立时IMS 域要求网络提供 5QI1 的 GBR 承载和 5QI5 的 SIP 信令承载。在无线侧这个流程表现为 UE 先做普通数据业务接入然后基站收到核心网下发的 Additional QoS Flow 信令发起 RRCReconfiguration在同一个 DRB 或新 DRB 上添加语音承载。排查 VoNR 失败先看两处信令一是 InitialContextSetupRequest 或 PDUSessionResourceModifyRequest 里是否出现 5QI1 的 QoS Flow二是 RRCReconfiguration 的 QoS flow 到 DRB 映射表是否符合预期。很多“呼得通但听不清”的现场信令流程完整但 5QI1 的 GBR 流被基站安排到了 DRB 而不是专有数据无线承载调度时仍按非 GBR 处理就会导致语音包排队延迟。前台 L3 日志里可以直接查看 RRCReconfiguration 中每个 DRB 的logicalChannelConfig重点看优先级和 PBR 设置是否和 5QI1 推荐的优先级一致。4.2 切换信令流程定位与 T304 定时器整定Xn 切换流程可以浓缩成五条关键消息源站下发测量控制UE 上报 MeasurementReport源站通过 Xn 口发送 HandoverRequest目标站返回 HandoverRequestAcknowledge源站再向 UE 发 RRCReconfiguration。UE 在目标小区完成随机接入后返回 RRCReconfigurationComplete目标站发一条 HandoverSuccess 给源站源站随后释放 UE 上下文。5G 网格优化遇到切换失败时先把信令文件里的 T304 相关消息按 UE 维度筛选出来。下面是 tshark 过滤切换准备和失败消息的命令tshark -r xn_trace.pcapng -Y xnapp -T fields \ -e frame.time_relative \ -e ip.src \ -e ip.dst \ -e xnapp.initiatingMessage \ -e xnapp.successfulOutcome \ -e xnapp.unsuccessfulOutcome 2/dev/null | grep -i handover字段加粗的目的不是直接看到“失败原因”而是把 HandoverPreparation 和 HandoverSuccess/HandoverFailure 的配对起来。取出时间差后如果失败发生在目标站准备之前问题大概率在邻区关系或者目标站资源如果失败消息在 HandoverRequestAcknowledge 之后出现才去看 T304 和物理随机接入。5G 邻区添加案例里最常见的就是漏配同频邻区UE 测量到了一个未配置邻区的小区却无法切换信令里会反复出现 “event A3 triggered” 但目标小区不存在。4.3 用批量命令把信令日志聚合成全网排障报表现场日志成百上千条时逐条看信令不现实。我的习惯是先用 awk 或数据库做个粗聚类把失败集中在哪几个小区、哪段时间看清楚再回头细看信令流程。下面这段命令可以统计每个小区 RRC 建立失败次数awk -F| $2RRCSetupRequest {req[$3]} $2RRCSetupComplete {cmp[$3]} $2RRCSetupFailure {fail[$3]} END { for (cell in req) printf %s 尝试%d 成功%d 失败%d\n, \ cell, req[cell], cmp[cell]0, fail[cell]0 } 5g_sig_dump.txt | sort -k4 -nr | head -20这里假设输入文件是用|分隔的 L3 消息日志第二列是消息名第三列是小区 ID。END块在文件读完时统一输出sort -k4 -nr按失败次数降序排列把最差的小区排在最上面。失败次数高但拥塞指标正常的小区需要抓单用户信令逐条看拥塞指标也高的小区则先查上行干扰和准入参数。5. 把信令流程分析沉淀成可复用的优化基线信令流程分析不能每次都在现场临时抓包我一般会在每个地市项目开始时用两周存量数据做一份“5G 信令流程基线”。基线内容是一张表记录关键流程的正常时延范围、失败率阈值和典型失败原因。比如 RRCSetupRequest 到 RRCSetupComplete 的 P95 应低于 150 msNGAP InitialContextSetup 的时延参考值在 80 ms 以内T304 的切换成功率目标大于 99%。这个基线不是拍脑袋而是从历史信令日志百分位里算出来的。基线建好后后续每一次排障都可以用同样命令重新计算再和基线对比。例如查看某个时段 NGAP InitialContextSetup 的时延分布tshark -r ng_trace.pcapng -Y ngap.procedureCode 10 \ -T fields -e frame.time_relative \ -e ngap.ngap_IE_UL_UE_NGAP_ID ic_setup_time.txt然后分两步处理第一步按 UE NGAP ID 去重把同样 ID 的最后一条消息时间减去第一条消息时间得到每个用户的上下文建立时间第二步用sort -n和awk计算 P50/P95/P99。基线更新周期建议跟随版本升级和参数调整每次大规模邻区优化后也要重算一遍否则新基线和旧基线混在一起阈值就失去意义。最后再提醒一个容易忽略的技巧信令流程分析完以后要把关键流程的消息树保存成模板。下次只需要把抓包文件路径和小区 ID 换掉过滤语法、字段输出、时间差计算一点不用改。这个模板就是团队里最值钱的知识资产远比截图和聊天记录可靠。本文还有配套的精品资源点击获取 5G网络优化信令流程详解：从RRC到NGAP的排障实践
简介面向5G网络优化工程师与通信从业者的信令流程详解PPT聚焦NSA组网下从4G到5G接入、测量、辅小区添加及切换等核心信令环节。资源以单份PPTX呈现大小仅1.54MB内容涵盖2.6GHz频段60M/100M小区SSB对齐与GSCN配置、SIB1/SIB2系统消息解读PLMN选择、ENDC指示、UE双连接能力识别Band3N41/N77/N78/N79组合、B1/A2/A3事件测量控制并详解辅小区添加失败引发的RRC重建如RLC模式不一致、256QAM支持、SRS端口轮发、线性功率超限等根因同时结合SS-RSRP评估服务质量。附带NSA状态下NR满足A2删腿、带SN的MN切换、SN变更等关键信令流程。已有419人学习下载适合需要深入理解空口信令交互、快速定位接入与切换问题的初级至中级优化人员可作为日常排障、参数调优与网优培训的实用参考。1. 为什么 5G 网优要先把信令流程啃透现场做了两轮簇优化RRC 建立成功率已经到 99% 以上但用户投诉还是集中在“视频卡顿、语音接不通、切小区掉线”。指标面板看不到原因把 UE 和基站之间的交互过程放出来才看得见是随机接入冲突是 RRC 重建还是切换目标侧接入超时是 NGAP 上下文建立慢还是 QoS flow 没有把语音承载映射到对应 5QI。5G 网络优化信令流程详解这件事讲的不只是消息名是把 RRC、NAS、NGAP 各层消息串成一条完整时间线再跟参数和计数器挂钩。适合 RAN 优化工程师、核心网运维和搞 VoNR 排障的人看。下面按“分层理解 — 逐流程拆解 — 故障定位 — 沉淀基线”四步展开。2. 5G 网络优化信令流程的分层结构从 RRC 到 NGAP 的消息地图2.1 信令看哪里空口与地面接口的分工网优人员手里的信令跟踪来源通常有两类路测前台软件导出的 L3 空口消息以及基站的 NGAP/Xn 接口跟踪。空口侧核心是 RRC 和 NASRRC 管连接建立、重配、释放NAS 管注册、鉴权、业务请求。5G 和前几代最大的差异是多了 RRC_INACTIVE 状态UE 从 INACTIVE 恢复连接时走的是 RRCResume 流程而不是完整的 RRCSetup这个状态设计直接影响寻呼量和接入时延。地面接口侧主要是 NG 口gNB 到 AMF和 Xn 口gNB 到 gNB。NG 口上跑 NGAP负责 UE 上下文管理、PDU Session 资源管理、寻呼、切换信令。Xn 口上跑 XnAP负责基站间切换和小区激活。优化时常常把 RRC 消息和 NGAP 消息放在同一时间轴上看因为端到端业务时延往往不是空口慢而是 N2 口上 AMF 往回下发 InitialContextSetupRequest 的动作迟了。从信令层看一个“流程”可以很窄比如只看 RRC 建立也可以很宽比如把注册、鉴权、Default QoS Flow 建立、PDU Session 更新全部串起来。5G 网络优化信令流程的读法建议从“状态 接口 消息”三个维度同时展开否则看到的只是一堆 16 进制载荷。2.2 重点接口与消息抓手下表是日常优化中最常看的信令对象列出的消息每条都有明确网络优化动作可以对应。接口协议典型消息优化时盯什么常见故障落点NR-UuRRC/NASRRCSetupRequest、RRCSetupComplete、RRCResumeRequest、 RRCReconfigurationRRC 建立时延、重配成功次数、释放原因接入禁止、定时器超时NGNGAPInitialContextSetupRequest、UEContextReleaseRequest、PDUSessionResourceSetupRequest上下文建立时延、PDU Session 建立成功率、释放原因AMF 未响应、切片不匹配XnXnAPHandoverPreparation、HandoverSuccess、UEContextRelease切换时延、失败原因、过早/过晚切换T304 超时、邻区漏配N2/NASNAS 5GSRegistrationRequest、ServiceRequest、PDUSessionEstablishmentRequest注册成功率、业务请求成功率核心网配置错误、TA 更新失败读信令时先分主从。RRC 流程的判断标准是 UE 到了哪个 RRC 状态NGAP 流程的判断标准是 UE 上下文在 AMF 和 gNB 上是否被正确建立、修改和释放。两边的消息描述同一个 UE却可能由不同网元打点时间戳同步是前提。2.3 用 tshark 把抓包文件切成可读的流程片段现网没有图形化跟踪工具时用 Wireshark 的命令行版 tshark 过滤 NGAP 消息是最直接的读法。假设手里有一份基站侧镜像口抓包5g_sig.pcapng先看里面到底有哪些流程tshark -r 5g_sig.pcapng -Y ngap -T fields \ -e frame.number \ -e frame.time_relative \ -e ngap.procedureCode \ -e ngap.criticality \ -e ngap.value 2/dev/null | head -30这段命令的意思是-Y ngap按显示过滤器只留 NGAP 消息-T fields指定输出字段frame.time_relative给出相对抓包起点的秒数方便计算两条消息间的时间差ngap.procedureCode对应 TS 38.413 里定义的流程编号比如 InitialContextSetup 是 10UEContextRelease 是 26HandoverPreparation 是 15。ngap.criticality能看到该消息对错误处理的等级。如果只看某一次 UE 的注册流程可以按 IMSI 或临时标识过滤。5G 核心网接口消息里通常有 UE NGAP ID可以写更精确的条件tshark -r 5g_sig.pcapng -Y ngap.procedureCode 1 nas_5gs message type 65 \ -T fields -e frame.time_relative -e ngap.ngap_IE_UL_UE_NGAP_ID \ -e nas_5gs.message_type5G NAS 消息类型中65 代表 Registration request66 是 Registration accept。把过滤条件、时间戳、临时标识打印出来后就能和前台路测的空口消息一一对上。这里要留意不同 Wireshark 版本的 NGAP 字段名略有差异老版本可能叫ngap.ProcedureCode大小写不同写脚本前先用tshark -G fields | grep ngap确认当前环境的字段名。3. 从接入到上下文建立拆解 5G 信令流程的参数挂钩3.1 随机接入阶段preamble 格式先决定时延上限5G 网络优化信令流程里的第一步往往是 UE 在目标小区发起随机接入。NR 的 preamble 序列分长格式和短格式长格式覆盖好、抗噪声强但占用时隙多短格式时延低适合高频段和中近点用户。按 3GPP TS 38.211长格式有 4 种format 0 到 3短格式有 9 种A1、A2、A3、B1、B2、B3、B4、C0、C2。优化人员不用全记但要会从基站配置里看到底配了哪种。格式类型前导码长度典型场景优化影响长格式 0-3较长占用多符号低频广覆盖、远点用户覆盖增加但接入时延变大短格式 A/B/C较短单时隙可完成中近点、高频、URLLC时延低对 SINR 敏感度高如果发现某小区远点用户随机接入失败率偏高优先查prach-ConfigurationIndex和preambleReceivedTargetPower是否匹配上行覆盖半径。错误的 configurationIndex 会让 preamble 落在错误的有效时间窗口内基站收不到UE 反复增大发射功率表现就是 RSSI 高但接入失败。3.2 RRC 建立与 NAS 服务请求流程拆解RRC 连接建立是 5G 信令流程里最常被考核的指标。标准流程是UE 发RRCSetupRequest基站回RRCSetupUE 回RRCSetupComplete。建立完成后如果 UE 此前没有注册会在空口上继续发 NAS 层的RegistrationRequest如果只是从空闲态恢复业务发的是ServiceRequest。基站端把 NAS 消息封装在InitialUEMessage里通过 NG 口送给 AMFAMF 回复DownlinkNASTransport再触发上下文建立。从网络优化角度这里的核心 KPI 不是单条消息的成功率而是RRCSetupRequest → RRCSetupComplete的时延分布。建议按 P50、P95、P99 统计而不是只看平均。平均时延容易被大量近点快业务拉低P95 才是用户真实感知。# 假设前台导出的 L3 消息为每行一条字段为 # 时间戳|消息类型|小区ID|IMSI|结果 awk -F| $2RRCSetupRequest {begin[$3 FS $4]$1} $2RRCSetupComplete begin[$3 FS $4]! {split($1,a,.); split(begin[$3 FS $4],b,.); print $3,$4,a[1]-b[1]} l3_dump.txt这段 awk 按“小区 ID IMSI”做关联把同一 UE 的 RRCSetupRequest 和 RRCSetupComplete 配对输出建立时延。FS设为竖线分隔split处理秒和毫秒输出结果可以直接导入 Excel 做百分位统计。要特别注意原始日志的时间格式必须统一否则会出现负数。3.3 NGAP 初始上下文建立和 QoS 流绑定RRC 建立只是“拉通了通道”真正让业务可用的是 NGAP 侧的 InitialContextSetup 流程。AMF 收到 ServiceRequest 后会向 gNB 下发 InitialContextSetupRequest里面带上要建立的 PDU Session、S-NSSAI、QoS flow 与 QFI 的映射。gNB 再把 QoS flow 映射到 DRB 上通过 RRCReconfiguration 配置给 UE。这段信令流程里最容易出现的问题有三个一是 UE 请求的网络切片和 AMF 允许的切片不匹配导致 PDU Session 建立被拒绝二是 QFI 分配冲突两个业务流用了同一个 QFI三是核心网侧 5QI 参数与无线侧配置不对齐例如语音用了 5QI1但 gNB 侧 RB 配置里没有对应的保证速率参数。下面这个 Python 脚本可以从 NGAP 跟踪文本中提取 QFI 和 5QI 组合# parse_qos_from_trace.py # 输入基站导出的 NGAP 文本跟踪按行包含 qosFlowIdentifier 和 fiveQI import re from collections import defaultdict qos_map defaultdict(set) pattern re.compile( rngap\.qosFlowIdentifier(\d).*?ngap\.fiveQI(\d) ) with open(ngap_trace.txt, encodingutf-8) as f: for line in f: m pattern.search(line) if m: qos_map[int(m.group(2))].add(int(m.group(1))) for t, qfis in qos_map.items(): print(f5QI{t}: QFI{sorted(qfis)})代码思路是正则匹配每条 NGAP 消息里的 QFI 和 5QI聚合后输出当前网元实际用到的 QoS 流组合。5QI 相同时 QFI 不应重复重复就说明配置下发阶段已经出错。脚本只做文本扫描不依赖额外第三方库适合在堡垒机上直接运行。3.4 关键定时器参数T300、T302、T304 的作用域定时器是信令流程和现网参数之间的桥。T300 是 UE 发出 RRCSetupRequest 后等待 RRCSetup 的时长超时则 UE 认为接入失败T302 控制被拒绝后的退避时间T304 则用在切换流程中UE 收到带同步的 RRCReconfiguration 后等待目标小区随机接入成功的最大时间。3GPP 为每个定时器定义了取值范围但现网取值直接决定用户的失败耐心。定时器流程位置超时后果常见初始值T300RRCSetupRequest → RRCSetupUE 重建或直接回到空闲态1000 msT302RRCSetup 被拒绝后UE 延后再次接入可配为 160~3000 msT304切换后随机接入切换失败UE 回到源小区1000~2000 msT304 调大并不总是好事。现网切换失败定位时如果目标小区空口质量差但信号不弱T304 调大只是让用户多等一会儿最终失败了感知更差。常见做法是先看切换准备阶段的目标小区是否来得及完成资源授权再看 preamble 是否碰撞最后才动 T304。调整后至少观察一个高话务时段的切换失败原因统计。4. 5G 网络优化中的信令故障率VoNR 与切换、寻呼的现网处置4.1 VoNR 信令流程里的 QoS 承载检查VoNR 是 5G 网络优化信令流程里最典型的跨层流程涉及 RRC、NAS、NGAP、PFCP、HTTP/2 多个环节。语音业务建立时IMS 域要求网络提供 5QI1 的 GBR 承载和 5QI5 的 SIP 信令承载。在无线侧这个流程表现为 UE 先做普通数据业务接入然后基站收到核心网下发的 Additional QoS Flow 信令发起 RRCReconfiguration在同一个 DRB 或新 DRB 上添加语音承载。排查 VoNR 失败先看两处信令一是 InitialContextSetupRequest 或 PDUSessionResourceModifyRequest 里是否出现 5QI1 的 QoS Flow二是 RRCReconfiguration 的 QoS flow 到 DRB 映射表是否符合预期。很多“呼得通但听不清”的现场信令流程完整但 5QI1 的 GBR 流被基站安排到了 DRB 而不是专有数据无线承载调度时仍按非 GBR 处理就会导致语音包排队延迟。前台 L3 日志里可以直接查看 RRCReconfiguration 中每个 DRB 的logicalChannelConfig重点看优先级和 PBR 设置是否和 5QI1 推荐的优先级一致。4.2 切换信令流程定位与 T304 定时器整定Xn 切换流程可以浓缩成五条关键消息源站下发测量控制UE 上报 MeasurementReport源站通过 Xn 口发送 HandoverRequest目标站返回 HandoverRequestAcknowledge源站再向 UE 发 RRCReconfiguration。UE 在目标小区完成随机接入后返回 RRCReconfigurationComplete目标站发一条 HandoverSuccess 给源站源站随后释放 UE 上下文。5G 网格优化遇到切换失败时先把信令文件里的 T304 相关消息按 UE 维度筛选出来。下面是 tshark 过滤切换准备和失败消息的命令tshark -r xn_trace.pcapng -Y xnapp -T fields \ -e frame.time_relative \ -e ip.src \ -e ip.dst \ -e xnapp.initiatingMessage \ -e xnapp.successfulOutcome \ -e xnapp.unsuccessfulOutcome 2/dev/null | grep -i handover字段加粗的目的不是直接看到“失败原因”而是把 HandoverPreparation 和 HandoverSuccess/HandoverFailure 的配对起来。取出时间差后如果失败发生在目标站准备之前问题大概率在邻区关系或者目标站资源如果失败消息在 HandoverRequestAcknowledge 之后出现才去看 T304 和物理随机接入。5G 邻区添加案例里最常见的就是漏配同频邻区UE 测量到了一个未配置邻区的小区却无法切换信令里会反复出现 “event A3 triggered” 但目标小区不存在。4.3 用批量命令把信令日志聚合成全网排障报表现场日志成百上千条时逐条看信令不现实。我的习惯是先用 awk 或数据库做个粗聚类把失败集中在哪几个小区、哪段时间看清楚再回头细看信令流程。下面这段命令可以统计每个小区 RRC 建立失败次数awk -F| $2RRCSetupRequest {req[$3]} $2RRCSetupComplete {cmp[$3]} $2RRCSetupFailure {fail[$3]} END { for (cell in req) printf %s 尝试%d 成功%d 失败%d\n, \ cell, req[cell], cmp[cell]0, fail[cell]0 } 5g_sig_dump.txt | sort -k4 -nr | head -20这里假设输入文件是用|分隔的 L3 消息日志第二列是消息名第三列是小区 ID。END块在文件读完时统一输出sort -k4 -nr按失败次数降序排列把最差的小区排在最上面。失败次数高但拥塞指标正常的小区需要抓单用户信令逐条看拥塞指标也高的小区则先查上行干扰和准入参数。5. 把信令流程分析沉淀成可复用的优化基线信令流程分析不能每次都在现场临时抓包我一般会在每个地市项目开始时用两周存量数据做一份“5G 信令流程基线”。基线内容是一张表记录关键流程的正常时延范围、失败率阈值和典型失败原因。比如 RRCSetupRequest 到 RRCSetupComplete 的 P95 应低于 150 msNGAP InitialContextSetup 的时延参考值在 80 ms 以内T304 的切换成功率目标大于 99%。这个基线不是拍脑袋而是从历史信令日志百分位里算出来的。基线建好后后续每一次排障都可以用同样命令重新计算再和基线对比。例如查看某个时段 NGAP InitialContextSetup 的时延分布tshark -r ng_trace.pcapng -Y ngap.procedureCode 10 \ -T fields -e frame.time_relative \ -e ngap.ngap_IE_UL_UE_NGAP_ID ic_setup_time.txt然后分两步处理第一步按 UE NGAP ID 去重把同样 ID 的最后一条消息时间减去第一条消息时间得到每个用户的上下文建立时间第二步用sort -n和awk计算 P50/P95/P99。基线更新周期建议跟随版本升级和参数调整每次大规模邻区优化后也要重算一遍否则新基线和旧基线混在一起阈值就失去意义。最后再提醒一个容易忽略的技巧信令流程分析完以后要把关键流程的消息树保存成模板。下次只需要把抓包文件路径和小区 ID 换掉过滤语法、字段输出、时间差计算一点不用改。这个模板就是团队里最值钱的知识资产远比截图和聊天记录可靠。本文还有配套的精品资源点击获取