HLR MAP_RESET으로 인해 SGSN에서 STP 혼잡, IMSIMGR Over State 및 SCTP 링크 플랩

소개

이 문서에서는 Cisco 5000 Series ASR(Aggregated Services Router)의 SGSN(Serving GPRS(General Packet Radio Service) Supporting Node)에서 발생하는 문제를 설명합니다. 이 문제에 대한 몇 가지 가능한 해결 방법도 설명되어 있습니다.

배경 정보

ASR SGSN의 이 특정 이벤트 체인은 이 문서에서 설명합니다.

1. 11월 21일 오전 6:25: HLR(Home Location Register)에서 MAP_RESET을 보냈습니다.
   
   
2. 11월 21일 오전 8:13: STP-2(Signal Transfer Point 2)에 대한 혼잡 경보가 발효됩니다.
   
   
3. 11월 21일 오전 8:23: STP-1 및 STP-2에 대한 혼잡 경보가 발생합니다.
   
   
4. 11월 21일 오전 8:48: International Mobile Subscriber Identity Manager(IMSIMGR)가 경고 상태로 전환됩니다.
   
   
5. 11월 21일, 10:07 AM: STP-2에서 SGSN으로 링크가 재설정됩니다.
   
   
6. 11월 21일 오전 10:15: SGSN LU(Location Update) 통계에서 개선이 관찰되었습니다.
   
   
7. 11월 21일, 10:00 “ AM € 10:30: 오전 10시부터 통계 개선이 시작됩니다.
   
   
8. 11월 21일 오전 11:15: SGSN LU 통계에서 감소 현상이 관찰되었습니다.
   
   
9. 11월 21일 오전 11:41: STP 팀은 STP-2의 SLC(Signaling Link Code)-1이 트래픽을 수신하지 않고, SLC가 재설정되며, 트래픽이 정상으로 돌아간다고 보고합니다.
   
   
10. 11월 21일 오전 11:42: STP의 SLC-1에 대해 SGSN에서 혼잡 경보가 발생합니다.
    
    
11. 11월 21일, 12:00 PM: SLC-3이 재설정된 후 GPRS LU 통계가 개선됩니다.

문제

HLR은 MAP_RESET 메시지를 수신하면 GPRS GLU(Location Update)에 대한 플래그를 설정합니다. UE(User Equipment)가 첫 번째 업링크 패킷을 전송하면 SGSN은 HLR에 GLU 메시지를 보냅니다.

At  7 AM SGSN , Nov 21st 2014 had
******** show subscriber summary *******
Total Subscribers:             2386266
Active:                        2386266
sgsn-pdp-type-ipv4:            942114

 
예제 출력에 표시된 바와 같이 SGSN에는 950,000개의 PDP(Packer Data Protocol) 컨텍스트가 있으며, UE는 하루가 진행됨에 따라 해당 컨텍스트를 탐색하려고 시도합니다.

제1 업링크 패킷이 수신되면 SGSN은 GLU 메시지를 트리거한다. STP는 수십만 개의 UE가 있기 때문에 생성되는 트래픽의 양을 처리할 수 없으며 영구적인 혼잡 상태로 전환됩니다.

메시지가 SGSN에서 대기열에 추가되고 최대 재전송 시간 제한이 발생합니다. 모든 GLU 메시지가 SGSN에서 HLR로 전달되지 않으므로 SGSN은 모바일 가입자를 분리하고 재연결을 요청해야 합니다. 그러면 분리된 모든 가입자가 연결을 시도하며, 이는 인바운드 연결 요청 수의 급증을 유발합니다. 네트워크 과부하 보호가 적용돼 접속시도가 대부분 혼잡으로 거부되고 모바일 가입자는 새로운 시도를 할 수밖에 없다.

이러한 일련의 사건들이 전개되면서 연쇄적인 영향을 미치게 된다. 많은 SAI(Send Authentication Information) 메시지, GLU 메시지 및 MAP-IMEI_CHECK 메시지가 SGSN 대기열에 머물러 있거나 삭제됩니다. 따라서 모든 STP-1 및 STP-2 링크가 혼잡 상태에 도달합니다. 각 STP에는 4개의 신호 링크가 있지만 이 시나리오에서는 STP-2의 처음 3개 링크가 매우 오랫동안 복구되지 않습니다.

혼잡 경보는 다음과 같습니다. 여기서 모든 STP 링크가 STP-2의 혼잡 상태로 이동하는 것을 확인할 수 있습니다.

Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-1 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-2 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-3 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:13:29 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:18:48 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:20:00 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:22:52 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:22:55 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:23:22 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:26:33 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:28:06 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:28:45 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 09:27:27 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1

