HLR MAP_RESET으로 인해 SGSN의 STP 혼잡, IMSIMGR Over State 및 SCTP 링크 플랩
목차
소개
이 문서에서는 Cisco 5000 Series ASR(Aggregated Services Router)의 SGSN(Serving General Packet Radio Service)에서 발생하는 문제에 대해 설명합니다. 이 문제에 대한 몇 가지 해결 방법도 설명되어 있습니다.
배경 정보
ASR SGSN의 이 이벤트 체인은 이 문서에서 설명합니다.
- 11월 21일 오전 6:25:MAP_RESET은 HLR(Home Location Register)에 의해 전송되었습니다.
- 11월 21일 오전 8:13:STP-2(Signal Transfer Point 2)에 대해 혼잡 경보가 발생합니다.
- 11월 21일 오전 8:23:STP-1 및 STP-2에 대해 혼잡 경보가 발생합니다.
- 11월 21일 오전 8:48:IMSIMGR(International Mobile Subscriber Identity Manager)이 경고 상태로 이동합니다.
- 11월 21일 오전 10:07:링크는 STP-2에서 SGSN으로 재설정됩니다.
- 11월 21일 오전 10:15:SGSN LU(Location Update) 통계에서 개선이 관찰됩니다.
- 11월 21일, 오전 10:30:통계가 오전 10시에 개선되기 시작한다.
- 11월 21일 오전 11:15:SGSN LU 통계에서 감소가 관찰됩니다.
- 11월 21일 오전 11:41:STP 팀은 STP-2의 SLC(Signaling Link Code)-1이 트래픽을 수신하지 않고, SLC가 재설정되고, 트래픽이 정상으로 돌아간다고 보고합니다.
- 11월 21일 오전 11:42:STP의 SLC-1에 대해 SGSN에 혼잡 경보가 발생합니다.
- 11월 21일 오후 12:00: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는 하루가 진행됨에 따라 이러한 컨텍스트를 탐색하려고 시도합니다.
첫 번째 업링크 패킷이 수신되면 SGSN은 GLU 메시지를 트리거합니다.수십만 개의 UE가 있기 때문에 STP는 생성되는 트래픽의 양을 처리할 수 없고 지속적인 정체 상태로 전환됩니다.
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 로드 공유 메커니즘에 따라 MTP3(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
각 새 통화 IMSIMGR은 P-TMSI(Packet Temporary Mobile Subscriber Identity) 연결 및 RU(Routing Area Update) 요청을 처리해야 합니다.
보수적인 관찰을 통해 시스템은 초당 6,850건의 2G 연결 요청 및 초당 약 5,313건의 3G 연결 요청을 수신합니다.네트워크 오버로드 보호를 위해 설정할 수 있는 최대 값은 초당 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) 프로세스에 따라 처리됩니다.
기본 설정에 따라 거부 또는 삭제 옵션을 선택할 경우, Cisco에서는 네트워크의 혼잡을 나타내기 위해 거부 원인 코드를 사용하는 것이 좋습니다. 그러면 업링크 절차를 시도하기 전에 네트워크 조건을 이해할 수 있습니다.
HLR 실패
이 섹션에서는 3GPP(3Generation Partnership Project) TS(Technical Specification) 23.060에 따라 HLR 재시작 시 SGSN 동작을 설명합니다.SGSN이 MAP 재설정을 수신할 때마다 가입자에 대해 HLR에 UL 요청을 보내야 합니다.
HLR이 다시 시작되면 하나 이상의 MS가 등록된 각 SGSN에 재설정 메시지를 보냅니다.따라서 SGSN-to-Mobile Switching Center(MSC)/VLR(Visiting Location Register) 연결이 있는 경우 SGSN이 관련 Mobile Management 컨텍스트를 유효하지 않은 것으로 표시합니다.첫 번째 유효한 LLC(Logical Link Control) 프레임(A/Gb 모드의 경우)을 받거나 표시된 모바일 스테이션에서 첫 번째 유효한 GPRS GPT-U(GPRS Tunneling Protocol User) 패킷 또는 업링크 신호 메시지(Iu 모드의 경우)를 수신한 후 SGSN은 연결 요청 또는 SGSN RA(Inter-SGSN Routing Area) 업데이트 절차에서 UL을 수행합니다.또한 NGPRS(Non-GPRS Alert Flag)가 설정된 경우 Non-GPRS Alert 절의 절차가 따릅니다.MSC/VLR에 대한 UL 절차 및 절차는 높은 신호 로드를 피하기 위해 해당 시간의 리소스 사용에 따라 최대 운영자 구성에 대한 SGSN에 의해 지연될 수 있습니다.
권장 사항
이 문제를 해결하려면 다음 단계를 완료하는 것이 좋습니다.
- 초당 새 연결 수를 늘립니다.이 값은 평균 연결 요청 수를 기준으로 계산할 수 있습니다.
- STP 링크의 TPS(Transactions Per Second)를 이상적인 값으로 늘립니다.
- 기본 SCTP-RTO-MAX 값 600(600*100 = 60,000)을 5(5*100ms)로 변경합니다. 예를 들어 TPS가 4,000개인 STP 2개에 대해 SGSN에서 초당 최대 1,000건의 연결 요청을 지원할 수 있습니다.
각 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 데이터를 계속 수신하며, 피어 포인트 코드가 병목 상태에서 나오지 않을 경우 해당 패킷은 대기 대기열로 삭제될 수 있습니다.
예를 들면 다음과 같습니다.
- SCTP는 M3UA에 흐름 제어 시작 표시를 보냅니다.
- M3UA는 연결에 대한 혼잡 활성 플래그를 설정하고 흐름 제어 상태에 대해 SCTP를 정기적으로 폴링하기 시작합니다.
- 연결이 흐름 제어에 있는 동안 QUEUE_SIZE가 8,000에 도달할 때까지 해당 연결에 대한 향후 데이터 요청을 대기시킵니다. 이 시점에서 연결에 대한 이후 메시지는 삭제됩니다.
- 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 타이머가 더 높습니다.
피드백