5G-Advanced端到端確定性傳輸分析與系統設計

孫海洋，施藝，李巖，范強，馬欣

5G-Advanced端到端確定性傳輸分析與系統設計

孫海洋，施藝，李巖，范強，馬欣

（華為技術有限公司，北京 100085）

5G蜂窩網絡因具有部署靈活、線纜成本低、移動性較強、服務質量（quality of service，QoS）控制完善和可擴展性強等優勢，在工廠場景中具有很廣泛的應用前景。但同時，工廠中的確定性業務對蜂窩網絡控制也提出了一定的要求。所以在5G-Advanced的相關討論中，業界也提出研究支持超低時延的5G蜂窩網絡。為了滿足2 ms的時延要求，提出了N3接口確定性和跨層調度優化兩種關鍵技術以減少在傳輸網和空口的傳輸或等待時延。這兩種技術在現有的蜂窩網絡與確定性網絡的互通通信機制和網絡協議的基礎上進行了改進，在對現有的網絡協議改動不大的前提下，能很好地滿足確定性業務較高的時延要求。

N3接口確定性；跨層調度優化；確定性低時延；5G

0 引言

5G蜂窩網絡因具有部署靈活、線纜成本低、移動性較強、服務質量（quality of service，QoS）控制完善和可擴展性強等優勢，在工廠場景中具有很廣泛的應用前景，越來越得到學術界和工業界的關注。蜂窩網絡已經給現有的工廠通信網絡領域帶來了重大的變革，在鋼鐵工業、港口運輸等有人類參與的遠程控制方面取得了較為廣泛的應用。5G蜂窩網絡是目前和未來工廠網絡無線化的主要形式。在5G-Advanced的相關討論中，業界也提出研究支持超低時延的5G蜂窩網絡[1-2]。

在之前的第三代合作伙伴計劃（3rd Generation Partnership Project，3GPP）網絡協議（如3GPP TS 23.501[3]）中，蜂窩網絡已經支持與工廠中的確定性網絡（如IEEE 802.1Q[4]）進行互通。隨著蜂窩網絡的不斷發展和成功應用，人們提出了更高的服務要求，希望可以從有人參與的遠程控制場景進一步深入生產線場景，如設備間的控制器協同。這就要求網絡具有一定的確定性QoS保證能力。對于當前的蜂窩網絡，即使使用了3GPP網絡協議，當前定義的與確定性網絡互通的特性增強，但由于傳輸網絡中交換機中存在的“多打一”現象以及基站調度的特殊性等問題，其支持確定性超低時延（如2 ms）的難度也會很大，所以必須提出新型的適用于確定性超低時延的端到端確定性技術。

目前在確定性網絡相關的研究主要有以下幾點。

● 3GPP TS 23.501[3]提出了5G蜂窩網絡與確定性網絡，如時間敏感網絡（time-sensitive networking，TSN）互通的架構。它將5G系統（5G system，5GS）看作整體，即將5G蜂窩網絡當作一個黑盒子，作為確定性網絡中的一個網橋或者節點以支持確定性網絡協議。

● IEEE 802.1Q[4]是現有的一類確定性網絡協議，可以基于時間隊列的調度以保證以太網的確定性，即可以保證通過交換網絡的業務最大時延是有限的。目前和5G蜂窩網絡互通的主要為其中的集中式模型。

● 3GPP TS 22.104[5]包含了現有的工廠自動化場景下各類業務的QoS需求。

1 背景與挑戰

1.1 現有的5G蜂窩網絡與確定性網絡互通技術

