精品文档5G SA语音EPS FB问题优化分析研究.docx
《精品文档5G SA语音EPS FB问题优化分析研究.docx》由会员分享,可在线阅读,更多相关《精品文档5G SA语音EPS FB问题优化分析研究.docx(40页珍藏版)》请在冰豆网上搜索。
精品文档5GSA语音EPSFB问题优化分析研究
5GSA语音EPSFB问题优化分析研究
5GSA语音EPSFB问题优化分析研究
【摘要】5GSA实验网的建设,除了5GSA的数据业务打通,5G的语音业务也是5G的标杆业务,5GSA语音打通,是5GSA网络建设的里程碑。
选择EPSFallback作为5GSA的语音方案,是因为考虑到目前5GSA建网初期,5G信号覆盖还处于初期阶段,没有大规模的覆盖,而4G的覆盖已经进入成熟期。
EPSFallback是指当用户需要使用语音服务时,5G用户从5G网络“切换”或者“重定向”到4G网络,通过4G网络使用VOLTE语音服务。
【关键字】EPSFallback邻区
【业务类别】参数优化
一、问题描述
安徽滁州地市进行5GSA语音端到端测试,发现有一定的掉话率。
现场使用华为5GNR基站和中兴ENODEB基站,4/5G核心网为中兴。
安徽滁州电信进行5GSA网络建设,除了5GSA的数据业务打通,5G的语音业务也是5G的标杆业务,5GSA语音打通,是5GSA网络建设的里程碑。
二、分析过程
2.1EPSFB方案及原理
2.1.1原理说明
选择EPSFallback作为5GSA的语音方案,是因为考虑到目前5GSA建网初期,5G信号覆盖还处于初期阶段,没有大规模的覆盖,而4G的覆盖已经进入成熟期。
Fallback是指当用户需要使用语音服务时,5G用户从5G网络“切换”或者“重定向”到4G网络,通过4G网络使用VOLTE语音服务。
EPSFallback主要是基于MME和AMF间的N26接口完成4/5G间信令交互。
2.1.2方案说明
EPSFB方案:
使用现网传统平台的SGW作为SGW-C和SGW-U的方案,此方案优点是布署快,在建网初期,可以直接利用现网设备,不要考虑SMF调试,以及SMF版本成熟度的问题。
目前现网方案。
2.1.3EPSFallback原理介绍
5G部署初期,由于网络覆盖不全等原因,5G语音业务会EPSFallback回4G通过VOLTE进行。
EPSFallback分为两种,一种是EPSFallback切换,一种是EPSFallback重定向,其主要流程如下:
1.UE注册到5G,建立IMSPDUsession,并注册IMS成功;
2.UE主叫或被叫场景下,SBC向PCF发送AAR消息。
PCF响应AAA消息触发建专用QoSFlow的流程。
3.PCF向SMF发送Npcf_SMPolicyControl_UpdateNotifyrequest消息通知AMF创建语音专有QosFlow。
SMF响应Npcf_SMPolicyControl_UpdateNotifyresponse消息。
4.SMF向AMF发送Namf_Communication_N1N2MessageTransfer,消息中携带SM相关信息。
AMF响应Namf_Communication_N1N2MessageTransferresponse消息;
5.AMF向NG-RAN发送N2sessionrequest消息,通知NG-RAN建立语音QOSflow资源,NG-RAN拒绝语音QOSflow,响应N2Sessionresponse消息,并携带IMSvoiceEPSfallbackorRATfallbacktriggered原因值。
6.AMF向SMF发送Nsmf_PDUSession_UpdateSMContextrequest携带IMSvoiceEPSfallbackorRATfallbacktriggered原因值。
SMF响应Nsmf_PDUSession_UpdateSMContextresponse消息。
7.NG-RAN发起5GStoEPSHO流程或者重定向TAU流程。
8.切换或重定向流程完成后(备注:
HO流程后也会伴随有TAU流程),SMF向MME发送CreatebearerRequest消息创建语音专载;
9.MME收到CreatebearerRequest消息后向eNB发送ActivateDedicateEPSBearerContextRequest消息创建语音专载;
10.语音专载创建成功后,流程结束;
2.2EPSFB流程
2.2.1基于切换的EPSFB
基于切换方式到4G,需要无线网优侧配置4G和5G间的邻区,否则无法进行切换。
2.2.2基于重定向的EPSFB
即通过TAU重定向到4G的方式。
2.3EPSFBDNS数据
因为EPSFB是基于5/4G间的切换或重定向流程实现的,那么DNS解析数据就很关键,主要涉及的DNS数据如下:
2.3.14G往5G切换时需要的DNS记录
使用解析记录的网元
MME
解析的目的
当用户想向5G切换时,通过源4G基站将目标5G基站的TAC码上报给MME,然后MME根据基站上报的5GTAC,向DNS查询得到一个可供切换的AMF,选定后,用户将向此AMF切换数据。
查询的FQDN(5GTAC域名)
TAC-LB01.TAC-MB00.TAC-HB77.5GSTAC.5GC.MNC011.MCC460.3GPPNETWORK.ORG(基于5G基站的TAC码组装的域名)
期望得到的解析记录
amfri44.amf.5gc.mnc011.mcc460.3gppnetwork.org(AMF的主机名)
最终结果
AMF的N26IP地址
2.3.25G到4G重选时需要的DNS记录(即TAU方式到4G)
使用解析记录的网元
MME
解析的目的
当用户直接从5G脱离,直接采用TAU的方式到达目标4G基站,用户上报GUMI标识给MME,MME根据此GUMI标识查询DNS,得到此用户原先所在的AMF地址,然后向AMF获取用户原先的上下文信息,以便在MME侧快速回复用户的业务。
查询的FQDN(AMF域名)
MMEGI4405.MME.EPC.MNC011.MCC460.3GPPNETWORK.ORG(基于用户的5GGUMI标识组装的域名)
期望得到的解析记录
amfri44.amf.5gc.mnc011.mcc460.3gppnetwork.org(AMF的主机名)
最终结果
AMF的N26地址
2.3.35G往4G切换时需要的DNS记录
使用解析记录的网元
AMF
解析的目的
当用户想向4G切换时,通过源5G基站将目标4G基站的TAC码上报给AMF,然后AMF根据基站上报的4GTAC,向DNS查询得到一个可供切换的MME,选定后,用户将向此MME切换数据。
查询的FQDN(4GTAC域名)
tac-lbD2.tac-hb25.tac.epc.mnc011.mcc460.3gppnetwork.org(基于4G基站的TAC码组装的域名)
期望得到的解析记录
topon.s10.mmec01.mmegi4401.mme.epc.mnc011.mcc460.3gppnetwork.org.(MME的主机名)
最终结果
MME的N26IP地址
2.3.44G到5G重选时需要的DNS记录(即TAU方式到5G)
使用解析记录的网元
AMF
解析的目的
当用户直接从4G脱离,直接采用TAU的方式到达目标5G基站,用户上报GUTI标识给AMF,AMF根据此GUTI标识查询DNS,得到此用户原先所在的MME地址,然后向MME获取用户原先的上下文信息,以便在AMF侧快速回复用户的业务。
查询的FQDN(MME域名)
mmec01.mmegi4401.mme.epc.mnc011.mcc460.3gppnetwork.org(基于用户的4GGUTI标识组装的域名)
期望得到的解析记录
topon.s10.mmec01.mmegi4401.mme.epc.mnc011.mcc460.3gppnetwork.org.(MME的主机名)
最终结果
MME的N26地址
2.4EPSFB信令分析
2.4.1MME信令
2.4.2AMF信令
2.4.3SMF信令
2.5FASTRETURN信令分析
2.5.1AMF信令
2.5.2SMF信令
2.6EPSFB呼叫建立异常分析方法
2.6.1无B1测控下发分析
2.6.1.1UE不支持B事件
判断方法-UE(Probe&Assistant):
前场测试信令在UE能力"UECapabilityInformation"中确认是否支持EventB测量?
不支持,则网络侧不会下B1测控
解决方案:
联系UE厂商进行排查和解决
2.6.1.2EPSFB功能开关是否开启
判断方法及应对-基站:
当EPSFB开关配置不正确/无License时,在5QI1对应的PDUSESSIONRSRCMODIFYRSP中将会携带原因值not-supported-5QI-value。
解决方案:
按照现网基线配置EPSFB相关配置开关和门限
1、打开EPSFB开关(示例基于切换)
MODNRCELLALGOSWITCH:
NrCellId=xx,VoiceStrategySwitch=EPS_FB_SWITCH-1,InterRatServiceMobilitySw=MOBILITY_TO_EUTRAN_SW-1;
2、配置NR切换策略组(请确认已经配置LTE邻频点邻区,请注意groupid的对应关系)
MODNRINTERRATHOPARAM:
NRCELLID=xx,EPSFBPROTECTIONTIMER=20,EPSFBMODE=HANDOVER;
ADD/MODNRCELLHOEUTRANMEAGRP:
NrCellId=xx,InterRHoToEutranMeasGrpId=2,EpsFbB1RsrpThld=-111,EpsFbB1Hyst=2,EpsFbB1TimeToTrig=320MS;
MODNRCELLQCIBEARER:
NrCellId=xx,Qci=1,InterRHoToEutranMeasGrpId=2;
2.6.1.3是否配置了LTE邻频点
判断方法及应对-基站:
NR侧配置LTE邻频点
ADDNRCELLEUTRANNFREQ:
NrCellId=xx,DlEarfcn=1300,MeasurementBandwidth=xx;
ADDNRCELLEUTRANNFREQ:
NrCellId=xx,DlEarfcn=38400,MeasurementBandwidth=xx;
ADDNRCELLEUTRANNFREQ:
NrCellId=xx,DlEarfcn=38950,MeasurementBandwidth=xx;
解决方案:
按照现网基线配置NR2L相关的邻频点信息,如果现网有多个LTE频点邻区,配置时注意频点优先。
MODNRCELLEUTRANNFREQ:
NrCellId=xx,DlEarfcn=1300,FreqSpecificOffset=DB0,ConnFreqPriority=5;
MODNRCELLEUTRANNFREQ:
NrCellId=xx,DlEarfcn=38400,FreqSpecificOffset=DB0,ConnFreqPriority=4;
MODNRCELLEUTRANNFREQ:
NrCellId=xx,DlEarfcn=38950,FreqSpecificOffset=DB0,ConnFreqPriority=3;
2.6.2未收到B1测量报告
2.6.2.1UE是否接收到了B1测量控制
判断方法-UE(Probe&Assistant):
UE侧确认在发起EPSFB呼叫(事件:
VoNRCallAttempt)后,是否收到B1测控:
判断方法及应对-基站:
网络侧确认配置的B1门限是否符合基线:
(如果配置过高,可能会导致LTE信号不满足门限,UE测量不到合适的LTE小区)
EPSFBB1门限配置MML命令举例:
ADD/MODNRCELLHOEUTRANMEAGRP:
NrCellId=xx,InterRHoToEutranMeasGrpId=2,EpsFbB1RsrpThld=-111,EpsFbB1Hyst=2,EpsFbB1TimeToTrig=320MS;
解决方案:
按照现网基线配置EPSFB相关配置开关和门限
2.6.2.2UE是否上报了B1测量报告
判断方法-UE(Probe&Assistant):
UE是否已上报B1测量报告:
如下举例中上报LTEPCI为322/138/420小区的测量结果。
解决方案:
如果UE已发送B1测量报告,但网络侧没有收到,需重点排查上行干扰情况。
2.6.3网络侧收到了B1测量报告,但未执行EPSFB回落动作(切换或重定向)
2.6.3.1网络侧是否收到了B1测量报告
判断方法及应对-基站:
网络侧是否收到的B1测量报告,虚用户跟踪收到EPSFB的B1测量报告举例如下:
解决方案:
如果UE已发送B1测量报告,但网络侧没有收到,需重点排查上行干扰情况。
2.6.3.2是否邻区配置异常,导致EPSFB执行动作(切换或重定向)不下发
判断方法及应对-基站:
如果B1测量报告中的PCI,未在NR2L的邻区关系中配置,或存在同频同PCI的情况,则会触发重定向(即使配置了切换)。
NR侧配置LTE外部邻区(NR侧建议只需要配置规划的8个LTE邻频点的邻区)
ADDGNBEUTRAEXTERNALCELL:
Mcc="xx",Mnc="xx",EnodebId=xx,CellId=xx,DlEarfcn=xx,PhysicalCellId=xx,Tac=xx;
NR侧配置LTE邻区
ADDNRCELLEUTRANRELATION:
NrCellId=xx,Mcc="xx",Mnc="xx",EnodebId=xx,CellId=xx;
解决方案:
确认UE上报的LTEPCI小区,是否已添加到了NR2L的邻区关系中;
如果NR2L邻区关系中,有同频同PCI的冲突场景,需调整邻区关系,去除同频同PCI场景。
2.6.3.3NR是否发送了切换请求
判断方法及应对-基站:
gNB发送切换请求给AMF,类型为“fivegs-to-eps”
解决方案:
eNB是否收到来自MME侧的切换请求,类型为“fivegs-to-eps”
2.6.3.4是否存在切换准备失败场景
判断方法及应对-基站:
LTE侧信令,AMF回复切换准备失败“NGAP_HO_PREP_FAIL",如原因值为“ho-failure-in-target-5GC-ngran-node-or-target-system”
解决方案:
切换准备失败场景,优先联系核心网AMF侧分析。
(以及排查N26接口是否正常)。
2.6.4EPSFB动作已下发,但LTE侧接入失败
2.6.4.1EPSFB动作(切换或重定向)是否下发
判断方法-UE(Probe&Assistant):
UE侧是否收到了EPSFB命令(L3:
"MobilityFromNRCommand"),如下切换方式的举例:
判断方法-UE(Probe&Assistant):
UE侧是否收到了EPSFB命令(L3:
"RRCRelease",并携带频点信息),如下为重定向方式的举例:
判断方法及应对-基站:
NR侧是否下发了EPSFB命令("UUAP_RRC_MOBIL_FROM_NR_CMD"),为切换方式举例:
判断方法及应对-基站:
NR侧是否下发了EPSFB命令("UUAP_RRC_REL"),为重定向方式举例:
解决方案:
网络侧下发,但UE没有收到,需重点排查下行空口质量是否存在弱覆盖,干扰的等情况。
2.6.4.2EPSFB是否执行成功
判断方法-UE(Probe&Assistant):
确认EPSFB的切换或重定向是否成功:
切换成功和重定向成功对应的事件分别为“NR2LTEHOSuc”和“NR2LTERedirectionSuc"
判断方法及应对-基站:
查看LTE网络的跟踪,基于切换方式的EPSFB,会看到“S1AP_HANDOVER_REQ"、“S1AP_HANDOVER_REQ_ACK"和"RRC_CONN_RECFG_CMP"消息,分别对应的5to4在S1口的切换请求和应答,以及空口的切换完成消息"RRC_CONN_RECFG_CMP",LTE在收到该消息后,会发送"S1AP_HANDOVER_NOTIFY"消息给MME,表示切换已完成。
解决方案:
如果存在EPSFB切换执行失败,在排查下邻区配置是否正确,是否存在外部小区定义错误导致,B1测量报告上报的PCI和切换小区不一致的问题。
2.6.4.3TAU是否完成
判断方法-UE(Probe&Assistant):
回落LTE后,TAU是否完成,L3消息:
"TrackingAreaUpdateComplete"
解决方案:
如果UE已发送了TrackingAreaUpdateRequest,但没有收到TrackingAreaUpdateAccept消息,重点联系MME侧分析,如果收到TrackingAreaUpdateAccept后,UE没有发送TrackingAreaUpdateComplete消息,则需联系UE分析。
2.6.4.3语音QCI1专用承载是否建立完成
判断方法-UE(Probe&Assistant):
QCI1专有承载是否建立完成,可在事件列表中,查看“ERABEstablishSuch(QCI=1)"事件
判断方法及应对-基站:
在eNB侧,确认是QCI1已建立完成
解决方案:
如果UE侧没有看到QCI1建立消息,则查看网络侧是否有,没有则联系MME侧分析确认。
2.7FastReturn异常分析方法
2.7.1QCI1释放后B1测控未下发
2.7.1.1FR事件启动判决方法-UE(Probe&Assistant)
判断方法-UE(Probe&Assistant):
FastReturn以语音释放为始,对应的PA事件为"ERABNormalRelease(QCI=1)",查看QCI1承载释放后是否有B1测控下发"LTEEventB1MeasConfig",PA事件为LTE2NRFastReturnBegin”
2.7.1.2确认UE是否支持现网的NR频段能力
判断方法-UE(Probe&Assistant):
从L3信令的UECapabilityInformation中,从字段“supportBandListNR-SA-r15"中,确认UE是否现网配置的NR频段,如果不支持,则不会下发B1。
判断方法及应对-基站:
网络侧排查方法一致,查看UE上报的能力(RRC_UE_CAP_INFO)中NR的支持能力。
2.7.1.3FastReturn功能开关是否开启
判断方法及应对-基站:
排查LTE配置,确认FastReturn功能是否开启,以及FastReturn的方式是切换还是重定向。
FastReturn功能开关:
MODCELLALGOEXTSWITCH:
LocalCellId=xx,HoAllowedSwitch=INTER_RAT_MOBILITY_TO_NR_SW-1;
MODCELLALGOEXTSWITCH:
LocalCellId=xx,HoAllowedSwitch=FAST_RETURN_TO_NR_SW-1;
MODCELLHOPARACFG:
LOCALCELLID=xx,HOMODESWITCH=NrRedirectSwitch-1&NrHoSwitch-0
2.7.1.4L2NR邻频点、邻区是否配置
判断方法及应对-基站:
如果L2NR的频点、外部邻区、邻区关系中任何一项没有配置,则网络侧不会下发B1测控。
核查LTE2NR的邻区配置:
LTE侧配置NR邻频点(LTE侧所有频点都需要配置5G的邻区邻频点):
ADDNRNFREQ:
LocalCellId=xx,DlArfcn=xxx(NR下行SSB频点),UlArfcnConfigInd=NOT_CFG,SsbOffset=xxx;
LTE侧配置NR外部邻区:
ADDNREXTERNALCELL:
Mcc="xx",Mnc="xx",GnodebId=xx,CellId=xx,DlArfcn=xx,UlArfcnConfigInd=NOT_CFG,PhyCellId=xx,Tac=xx;
LTE侧配置NR邻区:
ADDNRNRELATIONSHIP:
LocalCellId=xx,Mcc="xx",Mnc="xx",GnodebId=xx,CellId=xx;
2.7.1.5QCI级切换策略核查
判断方法及应对-基站:
QCI级切换策略核查,Fastreturn时,注意发起fastreturn时UE所携带的QCI切换属性中必须携带MUSTHO的QCI,且不能携带NOHO的QCI。
核查LTE侧,QCI级的切换策略是否OK:
ADD/MODSERVICEIRHOCFGGROUP:
CnOperatorId=xx,ServiceIrHoCfgGroupId=2,InterRatHoState=MUST_HO;
ADD/MODSERVICEIRHOCFGGROUP:
CnOperatorId=xx,ServiceIrHoCfgGroupId=1,InterRatHoState=PERMIT_HO;
ADD/MODSERVICEIRHOCFGGROUP:
CnOperatorId=xx,ServiceIrHoCfgGroupId=0,InterRatHoState=NO_HO;
ADD/MODCNOPERATORQCIPARA:
CnOperatorId=xx,Qci=9,ServiceIrHoCfgGroupId=2;(数据业务mustho,语音业务noho)
ADD/MODCNOPERATORQCIPARA:
CnOperatorId=xx,Qci=8,ServiceIrHoCfgGroupId=2;(数据业务mustho,语音业务noho)
ADD/MODCNOPERATORQCIPARA:
CnOperatorId=xx,Qci=7,ServiceIrHoCfgGroupId=2;(数据业务mustho,语音业务noho)
ADD/MODCNOPERATORQCIPARA:
CnOperatorId=xx,Qci=6,ServiceIrHoCfgGroupId=2;(数据业务mustho,语音业务noho)
ADD/MODCNOPERATORQCIPARA:
CnOperatorId=xx,Qci=5,ServiceIrHoCfgGroupId=2;(数据业务mustho,语音业务noho)
ADD/MODCNOPERATORQCIPARA:
CnOperatorId=x