企业官网建设流程全解析

简介：面向5G网优工程师的专项案例文档，聚焦5G语音业务采用EPS Fallback回落至4G VoLTE后、部分小区频繁掉2G引发用户投诉的问题。文档先从背景切入说明SA初期语音回落机制，再梳理EPS FB两类执行方式（基于重定向与基于切换），总结掉2G的常见原因分布，如回落阶段专载建立失败、TAU失败、寻呼异常及流程冲突等。重点给出三个实战优化案例：4G侧传输丢包、回落至4G后的不必要切换引发流程冲突、被叫5-4切换失败导致主叫CSFB掉2G，每个案例均结合信令回溯定位根因并给出具体处理方案，比如排查尾纤告警、控制切换触发难度、核查邻区关系并提升4G侧SINR。文末亦归纳后续优化方向，包括干扰监测整治、同频同PCI整治、语音打底网覆盖提升、MME/AMF协同等。资源为docx文档一份，整体3.82MB，已有750人学习，适合从事5G网络优化与语音质量提升工作的工程师参考借鉴。

1. 掉 2G 通话聚集：5G 语音优化的第一块硬骨头

5G 商用初期，VoNR 还没铺开，语音靠的是 EPS Fallback 回落到 4G 打 VoLTE。原本设计好的回落链路，却在不少 5G 小区里出现「掉 2G 通话聚集」——用户打着打着电话直接掉到 2G，呼叫时延拉长、通话断续甚至中断，投诉量跟着涨。这类问题表面看是回落异常，实际根子往往在 4G 侧传输、切换流程、邻区关系或干扰上。这篇笔记我拆的是一份真实网优案例，覆盖 EPS FB 回落原理、掉 2G 原因定界、三个实战处置案例和一套可复用的排查套路，适合刚接触 5G 语音优化的网优工程师，也适合手里正捏着 TOP 掉 2G 小区清单、急着找排查方向的人。

2. EPS Fallback 回落原理：三种回落方式与四个高风险环节

2.1 基于切换的 EPS FB：PSHO 如何把 UE 送进 Eutran

基于切换的 EPS FB，核心是 PSHO（Packet Switched Handover）。UE 在 5G 侧发起 ESR（Extended Service Request）后，gNodeB 直接下发 MobilityFromNRCommand 消息给 UE，这条消息里带关键信元 targetRAT-Type: Eutran，UE 收到后就按切换流程迁到 4G 小区。

判断一个回落是不是 PSHO，看信令里有没有这条 MobilityFromNRCommand 就行。有，就是切换型；没有，走的是重定向型。实际排查中，我习惯先把回落形式分清楚再往下查，因为切换型回落需要在 4G 侧完成切换准备，目标小区要提前配置好邻区关系和切换参数，出问题的环节和重定向型差别很大。

PSHO 的优点是回落速度快、时延低，UE 不会先回到空闲态再重新接入。代价是对邻区配置的完整性要求高：5G 侧要配置到 4G 的邻区关系，4G 侧要能正确解析切换请求。案例里出现的「回落成功后紧接着切到另一个 4G 小区导致流程冲突」，就是 PSHO 链路在 4G 侧又发生了二次切换，这个后面细讲。

2.2 基于重定向的 EPS FB：测量重定向与盲重定向的差异

基于重定向的 EPS FB 走的是 RRC Connection Release 流程，gNodeB 先把 UE 的连接释放掉，UE 再按指定的 Eutran 频点去 4G 侧重新接入。这里又分两种：

第一种是基于测量的重定向。gNodeB 先下发 RRC 重配置命令，里面携带 Eutran 频点、小区信息和 B1 事件门限参数，UE 按要求测量，上报测量报告后 gNodeB 才触发重定向。这种方式能保证 UE 落到的 4G 小区是测量过、信号达标的，但多了测量环节，时延比盲重定向长。

第二种是盲重定向。UE 发起 ESR 后，gNodeB 不执行测量阶段，直接下发 RRC Connection Release 把 UE 释放到配置的 Eutran 频点。好处是快，坏处是 UE 对目标频点实际覆盖一无所知——如果这个频点在 UE 当前位置覆盖很差，UE 接入 4G 失败或接入后信号差，后续就会触发重选或掉 2G。盲重定向出问题，优先怀疑频点配置和 4G 覆盖。

