Беспроводные сети / Мобильные решения : Узел Gateway GPRS Support Node (GGSN)

Поведение GGSN с ошибками активации PDP и никакими ответами эха GTP

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

Введение

Этот документ описывает поведение  General Packet Radio Service (GPRS) шлюза, Поддерживающего Узел (GGSN), когда Обслуживание узла поддержки GPRS (SGSN) не отвечает на запрос эха Протокола туннелирования GPRS (GTP), который передается от GGSN.

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

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

Когда SGSN не отвечает на запросы эха GTP, вы могли бы испытать высокие ошибки активации Протокола коммутации пакетов (PDP) в GGSN во время периода времени. Вот некоторые вопросы, которые могли бы возникнуть в этом сценарии:

  1. Создавание PDP или Обновления запросы PDP от SGSN достигают GGSN?

  2. Когда запросы эха GTP отказывают от GGSN до SGSNs, как GGSN должен вести себя, если Обновление контекст PDP, который передается от GGSN, не получает ответ?

  3. Как GGSN отказывает PDP, если он не получает ответ эха GTP или ответ для сообщений незапроса эха, которые поступают от SGSN для этого PDP?

  4. Как делает отсутствие в GTP echo/non-echo, ответы непосредственно влияют на ошибки активации PDP?

Поведение GGSN

Если сообщения не достигают GGSN, то SGSN вызывает сигнал тревоги ошибки пути и тихо отбрасывает их. Кроме того, если нет никакого ответа эха, полученного для запроса эха, который инициируется GGSN, он указывает, что узел не работает, таким образом, GGSN локально очищает вызовы, которые отнесены к тому узлу.

В подробных выходных данных command поддержки показа или показе gtpc статистика многословные выходные данные command, можно просмотреть счетчики Таймаута Req GGSN:

#show gtpc statistics verbose 

SGSN Restart: Timeout:
Create PDP Req: 5 GTPC Echo Timeout: 149160
Update PDP Req: 0 GTPU Echo Timeout: 0
Echo Response: 312 GGSN Req Timeout: 24182


Path Management Messages:
Echo Request RX: 34006780 Echo Response TX: 34006780
Echo Request TX: 29603851 Echo Response RX: 29537123

Если вы исследуете сообщения запроса эха, которые переданы от GGSN до SGSN, кажется, что GGSN не получает ответы эха. Необходимо гарантировать, что сообщения не отброшены из-за проблем маршрутизации в сети или что SGSN не доступен.

Самая обычная проблема является сбоями контрольного пути, которые заставляют большое число роуминга SGSNs становиться недостижимым.

Если существует какое-либо управляющее сообщение GTP (такое как обновление запрос контекста PDP) от GGSN, который не получает ответ после того, как все попытки исчерпаны, GGSN думает, что узел недостижим и разъединяет только, что отдельный сеанс сообщает о причине как об Ошибке пути. Контекст PDP удален на GGSN, но не уведомлен SGSN. Это количество определено с этими статистическими данными:

SGSN Restart:                       Timeout:
Create PDP Req: 5 GTPC Echo Timeout: 149160
Update PDP Req: 0 GTPU Echo Timeout: 0
Echo Response: 312 GGSN Req Timeout: 24182


Update PDP Context Denied:
No Resources: 500 No Memory: 0
System Failure: 0 Non-existent: 55460

GGSN теперь разъединяет сеанс контекста PDP и никогда не уведомляет SGSN или Пользовательское оборудование (UE). SGSN или UE могли бы вызвать обновление запрос контекста PDP, и GGSN мог бы отклонить его с Кодом причины 192 (не существующий).

