一種降低5G上行數據傳輸時延的方案*

林高全，曹 芳，林錦全

（廣東郵電職業技術學院，廣東 廣州 510630）

0 引言

本文提出了一種可以降低5G 終端傳輸上行小包數據的時延方案，特別提出了一個終端管理模塊，可以根據終端的業務特征如業務請求間隔、數據包大小等識別出該終端是否可進入Inactive 狀態[1]。對于可進入Inactive 狀態的終端，通過其業務特征是否有規律和TA 是否變化或者終端是否移動，進一步確定終端適合的可降低上行數據時延的兩種方法。對于TA 變化或者移動的終端，確定小包數據通過信令方式傳輸；對于TA 無變化或者不移動的終端，則采用預分配資源方式傳輸小包數據。同時，對于移動的終端，在識別出其可進入Inactive 狀態且通過信令方式傳輸小包數據時，在發生RNA 變化的情況下，需要在目標基站與源基站之間傳遞可進入Inactive 狀態標識，以便目標基站節約資源而不用重新識別就直接判斷終端進入Inactive 態。如果正好在確定該終端可以進入inactive 狀態時發生了切換，也可以在目標基站與源基站之間傳遞可進入Inactive 狀態標識，以便目標基站節約資源就可以判斷終端可以進入Inactive 態。

1 背 景

1.1 現有5G 的用戶數據傳輸方式

5G 的3 大場景包括增強型移動寬帶（Enhance Moblie Broad，eMBB）、大規模機器類通信（massive Machnice Type Communication，mMTC）和高可靠低時延通信（Ultra Reliable Low Latency Communication，URLLC）。其中：eMBB 對應的是3D/超高清視頻等大流量移動寬帶業務；mMTC 對應的是大規模物聯網業務；URLLC 對應的是如無人駕駛、工業自動化等需要低時延、高可靠連接的業務。mMTC 作為萬物互聯的技術場景，主要關注廣連接、低時延、可靠性以及廣覆蓋等性能指標，且其傳輸特征是比較明顯的小包數據傳輸方式。

同時，相對于LTE[2-3]，5G 的RRC 狀態在保留Idle 狀態與Connected 狀態的基礎上，引入了一種新的RRC 狀態，即Inactive 狀態。該狀態的特征是基站保留終端的上下文信息，且一直保持著面向核心網的信令面與用戶面承載。如果處于Inactive 狀態的終端發生移動，還可能會發起RNA 位置更新過程。

對于包括小包數據在內的用戶面數據傳輸[4]，按照5G Release 16 及之前的標準協議，終端必須在完成Idle 狀態遷移到Connected 狀態后，建立該終端的信令面連接與用戶面承載，才能在建立的用戶面承載上發送用戶面數據，如圖1 所示。

圖1 中信令面的信令連接建立至少需要好幾十毫秒的時間，因此對于時延較敏感的小包數據傳輸的mMTC 應用來說，如何盡量減少部分信令建立的時延非常關鍵。

圖1 數據包傳輸的標準流程

1.2 3GPP 標準關于降低上行小包數據傳輸時延的初步探討

為了降低mMTC 用戶的小包數據傳輸時延，3GPP 標準Release 17 將針對非頻繁小包在Inactive狀態下的傳輸展開研究。典型的mMTC 應用場景如無線傳感器的信息不定期上報。

在Release 17 中，標準引入了在Inactive 狀態下的mMTC 小包時延優化，并且提出了如下兩種方法。

（1）在信令中攜帶用戶數據。在隨機接入過程中（包括四步隨機接入與兩步隨機接入）的Msg3/MsgA 中攜帶小包數據以降低時延，相對時延可降低至少50＆。圖2 是四步隨機接入的信令小包數據傳輸流程。

圖2 隨機接入信令中傳輸小包數據的流程

（2）用戶數據在用戶面傳輸。通過預分配資源給Inactive 態的mMTC 終端降低時延，相對時延可降低至少90＆。圖3 是資源預分配的小包數據傳輸流程。

圖3 資源預分配的小包數據傳輸示意

1.3 初步探討存在的問題

但是，現有的3GPPRelease 17 的討論稿中關于降低小包數據傳輸時延的方法還有很多方面沒有涉及。

（1）只是建議小包用戶數據可放在信令中傳輸或者在用戶面傳輸，沒有具體的方法描述；