표시된 대로 PSP(Peer Server Process) 4만 지워졌으며 나머지는 여전히 혼잡 상태입니다.

Fri Nov 21 08:18:47 2014 Internal trap notification 1075 (M3UAPSPCongestionCleared)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congestion cleared congLevel-0

솔루션

이 섹션에서는 이전 섹션에서 설명한 문제를 해결하는 방법에 대해 설명합니다.

STP 링크가 너무 많은 트래픽 수신

이전 섹션에서 설명한 것처럼 STP의 특정 링크 하나가 많은 양의 트래픽을 수신합니다. STP-2의 처음 3개 링크가 혼잡 상태로 전환되고 복구되지 않는 것을 볼 수 있습니다. 따라서 하나의 링크만 사용할 수 있으며 혼잡 경보는 SLC-3(또는 peer-server-2-peer-server-process-4)에서 지워집니다. 

SGSN 로드 공유 메커니즘에 따라 MTP(Message Transfer Part) Level 3(MTP3) User Adaptation Layer(M3UA) 패킷을 4개 링크 모두에서 균등하게 보내야 합니다. 그러나 SNMP(Simple Network Message Protocol) 트랩에서 처음 3개의 STP-2 링크가 주기적으로 혼잡하므로 모든 트래픽이 SLC-3 링크(트래픽을 라우팅할 수 있는 유일한 STP 링크)로 라우팅됩니다. 따라서 STP-2 링크 간에 트래픽 분배가 왜곡되는 이유가 설명됩니다.

혼잡 상황에서는 하나 이상의 링크가 혼잡한 상태와 혼잡하지 않은 상태 사이를 전환하므로 사용 가능한 링크만 트래픽을 공유합니다. 이러한 이유로 링크 중 하나에서 활용도가 더 높아집니다. 이렇게 하려면 링크를 복구하기 위해 링크를 재설정해야 합니다.

다음 출력은 M3UA 레벨 통계 및 분리 통계를 보여줍니다. 고려해야 할 중요한 통계는 STP-2 PSP 인스턴스 4이며, 여기서 비정상적인 트래픽을 볼 수 있습니다. 

Time   #1:ss7rd-m3ua-psp-data-tx   #2:ss7rd-m3ua-psp-error-tx  #3:ss7rd-m3ua-psp-data-rx
21-11-14 7:30             37409                      0                     37942
21-11-14 8:00             43677                      0                     43866
21-11-14 8:30             190414                     0                     71844
21-11-14 9:00             547418                     0                     104135
21-11-14 9:30             536019                     0                     102477
21-11-14 10:00            376797                     0                     132227
21-11-14 10:30            100394                     0                     97302
21-11-14 11:00            119652                     0                     114809
21-11-14 11:30            107073                     0                     95354

다음은 STP 데이터입니다.

   DATE             TIME     LSN     LOC  SLC    LINK        TX %     RX %
11/21/2014 9:00 sgsncisco   5216       3   A     IPVL        11.26    62.07
11/21/2014 9:00 sgsncisco   5213       0   A1    IPVL        11.29    4.86
11/21/2014 9:00 sgsncisco   5214       1   A1    IPVL        11.27    4.85
11/21/2014 9:00 sgsncisco   5215       2   A     IPVL        11.23    4.7

이 출력은 문제가 발생한 시점의 초당 분리 수를 보여줍니다.

Time                 #13:2G-ms-init-detach      #14:2G-nw-init-detach

21-11-14 6:30                  136465                 7400
21-11-14 7:00                  149241                 9557
21-11-14 7:30                  165788                 12630
21-11-14 8:00                  179311                 16963
21-11-14 8:30                  125564                 44759
21-11-14 9:00                  112461                 95299
21-11-14 9:30                  240341                 112461
21-11-14 10:00                 288014                 116298
21-11-14 10:30                 203261                 123300
21-11-14 11:00                  67788                 122945

이 출력은 WEM에 따른 초당 어태치를 보여줍니다.

Time           #3:2G-total-attach-req-all  Request/Second

21-11-14 8:00         738279                205.078
21-11-14 9:00         14053511              3903.753
21-11-14 10:00        24395071              6776.409
21-11-14 11:00        24663454              6850.959
21-11-14 12:00        17360687              4822.413

경고 상태의 IMSIMGR

각 새 통화 IMSI/패킷 P-TMSI(Temporary Mobile Subscriber Identity) 연결 및 RAU(Routing Area Update) 요청은 IMSIMGR에서 처리해야 합니다.

신중하게 관찰하면 시스템은 초당 6,850개의 2-G 어태치 요청 및 초당 약 5,313개의 3-G 어태치 요청의 피크 값을 수신합니다. 네트워크 오버로드 보호를 위해 설정할 수 있는 최대값은 초당 연결 요청 5,000개입니다. IMSIMGR을 동작 가능한 상태로 유지하기 위해, 시스템은 UE들로부터의 그러한 많은 수의 호출들을 처리할 수 없다.

