RU2423013C2 - СПОСОБ И УСТРОЙСТВО ДЛЯ БЫСТРОЙ УСТАНОВКИ ПОЛЬЗОВАТЕЛЬСКОГО СОЕДИНЕНИЯ ПРОТОКОЛА IP ЧЕРЕЗ 3GPP Nb-ИНТЕРФЕЙС С ПРИМЕНЕНИЕМ "ЗАДЕРЖАННОГО УСТАНОВЛЕНИЯ ОБРАТНОГО КАНАЛА-НОСИТЕЛЯ" ПРОТОКОЛА ВIСС И ПРЕДОТВРАЩЕНИЯ ОТКАЗА - Google Patents

СПОСОБ И УСТРОЙСТВО ДЛЯ БЫСТРОЙ УСТАНОВКИ ПОЛЬЗОВАТЕЛЬСКОГО СОЕДИНЕНИЯ ПРОТОКОЛА IP ЧЕРЕЗ 3GPP Nb-ИНТЕРФЕЙС С ПРИМЕНЕНИЕМ "ЗАДЕРЖАННОГО УСТАНОВЛЕНИЯ ОБРАТНОГО КАНАЛА-НОСИТЕЛЯ" ПРОТОКОЛА ВIСС И ПРЕДОТВРАЩЕНИЯ ОТКАЗА Download PDF

Info