（2）沒有明確基站如何確定哪些終端要處于Inactive 狀態。處于Inactive 狀態的終端需要維持與核心網[5]的傳輸鏈路以及終端上下文等信息，需要占用基站寶貴的CPU 與內存資源，因此限制了基站接入的終端用戶數。所以，需要確定哪些終端可以保留Inactive 狀態，哪些終端必須回到Idle 狀態。

（3）沒有明確哪些終端適合小包用戶數據放在信令中傳輸，也沒有明確哪些終端適合小包數據預先分配資源。

（4）對有移動性要求的終端，為了目標基站能夠快速識別終端傳小包數據的方式，同時也為了減少目標基站的判斷而消耗不必要資源，需要明確源基站應該如何傳遞已經確定在Inactive 態優化小包用戶數據傳輸的終端標識給目標基站。

因此，本文主要針對基站如何識別哪些終端需要Inactive 狀態，進一步確定哪些終端適合隨機接入信令方式的小包數據傳輸方式，明確哪些終端適合資源預分配方式的小包數據傳輸方式，并對其中需要移動的終端，如何傳遞已經識別出來的該終端需要Inactive狀態且合適的小包數據傳輸方式信息。

2 降低上行小包數據傳輸時延的可行方案

2.1 方案框架組成

圖4 是包含終端管理模塊的無線側網絡結構圖。其中：終端是5G mMTC 終端；基站是5G 基站；終端管理模塊是一個功能模塊，可以放在基站內部，也可以放在網管系統或者其他網元中。

圖4 含終端管理模塊的網絡結構

本文主要針對終端管理模塊放置在基站內部作為基站的一個功能模塊來描述。終端管理模塊內置基站，如圖5 所示。

圖5 終端管理模塊內置基站示意

終端管理模塊的主要功能是根據基站上報的終端業務特征如業務請求規律、數據包數量與數據包大小等信息，識別出該終端是否需要進入Inactive狀態，并進一步根據基站上報的TA 信息或是否移動以及業務特征，確定該終端的小包數據是在信令中傳輸，還是通過預分配資源方式來傳輸，并通知給基站資源分配與調度模塊執行。

2.2 可實現的技術方案

2.1 章節中提到的終端管理模塊可管理終端可進入Inactive狀態的判決以及小包數據的傳輸方式。

如圖6 所示，基站與終端在進行一次業務交互時，采集終端的該次業務請求起止時間、該次業務請求的業務數據包數量與數據包大小等業務信息以及TA信息或者移動標志，然后上報給終端管理模塊。終端管理模塊根據基站內部模塊上報的每個終端的業務信息，得到該終端的業務特征如業務請求時間間隔、業務時長以及每次業務的數據量等。如果該終端業務特征之業務請求時間間隔和每次業務數據量滿足小包傳輸定義規格，如時間間隔小于30 s 且包流量小于50 Byte（這些參數建議都是可以配置的），則判斷該終端可以進入Inactive 狀態。同時，只要基站上報了TA 值，終端管理模塊則根據TA值是否發生變化，確定該終端的具體小包傳輸方式。具體的，如果滿足TA 未發生變化且業務請求間隔有規律，則建議采用資源預分配小包傳輸方式；如果不滿足，則可以進一步根據小包大小來判斷是采用信令小包傳輸方式還是按照正常的先建立信令連接再建立用戶面承載才傳輸用戶數據包。這里的小包大小若是30 Byte，則可以通過參數配置確定。或者如果基站只上報了該終端的移動標志，可以根據該終端移動標志判斷其是否移動來確定該終端的具體小包傳輸方式。如果通過終端移動標志判斷終端沒有移動且業務請求間隔有規律，則建議采用資源預分配小包傳輸方式，否則建議采用信令小包傳輸方式。終端管理模塊得到該終端可以進入Inactive狀態及建議的小包傳輸方式后，通過消息指示基站該終端可以進入Inactive 狀態及建議的小包傳輸方式。基站收到這個指示，可以對該終端執行可以進入Inactive 狀態的小包傳輸方式。

圖6 終端管理模塊實現小包傳輸方式的選擇流程

2.3 移動場景下的基站間可進入Inactive 狀態標識傳遞

