陸威，方琰崴，陳亞權(quán)

（中興通訊股份有限公司，江蘇 南京 210012）

0 引言

工信部發(fā)放5G 牌照后，電信運營商就緊鑼密鼓地加緊推動5G 商用進程。2019 年11 月，5G 商用套餐正式商用，這標志著中國正式跨入5G 商用時代。和以往的通信制式明顯不同的是，5G 在面向電信終端用戶的同時，還面向工業(yè)化、自動化的應(yīng)用。這標志著我國開啟了第四次工業(yè)革命的序幕，5G 技術(shù)將極大促進工業(yè)互聯(lián)網(wǎng)的發(fā)展，推動人類進入智能化時代[1]。工業(yè)互聯(lián)網(wǎng)對5G 提出了很高的網(wǎng)絡(luò)可靠性和低時延要求，例如工業(yè)控制、遠程醫(yī)療、車聯(lián)網(wǎng)等要求5G 網(wǎng)絡(luò)能提供小于10 ms 的端到端超低時延能力[2]。3GPP 對此場景定義為URLLC，并從R15 開始研究相關(guān)技術(shù)，制定一系列技術(shù)標準。當(dāng)前3GPP 的重點是改善5G 無線部分的通信時延[3]，對承載網(wǎng)、核心網(wǎng)等網(wǎng)絡(luò)架構(gòu)方面的超低時延技術(shù)研究較少，本文從5G 網(wǎng)絡(luò)架構(gòu)的角度[4]，介紹了URLLC 超低時延的解決方案和關(guān)鍵技術(shù)，并提供了部署方面的建議。

1 URLLC 解決方案架構(gòu)

工業(yè)自動化控制通常要求端到端時延達到毫秒級別[5]，這個端到端時延由多個部分構(gòu)成[6]，公式如下：

T_E2E 指端到端時延，是數(shù)據(jù)報文在UE 和APP 之間的單向時延。

T_RAN 指無線時延，是UE 和RAN 之間產(chǎn)生的時延。其中，電磁波在空間傳播速度是光速，引起的時延極低，可以忽略不計。時延主要來自設(shè)備的信道編碼、調(diào)制解調(diào)、算法計算、資源分配等的處理時間。在4G 網(wǎng)絡(luò)中，無線時延在5 ms 左右，在5G 網(wǎng)絡(luò)中，無線時延要求低于0.5 ms。3GPP 標準組對如何降低無線時延有大量研究，本文不做具體介紹。

T_Transmission+T_CN+T_Internet 指回傳、核心網(wǎng)、互聯(lián)網(wǎng)的疊加時延，這是光纖傳輸網(wǎng)絡(luò)、路由器節(jié)點、核心網(wǎng)用戶面網(wǎng)元、應(yīng)用服務(wù)器的IP 報文處理產(chǎn)生的時延。一個原因是傳輸距離比較大，中間存在多個網(wǎng)絡(luò)節(jié)點，每個節(jié)點轉(zhuǎn)發(fā)數(shù)據(jù)時都產(chǎn)生一部分時延；另一個原因是網(wǎng)絡(luò)虛擬化[7-9]帶來的性能下降，產(chǎn)生一部分時延。

圖1 是端到端URLLC 超低時延解決方案，采用多種技術(shù)實現(xiàn)超低時延的效果，包括云網(wǎng)融合的邊緣計算[10-11]、增強型用戶面硬件加速、最優(yōu)路徑的多維協(xié)同、端到端的時延監(jiān)控。這些技術(shù)可根據(jù)部署需要，選擇部分或所有技術(shù)進行組合使用。

URLLC 超低時延的網(wǎng)絡(luò)架構(gòu)遵循3GPP 定義的5G網(wǎng)架構(gòu)[12-16]，在實際部署時應(yīng)該基于幾個原則來實現(xiàn)超低時延的建網(wǎng)目標。

原則1：最短路徑。即用戶面UPF（User Plane Function，用戶面功能）網(wǎng)元下沉部署到靠近用戶的邊緣節(jié)點[17]。需要引入云網(wǎng)融合的邊緣計算和用戶面硬件加速技術(shù)。

原則2：預(yù)留資源。即在建網(wǎng)初期做話務(wù)模型預(yù)測時，預(yù)留一定比例的冗余量，讓網(wǎng)絡(luò)在實際運行時處于比較輕載的狀態(tài)，避免頻繁的網(wǎng)絡(luò)擁塞帶來的高時延[18]。在網(wǎng)絡(luò)運行階段，能監(jiān)控時延指標，動態(tài)調(diào)整資源分配，為超低時延的應(yīng)用預(yù)留資源。需要引入端到端的時延監(jiān)控技術(shù)。

