跨多簇PCRF使用LWR的E911高效承載管理

簡介

本文檔介紹使用LWR和UDC VM對緊急呼叫（例如E911呼叫）進行有效的承載處理，以確保優先順序的設定、可靠性和最佳化的網路資源使用。

架構概觀

E911緊急呼叫要求優先承載管理，以保證呼叫品質和網路可用性。該解決方案利用了輕量級複製(LWR)和使用者資料快取(UDC)虛擬機器。LWR內部使用Kafka DB進行複製。Kafka跨多個PCRF集群提供高速複製，從而在緊急呼叫期間實現協調承載控制。

此功能可幫助PCRF共用使用者資訊，如附加APN的數量、通知狀態和中間狀態（如更新和承載釋放）。

LWR群集元件

• Zookeeper:用於選擇控制器，確保只有一個控制器，並在發生故障時選擇新的控制器。它管理群整合員身份(哪些代理處於活動狀態以及群集的一部分)並監督主題配置(存在哪些主題、每個分割槽有多少個、副本的位置、誰是首選引線者，以及為每個主題設定哪些配置覆蓋)。

• 經紀商：LWR使用的代理服務是在主機上運行的消息隊列。Kafka代理接收來自生成者的消息，並將它們儲存在由唯一偏移量標籤的磁碟上。它允許消費者按主題、分區、偏移量提取消息，並且可以通過使用Zookeeper直接或間接地相互共用資訊來建立Kafka群集。
• MirrorMaker:Kafka MirrorMaker用於映象Kafka群集之間的資料。這有助於建立資料從一個資料中心到另一個數據中心的複製副本。可以同時運行多個映象進程，以提高吞吐量和容錯能力。

PCRF - LWR區域和主題配置

在生產過程中，可以將PCRF分組到多個區域，如西部、東南部和東北部。每個區域可以有大約5到6個通過LWR互連的PCRF節點。每當使用者發生某些事件時，PCRF都會在LWR上寫入或更新資料。這些事件的一些示例包括：

• 連線到網路

• 服務/承載建立
• 從網路分離

外掛配置

在「cluster-udc」下，新增了「lwr client plugin」配置，其中包括：

• 區域名稱：此PCRF所屬區域的名稱。
• 前端Id:PCRF的前端Id。此值必須與UDC配置中使用的現有前端ID值相同。
• 區域中的前端Id:該區域中所有PCRF的前端ID。
• 主題表:對映到縮放管理器和中間程式的主題名稱清單，它指示哪個主題是本地主題而哪個主題不是。此表必須配置全部三個區域主題。本地主題必須設定為true;對於本地主題，其餘兩個主題設定為false。

外掛配置：LWR客戶端外掛配置

LWR服務選項

新增新的服務選項以支援LWR寫入；必須在UDC服務中使用此服務配置。

LWR服務選項使用主題名稱來選擇必須在LWR上寫入的主題資料和屬性清單。必須根據前端ID從CRD表中選擇主題名稱。

服務選項：LWR

CRD更改 — Lwr-Apn — 對映

此表提供了在LWR上寫入屬性(lwrpcrferab)的控制，以及是否為E911承載管理釋放承載。

搜尋表組> CRD:Lwr-Apn — 對映

僅當「enable_lwr_write」為true時，UDC才會將「lwrpcrferab」屬性寫入LWR。因此，此操作為操作團隊提供控制，以便為APN啟用LWR寫入。例如，最初，LWR寫入僅針對某些測試APN啟用，而針對所有其他APN禁用。這允許操作團隊驗證LWR功能和複製是否正常工作。

同樣，如果「bearer_release」為true，則只有PCRF可以在接收SOS呼叫時釋放APN承載；如果APN的「bearer_release」為false，則E911承載管理無法啟動該APN。

自定義引用資料表：Lwr-Apn — 對映

主題查詢

此CRD表用於根據前端ID派生主題名稱。LWR服務選項使用此資訊來連線到PCRF配置用於的特定主題。

自定義引用資料表：主題查詢

關鍵概念和資料流

屬性複製

• 主要複製屬性是「lwrpcrferab」，編碼與E911相關的載體狀態。

• PCRF將此屬性寫入UDC，UDC隨後通過LWR傳播該屬性。

• LWR跨站點複製屬性，更新本地UDC和PCRF以維護同步的承載狀態。

域和服務更新

• 新的域支援通過UDC和LDAP進行SOS APN屬性管理。

• 現有SOS域現在使用「lwrpcrferab」屬性。

• 延遲SOS呼叫接受以允許承載釋放。

• 在SOS呼叫期間拒絕新的持有人/會話請求。

• 在SOS呼叫發起時釋放IMS和MCPTT承載。

• 在SOS呼叫期間暫停並在以後恢復承載。

假設

• 每個APN都控制LWR寫入啟用，以允許分階段部署和測試。

• PCRF僅在新的會話請求上寫入「lwrpcrferab」屬性，或者如果該屬性已經存在，則防止寫入過多。

• SOS呼叫接受中的預設延遲（例如600毫秒）允許PCRF在建立緊急呼叫之前釋放較低優先順序的承載。

• 過時的屬性保護計時器可確保及時清除過時的SOS會話或屬性。

呼叫流

• 將Data APN的「attach」傳送到PGW，然後PGW將CCR-I傳送到PCRF A並獲得成功響應。
• 將熱點APN的「attach」傳送到PGW，然後PGW將CCR-I傳送到PCRF A，並獲得成功的響應。
• 將「緊急呼叫」傳送到PGW，然後PGW將CCR-I傳送到PCRF B，並獲得成功響應。
• PCRF更新名為「lwrpcrferab」的屬性，將其階段設定為「Start」，其優先順序設定為「1」。 這可能表示緊急呼叫處理的開始，並為其分配最高優先順序。
• PCRF將此更新的「lwrpcrferab」屬性寫入UDC。
• 然後UDC將「lwrpcrferab」屬性寫入LWR。「lwrpcrferab」屬性在LWR群集中的所有節點和區域之間複製，以確保一致性和可用性。
• PCRF多集群中的每個節點都使用複製的屬性資訊更新其本地UDC和PCRF例項。
• 然後，PCRF釋放優先順序較低的承載。這些低優先順序服務的示例包括熱點、IMS影片和IPME。此操作可釋放用於高優先順序緊急呼叫的網路資源。
• SOS CCA-I消息存在已配置的延遲（預設為600毫秒）。這是為了確保資源分配或同步，然後再繼續。
• 最後，系統拒絕對特定APN（例如熱點）的任何新承載或會話請求，通過防止新的低優先順序連線來進一步優先化緊急呼叫。
• 當GW傳送CCR-T以刪除SOS呼叫時，PCRF接受資料APN的新承載建立請求。

優勢和影響

• 高可用性和可擴充性：基於Kafka的LWR確保跨多個資料中心進行即時複製和容錯能力。

• 優先順序處理：在緊急呼叫期間允許動態釋放或暫停低優先順序承載。

• 操作控制：支援每個APN的分階段功能啟用和細粒度承載管理。

• 提高緊急呼叫品質：有效的承載資源管理支援可靠的E911呼叫建立和維護。

結論

使用LWR的承載管理解決方案提供強大、可擴展且高效的機制，以便在E911呼叫期間對LTE承載進行優先順序劃分和管理。通過利用基於Kafka的複製和同步屬性管理，它確保了高可用性、操作靈活性和改進的緊急呼叫可靠性。