Вот раздел, который взят от TS 29.060:

  • Если Gprs поддержка узла (GSN) получает Gprs Туннелирующая плоскость Контроля протокола (GTP-C) сообщение, запрашивающее действие, отнесенное к контексту PDP, которому верит узел передачи, является существующим, но это не распознано узлом получения, узел получения должен передать обратно источнику сообщения, ответа с соответствующей оценкой причины (или "Несуществующий" или "Контекст, не найденный"). Идентификатор Оконечной точки туннеля, используемый в ответном сообщении, должен быть установлен во все, обнуляет.
  • Если SGSN получит Обновление Ответ Контекста PDP с "Не существующей" Оценкой причины, то это должно удалить Контекст PDP.

Код причины 192 ошибки

Код причины 192 (или не существующий) является ошибкой, которая передается GSNs на интерфейсе Gn. Это заполнено в Причине информационного элемента сообщений GTP.

Это сообщения GTP, которые могут иметь Код причины 192 ошибки:

  • Update_PDP_Context_Response

  • Delete_PDP_Context_Response

Примечание: Туннельный Идентификатор Конца (TEID), который используется в сообщении, которое содержит эту ошибку, будет нолем. Обратитесь к TS 29.060 для получения дальнейшей информации.

Эта ошибка может появиться в вышеупомянутых сообщениях, когда она передается GSN, и она не имеет контекста, который соответствует тому, который передается другим GSN. Когда эта ошибка получена, GSNs удаляют контекст PDP.

Примеры сценариев

В этом разделе описываются четыре сценария, в которых Код причины могут произойти 192 ошибки.

  • Сценарий 1 – ошибка пути GTP-C происходит между GSNs.

  • Сценарий 2 – запрос эха / сбой ответа происходит между GSNs.

  • Сценарий 3 – существует Версия 1 (GTPv1) GTP к Версии 0 (GTPv0) GTP handoff проблема, которая вызывает ошибку. Вот типовой поток вызовов для этого сценария:

    1. Создавание запроса контекста PDP с GTPv1 установлено.

    2. GTPv1-to-GTPv0 handoff происходит.

    3. Запрос к GGSN теперь в GTPv0.

    4. GGSN получает обновление запрос контекста PDP с ненулевым заголовком TEID и отклоняет его из-за (не существующей) ошибки.

      Примечание: SGSN должен был забыть TEID как вызов, перемещенный в GTPv0 (только метки потока существуют для GTPv0, не TEIDs). Это указывает, что SGSN держался за вызов GTPv1 даже после handoff к GTPv0.

  • Сценарий 4 – эффект TEID из синхронизования умножен. Например:

    1. UE1 устанавливает контекст PDP; SGSN выделяет Control-TEID-1 (C-TEID-1) как свой контроль TEID к GGSN на sgsn-UE1-ctxt контексте. C-TEID для всех сообщений на GGSN, которые направляются к SGSN, имеет C-TEID-1.

    2. Сообщение о передаче сигнала (неэхо) таймауты на SGSN и SGSN очищает это sgsn-UE1-ctxt контекст локально. Это также сообщает Контроллеру радиосети (RNC) для очистки. Это не сообщает GGSN, поскольку это обрабатывает GGSN как вниз. Теперь нет никакого контекста PDP для UE1 на SGSN, и контекст PDP для того же UE1 существует на GGSN с C-TEID-1. C-TEID-1 возвращается к хвосту списка свободной памяти.

    3. UE2 тогда хочет установить контекст PDP к тому же APN и проходит через тот же SGSN и GGSN. На SGSN выделен TEID, и sgsn-UE2-ctxt контекст передается GGSN. Если количество свободного TEIDs низко, то недавно освобожденный TEID перераспределен к новому контексту PDP. В этом случае C-TEID-1 перераспределен к UE2.

    4. На GGSN существует два контекста с C-TEID-1 как C-TEID Gn. GGSN не проверяет, существует ли TEID, уже представляют для того же. GGSN тогда инициирует Удалить контекст PDP (DPC) для UE1 к SGSN.

    5. На SGSN C-TEID-1 найден, вместе с контекстом для него, который является sgsn-UE2-Ctxt. Попытка предпринята, чтобы удалить тот контекст и ответить на GGSN.

    6. Если там инициируются в GGSN запросы (обновите/удалите PDP) для других контекстов SGSN отвечает Контекстом, не найденным причиной.

    7. Отбрасывания GGSN, что ответ DPC для UE2, потому что это никогда не отправляло запрос DPC для UE2.

    8. Существует теперь второй контекст на GGSN, который не соответствует никакому контексту на SGSN.

    9. Если тот же C-TEID-1 назначен на другой UE, проблема повторяет и соединяет проблему.