我看信令的时候，区分这三种回落形式就盯两个点：有没有 MobilityFromNRCommand，有没有下发带 Eutran 频点测量的 RRC 重配置。两个都没有、直接 release，那就是盲重定向。

2.3 四个高风险环节：回落、TAU、建专载、寻呼

EPS FB 和普通 VoLTE 相比，多了回落和 TAU 两个过程。把整个语音呼叫链路拆开看，掉 2G 高发在四个阶段：

回落阶段。UE 从 5G 往 4G 迁的过程中，在目标小区接入失败，常见原因是 45G 小区越区覆盖——UE 收到的是远处 4G 小区的信号，实际接入时又够不着，或者目标小区负载过高拒绝接入。这个阶段失败，UE 可能直接掉 2G，也可能回 5G 重来。

TAU 阶段。UE 回落后发生 RRC 重建，从新小区接入，触发了 TAU 流程。某些场景下终端会启动 T3402 定时器，默认 12 分钟。这个定时器一跑，期间终端无法正常做位置更新，一直在 2G 兜底，用户感知就是长时间回不了 4G/5G，这是最坑的一种，因为单个用户的问题会持续很久。

建专载阶段。回落后 4G 侧要为语音建立 QCI=1 专载，6 秒内没建成功就触发回 2G。常见原因是建专载和切换发生冲突——UE 刚落到 4G 还没站稳，又被切到另一个 4G 小区，专载建立流程被切换打断。

寻呼阶段。被叫寻呼无响应，或被叫侧回落异常，主叫终端等不到被叫的 183 消息，部分华为终端在 15 秒内没收到响应会主动回 2G 保证语音能接续。这种情况主叫侧其实是被被叫拖累的。

这四个环节不是孤立的，实际信令回溯时经常是多个环节叠加。我排查时习惯先定界到具体阶段，再往下看是无线侧还是核心网侧的问题，后面第 3 章说定界方法。

3. EPS FB 掉 2G 原因定界：从信令平台到数据驱动的排查路径

3.1 掉 2G 原因分类：六类原因与统计口径

把掉 2G 问题归归类，日常优化中碰到的无非这么几类：

4G 侧高干扰。4G 小区存在上行或下行干扰，回落过去的 UE 信号质量差，专载建立失败或通话质量差导致掉 2G。这类在 TOP 小区里占比最高，尤其城区密集区域。

5G 侧高干扰。5G 侧干扰导致语音承载建立质量差，回落时机或回落目标选择异常。

5G 侧站点故障。站点退服、板卡故障、传输异常，导致 UE 无法正常建立 5G 业务或回落链路异常。

4G 侧站点故障。4G 侧传输丢包、RRU 故障、小区退服等，UE 回落过去后业务无法正常建立。

流程冲突。回落成功后 4G 侧发生非必要切换，与专载建立、TAU 流程打架。

其他。承载更新失败、被叫开通视频彩铃导致主叫 QCI=2 建立失败、SIP 消息重传等。

统计口径上，案例给了一个可复制的做法：利用大数据平台和信令平台，根据呼叫信令关联 S1-MME 信令，识别通话过程中产生 ESR 流程的呼叫，视为存在掉 2G 问题。取 8-10 日共三天全网回落次数 6 次以上的 NR 小区，长沙华为区域筛出 64 个小区。这个口径有两个关键参数：统计窗口（三天）和回落次数阈值（6 次以上），实际做专题整治时这两个参数可以按地市规模调——小区多的大市可以把阈值抬高到 10 次，缩小整治范围先打 TOP。

3.2 大数据平台定界：ESR 流程识别与 TOP 小区筛选

定界思路是三层递进：先圈小区、再定阶段、最后定位根因。

# 第一步：按回落次数筛 TOP 小区（伪代码，实际在信令平台 SQL 中执行） SELECT nr_cell_id, COUNT(esr_flow_id) AS fallback_cnt FROM s1_mme_signaling WHERE date BETWEEN '2025-06-08' AND '2025-06-10' AND esr_type = 'VOICE' GROUP BY nr_cell_id HAVING fallback_cnt >= 6 ORDER BY fallback_cnt DESC;

