好的,我们继续深入解读下一篇。
深度解析 3GPP TS 28.552:5.1.1.6 移动性管理 (Part 2 - 护航高铁上的商务精英:5GS与EPS间切换测量)
本文技术原理深度参考了3GPP TS 28.552 V18.10.0 (2025-03) Release 18规范中,关于“5.1.1.6.3 Handovers between 5GS and EPS”及相关章节,旨在为读者提供一个关于5G与4G网络间移动性管理的性能测量全景解析。
引言:京沪高铁上的“无感切换”挑战
商务精英李杰正坐在飞驰的京沪高铁“复兴号”上,进行一场至关重要的跨国视频会议。窗外,华北平原的风景一闪而过,列车时速稳定在350公里。对于李杰而言,他最关心的不是窗外的风景,而是笔记本电脑屏幕上,与海外客户共享的PPT是否流畅,自己的声音和画面是否清晰、无卡顿。
他注意到,手机信号图标在“5G”和“4G”之间悄然切换了几次,但整个会议过程,他没有感受到任何一次掉线或明显的延迟。他不禁感叹:“都说高铁上信号不好,今天的5G体验确实‘无感’。”
在千里之外的网络优化中心,老王正带着小林,实时监控着李杰所在的这条高铁线路的网络性能。“小林,看到了吗?李杰的‘无感’体验,背后是我们网络移动性管理的‘千锤百炼’。高铁场景,是移动性管理最严苛的‘考场’之一。它不仅速度快,而且会频繁穿越5G新建覆盖区和4G成熟覆盖区的边界。”
老王将TS 28.552的屏幕切换到5.1.1.6.3节。“上次我们学习了gNB内部和之间的切换,那是‘同系统内的转场’。今天,我们要挑战的是‘跨系统’的无缝衔接——5G系统(5GS)与4G系统(EPS)之间的切换。这一节,就是我们保障李杰这种跨系统、高速移动用户体验的‘最高行动纲领’。它定义了如何衡量每一次从5G到4G的‘优雅降级’和从4G到5G的‘无缝回归’。”
这篇文章,我们将化身为高铁网络保障工程师,通过护航李杰的这次关键会议,深入剖析3GPP是如何定义和测量5G-4G互操作性能的,揭示“无感切换”背后的技术细节与测量之道。
1. “优雅降级”:从5G到4G的切换测量 (5GS to EPS Handover)
列车驶出北京城区,进入了河北的乡村地带。这里的5G网络尚在建设中,覆盖不如4G网络连续。李杰的手机检测到5G信号(NR)减弱,而4G信号(E-UTRAN)依然强劲。为了保证视频会议不中断,他所在的5G基站(gNB)决定,是时候将他平稳地切换到隔壁的4G基站(eNB)上了。
这个过程,我们称之为5GS to EPS Handover (从5G系统到EPS的切换)。与gNB之间的切换类似,它也遵循着“准备-执行”的逻辑。
1.1 切换准备阶段:5G基站的“提前招呼” (5.1.1.6.3.1 - 5.1.1.6.3.3)
gNB在决定切换后,不能直接把用户“踢”出去,它必须先和4G网络那边打好招呼,确认对方有能力、有资源接收这个用户。
1.1.1 准备请求数: Number of requested preparations for handovers from 5GS to EPS (5.1.1.6.3.1)
a) This measurement provides the number of preparations requested by the source gNB for the outgoing handovers from 5GS to EPS.
c) Transmission of HANDOVER REQUIRED message containing the “Handover Type” IE set to “5GStoEPS” (see TS 38.413) by the gNB-CU to the AMF.
e) MM.HoOut5gsToEpsPrepReq.
-
深度解析:
MM.HoOut5gsToEpsPrepReq(Handover Outgoing 5GS to EPS Preparation Request) 是这个跨系统切换流程的“发令枪”。它的触发点是源gNB向核心网的AMF发送了一个HANDOVER REQUIRED消息,并且消息中有一个关键的“身份证”——Handover Type字段被设置为5GStoEPS。这个字段明确告诉AMF:“这不是一次普通的5G内部切换,这是一个要去4G的跨系统切换请求!”这个计数器记录了所有这类“出逃”到4G的切换尝试总数。 -
场景化举例:
09:10:25,高铁上的gNB检测到李杰的5G信号低于门限,决定向4G切换。它立刻向AMF发送了HANDOVER REQUIRED (Type=5GStoEPS)消息。gNB的MM.HoOut5gsToEpsPrepReq计数器加1。
1.1.2 准备成功数: Number of successful preparations for handovers from 5GS to EPS (5.1.1.6.3.2)
c) Receipt of HANDOVER COMMAND message by the gNB-CU from the AMF (see TS 38.413), for informing that the resources have been successfully prepared at the target E-Utran Cell for the handover from 5GS and EPS.
e) MM.HoOut5gsToEpsPrepSucc.
-
深度解析: AMF收到请求后,会与4G核心网的MME进行交互,MME再指令目标eNB准备资源。如果一切顺利,AMF会给源gNB回复一个
HANDOVER COMMAND消息。MM.HoOut5gsToEpsPrepSucc的触发点就是源gNB收到这个“司令部”发来的“批准令”。这表明4G那边已经为李杰准备好了“新家”,准备阶段成功。 -
场景化举例:
09:10:25.120,gNB收到了AMF发来的HANDOVER COMMAND。这意味着4G目标小区已经万事俱备。gNB的MM.HoOut5gsToEpsPrepSucc计数器加1,切换流程可以继续。
1.1.3 准备失败数: Number of failed preparations for handovers from 5GS to EPS (5.1.1.6.3.3)
c) Receipt of HANDOVER PREPARATION FAILURE message (see TS 38.413) by the gNB-CU from the AMF, for informing that the preparation of resources have been failed at the target E-Utran Cell…
e) MM.HoOut5gsToEpsPrepFail.cause.
- 深度解析:
如果4G侧因故(如目标小区拥塞)无法准备资源,AMF会给源gNB回复一个
HANDOVER PREPARATION FAILURE消息。MM.HoOut5gsToEpsPrepFail.cause就会根据消息中携带的失败原因进行分类计数。这对于排查5G-4G互操作的“边界问题”至关重要。
1.2 切换执行阶段:UE的“跨代跳跃” (5.1.1.6.3.7 - 5.1.1.6.3.9)
准备工作就绪,源gNB现在可以命令李杰的终端正式“跳槽”到4G网络了。
1.2.1 执行请求数: Number of requested executions for handovers from 5GS to EPS (5.1.1.6.3.7)
c) Transmission of MobilityFromNRCommand message to the UE triggering the handover from the source NR Cell to the target E-UTRAN cell… (see TS 38.331).
e) MM.HoOutExe5gsToEpsReq.
- 深度解析:
MM.HoOutExe5gsToEpsReq(Execution) 的触发点是源gNB向UE发送了MobilityFromNRCommand消息。这是RRC层的一个专用指令,明确告诉UE:“离开NR(5G),去指定的E-UTRAN(4G)小区报到!”
1.2.2 执行成功数: Number of successful executions for handovers from 5GS to EPS (5.1.1.6.3.8)
c) Receipt of UE CONTEXT RELEASE COMMAND message by the gNB-CU from AMF (see TS 38.413) following a successful handover from 5GS to EPS.
e) MM.HoOutExe5gsToEpsSucc.
- 深度解析:
与gNB间切换类似,成功与否的最终确认来自于
UE CONTEXT RELEASE COMMAND消息。当李杰的终端成功接入4G网络后,新的网络(通过MME和AMF)会通知原来的gNB:“人已安全交接,你可以清除他的上下文了。”源gNB收到这个指令,就标志着一次跨系统切换的圆满成功。MM.HoOutExe5gsToEpsSucc计数器加1。
1.2.3 执行失败数: Number of failed executions for handovers from 5GS to EPS (5.1.1.6.3.9)
c) Receipt of UE CONTEXT RELEASE COMMAND at the source gNB-CU from AMF (see TS 38.413) indicating an unsuccessful handover from 5GS to EPS.
e) MM.HoOutExe5gsToEpsFail.cause.
- 深度解析:
如果源gNB最终从AMF收到的
UE CONTEXT RELEASE COMMAND消息中,携带的原因是切换失败,那么MM.HoOutExe5gsToEpsFail.cause就会根据相应的原因码进行累加。这通常意味着UE在跳转过程中失联或在目标4G小区接入失败。
2. “无缝回归”:从4G到5G的切换测量 (EPS to 5GS Handover)
列车继续前行,接近下一个城市,连绵的5G信号再次出现。现在,网络需要将李杰从4G网络平滑地切换回更高质量的5G网络,以提供更佳的会议体验。这个过程称为EPS to 5GS Handover。
对于这个方向,TS 28.552的视角聚焦在了目标5G gNB的资源分配上。
5.1.1.6.3.4
Number of requested resource allocations for handovers from EPS to 5GS(MM.HoIncEpsTo5gsResAlloReq) 5.1.1.6.3.5Number of successful resource allocations for handovers from EPS to 5GS(MM.HoIncEpsTo5gsResAlloSucc) 5.1.1.6.3.6Number of failed resource allocations for handovers from EPS to 5GS(MM.HoIncEpsTo5gsResAlloFail.cause)
-
深度解析与场景应用: 这组测量的主体是目标gNB。
- 当gNB收到AMF发来的
HANDOVER REQUEST消息,且消息类型为EPSto5GS时,MM.HoIncEpsTo5gsResAlloReq(Incoming) 加1。这表示gNB被选为了一个从4G“回归”用户的目标。 - 如果gNB成功分配资源,并向AMF发送
HANDOVER REQUEST ACKNOWLEDGE,则MM.HoIncEpsTo5gsResAlloSucc加1。 - 如果gNB因资源不足等原因无法分配,并向AMF发送
HANDOVER FAILURE,则MM.HoIncEpsTo5gsResAlloFail.cause加1。
通过监控这组指标,老王和小林可以评估5G网络“接纳”4G切换用户的能力。如果
Fail计数很高,且主要原因是“无线资源不可用”,那就说明5G小区的切换准入门限可能设置得过于严格,或者是容量确实紧张,需要扩容。 - 当gNB收到AMF发来的
3. 紧急预案:EPS Fallback (EPS回落) 的特殊测量
“王哥,切换(Handover)和回落(Fallback)有什么区别?”小林提出了一个关键问题。
“好问题!”老王解释道,“Handover是‘有计划的搬家’,网络提前为你联系好新家,告诉你钥匙在哪,你直接过去就行,整个过程是网络控制的,力求无缝。而Fallback更像是‘紧急避险’,通常发生在5G特有业务(如VoNR语音通话)无法平滑切换到4G对应业务(VoLTE)的场景。此时,5G网络可能会选择一种更快、更简单的机制,让UE先回落到4G,再在4G网络上重新发起业务。这是一个由业务层驱动、以保障业务连续性为最高优先级的特殊移动性流程。”
TS 28.552也为这种特殊的EPS Fallback Handover定义了专门的测量项(5.1.1.6.3.10 - 5.1.1.6.3.16),包括准备、执行的成功/失败,以及平均/最大执行时间。
5.1.1.6.3.10 Number of requested preparations for EPS fallback handovers c) Transmission of HANDOVER REQUIRED message… after the source gNodeB sends the AMF a PDU Session modification response in which “PDUSessionResourceModifyUnsuccessfulTransfer” carries the failure cause “IMS voice EPS fallback or RAT fallback triggered”…
- 深度解析:
EPS Fallback的触发机制非常特殊。它不是由无线信号测量直接触发,而是当gNB尝试修改一个PDU会话以支持IMS语音,但发现无法满足要求时,它会向核心网上报一个失败,其中携带的原因是“IMS voice EPS fallback…triggered”。这个上报动作,之后再触发gNB向AMF发送
HANDOVER REQUIRED消息,这才被计为一个Fallback的准备请求。
通过监控这些Fallback相关的测量,特别是Mean Time of EPS fallback handover(回落平均耗时),运营商可以评估其语音解决方案的稳健性。
结论:异构网络漫游的“守护神”
李杰的视频会议顺利结束,他自始至终没有察觉到脚下的网络已经历了数次“跨代穿梭”。这背后,正是5G-4G互操作测量体系在发挥作用。
通过对5.1.1.6.3节的学习,我们掌握了5G网络保障移动连续性的又一重要武器:
- 双向切换监控: 通过对“5G→4G”和“4G→5G”两个方向的准备、分配、执行各环节的精细测量,确保了双向切换流程的可观测、可诊断。
- 失败原因定位: 无论是哪个阶段、哪个方向的失败,带有
cause码的子计数器都能为我们提供精准的故障定位线索。 - 区分Handover与Fallback: 规范为“计划切换”和“紧急回落”这两种不同的移动性机制定义了独立的测量项,使得运营商能分别评估其网络的无缝移动能力和业务连续性保障能力。
- 关注中断时间:
Mean/Max Time等时延相关测量,将性能指标与用户真实感知直接挂钩,驱动网络向更低时延、更“无感”的切换体验演进。
这套测量体系,是异构网络并存时代下,保障用户体验一致性的“守护神”。它确保了无论用户身处何方,无论是“升维”到5G还是“降维”到4G,其数字生活都能平稳、连续地进行。
FAQ 环节
Q1:5G和4G之间的切换,是否必须经过核心网的AMF/MME?N26接口是什么作用? A1:是的,5G-4G异系统切换必须通过核心网进行协调,因为两个系统的核心网架构和信令体系不同。N26接口是5G AMF和4G MME之间的一个可选接口。如果部署了N26接口,AMF和MME可以直接交换移动性管理和会话管理信息,使得切换流程更高效,能够保持IP地址不变,实现更无缝的体验。如果没有N26接口,切换就需要走“非N26接口流程”,通常会导致UE需要重新发起PDU会话建立,可能会造成业务的短暂中断。因此,N26接口的性能对互操作体验至关重要。
Q2:MM.HoOut5gsToEpsPrepFail(5G→4G准备失败)和MM.HoIncEpsTo5gsResAlloFail(4G→5G分配失败)哪个指标在网络优化初期更值得关注?
A2:在5G建设初期,MM.HoOut5gsToEpsPrepFail(5G→4G准备失败)通常更值得关注。因为这个阶段5G是“覆盖空岛”,用户频繁地从5G区域移动到4G区域。如果这个指标很高,意味着用户在离开5G覆盖区时会面临掉线风险,严重影响5G的初始用户体验。失败原因通常是4G网络侧配置问题(如未正确配置为5G的邻区)或4G侧资源紧张。
Q3:为什么规范要为“EPS Fallback”定义一套独立的测量,而不是将其计入普通的5G→4G切换? A3:因为它们的触发逻辑、优化目标和对用户的影响完全不同。普通切换是基于无线信号强度的“网络层”决策,优化目标是无缝移动性。EPS Fallback通常是基于特定业务(如VoNR)无法在5G上维持的“业务层”决策,优化目标是保障业务的连续性,哪怕会牺牲一些无缝性。将它们分开测量,可以让语音业务的优化专家和无线移动性的优化专家各取所需,专注于各自领域的性能评估和问题定位,避免数据混淆。
Q4:这些切换测量项中的cause(原因码)来自哪里?我们能自定义吗?
A4:cause码是由3GPP标准严格定义的,不能自定义。它们在相关的接口协议规范(如定义NGAP接口的TS 38.413)中有详细的枚举列表。例如,在HANDOVER PREPARATION FAILURE消息中,就明确定义了CauseRadioNetwork、CauseTransport等多种原因分类,每个分类下又包含更具体的原因值。标准化的原因码保证了不同厂商的设备在上报失败原因时使用统一的“语言”,使得端到端的故障诊断成为可能。
Q5:对于“智行一号”这样的uRLLC业务,在评估切换性能时,除了成功率,还应该关注哪个指标?
A5:对于uRLLC业务,切换中断时间是与成功率同等重要的核心指标。MM.HoExeInterReq.TimeMean.SNSSAI(平均执行时间)和MM.HoExeInterReq.TimeMax.SNSSAI(最大执行时间)变得至关重要。因为uRLLC业务(如自动驾驶、远程手术)对时延和可靠性要求极高,即使是一次几十毫秒的中断都可能导致严重后果。因此,优化工程师必须将这个专用切片下的切换中断时间(特别是最大值)严格控制在一个极低的水平(如10ms以内),才能满足业务的SLA要求。