Способ и устройство для быстрой установки пользовательского соединения протокола ip через 3gpp nb-интерфейс с применением "задержанного установления обратного канала-носителя" протокола вiсс и предотвращения отказа
Изобретение относится к сетям мобильной связи. Технический результат заключается в предотвращении задержки установления вызова. Сущность изобретения заключается в том, что осуществляют установление IP соединения транспортировки пользовательских данных между медиа шлюзом О и медиа шлюзом Т, причем соединение транспортировки пользовательских данных устанавливается в соответствии с «Задержанным установлением обратного канала-носителя» протокола BICC. После приема IPBCP сообщения запроса от MGW Т MGW О посылает IPBCP сообщение Accepted к MGW Т и запускает передачу данных в соединении транспортировки пользовательских данных к MGW Т. Вероятно, что пользовательские данные приходят в MGW Т перед IPBCP сообщением Accepted. MGW Т извлекает IP-адрес и номер порта источника из принятого IP-пакета соединения транспортировки пользовательских данных от MGW О, и MGW Т передает, после приема IP-пакета соединения транспортировки пользовательских данных, первый(ые) IР-пакет(ы) соединения транспортировки пользовательских данных к MGW О с использованием извлеченного IP-адреса и номера порта в качестве получателя. 2 н. и 9 з.п. ф-лы, 1 ил.
В “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 Т в качестве адреса и номера порта источника. Здесь конкретным преимуществом предложенной методологии является ускорение установления соединения транспортировки пользовательских данных.
1. Способ для установления IP транспортного пользовательского соединения, которое использует «Задержанное установление обратного канала-носителя» протокола BICC, между сетевым объектом MGW О и сетевым объектом MGW Т в IP-сети, причем MGW О передает IPBCP сообщение Accepted к MGW Т, а также запускает передачу пакета(ов) по соединению транспортировки пользовательских данных к MGW Т, причем способ содержит этапы
извлечения посредством MGW Т IP-адреса и номера порта источника из принятого IP-пакета соединения транспортировки пользовательских данных от MGW О,
передачи посредством MGW Т, после приема IP-пакета соединения транспортировки пользовательских данных от MGW О, первого(ых) IP-пакета(ов) соединения транспортировки пользовательских данных к MGW О, с использованием извлеченных IP-адреса и номера порта в качестве получателя.
2. Способ по п.1, дополнительно характеризующийся передачей посредством MGW Т первого IP-пакета соединения транспортировки пользовательских данных к MGW О непосредственно после приема первого IP-пакета соединения транспортировки пользовательских данных от MGW О.
3. Способ по п.1, дополнительно характеризующийся транспортировкой пользовательских данных согласно транспортному протоколу реального времени (RTP), IETF RFC 2833 или RFC 1889.
4. Способ по п.3, дополнительно содержащий этап извлечения посредством MGW Т номера типа полезной нагрузки RTP из RTP-заголовка принятого IP-пакета соединения транспортировки пользовательских данных от MGWO.
5. Способ по п.4, дополнительно содержащий этап использования посредством MGW Т извлеченного номера типа полезной нагрузки RTP из RTP-заголовка принятого IP-пакета соединения транспортировки пользовательских данных от MGW О в качестве номера типа полезной нагрузки RTP в пакетах соединения транспортировки пользовательских данных, посланных к MGW О.
6. Способ по п.1, дополнительно характеризующийся транспортировкой пользовательских данных по протоколу Nb кадрирования, 3GPP TS 29.415.
7. Способ по п.6, дополнительно характеризующийся использованием посредством MGW Т сообщения "Nb Init" в качестве IP-пакета соединения транспортировки пользовательских данных от MGW О, чтобы извлечь из него данные.
8. Способ по п.7, дополнительно характеризующийся использованием посредством MGW Т сообщения "Nb Init Ack" в качестве первого IP-пакета соединения транспортировки пользовательских данных, посланного к MGW О.
9. Способ по п.1, дополнительно содержащий этап передачи посредством MGW Т указания (118) уведомления «канал-носитель установлен» после приема процедуры (113) "Tunnel Info Down".
10. Способ по любому из предыдущих пунктов, дополнительно характеризующийся использованием посредством MGW Т Nb-интерфейса Cs домена сети мобильной связи 3GPP для передачи соединения транспортировки пользовательских данных.
11. Сетевой объект MGW Т, который устанавливает IP-соединение транспортировки пользовательских данных способом по любому из предыдущих пунктов.