这条 SQL 干了三件事：限定三天窗口、只统计语音类 ESR 流程、按 NR 小区维度聚合回落后掉 2G 的次数。HAVING 条件里的fallback_cnt >= 6就是 TOP 小区筛选阈值，实际项目中我会先跑一版不带阈值的看看分布，再用帕累托法则取前 80% 的小区。

# 第二步：对 TOP 小区关联 4G 侧指标，判断高干扰与故障 SELECT nr_cell_id, lte_cell_id, lte_uplink_interference, lte_downlink_interference, lte_cell_avail_status, lte_transport_loss_rate FROM top_cell_daily WHERE nr_cell_id IN ('长沙雨花栗塘小区 1 栋-H5H-D59002491962PT-2611', ...);

第二步是把 TOP 小区和 4G 侧 KPI 关联起来，重点看三个字段：4G 小区的干扰电平（上行干扰 > -110dBm 基本算高干扰）、4G 小区可用状态（有没有退服）、传输丢包率。案例里雨花栗塘那个站点就是靠这层关联发现传输丢包的。

到了这一步，基本能定界是 4G 侧问题还是 5G 侧问题，再往下就要拉用户级信令了。

3.3 用户级信令回溯：拉 ESR 流程看具体掉 2G 点

平台筛出 TOP 小区后，真正定位根因靠的是单用户信令回溯。我一般按这个顺序拉数据：

# 第三步：按 IMSI 拉单用户全流程信令，定位掉 2G 阶段 # 关键信令节点按时间排序输出： # 1. UE -> gNodeB: ESR (语音) # 2. gNodeB -> UE: MobilityFromNRCommand / RRC Connection Release # 3. UE -> 4G eNodeB: RRC Connection Setup Complete (含 TAU 请求) # 4. MME -> UE: TAU Accept # 5. 4G 侧: QCI=1 专载建立请求/响应 # 6. 主被叫: SIP INVITE / 183 / UPDATE

拉出来之后按第 2 章说的四个高风险环节对号入座：如果 ESR 之后没有下发任何回落命令，看 gNodeB 是不是故障或配置问题；如果回落后 TAU 没完成，看 T3402 定时器有没有启动；如果专载建立请求发出但没响应，看 4G 侧 S1 口和传输；如果卡在 SIP 183 消息，问题在被叫侧或核心网。

有个常见的误区是只看 5G 侧信令，不看 4G 侧和核心网侧。掉 2G 这个结果往往是跨制式链路共同作用的结果，只看 NR 侧信令十有八九定界不准。案例里三个问题有两个根子在 4G 侧（传输丢包、切换冲突），一个在 4G 侧 SINR 差导致回落失败，都印证了这一点。

4. 三个真实优化案例：从传输丢包到流程冲突的实战处置

4.1 案例一：4G 侧传输丢包导致概率性回落 2G

雨花区栗塘小区附近有用户投诉打电话时延长，现场测试发现 5G 通话占用长沙雨花栗塘小区 1 栋-H5H-D59002491962PT-2611，EPS FB 回落至 4G 小区长沙雨花栗塘小区 1 栋 3DMIMOHL-D5900141413PD-131，出现概率性回落 2G。

处理路径很直接：先在 4G 侧做 PING 包排查，发现传输侧存在丢包。联系传输侧人员检查，定位到站点存在传输丢包告警。代维现场处理尾纤后丢包解决，EPS FB 通话恢复正常，不再回落 2G。

这个案例的价值在于它揭示了掉 2G 排查中一个容易被忽略的方向——传输。很多人一看到掉 2G 就扑向无线参数、干扰、邻区，忘了物理层底下还有传输链路这层。尾纤脏污或松动导致的丢包，在无线侧 KPI 上通常不明显，但数据面丢包会直接吃掉回落后的语音专载建立流程，表现出来就是概率性掉 2G。

排查建议：碰到概率性掉 2G、且无线侧指标没有明显异常的小区，别急着调参数，先花半小时做 4G 侧传输丢包排查。PING 大包（1500 字节）连续跑 1000 次，丢包率超过 0.1% 就要查传输侧。

