4G/5G SA互操作原理与流程详解：N26切换、重定向及优化实践

简介：本资源为《4G&5G互操作原理及流程（SA）》PPT课件，面向5G网络规划优化工程师、核心网与无线侧技术人员及通信专业学习者，聚焦SA组网下4G与5G协同的关键机制。内容围绕4G及5G互操作概述、NR空闲态与连接态互操作、LNR空闲态与连接态互操作、EPS Fallback语音回落流程、Fast Return信令流程以及常见语音问题排查思路六大模块展开，并给出SA移动策略设计中的空闲态与连接态策略、小区重选总体机制与重选算法参数解释，帮助读者理清NR与LTE之间的切换、重定向、重选及语音回落与快速返回的完整流程。资源包共1个pptx文件，大小约2.78MB，结构紧凑、便于直接用于培训或自学。目前已有148人学习下载，适合需要系统掌握SA互操作原理与信令流程的读者参考。

1. 4G与5G互操作到底在解决什么问题

很多人第一次接触“4G&5G互操作原理及流程（SA）”这个题目，是在准备网络优化面试或者写技术方案的时候。表面上看它像一份标准课件，但真正落到现网里，它回答的是一个非常具体的问题：当手机同时能连4G和5G，而5G核心网又是独立组网（SA）架构时，网络怎么决定让终端待在哪个制式、什么时候切、切过去之后业务怎么不断。

这件事的难点不在于“能不能连”，而在于“连得稳不稳、切得快不快、回落之后能不能快速回来”。SA架构下5G有自己的核心网，4G有EPC，两套核心网之间的交互比NSA复杂得多。如果互操作流程没配好，用户会碰到打游戏突然卡一下、VoNR通话建立慢、从地下室出来半天不回5G这些玄学问题。

这篇文章面向的是需要把互操作流程讲清楚、配明白、排得动的一线工程师和准备入行的同学。我会按“原理先立住、流程能复现、参数知道怎么调、坑知道在哪”的顺序展开，中间穿插可对照的流程表格和参数配置示例。读完之后，你至少能对着信令流程把一次N26接口切换的每一步说清楚，也能在遇到互操作失败时知道先查哪几个计数器。

2. SA互操作的核心网架构与关键接口

2.1 SA与NSA在互操作上的本质差别

NSA架构下，终端同时连4G和5G，但信令锚点始终在4G侧，5G只是加了一个数据管道。这种架构下互操作相对简单，因为核心网只有EPC一套，切换和重定向都在EPC内部完成。SA架构则完全不同：5G有自己的AMF、SMF、UPF，4G有MME、SGW、PGW，两套核心网各自独立，终端在4G和5G之间移动时，涉及的是两个核心网之间的互操作。

这个差别带来的直接后果是：SA下互操作必须依赖N26接口。N26是AMF和MME之间的接口，负责在切换过程中传递UE上下文、承载信息和会话状态。没有N26，4G和5G之间的切换就只能走重定向，业务中断时间从几十毫秒变成几秒，用户体验差距非常大。

从协议栈角度看，N26基于GTPv2-C，和S10接口类似但消息类型有扩展。它承载的核心消息包括Forward Relocation Request、Forward Relocation Response、Context Response等。这些消息里携带的IE决定了目标侧能不能顺利接住这个UE。

2.2 N26接口与核心网元的分工

N26接口的两端分别是5G的AMF和4G的MME。在互操作过程中，源侧核心网元负责发起切换准备，目标侧负责资源分配和上下文接收。具体分工可以用下面这张表来对照：

在实际部署中，PGW-C和SMF通常融合部署，UPF和PGW-U也融合部署。这种融合架构让会话在4G和5G之间迁移时不需要更换IP地址，业务连续性才有保障。

2.3 互操作的两大类场景

SA互操作从流程上分两大类：基于N26的切换和基于重定向的互操作。前者用于语音和数据业务都需要连续性的场景，后者用于终端不支持N26或者网络侧没有部署N26的情况。

基于N26的切换又分两种方向：5G到4G的切换（通常因为5G覆盖边缘或VoNR回落）和4G到5G的切换（通常因为终端进入5G覆盖且业务允许）。两个方向的流程不对称，信令消息和参数配置都有差异。