根據3GPP TS 23.501[3]的定義，在3GPP Release 16（Rel-16）中，為實現5G系統與TSN的互通，支持TSN流的確定性傳輸，將5GS整體作為一個TSN網橋，其傳輸TSN流時的入端口和出端口分別位于設備端TSN轉換器（device-side TSN translator，DS-TT）網絡端TSN轉換器和（network-side TSN translator，NW-TT），5GS與TSN互通系統架構如圖1所示，上行流經由DS-TT傳輸到NW-TT，下行流從NW-TT傳輸到DS-TT。 TSN支持IEEE Std 802.1Qcc-2018[6]中所定義的完全集中式模型。DS-TT作為用戶設備（user equipment，UE）與工廠設備互通的翻譯，NW-TT作為用戶面功能（user plane function，UPF）與工廠設備互通的翻譯。TSN流的報文在出口TT處緩存后，按照集中網絡配置（centralized network configuration，CNC）通過應用功能（application function，AF）配置的IEEE 802.1Q[4]調度參數往下游節點發送報文，從而解決5G蜂窩網絡轉發時延不確定的問題。當然，作為實現與TSN互通的前提條件，5GS整體需要支持作為IEEE Std 802.1AS-2020[7]中規定的時間感知系統，保證5GS與TSN的時鐘同步。另外，NW-TT要支持IEEE Std 802.1AB[8]中描述的鏈路層連接發現和報告（link layer connectivity discovery and reporting）。

圖1 5GS與TSN互通系統架構

具體來說，TSN AF保存業務等級（traffic class）、UE-DS-TT駐留時間和網橋時延（bridge delay）的映射；TSN AF在接收CNC的流調度信息時，計算時延、優先級、包大小，并執行流聚合，通知策略控制功能（policy control function，PCF）進行5GS確定性傳輸。另外，TSN AF還要生成時間敏感通信輔助容器（time-sensitive communication assistance container，TSCAC）并發送給PCF，TSCAC是基于TSN時鐘的，可以包含周期、突發到達時間、業務流方向等信息。其中，周期指的是兩個數據突發開始之間的時間段；突發到達時間是在給定的流方向上，數據突發的第一個數據包到達5GS的入端口的時間（上行為DS-TT，下行為NW-TT）；業務流方向指時間敏感通信（time-sensitive communication，TSC）流的方向。PCF基于與TSN相關的訴求生成5G內部的QoS參數。會話管理功能（session management function，SMF）會接收PCF生成的5GS內部的QoS參數，按照5GS內部已有的處理方式進行控制。另外，SMF接收PCF透傳的TSCAC，并生成時間敏感通信輔助信息（TSC assistance information，TSCAI）。SMF將TSCAI發送給無線電接入網絡（radio access network，RAN），RAN根據TSCAI進行調度。由于TSCAI由RAN來使用，所以SMF需要根據UPF上報的時鐘偏移進行校正，使其映射為5GS內部使用的時鐘，并且SMF要將到達5GS入端口的突發到達時間映射為RAN可以控制的突發到達時間。對于下行方向的流量，SMF根據UPF最近一次接收的時間偏移測量值，校正TSC輔助容器中的突發到達時間，并將TSCAI突發到達時間設置為校正值與核心網包時延預算（core network packet delay budget，CN PDB）的總和，表示數據突發的第一個數據包到達RAN的最晚可能時間。對于上行方向的流量，SMF根據從UPF接收的最新時間偏移測量值，校正TSC輔助容器中的突發到達時間，并將TSCAI突發到達時間設置為校正值與UE-DS-TT駐留時間之和，表示數據突發的第一個數據包到達UE出口的最晚可能時間。如果UE沒有提供UE-DS-TT的駐留時間，SMF基于實現設置突發到達時間。RAN可以根據TSC流的業務周期以及突發達到時間等為業務流配置更短周期的半靜態資源調度的實現方法來輔助調度。其他網元與確定性調度關系不大，篇幅原因，本文不做詳細介紹，可以進一步參考3GPP標準協議[3, 9-23]。其中，文獻[3,9-10]是基本的架構功能及流程描述，文獻[11-19]描述了核心網網元提供的具體的服務及其中的信元，文獻[20-23]描述了5G無線接入網的功能與流程實現。

圖2 非TSN場景下5GS支持TSC的系統架構

在3GPP Rel-17標準中，5G蜂窩網絡進一步增強支持非TSN的TSC業務。由于沒有限制具體的確定性協議，所以不要求AF可以提供確切的TSCAC，而是新引入了一個網元時間敏感通信和時鐘同步功能（time-sensitive communication and time synchronization function，TSCTSF）[24]，由TSCTSF根據AF/NEF提供的業務類型參數創建TSCAC，提供給PCF。引入TSCTSF的非TSN場景下5GS支持TSC的系統架構如圖2所示。同時，5GS可以進一步支持作為IEEE Std 1588[25]中描述的邊界時鐘、點到點透明時鐘或者端到端透明時鐘來進行時鐘同步。