4.2 案例二：流程冲突导致掉 2G——回落后二次切换惹的祸

涂家冲某领导反映打电话过程中掉 2G，信令回溯发现：EPS FB 流程发起后，UE 已正常切换至 4G，接通过程中又切换到另外一个 4G 小区，流程冲突导致掉 2G。

这里的机制要拆开看：UE 回落成功后，4G 侧又发起了切换。如果这个切换不是基于覆盖的必要切换，就会和正在进行中的专载建立流程撞车。专载建立要求 UE 和目标小区之间有一个稳定的上下文，切换过程中上下文要搬到新小区，两个流程同时跑必然互相踩踏。案例里回落后发生的这几次切换，经分析并非基于覆盖的必要切换。

处理办法是控制切换触发难度，减少不必要切换触发次数。具体落地有几种做法：

# A3/A5 事件切换门限调整示例（4G 侧参数，不同厂家命名略有差异） # 原配置：A3 偏置 3dB，触发时延 320ms # 调整为：A3 偏置 6dB，触发时延 480ms MOD LTEINTRAHO: LOCALCELLID=131, A3OFFSET=6, TRIGGER_TIME=480ms;

A3 偏置从 3dB 提高到 6dB，意味着邻区信号要比服务小区强 6dB 才触发切换，不必要切换的数量会明显下降。触发时延从 320ms 拉到 480ms，给专载建立争取时间。调整后观察掉 2G 次数和切换成功率，两者要一起看——切换门限调严了，掉 2G 可能降，但切换成功率也会略降，要找到一个平衡点。

这个案例提醒一个点：EPS FB 优化不能只盯着 5G 侧，4G 侧的切换策略直接影响语音回落质量。特别是回落目标小区处于多个 4G 小区交叠区域时，非必要切换的概率很高。

4.3 案例三：被叫 5-4 切换失败触发 CSFB，主叫跟着掉 2G

这个案例最复杂，信令回溯细节值得完整过一遍：

14:21:04 主叫占用长沙岳麓银盆岭-13 小区，电平 -65dBm，SINR 14dB，发起呼叫请求，回落至长沙长江宾馆-71 小区，电平 -75dBm，SINR 2.5dB。14:21:05 创建 QCI=1 承载。

被叫 14:21:06 占用长沙岳麓银盆岭 5G-13，电平 -67dBm，SINR 12dB，收到寻呼消息，回落目标小区长沙岳麓银盆岭-17，电平 -79dBm，SINR -5dB——4G 侧 SINR 极差，5-4 回落失败，UE 重选回 5G。14:21:14 被叫语音信令交互过程处于 5G，向网络发起 SIP Invite Precondition Failure 580，主叫终端主动上报 cancel，导致未接通。随后主叫发起 CSFB 流程继续呼叫，终端掉 2G。

这个案例链条很长，拆解一下核心矛盾：

• 被叫回落目标小区 4G SINR 为 -5dB，这个质量根本撑不起 QCI=1 专载，回落失败。
• 被叫重选回 5G 之后，语音承载还是没法建立，SIP 层报 Precondition Failure 580。
• 主叫收到失败，没有放弃，走了 CSFB 兜底——结果就是掉 2G。

根因其实在被叫侧的 5-4 回落目标选择。优化方案分两条线：核查添加长沙岳麓区银盆岭 BBUO2-H5H-D59002494398PT-2613 与长沙岳麓银盆岭 HFD-D5900462585PT-17 小区的邻区关系；优化提升该路段 4G 侧 SINR 值。

邻区关系这块是常见动作。被叫回落到 SINR -5dB 的小区，说明 5G 侧配置的回落目标频点/小区里，这个差小区排在了前面，或者漏配了更好的邻区。加邻区后，回落目标选择范围变大，gNodeB 才有机会把 UE 落到质量更好的 4G 小区。4G 侧 SINR 优化则涉及 RF 调整、功率参数优化或干扰排查，周期更长，但属于治本。

5. 掉 2G 专题整治避坑清单：五条踩坑记录与验证方法

5.1 现象一：概率性掉 2G，无线侧指标全绿

