▋多用戶接入場景下 SR 配置不合理導致 SCG Failure? 【現象描述】? 在多用戶小區吞吐量測試中，出現個別終端 SCG Failure ?掉線較為頻繁的現象。? 【問題分析】? 1、首先，檢查 SCG Failure ?的原因。? 檢查測試 log 時發現 SCG Failure 的原因為 Random Access Problem。 2、然后，進一步查看終端發起 Random Access ?的原因。?如下圖，可見終端發起 RACH 的原因為 CONNCTION_REQUEST ?和UL_DATA_ARRIVAL，結合多用戶的測試場景，可以確定終端此時是因為需要進行上行傳輸而未申請到 SR，只能通過 RACH 來申請 UL_GRANT。? 但是 RACH 會有一定的概率出現 MESSAGE 4 Timer Expired ?導致失敗。 具體過程如下：gNB 給終端下發短周期 PUCCH SR 資源，且配置了 SR ?最大允許發送次數，如果 SR ?最大允許發送次數設置較小，而接入較多用戶時，終端得到上行調度的時延會顯著增加，容易導致 SR ?發送次數達到設置的最大允許值。此時終端會釋放 PUCCH ?SR資源，并通過 RACH 向 gNB 申請 UL grant。當 RACH 次數增多，gNB ?上行調度壓力增大，引起其他終端出現 SR ?發送次數達到最大值的概率增大，形成惡性循環，從而產生終端會出現多次 SCG Failure (Random Access Problem)的問題。? 【解決方案】? 針對多用戶接入場景，網絡側配置合理的 ?SR ?最大允許發送次數，如將 8/16 ?變更為32/64。? 【效果評估】? 網絡側配置合理的 SR ?最大允許發送次數后，問題解決，多用戶小區吞吐量測試中，終端不再出現 SCG Failure ?的問題。? 【后續建議】? 面向未來 5G 商用，根據終端用戶數，配置合理的 SR 最大允許發送次數和 PRACH ?資源，在小區吞吐量和用戶公平性之間獲取平衡。? ▋用戶面時延較長問題? 【現象描述】? 空口時延平均值在 17ms ?左右，時延較長。 傳輸+核心網部分時延較長，平均值 10ms ?左右。 【問題分析】? 5G ?端到端用戶面時延主要分為空口時延（終端至基站）和傳輸+核心網兩部分。其中空口時延與終端處理能力、子載波間隔、幀結構、調度方式、SR 周期配置、ping ?包大小等有密切聯系，實際環境中，終端需要 2~10ms ?的處理時延。在終端處理能力、子載波間隔和幀結構等統一的情況下，空口時延較長主要是受到了調度方式和 ping ?包大小的影響。開啟預調度可免除 SR ?調度流程，縮小空口時延。ping 包較大（2000B）需要分包可導致時延增長。傳輸+核心網部分時延主要與核心網部署位置相關，核心網部署越遠，所需傳輸時延越長，通常情況下，本地核心網部署傳輸+核心網部分時延為 1~3ms，鄰省約 6~8ms。? 【解決方案】? 網絡側開啟預調度功能，減小 ping 包大小（32B）。采用本地核心網部署。 【效果評估】? 縮小 ping 包大小后（原 2000B，現 32B），空口時延縮小 ?1~8ms 。