Configuração e Solução de Problemas do Recurso de Paginação Crítica do Controle de Paginação Dinâmica

Introdução

Este documento detalha a lógica de paginação e os aprimoramentos que otimizam a paginação durante o congestionamento da CPU MME, garantindo a estabilidade e a continuidade da rede.

Descrição do problema

Impacto de Tempestade de Paginação nos Recursos MME devido a Falha de eNB/RAN

Em redes móveis de grande escala, o procedimento de paging é crítico para localizar equipamentos de usuário (UEs) ociosos quando há dados de downlink. Esse procedimento envolve vários estágios de paginação e uma lógica de fallback que se estende pela rede sob certas condições de falha.

Um problema significativo pode ser observado devido a qualquer falha crítica no nível Evolved Node B (eNB)/Radio Access Network (RAN), em que todas as tentativas de paginação durante o estágio de paginação 1 falharam. De acordo com o mecanismo de fallback padrão, essas falhas de paging foram escaladas para o estágio 2 da paginação, depois para o estágio 3 da paginação e, eventualmente, levaram a tentativas simultâneas de paging no estágio 4 da paginação.

Os operadores de rede normalmente configuram o estágio de paging 3 e o estágio 4 com lógica de área ampla—disparando o paging para todos os eNBs ou todas as identidades de área de rastreamento (TAIs). Nos cenários em que a máquina virtual de plano de controle (CPVM) é recarregada (devido à falha de caminho do Evolved GPRS Tunneling Protocol Control (EGTPC)) ou o RAN não responde, a lógica de fallback resulta em paginação em massa pela rede.

Impacto

• Essa tempestade de paging leva a um aumento inesperado de mensagens de paging e solicitações de reanexação, colocando uma carga imensa no gerenciador de Entidade de Gerenciamento de Mobilidade (MME).
• A utilização elevada da CPU e da memória é observada, frequentemente empurrando o sistema para estados de sobrecarga ou de aviso.
• Nessas condições de sobrecarga, o gerenciador de MME (componente do MME que processa a paginação) entra em um estado de "ocupado fora", fazendo com que rejeite novas conexões ou sessões, resultando em downgrades de capacidade temporários e degradação de serviço.

Pontos principais para os operadores de rede

Este caso sublinha a importância de:

• Implementando mecanismos de controle de taxa e controle de fluxo para paging.
• Monitoramento de indicadores anteriores, como recarregamentos de CPVM, capacidade de resposta de paging de RAN e padrões de repetição de paging para gerenciar a carga antecipadamente.

Representação gráfica do impacto

Aqui, presume-se que o perfil de paginação foi configurado a partir dos estágios de paginação 1, 2, 3 e 4.

Esses gráficos representam o total de tentativas e falhas de paginação para diferentes estágios de paginação.

Tentativa de Estágio1 do Perfil de Paginação MME

Falha no Estágio1 do Perfil de Paginação MME

Falha no Estágio2 do Perfil de Paginação MME

Tentativa de Estágio3 do Perfil de Paginação MME

Tentativa de Estágio4 do Perfil de Paginação MME

Gráfico de Utilização da CPU do MME Manager

Gráfico de Utilização da CPU do MME Manager

Utilização de Memória do Gerenciador MME - logs:

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

Configuração de exemplo

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

Como a Paginação é Gerenciada no MME

Lógica Funcional

É importante entender a lógica de paging geral, especialmente ao lidar com condições excepcionais em cenários de paging críticos. Conforme descrito, os Gerenciadores de Sessão manipulam o cache de paginação e mantêm o mapeamento entre os gerenciadores TAIs e MME. Esse mapeamento é atualizado após cada tentativa/resposta de paginação bem-sucedida, mas permanece inalterado no caso de uma falha de paginação. Durante a primeira tentativa de paging, o Gerenciador de Sessão envia a solicitação de paging para todos os gerenciadores MME e usa as respostas para criar o cache de paging e estabelecer o mapeamento do gerenciador TAI-MME.

Fluxo de Mensagens de Paginação

Criando o cache

Sempre que o Sessmgr quiser paginar o UE, ele verificará se as informações de cache estão presentes para todos os TACs que precisam ser paginados. Se sim, e a entrada do cache passar na verificação de validade, o Sessmgr enviará a solicitação de paginação unicast/multicast para o MMEMgr relevante. Se não, o Sessmgr envia a solicitação de paginação a todos os MEMgrs. Em resposta, o MMEMgr deve indicar os TACs na solicitação de paging que ele atende, para que o Sessmgr crie o cache.

Validade do Cache

Cada entrada de cache inclui um timestamp de origem. Quando o cache é acessado, ele é validado com base em seu carimbo de data/hora de criação e no tempo limite de validade do cache configurado. Se o tempo limite tiver expirado, a entrada não deverá ser usada. Todo o cache deve ser limpo quando todos os serviços MME são interrompidos.

Solução

Como funciona a desativação automática do recurso de paginação

Como mencionado anteriormente, somente o estágio de paginação que é configurado sob a configuração de paginação crítica só pode ser disparado, mas não é o caso e é visto que há uma dependência de cache de paginação neste recurso. Portanto, se algum mapeamento de gerenciador TAI-ME específico já estiver disponível no cache de paginação do Sessmgr, a paginação crítica usará o disparador de paginação apenas para os estágios de paginação configurados. Mas, caso não haja mapeamento TAI-MMEMgr disponível para qualquer TAI em particular, as tentativas podem ser vistas em estágios de paginação subsequentes também, mesmo que não esteja configurado em estágios de paginação. E, uma vez que o mapeamento é criado no cache de paging, então a lógica normal do paging crítico ocorre.

Configuração

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 

Configuração de exemplo

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

Aqui, os estágios de paginação 1 e 2 são acionados sempre que as condições atingem a paginação crítica. Caso as tentativas de paginação falhem nos Estágios 1 e 2, conforme a lógica de paginação, as tentativas são acionadas no próximo estágio de paginação. Neste cenário, é o estágio de paginação 3 e 4. Mas se a paginação crítica estiver configurada, não haverá mais tentativas de paginação após o estágio de paginação 2. Mas há condições excepcionais em que tentativas de paginação em estágios de paginação não configurados também podem ser vistas. Consulte a seção 'Condição excepcional de pager crítica' para obter detalhes.

Condição excepcional de pager crítico

Como mencionado anteriormente, somente o estágio de paginação configurado sob paginação crítica é acionado, mas não é o caso e é visto que há uma dependência de cache de paginação neste recurso. Portanto, se algum mapeamento de gerenciador TAI-ME específico já estiver disponível no cache de paginação do Sessmgr, a paginação crítica usará o disparador de paginação apenas para os estágios de paginação configurados. Mas, caso não haja mapeamento TAI-MMEMgr disponível para qualquer TAI em particular, as tentativas podem ser vistas em estágios de paginação subsequentes também, mesmo que não esteja configurado em estágios de paginação. Depois que o mapeamento for criado no cache de paginação, ele usará novamente a lógica normal de paginação crítica.

Teste de recursos

Como mencionado anteriormente, os estágios de paginação 1 e 2 são configurados em paging profile paging-ps. Portanto, em caso de falha de paginação nos estágios 1 e 2, outras tentativas de paginação foram ignoradas nos outros estágios de paginação 3 e 4. Mas ainda é possível ver que poucas tentativas foram feitas. E isso ocorre devido às condições definidas em "Condição excepcional de paging crítico".