業(yè)務(wù)感知技術(shù)在5G回傳網(wǎng)絡(luò)中的應(yīng)用及演進(jìn)思考*

李振文 李芳

(中國信息通信研究院技術(shù)與標(biāo)準(zhǔn)研究所，北京 100191)

0 引言

5G終端與基站之間無線傳輸?shù)碾姶怒h(huán)境復(fù)雜，可能產(chǎn)生反射、折射、繞射、多普勒效應(yīng)等現(xiàn)象，從而引起多徑干擾、信號(hào)傳播延遲和展寬等問題，為業(yè)務(wù)傳輸性能帶來一定的不確定性，3GPP的R17和R18版本正在研究增強(qiáng)5G無線接入網(wǎng)切片服務(wù)能力和確定性傳輸技術(shù)。由于5G網(wǎng)絡(luò)的確定性由無線接入網(wǎng)、承載網(wǎng)和核心網(wǎng)共同構(gòu)建，所以回傳網(wǎng)絡(luò)應(yīng)盡可能提高傳輸質(zhì)量。

5G發(fā)展進(jìn)入成熟期，主要業(yè)務(wù)從to C為主向to B+to C轉(zhuǎn)變，精細(xì)化的SLA保證和差異化承載能力更加凸顯。5G行業(yè)專網(wǎng)的發(fā)展，需要在一張物理網(wǎng)絡(luò)上承載多種業(yè)務(wù)，而不同行業(yè)的業(yè)務(wù)特點(diǎn)也不同，需要進(jìn)行差異化承載和定制化的SLA保證，除了通過網(wǎng)絡(luò)的軟、硬切片技術(shù)進(jìn)行傳輸過程中關(guān)鍵業(yè)務(wù)的隔離以外，還需要業(yè)務(wù)感知技術(shù)將用戶和業(yè)務(wù)的類別、SLA需求等更豐富的信息傳遞給網(wǎng)絡(luò)，實(shí)現(xiàn)網(wǎng)絡(luò)賦能，進(jìn)一步支撐云網(wǎng)融合及將來的算力網(wǎng)絡(luò)發(fā)展。

1 5G網(wǎng)絡(luò)中存在的問題分析

5G網(wǎng)絡(luò)由無線接入網(wǎng)(AN)、移動(dòng)承載網(wǎng)(TN)和核心網(wǎng)(CN)共同構(gòu)成，在為移動(dòng)終端提供語音、短信等基礎(chǔ)電信服務(wù)的過程中，無線接入網(wǎng)和核心網(wǎng)直接參與處理用戶的業(yè)務(wù)信息；從4G網(wǎng)絡(luò)開始，移動(dòng)互聯(lián)網(wǎng)業(yè)務(wù)已經(jīng)逐漸成為了業(yè)務(wù)的主要部分，但是在移動(dòng)互聯(lián)網(wǎng)業(yè)務(wù)處理流程中，5G網(wǎng)絡(luò)只是提供一個(gè)Underlay的“管道”，無法感知業(yè)務(wù)的SLA需求，導(dǎo)致運(yùn)營(yíng)商不能針對(duì)不同的用戶或業(yè)務(wù)提供精細(xì)化、差異化的服務(wù)，從而逐步陷入低價(jià)賣流量、增量不增收的困境。從長(zhǎng)期來看，這不利于我國5G網(wǎng)絡(luò)的健康發(fā)展。從5G業(yè)務(wù)端到端處理流程分析，導(dǎo)致5G網(wǎng)絡(luò)“管道化”的主要原因有以下三方面。

1.1 無線接入和核心網(wǎng)側(cè)GTP隧道封裝導(dǎo)致回傳網(wǎng)絡(luò)難以識(shí)別用戶業(yè)務(wù)特征