原則3：云網(wǎng)協(xié)同。即APP 也下沉部署到靠近用戶的邊緣節(jié)點。當(dāng)用戶移動時，5G 網(wǎng)絡(luò)的UPF 會跟隨用戶切換到靠近用戶的新位置，同時云內(nèi)的APP 也能協(xié)同跟隨用戶切換到新的UPF 位置。需要引入最優(yōu)路徑的多維協(xié)同技術(shù)[19]。

圖1 端到端URLLC超低時延解決方案

2 URLLC 關(guān)鍵技術(shù)

2.1 云網(wǎng)融合的邊緣計算

5G 時代以前，移動用戶的流量比較少，運營商為節(jié)約建設(shè)成本，一般把用戶面網(wǎng)元（EPC PGW）部署在省會城市，流量先匯聚到省會EPC PGW，然后再進入Internet的云端處理。用戶和云端應(yīng)用之間有很長的空間距離，IP 報文會經(jīng)過很多路由節(jié)點和光纖傳輸設(shè)備，帶來較大的時延。3GPP 和ETSI 針對5G 的低時延高帶寬需求特點，設(shè)計了MEC（Multi-access Edge Computing，多接入邊緣計算）解決方案，把用戶面設(shè)備UPF 部署到靠近邊緣的MEC 中，縮短UE 到UPF 間的傳輸距離并減少路由跳數(shù)，從而降低時延[20]。這個解決方案解決了網(wǎng)（UEUPF 的路徑）的低時延問題，未解決網(wǎng)和云（UPF-APP）之間的低時延問題。原因是云端的應(yīng)用不屬于運營商資產(chǎn)，運營商從網(wǎng)絡(luò)安全的角度會采用防火墻等安全設(shè)備隔離云端的應(yīng)用，而且云端的APP 和運營商的網(wǎng)絡(luò)一般也不在同一個站點，網(wǎng)和云間存在的路由器、防火墻、光纖等傳輸路徑增大了時延。采用云網(wǎng)融合的邊緣計算技術(shù)，可以解決云網(wǎng)之間的時延問題，從而提供端到端毫秒級的超低時延能力。

云網(wǎng)融合的邊緣計算，核心網(wǎng)思想是把運營商的網(wǎng)（UPF）和云端低時延需求的APP 融合在同一個MEC 站點的局域網(wǎng)內(nèi)，UPF 和APP 間的報文傳輸不需要繞到外部網(wǎng)絡(luò)做路由迂回，大大降低了UE 和APP 間的報文傳輸路徑，從而降低時延。但這個方案的UPF 和APP 間存在安全隱患，需要采用如下幾個技術(shù)保證云網(wǎng)融合后的安全可靠性[21-23]。

技術(shù)1：MEC 內(nèi)部的局域網(wǎng)內(nèi)劃分不同的VLAN（Virtual Local Area Network，虛擬局域網(wǎng)）并建立DMZ（Demilitarized Zone，隔離區(qū)），讓APP 處在DMZ 中，避免非授權(quán)許可的端口報文侵入到本網(wǎng)內(nèi)。

技術(shù)2：UPF 和APP 間增加虛擬防火墻。由于UPF和APP 間的報文端口比較單一，虛擬防火墻的配置和業(yè)務(wù)處理比較簡單，增加的虛擬防火墻帶來的極低時延（微秒級別）對端到端時延影響非常小。

技術(shù)3：對APP 做安全認證。運營商對進入MEC的APP 提前做軟件安全掃描，避免該APP 攜帶病毒或被植入不明軟件。一旦安全掃描通過，運營商向該APP 發(fā)放證書，用于后續(xù)的鑒權(quán)認證，只有認證通過的APP 才被允許在MEC 內(nèi)運行。

技術(shù)4：對APP 做安全加固。當(dāng)APP 部署到MEC時，運營商需對APP 的操作系統(tǒng)、數(shù)據(jù)庫等做安全加固，確保不用的端口、服務(wù)和協(xié)議棧都被關(guān)閉。

技術(shù)5：運營商在MEC 中部署一套APP 鑒權(quán)認證系統(tǒng)。APP 在MEC 內(nèi)啟動時，該系統(tǒng)對APP 進行鑒權(quán)認證，確保APP 的完整性和一致性。如果APP 未通過鑒權(quán)認證，就被隔離刪除。

