任 馳，馬瑞濤（中國聯(lián)通研究院，北京 100176）

1 概述

3GPP 在R15階段針對5G 系統(tǒng)定義了一些有助于降低網(wǎng)絡(luò)端到端延遲并提升可靠性的特性，如SSC 模式2 或3 下的PDU 會話錨點(diǎn)重定位，AF 影響下的數(shù)據(jù)流量路由等，但單純的用戶面?zhèn)鬏斅窂絻?yōu)化并不能夠解決所有的問題，網(wǎng)絡(luò)中的其他因素如UE 移動性等仍有可能會導(dǎo)致用戶業(yè)務(wù)延遲和抖動的增加，進(jìn)而影響到極端性能要求下業(yè)務(wù)的體驗(yàn)。針對這些問題，3GPP 在R16 階段專門針對極高可靠性低延遲通信（uRLLC）業(yè)務(wù)場景定義了新的網(wǎng)絡(luò)架構(gòu)和增強(qiáng)能力要求，通過UE 和外部數(shù)據(jù)網(wǎng)絡(luò)之間用戶面的冗余傳輸機(jī)制，提升用戶業(yè)務(wù)的可靠性體驗(yàn)，進(jìn)而實(shí)現(xiàn)通過5G網(wǎng)絡(luò)滿足uRLLC業(yè)務(wù)性能需求的目標(biāo)。

為支持高可靠性通信能力，3GPP 基于uRLLC 業(yè)務(wù)需求，定義了2 種用戶面冗余傳輸方案以提升數(shù)據(jù)傳輸?shù)目煽啃?，分別為：基于雙連接的端到端冗余用戶面路徑方案和冗余N3/N9接口傳輸方案。

同時，為協(xié)助運(yùn)營商對uRLLC 業(yè)務(wù)進(jìn)行性能監(jiān)控和管理，定義了不同粒度的QoS 監(jiān)控機(jī)制，包括每UE的每QoS 流粒度的QoS 監(jiān)控和每GTP-U 隧道粒度的QoS監(jiān)控。

2 用于高可靠性通信的冗余傳輸機(jī)制

2.1 基于雙連接的端到端冗余用戶面路徑方案

為了支持高可靠性的uRLLC 業(yè)務(wù)，UE 可以在5G網(wǎng)絡(luò)中建立一對冗余的PDU 會話，為保障這2 個PDU會話用戶面數(shù)據(jù)傳輸互不影響，網(wǎng)絡(luò)應(yīng)確保這2 個PDU 會話的用戶面路徑是互不交叉的，該方案即為基于雙連接的端到端冗余用戶面路徑方案。在實(shí)際的會話建立過程中，UDM 通過向SMF 提供對應(yīng)的指示，指示SMF 該用戶所使用的業(yè)務(wù)是否允許建立冗余的PDU會話。

基于不同的業(yè)務(wù)場景和應(yīng)用能力，應(yīng)用側(cè)可以通過不同的高層協(xié)議，如IEEE TSN（Time Sensitive Networking）FRER（Frame Replication and Elimination for Reliability），利用冗余的用戶面路徑進(jìn)行端到端的數(shù)據(jù)流量分發(fā)，實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)在發(fā)端的復(fù)制和在收端的消除。如當(dāng)應(yīng)用傳輸上行業(yè)務(wù)流量時，UE端的應(yīng)用客戶端可以進(jìn)行上行數(shù)據(jù)報文的復(fù)制，并將重復(fù)的上行數(shù)據(jù)報文通過所建立的2個冗余PDU會話發(fā)送至應(yīng)用服務(wù)器端，應(yīng)用服務(wù)器端在接收到復(fù)制的冗余上行數(shù)據(jù)報文后，基于特定的機(jī)制進(jìn)行冗余數(shù)據(jù)報文的消除以及數(shù)據(jù)報文的排序，完成上行數(shù)據(jù)的發(fā)送和接收。反之，下行數(shù)據(jù)的發(fā)送和接收也可以通過應(yīng)用服務(wù)器端的數(shù)據(jù)報文復(fù)制以及UE 應(yīng)用客戶端的數(shù)據(jù)報文消除實(shí)現(xiàn)。所有的冗余傳輸機(jī)制通過應(yīng)用層實(shí)現(xiàn)，對3GPP系統(tǒng)本身沒有特殊的要求。

