소개
이 문서에서는 MME CPU 혼잡 동안 페이징을 최적화하고 네트워크 안정성 및 연속성을 보장하는 페이징 로직 및 개선 사항에 대해 자세히 설명합니다.
문제/장애 설명
eNB/RAN 실패로 인한 MME 리소스에 대한 페이징 스톰 영향
대규모 모바일 네트워크에서는 다운링크 데이터가 있는 경우 유휴 UE(User Equipment)를 찾기 위해 페이징 절차가 중요합니다. 이 절차에는 여러 페이징 단계 및 특정 장애 상황에서 네트워크 전반으로 확장되는 폴백 로직이 포함됩니다.
페이징 단계 1에서 모든 페이징 시도가 실패한 eNB(Evolved Node B)/RAN(Radio Access Network) 레벨에서 심각한 오류가 발생하여 중요한 문제가 관찰될 수 있습니다. 표준 폴백 메커니즘에 따르면 이러한 페이징 실패는 페이징 단계 2로 에스컬레이션된 다음 페이징 단계 3으로 에스컬레이션되었으며, 결국 페이징 단계 4에서 동시 페이징 시도를 초래했습니다.
네트워크 운영자는 일반적으로 페이징 단계 3과 단계 4를 광역 논리로 구성하여 모든 eNB 또는 모든 TAI(Tracking Area Identity)에 대한 페이징을 트리거합니다. EGTPC(Evolved GPRS Tunneling Protocol Control) 경로 장애로 인해 CPVM(Control Plane Virtual Machine)이 다시 로드되거나 RAN이 응답하지 않는 시나리오에서 폴백 논리로 인해 네트워크 전체에서 대량 페이징이 발생합니다.
영향
- 이 페이징 폭풍으로 인해 페이징 메시지 및 재첨부 요청이 예기치 않게 급증하여 MME(Mobility Management Entity) 관리자에 엄청난 부하가 걸리게 됩니다.
- CPU 및 메모리 사용률이 높게 관찰되어 시스템을 과부하 또는 경고 상태로 몰아넣는 경우가 많습니다.
- 이러한 스트레스 조건에서 MME 관리자(페이징을 처리하는 MME의 구성 요소)는 '통화 중 발신' 상태가 되어 새로운 연결 또는 세션을 거부하게 되고, 그로 인해 일시적인 용량 저하와 서비스 저하가 발생합니다.
네트워크 운영자를 위한 핵심 요점
이 사례는 다음 항목의 중요성을 강조합니다.
- 페이징을 위한 속도 제어 및 조절 메커니즘 구현
- 선제적으로 로드를 관리하기 위해 CPVM 다시 로드, RAN 페이징 응답, 페이징 재시도 패턴과 같은 초기 지표를 모니터링합니다.
영향 그래픽 표시
여기서 페이징 프로파일은 페이징 스테이지 1, 2, 3, 4부터 설정된 것으로 가정한다.
이 그래프는 서로 다른 페이징 단계에 대한 총 페이징 시도 및 실패를 나타냅니다.
MME 페이징 프로필 Stage1 시도
MME 페이징 프로파일 스테이지1 실패
MME 페이징 프로파일 Stage2 실패
MME 페이징 프로필 Stage3 시도
MME 페이징 프로필 Stage4 시도
MME Manager CPU 사용률 그래프
MME Manager 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에 대한 캐시 정보가 있는지 확인합니다. Yes인 경우 캐시 엔트리가 유효성 검사를 통과하면 Essmgr은 유니캐스트/멀티캐스트 페이징 요청을 관련 MMEMgr에 보냅니다. no인 경우 Sessmgr은 페이징 요청을 모든 MMEMgrs에 브로드캐스트합니다. 이에 대해 MMEMgr은 자신이 지원하는 페이징 요청에 TAC를 표시해야 Sessmgr에서 캐시를 빌드할 수 있습니다.
캐시의 유효성
각 캐시 항목에는 원본 타임스탬프가 포함됩니다. 캐시에 액세스하면 생성 타임스탬프와 구성된 캐시 유효성 시간 제한을 기반으로 검증됩니다. 시간 초과가 만료된 경우 항목을 사용하지 않아야 합니다. 모든 MME 서비스가 중지되면 전체 캐시를 지워야 합니다.
솔루션
페이징 기능의 자동 비활성화 작동 방식
앞에서 설명한 것처럼 중요한 페이징 컨피그레이션에서 구성된 페이징 단계만 트리거될 뿐, 이는 사실이 아니며 이 기능에는 페이징 캐시의 종속성이 있습니다. 따라서 특정 TAI-MME 관리자 매핑이 Sessmgr 페이징 캐시에서 이미 사용 가능한 경우 중요 페이징은 구성된 페이징 단계에 대해서만 페이징 트리거를 사용합니다. 그러나 특정 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 이후에는 더 이상 페이징이 시도되지 않습니다. 그러나 구성되지 않은 페이징 단계에서도 페이징 시도를 볼 수 있는 예외적인 조건이 있습니다. 자세한 내용은 '심각한 페이징 예외 조건' 섹션을 참조하십시오.
심각한 페이징 예외 조건
앞에서 언급한 것처럼, 중요한 페이징 아래에 구성된 페이징 단계만 트리거되지만, 이는 사실이 아니며 이 기능에서 페이징 캐시의 종속성이 있음을 알 수 있습니다. 따라서 특정 TAI-MME 관리자 매핑이 Sessmgr 페이징 캐시에서 이미 사용 가능한 경우 중요 페이징은 구성된 페이징 단계에 대해서만 페이징 트리거를 사용합니다. 그러나 특정 TAI에 대해 사용 가능한 TAI-MMEMgr 매핑이 없는 경우, 페이징 단계 아래에 구성되지 않은 경우에도 후속 페이징 단계에서도 시도가 표시될 수 있습니다. 그리고 매핑이 페이징 캐시 아래에 구축되면 다시 중요한 페이징의 일반 논리를 사용합니다.
기능 테스트

앞에서 언급한 바와 같이 페이징 단계 1 및 2는 페이징 프로파일 paging-ps 아래에 구성됩니다. 따라서 1단계와 2단계에서 페이징 실패가 발생할 경우 다른 3단계와 4단계에서 다른 페이징 시도를 건너뛰었지만 몇 가지 시도를 할 수 있습니다. 이는 '심각한 페이징 예외 조건'에서 정의한 조건 때문입니다.