重定向流程则简单粗暴：源侧直接释放连接并下发目标频点，终端重新搜网接入。这种方式的业务中断时间通常在1到3秒，适合对时延不敏感的场景，但现网中如果大量使用重定向，用户感知会明显下降。

注意：N26接口是否部署，直接决定了互操作是“切换”还是“重定向”。在优化前先确认核心网侧N26状态，否则后面所有参数调整都是白费功夫。

3. 5G到4G的切换流程拆解与参数配置

3.1 基于N26的切换信令全流程

5G到4G的切换是整个互操作里最常被问到的流程，因为它直接关系到VoNR通话质量和边缘覆盖体验。下面按信令顺序拆解每一步。

第一步，源gNB决定发起切换。触发条件通常是测量报告显示4G邻区信号质量优于5G服务小区，或者5G侧资源紧张需要负载均衡。gNB向AMF发送Handover Required消息，里面包含目标小区ID和切换类型。

第二步，AMF通过N26接口向MME发送Forward Relocation Request。这个消息里携带了UE的IMSI、源TAI、目标TAI、PDU会话列表等关键信息。MME收到后开始准备4G侧资源。

第三步，MME选择目标SGW和PGW，向SGW发送Create Session Request。SGW再向PGW-C+SMF发送请求，PGW-C+SMF需要判断哪些PDU会话可以迁移到4G。这里有个关键点：如果某个PDU会话的QoS参数在4G侧不支持，SMF会拒绝迁移该会话。

第四步，MME向目标eNB发送Handover Request，eNB分配无线资源后返回Handover Request Acknowledge。MME再通过N26向AMF发送Forward Relocation Response，告知切换准备完成。

第五步，AMF向源gNB发送Handover Command，gNB转发给UE。UE切换到4G目标小区，完成随机接入后发送Handover Complete。目标eNB通知MME，MME再通知SGW和PGW-C+SMF完成路径更新。

整个流程走完，用户面路径从“UE-gNB-UPF”变成“UE-eNB-SGW-PGW-U”。如果PGW-C+SMF融合部署且IP地址不变，上层业务基本无感知。

3.2 关键参数：N26开关与切换门限

参数配置是互操作能不能按预期工作的核心。下面这张表列出了5G到4G切换中最常调的几个参数：

这些参数在gNB侧配置，但AMF和MME侧也有对应的开关。比如AMF侧需要配置N26对端MME的IP地址和端口，MME侧需要配置支持的N26消息类型。任何一侧没配好，切换都会失败。

3.3 用日志验证切换是否走通N26

光看参数不够，得从信令日志里确认流程真的走了N26。下面是一段用常见信令分析工具过滤N26消息的示例命令：

# 过滤N26接口上的Forward Relocation消息 tshark -i eth0 -f "sctp port 38462" -Y "gtpv2.message_type == 0x01 or gtpv2.message_type == 0x02" -V # 统计N26接口上各类型消息数量 tshark -i eth0 -f "sctp port 38462" -T fields -e gtpv2.message_type | sort | uniq -c | sort -rn

第一行命令抓取N26接口上的Forward Relocation Request（消息类型0x01）和Response（0x02），-V参数输出详细解码。第二行统计所有GTPv2消息类型，用来判断N26接口上有没有异常消息。

如果只看到Forward Relocation Request但没有Response，说明目标MME侧拒绝或超时。这时候要查MME的N26配置和SGW选择是否正常。如果连Request都没有，说明AMF根本没发起N26流程，要回头查gNB的切换触发条件和AMF的N26开关。

提示：N26接口默认使用SCTP端口38462，但现网可能改过。抓包前先确认AMF和MME的实际配置端口，否则过滤器写错什么都抓不到。

4. 4G到5G的互操作流程与重定向对比

4.1 4G到5G切换的触发条件与流程差异

4G到5G的切换流程和反方向类似，但有几个关键差异。首先是触发条件不同：4G到5G通常由B1事件触发，即5G邻区信号质量超过绝对门限。其次是核心网交互方向相反：MME通过N26向AMF发送Forward Relocation Request，AMF负责准备5G侧资源。