為了建立完全冗余的端到端用戶面路徑，運(yùn)營商在實(shí)際的網(wǎng)絡(luò)部署中應(yīng)該盡可能確保冗余系統(tǒng)間各自的獨(dú)立性，包括：

a）RAN 支持雙連接能力，并且在uRLLC 業(yè)務(wù)的目標(biāo)區(qū)域內(nèi)，支持雙連接的RAN 側(cè)覆蓋足夠滿足業(yè)務(wù)要求。

b）UE支持雙連接功能。

c）核心網(wǎng)側(cè)的UPF 部署需要和RAN 側(cè)部署對齊，支持建立冗余用戶面路徑。

d）底層的傳輸拓?fù)湟矐?yīng)和RAN 以及UPF 部署對齊，確保傳輸網(wǎng)轉(zhuǎn)發(fā)面路徑也是互不交叉的。

e）物理網(wǎng)絡(luò)的拓?fù)浜偷乩矸植紤?yīng)在運(yùn)營商認(rèn)為的足夠范圍內(nèi)支持必要的冗余用戶面路徑。

f）整體冗余用戶面的操作應(yīng)在運(yùn)營商認(rèn)為的范圍內(nèi)足夠獨(dú)立，如分別設(shè)置獨(dú)立的供電系統(tǒng)等。

圖1為使用冗余機(jī)制時的雙PDU會話用戶面資源配置示例。

圖1 基于雙連接的端到端冗余用戶面路徑方案架構(gòu)示意

其中一個PDU 會話由UE 通過主NG-RAN（Master NG-RAN）連接到PDU 會話錨點(diǎn)UPF1，并最終連接到數(shù)據(jù)網(wǎng)絡(luò)（DN），另一個PDU 會話由UE 通過副NGRAN（Secondary NG-RAN）連 接 到PDU 會 話 錨 點(diǎn)UPF2，并最終連接到同一個DN，在此過程中，NGRAN 應(yīng)能夠感知2 個PDU 會話的冗余用戶面資源是否是通過2 個NG-RAN 節(jié)點(diǎn)建立的，以便進(jìn)行后續(xù)的用戶移動性及會話控制。需要注意的是，基于5G系統(tǒng)的移動性管理原則，即使UE的雙PDU會話是通過2個NG-RAN 節(jié)點(diǎn)建立的，該UE 也僅有1 個到AMF 的N1連接，即這2個NG-RAN 都通過N2接口連接到同一個AMF。

基于UE 建立的2 個PDU 會話，5G 系統(tǒng)為UE 建立2 條獨(dú)立的用戶面路徑。5G 網(wǎng)絡(luò)可以通過UE 路由選擇策略（URSP——UE Route Selection Policy）協(xié)助UE建立到同一個DN 的冗余PDU 會話，即PCF 可以為UE的同一個應(yīng)用分別配置2 條不同的URSP 策略，這2 條URSP 策略應(yīng)配置不同的流量描述符，以確保UE 在套用這2條URSP 規(guī)則時，會分別建立2個不同的PDU 會話。在實(shí)際的應(yīng)用中，URSP 的配置和應(yīng)用側(cè)的系統(tǒng)架構(gòu)及能力高度相關(guān)，但應(yīng)用側(cè)的配置和部署要求不屬于運(yùn)營商網(wǎng)絡(luò)的管理范圍。