GTP-U是3GPP早期定義的用戶面?zhèn)鬏攨f(xié)議，最初用在GPRS網(wǎng)絡(luò)節(jié)點(diǎn)間用戶面數(shù)據(jù)包的傳輸，并在后來的3G/4G/5G移動(dòng)系統(tǒng)中一直被延續(xù)使用。GTP-U傳輸協(xié)議的特點(diǎn)是：在同一IP端到端連接上，構(gòu)建點(diǎn)對(duì)點(diǎn)的隧道封裝傳輸協(xié)議，提供多路傳輸復(fù)用、路徑管理(GTP-U自己還有“帶內(nèi)控制消息”用于隧道Path管理)等能力。GTP-U隧道傳輸協(xié)議從2.5G GPRS系統(tǒng)開始被運(yùn)用，在傳統(tǒng)蜂窩非云化的電信網(wǎng)絡(luò)中非常經(jīng)典。GTP-U協(xié)議一直由3GPP控制主導(dǎo)，可按需不斷地進(jìn)行內(nèi)容擴(kuò)展，但也難以適應(yīng)未來的云化網(wǎng)絡(luò)特征[1]?；貍骶W(wǎng)從無線接入網(wǎng)和核心網(wǎng)N3接口接收的用戶面數(shù)據(jù)都是帶有GTP-U封裝的，這在一定程度上加大了回傳網(wǎng)設(shè)備識(shí)別業(yè)務(wù)特征的難度。

1.2 傳統(tǒng)的DNS和業(yè)務(wù)系統(tǒng)調(diào)度機(jī)制未考慮精細(xì)化SLA業(yè)務(wù)需求

DNS是互聯(lián)網(wǎng)的一項(xiàng)服務(wù)，它作為將域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫，用戶能夠更方便地訪問互聯(lián)網(wǎng)。DNS和業(yè)務(wù)系統(tǒng)當(dāng)前確定目的服務(wù)器的主要依據(jù)是接收到用戶終端DNS解析請(qǐng)求的DNS服務(wù)器所在的運(yùn)營(yíng)商、地域信息，但如果用戶終端中配置的DNS服務(wù)器地址配置錯(cuò)誤，或者配置為公共的DNS服務(wù)器，最終用戶終端得到的服務(wù)器地址就會(huì)出現(xiàn)偏差。為了改進(jìn)這個(gè)問題，阿里云等部署了HTTPDNS技術(shù)，用戶終端通過HTTP向HTTPDNS服務(wù)器發(fā)出域名解析請(qǐng)求，此時(shí)HTTPDNS服務(wù)器可以獲取終端的精確IP地址，并基于此IP進(jìn)行調(diào)度。但這種調(diào)度方式仍然沒有將用戶終端與目的服務(wù)器之間網(wǎng)絡(luò)的SLA指標(biāo)納入考慮范圍，如果鏈路出現(xiàn)擁塞，就可能導(dǎo)致用戶的服務(wù)質(zhì)量劣化。

1.3 5G回傳網(wǎng)絡(luò)中的算路機(jī)制未考慮應(yīng)用層需求

在5G回傳網(wǎng)絡(luò)中，傳統(tǒng)的IP路由或MPLS技術(shù)不感知業(yè)務(wù)，只負(fù)責(zé)按照網(wǎng)絡(luò)層度量值或人工設(shè)置的路徑約束進(jìn)行數(shù)據(jù)報(bào)文的轉(zhuǎn)發(fā)。通過鏈路帶寬計(jì)算得到路由協(xié)議中的度量值，也可以手工配置。近年來，隨著SDN技術(shù)的發(fā)展，部分廠商支持在計(jì)算轉(zhuǎn)發(fā)路徑的因子中增加網(wǎng)絡(luò)時(shí)延信息，但網(wǎng)絡(luò)層與應(yīng)用層業(yè)務(wù)依然是割裂的，網(wǎng)絡(luò)層的路徑計(jì)算結(jié)果無法與應(yīng)用層的需求實(shí)時(shí)進(jìn)行匹配。

2 基于數(shù)據(jù)傳輸網(wǎng)絡(luò)的業(yè)務(wù)感知技術(shù)