1.2 超低時延下的挑戰

根據3GPP TS 22.104[5]的需求，在工廠自動化場景中，要求應用層端到端時延可以低至2～4 ms，工廠自動化場景需求見表1。

但是，當前3GPP TS 23.501[3]支持的最低的標準化5GS內部端到端包時延預算（packet delay budget，PDB）為5 ms。對應的雙端無線場景能支持的應用層端到端時延需求為10 ms。雙端無線部署場景示意圖如圖3所示，可編程邏輯控制器（programmable logic controller，PLC）和輸入輸出（input/output，I/O）設備均通過5G蜂窩網絡的空口進行交互，UPF直接轉發對應的業務數據。在工廠自動化場景中，使用雙端無線部署可以比單端無線部署進一步削減線纜的數量，并減少UPF與數據網絡之間的傳輸時延。在控制器到控制器（controller to controller）場景，默認使用雙端無線部署。

表1 工廠自動化場景需求

圖3 雙端無線部署場景示意圖

據分析，當前5G蜂窩網絡無法支持超低時延的原因主要有如下兩個方面。

（1）傳輸網時延的拖尾效應

工廠場景實際部署時，在RAN和UPF之間（如圖1中的N3接口）會經過傳輸網，并不是直接相連。傳輸網中存在一定數量的交換機。對于普通的以太網協議，傳輸網中的數據流會存在“多打一”現象。“多打一”現象具體指交換節點的入端口比對應的出端口多，因而導致必然會有至少兩個入端口對應一個出口，即存在至少兩個入端口的流量/數據包都需要一個出端口進行轉發的情況。這個端口的交叉會帶來潛在的多個入端口的流量/數據包去競爭一個出端口的現象，從而在出端口出現隊列擁塞。擁塞會帶來額外不確定的等待時延。這樣，在傳輸網絡中的時延就會出現長尾效應，如圖4所示。即在這種情況下，盡管傳輸網能夠支持的最小時延可以是一個較低的值，但是其傳輸數據包的最大時延是一個較高的值，可能會超過2 ms。因此，這樣的傳輸網將無法滿足確定性超低時延。

圖4 長尾效應

（2）空口調度的特殊性

目前，RAN是按照空口時隙調度，不能夠對業務流進行“隨到隨發”。例如，對于時分雙工（time division duplex，TDD）系統，如果一個下行的數據包沒有在可調度的下行鏈路時隙到達，則它必須等到下一個下行鏈路時隙才可以被傳輸。TDD數據包調度示意圖如圖5所示，矩形數據包和三角形數據包在第一個下行時隙（downlink slot，DL slot）到達，且下一個時隙同為下行時隙。這兩個數據包都在1個時隙的時間內發出。而圓形的數據包由于在保護帶對應的時間段到達，只能等待2個時隙（其中一個時隙為上行時隙，無法傳遞下行數據包）。當PDB值低至2 ms時，如果數據包錯過了第一個時隙，則要使RAN滿足要求是很有挑戰性的，因為每個時隙的典型值為250 μs。假設在核心網傳遞該下行數據包的傳輸時延為1 ms，那么RAN只剩下1 ms進行傳遞。這意味著RAN只有1個或2個時隙可用于滿足時延需求。如果RAN錯過了，則數據包將以大于端到端2 ms的時延傳送，不符合應用的訴求。

圖5 TDD數據包調度示意圖

另一方面，同一RAN節點中不同TSC流的突發到達時間可能會相互沖突。例如，當不同的流都在同一時間到達時，RAN可能無法同時調度所有TSC流的數據包。這樣，有一部分TSC流的數據包就要推遲發送。這就會導致類似的問題。

2 端到端確定性系統設計

為了解決第1.2節中提到的挑戰，提出了一種端到端確定性系統，對N3接口確定性和跨層調度優化兩個方面進行改進。

對于傳輸網時延的拖尾效應，其主要原因是N3接口的傳輸網目前不能配合5GS進行確定性傳輸。所以該端到端確定性系統應使能5GS與支持確定性的傳輸網進行互通來保證N3接口的確定性。換一種說法，5GS要與N3中的確定性網絡進行互通。

