Беспроводные сети : узел поддержки Cisco SGSN Serving GPRS Support Node

Перегрузка STP, IMSIMGR по Состоянию и откидные створки ссылки SCTP в SGSN из-за HLR MAP_RESET

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает проблему, с которой встречаются на Служащем  Узле Поддержки General Packet Radio Service (GPRS) (SGSN) Cisco Маршрутизатор Aggregated Services (ASR) серии 5000. Некоторые возможные обходной пути для этой проблемы также описаны.

Внесенный Кришной Кишором D V, специалистом службы технической поддержки Cisco.

Общие сведения

Эта определенная цепочка событий на ASR SGSN описана в этом документе:

  1. 21-го ноября, 6:25: MAP_RESET передавался Домашним регистром местоположения (HLR).

  2. 21-го ноября, 8:13: аварийный сигнал перегрузки выдан для Пункта передачи сигнала 2 (STP 2).

  3. 21-го ноября, 8:23: аварийный сигнал перегрузки выдан для STP 1 и STP 2.

  4. 21-го ноября, 8:48: Менеджер Международного идентификатора мобильного абонента (IMSIMGR) перемещается в предупредить состояние.

  5. 21-го ноября, 10:07: ссылки перезагружены от STP 2 к SGSN.

  6. 21-го ноября, 10:15: Улучшение наблюдается в stats Обновления информации о местоположении (LU) SGSN.

  7. 21-го ноября, 10:00 - 10:30: статистические данные начинают улучшаться в 10:00.

  8. 21-го ноября, 11:15: снижение наблюдается в stats LU SGSN.

  9. 21-го ноября, 11:41: команда STP сообщает, что Код звена сигнализации (SLC),-1 из STP 2 не получают трафик, SLC, перезагружен, и трафик возвращается к обычному.

  10. 21-го ноября, 11:42: аварийный сигнал перегрузки выдан на SGSN для SLC 1 STP.

  11. 21-го ноября, 12:00: После того, как SLC 3 перезагружен, stats LU GPRS улучшается.

Проблема

Когда HLR получает сообщение MAP_RESET, он устанавливает флаг для Обновления информации о местоположении GPRS (GLU). Когда Пользовательское оборудование (UE) передает свои первые соединительные пакеты, SGSN передает сообщение GLU к HLR.

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), и UEs пытаются просмотреть их, в то время как развивается день.

Когда первые соединительные пакеты получены, SGSN инициирует сообщение GLU. С тех пор существуют сотни тысяч UEs, STP не может обработать объем трафика, который генерируется, и это перемещается в постоянное состояние перегрузки.

Сообщения помещены в очередь в SGSN, и происходит максимальный тайм-аут повторной передачи. Так как все сообщения GLU не проходят от SGSN до HLR, SGSN вынужден отсоединить мобильных абонентов и запросить, чтобы они повторно прикрепили. Все отдельные абоненты тогда пытаются подключить, который вызывает внезапный скачок в количестве входящих прикрепляемых запросов. Так как защита перегрузки сети применена, большинство попыток подключить отклонено из-за перегрузки, и мобильные абоненты вынуждены предпринять новую попытку.

Поскольку эта цепочка событий разворачивается, она производит каскадное влияние. Много сообщений Информации для аутентификации передачи (SAI), сообщений GLU и сообщений MAP-IMEI_CHECK застревают в очереди SGSN или отброшенный. Поэтому весь STP 1 и ссылки STP 2 достигает состояния перегрузки. Каждый STP имеет четыре звена сигнализации, но в этом сценарии, первые три ссылки STP 2 не восстанавливаются очень долго.

Вот сигналы тревоги перегрузки, в которых вы видите, что весь 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) 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 в состояние перегрузки и никогда не восстанавливаются, таким образом, только одна ссылка доступна, и сигнал тревоги перегрузки очищен на SLC 3 (или peer-server-2-peer-server-process-4). 

Согласно механизму распределения нагрузки SGSN, это должно передать Уровень адаптации пользователя Уровня 3 (MTP3) Стороны передачи сообщений (MTP) (M3UA) пакеты одинаково на всех четырех ссылках. Однако от trap-сообщений Протокола сообщения простой сети (SNMP), первые три ссылки 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) присоединение и запрос Обновления области маршрутизации (RAU) должен быть обработан IMSIMGR.

С консервативным наблюдением система получает пиковое значение 6,850 запросов присоединения 2-G в секунду и приблизительно 5,313 запросов присоединения 3-G в секунду. Максимальное значение, которое можно установить для защиты перегрузки сети, является 5,000 запросов присоединения в секунду. Для хранения IMSIMGR в действующем состоянии система не может обработать такое большое число вызовов от UEs.

Когда размер очереди достигает 1,500 запросов присоединения в секунду, эта проблема начинается после 8:00:

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

С тех пор существует приблизительно 12,000 запросов присоединения в секунду, почти 9,000 требований обработаны IMSIMGR и отклонены. Это заставляет Обработку ЦПУ IMSIMGR достигать высокого состояния.

Если SGSN получает больше, чем настроенный номер запросов присоединения за секунду, то запросы буферизованы в следующей очереди и только отброшены когда переполнение буфера из-за высокой входящей скорости присоединения. Когда срок действия сообщения с очередями пересекает настроенное время ожидания, сообщения в очереди обработаны в соответствии с Первым прибыл, Первым обслужен (FIFO) процесс пока они ageout.

