Cisco 5G 核心網路 過載控制 AI/ML 水平擴縮 SCP nRF SMF

著手控制平面/使用者平面 5G核心網路過載控制解法多元

隨著全球5G行動網路積極部署,提高營運效率和客戶體驗是網路營運商的重要目標。新興基於微服務的雲端原生設計提供了建立靈活且彈性網路架構的機會。

從營運效率和可用性的角度來看,核心網路功能(Network Function, NF)的過載控制是個關鍵且獨特的設計考量要點,取決於端到端的5G解決方案。思科(Cisco)研究了存取和移動管理功能(Access and Mobility Management Function, AMF)擴縮(Scaling)的具體案例,並說明其在其他5G核心網路區域的使用方式。本文的目標是討論因為不同原因,而可能在5G核心網路內發生的各類過載情形,也將討論過載檢測、控制和預防機制。本文同時展示在各種服務供應商網路的實際部署經驗中,研究和發現的核心網路設計方案。對核心網路功能的微調預計將確保過載情況下的最佳性能。

5G網路的過載控制策略是一個關鍵的設計考慮因素,在很大程度上取決於端到端的5G部署和設計[1]。如果缺乏對可用運算資源的使用控制,很容易導致資料平面(Data Plane)元件的過度分配(Over-provisioning),進而導致行動通訊營運商的成本增加[2]。在這種情況下,參考資料[3]討論了5G網路中AMF擴縮的具體案例,[4][5]則討論了類似的過載方案。了解這樣的方案如何擴展到其他5G核心(5GC)網路功能十分重要。

人工智慧(AI)和機器學習(ML)的出現和普及也為行動網路中,更先進的NF規模縮放技術鋪路。參考資料[6]中,作者提出了一種基於ML技術預測流量負載變化的方法;參考資料[7]提出了一種基於神經網路的擴縮技術,以預測NF上即將出現的控制流量負載。這些技術中,有許多也可以被概括為採用本文討論的方案進行實作。

目前的網路設計指南[8]並未明確解決每個網路功能層面所需的過載控制演算法。本文將解釋5GC網路(圖1)中,一些獨特和新穎的策略及實用方法,以偵測、控制並克服不同等級的過載情況,搭配各種互補設計機制。本文也針對不同用例的最佳過載處理方式提出看法,並在各種操作參數之間取得平衡。

圖1 5G核網資料中心的叢集連線(Cluster Connectivity)

本文其他內容可分為以下部分:首先從使用者設備(UE)角度提供過載管理相關見解,接著對5G核心NF的控制平面(Control Plane)過載管理進行深入探討。再來描述了5G SA部署的實際過載偵測機制,以及網路儲存功能(Network Repository Function, NRF)和服務通訊代理(Service Communication Proxy, SCP)如何共同幫助優化網路,以便更好地控制負載和處理過載。此外,也描述使用者平面(User Plane)過載情況,以及如何透過正確的使用者平面功能(UPF)選擇和UPF內限流(Throttling)來實現負載控制,並討論過載處理中所使用的雲端原生基礎架構和工具。

5G核心內過載案例

UE發起訊令所導致之過載情形

各種類型的使用者設備(UE)發起和/或誘發的訊令事件可能會導致5G核心基於服務的介面(SBI)發生過載[9]。

若有大量UE進行移動性認證程序(Mobility Registration Procedure),例如,在人口稠密地區,大眾運輸系統在站點間高速移動大量人群,這種情況將導致許多UE同時在從一個認證區域移動到另一個時,進行移動性認證。在5G網路中,以下情況將影響移動性訊令流量增加:

.與個體移動訂閱者一起被運送的智慧手機數量。

.為數眾多的物聯網設備,如穿戴式感測器、監測和主動車輛診斷資訊傳輸,由於快速移動而向核心網路產生訊令(這在部署的後期階段尤為關鍵)。

UE上運行的大量應用在5GC NF產生應用訊令。以下情況會造成5GC基於服務的介面發生過載:

.數量可觀的一群人在體育場現場觀看體育賽事,並試圖存取動作回放影片、球員資料影片,使用擴增實境(AR)眼鏡或耳機即時獲取與賽事和球員相關的資訊。上述行為將創建/更新/刪除QoS流,可能導致5GC基於服務的介面上產生大量訊令問題。

.來自區域內大量UE的應用級心跳訊息,導致頻繁的IDLE/CONNECTED狀態轉換,進而造成5GC中,下一代無線存取網路(NG-RAN)到AMF到會議管理功能(SMF)到UPF訊令過載。這種情況可以使用RRC INACTIVE狀態來緩解。

.大量UE造成應用層廣播。這可能導致面向應用層廣播域每個成員的訊令洪流。例如,當大量的UE是乙太網路網域名稱(DN)的一部分,並且在乙太網路協定資料單元(PDU)會議之上運行IP,位址解析協定(ARP)或IPv6鄰居發現(ND)將產生可觀的訊令流量。

網路功能故障/重啟所導致之過載情形

在5GC SBI中,有多種故障和網路功能重啟相關的情況可能導致過載。一個NF的重啟,按其恢復時間戳記(Time Stamp),可能導致:

.如果對等NF決定恢復資源,將在重新啟動的NF重新創建資源。

.清理資源,這很可能導致面向大量UE的PDU會議認證取消(Deregistration)或釋放(Release)。

NF重啟會導致3GPP 5GC SBI在很短的時間內出現大量的訊令訊息。當完全合格的TEID(Fully Qualified TEID, FTEID)分配由UPF完成,且V-UPF分配不同的FTEID,在UPF重啟時,恢復封包轉發控制協定(PFCP)會議(第4.3.4節[10])將導致N16介面上大量的訊令訊息,用於歸屬地路由(Home Routed)PDU會議。

大多數5G NF透過監測資源使用情況來支援過載處理(OLH)。人們定義必要的測量項目,以處理節點、服務和Pod層面的過載情形。通常情況下,過載是透過定義負載等級(Load Level, LL)來進行測量。LL的定義從LL1到LLN,即從最小到最大,以此定義來監測過載。NF內的OLH過程監測資源利用率並計算LL。這一機制由資源測量、閾值設置和LL確立組成。

每隔m毫秒對資源利用率進行監測。資源利用率超過配置值時,為每個資源計算負載等級。負載等級與嚴重程度範圍的警報相對應,也就是說,如果Pod的負載等級為從LL1到LLX,就會發出Minor警報;如果Pod的負載等級從LLX+1到LLN,則會發出Major警報。

5G核心的控制平面過載偵測及管理

以下為5GC(第5.19節[8])控制平面(5G-CP)中,負載控制機制的一些重要特性。

5G核心中的過載偵測

.NRF負載偵測:利用在NRF認證的NF,NF服務的動態負載資訊經由NRF發現。對已經發現的負載資訊,若欲取得後續更新,需要訂閱NRF以獲得NF狀態通知。如圖2所示,SCP在轉發額外流量之前,先向NRF查詢NF當前的負載等級。NRF在處理NF發現請求時,可考慮NF/NF服務的動態負載及容量。

圖2 NRF端的過載處理

在向NRF進行認證期間,NF/NF服務登記預期負載百分比(0-100)和容量,用於控制NF/NF服務的負載。這些將在後面的公式1中詳細說明。

.SCP中的NF選擇:當多個NF配置檔案(NF Profile)從NRF響應,且Producer NF無狀態,SCP通常支援NF選擇/再選擇功能。NF Instance選擇和重新選擇(Re-selection)是SCP的主要任務,NF Instance選擇或重新選擇是為了:(1)在流量開始時選擇一個NF Instance來轉發訊息;(2)如果情況發生變化,如NF故障或過載,則重新進行選擇。

若Producer NF的響應為重試(Retry)配置的響應之一,SCP會將請求發送到剩餘NF配置檔案列表中的另一個Producer NF。除了預定義的錯誤響應代碼,也可以在響應超時的時候重新選擇Producer NF。