流程上，MME先收到eNB的Handover Required，然后通过N26向AMF发Forward Relocation Request。AMF选择SMF，SMF再选择UPF，完成PDU会话的建立或修改。AMF向目标gNB发Handover Request，gNB分配资源后返回响应。MME收到Forward Relocation Response后向源eNB发Handover Command，UE切换到5G。

这里有个容易忽略的点：4G到5G切换时，如果终端在4G侧有多个承载，SMF需要判断哪些能映射到5G的QoS Flow。映射规则基于QCI到5QI的对应关系，如果某个QCI在5G侧没有对应的5QI，该承载会被释放。

4.2 重定向流程：什么时候用、怎么配

重定向流程比切换简单得多，但代价是业务中断时间长。它的典型使用场景包括：终端不支持N26、核心网未部署N26、或者切换准备失败后的兜底。

重定向的流程是：源侧eNB或gNB直接下发RRC Release消息，里面携带目标频点信息。终端释放连接后重新搜网，在目标制式上发起初始接入。整个过程没有核心网之间的交互，所以不需要N26。

配置上，重定向主要控制两个参数：redirectCarrierInfo和redirectProbability。前者指定目标频点，后者控制重定向概率。如果现网中重定向比例过高，说明切换成功率有问题，需要回头查N26和切换门限。

下面这张表对比了切换和重定向的关键指标：

4.3 互操作中的QoS映射与承载处理

QoS映射是互操作里最容易出问题的地方。5G用5QI标识QoS Flow，4G用QCI标识EPS Bearer。两者之间的映射关系在3GPP TS 23.501里有定义，但现网中经常遇到映射不一致导致承载建立失败。

常见做法是：在PGW-C+SMF上配置QCI到5QI的映射表，确保语音、视频、信令等关键业务有对应的QoS等级。如果某个QCI没有映射，SMF会在切换准备阶段拒绝该会话，导致切换失败。

排查时，重点看SMF的日志里有没有“QoS mapping failed”或“no corresponding 5QI”这类关键字。如果有，说明映射表缺项，需要补配。

# 在SMF日志中查找QoS映射失败记录 grep -i "qos.*mapping.*fail\|no.*corresponding.*5qi" /var/log/smf/smf.log | tail -50 # 查看当前QCI到5QI的映射配置 smf-cli show qos-mapping table

第一行命令从SMF日志里过滤映射失败记录，tail -50只看最近50条。第二行通过SMF命令行接口查看当前映射表。如果发现某个QCI没有对应项，需要根据业务类型补配。

注意：QCI和5QI的映射不是一一对应的，多个QCI可能映射到同一个5QI。配置时要参考运营商的QoS策略，不要自己拍脑袋定。

5. 互操作常见问题排查与避坑

5.1 N26接口不通导致切换全部失败

现象：5G到4G切换成功率突然掉到零，但重定向比例飙升。核心网日志里大量Forward Relocation Request超时。

原因：N26接口的SCTP链路中断，或者AMF/MME侧的对端配置被误改。常见的是MME侧N26的IP地址写错，或者AMF侧没有添加MME的N26地址。

解决：先ping测试AMF和MME之间的IP连通性，再用SCTP层工具检查链路状态。确认配置无误后，重启N26接口的SCTP关联。如果还是不通，查中间有没有防火墙拦截SCTP端口。

5.2 切换门限设置不合理导致乒乓切换

现象：终端在5G和4G之间反复切换，信令负荷高，用户感觉网络忽快忽慢。

原因：A2和B2门限设置得太接近，或者4G到5G的B1门限太低。终端在边缘区域信号波动时，频繁触发两个方向的切换。

解决：调整门限迟滞。A2和B2之间至少留5dB的差值，B1门限要比5G小区边缘场强高3到5dB。同时开启切换惩罚定时器，避免短时间内重复切换。

5.3 QoS映射缺失导致语音回落失败

现象：VoNR通话建立时，5G到4G切换失败，通话直接掉线。