為了解決數(shù)據(jù)傳輸網(wǎng)絡(luò)無法獲取到應(yīng)用層業(yè)務(wù)需求信息的問題，業(yè)界提出了業(yè)務(wù)感知技術(shù)，當(dāng)前主要分為以下兩類。

2.1 APN6(Application-aware IPv6 networking)[2]

APN6是在數(shù)據(jù)平面利用IPv6報(bào)文擴(kuò)展頭(Extension Headers)，如逐跳選項(xiàng)頭(Hop-by-Hop Options Header)、段路由頭(Segment Routing Header)的可編程空間，攜帶應(yīng)用的相關(guān)信息(標(biāo)識(shí)和需求)到網(wǎng)絡(luò)中，網(wǎng)絡(luò)設(shè)備依據(jù)這些信息為其提供相應(yīng)的網(wǎng)絡(luò)服務(wù)，如將報(bào)文映射進(jìn)相應(yīng)的能夠保障其SLA的SRv6路徑等。應(yīng)用感知信息可以由用戶終端設(shè)備或應(yīng)用直接生成，也可以由網(wǎng)絡(luò)邊緣設(shè)備生成，分別對(duì)應(yīng)APN6的主機(jī)側(cè)方案和網(wǎng)絡(luò)側(cè)方案[3]。

2.2 SRN(Software Resolved Networks)[4]

SRN架構(gòu)和流程如圖1所示。在控制平面，基于RFC 6891進(jìn)行DNS協(xié)議擴(kuò)展，實(shí)現(xiàn)了用戶終端、服務(wù)器與SDN控制器和接入路由器的交互。用戶終端通過擴(kuò)展的DNS協(xié)議，將應(yīng)用SLA需求信息(如帶寬和時(shí)延等)通過DNS代理轉(zhuǎn)發(fā)給DNS解析器，并暫時(shí)緩存DNS解析器應(yīng)答的DNS服務(wù)器IP地址信息；DNS代理向SDN控制器發(fā)送到DNS服務(wù)器的路徑請(qǐng)求，由SDN控制器綜合網(wǎng)絡(luò)鏈路狀態(tài)和應(yīng)用需求計(jì)算出可到達(dá)DNS服務(wù)器的SRv6-Policy，并下發(fā)給接入路由器的路由管理組件進(jìn)行轉(zhuǎn)發(fā)表項(xiàng)的安裝；DNS代理將DNS解析器返回的應(yīng)用服務(wù)器IP地址和SDN控制器的路徑計(jì)算結(jié)果BSID一起應(yīng)答給用戶終端。為了防止網(wǎng)絡(luò)設(shè)備的故障導(dǎo)致服務(wù)劣化，網(wǎng)絡(luò)狀態(tài)監(jiān)控組件會(huì)實(shí)時(shí)刷新OSPF路由信息，并及時(shí)通知SDN控制器進(jìn)行同步更新。在轉(zhuǎn)發(fā)平面，用戶終端發(fā)送數(shù)據(jù)包時(shí)，攜帶DNS代理下發(fā)的BSID，接入路由器將數(shù)據(jù)包沿控制器下發(fā)的SRv6-Policy轉(zhuǎn)發(fā)給網(wǎng)絡(luò)中的應(yīng)用服務(wù)器。

為了提升網(wǎng)絡(luò)與業(yè)務(wù)的關(guān)聯(lián)性，APN6和SRN提出了不同的解決思路，它們的數(shù)據(jù)面轉(zhuǎn)發(fā)都基于SRv6技術(shù)，但攜帶業(yè)務(wù)層信息的方式不用，APN6是在IPv6的擴(kuò)展頭中封裝應(yīng)用信息及SLA需求信息，可用的擴(kuò)展空間非常豐富(128 bit/SID)。而SRN是基于控制面的DNS協(xié)議進(jìn)行擴(kuò)展，相對(duì)攜帶信息的空間較少，只能攜帶帶寬、時(shí)延等基本的SLA需求信息，它的優(yōu)勢(shì)是這是一個(gè)輕量級(jí)的方案，對(duì)企業(yè)的DNS服務(wù)器和主機(jī)(LINUX內(nèi)核)進(jìn)行軟件升級(jí)即可，不需要運(yùn)營(yíng)商網(wǎng)絡(luò)設(shè)備升級(jí)，也不依賴眾多的應(yīng)用生態(tài)的支持，所以實(shí)施起來相對(duì)更容易，兩者詳細(xì)對(duì)比參見表1。