在具體的冗余PDU 會話建立和管理過程中，由UE 發(fā)起2 個互為冗余的PDU 會話建立請求，UE 基于不同的URSP 策略在2 個PDU 會話的建立請求中分別攜帶不同的DNN 和S-NSSAI，并由SMF 基于PCF 提供的PDU 會話相關(guān)策略信息、UE 指示的DNN/S-NSSAI以及從UDM 獲得的用戶簽約信息決定PDU 會話是否應(yīng)該按冗余PDU 會話的標(biāo)準(zhǔn)進(jìn)行處理。SMF 基于這些信息生成一個冗余序列號（RSN——Redundancy Sequence Number）用于區(qū)分這2 個互為冗余的PDU 會話，并通過RSN 向RAN 側(cè)指示冗余用戶面資源需求。運(yùn)營商基于DNN 和S-NSSAI 的組合配置SMF 為不同的PDU 會話選擇不同的UPF，并確保冗余PDU 會話的用戶面路徑互不相交。

在PDU 會話建立，或會話狀態(tài)轉(zhuǎn)換為CM-CONNECTED 時，網(wǎng)絡(luò)通過RSN 參數(shù)向NG-RAN 指示通過雙連接為對應(yīng)的PDU 會話提供冗余的用戶面資源，RSN 具體的取值指示了PDU 會話對應(yīng)的冗余用戶面需求。與不同的RSN 取值相關(guān)聯(lián)的PDU 會話需要通過不同的、冗余的用戶面資源進(jìn)行建立，基于RSN 和RAN 側(cè)的配置，由NG-RAN 完成雙連接的建立，實(shí)現(xiàn)端到端冗余用戶面路徑的建立。

NG-RAN 根據(jù)自身配置，結(jié)合由RSN 指示的通過雙連接建立的用戶面資源需求判斷針對一個PDU 會話的RAN 資源建立請求是否可以滿足，如果可以滿足針對PDU 會話的RAN 資源建立請求，即使由RSN 指示的用戶面需求無法滿足，PDU 會話也可以成功建立，而如果RAN 判斷無法滿足針對PDU 會話的RAN資源建立請求，則RAN 會拒絕該請求并最終導(dǎo)致SMF向UE 拒絕PDU 會話建立請求。在實(shí)際的業(yè)務(wù)過程中，針對每個PDU 會話是否能夠被建立的判斷是分別進(jìn)行的，即使冗余PDU 會話其中之一的建立請求被網(wǎng)絡(luò)拒絕，也不會影響另一個PDU 會話的建立。RAN 基于網(wǎng)絡(luò)配置判斷是否在無法繼續(xù)保持由RSN 參數(shù)指示的資源時向SMF 發(fā)送相關(guān)的通知，以便SMF 進(jìn)一步?jīng)Q定是否釋放對應(yīng)的PDU會話。

在移動性管理過程中，RSN 指示會在切換過程中從源NG-RAN發(fā)送到目標(biāo)NG-RAN。

2.2 冗余N3/N9接口傳輸方案

除2.1 節(jié)介紹的基于雙連接的端到端冗余用戶面路徑方案外，為解決可能的由特定回傳網(wǎng)絡(luò)部署環(huán)境等原因造成的單N3隧道可靠性不足的問題，冗余傳輸機(jī)制也可能會部署在PDU 會話錨點(diǎn)UPF 和NG-RAN之間，即通過建立關(guān)聯(lián)到同一個PDU 會話的2 個獨(dú)立的N3 隧道實(shí)現(xiàn)。這2 個N3 隧道可以進(jìn)一步的通過關(guān)聯(lián)到不同的傳輸層路徑進(jìn)一步增強(qiáng)其可靠性。

為確保所建立的用于冗余傳輸?shù)? 個N3 隧道通過互不交叉的傳輸層路徑進(jìn)行數(shù)據(jù)傳輸，SMF 或PDU會話錨點(diǎn)UPF 可在隧道信息中提供不同的路由信息，如不同的IP 地址，或不同的網(wǎng)絡(luò)實(shí)例，這些路由信息進(jìn)一步由網(wǎng)絡(luò)基于網(wǎng)絡(luò)部署配置映射為互不交叉的傳輸層路徑。在對應(yīng)的隧道建立過程中，SMF 向NGRAN 和PDU 會話錨點(diǎn)UPF 指示2 個CN/AN 隧道信息其中之一用作對應(yīng)PDU 會話的冗余隧道。利用2 個N3/N9 隧道的冗余傳輸以QoS 流的粒度進(jìn)行，同一個QoS 流在冗余N3/N9 隧道中的傳輸共享同一個QoS 流ID。

