СПОСОБ И УСТРОЙСТВО ДЛЯ БЫСТРОЙ УСТАНОВКИ ПОЛЬЗОВАТЕЛЬСКОГО СОЕДИНЕНИЯ ПРОТОКОЛА IP ЧЕРЕЗ 3GPP Nb-ИНТЕРФЕЙС С ПРИМЕНЕНИЕМ "ЗАДЕРЖАННОГО УСТАНОВЛЕНИЯ ОБРАТНОГО КАНАЛА-НОСИТЕЛЯ" ПРОТОКОЛА ВIСС И ПРЕДОТВРАЩЕНИЯ ОТКАЗА
METHOD AND DEVICE TO QUICKLY ESTABLISH USER CONNECTION OF IP PROTOCOL VIA 3GPP Nb-INTERFACE WITH APPLICATION OF "DELAYED ESTABLISHMENT OF BACKWARD CARRIER CHANNEL" OF BICC PROTOCOL AND TO PREVENT FAILURE

В “Cs домене” сети мобильной связи 3GPP «Протокол Nb кадрирования», стандартизованный в документе 3GPP TS 29.415, используется для транспортировки пользовательских данных. Протокол Nb кадрирования также характеризует сообщения внутриполосной сигнализации, например сообщение инициализации и сообщение квитирования инициализации, которыми необходимо обмениваться перед любыми пользовательскими данными. Для так называемой сигнализации управления вызовом используется стандартизованный ITU-T протокол «Независимого от канала-носителя управления вызовом» (BICC), ITU-T Q.1902.5, как описано в документе 3GPP TS 23.205.
В случае использования IP-протокола для транспортировки пользовательских данных по Nb-интерфейсу в базовой сети Cs домена, IP-адреса и номера UDP-портов, используемые для передачи и приема транспортных соединений в «медиа-шлюзах» (MGW) или интегрированных «центрах коммутации услуг мобильной связи» (MSC), которые соединяют функцию MGW и MSC-сервера в одном устройстве, согласовываются с помощью «Протокола управления каналом-носителем IP» (IPBCP), ITU-T Q.1970, как описано в документе 3GPP TS 29.414.
Протокол BICC предоставляет различные способы для установки IP-транспортных соединений, среди них так называемое «Задержанное установление обратного канала-носителя», которое является задержанным обратно направленным установлением транспортного соединения. В этом случае все еще нерешенными являются следующие проблемы.
Шлюз MGW О передает к следующему шлюзу MGW Т в направлении вызываемой стороны сообщение протокола IРBCP Accepted («принято») с IP-адресом и номером UDP-порта, которое MGW О выбрал для передачи и приема пользовательского соединения. MGW О одновременно или вскоре после этого посылает сообщение инициализации протокола Nb кадрирования к MGW Т. Необходимо, чтобы MGWТ отвечал немедленно на сообщение инициализации протокола Nb кадрирования сообщением ответа инициализации к MGW О, чтобы реализовать быстрое установление пользовательского соединения, чтобы предотвратить ситуацию, когда MGW О воспринимает отсутствие ответного сообщения в течение некоторого периода как случай ошибки. В соответствии с существующим стандартом, MGW Т должен посылать ответное сообщение инициализации на IP-адрес и номер UDP-порта MGW О, указанные в сообщении протокола IРBCP Accepted.
MGW О посылает сообщение инициализации протокола Nb кадрирования непосредственно с помощью IP-протокола к MGW Т. С другой стороны, MGW О посылает сообщение протокола IРBCP Accepted к MSC-серверу О, управляющему им. Затем MSC-сервер О направляет IРBCP-сообщение посредством сигнализации управления вызовом BICC к MSC-серверу Т, управляющему шлюзом MGW Т, который пропускает сообщение на MGW Т. Поэтому в данном сценарии вероятно, что сообщение инициализации MGW Т протокола Nb кадрирования достигает своего получателя явно раньше сообщения протокола IРBCP Accepted.
Проблематичным образом, поведение MGW Т в этой ситуации до сих пор не было определено в стандарте. В результате MGW Т мог бы игнорировать по-прежнему неожидаемое сообщение инициализации протокола Nb кадрирования и/или предполагать ошибочную ситуацию и разрывать установление соединения. MGW Т может также продолжать ожидать сообщение протокола IРBCP Accepted, то есть перед посылкой ответного сообщения инициализации, которое может привести к задержкам инициализации транспортного соединения и ошибкам в MGW О.
Предметом настоящего изобретения является процедура, которая позволяет шлюзу MGW Т в случае сценария «задержанного установления обратного канала-носителя», описанного выше, посылать ответное сообщение инициализации протокола Nb кадрирования к MGW О немедленно, чтобы предотвращать ошибки и/или задержки в процессе установления транспортного соединения.
До сих пор вышеуказанная проблема не была рассмотрена, и отсутствует приемлемое решение вышеописанных проблем.
Сущность изобретения
Типовой сценарий для решения согласно настоящему изобретению является следующим:
- IP в базовой сети (CN), задержанное установление обратного канала-носителя BICC;
- UP инициализация запускается инициированием MGW, как только информация локального адреса и удаленного адреса становится доступной; но в тот же самый момент информация локального адреса посылается к одноранговому MGW => «состязание» при передаче сообщений между UP-инициализацией (“UP-Init”), с одной стороны, и сообщением протокола IРBCP Accepted в рамках Notify.Ind (Tunnel Info Up)->APM->Mod.Req(Tunnel Info Down), с другой стороны;
- Высокая вероятность того, что “UP-Init” поступит раньше и будет отброшен, поскольку удаленный адрес неизвестен на интервале приема MGW;
- После таймаута (500 мс) “UP-Init” будет повторно передан инициирующим MGW, вероятно, успешно.
Решение, предоставленное здесь, заключается в подтверждении “UP-Init” немедленно после приема в MGW путем использования IP-адреса/UDP-порта в поле адреса источника “UP-Init”. Это описывается здесь кратко следующим образом:
- Распознать специальную ситуацию в принимающем MGW: подготовиться принимать “UP-Init” в течение обработки Add.Req;
- Принять “UP-Init”; извлечь удаленный адрес из поля источника IP- и UDP-заголовков “UP-Init”;
- Извлечь номер типа полезной нагрузки RTP из RTP-заголовка “UP-Init”;
- Послать квитирование UP инициализации (“UP Init Ack”) незамедлительно с использованием извлеченного удаленного адреса, порта, номера типа полезной нагрузки RTP;
- Послать Notify.Ind (установление канала-носителя), как только удаленный адрес принят от MSC-S посредством сообщения IРBCP Accepted.
Среди преимуществ предложенного решения то, что предотвращаются потеря сообщения “UP-Init”, таймаут и повторение “UP-Init”. Кроме того, предотвращается задержка установления вызова, обусловленная таймаутом.
Краткое описание чертежей
На чертеже представлен поток сообщений согласно изобретению.
Детальное описание предпочтительных вариантов осуществления
В соответствии с настоящим изобретением MGW Т использует в качестве адреса получателя номер порта для инициализации ответного сообщения протокола Nb кадрирования, адрес и номер порта «источника» (отправителя), указанные в принятом IP-пакете, переносящем сообщение инициализации протокола Nb кадрирования.
Это отличается от установленных стандартов, которые предписывают использование IP-адреса и номера порта, указанных в IРBCP сообщении Accepted, посланном от MGW О к MGW Т. Однако в соответствии с IPBCP, гарантируется, что эти адреса и номера портов идентичны, поскольку IPBCP предписывает, что указанные IP-адрес и номер порта должны использоваться при передаче, а также при приеме IP-пакетов транспортного соединения. Таким образом, IPBCP отклоняется от понимания IETF, заключающегося в том, что IP-адреса и номера портов, передаваемые в рамках «Протокола описания сессии» (SDP, IETF RFC 2327), ссылаются только на получателя, но не на источник медиа потока, даже если IPBCP использует протокол SDP.
На чертеже показан поток 100 информации для установления IP- транспортного пользовательского соединения посредством «задержанного установления обратного канала-носителя» протокола BICC, согласно предложенному решению, между медиа шлюзом MGW О 102 и управляющим MSC-сервером MSC-S O 104, а также между медиа шлюзом MGW Т 106 и управляющим MSC-сервером MSC-S T 108.
Здесь MGW О 102 показан размещенным перед MGW Т 106 в транспортном соединении, как наблюдается от вызывающей стороны. Протокол IPBCP транспортируется между MGW и сервером посредством сообщений “Tunnel Info UP” (109, 110) “Tunnel Info Down” (112, 113) и между MSC-серверами посредством сообщений “APM” сигнализации BICC (111, 115).
В соответствии с «задержанным установлением обратного канала-носителя», MGW Т 106 сначала посылает сообщение запроса IPBCP (109, 111, 112) на MGW О 102 и указывает в нем IP-адрес и номер UDP-порта, которые MGW Т должен использовать для передачи и приема IP-пакетов нового IP-транспортного соединения.
При приеме этого сообщения запроса IPBCP (109, 111, 112) MGW О 102 посылает IРBCP сообщение Accepted (110, 115, 113) и в то же самое время или вскоре после этого сообщение инициализации “UP-Init” 114 протокола Nb кадрирования к MGW Т 106. Поскольку “UP-Init” посылается непосредственно посредством протокола IP к MGW Т 106, в то время как IРBCP сообщение проходит через MSC-S Т 108 и MSC-S О 104, вероятно, что сообщение “UP-Init” достигнет MGW Т первым.
В соответствии с предложенным способом MGW Т посылает первый пакет в рамках пользовательского соединения данных к MGW О, т.е. сообщение ответа инициализации “UP Init Ack” 116 протокола Nb кадрирования непосредственно после приема первого пакета в рамках пользовательского соединения данных от MGW О, т.е. сообщения “UP-Init” 114, и использует в качестве IP-адреса получателя и номера порта адрес и номер порта, указанные в IP-заголовке сообщения “UP-Init” 114, в качестве адреса и номера порта источника.
В качестве номера типа полезной нагрузки RTP в сообщении “UP Init Ack” 116 MGW Т 106 использует тип полезной нагрузки RTP, использованный в заголовке RTP принятого сообщения “UP-Init” 114.
MGW Т 106, в соответствии с предложенным способом, посылает сообщение ответа инициализации незамедлительно после или вскоре после приема сообщения инициализации, а не как ранее, согласно стандарту, сразу после приема IРBCP сообщения Accepted.
В продолжение, протокол Nb кадрирования транспортируется в полезной нагрузке «транспортного протокола реального времени» (RTP), IETF RFC 2833. Заголовок RTP каждого пакета содержит так называемый тип полезной нагрузки RTP для индикации типа полезной нагрузки. Для протокола Nb кадрирования в качестве полезной нагрузки в рамках RTP используется так называемый номер типа динамической полезной нагрузки RTP, т.е. номер, который присваивается типу полезной нагрузки путем согласования перед установлением транспортного соединения RTP. Для этого согласования применяется протокол IPBCP.
Соответственно, MGW Т 106 использует тот же самый номер типа полезной нагрузки RTP для сообщения ответа инициализации протокола Nb кадрирования, который был использован в заголовке RTP пакетной транспортировки сообщения инициализации протокола Nb кадрирования. В соответствии с существующим стандартом, MGW Т 106 должен был бы использовать номер типа полезной нагрузки RTP, принятый в IРBCP сообщении. Однако поскольку MGW О 102 использует номер типа полезной нагрузки RTP, который указан в IРBCP сообщении к MGW Т 106 для сообщения инициализации Iu FP, и поскольку MGW Т 106 должен указывать тот же самый номер типа полезной нагрузки RTP в ответном IРBCP сообщении к MGW О 102, которое он принимает в IРBCP сообщении от MGW О 102 в соответствии с IРBCP, то гарантируется, что измененное поведение MGW Т 106 не вызывает ошибок в MGW О 102.
В соответствии с существующим стандартом, MGW Т 106 должен уведомлять MSC-S Т 108 с использованием процедуры 118 установления канала-носителя, как только соединение транспортировки пользовательских данных установлено посредством инициализации протокола Nb кадрирования. Однако MSC-S Т 108 будет ожидать это уведомление только после передачи процедуры 113 Tunnel Info Down. Поэтому предпочтительно, если MGW Т 106 передает процедуру 118 установления канала-носителя только после приема процедуры 113 Tunnel Info Down.
Должно быть понятно, что с помощью методологии, предложенной здесь, предотвращаются ошибки и задержки в случае задержанного установления обратного канала-носителя протокола IРBCP в течение установки транспортных соединений IP-протокола через Cs домен сети мобильной связи 3GPP.
Методология, предложенная здесь, также применима, если другие протоколы кадрирования используются для транспортировки пользовательских данных вместо протокола Nb кадрирования, например, если пользовательские данные непосредственно транспортируются согласно транспортным протоколам реального времени (RTP), IETF RFC 2833. Существенно, что MGW Т посылает первый пакет по соединению транспортировки пользовательских данных к MGW О после приема первого пакета по соединению транспортировки пользовательских данных от MGW О, и что MGW Т использует в качестве IP-адреса и номера порта получателя посланного пакета адрес и номер порта, указанные в IP-заголовке принятого пакета от MGW Т в качестве адреса и номера порта источника. Здесь конкретным преимуществом предложенной методологии является ускорение установления соединения транспортировки пользовательских данных.