简介:面向通信网络优化工程师的VoLTE掉话分析专项资料,基于广州ATU网格真实测试数据,完整记录了掉话率从11.5%优化至3.27%、接通率从93.1%提升至96.6%的改善历程,并围绕异频重定向、异系统重定向、TM3/8模式转换、X2接口开启与跨站重建立等典型掉话场景,给出中兴eNodeB P01升级P02版本后的验证结论与优化手段,内容源于实际项目,实操参考价值强。文档同时总结了日常优化工作框架,涵盖无线覆盖优化、参数优化、系统内外邻区优化、功能优化四个方向,并深入解读RLC优先级冲突导致专载释放、QCI5 PDCP DiscardTimer过小引发SIP信令丢包、SBC TCP重传次数过大等疑难问题的原因分析与优化措施;还包含X2开启后RRC重建成功率从50%提升至80%等实测数据,帮助读者理解跨站重建立原理与PCI查询机制。资源为单个PDF文件,约2.58MB,内容紧凑实用;已有364人学习下载,适合通信行业一线网络优化人员、VoLTE技术支撑及项目交付团队学习参考。
1. 广州 VoLTE 掉话率三个月从 11.5% 压到 3.27%,这份优化复盘把问题一个一个钉死了
做 VoLTE 优化的人都知道,掉话分析最怕的不是问题多,而是问题散——今天调个参数,明天改个邻区,后天又发现是核心网的问题,最后说不清到底哪个动作起了作用。这份关于广州 VoLTE 掉话分析的经验文档,难得的地方在于它把掉话问题按「根因—版本—参数—验证」拆成了一个个可闭环的案例:中兴 eNodeB 从 P01 升到 P02,解决了异频重定向、异系统重定向、TM3/8 转换、X2 告警四类问题;RLC 优先级、PDCP DiscardTimer、PUSCH 功控、SBC TCP 重传次数这些参数优化,每一个都有现象描述、原因分析和优化前后对比。从四月到七月,ATU 网格掉话率从 11.5% 降到 3.27%,接通率从 93.1% 提到 96.6%。如果你是网优工程师、VoLTE 专项负责人,或者正在处理类似掉话指标的运营商技术人员,这份文档可以直接拿来对照排障,能省掉不少自己摸索的时间。
2. 中兴 P02 版本升级:四类掉话问题的根因与验证逻辑
VoLTE 掉话里有一大类是版本缺陷导致的功能异常,这类问题有个特征:参数怎么调都没用,因为问题出在基站算法本身的实现上。广州这次遇到的就是典型情况,中兴 eNodeB 在 P01 版本下有四类问题,全部靠升级 P02 版本解决。
2.1 异频重定向掉话:邻区缺失不是唯一原因
异频重定向掉话的背景是中兴 eNodeB P01 版本在邻区缺失时触发异频重定向,导致 VoLTE 掉话。最初大家以为补邻区就能解决,但实际测试中发现,网格 44、45 测试过程中虽然多次连续上报异频 A3 测报,网络却既没切换也没重定向。这说明问题不在邻区配置,而在基站对 QCI 1 业务异频重定向功能的处理逻辑上——P02 版本直接禁止了 QCI 1 业务异频重定向功能。
这个细节很关键。如果只盯着邻区关系去排查,可能补了上百条邻区仍然解决不了掉话,因为基站版本里对 VoLTE 业务的重定向策略才是根因。P02 版本升级后,异频重定向掉话在网格 44、45 测试中未再出现。
2.2 异系统重定向掉话:A2/B2 事件上报后不下发重定向
异系统重定向是 VoLTE 掉话的重灾区,尤其是基础覆盖较差的区域。网格 44、45 基础覆盖较差,以往拉网测试均会发生多次异系统重定向掉话。7 月 24 日完成 P02 版本升级后,重定向掉话问题解决,拉网测试掉话率改善明显。
P02 版本的处理逻辑是:终端上报 A2(盲重定向门限)或 B2 事件(2G 邻区信息错误)时,网络均不下发重定向,VoLTE 业务保持通话结束后自动挂机,不产生掉话事件。这意味着在覆盖不足的区域,VoLTE 通话会「硬撑」到通话自然结束,而不是中途被重定向打断——掉话指标好看了,但用户体验其实取决于通话能否自然结束。
2.3 TM3/8 转换掉话:基站提前转换导致的终端异常
TM3 到 TM8 的模式转换本身是正常的自适应过程,但 P01 版本存在基站提前转换导致终端掉话的问题。8 月 3 日网格 45 所有升级站点打开 TM3/8 自适应后,遍历拉网测试中出现 26 次 TM3 向 TM8 的模式转换,转换正常未发生异常。
这个案例提示了一个排查方向:如果终端掉话时间点与 TM 模式切换时间点吻合,不要先怀疑终端能力,优先查基站版本对 TM 自适应转换的触发条件是否合理。提前转换和滞后转换都会导致终端侧解调失败,最终表现为掉话。
2.4 版本升级后的配置建议
| 问题类型 | P01 版本表现 | P02 版本处理 | 验证结果 |
|---|---|---|---|
| 异频重定向掉话 | 邻区缺失触发重定向掉话 | 禁止 QCI 1 业务异频重定向 | 网格 44、45 未再出现 |
| 异系统重定向掉话 | A2/B2 上报后下发重定向 | 禁止 QCI 1 业务重定向 | 重定向掉话问题解决 |
| TM3/8 转换掉话 | 基站提前转换导致掉话 | TM3/8 自适应 | 26 次转换无异常 |
| X2 接口告警 | 网管告警抑制问题 | 抑制 X2 告警量 | 仅出 X2 断链告警,无 SCTP 断链 |
提示:P02 版本对重定向的「禁止」是策略性的,不是彻底关闭能力。优化时要确认版本升级后 QCI 1 业务的重定向策略与现网覆盖场景是否匹配,避免出现通话「硬撑」到信号完全丢失的情况。
版本类问题的排查思路是:先看信令里有没有规律性的事件时序,比如 A3 上报后无切换、A2/B2 上报后被忽略,再结合基站版本已知问题列表定位。如果参数排查和邻区排查都走完了还找不到原因,大概率要往版本缺陷方向推。
3. 参数优化实战:RLC 优先级、PDCP DiscardTimer 与 TCP 重传次数的调优记录
版本升级解决的是基站功能缺陷类掉话,参数优化解决的则是配置不合理导致的掉话和未接通。广州这次参数层面的动作不少,每个都有清晰的优化逻辑。
3.1 RLC 优先级优化:专载建立与切换冲突的根因
现象是呼叫建立与切换过程冲突,专载被 MME 释放。呼叫建立过程中专载建立与切换几乎同时发生,MME 未收到 NAS 专载完成消息导致释放专载,终端回复 invite 580,也有上发 CANCEL 的情况,专载丢失形成未接通事件。
原因分析比较直接:QCI 5 设置的 RLC 优先级为 2,高于 SRB=2(传送 NAS 层消息)配置为 3,导致 NAS 的层 3 消息虽然比 MR 要早,但因为优先级比 MR 和 SIP 低,未及时发送。在呼叫建立与切换并发时,NAS 专载完成消息没有及时到达 MME,MME 侧判定专载建立失败。
优化措施是降低 QCI 5 优先级,确保 SIP 消息及时上传,修改后此类问题改善明显。这个参数调整看起来简单,但背后是 LTE 信令承载的优先级博弈:SRB 用于 RRC 和 NAS 信令,QCI 5 用于 SIP 信令,两者优先级配反了就会在资源竞争时出问题。
3.2 QCI 5 PDCP DiscardTimer:从 300ms 到无穷大的取舍
现象是终端业务建立过程中出现 SIP 信息传递丢失,导致收到网络下发的 INVITE 500 或 580 等原因值释放。原因是 UE 在无线信道较差时,SIP 信令发送或接收不完整,导致 IMS 相关定时器超时并发起会话 cancel。
分析下来,QCI 5 的 PDCP 丢弃时长过小是直接原因——在无线覆盖较差的地方上行时延变大,QCI 5 信令容易丢包。优化措施是把 QCI 5 PDCP DiscardTimer 由 300ms 修改为无穷大,优化效果是 VoLTE 无线接通率提升明显。
PDCP DiscardTimer 的调优要理解一个权衡:定时器太短,信令在空口时延大时会被提前丢弃,导致 SIP 消息不完整;定时器设成无穷大,则意味着 PDCP 层会一直保留数据等待重传,可能增加时延。对 QCI 5 这种信令承载来说,宁可信令晚到,也不能让信令丢失,所以广州这边直接改成了无穷大。
3.3 SBC 传输协议 TCP 重传次数优化:一个核心网侧的案例
这个案例的场景比较特殊:被叫从 2G 返回 4G 后,主叫起呼,被叫首先发 BYE 消息,紧接着接连收到多条上一次呼叫的 INVITE,被叫回复 BYE 481、INVITE 486、INVITE 580,呼叫失败。
定位下来是爱立信 SBC 的 TCP 重传配置不合理:最大重传次数从 15 次改为 5 次,最大重传间隔从十几分钟改为 15s,此类问题解决。这个案例说明 VoLTE 掉话不全是无线侧问题,核心网网元的 TCP 栈参数也会导致 SIP 消息时序错乱,排查时不要只盯着空口指标。
3.4 上行 PUSCH 功控参数优化:发射功率降 2~3dB 的代价
4 月集团在中兴区域拉网测试发现上行 PUSCH 发射功率偏高,现网参数检查发现上行期望功率值设置过高。优化措施是:
# 现网配置 p0NominalPUSCH = -75 puschPCAdjType = 0 # 优化值 p0NominalPUSCH = -87 puschPCAdjType = 2同等路损情况下,参数修改后 UE 发射功率大约下降 2~3dB,PUSCH TxPower(10dBm 以上)占比由 40% 下降到 30% 左右。这里要注意,无论参数怎么调,终端平均上行发射功率仍高于 10dB,说明中兴的功控方式本身还有优化空间。PUSCH 功控参数调整的本质是在覆盖和干扰之间找平衡:期望功率设太高,终端发射功率大,对邻区干扰也大;设太低,边缘用户的 PUSCH 解调性能会下降。
3.5 RTP 丢包率与 PDCP DiscardTimer 的关系
4 月测试中中兴区域 RTP 丢包率偏高,个别网格达到 2% 以上。分析发现无线质量较好时基本无丢包,无线质量较差时上行丢包较严重,PDCP 重传时间超时数据包被丢弃。外场测试表明 QCI 1 PDCP DiscardTimer 配置与 RTP 丢包率及 Jitter 有密切关系:配置越大,RTP 丢包率越低,但 Jitter 也随之变大。
广州当时正在 601P02 版本下进行 100ms、300ms、500ms、750ms、1500ms、infinity 完整的对比验证,同时联合中兴公司定位 RTP 丢包率偏高问题。这个权衡要记住:QCI 1 是语音承载,RTP 丢包率直接影响 MOS 值,Jitter 过大会影响语音流畅度,不能为了压丢包率无限加大 DiscardTimer,要根据实际 MOS 测试结果选择平衡点。
| 参数项 | 原配置 | 优化值 | 优化效果 |
|---|---|---|---|
| QCI 5 RLC 优先级 | 2 | 降低 | 专载建立冲突改善 |
| QCI 5 PDCP DiscardTimer | 300ms | 无穷大 | 无线接通率提升明显 |
| SBC TCP 最大重传次数 | 15 次 | 5 次 | SIP 消息时序错乱解决 |
| SBC TCP 最大重传间隔 | 十几分钟 | 15s | 呼叫失败解决 |
| p0NominalPUSCH | -75 | -87 | UE 发射功率下降 2~3dB |
4. X2 接口与跨站重建立:从告警抑制到 RRC 重建成功率 50%→80%
X2 接口在 VoLTE 优化里容易被忽视,但它直接影响跨站重建立的能力。广州前期因为中兴网管告警问题未打开 X2 接口,导致跨站重建立不可用,这个问题的处理过程值得细看。
4.1 X2 告警抑制:为什么之前不敢开
广州前期没开 X2 接口的直接原因是中兴网管告警量太大,开了之后告警刷屏,反而掩盖了真正的故障。P02 版本对 X2 告警量做了抑制后,8 月 5 日网格 44、45 所有升级站点打开 X2 接口功能,指定开启 X2 自配置站点 213 个。
8 月 6 日统计站点 X2 偶联条数共计 4604 条,网管出现 60 多条 X2 断链告警。告警主要原因有两个:一是传输不通,部分微站无法与宏站正常建链;二是个别小区被闭塞不能正常建链。升级后 EMS 网管上只出 X2 断链告警,并且所有基站仅出 1 条(多条 X2 断链),无 SCTP 断链告警,网管上可明确区分 X2 与 S1 告警,告警量大幅下降。
4.2 跨站重建立原理:PCI 匹配与上下文索取
P02 版本支持无邻区的跨站重建立,原理是:目标小区通过终端上报的 PCI 查找该站点保存的有 X2 关系的邻站所有小区信息,向所有相同 PCI 小区索取上下文。
这个机制的价值在于,即使邻区关系配置不完整,只要 X2 链路存在,基站也能通过 PCI 匹配找到目标小区并索取 UE 上下文,避免因邻区漏配导致的重建立失败。X2 开启后,网格 44 统计 VoLTE 拉网发生重建立请求共 14 次,跨站重建成功 6 次;从性能指标统计来看,RRC 重建成功率从 50% 左右提升至 80% 左右。
4.3 X2 开启后的告警管理经验
X2 开启后的告警管理有一个注意点:X2 断链告警不等于业务故障,需要区分传输问题和配置问题。微站与宏站无法建链通常需要协调传输资源,闭塞小区导致的断链则需要检查小区状态。X2 告警抑制的价值在于让运维人员能从告警洪流中快速定位真正的故障类型,而不是被海量告警淹没。
提示:如果现网 X2 接口因为告警问题长期未开启,优先推动基站版本升级解决告警抑制能力,再开启 X2 接口。直接开启可能导致告警风暴,运维压力反而更大。
跨站重建立功能的查证建议看两个指标:RRC 重建请求次数和重建成功率。如果重建请求次数多但成功率低,可以检查 X2 链路质量和邻区 PCI 配置是否正确;如果重建请求次数本身很少,要考虑是不是终端在弱覆盖区域直接掉话,根本没机会发起重建。
5. 专载释放冲突排查:三个真实掉话场景与处理思路
专载释放与切换的冲突,是 VoLTE 掉话里最隐蔽的一类问题。表面上看是切换或挂机过程中掉话,实际原因是核心网和无线侧的交互时序出现了竞态条件。广州在这块踩了不少坑,三个场景的排查过程值得完整记录。
5.1 场景一:BYE 200 与切换冲突,MME 未收到 delete bearer request
现象是通话挂机后主叫上报 BYE 消息,IMS 回 BYE 200 消息前后,同时手机发生切换,未收到 EPS 专载释放请求,1s 后软件统计掉话。
分析 MME log 发现,MME 未收到 PGW 下发的 delete bearer request。当 X2 切换触发 SGW-initiated bearer modification procedure(完整信令是 CCR-CCA),此时 SIP 挂机触发 PCRF 也发 RAR 给 PGW。由于 Gx 链路时延等原因,RAR 先于 CCA 到达 PGW,根据协议规定,PGW 会继续 SGW-initiated bearer modification procedure 而 reject RAR(result code DIAMETER_OUT_OF_SPACE)。
解决办法有两步:一是缩短 DRA 时延配置,二是修改 SAPC 到 DRA 链路为主-备模式,保证 CCA 和 RAR 走同一路径,从而控制到达 PGW 的先后顺序。近期调整后的网格测试,暂时没有发现 BYE 200 消息前后发生切换没释放 QCI 1 专载的情况。
5.2 场景二:del bearer req 已到 MME,但 NAS 未下发
现象与场景一类似:通话挂机后主叫上报 BYE 消息,IMS 回 BYE 200 消息前后手机发生切换,EPS 专载没有释放,1s 后软件统计掉话。
区别在于这次 MME 收到了 del bearer req,也下发了 Deactivate EPS bearer context Request 给源 eNB 携带 NAS 释放专载,但同时源 eNB 触发 X2 切换,向 MME 响应 ERAB release response(X2-Handover-Triggered),NAS 消息未下发到手机。根据协议 36.413 中 8.6.2.4 的描述,当 eNB 在触发 X2 切换时,eNB 将不传递 NAS 消息。
这个问题严格来说不是网络故障,而是测试软件统计逻辑的问题——专载在核心网侧已释放,只是因为切换导致 NAS 消息没有到达终端。建议软件加以剔除该问题。这也是一个重要的经验:拉网测试的掉话统计不一定都是网络问题,软件判定逻辑可能把「网络已释放但终端未收到」的事件计入掉话。
5.3 场景三:呼叫建立与切换冲突,专载被 MME 释放
现象是呼叫建立与切换过程冲突,专载被 MME 释放。呼叫建立过程中专载建立与切换几乎同时发生,MME 未收到 NAS 专载完成消息导致释放专载。
这个场景的根因在 RLC 优先级配置:QCI 5 的 RLC 优先级高于 SRB=2,导致 NAS 层消息在资源竞争时排在 MR 和 SIP 之后,未及时发送到网络。优化措施是降低 QCI 5 优先级,确保 SIP 消息及时上传。对比场景一和场景二,这个案例是纯无线侧参数问题,参数调整后即可解决。
5.4 三类冲突的共性排查思路
专载释放与切换冲突的排查,建议先区分问题发生在哪个网元。看 MME log 确认是否收到 delete bearer request——没收到,查 PGW 和 DRA 之间的信令路径及时延;收到了但 NAS 没到终端,查 eNB 是否触发了 X2 切换,以及切换时 NAS 消息的处理逻辑是否符合协议。
| 场景 | 核心现象 | 根因位置 | 解决方向 |
|---|---|---|---|
| 场景一 | MME 未收到 del bearer req | PGW 信令时序 | 缩短 DRA 时延,SAPC-DRA 主备模式 |
| 场景二 | MME 收到但 NAS 未下发 | eNB 切换触发 | 测试软件剔除该类事件 |
| 场景三 | MME 未收到 NAS 专载完成 | RLC 优先级配置 | 降低 QCI 5 优先级 |
排查看信令时序是最靠谱的路径。把 BYE、BYE 200、切换请求、del bearer req 四条消息的时间戳对齐,基本能定位问题出在哪一段链路。另外,软件统计掉话和真实掉话要区分对待,有些事件是协议行为导致的终端感知异常,不一定是网络故障。
6. 2G 邻区拟合补漏:把 eSRVCC 成功率再压一截的落地脚本思路
最后说一个广州在系统间邻区优化上比较实用的做法:利用拉网测试数据做 4G 弱信号与 2G 强信号的经纬度拟合,自动补漏 GSM 邻区关系。这套思路对 eSRVCC 切换提升效果明显,而且因为 2G 邻区不准确导致的异系统重定向大大减少。
完整流程展开是这样的:
import csv from math import radians, cos, sin, asin, sqrt def haversine(lon1, lat1, lon2, lat2): # 经纬度转弧度 lon1, lat1, lon2, lat2 = map(radians, [lon1, lat1, lon2, lat2]) dlon = lon2 - lon1 dlat = lat2 - lat1 a = sin(dlat/2)**2 + cos(lat1) * cos(lat2) * sin(dlon/2)**2 return 2 * asin(sqrt(a)) * 6371 * 1000 # 返回米 def load_test_data(filepath): """加载拉网测试数据,包含经纬度、RSRP、服务小区和 RXLEV""" records = [] with open(filepath, 'r') as f: reader = csv.DictReader(f) for row in reader: records.append({ 'lon': float(row['longitude']), 'lat': float(row['latitude']), 'rsrp': float(row['rsrp']), 'cell': row['serving_cell'], 'rxlev': float(row.get('rxlev', -110)) }) return records def find_weak_lte(records, rsrp_threshold=-110): """筛选 4G 弱信号点:RSRP 低于阈值""" return [r for r in records if r['rsrp'] < rsrp_threshold] def match_2g_strong(weak_points, all_records, distance_threshold=50, rxlev_threshold=-95): """在 50 米范围内找 2G 强信号点,匹配服务小区""" matched = set() for wp in weak_points: for r in all_records: # 先过滤 2G 信号强度,再做距离计算 if r['rxlev'] < rxlev_threshold: continue dist = haversine(wp['lon'], wp['lat'], r['lon'], r['lat']) if dist < distance_threshold: # 记录 (4G小区, 2G小区) 对 matched.add((wp['cell'], r['cell'])) return matched # 第一轮拟合:剔除现网已配置邻区后补漏 483 对 weak_4g = find_weak_lte(test_data, -110) needed_pairs = match_2g_strong(weak_4g, test_data, 50, -95)这段脚本的核心逻辑是:先把拉网测试数据中 4G RSRP 低于 -110dBm 的点筛出来,再在 50 米范围内找 2G 信号强度 RXLEV 高于 -95dBm 的点,拟合出「4G 弱信号路段对应的 2G 服务小区」,剔除现网已配置的邻区关系后,剩下的就是需要补漏的 GSM 邻区。
几个参数要注意:RSRP 阈值 -110dBm 是 4G 弱覆盖的常用判定门限,RXLEV 阈值 -95dBm 是 2G 信号可用性的经验值,50 米是经纬度拟合的匹配半径。实际使用中这三个参数要根据当地网络质量微调——如果补漏后发现 eSRVCC 切换仍不理想,可以适当放宽 RXLEV 阈值到 -90dBm;如果补漏数量过大导致邻区关系冗余,可以收紧匹配半径到 30 米。
广州的实践结果是:5 月份第一轮拟合数据,剔除现网已配置的邻区关系后补漏 483 对;6 月份第二轮拟合数据补漏 487 对。eSRVCC 切换提升明显,且由于 2G 邻区不准确导致的异系统重定向大大减少。
值得一提的还有 eSRVCC 的另一个隐患:目前芯片在测量 GSM 邻区时延较长,存在 LTE 弱信号拖死掉话的较大概率。邻区补漏解决的是「有邻区可切」的问题,终端测量性能解决的是「测得够快」的问题,两者需要并行推进。
另外,MME 专载保存功能也值得关注——在基站发起 UE-lost 原因值的上下文释放请求时,MME 保持专载 2s 不释放,等待空口重建。广州在 GZMME1602 下成功验证了该功能,测试中专载保持时长约 1.358s。当无线环境较差时,UE 发生 RRC 重建,若重建成功手机将不会掉话;即使 RRC 重建失败,通过 MME 专载 QCI1 保持功能,新发起的业务过程中 RRC 重配也会建立包括专载 QCI1 在内的 DRB。不过这个功能是爱立信 MME 非必选功能,不在集采目录,想用还得先解决采购问题。
我自己的习惯是:每一次邻区优化都强制走一遍这套拟合流程,哪怕现网邻区关系看起来已经比较完整——因为路测数据里永远能翻出几对「理论上该配但实际漏了」的邻区。做 VoLTE 优化就是这样,掉话率越往低压,越要靠数据而不是感觉来发现问题。希望这份复盘里的版本升级路径、参数调整值和排查思路能帮你的网格少走几个弯路。
本文还有配套的精品资源,点击获取