以上技術(shù)在實際應(yīng)用中有著良好的效果，MEC 內(nèi)UPF 和APP 的綜合時延能控制在10 μs 級別，而且安全性也得到了保障。

2.2 增強型用戶面硬件加速

電信網(wǎng)絡(luò)功能虛擬化（NFV）后，通過使用通用COTS（Commercial Off-The-Shelf）服務(wù)器以及虛擬化技術(shù)來轉(zhuǎn)發(fā)IP 報文，從而提升資源利用率，降低網(wǎng)絡(luò)設(shè)備成本。但NFV 技術(shù)采用的通用硬件也帶來了一個缺點，即用戶面的數(shù)據(jù)除了經(jīng)過網(wǎng)卡的收發(fā)外，還需要CPU 和應(yīng)用層軟件介入處理，涉及的模塊多，而且CPU 并不是專為報文轉(zhuǎn)發(fā)設(shè)計的，轉(zhuǎn)發(fā)性能低，導(dǎo)致IP 報文轉(zhuǎn)發(fā)時延大，不能很好地滿足5G 網(wǎng)絡(luò)超低時延的性能要求。

可以在通用COTS 服務(wù)器中加入FPGA 智能網(wǎng)卡硬件[25]，讓該智能網(wǎng)卡專門處理用戶面IP 報文轉(zhuǎn)發(fā)，從而顯著提高轉(zhuǎn)發(fā)效率，使UPF 網(wǎng)元級的轉(zhuǎn)發(fā)時延從毫秒級降低到10 μs 級別。

圖2 是UPF 帶有智能網(wǎng)卡的數(shù)據(jù)處理架構(gòu)，有兩個關(guān)鍵的處理流程即建立流表流程和智能網(wǎng)卡本地卸載流程。

圖2 用戶面硬件加速數(shù)據(jù)處理架構(gòu)

（1）建立流表流程。智能網(wǎng)卡從無線側(cè)收到信令面的會話建立請求報文，智能網(wǎng)卡把該報文發(fā)送給UPF 的信令模塊，UPF 信令模塊解包獲得TEID（Tunnel Endpoint Identifier，隧道端點標識），并返回給智能網(wǎng)卡，智能網(wǎng)卡把此TEID 記錄在本地。后續(xù)智能網(wǎng)卡收到用戶面的業(yè)務(wù)首包時，解析GTP（GPRS Tunnelling Protocol）內(nèi)層用戶IP 的源地址端口等五元組，查找智能網(wǎng)卡內(nèi)的流表，由于這是首包，流表中沒有對應(yīng)的轉(zhuǎn)發(fā)規(guī)則，智能網(wǎng)卡就把報文上傳給UPF 的DPI，DPI 剝離GTP 頭，處理CRC校驗和，獲得流表信息，并下發(fā)給智能網(wǎng)卡。智能網(wǎng)卡后續(xù)收到報文時，就可以通過本地流表的轉(zhuǎn)發(fā)規(guī)則，把報文直接轉(zhuǎn)發(fā)出去。

（2）智能網(wǎng)卡本地卸載流程。智能網(wǎng)卡從無線側(cè)收到用戶面報文后，根據(jù)物理端口和報文（源地址和端口）判斷是否來自無線側(cè)的GTP 報文，智能網(wǎng)卡查找本地TEID 表，如果存在則說明報文合法。智能網(wǎng)卡再獲取GTP 內(nèi)層用戶IP 真實地址和源地址端口等五元組信息，查找智能網(wǎng)卡本地的流表，查找成功后，根據(jù)流表內(nèi)的轉(zhuǎn)發(fā)規(guī)則，把報文送到Gi 口直接轉(zhuǎn)發(fā)出去。

UPF 植入智能網(wǎng)卡后，把大部分的IP 報文處理（解包、查流表、轉(zhuǎn)發(fā)等）卸載到智能網(wǎng)卡本地處理，大幅減輕CPU 的處理負荷，減少內(nèi)存讀取次數(shù)，降低PCIe 總線負荷，從而提升整個COTS 服務(wù)器的處理性能。

2.3 最優(yōu)路徑的多維協(xié)同

IP 報文傳輸路徑的距離長短和路由跳數(shù)多少，都會影響時延的大小。一般APP 會在地理位置上分布式部署到邊緣位置，縮短APP 和UE 之間的路徑。UE 在發(fā)起會話時，URLLC 網(wǎng)絡(luò)會根據(jù)UE 所在位置、APP 分布式部署的地理位置，選擇一個UPF 為該UE 服務(wù)，確保UERAN-回傳網(wǎng)絡(luò)-UPF-APP 是一條時延最優(yōu)路徑。