舉例來說,因為服務請求通過SCP來自AMF,SMF的多個NF配置檔案從NRF響應,如果配置的錯誤響應之一來自SMF1,SCP可以在請求超時值之內選擇SMF2。響應超時是非常直接的配置,由於無法長時間重試,請求超時定義了電路交換資料(Circuit Switched Data, CSD)在多長時間內可以嘗試從同類型的NF中選擇可用的Producer NF。

.SCP中的NF負載平衡:消費者NF的請求可以在SCP以負載平衡的方式進行處理。在無狀態Producer NF的情況下,SCP支援InterNF負載平衡配置檔案。SCP可以根據以下服務屬性在多個Producer之間進行負載平衡:優先級、容量、負載。

優先級最低的NF配置檔案優先於其他配置檔案。如果多個NF配置檔案具有相同的優先級,SCP基於負載和容量指標在這些目標之間達成負載平衡。基於負載和容量參數的詳細負載平衡方案解釋如圖3所示,具有以下選項:相同優先級和相同容量和零負載;相同優先級和不同容量和零負載;相同優先級,但容量和負載不同。NF流量份額的計算如公式(1)所述。

圖3 SCP中的Producer選擇基準

NF總體流量份額的計算公式:

...............(1)

其中,C=NF節點的流量容量;L=NF節點的流量負載係數(%)。

5G核心中的過載處理

.AMF的過載控制和處理:在AMF,對於來自UE的NG應用協定(NGAP)初始訊息,AMF可經過配置來限制每秒接收的封包數量。超過允許呼叫數量的封包將被拒絕,可以防止NF堵塞。由於AMF是所有流量進入5GC(控制平面)的入口,在AMF的限制允許其控制5GC的流量堵塞。為了避免雪球效應(例如,由重新傳輸被拒絕的呼叫而引起),可在AMF上配置一個延後計時器(Back-off Timer),以便隔開各個重新傳輸的呼叫。

當AMF發生堵塞時,會向gNB發送一個過載訊號,而gNB會限制對過載AMF的訊號分配。過載訊號可以由AMF向目標gNB節點自動生成,或由營運商透過REST API手動配置。

在UE和AMF之間,從AMF向UE通知封包的重發計時器(Re-send Timer),這有助於防止堵塞。這被稱為「延後計時器」,在試圖重試訊息時,將一個隨機生成的值提供給每個UE。在UE、gNB和AMF,實現從AMF到UE的有效尋呼有助於有效利用無線電資源,進而減少無線電存取網路(RAN)的網路流量堵塞。

.由於過載而進行內部訊息限流:網路功能,如統一資料管理(UDM)、驗證伺服器功能(AUSF)、計費功能(CHF)等,允許根據配置的負載等級(LL)百分比進行增量限流的配置。OLH過程監控HTTP/2[11]連接埠控制訊息緩衝區(Buffer)的使用情形,緩衝區的使用值將用於LL的計算。根據配置,應用處理(Application Process) 採取必要的行動來分解當前LL所需的傳入流量(Incoming Traffic)。它加強了佇列(Queue)大小的計算,以支援佇列中的訊息。透過改進的流量計算邏輯,只有選定的HTTP連接埠將被考慮用於負載計算。

過載機制允許處於過載狀態的service Pod維持運作,並透過減少傳入流量和放棄傳出流量(Outgoing Traffic),從過載狀態恢復。對於傳入的請求,當系統過載時,NF會發送一個503服務不可用的響應訊息。響應標頭(Header)包含HTTP/2訊息優先級值,任何沒有3GPP Sbi-訊息優先級(SMP)(第5.2.3.2.2節[9])標頭的傳入請求皆分配默認的優先級值,該值在1-31之間(例如24)。它也支援增量限流,允許營運商根據配置的百分比對訊息進行節流。透過3gpp-Sbi-Message-Priority(SMP)對傳入流量進行優先級處理,可實現過載計算。此外,它將對等NF的配置與SMP和LL範圍的相應API進行比較。