終端管理模塊確定為采用Inactive 狀態的信令傳輸小包數據方式的終端，由于終端管理模塊內置于基站網元，對于跨基站之間的RNA更新或者切換，需要源基站傳遞終端可進入Inactive 態下可信令傳輸小包標識給目標基站，具體的傳遞流程如下。

2.3.1 傳遞可進入Inactive 狀態標識的RNA 更新流程

如圖7 所示，當終端在Inactive 狀態下發生RNA更新時，因為RNA 更新后目標基站可能會讓終端返回Idle 狀態，所以在RNA 更新過程中目標基站向源基站發送查詢UE 上下文請求（RETRIEVE UE CONTEXT REQUEST）消息時，源基站在查詢UE 上下文響應消息（RETRIEVE UE CONTEXT RESPONSE）中攜帶可進入Inactive 狀態標識給目標基站。目標基站解析后發現該消息中攜帶了“可進入Inactive狀態標識”，則通知目標基站的終端管理模塊記錄該終端可以進入Inactive 狀態。同時，基站在RNA更新完成后繼續保持該終端在Inactive 狀態，并且指示終端可以采用信令方式傳輸小包數據。

圖7 攜帶可進入inactive 標識的信令流程

表1是具體的RETRIEVE UE CONTEXT RESPONSE 消息中“可進入Inactive 狀態標識”enableInactiveFlag的具體位置信息。本實施例考慮在標準的信息元素（Information Element，IE）列表中加入一個信息元素enableInactiveFlag。其 中，enableInactiveFlag 是 1 bit 大小的使能Inactive 狀態標志的字段；M 表示對應信息元素（IE）在消息中必定存在；O 表示對應信息元素（IE）在消息中可選存在。

表1 RETRIEVE UE CONTEXT RESPONSE 消息的IE

2.3.2 傳遞可進入Inactive 狀態標識的切換流程

如圖8 所示，當終端管理模塊正好確定該終端可以進入Inactive 狀態時就發生了切換[6]，此時可能終端處于Connected 狀態。為了避免目標基站重新做一遍源基站已經確定該終端可以進入Inactive狀態的流程而浪費資源及影響業務體驗，因此需要源基站在切換請求消息中攜帶可進入Inactive 狀態標識給目標基站。目標基站解析后發現切換請求消息（Handover Request）中攜帶了“可進入Inactive狀態標識”，則通知終端管理模塊記錄該終端可以進入Inactive 狀態，且目標基站后續保持該終端在Inactive 狀態，且指示終端采用信令方式傳輸小包數據，同時目標基站給源基站回切換請求確認消息（Handover Request Acknowledge）。

圖8 攜帶可進入inactive 標識的切換流程

這里只描述了基于Xn 口的切換，也同樣適用于Ng 口的切換。只是源基站在切換請求（Handover Required）消息中攜帶可進入Inactive 標識給AMF，然后再通過AMF 通過Handover Request 消息傳遞給目標基站。

具體的IE 設計可以參考前面的RNA 更新流程。

2.4 測試數據

通過仿真軟件來模擬標準的數據發包過程的時延、使用提到的在Inactive 狀態下采用直接資源預分配的時延與在隨機接入過程中直接攜帶數據包的時延，測試結果如表2 所示。

表2 測試結果比較

仿真軟件說明：采用TDD，幀格式為DSUUD，假設TTI=1 ms 調度單位，收到數據包后需要大于等于4TTI才能回ack，且假設Ng 接口的單向時延為5 ms。

通過表2 中的測試數據可知：采用標準的從Idle 狀態到Connected 狀態后再傳輸小包數據的上行時延為89 ms；采用提到的終端處于Inactive 狀態且在隨機接入過程中攜帶小包數據的上行時延僅為9 ms，而采用資源預分配的小包數據上行時延僅為1 ms，相對標準小包數據傳輸的上行時延，分別可以降低90＆與99＆。由此可知，采用本文提到的終端識別方法，不論是進入隨機接入的信令小包傳輸方式還是資源預分配的小包傳輸方式，都能顯著降低上行小包數據的傳輸時延。

3 結語

該方案可以使基站提前識別需要進入Inactive的終端，并進一步通過終端TA 與業務特征是否周期性變化及預測，區分該終端是進入隨機接入的信令小包傳輸方式還是資源預分配的小包傳輸方式，在能夠降低小包數據傳輸時延并保證業務體驗的基本目標的情況下，更有效地利用無線資源，使終端更加節能。