Вот раздел, который взят от TS 29.060:

Ответ эха

Сообщение должно передаваться как ответ на полученный Запрос эха.

GSN, который получает Ответ Эха от однорангового GSN, должен сравнить Значение счетчика Перезапуска, полученное с предыдущим Значением счетчика Перезапуска, сохраненным для того однорангового GSN. Если никакое предыдущее значение не было сохранено, Значение счетчика Перезапуска, полученное в Ответе Эха, должно быть сохранено для однорангового GSN.

Значение Счетчика Перезапуска, ранее сохраненного для однорангового GSN, может отличаться от Значения счетчика Перезапуска, полученного в Ответе Эха от того однорангового GSN. В этом случае GSN, который передал Ответ Эха, нужно рассмотреть, как перезапущено GSN, который получил Ответ Эха. Новое полученное Значение счетчика Перезапуска должно быть сохранено объектом получения, заменяя значение, ранее сохраненное для передачи GSN.

Если передача, GSN является GGSN и получением GSN, будет SGSN, то SGSN должен рассмотреть все контексты PDP с помощью GGSN в качестве неактивного. Поскольку дальнейшие действия SGSN ссылаются на Технические спецификации (TS) Проекта партнерства третьего поколения (3GPP) 23.007 [3].

Если передача, GSN является SGSN и получением GSN, будет GGSN, то GGSN должен рассмотреть все контексты PDP с помощью SGSN в качестве неактивного. Поскольку дальнейшие действия GGSN обращаются к 3GPP TS 23.007 [3].

Вот раздел, который взят от 3GPP TS 23.007 V8.0:

Восстановление данных в SGSN

Перезапуск SGSN

После перезапуска SGSN SGSN удаляет весь Менеджмент мобильности (MM), PDP, Мультимедийные широковещательные сервисы групповой адресации (MBMS) UE и контексты Несущей MBMS, на которые влияет перезапуск. Хранилище SGSN данных энергозависимо за исключением указанного в этом подпункте. SGSN поддерживает во временной памяти счетчик Перезапуска GGSN для каждого GGSN, с которым SGSN находится в контакте, и в долговременной памяти счетчики Перезапуска SGSN, которые касаются каждого GGSN, с которым SGSN находится в контакте. Счетчики Перезапуска SGSN должны быть инкрементно увеличены, и все счетчики Перезапуска GGSN сразу очищены после того, как SGSN перезапустил. Счетчик перезапуска может быть характерен для всего GGSNs или может быть отдельный счетчик для каждого GGSN.

GGSN выполняет функцию опроса (запрос эха и ответ эха) к SGSNs, с которым GGSN находится в контакте. Счетчик Перезапуска SGSN должен быть включен в ответ эха. Если значение, полученное в GGSN, будет отличаться от того, сохраненного для этого SGSN, то GGSN будет полагать, что SGSN перезапустил (см. 3GPP  TS 29.060). Счетчики Перезапуска GGSN должны быть обновлены в SGSN к значению, полученному в первом сообщении для ответа на эхо-запрос, прибывающем из каждого GGSN после того, как SGSN перезапустит.

Когда GGSN обнаруживает перезапуск в SGSN, с которым он имеет активированный контекст (ы) PDP, он должен удалить все они контекст (ы) PDP. Кроме того, новое значение счетчика Перезапуска SGSN, полученного в ответе эха от перезапущенного SGSN, должно быть обновлено в GGSN.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 119246