在一個uRLLC 業(yè)務(wù)的QoS 流建立期間，或建立完成后，如果SMF 基于授權(quán)的5QI、NG-RAN 節(jié)點(diǎn)能力、運(yùn)營商配置等因素決定執(zhí)行冗余傳輸，SMF 分別通過N2信息和N4接口通知NG-RAN 和PDU會話錨點(diǎn)UPF建立冗余用戶面隧道。在這種情況下，NG-RAN 也需要在隧道信息中提供不同的路由信息如不同的IP 地址，以協(xié)助網(wǎng)絡(luò)將這些路由信息映射為互不交叉的傳輸層路徑。在用于SMF 決定是否應(yīng)用冗余傳輸?shù)男畔⒅?，NG-RAN 節(jié)點(diǎn)對N3/N9 傳輸能力的支持情況可以在SMF 中預(yù)先進(jìn)行配置，配置的粒度可以基于網(wǎng)絡(luò)切片粒度或基于SMF服務(wù)區(qū)域粒度。

當(dāng)用戶面路徑僅涉及N3 接口時，即無中間UPF（I-UPF）插入情況下，冗余N3 接口傳輸方案如圖2 所示。

圖2 無中間UPF情況下的冗余N3接口傳輸方案架構(gòu)示意

針對PDU 會話錨點(diǎn)UPF 從DN 收到的該QoS 流的每個下行數(shù)據(jù)報文，PDU 會話錨點(diǎn)UPF 對報文進(jìn)行復(fù)制，并為所復(fù)制的數(shù)據(jù)報文分配相同的GTP-U 序列號以協(xié)助后續(xù)的冗余傳輸，NG-RAN 在接收到復(fù)制的數(shù)據(jù)報文后，將具有相同GTP-U 序列號的數(shù)據(jù)報文中冗余的數(shù)據(jù)報文消除，之后將保留的數(shù)據(jù)報文轉(zhuǎn)發(fā)給UE。而針對NG-RAN 從UE 收到的該QoS流的每個上行數(shù)據(jù)報文，則由NG-RAN 對報文進(jìn)行復(fù)制以及相同的GTP-U 序列號的分配，這些復(fù)制的數(shù)據(jù)報文分別通過2 條N3 隧道傳輸至PDU 會話錨點(diǎn)UPF，UPF 在接收到復(fù)制的數(shù)據(jù)報文后，將具有相同GTP-U 序列號的數(shù)據(jù)報文中冗余的數(shù)據(jù)報文消除，之后將保留的數(shù)據(jù)報文轉(zhuǎn)發(fā)至DN。

當(dāng)用戶面路徑涉及中間UPF（I-UPF）插入時，冗余N3/N9接口傳輸方案如圖3所示。

圖3 存在中間UPF情況下的冗余N3/N9接口傳輸方案架構(gòu)

針對同時在N3和N9接口執(zhí)行冗余傳輸機(jī)制的情況，在NG-RAN 和PDU 會話錨點(diǎn)UPF 之間會插入2 個中間UPF，這2 個中間UPF 服務(wù)于同一個PDU 會話的同一個uRLLC 業(yè)務(wù)的QoS 流，此時針對下行流量，由PDU 會話錨點(diǎn)UPF 對下行數(shù)據(jù)報文進(jìn)行復(fù)制并分配相同的GTP-U 序列號，然后將這2 個具有相同GTP-U序列號的下行數(shù)據(jù)報文分別通過2 條N9 隧道發(fā)送到不同的中間UPF，再分別由這2 個中間UPF 通過不同的N3 隧道發(fā)送至NG-RAN，最終NG-RAN 完成重復(fù)數(shù)據(jù)報文的消除后將數(shù)據(jù)發(fā)送給UE。上行流量的數(shù)據(jù)報文傳送機(jī)制和下行類似。在涉及插入中間UPF的情況下，NG-RAN 和PDU 會話錨點(diǎn)UPF 需要如上文所述支持?jǐn)?shù)據(jù)報文的復(fù)制和消除功能，但中間UPF 不需要支持和執(zhí)行這些功能。