表1 APN6與SRN的對(duì)比

3 面向云網(wǎng)融合的5G回傳業(yè)務(wù)感知方案架構(gòu)

從業(yè)務(wù)發(fā)展趨勢(shì)來看，5G網(wǎng)絡(luò)中的業(yè)務(wù)種類，流量模型與3G/4G相比都發(fā)生了顯著的變化，尤其是行業(yè)業(yè)務(wù)的應(yīng)用提出了比個(gè)人業(yè)務(wù)更嚴(yán)苛的需求。為了更好地滿足這些需求，并加快構(gòu)建數(shù)字化轉(zhuǎn)型的新型基礎(chǔ)設(shè)施，我國運(yùn)營(yíng)商都把云和網(wǎng)的融合確定為網(wǎng)絡(luò)發(fā)展演進(jìn)的重要方向，期望通過云網(wǎng)融合推動(dòng)5G應(yīng)用創(chuàng)新發(fā)展。面對(duì)長(zhǎng)久以來云業(yè)務(wù)與網(wǎng)絡(luò)各自獨(dú)立發(fā)展的現(xiàn)狀，當(dāng)前需要思考如何逐漸改變這種解耦的發(fā)展方式，在這個(gè)過程中，網(wǎng)絡(luò)對(duì)業(yè)務(wù)的感知技術(shù)成為業(yè)務(wù)層和網(wǎng)絡(luò)層之間協(xié)同發(fā)展的紐帶。

APN和SRN兩類技術(shù)分別是針對(duì)廣域和企業(yè)場(chǎng)景進(jìn)行業(yè)務(wù)感知，但是對(duì)于5G網(wǎng)絡(luò)，由于其業(yè)務(wù)報(bào)文被封裝在GTP隧道中的特殊性，這兩種技術(shù)并不能直接適用，需要進(jìn)行針對(duì)性的優(yōu)化。結(jié)合APN技術(shù)的優(yōu)勢(shì)，提出面向云網(wǎng)融合的5G回傳業(yè)務(wù)感知方案。如圖2所示，與當(dāng)前的APN6方案相比，其關(guān)鍵的優(yōu)化點(diǎn)在于針對(duì)5G回傳的具體場(chǎng)景進(jìn)行分析，并提出回傳邊緣PE設(shè)備對(duì)APN6信息的兩種可選獲取方式。其主要業(yè)務(wù)處理流程如下。

圖1 SRN架構(gòu)

(1)終端或APP Server在發(fā)送業(yè)務(wù)報(bào)文前增加APN6標(biāo)識(shí)，包含應(yīng)用標(biāo)識(shí)信息(用戶組等)和應(yīng)用需求信息(帶寬、時(shí)延、抖動(dòng)、丟包率等 )，其報(bào)文封裝格式可與當(dāng)前APN6中定義的格式保持一致，即在用戶報(bào)文頭后通過IPv6的逐跳選項(xiàng)頭(HBH)、目的選項(xiàng)頭(DOH)或段路由頭(SRH)攜帶。

圖2 面向云網(wǎng)融合的5G回傳業(yè)務(wù)感知方案

(2)回傳網(wǎng)絡(luò)中的邊緣PE設(shè)備收到報(bào)文后，獲取最終用戶業(yè)務(wù)報(bào)文中的APN6標(biāo)識(shí)信息。在這個(gè)過程中，具體獲取APN6的方式有以下兩種選擇。