由于UE 會移動，當(dāng)UE 從一個基站切換到另一個基站時，UE-RAN（新）-回傳網(wǎng)絡(luò)（新）-UPF-APP 的路徑就發(fā)生了變化，該路徑并不是時延最優(yōu)路徑，會加大UE和APP 間的時延。為了能在UE 發(fā)生移動切換時，持續(xù)獲得低時延，需要及時根據(jù)UE 最新的位置信息和APP分布式部署位置信息，更新傳輸路徑[24]。

3GPP 已經(jīng)定義了UE 的切換流程，由SMF 根據(jù)UE的位置和UPF 的網(wǎng)絡(luò)拓撲，選擇新的UPF 為UE 提供服務(wù)。在引入URLLC 超低時延需求后，SMF 還需要綜合考慮UE 位置和APP 地理位置拓撲信息，來選擇最優(yōu)路徑上的新的UPF 和新的APP 節(jié)點。SMF 還需要通知APP，讓APP 調(diào)度原節(jié)點的狀態(tài)信息給新的APP 節(jié)點。后續(xù)該UE 的IP 報文就在“ UE-RAN（新）-回傳網(wǎng)絡(luò)（新）-UPF（新）-APP（新）”新的最優(yōu)路徑上傳輸。

2.4 端到端的時延監(jiān)控

URLLC 網(wǎng)絡(luò)在正常情況下能提供超低時延的數(shù)據(jù)傳輸能力，但有時因用戶接入太多，或突發(fā)大流量等原因，網(wǎng)絡(luò)也會發(fā)生數(shù)據(jù)擁塞或丟包，因此需要有機制能實時監(jiān)控時延狀態(tài)，當(dāng)時延高于某個閾值時，URLLC 網(wǎng)絡(luò)能調(diào)整網(wǎng)絡(luò)資源的分配，搶占低優(yōu)先級應(yīng)用的資源，并預(yù)留給高優(yōu)先級的低時延應(yīng)用，能盡快解決高時延的問題。同時也能及時把高時延告警發(fā)送給應(yīng)用，讓應(yīng)用能及時應(yīng)對處理。例如車聯(lián)網(wǎng)為了保障車輛行駛安全，需要采用超低時延的URLLC 網(wǎng)絡(luò)來保障車輛能及時獲取到周邊環(huán)境的信息，否則容易發(fā)生事故[26]。URLLC 網(wǎng)絡(luò)一旦檢測到時延低于車聯(lián)網(wǎng)要求，就要及時通知車輛降低車速，以便車輛在緊急情況時有更多的緩沖時間完成剎車等動作。

應(yīng)用一般更關(guān)注單向時延，即IP 報文在UE-基站（NR）-回傳網(wǎng)絡(luò)-核心網(wǎng)UPF 間的整個傳輸路徑上的時延。在該路徑的關(guān)鍵節(jié)點上設(shè)置時延監(jiān)控點，這些節(jié)點間通過微秒級別的高精度時鐘同步保證時間一致性[27]，每個節(jié)點轉(zhuǎn)發(fā)IP 報文時都會把本節(jié)點的當(dāng)前時間戳插入該IP 報文。UPF 作為監(jiān)控的匯總點，對收到的IP 報文中的時間戳進行計算，獲得該IP 報文在URLLC 網(wǎng)內(nèi)的端到端傳輸時延。由于不同的應(yīng)用對時延的要求是不同的，需要能針對特定對象進行監(jiān)控，例如針對業(yè)務(wù)類型，或者某個UE，或者某個切片進行監(jiān)控。一般需要3個步驟完成時延監(jiān)控。

第一步，由APP 向URLLC 網(wǎng)絡(luò)發(fā)起時延監(jiān)控激活請求，后續(xù)URLLC 網(wǎng)絡(luò)就能周期性監(jiān)控時延狀態(tài)。具體流程為：

APP 向PCF 發(fā)送“時延監(jiān)控請求”消息，內(nèi)帶“被監(jiān)控對象（例如IMSI）”“時延閾值Tmax-delay（例如50 ms）”。

PCF 收到“時延監(jiān)控請求”消息后，對APP 進行鑒權(quán)認證，確保該APP 是合法應(yīng)用。并把“時延監(jiān)控請求”消息轉(zhuǎn)發(fā)給SMF。