Publication number
RU2423013C2
RU2423013C2 RU2008110172/09A RU2008110172A RU2423013C2 RU 2423013 C2 RU2423013 C2 RU 2423013C2 RU 2008110172/09 A RU2008110172/09 A RU 2008110172/09A RU 2008110172 A RU2008110172 A RU 2008110172A RU 2423013 C2 RU2423013 C2 RU 2423013C2
Authority
RU
Russia
Prior art keywords
mgw
user data
packet
connection
data transport
Prior art date
Application number
RU2008110172/09A
Other languages
English (en)
Other versions
RU2008110172A (ru
Inventor
Андрей ГЕРБИНГ (DE)
Андрей ГЕРБИНГ
Томас БЕЛЛИНГ (DE)
Томас Беллинг
Норберт ЗАЙТТЕР (DE)
Норберт ЗАЙТТЕР
Ральф КОХАНОВСКИЙ (DE)
Ральф КОХАНОВСКИЙ
Марчело Нелсон ВАДЕК (BR)
Марчело Нелсон ВАДЕК
Original Assignee
Сименс Акциенгезелльшафт
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Сименс Акциенгезелльшафт filed Critical Сименс Акциенгезелльшафт
Publication of RU2008110172A publication Critical patent/RU2008110172A/ru
Application granted granted Critical
Publication of RU2423013C2 publication Critical patent/RU2423013C2/ru

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1245—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks where a network other than PSTN/ISDN interconnects two PSTN/ISDN networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Изобретение относится к сетям мобильной связи. Технический результат заключается в предотвращении задержки установления вызова. Сущность изобретения заключается в том, что осуществляют установление IP соединения транспортировки пользовательских данных между медиа шлюзом О и медиа шлюзом Т, причем соединение транспортировки пользовательских данных устанавливается в соответствии с «Задержанным установлением обратного канала-носителя» протокола BICC. После приема IPBCP сообщения запроса от MGW Т MGW О посылает IPBCP сообщение Accepted к MGW Т и запускает передачу данных в соединении транспортировки пользовательских данных к MGW Т. Вероятно, что пользовательские данные приходят в MGW Т перед IPBCP сообщением Accepted. MGW Т извлекает IP-адрес и номер порта источника из принятого IP-пакета соединения транспортировки пользовательских данных от MGW О, и MGW Т передает, после приема IP-пакета соединения транспортировки пользовательских данных, первый(ые) IР-пакет(ы) соединения транспортировки пользовательских данных к MGW О с использованием извлеченного IP-адреса и номера порта в качестве получателя. 2 н. и 9 з.п. ф-лы, 1 ил.

Description

В “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 Т в качестве адреса и номера порта источника. Здесь конкретным преимуществом предложенной методологии является ускорение установления соединения транспортировки пользовательских данных.

Claims (11)

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-соединение транспортировки пользовательских данных способом по любому из предыдущих пунктов.
RU2008110172/09A 2005-08-18 2006-08-09 СПОСОБ И УСТРОЙСТВО ДЛЯ БЫСТРОЙ УСТАНОВКИ ПОЛЬЗОВАТЕЛЬСКОГО СОЕДИНЕНИЯ ПРОТОКОЛА IP ЧЕРЕЗ 3GPP Nb-ИНТЕРФЕЙС С ПРИМЕНЕНИЕМ "ЗАДЕРЖАННОГО УСТАНОВЛЕНИЯ ОБРАТНОГО КАНАЛА-НОСИТЕЛЯ" ПРОТОКОЛА ВIСС И ПРЕДОТВРАЩЕНИЯ ОТКАЗА RU2423013C2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP05017998.5 2005-08-18
EP05017998.5A EP1755304B1 (en) 2005-08-18 2005-08-18 Method and apparatus for a fast installation of an IP user connection over a 3GPP Nb interface under application of the BICC "Delayed Backward Bearer Establishment" and avoidance of failure

Publications (2)

Publication Number Publication Date
RU2008110172A RU2008110172A (ru) 2009-09-27
RU2423013C2 true RU2423013C2 (ru) 2011-06-27

Family

ID=35310898

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2008110172/09A RU2423013C2 (ru) 2005-08-18 2006-08-09 СПОСОБ И УСТРОЙСТВО ДЛЯ БЫСТРОЙ УСТАНОВКИ ПОЛЬЗОВАТЕЛЬСКОГО СОЕДИНЕНИЯ ПРОТОКОЛА IP ЧЕРЕЗ 3GPP Nb-ИНТЕРФЕЙС С ПРИМЕНЕНИЕМ "ЗАДЕРЖАННОГО УСТАНОВЛЕНИЯ ОБРАТНОГО КАНАЛА-НОСИТЕЛЯ" ПРОТОКОЛА ВIСС И ПРЕДОТВРАЩЕНИЯ ОТКАЗА

Country Status (8)

Country Link
US (1) US8265088B2 (ru)
EP (1) EP1755304B1 (ru)
CN (1) CN101243674B (ru)
ES (1) ES2537308T3 (ru)
MX (1) MX2008002304A (ru)
PL (1) PL1755304T3 (ru)
RU (1) RU2423013C2 (ru)
WO (1) WO2007020216A1 (ru)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101415249B (zh) * 2007-10-16 2011-02-16 华为技术有限公司 会话初始化协议数据业务信令协商的方法、系统及装置
CA2722014A1 (en) * 2008-04-25 2009-10-29 Nokia Siemens Networks Oy Network entity selection

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6230005B1 (en) * 1998-10-01 2001-05-08 Nokia Telecommunications, Oy Method and apparatus for providing overlay to support third generation cellular services
US6826176B1 (en) * 2000-05-17 2004-11-30 Telefonaktiebolaget Lm Ericsson (Publ) Connectionless media transmission without bearer-channel control signaling
US6765912B1 (en) * 2000-08-08 2004-07-20 Nortel Networks Limited Network resource usage in call sessions
CN1214553C (zh) 2000-11-17 2005-08-10 三星电子株式会社 在窄带时分双工码分多址移动通信系统中测量传播延迟的设备和方法
RU2232466C2 (ru) 2000-11-17 2004-07-10 Самсунг Электроникс Ко., Лтд. Устройство и способ для измерения задержки на распространение в системе мобильной связи уп-двр мдкр
US6819678B2 (en) * 2000-12-21 2004-11-16 Nortel Networks Limited Interworking of dissimilar packet networks for telephony communications
US6937605B2 (en) 2002-05-21 2005-08-30 Nokia Corporation Wireless gateway, and associated method, for a packet radio communication system
EP1642436B1 (en) * 2003-05-16 2014-03-19 Unwired Planet, LLC Call admission control in voip systems
CN100388710C (zh) * 2003-11-14 2008-05-14 中兴通讯股份有限公司 承载控制分离网络与公用交换网络双音多频信令互通方法

Also Published As

Publication number Publication date
CN101243674A (zh) 2008-08-13
EP1755304A1 (en) 2007-02-21
CN101243674B (zh) 2011-11-23
EP1755304B1 (en) 2015-04-01
US8265088B2 (en) 2012-09-11
ES2537308T3 (es) 2015-06-05
WO2007020216A1 (en) 2007-02-22
PL1755304T3 (pl) 2015-08-31
RU2008110172A (ru) 2009-09-27
US20090279555A1 (en) 2009-11-12
MX2008002304A (es) 2008-03-14

Similar Documents

Publication Publication Date Title
KR100886548B1 (ko) 인터넷 프로토콜 멀티미디어 서브시스템 네트워크에서단말의 성능 정보를 전달하기 위한 방법 및 시스템
US7613147B2 (en) Packet-based conversational service for a multimedia session in a mobile communications system
US7870269B2 (en) Method and system for activating a packet data subscriber context for packet data
US20050066038A1 (en) Session control system, communication terminal and servers
US7697471B2 (en) Address translation in a communication system
WO2007128217A1 (en) Method of internet protocol(ip) message transmission, negotiated bandwidth saving capability and saving network bandwidth
US7724711B2 (en) Method of speeding up the registration procedure in a cellular network
US20100134590A1 (en) Codec negotiation
DK1982505T3 (en) Method of maintaining connection in telecommunication system and telecommunication system
EP1380182B1 (en) One-to-one communication in a system having different control plane and user plane logical entities
US20040255039A1 (en) Method, system and network element device for controlling sessions between terminals
KR20060086200A (ko) 이동 통신 단말기 호 셋업 방법
US9374264B2 (en) System and method for transmitting and receiving session initiation protocol messages
US8031697B2 (en) Method for bearer independent call control (BICC) optimization for IP bearer support
RU2423013C2 (ru) СПОСОБ И УСТРОЙСТВО ДЛЯ БЫСТРОЙ УСТАНОВКИ ПОЛЬЗОВАТЕЛЬСКОГО СОЕДИНЕНИЯ ПРОТОКОЛА IP ЧЕРЕЗ 3GPP Nb-ИНТЕРФЕЙС С ПРИМЕНЕНИЕМ "ЗАДЕРЖАННОГО УСТАНОВЛЕНИЯ ОБРАТНОГО КАНАЛА-НОСИТЕЛЯ" ПРОТОКОЛА ВIСС И ПРЕДОТВРАЩЕНИЯ ОТКАЗА
US8923796B2 (en) Expedited call setup
WO2009115126A1 (en) Different ip interfaces in a communication network system
US20100054177A1 (en) Method and system of using ip multimedia system for call setup in mobile satellite systems
KR100957432B1 (ko) 미디어 전송 방법
KR100652768B1 (ko) Ｉｍｓ 네트워크에서의 단말 사이의 ｉｐ 연결 종료 방법

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20160810