现象：小区掉 2G 次数不低，但干扰、KPI、告警全部正常，参数翻了几遍找不到原因。按传输排查流程 PING 包测试，发现 4G 侧传输丢包。原因：尾纤脏污/松动导致的传输层丢包，无线侧 KPI 无感知。解决：代维现场处理尾纤后丢包消失。

这个坑我踩过不止一次。概率性掉 2G 且无线侧无异常的，优先查传输，PING 大包 1000 次看丢包率，别一头扎进参数里。

5.2 现象二：回落成功后马上二次切换，专载建立失败

现象：信令里看到 EPS FB 到 4G 后，紧接着又切换了一次，然后专载建立失败掉 2G。原因：回落后触发了非基于覆盖的必要切换，切换流程和专载建立流程冲突。解决：调严 A3/A5 切换门限（偏置增 3dB、时延增 160ms 起步），减少不必要切换触发次数。

注意这里有个度的问题：切换门限调太严，真需要切换的时候切不过去，会引入掉话风险。每调一版参数，必须同时盯切换成功率，看到成功率掉到 99% 以下就得往回退。

5.3 现象三：被叫回落目标小区 SINR 为负值

现象：信令回溯发现被叫回落目标小区 SINR -5dB，专载建立失败回 5G，主叫最终掉 2G。原因：5G 侧回落目标选择里没有配置质量更好的邻区，UE 盲落或测落到差小区。解决：核查并添加目标路段 4G 邻区关系，重点补强室内外交叠区域的邻区配置；同步推动 4G 侧 RF 优化提升 SINR。

补邻区这个动作看着简单，实际要查同频同 PCI 的问题——5-4 邻区里如果有两个 4G 小区同频同 PCI，回落目标选择会出乱子，案例总结里提到的「常态化开展 5-4 邻区同频同 PCI 问题整治」说的就是这事。

5.4 现象四：T3402 定时器启动，用户长时间无法回 4G/5G

现象：用户掉 2G 后长时间驻留在 2G，12 分钟级别才恢复。原因：回落后发生 RRC 重建，从新小区接入，触发 TAU 失败，终端启动 T3402 定时器。解决：这个要从源头压降回落后的 RRC 重建概率——核查回落目标小区配置、提升 4G 覆盖质量、优化重选参数，让 UE 回落一次就能站稳。

T3402 是终端侧定时器，网侧没法直接改它，只能通过减少触发场景来规避。被 T3402 卡住的用户，感知是最差的，这类投诉升级也快，排查时优先处理。

5.5 现象五：主叫掉 2G，根因在被叫侧寻呼无响应

现象：主叫语音接通时延异常，随后掉 2G，5G/4G 侧指标都看得到语音呼叫发起，但 SIP 层等不到 183。原因：被叫寻呼无响应或回落异常，主叫侧 15 秒未收到 183 消息触发回落 2G 兜底。解决：不能只看主叫小区，要拉被叫侧完整信令链路，定位被叫寻呼失败原因——被叫所在 5G 小区寻呼配置、被叫回落目标小区质量、被叫终端状态。

这条写在避坑清单里，是因为踩坑的人极多：主叫侧小区指标看起来一切正常，问题却出在另一个小区的被叫身上。

5.6 验证方法与复测习惯

每次优化动作之后，验证分三层：

第一层看指标，调完 4-24 小时（看统计粒度）拉掉 2G 次数、回落成功率、专载建立成功率三个指标，和调整前对比。第二层看信令，挑几个优化小区的实时呼叫，拉 ESR 之后的完整链路确认不再掉 2G。

第三层是现场测试。案例里雨花区那个就是用户投诉后现场测试复现的。我自己的习惯是：无线参数调整类优化，必须做 DT/CQT 验证，选早晚忙时各测一轮，单小区至少验证 20 次呼叫。现场测试能发现平台统计看不见的问题，比如回落目标小区实际覆盖和平台配置不一致。

最后分享一个压箱底的习惯：从那以后，我每次做掉 2G 专题整治，都会强制走一遍「平台筛 TOP → 用户级信令定界 → 四阶段对号入座 → 无线/传输/核心网逐层排查」的完整流程，宁可多花半天拉信令，也不跳过定界直接改参数。这个流程看着笨，但能挡住上面五类坑里至少四类。希望帮到你。

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