.基於優先級的訊息處理:AUSF UDM考慮3GPP-Sbi-Message-Priority(SMP),從自定義HTTP標頭的列表進行過載處理。參照LL配置的優先級範圍,使service Pod能夠接受或拒絕訊息。圖4顯示AUSF UDM的過載處理程序。

圖4 AUSF UDM過載處理程序

.NF層面的過載控制處理:NF通常基於佇列中未處理的訊息請求支援應用過載保護,根據未處理的訊息數閾值,宣告過載情況,如圖5所示。根據SCP Pod的訊息佇列狀態,可觸發過載控制功能,如此便能在系統中維持一定程度的穩定性。

圖5 佇列閾值示意圖

要使用過載保護功能,系統必須設置未處理訊息數臨界值。理想情況下,好的設計可以配置三個不同級別的閾值,每個閾值的計數必須具連續性,或按照以下順序:
MinorThreshold

NF也可以經過配置,在資源臨界過載(Resource Critical Overload)的情況下,向消費者發送錯誤代碼503 Service Unavailable,如此便將觸發對等單位,重新選擇目標NF。HTTP響應顯示,在過載情況下,NF服務消費者必須等待多長時間才能提出新的請求。根據訊息計數閾值的配置,會產生Minor/Major/Critical三種警報。

如果Minor警報存在的時間超過升級間隔(Escalation Interval),Minor警報就會升級為Major警報,如圖6所示。當系統的待處理請求少於較低的閾值時,升級後的Major警報將被清除。如果Major警報存在的時間超過升級間隔,則Major警報將升級為Critical警報(圖6)。當系統的待處理請求少於較低的閾值時,升級後的Critical警報將被清除。一旦請求超過資源臨界閾值,就會引發Critical警報。

圖6 Minor/Major/Critical警報運作圖

若未處理的請求數增加的時間比輪詢間隔(Polling Interval)長(也就是逐漸增加),則將依次產生Minor警報和Critical警報。

5G核心內使用者平面過載控制及管理

UPF過載控制及處理

在處理5GC使用者平面(5G-UP)的過載情況時,需要考慮兩大面向。

.主動避免過載情況發生的積極方法和手段。

.一旦發生過載情況,處理過載情況的應對方法。

UPF在N4介面上向SMF發送其負載資訊,如圖7所示。接著,SMF利用該資訊在連接到SMF的所有UPF之間,為一個使用者群組執行負載平衡。UPF發送的負載控制資訊(LCI)將包含負載度量(Load Metric)和序列號(Sequence Number)相關資訊,並且可以按照3GPP的規定[12],以下列任何一種訊息從UPF發送至SMF。

圖7 UPF選擇負載控制及過載規避

.會議建立響應(Session Establishment Response)

.會議修改響應(Session Modification Response)

.會議刪除響應(Session Deletion Response)

.會議回報請求(Session Report Request)

通常情況下,UPF在PFCP訊息中附帶LCI,以避免N4介面上的額外(Extra)。SMF使用從UPF發送的LCI資訊來加強其UPF選擇程序。此外,SMF可以透過查詢負載資訊實現負載平衡,並在以下情況中,選擇能夠對會議進行排序的UPF。

.當負載增加或減少x%或更多(其中x可由操作員進行配置)。

.當某個UPF的負載增加,超過該UPF的最大配置負載等級(例如,80%或以上)。

.當某個UPF的負載下降,低於該UPF的最小配置負載等級(例如,20%或低於LCI可以配置為無須回報)。

在SMF上,SMF中的每個Pod/Instance可以經過配置,根據忙時試呼(BHCA)嘗試次數來限制傳入的呼叫。接著,超過可接受呼叫最大數量的封包可以被配置為排隊或拒絕,作為預防堵塞的演算法。

當支援過載控制的UPF意識到其負載已經或即將超過其容量時,該UPF將在正常的PFCP訊令中附加上過載控制訊息IE(OCI),傳送至支援的SMF。在這種情況下,所使用之指標表示UPF要求流量減少的百分比。接收到此訊息的SMF應試著依照UPF所提出的百分比要求,透過減少發送至該UPF的請求量來緩解過載情況,並可能根據特定實作情況採取其他行動。