2.3 傳輸層的冗余傳輸

在數(shù)據(jù)網(wǎng)絡(luò)DN 的應(yīng)用層不支持專門用于冗余傳輸?shù)膮f(xié)議（如IEEE FRER），同時5G 系統(tǒng)也不支持冗余的N3 隧道機(jī)制的情況下，仍然可以通過在UPF 和NG-RAN 之間提供2條不相交的回傳傳輸路徑實(shí)現(xiàn)冗余傳輸能力，在這種情況下，NG-RAN 和UPF 內(nèi)的冗余處理功能利用這2條獨(dú)立的傳輸路徑實(shí)現(xiàn)對上下行uRLLC 業(yè)務(wù)流量的冗余處理。單純的傳輸層冗余機(jī)制不影響已有的3GPP協(xié)議。

UE 發(fā)起一個用于uRLLC 業(yè)務(wù)的PDU 會話，SMF通過DNN、S-NSSAI、UPF 支持傳輸層冗余機(jī)制能力的情況等信息為該P(yáng)DU 會話選擇一個合適UPF，并指示UPF 和NG-RAN 之間建立一條N3 隧道。針對下行數(shù)據(jù)傳輸，UPF 在單一的N3 隧道上發(fā)送下行數(shù)據(jù)報文，UPF的冗余處理功能在傳輸層進(jìn)行下行數(shù)據(jù)報文的復(fù)制，NG-RAN 的冗余處理功能消除復(fù)制數(shù)據(jù)報文并將其發(fā)送給NG-RAN 的正常用戶面報文處理模塊，并由NG-RAN 最終發(fā)送給UE。同理，針對上行數(shù)據(jù)報文，由NG-RAN 的冗余處理功能在傳輸層的回傳部分對報文進(jìn)行復(fù)制，由UPF 的冗余處理功能消除復(fù)制報文并轉(zhuǎn)發(fā)給UPF 的正常用戶面報文處理模塊，并最終轉(zhuǎn)發(fā)至數(shù)據(jù)網(wǎng)絡(luò)DN。

3 針對uRLLC業(yè)務(wù)的QoS監(jiān)控

為配合移動網(wǎng)運(yùn)營商進(jìn)行uRLLC 業(yè)務(wù)的性能監(jiān)控和管理，5G 系統(tǒng)支持用于QoS 監(jiān)控的報文延遲測量機(jī)制。在UE 和PDU 會話錨點(diǎn)UPF 之間的報文延遲包括上下行報文的Uu 接口延遲以及NG-RAN 和PDU 會話錨點(diǎn)UPF 之間的延遲。針對上下行數(shù)據(jù)報文延遲的QoS 監(jiān)控可以在不同粒度上進(jìn)行，包括每UE 的每QoS流粒度以及每GTP-U 隧道粒度等。具體的QoS監(jiān)控執(zhí)行粒度可基于運(yùn)營商策略，第三方應(yīng)用需求等因素決定，并通過PCF 的PCC 策略進(jìn)行配置、下發(fā)和執(zhí)行。

3.1 每UE每QoS流粒度

以每UE 每QoS 流粒度進(jìn)行的上下行報文端到端延遲測量由SMF 在PDU 會話建立或修改的過程中激活，在此過程中，SMF 分別向PDU 會話錨點(diǎn)UPF 和NG-RAN 發(fā)送QoS 監(jiān)控請求，要求進(jìn)行UE 和PDU 會話錨點(diǎn)之間的上下行報文延遲測量，SMF 基于PCF 發(fā)送的QoS監(jiān)控策略信息生成對應(yīng)的監(jiān)控參數(shù)并包含在發(fā)送給NG-RAN 和PDU 會話錨點(diǎn)UPF 的QoS 監(jiān)控請求中，對應(yīng)的監(jiān)控參數(shù)也可以在SMF本地進(jìn)行配置。