對于空口調度的特殊性所帶來的問題，其主要原因是RAN目前只能接收TSC流的TSCAI去輔助調度，但是不能按照自己的調度情況進行反饋，所以該端到端確定性系統應支持RAN按照自己的調度情況進行反饋。核心網可以將RAN的反饋進一步提交給應用，應用要基于RAN的反饋調整發包時間。

另外，由于該端到端確定性系統應依賴于5G蜂窩網絡以及現有的確定性網絡協議，所以其不應該對現有標準協議（如3GPP TS 23.501[3]、IEEE 802.1Q[4]等）做出較大的改動。這是為了避免改動過大導致無法形成產業共識，將來各廠商的設備沒有辦法真正互通，為商用帶來負面影響。

2.1 N3接口確定性

為了保證N3接口的確定性，可以將RAN和UPF分別作為現有確定性協議中的終端用戶，比如可以作為IEEE 802.1Q[4]中所定義的發送者和接收者。對于上行方向的業務流，RAN作為發送者，UPF作為接收者。對于下行方向的業務流，UPF作為發送者，RAN作為接收者。這樣RAN和UPF就可以利用現有的確定性協議來保證N3接口上傳輸的時延上限。如果RAN和UPF要基于現有的確定性協議來進行調度，那么要求傳輸網中的確定性網絡控制器匹配在RAN和UPF之間傳遞的業務的相關訴求。另一方面，RAN和UPF也要匹配確定性網絡控制器的要求。但是，RAN和UPF作為5GS內部的網元，尤其是UPF，作為核心網的用戶面，需要由5G核心網的控制面網元進行控制，而不宜由傳輸網的控制器直接進行控制。

基于上述思考，提出了一種5GS和確定性傳輸網互通的架構，如圖6所示。

其中，RAN和UPF充當最終用戶，按照現有的確定性協議支持基于時間窗的調度。5G核心網控制面與外部確定性傳輸網控制器交互（當然，也可以由傳輸網的網絡管理員來進行配置），以實現RAN和UPF之間的確定性通信相關參數的傳遞。本架構并不限制N3接口上確定性協議的種類，可以按照需求盡量重用現有的傳輸網所支持的確定性協議。5G核心網控制面根據傳輸網提供的確定性傳輸參數為RAN和UPF配置調度參數。具體的，5G核心網控制面可以根據流量模式（如周期、時延要求、流量特征等）確定業務流在RAN或UPF上排隊和調度的時間。5G核心網控制面仍然重用第1.1節中描述的5G核心網架構中的控制面網元即可，沒有必要引入新的控制面網元。

圖6 5GS和確定性傳輸網互通的架構

引入圖6所述的架構，傳輸網中的交換機可以按照現有的確定性協議進行工作。RAN和UPF也可以根據現有的5GS架構獲取確定性傳輸所需要的參數配置。而且N3接口的確定性網絡與當前架構中數據網絡里與5GS互通的確定性網絡可以相互獨立。這樣，最大程度上重用了現有的機制，避免了對現有的5GS架構和確定性協議產生過大的影響。但是RAN和UPF卻可以按照確定性網絡中的終端用戶進行數據包傳遞，從而保證了N3接口的確定性，消除了“多打一”帶來的長尾效應。

2.2 跨層調度優化

為了解決空口調度的特殊性所帶來的兩個問題，即業務數據流的到達時間與RAN的調度時機不匹配，以及多流的調度沖突，可以考慮讓RAN根據自己的調度進行合適的反饋。如第2.1節所述，現有技術中TSN AF或TSCTSF已經可以向5G核心網提供TSCAC，并且SMF會將TSCAC轉化為TSCAI并交由RAN進行相關TSC流的調度。但正如第2.1節提到的，RAN目前只是被動地接受各個TSC流的TSCAI，并且依照TSCAI進行調度。如果出現了業務數據流的到達時間與RAN的調度時機不匹配，或者多個TSC流的調度沖突問題，RAN也只能讓對應的TSC流的數據包進行等待。那么，假如TSC流的數據包恰好在匹配RAN的調度時機的時間窗到達，而且到達時與其他的TSC流之間沒有不可調和的沖突，則第1.2節中提到的問題就可以規避掉。那么可以讓RAN基于現有技術中各個TSC流的TSCAI以及本身的調度情況進行反饋，從而使對應的應用可以調整其發包時間。

