簡介
本文檔詳細介紹在MME CPU擁塞時最佳化尋呼的尋呼邏輯和增強功能,以確保網路穩定性和連續性。
問題描述
由於eNB/RAN故障,尋呼風暴對MME資源的影響
在大規模行動網路中,當存在下行鏈路資料時,尋呼過程對於定位空閒使用者裝置(UE)至關重要。此過程涉及多個尋呼階段和在特定故障情況下跨網路擴展的回退邏輯。
由於在演化節點B(eNB)/無線接入網路(RAN)級別發生任何嚴重故障(其中尋呼階段1期間的所有尋呼嘗試均失敗),可以觀察到嚴重問題。根據標準回退機制,這些尋呼失敗被升級到尋呼階段2,然後升級到尋呼階段3,最終導致在尋呼階段4同時進行尋呼嘗試。
網路操作員通常使用廣域邏輯配置尋呼階段3和尋呼階段4,從而觸發對所有eNB或所有跟蹤區域標識(TAI)的尋呼。 在控制平面虛擬機器(CPVM)重新載入(由於進化GPRS隧道協定控制(EGTPC)路徑失敗)或RAN無響應的場景中,回退邏輯會導致網路出現大量尋呼。
影響
- 此尋呼風暴導致尋呼消息和重新附加請求意外激增,給移動性管理實體(MME)管理器帶來了巨大的負載。
- CPU和記憶體使用率較高,通常會導致系統進入過載或警告狀態。
- 在這些壓力條件下,MME管理器(處理尋呼的MME元件)進入「忙出」狀態,導致它拒絕新的連線或會話,導致臨時的容量降級和服務降級。
網路運營商的主要收穫
本案突顯了以下事項的重要性:
- 實現尋呼的速率控制和限制機制。
- 監控CPVM重新載入、RAN尋呼響應和尋呼重試模式等早期指示符,以便搶先管理負載。
影響的圖形表示
這裡假設尋呼配置檔案已從尋呼階段1、2、3和4配置。
這些圖形表示不同尋呼階段的尋呼嘗試和失敗總數。
MME呼叫設定檔Stage1嘗試
MME呼叫設定檔Stage1失敗
MME分頁配置檔案Stage2故障
MME呼叫設定檔Stage3嘗試
MME頁面設定檔Stage4嘗試
MME管理器CPU利用率圖表
MME管理器CPU利用率圖表
MME管理器記憶體利用率 — 日誌:
2024-01-11T22:18:10.575996+09:00 UHNxxxmmvm0001 evlogd: [local-60sec10.022] UHN3tte2mmvm0001 [resmgr 14508 error] [17/0/10121 <rmmgr:170> _resource_cpu.c:4421] [software internal system critical-info syslog] The task mmemgr-8 is way over its memory limit! Allocated 409600K, Using 624696K
2024-01-11T22:18:10.069772+09:00 UHN3xxxmmvm0001 evlogd: [local-60sec9.695] UHN3tte2mmvm0001 [resmgr 14508 error] [8/0/10120 <rmmgr:80> _resource_cpu.c:4421] [software internal system critical-info syslog] The task mmemgr-6 is way over its memory limit! Allocated 409600K, Using 584680K
2024-01-11T22:18:09.998162+09:00 UHN3xxxmmvm0001 evlogd: [local-60sec9.634] UHN3tte2mmvm0001 [resmgr 14508 error] [10/0/10132 <rmmgr:100> _resource_cpu.c:4421] [software internal system critical-info syslog] The task mmemgr-2 is way over its memory limit! Allocated 409600K, Using 543404K
示例配置
paging-profile paging-ps
paging-stage 1 match-criteria ue-contact-time 1200 action last-n-enb-last-tai max-n-enb 1 t3413-timeout 2 max-paging-attempts 1.
paging-stage 2 match-criteria all action last-n-enb-last-tai max-n-enb 5 t3413-timeout 2 max-paging-attempts 1
paging-stage 3 match-criteria all action all-enb-last-tai t3413-timeout 2 max-paging-attempts 1
paging-stage 4 match-criteria all action all-enb-all-tai t3413-timeout 3 max-paging-attempts 1
如何在MME中管理尋呼