在端到端的報文延遲測量中，由NG-RAN 基于SMF 下發(fā)的監(jiān)控參數(shù)進(jìn)行Uu 接口的上下行報文延遲測量，并將測量結(jié)果通過上行數(shù)據(jù)報文發(fā)送給PDU 會話錨點(diǎn)UPF，NG-RAN 也可以在沒有可用的上行數(shù)據(jù)報文的情況下自行生成一個偽上行報文（Dummy UL Packet），并將Uu 接口的上下行報文延遲測量結(jié)果包含在其中上報給PDU會話錨點(diǎn)UPF。

如果NG-RAN 和PDU 會話錨點(diǎn)是時間同步的，那么單向的NG-RAN 和PDU 會話錨點(diǎn)UPF 之間的報文延遲監(jiān)控通過在GTP-U 報文頭中傳送時間戳的方式支持，NG-RAN和PDU會話錨點(diǎn)UPF分別在GTP-U的報文頭中封裝QoS 監(jiān)控報文指示，用于表示該報文是用于上下行報文延遲測量的，并同時在其中封裝本地時間。PDU會話錨點(diǎn)UPF基于所接收到的QoS監(jiān)控報文中的時間戳以及本地時間進(jìn)行NG-RAN 和PDU 會話錨點(diǎn)UPF 之間的上行和下行報文延遲的計算，并結(jié)合接收到的由NG-RAN 上報的Uu 接口的上下行報文延遲，最終得到端到端的數(shù)據(jù)報文延遲并上報給SMF。

如果NG-RAN 和PDU 會話錨點(diǎn)UPF 不是時間同步的，那么后續(xù)的計算需要假設(shè)在NG-RAN 和PDU 會話錨點(diǎn)UPF 之間的上行和下行的數(shù)據(jù)報文延遲是一樣的，在此前提下，由PDU 會話錨點(diǎn)UPF 生成監(jiān)控報文并發(fā)送給NG-RAN，在此過程中：

a）PDU 會話錨點(diǎn)UPF 在發(fā)送下行數(shù)據(jù)報文時，在GTP-U 報文頭中封裝QoS 監(jiān)控報文指示以及此時PDU會話錨點(diǎn)UPF的本地時間T1。

b）NG-RAN 記錄接收到的來自PDU 會話錨點(diǎn)UPF 的QoS 監(jiān)控報文中的時間戳T1 以及NG-RAN 接收到該報文時NG-RAN 的本地時間T2，同時發(fā)起Uu接口上下行報文延遲測量。

c）在接收到UE 發(fā)送的上行數(shù)據(jù)報文或NG-RAN發(fā)送偽上行報文用于監(jiān)控響應(yīng)時，NG-RAN 在上行報文的GTP-U 報文頭中封裝QoS 監(jiān)控指示、上述PDU 錨點(diǎn)發(fā)送下行報文時封裝的時間戳T1、NG-RAN 收到T1報文時的本地時間T2 以及此時NG-RAN 的本地時間T3，并將其發(fā)送給PDU會話錨點(diǎn)UPF。

d）PDU 會話錨點(diǎn)UPF 記錄收到上述上行QoS 監(jiān)控響應(yīng)報文時的時間戳T4，并通過公式（T2-T1+T4-T3）/2 計算得到NG-RAN 和PDU 會話錨點(diǎn)UPF 之間的數(shù)據(jù)報文延遲，結(jié)合從NG-RAN 收到的Uu 接口報文延遲得到端到端的報文延遲，最終上報給SMF。

在應(yīng)用了N3/N9 接口冗余傳輸?shù)那闆r下，PDU 會話錨點(diǎn)UPF和NG-RAN 將分別在2條用戶面路徑上進(jìn)行QoS 監(jiān)控，并由PDU 會話錨點(diǎn)UPF 向SMF 分別報告2條用戶面路徑的報文延遲。