SMF可以使用以下方法來處理過載的UPF,如圖8所示。

圖8 SMF處理過載UPF的方式類型

.SMF可以透過取消選取(Deselect)的方式,禁止新傳入的會議選擇過載UPF,直到其過載狀態恢復正常。

.SMF可以只允許被標記為優先會議(Priority Sessions)的會議,例如緊急呼叫。

.如果pool當中所有UPF都處於過載狀態,SMF可以拒絕新的會議。

.SMF可以啟用調度系統(Orchestration System)來通知需要額外的使用者平面容量,在這種情況下,自動化系統根據可用資源生成一或多個新的UPF Instance。

.SMF可以結合利用使用者平面通知的用量報告和過載控制資訊,並向政策控制功能(Policy Control Function, PCF)發出觸發器(Trigger),可以發送規則來限制訂閱者,進而使負載正常化。

.SMF也可以具有向UPF發送流量限流規則的功能,無須PCF參與。SMF可以藉由一些靜態配置來克服過載情況。

過載處理基礎架構

3GPP採用的雲端原生部署範式[9]使服務部署更加靈活、彈性、可擴展,資源使用效率也更高。微服務架構和相關容器調度框架[13]的採用率提升,在使用一般通用硬體、基於多處理器的伺服器架構中,有機會能夠更好地管理運算資源及相關過載處理[14]。

在Kubernetes(K8s)可以找到水平Pod自動擴縮(Horizontal Pod Autoscaling)的具體實作[15]。實作中,K8s控制器定期監測可用資源,並根據使用者指定的預期數量,控制給定Pod(或應用程式)的複製數量,詳細解釋如圖9所示。

圖9 Horizontal Pod Autoscaler及Metric Collection

服務的敏捷性和彈性通常與基於觀察到的資源使用情況(如CPU利用率)的Pod自動擴縮有關。此外,也能夠以更智慧的方式管理這種自動擴縮,以迎合特定的工作負載模式[16][17]。典型的水平自動擴縮機制根據以下類型的一或多個指標來縮放工作負載中的Pod數量。

.實際資源使用情況:當一個特定Pod的CPU或記憶體使用量超過所配置之閾值。

.自定義指標:基於叢集(Cluster)中Kubernetes物件回報的任何指標,如每秒的用戶端請求率,或每秒的I/O寫入量。

.外部指標:基於叢集外部應用程式或服務的一個指標。

其中一種Pod水平擴縮方案[16]使用基於歷史資源使用資料的預測演算法,對擴縮情形進行主動預測。相比之下,現有Kubernetes自動擴縮器則是根據預定的閾值來運作。

另一個自動擴縮Pod方案[17]使用特定性能指標作為QoS屬性。例如,應用響應時間和減少能源消耗(該列表並不詳盡)。該方案採用一種基於強化學習(RL)的演算法。 這些方案皆表明,簡單基於閾值的自動擴縮可能不足以滿足各類應用的整體系統性能。舉例來說,基於CPU利用率的自動縮放,對非CPU密集型的應用可能效果較差。使用機器學習(ML)技術和工具,根據5G服務具體性能參數進行自動縮放的機會更大。

AI/ML加值過載控制管理技術

本文討論了過載控制及管理的新穎設計,以及網路功能的自動縮放政策。

Cisco在實驗室環境中觀察到這些演算法對於網路叢集的特定設計(即網路功能在網路中的位置)具有顯著的運行穩定性,不過,現實世界的實際部署將需要進一步仔細設計叢集大小和參數微調。雖然使用基於微服務的雲端原生平台可以實現可擴縮的網路設計,但如果擴縮的彈性處理不當,就會帶來巨大的挑戰。本文討論了雲端原生基礎架構和用於過載管理的工具,並著重討論SCP、NRF和SMF功能在實作過載和自動擴縮功能中的關鍵作用。

在本文的未來版本中,Cisco預計針對5G服務性能參數,使用基於AI/ML的工具和方案,研究、開發並加強本文所討論的過載控制及管理的功能和技術。

(本文作者皆任職於Cisco)

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!