При выборе отклонения или опций отбрасывания на основе предпочтения Cisco рекомендует использовать код причины отклонения для указания на перегрузку в сети, которая позволяет вам понимать состояния сети перед попыткой соединительной процедуры. 

Сбой HLR

Согласно Технической спецификации (TS) Проекта партнерства третьего поколения (3GPP) 23.060, этот раздел описывает поведение SGSN во время перезапуска HLR. Каждый раз, когда SGSN получает сброс MAP, он, как ожидают, отправит запрос UL к HLR для его абонентов.

Когда HLR перезапускает, он передает сообщение сброса к каждому SGSN, к которому зарегистрированы или больше его Мобильных станций (MSS). Если SGSN к мобильному коммутационному центру (MSC) / Посещающий Регистр местоположения (VLR) ассоциация существует, это заставляет SGSN отмечать соответствующие Мобильные контексты менеджмента как недопустимые. После получения первого допустимого кадра Протокола LLC (для режима A/Gb) или после получения первого допустимого Пользователя Протокола туннелирования GPRS (GPT-U) пакет или соединительное сигнальное сообщение (для режима Iu) от отмеченной Мобильной станции, SGSN выполняет UL к HLR как в запросе присоединения или inter-SGSN процедурах обновления Области маршрутизации (RA). Кроме того, если Флаг предупреждения неGPRS (NGAF) установлен, процедура в пункте Предупреждения неGPRS выполнена. Процедура UL и процедура к MSC/VLR могли бы быть задержаны SGSN для максимальной конфигурации оператора, зависящей от использования ресурсов в то время во избежание высокой сигнальной загрузки.

Примечание: Периодическая резервная копия данных HLR к энергонезависимому хранилищу является обязательной, как описано в TS 23.007 [5].

Рекомендации

Cisco рекомендует выполнить эти шаги для решения этого вопроса:

  1. Увеличьте число новых соединений в секунду. Это может быть вычислено основанное в среднем количество запросов присоединения.

  2. Увеличьтесь Transactions Per Second (TPS) в STP связывается с идеальным значением.

  3. Измените значение MAX RTO SCTP по умолчанию 600 (600*100 = 60,000) к 5 (5*100 мс). Например, для двух STPs с 4,000 TPS, можно поддержать до 1,000 запросов присоединения в секунду от SGSN.

Примечание: Каждый запрос присоединения приводит к четырем транзакциям к STP, что означает, что 1,000 запросов присоединения в секунду приводят к 4,000 TPS.


Идеально, каждый STP имеет четыре ссылки так, чтобы 125 запросов присоединения могли быть обработаны на ссылку STP. Это распределено одинаково через все ссылки STP. Однако, если одна из ссылок выключается, много попыток повторного соединения замечены, очередь становится полной, и отбрасывания пакетов происходят. Если больше ссылок выключается, то трафик неравномерно распределен.

Трафик

Трафик UE не придерживается линейной формы. Это обычно происходит в пакете и со многими попытками повторного соединения. SGSN передает трафик в связках (bundle) к STP. В то время суммы трафика превышают настроенный TPS на STP. Это заставляет некоторые ссылки в STP начинать объявлять низкий размер окна, если они уже обрабатывают больше вызовов, и SGSN начинает помещать в очередь блоки данных SCTP, которые помещены в очередь. Это тогда ждет RTO таймер MAX для истечения.

Если STP периодически передает хороший объявленный размер окна, то должна существовать возможность передать больше блоков данных SCTP, если значение SCTP_RTO_MAX уменьшено до пяти секунд или меньше. Очередь очищена быстрее, и сигнал тревоги перегрузки M3UA не инициирован. Кроме того, вы не должны видеть Флаг управления Внутреннего потока, инициированный SCTP для управления потоком пакетов.

SGSN только передает пакеты в сумме, которую может принять STP, который основывается на объявленном размере окна. При увеличении TPS на ссылку STP он помогает избегать перегрузки STP и уменьшает таймер SCTP_RTO_MAX.

Триггеры для M3UA переполненный сигнал тревоги в SGSN

Если объявленный размер окна в Протоколе SCTP Выборочное Подтверждение (SACK), который сообщение близко к нулю (или нулю), то SGSN выдает аварийный сигнал M3UA, чтобы указать, что сообщения не должны быть переданы за той одноранговой оконечной точкой. Это заставляет ссылку колебаться или перемещаться в состояние перегрузки. Так как SGSN передает более высокий размер окна, вы продолжаете получать данные M3UA от одноранговых узлов, и те пакеты могли бы быть брошены в ждущую очередь, если одноранговый точечный код никогда не выходит из состояния перегрузки.

Например:

  1. SCTP передает управление потоками, запускают индикацию M3UA.

  2. M3UA устанавливает перегрузку активный флаг для ассоциации и начинает опрашивать SCTP периодически о его статусе управления потоками.

  3. В то время как ассоциация находится на управлении потоками, она помещает будущие запросы данных в очередь для той ассоциации, пока QUEUE_SIZE не достиг 8,000. В той точке сбрасывают от будущих сообщений для ассоциации.

  4. Если STP передает надлежащий объявленный размер окна, то M3UA пытается освободить сообщения, которые помещены в очередь, пока это не достигает 5,000. Таймер RTO также играет роль в этом.

Сообщения SCTP помещены в очередь только для тех ассоциаций, где флаг управления потоками становится Правда, и 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.



Document ID: 118937