基于上述思考，提出了基于RAN反饋的數據包發送時間調整流程，具體如圖7所示。

步驟1 AF（或者TSCTSF）按照現有技術向5G核心網控制面提供TSCAC。

步驟2 5G核心網控制面（具體為SMF）將TSCAC轉化為TSCAI發送給RAN。

步驟3 RAN根據自己的調度情況可以作出判斷。若TSC流的數據包恰好在匹配RAN的調度時機的時間窗到達，而且到達時，與其他的TSC流之間沒有不可調和的沖突，那么RAN就不必對該TSC流對應的數據包的發送時間反饋調整請求。在其他情況下，RAN需要找到一個合適的時機，使對應TSC流的數據包達到上述效果，并且向5G核心網控制面發送對應的到達時間調整請求。具體地，RAN可以反饋給SMF，SMF可以按照現有的架構再上報給PCF。

步驟4 5G核心網控制面（具體為PCF），將到達時間調整請求發送給AF（或者TSCTSF）。

步驟5 AF（或TSCTSF）根據應用側的一些手段，調整應用服務器的數據包發送時間。

步驟6 AF（或TSCTSF）根據調整后的數據包發送時間更新發送給網絡側的TSCAC。

本流程既可以用于第2.2節中的5GS和確定性傳輸網互通架構，又可以用于第1.2節中的5GS與TSN互通系統架構或非TSN場景下5GS支持TSC的系統架構。當本流程用于5GS和確定性傳輸網互通架構中時，RAN可以根據TSCAI較為準確地知道對應TSC流的突發到達時間。圖7中帶陰影的小方塊部分代指用戶面數據包，只給出了下行作為例子。但由于TSCAC中包含的突發到達時間本身就可以包含上行方向和下行方向，所以本流程可以既用于下行的業務流，又用于上行的業務流。

圖7 基于RAN反饋的數據包發送時間調整流程

引入圖7所述的流程，對現有技術中TSC流調度的機制并未作出大的改變，如步驟（1）、步驟（2）和步驟（6）均可以重用現有的機制，只在步驟（3）、步驟（4）和步驟（5）引入了必要的反饋和調整機制，從而避免了對現有的協議流程產生過大的影響。但是應用發送數據包的時機和RAN的調度時機卻可以較好地匹配，并且可以避免多個TSC流之間的沖突，從而減少了由于RAN調度的特殊性所引入的等待時延。

3 結束語

本文提出的端到端確定性系統，基于5GS和確定性傳輸網互通的架構和基于RAN反饋的數據包發送時間調整流程，消除了傳輸網中“多打一”導致的長尾效應，減少了由于RAN調度的特殊性所導致的等待時延，從而保證了端到端的確定性超低時延。并且基于5GS和確定性傳輸網互通的架構和基于RAN反饋的數據包發送時間調整流程可以相互獨立，將來可以獨立演進。另外，本系統模型引入的技術對現有協議的改動較小，與現有技術的結合較好，從而增加了該系統模型的可實施性和可部署性。

進一步地，考慮除了工廠場景，生產與生活中還有一些其他超低時延要求的業務，比如增強現實（augmented reality，AR）、虛擬現實（virtual reality， VR）業務等，本系統也可以用于這些業務場景，從而降低這些業務在5GS中傳遞的時延。

[1] 3GPP. Discussion on enhancement for URLLC and deterministic network: S2-2104144[S]. 2021.

[2] 3GPP. Study on 5G timing resiliency and TSC & URLLC enhancements: SP-211634[S]. 2021.

[3] 3GPP. System architecture for the 5G system; stage 2: TS 23.501[S]. 2021.

[4] IEEE. IEEE standard for local and metropolitan area networks— bridges and bridged networks: Std 802.1Q[S]. 2018.

[5] 3GPP. Service requirements for cyber-physical control applications in vertical domains; stage 1: TS 22.104[S]. 2021.

[6] IEEE. IEEE standard for local and metropolitan area networks- bridges and bridged networks- amendment: stream reservation protocol (SRP) enhancements and performance improvements: Std 802.1Qcc-2018[S]. 2018.