一是基站和核心網(wǎng)設(shè)備不做特殊處理，由于此時(shí)回傳邊緣PE設(shè)備收到的基站或核心網(wǎng)設(shè)備發(fā)送的報(bào)文封裝如圖3所示，所以回傳邊緣PE設(shè)備需要通過固定字節(jié)偏移來獲取APN6中的封裝信息，此時(shí)的偏移量為外層報(bào)文頭之和(126 字節(jié))：如果對(duì)于回傳網(wǎng)絡(luò)的中間P設(shè)備需要獲取APN6信息，還要考慮在此基礎(chǔ)上增加外層IPv6與UDP之間的SRH和SID列表，對(duì)設(shè)備芯片的轉(zhuǎn)發(fā)性能要求更高。

圖3 基站/核心網(wǎng)與回傳設(shè)備間報(bào)文封裝

二是在基站或核心網(wǎng)設(shè)備對(duì)收到終端或APP Server發(fā)送的用戶報(bào)文主動(dòng)進(jìn)行判斷，發(fā)現(xiàn)是攜帶APN6的報(bào)文時(shí)，則對(duì)其做特殊處理，將APN6報(bào)文頭中的信息復(fù)制到外層IPv6與UDP之間，同時(shí)刪除內(nèi)層IPv6后的APN6報(bào)文；之后發(fā)送到回傳邊緣PE設(shè)備，只需偏移ETH+VLAN+外層IPv6的字節(jié)數(shù)(62 字節(jié))即可獲取到APN6信息，相對(duì)第一種方式對(duì)回傳設(shè)備硬件的要求更低(見圖4)。

圖4 基站/核心網(wǎng)復(fù)制APN6信息至外層

(3)回傳網(wǎng)絡(luò)中的邊緣PE設(shè)備將DPI獲取的信息上送控制器。

(4)控制器基于邊緣PE設(shè)備上送的信息，將帶寬、時(shí)延、抖動(dòng)、丟包率等需求信息納入算路因子(時(shí)延、丟包率等需留出無線接入網(wǎng)和核心網(wǎng)的余量)，并計(jì)算到達(dá)外層目的IP(邊緣云或核心云中的核心網(wǎng)設(shè)備)的路徑，下發(fā)至邊緣PE設(shè)備。

(5)邊緣PE設(shè)備收到控制器下發(fā)的路徑后，根據(jù)SRv6 Policy進(jìn)行SID列表的封裝，APN6信息保留用于回傳網(wǎng)中P設(shè)備進(jìn)行隨流監(jiān)控等服務(wù)，并按照下發(fā)路徑進(jìn)行報(bào)文轉(zhuǎn)發(fā)至相應(yīng)的邊緣云或核心云內(nèi)核心網(wǎng)設(shè)備中。

4 結(jié)束語

為了提升網(wǎng)絡(luò)層與業(yè)務(wù)層的關(guān)聯(lián)性，業(yè)界在進(jìn)行不斷的嘗試和探索，APN6和SRN是其中的兩種典型方案，不排除后續(xù)會(huì)有更多的方案被提出和驗(yàn)證?；赟Rv6的APN6相對(duì)于傳統(tǒng)的最短路徑算法和QoS優(yōu)先級(jí)映射，具有業(yè)務(wù)級(jí)或用戶級(jí)的細(xì)粒度和可量化的多維度SLA保證等優(yōu)勢(shì)；相對(duì)于SRN又具備更豐富的信息攜帶能力和擴(kuò)展空間的優(yōu)勢(shì)。面向云網(wǎng)融合的5G回傳業(yè)務(wù)感知方案，在APN6信息的傳遞和獲取方式上進(jìn)行了優(yōu)化，在未來算力網(wǎng)絡(luò)中，還可以通過字段擴(kuò)展攜帶業(yè)務(wù)的算力需求信息，具有更大的發(fā)展?jié)摿?。但APN6在生態(tài)建設(shè)和性能驗(yàn)證等方面也還需要繼續(xù)加大投入，具體有以下三方面建議。

