5G發展進入成熟期，主要業務從to C為主向to B+to C轉變，精細化的SLA保證和差異化承載能力更加凸顯。5G行業專網的發展，需要在一張物理網絡上承載多種業務，而不同行業的業務特點也不同，需要進行差異化承載和定制化的SLA保證，除了通過網絡的軟、硬切片技術進行傳輸過程中關鍵業務的隔離以外，還需要業務感知技術將用戶和業務的類別、SLA需求等更豐富的信息傳遞給網絡，實現網絡賦能，進一步支撐云網融合及將來的算力網絡發展。
1 5G網絡中存在的問題分析
5G網絡由無線接入網(AN)、移動承載網(TN)和核心網(CN)共同構成，在為移動終端提供語音、短信等基礎電信服務的過程中，無線接入網和核心網直接參與處理用戶的業務信息;從4G網絡開始，移動互聯網業務已經逐漸成為了業務的主要部分，但是在移動互聯網業務處理流程中，5G網絡只是提供一個Underlay的“管道”，無法感知業務的SLA需求，導致運營商不能針對不同的用戶或業務提供精細化、差異化的服務，從而逐步陷入低價賣流量、增量不增收的困境。從長期來看，這不利于我國5G網絡的健康發展。從5G業務端到端處理流程分析，導致5G網絡“管道化”的主要原因有以下三方面。
1.1 無線接入和核心網側GTP隧道封裝導致回傳網絡難以識別用戶業務特征
GTP-U是3GPP早期定義的用戶面傳輸協議，最初用在GPRS網絡節點間用戶面數據包的傳輸，并在后來的3G/4G/5G移動系統中一直被延續使用。GTP-U傳輸協議的特點是：在同一IP端到端連接上，構建點對點的隧道封裝傳輸協議，提供多路傳輸復用、路徑管理(GTP-U自己還有“帶內控制消息”用于隧道Path管理)等能力。GTP-U隧道傳輸協議從2.5G GPRS系統開始被運用，在傳統蜂窩非云化的電信網絡中非常經典。GTP-U協議一直由3GPP控制主導，可按需不斷地進行內容擴展，但也難以適應未來的云化網絡特征?；貍骶W從無線接入網和核心網N3接口接收的用戶面數據都是帶有GTP-U封裝的，這在一定程度上加大了回傳網設備識別業務特征的難度。
1.2 傳統的DNS和業務系統調度機制未考慮精細化SLA業務需求
DNS是互聯網的一項服務，它作為將域名和IP地址相互映射的一個分布式數據庫，用戶能夠更方便地訪問互聯網。DNS和業務系統當前確定目的服務器的主要依據是接收到用戶終端DNS解析請求的DNS服務器所在的運營商、地域信息，但如果用戶終端中配置的DNS服務器地址配置錯誤，或者配置為公共的DNS服務器，最終用戶終端得到的服務器地址就會出現偏差。為了改進這個問題，阿里云等部署了HTTPDNS技術，用戶終端通過HTTP向HTTPDNS服務器發出域名解析請求，此時HTTPDNS服務器可以獲取終端的精確IP地址，并基于此IP進行調度。但這種調度方式仍然沒有將用戶終端與目的服務器之間網絡的SLA指標納入考慮范圍，如果鏈路出現擁塞，就可能導致用戶的服務質量劣化。
1.3 5G回傳網絡中的算路機制未考慮應用層需求
在5G回傳網絡中，傳統的IP路由或MPLS技術不感知業務，只負責按照網絡層度量值或人工設置的路徑約束進行數據報文的轉發。通過鏈路帶寬計算得到路由協議中的度量值，也可以手工配置。近年來，隨著SDN技術的發展，部分廠商支持在計算轉發路徑的因子中增加網絡時延信息，但網絡層與應用層業務依然是割裂的，網絡層的路徑計算結果無法與應用層的需求實時進行匹配。
2 基于數據傳輸網絡的業務感知技術
為了解決數據傳輸網絡無法獲取到應用層業務需求信息的問題，業界提出了業務感知技術，當前主要分為以下兩類。
2.1 APN6(Application-aware IPv6 networking)
APN6是在數據平面利用IPv6報文擴展頭(Extension Headers)，如逐跳選項頭(Hop-by-Hop Options Header)、段路由頭(Segment Routing Header)的可編程空間，攜帶應用的相關信息(標識和需求)到網絡中，網絡設備依據這些信息為其提供相應的網絡服務，如將報文映射進相應的能夠保障其SLA的SRv6路徑等。應用感知信息可以由用戶終端設備或應用直接生成，也可以由網絡邊緣設備生成，分別對應APN6的主機側方案和網絡側方案。
2.2 SRN(Software Resolved Networks)
SRN架構和流程如圖1所示。在控制平面，基于RFC 6891進行DNS協議擴展，實現了用戶終端、服務器與SDN控制器和接入路由器的交互。用戶終端通過擴展的DNS協議，將應用SLA需求信息(如帶寬和時延等)通過DNS代理轉發給DNS解析器，并暫時緩存DNS解析器應答的DNS服務器IP地址信息;DNS代理向SDN控制器發送到DNS服務器的路徑請求，由SDN控制器綜合網絡鏈路狀態和應用需求計算出可到達DNS服務器的SRv6-Policy，并下發給接入路由器的路由管理組件進行轉發表項的安裝;DNS代理將DNS解析器返回的應用服務器IP地址和SDN控制器的路徑計算結果BSID一起應答給用戶終端。為了防止網絡設備的故障導致服務劣化，網絡狀態監控組件會實時刷新OSPF路由信息，并及時通知SDN控制器進行同步更新。在轉發平面，用戶終端發送數據包時，攜帶DNS代理下發的BSID，接入路由器將數據包沿控制器下發的SRv6-Policy轉發給網絡中的應用服務器。
為了提升網絡與業務的關聯性，APN6和SRN提出了不同的解決思路，它們的數據面轉發都基于SRv6技術，但攜帶業務層信息的方式不用，APN6是在IPv6的擴展頭中封裝應用信息及SLA需求信息，可用的擴展空間非常豐富(128 bit/SID)。而SRN是基于控制面的DNS協議進行擴展，相對攜帶信息的空間較少，只能攜帶帶寬、時延等基本的SLA需求信息,它的優勢是這是一個輕量級的方案，對企業的DNS服務器和主機(LINUX內核)進行軟件升級即可，不需要運營商網絡設備升級，也不依賴眾多的應用生態的支持，所以實施起來相對更容易，兩者詳細對比參見表1.
3 面向云網融合的5G回傳業務感知方案架構
從業務發展趨勢來看，5G網絡中的業務種類，流量模型與3G/4G相比都發生了顯著的變化，尤其是行業業務的應用提出了比個人業務更嚴苛的需求。為了更好地滿足這些需求，并加快構建數字化轉型的新型基礎設施，我國運營商都把云和網的融合確定為網絡發展演進的重要方向，期望通過云網融合推動5G應用創新發展。面對長久以來云業務與網絡各自獨立發展的現狀，當前需要思考如何逐漸改變這種解耦的發展方式，在這個過程中，網絡對業務的感知技術成為業務層和網絡層之間協同發展的紐帶。
APN和SRN兩類技術分別是針對廣域和企業場景進行業務感知，但是對于5G網絡，由于其業務報文被封裝在GTP隧道中的特殊性，這兩種技術并不能直接適用，需要進行針對性的優化。結合APN技術的優勢，提出面向云網融合的5G回傳業務感知方案。如圖2所示，與當前的APN6方案相比，其關鍵的優化點在于針對5G回傳的具體場景進行分析，并提出回傳邊緣PE設備對APN6信息的兩種可選獲取方式。其主要業務處理流程如下。
圖2 面向云網融合的5G回傳業務感知方案
(1)終端或APP Server在發送業務報文前增加APN6標識，包含應用標識信息(用戶組等)和應用需求信息(帶寬、時延、抖動、丟包率等)，其報文封裝格式可與當前APN6中定義的格式保持一致，即在用戶報文頭后通過IPv6的逐跳選項頭(HBH)、目的選項頭(DOH)或段路由頭(SRH)攜帶。
(2)回傳網絡中的邊緣PE設備收到報文后，獲取最終用戶業務報文中的APN6標識信息。在這個過程中，具體獲取APN6的方式有以下兩種選擇。
一是基站和核心網設備不做特殊處理，由于此時回傳邊緣PE設備收到的基站或核心網設備發送的報文封裝如圖3所示，所以回傳邊緣PE設備需要通過固定字節偏移來獲取APN6中的封裝信息，此時的偏移量為外層報文頭之和(126 字節)：如果對于回傳網絡的中間P設備需要獲取APN6信息，還要考慮在此基礎上增加外層IPv6與UDP之間的SRH和SID列表，對設備芯片的轉發性能要求更高。
圖3 基站/核心網與回傳設備間報文封裝
二是在基站或核心網設備對收到終端或APP Server發送的用戶報文主動進行判斷，發現是攜帶APN6的報文時，則對其做特殊處理，將APN6報文頭中的信息復制到外層IPv6與UDP之間，同時刪除內層IPv6后的APN6報文;之后發送到回傳邊緣PE設備，只需偏移ETH+VLAN+外層IPv6的字節數(62 字節)即可獲取到APN6信息，相對第一種方式對回傳設備硬件的要求更低(見圖4)。
圖4 基站/核心網復制APN6信息至外層
(3)回傳網絡中的邊緣PE設備將DPI獲取的信息上送控制器。
(4)控制器基于邊緣PE設備上送的信息，將帶寬、時延、抖動、丟包率等需求信息納入算路因子(時延、丟包率等需留出無線接入網和核心網的余量)，并計算到達外層目的IP(邊緣云或核心云中的核心網設備)的路徑，下發至邊緣PE設備。
(5)邊緣PE設備收到控制器下發的路徑后，根據SRv6 Policy進行SID列表的封裝，APN6信息保留用于回傳網中P設備進行隨流監控等服務，并按照下發路徑進行報文轉發至相應的邊緣云或核心云內核心網設備中。
4 結束語
為了提升網絡層與業務層的關聯性，業界在進行不斷的嘗試和探索，APN6和SRN是其中的兩種典型方案，不排除后續會有更多的方案被提出和驗證。基于SRv6的APN6相對于傳統的最短路徑算法和QoS優先級映射，具有業務級或用戶級的細粒度和可量化的多維度SLA保證等優勢;相對于SRN又具備更豐富的信息攜帶能力和擴展空間的優勢。面向云網融合的5G回傳業務感知方案，在APN6信息的傳遞和獲取方式上進行了優化，在未來算力網絡中，還可以通過字段擴展攜帶業務的算力需求信息，具有更大的發展潛力。但APN6在生態建設和性能驗證等方面也還需要繼續加大投入，具體有以下三方面建議。
(1)主機側方案要求業務應用支持封裝APN6報文頭，但當前APP種類眾多，生態鏈支持的難度較大，后續建議加強業界生態建設，吸引APP廠家的共同參與和支持;另外，針對5G回傳的場景，在當前GTP隧道封裝的報文中實現APN6.需要對報文進行深度檢測或基站、核心網設備特殊處理，除了功能上的要求之外，還可能對網絡設備轉發性能帶來較大壓力，同時業務時延也會增加，需評估是否在可接受范圍內。當然，比較理想的方案是在6G網絡中，無線接入側和核心網側能去掉GTP封裝，或者擴展協議將終端APN6的信息通過標準化的接口傳遞給回傳網絡。
(2)APN6標準還未成為穩定的工作組文稿或RFC，建議相關廠商和運營商針對典型場景，補充更多的性能測試數據，并進行針對性的優化，增強其可部署性。
(3)APN6當前解決的是用戶側需求信息感知的問題，而將來的算力網絡，需要網絡對用戶側需求和資源側供給做最優的匹配，所以還需要面向算力網絡做相應的擴展，增加感知業務對算力需求字段的支持，并與CFN[7]等新技術結合，既為業務匹配最佳算力資源節點，又能計算出到算力資源節點的最佳路徑。
在算力網絡時代，網絡不再是單純的數據傳輸，而是集通信、計算、存儲為一體的信息系統。算力資源的統一建模度量是算力調度的基礎，算力網絡中的算力資源將是泛在化、異構化的，通過模型函數將不同類型的算力資源映射到統一的量綱維度，形成業務層可理解、可閱讀的零散算力資源池，為算力網絡的資源匹配調度提供基礎保障。統一的管控體系是關鍵，傳統信息系統中應用、終端、網絡相互獨立，缺乏統一的架構體系進行集中管控、協同。因此，算力網絡的管控系統將由網絡進一步向端側延伸，通過網絡層對應用層業務感知，建立云網邊端融合一體的新型網絡架構，實現算力資源的無差別交付、自動化匹配，以及網絡的智能化調度，并解決算力網絡中多方協作關系和運營模式等問題。