SMF 收到“時延監(jiān)控請求”消息后，根據(jù)消息中的“被監(jiān)控對象”，確定在哪些UPF 上設(shè)置監(jiān)控點。如果“被監(jiān)控對象”是某個APP，SMF 會向它管理的所有UPF發(fā)送“時延監(jiān)控請求”消息。如果“被監(jiān)控對象”是某個UE 的IMSI，SMF 會向UE 當(dāng)前所在的UPF 發(fā)送“時延監(jiān)控請求”消息。后續(xù)UE 發(fā)生UPF 間切換時，SMF 還需把該請求消息發(fā)送給新的UPF。如果“被監(jiān)控對象”是某個切片，SMF 會向該切片所在的UPF 發(fā)送“時延監(jiān)控請求”消息。

UPF 收到“時延監(jiān)控請求”消息后，記錄該時延監(jiān)控請求攜帶的參數(shù)。后續(xù)UPF 收到IP 報文時，會計算IP報文攜帶的各個節(jié)點插入的時間戳，獲得UE 到UPF 間的單向時延數(shù)據(jù)。

第二步，UPF 收到IP 報文時，執(zhí)行時延檢測。具體流程為：

UE 向RAN 發(fā)送IP 報文時插入UE 的時間戳T1。RAN 收到IP 報文后插入RAN 的時間戳T2，并轉(zhuǎn)發(fā)給UPF。UPF 收到IP 報文后插入UPF 的時間戳T3。

UPF 根據(jù)公式Tdelay=T3-T1，計算獲得UE 到UPF間的時延Tdelay，如果Tdelay 大于Tmax-delay 的值，說明該報文時延超過了閾值。如果后續(xù)連續(xù)10（該值可以根據(jù)應(yīng)用場景需要更改大?。﹤€報文時延都大于閾值，就認為當(dāng)前網(wǎng)絡(luò)時延不滿足應(yīng)用的要求。此時UPF 執(zhí)行2 個動作：一個是通知URLLC 網(wǎng)絡(luò)內(nèi)的瓶頸節(jié)點（通過“T2-T1”和“T3-T2”的值判斷哪些節(jié)點產(chǎn)生了高時延），調(diào)整節(jié)點內(nèi)資源分配策略，提升本IP 流的轉(zhuǎn)發(fā)速度；另一個是通知APP，由APP 根據(jù)本地策略調(diào)整動作，例如高速自動駕駛中的車輛能降低車速。

第三步，APP 向URLLC 網(wǎng)絡(luò)發(fā)送“去激活時延監(jiān)控”的請求，后續(xù)URLLC 停止對該APP 指定對象的時延監(jiān)控。本步驟在實際應(yīng)用中是必不可少的，原因是時延監(jiān)控也耗費了URLLC 網(wǎng)絡(luò)的資源消耗，在UE 的應(yīng)用結(jié)束后，盡快通知URLLC 網(wǎng)絡(luò)停止對該UE 的監(jiān)控，可以降低URLLC 網(wǎng)絡(luò)后續(xù)的處理負荷。

3 URLLC 部署建議

URLLC 有很多應(yīng)用場景，不同的應(yīng)用場景對時延的指標要求是有差異的，有的要求50 ms，有的要求10 ms，有的可能要求小于1 ms。

表1 是3GPP 定義的部分應(yīng)用場景的時延要求[28-31]，有的時延甚至嚴格到0.5 ms，這是非常高的要求，目前該類應(yīng)用還非常少。因此運營商在建設(shè)URLLC 網(wǎng)絡(luò)時，要綜合考慮建網(wǎng)成本和應(yīng)用的要求。可以采用“架構(gòu)一步到位，邊緣節(jié)點逐步擴展”的原則。按照應(yīng)用需求的節(jié)奏，分階段完成部署。初期先集中建設(shè)URLLC 控制面網(wǎng)元，并在部分工業(yè)園區(qū)部署URLLC 用戶面網(wǎng)元，滿足部分客戶的部分應(yīng)用需求。發(fā)展后期再根據(jù)應(yīng)用類型和客戶數(shù)量的增多，部署更多的MEC 邊緣站點，并利用最優(yōu)路徑的多維協(xié)同技術(shù)，讓用戶在移動過程中一直保持超低時延的通信狀態(tài)。

表1 URLLC典型業(yè)務(wù)的時延要求

3.1 URLLC 部署初期