3.2 每GTP-U隧道粒度

每GTP-U 隧道粒度的QoS 監(jiān)控同樣由SMF 發(fā)起，并由SMF 分別向UPF 和NG-RAN 下發(fā)對應(yīng)的QoS 監(jiān)控請求。NG-RAN 或UPF 通過向?qū)Χ税l(fā)送Echo請求，并測量發(fā)送Echo 請求和收到Echo 響應(yīng)之間的時長來估算NG-RAN 和UPF 之間GTP 隧道的雙向延遲（RTT——Round Trip Delay），NG-RAN 或UPF 通過累加RTT/2、節(jié)點(diǎn)自身處理時長以及可能的其他節(jié)點(diǎn)如IP設(shè)備的處理時長，得到估算的GTP-U 隧道的數(shù)據(jù)報文延遲。

為了能夠及時掌握傳輸延遲的變化，NG-RAN 或UPF 可以周期性地進(jìn)行RTT 的測量。GTP-U 隧道粒度的QoS 監(jiān)控由接收并存儲了包括報文延遲預(yù)算等QoS 信息的GTP-U 端點(diǎn)執(zhí)行，該GTP-U 端點(diǎn)通過比較接收到的累加的報文延遲和QoS參數(shù)中的報文延遲預(yù)算判斷當(dāng)前的RTT 是否超出了所要求的延遲需求，如果當(dāng)前的GTP-U 隧道延遲超出了業(yè)務(wù)所要求的延遲要求，GTP-U 端點(diǎn)將會基于運(yùn)營商的管理需求觸發(fā)一個到對應(yīng)控制面網(wǎng)絡(luò)功能如SMF 或OAM 的QoS 監(jiān)控告警信令，用于觸發(fā)運(yùn)營商進(jìn)行后續(xù)的uRLLC 業(yè)務(wù)性能管理和優(yōu)化過程。

4 結(jié)束語

uRLLC 是垂直行業(yè)尤其是工業(yè)制造相關(guān)產(chǎn)業(yè)所關(guān)注的重要場景，同時也是移動網(wǎng)運(yùn)營商介入垂直行業(yè)市場所需要具備的重要能力。本文根據(jù)3GPP 相關(guān)標(biāo)準(zhǔn)的要求，重點(diǎn)分析了5G 核心網(wǎng)支持uRLLC 能力的系統(tǒng)架構(gòu)增強(qiáng)要求，討論了用于uRLLC 業(yè)務(wù)的幾種不同的冗余傳輸機(jī)制，并介紹了支持運(yùn)營商進(jìn)行uRLLC業(yè)務(wù)性能管理的QoS監(jiān)控方案。

uRLLC 所面向的業(yè)務(wù)場景對業(yè)務(wù)延遲、抖動以及可靠性等性能要求相對苛刻，相關(guān)的能力增強(qiáng)除了對5G 網(wǎng)絡(luò)設(shè)備功能本身的要求外，還對運(yùn)營商端到端整體的網(wǎng)絡(luò)部署如無線側(cè)NG-RAN 的覆蓋規(guī)劃，傳輸網(wǎng)的冗余傳輸路徑設(shè)置等有較高的需求，極致的uRLLC業(yè)務(wù)體驗(yàn)保障也必將帶來網(wǎng)絡(luò)建設(shè)和運(yùn)營成本的水漲船高，因此在后續(xù)針對uRLLC 業(yè)務(wù)需求和場景的網(wǎng)絡(luò)部署及業(yè)務(wù)對接落地的過程中，如何在考慮網(wǎng)絡(luò)建設(shè)成本的情況下滿足行業(yè)用戶的業(yè)務(wù)需求，形成uRLLC 整體性和系統(tǒng)性的建設(shè)和運(yùn)營思路，將是下一步運(yùn)營商網(wǎng)絡(luò)演進(jìn)研究和網(wǎng)絡(luò)業(yè)務(wù)運(yùn)營過程中需要重點(diǎn)考慮的內(nèi)容。