5G优化案例给疏停核解决5G网络分流问题.docx
《5G优化案例给疏停核解决5G网络分流问题.docx》由会员分享，可在线阅读，更多相关《5G优化案例给疏停核解决5G网络分流问题.docx（23页珍藏版）》请在冰点文库上搜索。
5G优化案例给疏停核解决5G网络分流问题
“给、疏、停、核”解决NSA网络分流问题
【摘要】电信目前NSA主要使用3x组网方式，LTEeNB、5GgNB基站一个为主站、一个为辅站，通过X2接口互通，UE（用户终端）在连接态下可同时使用两个基站的无线资源。
用户数据流量既可以从5G向LTE分流，也可以从LTE向5G分流。
LTE-NRDC动态分流能较大的提升用户的数据吞吐率，在商用的早期，NR空口负载低，
通过DC动态分流，可以提供较好的用户体验。
本文通过首先介绍了3x组网下上下行分流的算法原理，并给出了动态分流的开通方法，同时针对本地网发现的上下行分流问题进行了分析归纳，给出了问题的跟因和解决方法，同时梳理出相应的四字总结建议-“给、疏、停、核”，作为分流问题的分析处理借鉴，有较大意义。
【关键字】动态分流、NSA、DC双连接
【业务类别】优化方法、问题定位、感知提升、经验推广
1NSADC动态分流基本概念
基于EPC（EvolvedPacketCore，演进型分组核心网）的NSA组网是具有NSA双连接能力的终端与LTE基站和NR基站连接（LTE-NRNSADC），利用两个基站的无线资源进行传输。
是5G早期的主流组网模式。
LTEeNodeB为主站MeNB，gNodeB为辅站SgNB，MeNB与SgNB之间通过X2口相连。
在3GPP标准中定义了Option3/3a/3x三种方式，电信主要采用Option3X组网。
Option3X架构中，数据分流锚点在gNodeB。
支持E-RAB数据全部通过gNodeB分流SCG（SecondaryCellGroup）Bearer，或者E-RAB同时分流到eNodeB上和gNodeB上承载即SCGSplitBearer。
在SgNB的PDCP进行分流，分别分往MeNB的RLC层和SgNB的RLC层，在UE侧的PDCP层进行聚合。
1）Option3X架构的下行动态分流
NR根据需要将用户面数据通过LTE和NR两侧发送给终端。
例如NR下行带宽接近瓶颈时，NR直接建立到LTE的用户面传输路径并将部分用户面数据通过LTE侧发送给终端，无须核心网参与。
Option3X结构的下行动态分流结构示意图
3）Option3X架构的上行动态分流
终端将用户面数据通过LTE和NR两侧上传给基站。
例如当终端缓存数据满足分流条件
时，终端将数据上传给NR和LTE，最终在NRPDCP层汇总并上传给核心网。
Option3X结构的上行动态分流结构示意图
下行分流与基站强相关，由基站根据分流算法来执行是否分流以及向两侧分流的比例。
上行分流算法与终端强相关，基站侧通过开关参数控制分流策略，具体分流算法由终
端侧自行决定，所以上行分流性能表现由终端主导。
2Option3X架构下行动态分流算法的原理
2.1SCG情况下PDCP下发数据包机制
PDCP按照PDU的粒度往RLC层发送数据包，PDCP层从上游接收数据包之后进行包头封装/加密等动作形成PDU数据包之后，就立即向RLC层发送。
不同SN的PDCPPDU数据包是串行发送到RLC层。
从时域上来说，每个PDCPPDU数据包在PDCP处理转发的时间是us粒度的，具体所需时间与CPU能力有关。
本质上在SCGonly场景，PDCP对于上游来的数据包是即来即发，
不会耽误PDU数据包的下发，最大化利用SCG空口能力。
SCGonly场景PDCP数据包发送机制
2.2动态分流情况下PDCP下发数据包机制
PDCP按照PDU的粒度往RLC层发送数据包，PDCP层从上游接收数据包之后进行包头封装/加密等动作形成PDU数据包之后，就立即向RLC层发送。
不同SN的PDCPPDU数据包是串行发送到RLC层。
在时域上，时间被分割为10ms粒度：
▪在10ms初期，PDCP根据NRRLC层的感知速率估算出10ms+单
向X2时延内NR可以发送的数据量（令牌）；
▪在10ms初期，PDCP接收LTERLC根据感知速率估算的未来10ms内发送的数据量（DBS）；
▪PDCP先给NRRLC分配对应令牌的数据包，直到令牌耗尽；
▪PDCP再根据NR和LTE的时延（X2口时延+RLC已有缓存待发送的时延之和）差值给时延小的一侧补齐对应时延影响的数据包，如果LTE侧为时延小的一侧，同时消耗LTEDBS；
▪PDCP再按照NR与LTERLC层感知速率比，按照次序给NR以及
LTERLC层分数据包，直到LTEDBS分配完成；（平均到1ms内给LTERLC发送的数据包速率不能高于参数设置的最高速率。
比如X2口限速最高100Mbps，则对应1ms内发送的数据包不能超过100Kbit；在此情况下，本ms内给NR分配的数据也受到限制）。
▪当远端令牌耗尽后，不再给RLC发送数据，直到10ms周期结束；
3Option3X架构上行动态分流算法的原理
3.1SCG情况下PDCP上传数据包机制
机制同下行SCG场景，具体实现由终端侧决定；
3.2动态分流情况下PDCP上传数据包机制
上行分流算法与终端强相关，基站侧通过开关参数控制分流策略，具体分流算法有终端侧自行决定，所以上行分流性能表现由终端主导。
海思分流策略是当终端PDCP层+RLC层缓存数据超过分流门限值，启动分流算法，进行上行分流。
4动态分流开通配置
4.1公共配置
//Step1:
NR侧修改相关定时器
//---先根据IMSI开户使用的QCI等级查询PdcpParamGroupId和RlcParamGroupId，然后再修改对应参数组的定时器。
以QCI9为例：
LSTNRCELLQCIBEARER:
NrCellId=63,Qci=9;//确定RLC模式为AM模式，且获取到
AmPdcpParamGroupId的值x
LSTNRDUCELLQCIBEARER:
NrCellId=63,Qci=9;//获取到AmRlcParamGroupId的值y
MODGNBPDCPPARAMGROUP:
PdcpParamGroupId=x,gNBPdcpReorderingTimer=MS300,UePdcpReorderingTimer=MS300;
MODGNBRLCPARAMGROUP:
RlcParamGroupId=y,RlcMode=AM,UeAmStatusRptProhibitTmr=MS20,UeRlcReassemblyTimer=MS40;
//Step2:
LTE侧修改相关定时器（注意只修改NSA的RLCPDCP参数组，不要影响LTE用户）
//---先根据QCI等级查询LTE侧使用的NsaDcRlcPdcpParamGroupId。
以QCI9为例：
LSTQCIPARA:
Qci=9;//获取到NsaDcRlcPdcpParamGroupId的值x
//---若LTE侧为非CA，则
MODRLCPDCPPARAGROUP:
RlcPdcpParaGroupId=x,CatType=LTE,RlcMode=RlcMode_AM,UeStatusProhibitTimer=Tstatprohibit_m15,UeAmReorderingTimer=Treordering_m15;
//---若LTE侧为CA，则
MODRLCPDCPPARAGROUP:
RlcPdcpParaGroupId=x,CatType=LTE,RlcMode=RlcMode_AM,CaUeRlcParaAdptiveThd=10,CaUeReorderingTimer=Treordering_m10,CaUeStatProhTimer=m10;
//Step3:
打开NR基站上SN偏置开关（小区级参数）。
对于定点峰值测试场景（如
speedtest等），建议关闭；对于移动拉网场景建议打开。
MODNRCELLRSVD:
NrCellId=57,RsvdParam0=2;//SN偏置开关，0和1表示打开，2表示关闭
//Step4:
设置X2分流限速门限
MODGNBRSVD:
RsvdParam10=1;//（0means100M,1meas200M,3meas400M）
4.2开通下行动态分流
MODGNBPDCPPARAMGROUP:
PdcpParamGroupId=5,DlDataPdcpSplitMode=SCG_AND_MCG;
4.3开通上行动态分流
//注意UlDataSplitThreshold在SRAN15.0版本的配置单位是bit，推荐值是12800bit；在SRAN15.1版本因协议变更其单位变为Byte，因此该参数推荐值变为1600Byte。
MODGNBPDCPPARAMGROUP:
PdcpParamGroupId=5,UlDataSplitPrimaryPath=SCG,UlDataSplitThreshold=1600;
5下行不分流定位分析
5.1下行分流流程
下行分流算法由基站侧控制，终端默认支持。
按照优先用满5G空口能力的原则，先给5G侧预留足量数据，在数据量有剩余的情况下再分流给LTE侧。
具体算法流程如下。
➢分流启动
满足如下条件后启动下行分流：
➢数据分配
●
基站侧打开分流模式开关（QCI级配置）
●RLC为AM/UM模式（QCI级配置）
●承载在SgNB侧建立完成
数据分配包括以下3个步骤：
Step1:
给SgNB分配数据
Step2:
补齐时延差
●
计算SgNBPDCP缓存量
●根据SgNBRLC上报的感知速率（通常由空口能力决定）计
算SgNBRLC桶令牌（即PDCP为RLC层预分配数据量）
●为SgNB分配数据直到SgNB桶令牌耗尽
●根据LTE和NR的RLC状态报告中的时延计算差值
●为时延小的那一侧多分数据，补齐时延差（通常NR侧时延小），以尽可能避免UEPDCP收包乱序
Step3:
给MeNB分配数据
➢停分流机制
●
根据MeNBRLC上报的感知速率（通常由空口能力决定）计算MeNB
桶令牌（预分配数据量）
●为MeNB和SgNB按速率比例分配数据直到MeNB桶令牌耗尽
在特殊场景下需要及时停止分流，以避免分流引入负增益。
典型场景如下：
●2s内收不到状态报告反馈
●连续200个统计周期内x2链路丢包率超过0.5%
●连续200个统计周期内两端速率比相差大于50倍
●超过UE的AMBR5.2下行分流问题识别
1、通过PROBE查看NR的PDCP层和RLC层有速率，LTE的RLC层和MAC层Throughput
速率几乎为0（小于1Mbps），识别为LTE未分流。
LTE未分流现象
2、通过PROBE查看NR的PDCP层和RLC层的Throughput达到峰值，且调度的RB和Grant均调度满；LTE的RLC层Throughput速率经常出现未达到峰值且调度的RB和Grant均未调度满的情况，识别为LTE分流未满。
LTE分流未满现象
5.3下行分流问题原因定位
通常上游来水不足的原因有三大类：
1）Ｘ2时延大导致多给NR分数据2）灌包服务
器发送数据不足3）空口误码，乱序等原因导致TCP发送窗口收缩导致。
5.3.1给-上游来水不足
CELLDT3208（PDCP层桶令牌打印）
如果ulMeNBToKen基本不为0，说明NR侧来水不足以耗尽近端令牌。
反之如果
ulMeNBToKen基本为0，说明NR侧来水充足，足以耗尽近端令牌（NR侧数据量充足）
来水充足，近端桶令牌基本都可以耗尽（大多数时间桶令牌为0）
来水不足，近端桶令牌耗不尽（桶令牌不为0）
解决方案：
1、查看X2时延：
见下一节X2时延大。
2、若为TCP业务，核查TCP层发送窗口是否限制速率，比如空口高误码，RLC
重传、RTT大时延等均会影响TCP发送窗口。
3、如果TCP层没有异常导致TCP发送窗口收缩，加大上游来水，例如多开灌包
窗口/线程。
5.3.2疏-X2时延大
在分流算法中补齐时延差需要考虑X2时延，因此需要保证X2的小时延防止数据大部
分发送给NR，导致LTE侧数据量少。
跟踪中分析ucRttDelay[S]参数如果不为0，将该值换算成2进制，并右移24位，得到的是X2环回时延，例如下图中ucRttDelay[S]参数为671088640，右移24位后为101000=40ms，单向时延为20ms。
解决方案
如果单向X2单向时延大于5ms，对X2时延进行优化。
否则会对下行分流性能有影响。
5.3.3停-触发了停分流机制
➢连续2s内收到状态报告反馈中的PDCP_SN没有增加并且MeNB不处于流控反压状态
分析思路：
1、RLC层分析是否收到PDCP层发送的数据包
2、如果收到，继续分析MAC层空口上下行是否有异常
3、继续分析RLC层为何不给PDCP层回复状态报告
➢低速保护机制（连续2s内NR与LTE速率比超过50倍）
分析日志，当ucLowRateStopSplitFlag值为1时表示触发了低速保护停分流机制，停分流60s。
低速保护现象
解决方案：
优化LTE侧速率或降低NR侧速率。
6上行不分流定位分析
6.1上行分流流程
上行分流算法完全由终端侧控制，具体算法取决于各厂商终端实现。
目前支持上行分流的商用终端类型少。
6.2上行分流问题原因定位
6.2.1核-终端不支持上行分流能力
1、终端上报的UE能力中如果携带UE-MRDC-Capability->splitDRB-withUL-MCG-SCG能力，表示终端支持上行分流。
2、如果UE能力中不携带该信元，表示终端不支持上行分流，则基站侧无论配置上行分流开启与否，在添加辅载波（SCG）时发送给终端的信令消息均为上行不分流（上行分流门限为无穷大，UlDataSplitThreshold=INFINITY;）
6.2.2核-基站未给终端下发上行分流配置
1、NR基站侧需要配置2个关键参数GNBPDCPPARAMGROUP：
UlDataSplitPrimaryPath=SCG,UlDataSplitThreshold=BYTE51200;
2、在终端初始接入NR时，建立5G承载；SCGAddtionReqACK消息和之后eNB会发送RRCReconfig消息给终端这两条消息中会携带上行分流路径PrimaryPath（1=SCG，0=MCG）和上行分流门限（ul-DataSplitThreshold）。
在终端进行SgNB切换时，SgNB_Mod_REQ_ACK/SGNB_MOD_REQUIRED/SGNB_CHANGE_REQUIRED消息中也会携带目标站点的上行分流参数。
上行分流参数相关信令
上行分流相关信元（PrimaryPath.cellGroup和ul-DataSplitThreshold）
3、终端会依据自身的上行分流算法按照基站下发的上行分流配置进行上行分流。
解决方案：
详细核查参数配置。
7案例分析
7.1来水量不足问题
【问题描述】：
使用PROBE进行TCP下载业务时发现LTE未分流。
如下图，LTE侧无速率，NR侧速率较低，
且NR侧下行grant不满（792/1600）。
Probe中NR和LTE速率低现象
【问题分析】：
分析日志发现NR侧令牌数全程基本未耗尽，因此不会给LTE分数据。
跟踪近端桶令牌
由于NR侧令牌未耗尽，因此没有数据供LTE侧消耗令牌数，导致LTE侧桶令牌无法耗尽。
说明上游来水不足导致NR侧速率较低且LTE侧无速率。
跟踪远端桶令牌
【解决建议】：
在增大来水量后，测试结果正常，问题解决。
7.2X2时延大问题
【问题描述】：
测速时，LTEOnly的时候速率很高，DC的时候速率低。
在办公室复测发现DC分流下LTE的速率很低，而LTEOnly的时候测到的LTE速率明显高很多，如下图。
终端侧NR和LTE速率情况
【问题分析】：
跟踪中分析ucRttDelay[S]参数换算成2进制，并右移24位，得到的是X2环回时延为101000=40ms，单向时延为20ms。
跟踪X2时延
下图为NR和LTE侧RLC缓存时延大小。
根据分流算法，先给NR侧分（10ms+X2单向时延）的数据量，之后才会给LTE侧分数据，下图中当NR缓存时延超过30ms时才会给LTE分数据，与算法机制吻合。
跟踪RLC缓存时延
【解决建议】：
由于X2时延过大导致来水量不足以分给LTE，优化X2时延后问题解决。
7.3触发停分流机制问题—低速停分流保护机制
【问题描述】：
Mate20X终端，PROBE下TCP测试下行分流。
NR带宽100M，LTE带宽15M。
TCP测试
发现偶尔有不分流现象（LTERLC速率为0），停分流时间为60s的整数倍。
Probe低速保护停分流现象
（1）
Probe低速保护停分流现象
（2）
【问题分析】：
查看日志，ucLowRateStopSplitFlag参数为1，说明触发了低速保护停分流机制。
低速保护停分流现象
找到对应TTI前2s时间段，查看LTE和NR感知速率情况，判断NR是否是LTE的50倍
以上。
NR和LTERLC感知速率
【解决建议】：
停分流之前的2s内NR/LTE的RLC感知速率比大于50倍，主要因为LTERLC感知速率太低（1.08Mbps）。
因为LTE带宽只有15M，且LTE为现网存量用户，导致LTE侧速率太低，触发了低速停分流保护机制，60s后恢复分流。
在LTE用户较少时进行测试问题解决。
7.4触发停分流机制问题—X2丢包率超过千分之5
【问题描述】：
基站19B版本下，PROBE测试下行TCP分流业务，发现LTE无速率，NR速率300Mbps，LTE
不分流，IPPM查看X2时延小于1ms。
【问题分析】：
分析日志发现ucSplitMack值为32，表示连续2s内X2丢包率超过千分之5，触发停分流机制。
跟踪停分流原因值
分析发现X2丢包率在百分之20以上（[W]=[U]/[N]）。
X2丢包情况
【解决建议】：
核查发现gNB和eNB之间有防火墙，改造X2链接将防火墙绕开后，丢包率恢复，可
以正常分流。
8经验总结与推广
NR下行覆盖不受限，而且在NSA商用的早期，NR空口负载低，可以提供较高的用户体验，可逐步推广下行分流；上行分流性能强依赖于终端的分流算法（非协议定义），因此不建议大规模开通上行分流。
针对本地网发现的上下行分流问题进行了分析归纳，给出了问题的种类和跟因，同时梳理出相应的解决方法，作为问题处理树如下，指导类似问题的解决。
升级会员 