[7] IEEE. IEEE standard for local and metropolitan area networks--timing and synchronization for time-sensitive applications: Std 802.1AS-2020[S]. 2020.

[8] IEEE. IEEE standard for local and metropolitan area networks -- station and media access control connectivity discovery: Std 802.1AB-2016[S]. 2016.

[9] 3GPP. Procedures for the 5G system; stage 2: TS 23.502[S]. 2021.

[10] 3GPP. Policy and charging control framework for the 5G system: TS 23.503[S]. 2021.

[11] 3GPP. 5G system; session management policy control service; stage 3: TS 29.512[S]. 2021.

[12] 3GPP. Interface between the control plane and the user plane nodes; stage 3: TS 29.244[S]. 2021.

[13] 3GPP. 5G system; session management services; stage 3: TS 29.502[S]. 2021.

[14] 3GPP. Policy and charging control signalling flows and QoS parameter mapping; stage 3: TS 29.513[S]. 2021.

[15] 3GPP. 5G system; policy authorization service; stage 3: TS 29.514[S]. 2021.

[16] 3GPP. 5G system; access and mobility management services; stage 3: TS 29.518[S]. 2021.

[17] 3GPP. Non-access-stratum (NAS) protocol for 5G system (5GS); stage 3: TS 24.501[S]. 2021.

[18] 3GPP. 5G system; network function repository services; stage 3: TS 29.510[S]. 2021.

[19] 3GPP. 5G system; network exposure function northbound API; tage 3: TS 29.522[S]. 2021.

[20] 3GPP. NG-RAN; NG application protocol (NGAP): TS 38.413[S]. 2021.

[21] 3GPP. NR; NR and NG-RAN overall description: TS 38.300[S]. 2021.

[22] 3GPP. NR; radio resource control (RRC); protocol specification: TS 38.331[S]. 2021.

[23] 3GPP. PDU session user plane protocol: TS 38.415[S]. 2021.

[24] 3GPP. Introduction of architecture for AF requested support of time sensitive communication and time synchronization: S2-2105082[S]. 2021.

[25] IEEE. IEEE standard for a precision clock synchronization protocol for networked measurement and control systems: Std 1588[S]. 2019.

5G-Advanced E2E deterministic transmission analysis and system design

SUN Haiyang, SHI Yi, LI Yan, FAN Qiang, MA Xin

Huawei Technologies Co., Ltd., Beijing 100085, China

Because of the advantages of flexible deployment, low cable cost, strong support for mobility and comprehensive QoS control and high scalability, cellular networks had been widely used in factory scenarios. At the same time, the deterministic service in the factory also puts forward certain requirements for cellular network control. Therefore, in discussions related to 5G-Advanced, the industry also proposes to research a 5G cellular network that supports ultra-low latency. To meet the delay requirement of 2 ms, two key technologies, deterministic N3 interface and cross-layer scheduling optimization were proposed to reduce the transmission or waiting delay on the transport network and air interface. These two technologies were the enhancement based on the current communication mechanism and network protocol between cellular network and deterministic network. The high delay requirement of deterministic services can be met well without changing the existing network protocol too much.

deterministic N3 interface, cross-layer scheduling optimization, deterministic low latency, 5G

TP393

A

10.11959/j.issn.1000?0801.2022055

2022?01?10；

2022?03?09

孫海洋（1994? ），男，現就職于華為技術有限公司，3GPP SA2（System Aspects 2）標準代表，主要研究方向為確定性網絡、策略控制、QoS管理、網絡切片等。

施藝（1984? ），男，現就職于華為技術有限公司，負責5G-Advanced URLLC研究工作和產業推動，主要研究方向為確定性網絡、toB物聯網、工業大上行等。

李巖（1976? ），男，華為技術有限公司移動寬帶網絡架構研究技術專家，主要研究方向為移動邊緣計算、低時延高可靠、網絡切片。

范強（1990? ），男，華為技術有限公司標準研究工程師，主要研究方向為IIoT/URLLC、XR、移動性管理等。

馬欣（1982? ），男，華為技術有限公司主任工程師，主要研究方向為工業控制領域的5G技術與產業推動。