动态寻呼控制关键寻呼功能的配置和故障排除

简介

本文档详细介绍在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上跳过。但是，您仍然可以看到很少的尝试。它是由“关键寻呼异常条件”下定义的条件造成的。