이 문제는 대기열 크기가 초당 연결 요청 1,500개에 도달하는 오전 8시 이후에 시작됩니다.

network-overload-protection sgsn-new-connections-per-second 500 action
 reject-with-cause congestion queue-size 1500 wait-time 5

초당 약 12,000건의 어태치 요청이 있으므로 IMSIMGR에서 거의 9,000건의 통화를 처리하고 거부합니다. 그러면 IMSIMGR CPU 처리가 높은 상태에 도달합니다.

SGSN이 초당 구성된 수보다 많은 연결 요청을 수신하는 경우, 요청은 페이싱 대기열에서 버퍼링되며 높은 인바운드 연결 속도로 인해 버퍼가 오버플로될 때만 삭제됩니다. 대기열에 있는 메시지는 대기열에 있는 메시지 수명이 구성된 대기 시간을 초과할 때 에이징이 완료될 때까지 FIFO(First-In, First-Out) 프로세스에 따라 처리됩니다.

기본 설정에 따라 거부 또는 삭제 옵션을 선택하는 경우, 네트워크의 정체를 나타내기 위해 거부 원인 코드를 사용하는 것이 좋습니다. 그러면 업링크 절차를 시도하기 전에 네트워크 상태를 파악할 수 있습니다. 

HLR 실패

3GPP(3rd Generation Partnership Project) TS(Technical Specification) 23.060에 따라 이 섹션에서는 HLR 재시작 동안의 SGSN 동작에 대해 설명합니다. SGSN은 MAP 재설정을 수신할 때마다 가입자에 대한 HLR을 향해 UL 요청을 전송할 것으로 예상됩니다.

HLR이 다시 시작되면 하나 이상의 MS(Mobile Station)가 등록된 각 SGSN에 재설정 메시지를 보냅니다. 그러면 SGSN-MSC(Mobile Switching Center)/VLR(Visiting Location Register) 연결이 있는 경우 SGSN에서 관련 Mobile Management 컨텍스트를 잘못된 것으로 표시합니다. 첫 번째 유효한 LLC(Logical Link Control) 프레임(A/Gb 모드) 수신 후 또는 첫 번째 유효한 GPT-U(GPRS Tunneling Protocol User) 패킷 또는 업링크 시그널링 메시지(Iu 모드) 수신 후(표시 이동국에서) SGSN은 연결 요청 또는 RA(inter-SGSN Routing Area) 업데이트 절차처럼 HLR에 UL을 수행합니다. 또한 NGPRS(Non-GPRS Alert Flag)가 설정되어 있으면 Non-GPRS Alert 절의 절차를 따릅니다. UL 절차 및 MSC/VLR에 대한 절차는 높은 시그널링 부하를 피하기 위해 그 시점에 리소스의 사용에 따라 최대 운영자 컨피그레이션을 위해 SGSN에 의해 지연될 수 있다.

참고: TS 23.007 [5]에 설명된 대로 HLR 데이터를 비휘발성 저장소에 주기적으로 백업해야 합니다.

권장 사항

이 문제를 해결하려면 다음 단계를 완료하는 것이 좋습니다.

1. 초당 새 연결 수 증가 이는 평균 어태치 요청 수를 기준으로 계산할 수 있습니다.
   
   
2. STP 링크의 TPS(Transactions Per Second)를 이상적인 값으로 늘립니다.
   
   
3. 기본 SCTP-RTO-MAX 값 600(600*100 = 60,000)을 5(5*100ms)로 변경합니다. 예를 들어 TPS가 4,000개인 2개의 STP의 경우 SGSN에서 초당 최대 1,000개의 연결 요청을 지원할 수 있습니다.

참고: 각 어태치 요청은 STP에 대해 4개의 트랜잭션을 발생시킵니다. 즉, 초당 1,000건의 어태치 요청이 4,000건의 TPS를 발생시킵니다.

각 STP에는 4개의 링크가 있으므로 STP 링크당 125개의 어태치 요청을 처리할 수 있습니다. 이는 모든 STP 링크에 동일하게 배포됩니다. 그러나 링크 중 하나가 다운되면 많은 재연결 시도가 나타나고, 대기열이 가득 차고, 패킷 폐기가 발생합니다. 더 많은 링크가 다운되면 트래픽이 불균일하게 분산됩니다.

트래픽 흐름