功能邏輯
瞭解一般分頁邏輯非常重要,特別是在處理關鍵分頁場景下的特殊情況時。如上所述,會話管理器處理尋呼快取並維護TAI和MME管理器之間的對映。每次尋呼嘗試/響應成功後,都會更新此對映,但在尋呼失敗時仍會保持不變。在第一次尋呼嘗試期間,會話管理器將尋呼請求廣播到所有MME管理器,並使用響應來構建尋呼快取記憶體和建立TAI-MME管理器對映。
尋呼消息流
構建快取
每當Sessmgr想要尋呼UE時,它會檢查是否需要尋呼的所有TAC的快取資訊是否存在。如果是,並且快取條目通過有效性檢查,則Sessmgr將單播/組播尋呼請求傳送到相關MMEMgr。如果否,則Sessmgr會將尋呼請求廣播到所有MMEMgrs。作為響應,MMEMgr必須在它所服務的分頁請求中指示TAC,以便Sessmgr構建快取。
快取的有效性
每個快取條目都包括一個源時間戳。當訪問快取時,會基於其建立時間戳和配置的快取有效性超時來驗證快取。如果超時已過期,則不得使用該條目。當所有MME服務都停止時,必須清除整個快取。
解決方案
自動停用尋呼功能的運作方式
如前所述,僅觸發在關鍵分頁配置下配置的分頁級,但情況並非如此,並且在該功能中發現存在分頁快取記憶體的相關性。因此,如果Sessmgr尋呼快取下已有任何特定的TAI-MME管理器對映可用,則關鍵尋呼僅對已配置的尋呼階段使用尋呼觸發。但是,如果任何特定TAI沒有TAI-MMEMgr對映可用,則即使未配置在尋呼階段下,也可以在後續尋呼階段看到嘗試。而且,一旦對映在分頁快取記憶體下建立,則關鍵分頁的正常邏輯就會發生。
組態
mme-manager
congestion-control cpu-utilization threshold 90 tolerance 10
#exit
Configuration: critical paging need to configure under paging-profile to allow the configured paging stages while skip the unconfigured paging stages.
configure
lte-policy
paging-profile paging_profile_name
[ no ] critical paging_stage
end
示例配置
paging-profile paging-ps
paging-stage 1 match-criteria ue-contact-time 1200 action last-n-enb-last-tai max-n-enb 1 t3413-timeout 2 max-paging-attempts 1
paging-stage 2 match-criteria all action last-n-enb-last-tai max-n-enb 5 t3413-timeout 2 max-paging-attempts 1
paging-stage 3 match-criteria all action all-enb-last-tai t3413-timeout 2 max-paging-attempts 1
paging-stage 4 match-criteria all action all-enb-all-tai t3413-timeout 3 max-paging-attempts 1
critical 1 2
在這裡,每當達到關鍵分頁的條件時,都會觸發分頁階段1和2。如果在階段1和2上的分頁嘗試失敗,則根據分頁邏輯,在下一個分頁階段觸發嘗試。在此情況中,它是尋呼階段3和4。但是,如果配置了關鍵尋呼,則在尋呼階段2之後不會嘗試進一步尋呼。但是,也可能會出現異常情況,在未配置的尋呼階段上嘗試尋呼。有關詳細資訊,請參閱「關鍵尋呼異常條件」一節。
緊急尋呼異常情況
如前所述,只觸發在關鍵分頁下配置的分頁級,但情況並非如此,並且在該功能中發現存在分頁快取記憶體的依賴性。因此,如果Sessmgr尋呼快取下已有任何特定的TAI-MME管理器對映可用,則關鍵尋呼僅對已配置的尋呼階段使用尋呼觸發。但是,如果任何特定TAI沒有TAI-MMEMgr對映可用,則即使未配置在尋呼階段下,也可以在後續尋呼階段看到嘗試。一旦對映在分頁快取下建立,那麼它再次使用關鍵分頁的正常邏輯。
功能測試

如前所述,尋呼階段1和2在尋呼配置檔案paging-ps下配置。因此,在階段1和2上的分頁失敗的情況下,其他分頁階段3和4上的其他分頁嘗試已被跳過。但是,您仍然可以看見進行的嘗試很少。這是由於在「關鍵分頁異常條件」下定義的條件。