1、例如当终端缓存数据满足分流条件时，终端将数据上传给 NR 和LTE，最终在 NR PDCP 层汇总并上传给核心网。Option3X 结构的上行动态分流结构示意图下行分流与基站强相关，由基站根据分流算法来执行是否分流以及向两侧分流的比例。上行分流算法与终端强相关，基站侧通过开关参数控制分流策略，具体分流算法由终端侧自行决定，所以上行分流性能表现由终端主导。2Option3X 架构下行动态分流算法的原理2.1SCG 情况下 PDCP 下发数据包机制PDCP 按照 PDU 的粒度往 RLC 层发送数据包，PDCP 层从上游接收数据包之后进行包头封装/加密等动作形成 PDU 数据包之后，就立即向 RL
2、C 层发送。不同 SN 的 PDCP PDU 数据包是串行发送到 RLC 层。从时域上来说，每个 PDCP PDU 数据包在 PDCP 处理转发的时间是us 粒度的，具体所需时间与 CPU 能力有关。本质上在 SCG only 场景，PDCP 对于上游来的数据包是即来即发，不会耽误 PDU 数据包的下发，最大化利用 SCG 空口能力。SCG only 场景 PDCP 数据包发送机制2.2动态分流情况下 PDCP 下发数据包机制在时域上，时间被分割为 10ms 粒度：在 10ms 初期，PDCP 根据 NR RLC 层的感知速率估算出 10ms+单向 X2 时延内 NR 可以发送的数据量（令牌）
3、；在 10ms 初期， PDCP 接收 LTE RLC 根据感知速率估算的未来10ms 内发送的数据量（DBS）；PDCP 先给 NR RLC 分配对应令牌的数据包，直到令牌耗尽；PDCP 再根据 NR 和 LTE 的时延（X2 口时延+RLC 已有缓存待发送 的时延之和）差值给时延小的一侧补齐对应时延影响的数据包， 如果 LTE 侧为时延小的一侧，同时消耗 LTE DBS；PDCP 再按照 NR 与 LTE RLC 层感知速率比，按照次序给 NR 以及LTE RLC 层分数据包，直到 LTE DBS 分配完成；（平均到 1ms 内给 LTE RLC 发送的数据包速率不能高于参数设置的最高速率
4、。比如 X2 口限速最高 100Mbps，则对应 1ms 内发送的数据包不能超过 100Kbit；在此情况下，本 ms 内给 NR 分配的数据也受到限制）。当远端令牌耗尽后，不再给 RLC 发送数据，直到 10ms 周期结束；3Option3X 架构上行动态分流算法的原理3.1SCG 情况下 PDCP 上传数据包机制机制同下行 SCG 场景，具体实现由终端侧决定；3.2动态分流情况下 PDCP 上传数据包机制上行分流算法与终端强相关，基站侧通过开关参数控制分流策略，具体分流算法有终端侧自行决定，所以上行分流性能表现由终端主导。海思分流策略是当终端PDCP 层+RLC 层缓存数据超过分流门限值，
5、启动分流算法，进行上行分流。4动态分流开通配置4.1公共配置/ Step1 : NR 侧修改相关定时器/ -先根据IMSI 开户使用的 QCI 等级查询 PdcpParamGroupId 和 RlcParamGroupId，然后再修改对应参数组的定时器。以 QCI9 为例：LST NRCELLQCIBEARER: NrCellId=63, Qci=9; / 确 定 RLC 模 式 为 AM 模 式 ， 且 获 取 到AmPdcpParamGroupId 的值xLST NRDUCELLQCIBEARER: /获取到 AmRlcParamGroupId 的值yMOD GNBPDCPPARAMGRO
6、UP: PdcpParamGroupId=x, gNBPdcpReorderingTimer=MS300, UePdcpReorderingTimer=MS300;MOD GNBRLCPARAMGROUP: RlcParamGroupId=y, RlcMode=AM, UeAmStatusRptProhibitTmr=MS20, UeRlcReassemblyTimer=MS40;/ Step2 : LTE 侧修改相关定时器（注意只修改 NSA 的 RLCPDCP 参数组，不要影响 LTE 用户）/ -先根据QCI 等级查询 LTE 侧使用的 NsaDcRlcPdcpParamGroupId。
7、 LST QCIPARA: Qci=9; /获取到 NsaDcRlcPdcpParamGroupId 的值x/ -若LTE 侧为非 CA，则MOD RLCPDCPPARAGROUP: RlcPdcpParaGroupId=x, CatType=LTE, RlcMode=RlcMode_AM, UeStatusProhibitTimer=Tstatprohibit_m15, UeAmReorderingTimer=Treordering_m15;/ -若LTE 侧为 CA，则 RlcPdcpParaGroupId=x, CatType=LTE, RlcMode=RlcMode_AM, CaUeR
8、lcParaAdptiveThd=10, CaUeReorderingTimer=Treordering_m10, CaUeStatProhTimer=m10;/ Step3 : 打开 NR 基站上 SN 偏置开关（ 小区级参数）。对于定点峰值测试场景（ 如speedtest 等），建议关闭；对于移动拉网场景建议打开。MOD NRCELLRSVD: NrCellId=57, RsvdParam0=2; /SN 偏置开关，0 和 1 表示打开，2 表示关闭/ Step4 : 设置X2 分流限速门限MOD GNBRSVD: RsvdParam10=1; /（0 means 100M,1 meas
9、200M,3 meas 400M）4.2开通下行动态分流 PdcpParamGroupId=5, DlDataPdcpSplitMode=SCG_AND_MCG;4.3开通上行动态分流/ 注意 UlDataSplitThreshold 在 SRAN15.0 版本的配置单位是 bit ， 推荐值是 12800bit ； 在SRAN15.1 版本因协议变更其单位变为 Byte，因此该参数推荐值变为 1600Byte。 PdcpParamGroupId=5, UlDataSplitPrimaryPath=SCG, UlDataSplitThreshold=1600;5下行不分流定位分析5.1下行分流
10、流程下行分流算法由基站侧控制，终端默认支持。按照优先用满 5G 空口能力的原则，先给5G 侧预留足量数据，在数据量有剩余的情况下再分流给 LTE 侧。具体算法流程如下。分流启动满足如下条件后启动下行分流：数据分配基站侧打开分流模式开关（QCI 级配置）RLC 为 AM/UM 模式（QCI 级配置）承载在 SgNB 侧建立完成数据分配包括以下 3 个步骤： Step 1: 给SgNB 分配数据Step2 : 补齐时延差计算 SgNB PDCP 缓存量根据 SgNB RLC 上报的感知速率（通常由空口能力决定）计算 SgNB RLC 桶令牌（即 PDCP 为 RLC 层预分配数据量）为 SgNB
11、分配数据直到 SgNB 桶令牌耗尽根据LTE 和NR 的 RLC 状态报告中的时延计算差值为时延小的那一侧多分数据，补齐时延差（通常 NR 侧时延小）， 以尽可能避免 UE PDCP 收包乱序Step 3: 给MeNB 分配数据停分流机制根据MeNB RLC 上报的感知速率（通常由空口能力决定）计算 MeNB桶令牌（预分配数据量）为MeNB 和SgNB 按速率比例分配数据直到 MeNB 桶令牌耗尽在特殊场景下需要及时停止分流，以避免分流引入负增益。典型场景如下：2s 内收不到状态报告反馈连续 200 个统计周期内 x2 链路丢包率超过 0.5% 连续 200 个统计周期内两端速率比相差大于 5
12、0 倍超过 UE 的 AMBR 5.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下行分流问题原因定位通常上游来水不足的原因
13、有三大类：1） 2 时延大导致多给NR 分数据 2）灌包服务器发送数据不足 3）空口误码，乱序等原因导致 TCP 发送窗口收缩导致。5.3.1给-上游来水不足CELLDT 3208（PDCP 层桶令牌打印）如果 ulMeNBToKen 基本不为 0 ， 说明 NR 侧来水不足以耗尽近端令牌。 反之如果ulMeNBToKen 基本为 0，说明 NR 侧来水充足，足以耗尽近端令牌（NR 侧数据量充足）来水充足，近端桶令牌基本都可以耗尽（大多数时间桶令牌为 0）来水不足，近端桶令牌耗不尽（桶令牌不为 0）解决方案：1、 查看 X2 时延：见下一节 X2 时延大。2、 若为 TCP 业务，核查 TCP
14、 层发送窗口是否限制速率，比如空口高误码，RLC重传、RTT 大时延等均会影响 TCP 发送窗口。3、 如果 TCP 层没有异常导致 TCP 发送窗口收缩，加大上游来水，例如多开灌包窗口/线程。5.3.2疏-X2 时延大在分流算法中补齐时延差需要考虑X2 时延，因此需要保证X2 的小时延防止数据大部分发送给 NR，导致 LTE 侧数据量少。跟踪中分析ucRttDelayS参数如果不为 0 ，将该值换算成 2 进制，并右移 24 位，得到的是 X2 环回时延， 例如下图中 ucRttDelayS 参数为 671088640 ， 右移 24 位后为101000=40ms，单向时延为 20ms。解决
15、方案如果单向 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。低速保护现象优
16、化 LTE 侧速率或降低 NR 侧速率。6上行不分流定位分析6.1上行分流流程上行分流算法完全由终端侧控制，具体算法取决于各厂商终端实现。目前支持上行分流的商用终端类型少。6.2上行分流问题原因定位6.2.1核-终端不支持上行分流能力1、 终端上报的 UE 能力中如果携带 UE-MRDC-Capability -splitDRB-withUL- MCG-SCG 能力，表示终端支持上行分流。2、 如果 UE 能力中不携带该信元，表示终端不支持上行分流，则基站侧无论配置上行分流开启与否，在添加辅载波（SCG）时发送给终端的信令消息均为上行不分流（上行分流门限为无穷大，UlDataSplitThre
17、shold=INFINITY;）6.2.2核-基站未给终端下发上行分流配置1、NR 基站侧需要配置 2 个关键参数GNBPDCPPARAMGROUP：UlDataSplitPrimaryPath=SCG, UlDataSplitThreshold=BYTE51200;2、在终端初始接入 NR 时，建立 5G 承载；SCG Addtion Req ACK 消息和之后 eNB 会发送 RRC Reconfig 消息给终端这两条消息中会携带上行分流路径 PrimaryPath（1=SCG，0=MCG）和上行分流门限（ ul-DataSplitThreshold ）。在终端进行 SgNB 切换时， S
18、gNB_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 和 L
19、TE 速率低现象【问题分析】：分析日志发现 NR 侧令牌数全程基本未耗尽，因此不会给 LTE 分数据。跟踪近端桶令牌由于NR 侧令牌未耗尽，因此没有数据供LTE 侧消耗令牌数，导致LTE 侧桶令牌无法耗尽。说明上游来水不足导致 NR 侧速率较低且 LTE 侧无速率。跟踪远端桶令牌【解决建议】：在增大来水量后，测试结果正常，问题解决。7.2X2 时延大问题测速时，LTE Only 的时候速率很高，DC 的时候速率低。在办公室复测发现 DC 分流下LTE 的速率很低，而 LTE Only 的时候测到的 LTE 速率明显高很多，如下图。终端侧 NR 和 LTE 速率情况跟踪中分析ucRttDelay
20、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。TC
21、P 测试发现偶尔有不分流现象（LTE RLC 速率为 0），停分流时间为 60s 的整数倍。Probe 低速保护停分流现象（1）Probe 低速保护停分流现象（2）查看日志，ucLowRateStopSplitFlag 参数为 1，说明触发了低速保护停分流机制。低速保护停分流现象找到对应TTI 前 2s 时间段，查看LTE 和NR 感知速率情况，判断NR 是否是LTE 的 50 倍以上。NR 和 LTE RLC 感知速率停分流之前的 2s 内NR/LTE 的 RLC 感知速率比大于 50 倍，主要因为 LTE RLC 感知速率太低（1.08Mbps）。因为 LTE 带宽只有 15M，且LTE
22、为现网存量用户，导致 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 空口负载低，可以提供较高的用户体验，可逐步推广下行分流；上行分流性能强依赖于终端的分流算法（非协议定义），因此不建议大规模开通上行分流。针对本地网发现的上下行分流问题进行了分析归纳，给出了问题的种类和跟因，同时梳理出相应的解决方法，作为问题处理树如下，指导类似问题的解决。