原因：语音承载的QCI在SMF侧没有对应的5QI映射，切换准备阶段SMF拒绝迁移该会话。

解决：检查SMF的QoS映射表，确保QCI 1（语音）和QCI 5（信令）有对应的5QI。通常QCI 1映射到5QI 1，QCI 5映射到5QI 5。如果缺失，补配后重启SMF的会话管理模块。

5.4 终端不支持N26导致互操作退化

现象：部分品牌终端在5G到4G时总是走重定向，其他终端正常。

原因：终端能力上报里没有包含N26支持指示，或者终端固件版本太旧。

解决：查核心网侧收到的UE Capability信息，确认有没有N26相关IE。如果没有，联系终端厂商确认是否支持。现网中如果这类终端占比高，需要在网络侧配置重定向兜底策略，保证业务不中断。

5.5 路径更新失败导致用户面不通

现象：切换信令流程走完了，但用户面数据不通，ping包全丢。

原因：PGW-C+SMF没有完成路径更新，或者UPF和SGW之间的GTP隧道没建立起来。

解决：查SMF的路径更新日志，确认有没有收到Modify Bearer Request。再查UPF和SGW之间的GTP-U隧道状态。如果隧道没建，检查UPF和SGW的GTP-U端口配置和IP路由。

6. 用计数器与信令跟踪验证互操作效果

6.1 关键计数器与指标解读

优化互操作不能只看成功率一个数，要拆开看各个阶段的失败原因。下面这张表列出了最常用的几个计数器：

这些计数器通常从AMF、MME、SMF的Performance Management模块采集。如果HO_SuccRate_5G2G低但N26_MsgTimeout为0，说明切换请求发出去了但目标侧拒绝，要查目标eNB的资源或QoS映射。

6.2 用信令跟踪定位单用户问题

计数器只能看整体趋势，单用户问题得靠信令跟踪。常见做法是在AMF或MME上开启针对特定IMSI的信令跟踪，把整个切换流程的消息全部抓下来。

# 在AMF上开启针对指定IMSI的信令跟踪 amf-cli trace start --imsi 310150123456789 --interface N26 --duration 300 # 跟踪结束后导出消息序列 amf-cli trace export --imsi 310150123456789 --format pcap --output /tmp/trace.pcap

第一行命令在AMF上启动针对指定IMSI的N26接口跟踪，持续300秒。第二行把跟踪结果导出为pcap文件，方便用Wireshark分析。导出后重点看Forward Relocation Request里携带的PDU会话列表，以及Response里哪些会话被拒绝了。

如果Response里某个会话的Cause值是“QoS not supported”，说明映射表缺项。如果是“Resource unavailable”，说明目标eNB资源不足。不同Cause值指向不同的排查方向。

6.3 一个容易忽略的验证点：切换后的IP地址

业务连续性最终体现在IP地址不变。切换完成后，从终端侧ping一个外部地址，同时抓包看源IP有没有变。如果IP变了，说明PGW-C+SMF没有融合部署，或者路径更新时更换了锚点。

这个验证点经常被忽略，因为信令流程看起来是成功的，但用户面已经断了。我一般会在切换测试后加一步：从终端发起一个长ping，同时后台抓包，切换前后各看10个包，确认源IP和目的IP都没变。

提示：IP地址不变的前提是PGW-C+SMF融合部署且UPF支持锚点功能。如果现网是分离部署，切换后IP大概率会变，这时候要考虑用应用层重连来兜底。

6.4 我踩过的一个坑：N26配置对了但SCTP参数不匹配

有一次现网N26链路显示正常，但切换成功率始终上不去。查了半天配置都没问题，最后发现是SCTP的Max Inbound Streams参数不匹配。AMF侧配的是16，MME侧配的是8，导致高并发切换时部分消息被丢弃。

这个坑的血泪经验是：N26不只是IP和端口要对，SCTP层的参数也要对齐。后来我养成了一个习惯，每次检查N26的时候，除了看链路状态，还会用ss -S和netstat -s看SCTP的重传和丢弃统计。如果重传率高，先查SCTP参数再查业务层。

希望帮到你。

本文还有配套的精品资源，点击获取