UE 트래픽은 선형 방식을 따르지 않습니다. 일반적으로 버스트 및 많은 재연결 시도에서 발생합니다. SGSN은 번들에서 STP로 트래픽을 전송합니다. 이때 트래픽 양이 STP에 구성된 TPS를 초과합니다. 이렇게 하면 STP의 일부 링크가 이미 더 많은 통화를 처리하는 경우 낮은 윈도우 크기를 알리기 시작하고 SGSN은 대기열에 있는 SCTP 데이터 청크를 대기열에 추가하기 시작합니다. 그런 다음 RTO MAX 타이머가 만료될 때까지 기다립니다.

STP가 정기적으로 양호한 알림 윈도우 크기를 전송하는 경우, SCTP_RTO_MAX 값이 5초 이하로 감소하면 더 많은 SCTP 데이터 청크를 전송할 수 있습니다. 큐가 더 빠르게 지워지며 M3UA 혼잡 경보가 트리거되지 않습니다. 또한 패킷 흐름을 제어하기 위해 SCTP에 의해 트리거되는 내부 흐름 제어 플래그가 표시되지 않아야 합니다.

SGSN은 STP가 수락할 수 있는 양의 패킷만 전송하며, 이는 보급된 윈도우 크기를 기반으로 합니다. STP당 TPS 링크를 늘리면 STP 혼잡을 방지하고 SCTP_RTO_MAX 타이머를 줄이는 데 도움이 됩니다.

SGSN에서 M3UA 혼잡 경보 트리거

SCTP(Stream Control Transmission Protocol) SACK(Selective Acknowledgement) 메시지의 알려진 윈도우 크기가 0(또는 0)에 가까우면 SGSN에서 M3UA 경보를 발생시켜 해당 피어 엔드포인트에 대해 메시지를 보내지 않도록 지정합니다. 이렇게 하면 링크가 플랩되거나 정체된 상태로 전환됩니다. SGSN이 더 높은 윈도우 크기를 전송하므로 피어 노드에서 M3UA 데이터를 계속 수신하며, 피어 포인트 코드가 혼잡 상태를 벗어나지 않는 경우 이러한 패킷이 대기 큐로 삭제될 수 있습니다.

예를 들면 다음과 같습니다.

1. SCTP는 M3UA에 흐름 제어 시작 표시를 보냅니다.
   
   
2. M3UA는 연결에 대한 혼잡 활성 플래그를 설정하고 SCTP의 흐름 제어 상태에 대해 주기적으로 폴링을 시작합니다.
   
   
3. 연결이 흐름 제어에 있는 동안에는 QUEUE_SIZE가 8,000에 도달할 때까지 해당 연결에 대한 향후 데이터 요청을 대기시킵니다. 이 시점에서 연결에 대한 향후 메시지는 삭제됩니다.
   
   
4. STP가 적절한 알림 윈도우 크기를 전송하면 M3UA는 5,000에 도달할 때까지 대기열에 있는 메시지를 비우려고 시도합니다. RTO 타이머도 여기에 해당됩니다.

SCTP 메시지는 흐름 제어 플래그가 True가 되는 연결에 대해서만 대기되며, SGSN은 STP 응답에 따라 처리합니다.

*Peer Server Id :        2   Peer Server Process Id:        2 
 
 Association State : ESTABLISHED
 
 Flow Control Flag                       :                TRUE 
 Peer INIT Tag                           :                20229
 SGSN INIT Tag                           :           3315914061
 Next TSN to Assign to                          
 Outgoing Data Chunk                   :           3418060778
 Lowest cumulative TSN acknowledged      :           3418060634
 Cumulative Peer TSN arrived from peer   :            103253660
 Last Peer TSN sent in the SACK          :            103253658
 Self RWND                               :              1048576
 Advertised RWND in received SACK        :                    8
 Peer RWND(estimated)                    :                    8
 Retransmission counter                  :                    0
 Zero Window Probing Flag                :                FALSE
 Last Tsn received during ZWnd Probing   :                    0
 Bytes outstanding on all                       
 addresses of this association        :                19480
 Congestion Queue Length                 :                  143
  Ordered TSN assignment Waiting QLen     :                 8050 
 Unordered TSN assignment Waiting QLen   :                    0
 Total number of GAP ACKs Transmitted    :                  279
 Total number of GAP ACKs Received       :                58787
 
 
 Path No.                                :                    1
 
 Current CWND                            :                11840
 SSThresh                                :                11840
 Partial Bytes Acked                     :                    0
 Bytes Outstanding for this Path         :                19480
 Current RTO for this Path(in ms)        :                60000

그림과 같이, 총 아웃바운드 청크 수가 5,000개 제한(8050+143=8193)을 초과하고 60초 RTO 최대 타이머를 작동하기 때문에 SCTP 데이터 요청이 취소됩니다. 또한 RTO 타이머가 더 높습니다.