(1)主機(jī)側(cè)方案要求業(yè)務(wù)應(yīng)用支持封裝APN6報(bào)文頭，但當(dāng)前APP種類眾多，生態(tài)鏈支持的難度較大，后續(xù)建議加強(qiáng)業(yè)界生態(tài)建設(shè)，吸引APP廠家的共同參與和支持；另外，針對(duì)5G回傳的場(chǎng)景，在當(dāng)前GTP隧道封裝的報(bào)文中實(shí)現(xiàn)APN6，需要對(duì)報(bào)文進(jìn)行深度檢測(cè)或基站、核心網(wǎng)設(shè)備特殊處理， 除了功能上的要求之外，還可能對(duì)網(wǎng)絡(luò)設(shè)備轉(zhuǎn)發(fā)性能帶來較大壓力，同時(shí)業(yè)務(wù)時(shí)延也會(huì)增加，需評(píng)估是否在可接受范圍內(nèi)。當(dāng)然，比較理想的方案是在6G網(wǎng)絡(luò)中，無線接入側(cè)和核心網(wǎng)側(cè)能去掉GTP封裝，或者擴(kuò)展協(xié)議將終端APN6的信息通過標(biāo)準(zhǔn)化的接口傳遞給回傳網(wǎng)絡(luò)。

(2)APN6標(biāo)準(zhǔn)還未成為穩(wěn)定的工作組文稿或RFC，建議相關(guān)廠商和運(yùn)營(yíng)商針對(duì)典型場(chǎng)景，補(bǔ)充更多的性能測(cè)試數(shù)據(jù)，并進(jìn)行針對(duì)性的優(yōu)化，增強(qiáng)其可部署性。

(3)APN6當(dāng)前解決的是用戶側(cè)需求信息感知的問題，而將來的算力網(wǎng)絡(luò)，需要網(wǎng)絡(luò)對(duì)用戶側(cè)需求和資源側(cè)供給做最優(yōu)的匹配，所以還需要面向算力網(wǎng)絡(luò)做相應(yīng)的擴(kuò)展，增加感知業(yè)務(wù)對(duì)算力需求字段的支持，并與CFN[7]等新技術(shù)結(jié)合，既為業(yè)務(wù)匹配最佳算力資源節(jié)點(diǎn)，又能計(jì)算出到算力資源節(jié)點(diǎn)的最佳路徑。

在算力網(wǎng)絡(luò)時(shí)代，網(wǎng)絡(luò)不再是單純的數(shù)據(jù)傳輸，而是集通信、計(jì)算、存儲(chǔ)為一體的信息系統(tǒng)。算力資源的統(tǒng)一建模度量是算力調(diào)度的基礎(chǔ)，算力網(wǎng)絡(luò)中的算力資源將是泛在化、異構(gòu)化的，通過模型函數(shù)將不同類型的算力資源映射到統(tǒng)一的量綱維度，形成業(yè)務(wù)層可理解、可閱讀的零散算力資源池，為算力網(wǎng)絡(luò)的資源匹配調(diào)度提供基礎(chǔ)保障。統(tǒng)一的管控體系是關(guān)鍵，傳統(tǒng)信息系統(tǒng)中應(yīng)用、終端、網(wǎng)絡(luò)相互獨(dú)立，缺乏統(tǒng)一的架構(gòu)體系進(jìn)行集中管控、協(xié)同。因此，算力網(wǎng)絡(luò)的管控系統(tǒng)將由網(wǎng)絡(luò)進(jìn)一步向端側(cè)延伸，通過網(wǎng)絡(luò)層對(duì)應(yīng)用層業(yè)務(wù)感知，建立云網(wǎng)邊端融合一體的新型網(wǎng)絡(luò)架構(gòu)，實(shí)現(xiàn)算力資源的無差別交付、自動(dòng)化匹配，以及網(wǎng)絡(luò)的智能化調(diào)度，并解決算力網(wǎng)絡(luò)中多方協(xié)作關(guān)系和運(yùn)營(yíng)模式等問題[8]。