在建網(wǎng)初期，URLLC 應(yīng)用的需求比較少，主要是一些工業(yè)園區(qū)的工業(yè)控制有這樣的需求?？稍谑行某鞘屑薪ㄔO(shè)一套URLLC 核心網(wǎng)控制面網(wǎng)絡(luò)，例如AMF、SMF、PCF 等，這些控制面網(wǎng)元對應(yīng)用的時延沒什么影響，集中部署可以降低建設(shè)成本。而用戶面網(wǎng)元UPF 和園區(qū)應(yīng)用APP 以及URLLC 無線專網(wǎng)，采用按需部署的策略逐步建設(shè)[32-33]。

這個階段的用戶數(shù)少，園區(qū)應(yīng)用也不多，無需采用網(wǎng)絡(luò)切片建網(wǎng)，可以針對每個園區(qū)建設(shè)專網(wǎng)。當(dāng)園區(qū)有URLLC 需求時，運營商就在該園區(qū)內(nèi)部署URLLC 無線專網(wǎng)，在園區(qū)內(nèi)建設(shè)MEC，并把UPF 和園區(qū)APP 下沉部署在該MEC 中。

MEC 內(nèi)的UPF 和園區(qū)APP 在部署初始階段就需要做好安全隔離和安全加固措施，避免在初期引入安全風(fēng)險。針對MEC 內(nèi)的UPF，需要配置好本地分流策略，把需要極低時延的流量分流到本地APP，把其他流量路由到Internet 云端。

URLLC 網(wǎng)絡(luò)建好后，不能因為規(guī)模不大而降低網(wǎng)絡(luò)性能指標的要求。從某個工業(yè)園區(qū)的視角看，他的應(yīng)用和時延要求是完整和確定的。因此運營商為某個園區(qū)建好URLLC 網(wǎng)絡(luò)后，應(yīng)對該網(wǎng)絡(luò)啟動時延監(jiān)控功能，統(tǒng)計分析時延表現(xiàn)，及時發(fā)現(xiàn)問題并調(diào)優(yōu)網(wǎng)絡(luò)。

3.2 URLLC 部署中后期

在建網(wǎng)中期，URLLC 應(yīng)用的需求數(shù)量逐步增加，為了能靈活地為不同的園區(qū)和一些關(guān)鍵性的應(yīng)用提供差異化性能指標的網(wǎng)絡(luò)，需要采用網(wǎng)絡(luò)切片的方式進行建網(wǎng)?？梢詾槟硞€園區(qū)建設(shè)一個端到端的切片，也可以為某個應(yīng)用建設(shè)端到端的切片。建設(shè)什么樣的切片，需要運營商和園區(qū)客戶談，綜合考慮成本、靈活性、指標要求，再決定是否采用切片建網(wǎng)[34]。

在建網(wǎng)后期，預(yù)計車聯(lián)網(wǎng)等超低時延要求的應(yīng)用也成熟了，這些應(yīng)用服務(wù)的地理范圍比較廣，需要考慮用戶跨MEC 移動時的超低時延問題。因此這個階段首先要建設(shè)廣覆蓋的URLLC 無線網(wǎng)絡(luò)，確保用戶在漫游和移動過程中保持業(yè)務(wù)連續(xù)性。隨著基站的廣泛部署，相應(yīng)地也需要增加MEC 的分布式部署規(guī)模，做到基站部署到哪里，MEC 跟到哪里，MEC 內(nèi)的UPF 和APP 也跟到哪里。由于UE 會在大的地理范圍內(nèi)移動，需要APP 和UPF 支持最優(yōu)路徑的動態(tài)協(xié)同，確保UE 和APP 間的業(yè)務(wù)流量一直處在最短傳輸路徑上，能持續(xù)地獲得超低時延通信連接。

4 結(jié)束語

URLLC 的超低時延需求，必須通過系統(tǒng)性的端到端解決方案來滿足。從架構(gòu)層面的UPF 和APP 分布式下沉邊緣計算技術(shù)，到硬件層面的用戶面加速技術(shù)，到應(yīng)用層面的最短路徑優(yōu)化提升，最終到總體層面的端到端時延監(jiān)控技術(shù)，完整地構(gòu)建了一套解決方案[35]。而基于此方案的橫向由易到難，縱向由點到面的部署方案，讓URLLC 的部署更加有序和科學(xué)。

URLLC 是5G 應(yīng)用的核心技術(shù)，為工業(yè)4.0 變革、遠程醫(yī)療、自動駕駛等應(yīng)用提供了高質(zhì)量的通信基礎(chǔ)設(shè)施，它的成熟商用和廣泛部署，必將對未來世界產(chǎn)生深遠的影響。