Способ и устройство для передачи ip-пакетов между сетевым радиоконтроллером (rnc) и другим устройством сети мобильной радиосвязи
Изобретение относится к области мобильной радиосвязи. Достигаемый технический результат - уменьшение сигнализационной нагрузки за счет централизованной обработки смены режима кодека. Способ для передачи IP-пакетов между сетевым радиоконтроллером (RNC) (2) и последующим устройством сети мобильной радиосвязи, характеризуется тем, что подлежащий передаче IP-пакет содержит первый указатель режима кодека, который показывает, с каким режимом кодека проводилась передача от мобильного терминала (МТ) (1) к первому сетевому радиоконтроллеру (RNC) (2), проходимое IP-пакетом на пути через сеть мобильной радиосвязи устройство замены указателя режима кодека (DCF) (5) производит замену содержащегося в пакете данных первого указателя режима кодека на второй указатель режима кодека, известный упомянутому последующему устройству или мобильному терминалу (МТ) (1), соответствующий согласно запомненной таблице в устройстве замены указателя режима кодека первому указателю режима кодека, IP-пакет, который содержит второй указатель режима кодека, пересылают дальше к упомянутому последующему устройству. 2 н. и 18 з.п. ф-лы, 10 ил.
Изобретение относится к способу и устройству в сети мобильной радиосвязи, которым при подлежащих передаче IP-пакетах между абонентами сети мобильной радиосвязи централизованно производят смену режима кодека.
Задачей настоящего изобретения является оптимирование способа и устройства названного выше вида таким образом, чтобы достигалось уменьшение сигнализационной нагрузки за счет централизованной обработки смены режима кодека.
Эта задача решается согласно изобретению предметами независимых пунктов формулы изобретения относительно способа и устройства. Формы дальнейшего развития изобретения приведены в зависимых пунктах формулы изобретения. Соответствующая изобретению передача IP-пакетов между Radio Network Controller (RNC) сетевым радиоконтроллером, называемым также контроллером базовых станций, и другим устройством сети мобильной радиосвязи имеет преимущество, что сетевой радиоконтроллер не должен знать режим(ы) кодека(ов), которые имеются в настоящее время и которые будут в будущем. Таким образом отпадает обновление программного обеспечения в сетевых радиоконтроллерах (RNC). Сетевой радиоконтроллер (RNC) (2) должен открывать IP-пакет (user level IP Paket, IP-пакет уровня пользователя), который рассматривается полностью как данные. Тем самым (RNC) (2) не должен знать, как структурированы данные. Точно так же (RNC) (2) не должен знать, какой заголовок протокола передачи: RTP header, IP Protokoll header, UDP Protokoll header и RTP payload header применяется.
Изобретение поясняется более подробно на основе представленного на чертежах примера выполнения. В частности, показано:
Фигура 1 - архитектура сети связи с устройством (DCF) для поддержки смены режима кодека согласно изобретению.
Фигура 2 - обмен данными, касающимися кодека и режима, при вызове.
Фигура 3 - введение сетевого доступа.
Фигура 4 - введение базовой сети.
Фигура 5 - структура OCS-кадра (OCSF, кадр оптимированной поддержки кодека).
Фигура 6 -информация примененных частичных потоков RAB.
Фигура 7 - обработка IP-пакета при вызове (звонке) между мобильными терминалами.
Фигура 8 - обработка IP-пакета при вызове между неподвижной станцией и мобильным терминалом.
Фигура 9 - пакет данных к отдельным станциям для вызова между двумя мобильными терминалами.
Фигура 10 - пакет данных к отдельным станциям для вызова между мобильным терминалом и неподвижной станцией.
IP-пакет преобразуют для транспортировки между двумя сетевыми радиоконтроллерами в Optimized Codec Support Frame (оптимированный кадр поддержки кодека) и для транспортировки между сетевыми радиоконтроллерами и мобильным терминалом разделяют на различные частичные потоки RAB.
Фигура 1 показывает архитектуру сети связи, которая находит применение для способа передачи IP-пакетов между сетевыми радиоконтроллерами (RNC) при вызовах между мобильными терминалами. От первого мобильного терминала (1) IP-пакет (например, кодированный язык AMR) попадает к сетевому радиоконтроллеру (2), который включают там в OCS-кадр и оттуда передают дальше через узел Serving GPRS Support (3) к узлу Gateway GPRS Support (4). Мобильный терминал (1, 11) представляет собой мобильный радиотелефон, мобильную трубку, мобильный компьютер, комбинацию названных приборов или тому подобное. Для этого RNC (2) имеет таблицу, которая составляется динамически при построении соединения, чтобы можно было заменять значение TFCI на корреспондирующее значение RFCI и значение TFCI req. на корреспондирующее значение RFCI req. При этом контроллеру RNC (2) дают информацию присваивания (RANAP: RAB assignment), которая делает его способным на основе актуальной ситуации на воздушном интерфейсе задавать соответствующий режим кодека. Не является необходимым, чтобы RNC (2) знал режим кодека, однако нужно, чтобы он знал его характеристики (например, необходимую ширину полосы). OCS-кадр имеет поля RFCI, RFCI req., факультативные поля и IP-пакет, причем последовательность полей устанавливается в фазе реализации. Транспортировка происходит, например, посредством заголовка GTP-U Header, который создается RNC (2). GGSN (4) выдает OCS-кадр на устройство замены указания режима кодека (DCF) (5), а оно проверяет на основе таблицы (5а) примененное указание режима кодека и заменяет его при необходимости на другое. При этом OCS-кадр может транспортироваться между GGSN (4) и (DCF) (5) как одно целое (один аргумент) или разделенным на различные аргументы (RFCI = аргумент 1, RFCI req. = аргумент 2, IP-пакет = аргумент 3). Устройство замены указания режима кодека (DCF) (5) может быть встроено в сеть связи в виде центрального блока или децентрального блока. При этом DCF (5) может быть собственным узлом, блоком узла GGSN (4) или другого узла. В центральном DCF (5) значение RFCI от передатчика преобразуется в значение RPCI приемника и значение RFCI req. передатчика преобразуется в значение RFCI req. приемника. Другой задачей DCF (5) является сравнение запрошенного режима кодека (представленного значением AMR req.) со значением RFCI req. Если они различны, то DCF (5) заменяет значение AMR req. соответственно значения RFCI req. При одном DCF (5) на GGSN (4) DCF (5) получает значение RFCI, значение RFCI req. и IP-пакет от GGSN (4). После этого DCF (5) сравнивает режим кодека AMR req. со значением RFCI req. и заменяет значение AMR req., если значения не подходят друг к другу. Для направления приемника узлом GGSN (4) на основе индикатора (например, анализа TFT) IP-пакет направляют дальше к DCF (5) и там устанавливают режим кодека AMR и режим кодека AMR req. и заменяют соответствующим значением RFCI и значением RFCI req. Различие между центральным и децентральным DCF (5) заключается в том, что в случае децентрального DCF (5) для вызова (звонка) между двумя мобильными терминалами (1, 11) вызов DCF происходит дважды. Замена может предписываться, например, в зависимости от нагрузки контроллером RNC (2) на DCF (5) на основе значения RFCI req. OCS-кадр снова передают к GGSN (4) и направляют дальше к мобильному терминалу приемнику (11) через отдельные узлы SGSN (3) и RNC (2). Расформирование пакета происходит опять-таки в RNC (2). Если приемником является неподвижная станция (15), то IP-пакет направляется к ней от GGSN (4) или от самого DCF (5) через брандмауэр межсетевой защиты (8), сеть Интернет (9) и внешнюю сеть (10).
Фигура 2 показывает, как определяют примененные для вызова режим(ы) кодека(ов) между двумя мобильными терминалами 1 и 11. При этом должно быть обеспечено, что мобильный терминал (1) определил носителя (Bearer) для транспортировки, например, SIP сообщений (messages). SIP сообщения (пакеты идентификации службы) содержат список со всеми возможными согласуемыми режимами кодеков с точки зрения вызывающей стороны. Мобильный терминал (1) посылает SIP сообщение, например, с SDP информацией, которая содержит предложенные режим(ы) кодека(ов). SDP протокол является предпочтительным для транспортировки режимов кодеков, однако могут применяться также другие протоколы, как html или xml. Вызванный мобильный терминал (11) посылает в качестве ответа режим(ы) кодеков, с которыми он хотел бы вести разговор. Call State Control Funktion (CSCF функция контроля режима вызова) (7) IP мультимедийной подсистемы (IMS), которая может быть достигнута через IP-сеть (6), может вмешиваться при установлении примененных режима(ов) кодека(ов) в случае, если должны применяться другие режим(ы) кодека(ов), чем предложенные мобильными терминалами (1, 11). IP-сеть представляет собой так называемый Operator spezific IP Network (специальный оператор IP сети) (3GPP 29061). Оба мобильных терминала теперь готовы для передачи режима(ов) кодека(ов), которые могут преобразовываться на обеих сторонах. В AMR кодированном языке мобильный терминал должен преобразовывать переданные режим(ы) кодека(ов), например, в SDU параметры. Если CSCF (7) или другой участвующий в передаче режима(ов) кодека(ов) во время установления разговора узел уже преобразовал режим(ы) кодека(ов) в SDU параметры, то для улучшения SDP или SIP протокола необходимо, чтобы SDU параметры передавались дальше на мобильные терминалы (1, 11). Последовательность SDU параметров может быть идентичной с подлежащим(и) передаче режимом(ами) кодека(ов) в списке SIP/SDP, который содержит согласованные режим(ы) кодека(ов).
Фигура 3 показывает инициализацию сетевого доступа. При этом SGSN (3) знает режим(ы) кодека(ов), которые должны применяться для вызова. Это происходит, например, через SDU параметры. Процедуры протокола управления сеансом 3GPP Session Management Protokoll "активируй PDP контекст", "модифицируй PDP контекст" или "активируй вторичный PDP контекст" расширяют для передачи SDU параметров (с той же последовательностью, как и соответствующие режим(ы) кодека(ов) передачи режима(ов) кодека(ов)), что выражает режим(ы) кодека(ов) на SGSN (3). При этом достигается то, что SGSN (3) не знает о типе услуги, что означает, что SGSN (3) не должен инициализироваться всеми различными режимом(ами) кодека(ов), которые могли бы быть запрошены для вызова. SGSN (3) таким образом ничего не знает о передаваемой услуге. Запрос RANAP (RAB присвоение), который содержит данные на мобильные терминалы SDU параметры, вызывает SGSN (3) для передачи. Сообщение RRC Protokoll, которое определяет частичные потоки RAB согласно SDU параметрам, вызывается RNC (2). Поля заголовков (Transport Format Combination Identifier) TFCIs и (RAB SubFlow Combination Identifier) RFCIs в пакетах данных запомнены в RNC (2) для вызова согласно полученным SDU параметрам. Последовательность TFCIs и RFCIs корреспондирует с полученными SDU параметрами. TFCIs и RFCIs применяют для идентификации режима(ов) кодека(ов), без того, чтобы RNC (2) знала о режиме(ах) кодека(ов). Тем самым RNC (2) не должна ничего знать о передаваемых услугах. Если установка RAB частичных потоков успешно закончена, то RAB частичными потоками передают сообщение RRC Protokoll, что построение соединения выполнено. Мобильные терминалы (1, 11), RNC (2) и DCF (5) являются инстанциями, которые знают отображение RFCIs в SDU параметры.
Фигура 4 показывает инициализацию режима(ов) кодека(ов) в базовой сети. Для вызовов между неподвижной станцией и мобильным терминалом, а также между двумя мобильными терминалами DCF (5) знает, какие RFCIs стоят для каких SDU параметров. Тем самым готово отображение между RFCIs и их соответствующими режимом(ами) кодека(ов) и превращение IP пакета в OCS-кадр. Альтернативно DCF (5) при вызовах между двумя мобильными терминалами может заменять значения RFCI и запрошенного RFCI, так как RNC (2) может выражать тип SDU параметра, который действует для специального режима кодека с другим RFCI, чем соответствующего RNC (2), который обслуживает соответствующий принимающий мобильный терминал (11). Для упрощения примененные RFCIs должны бы иметь такую же последовательность, как и SDU параметры и SIP/SDU связанные режим(ы) кодека(ов). DCF (5) применяет таблицу, чтобы быть в состоянии конвертировать RFCIs и OCS-кадры в IP-пакеты и наоборот. В таблице содержатся RFCIs и соответствующие SDP параметры, а также идентификаторы туннельной конечной точки (Tunnel Endpoint Identifier) для PDP контекстов для отображения соответствующих RFCIs. После положительного ответа посредством сообщения установления вызова RRC, RNC (2) отвечает сообщением RANAP и добавляет для вызова RFCIs и их значения. SGSN (3) передает через GTP-C-заголовок расширения RFCIs и их значения к GGSN (4). После получения GGSN (4) передает RFCIs и их значения к DCF (5), где имеет место инициализация для разговора. Теперь DCF (5) является подготовленным для запоминания RFCIs и преобразования IP-пакетов в OCS-кадры и наоборот.
Фигура 5 показывает структуру OCS-кадра. Примененный режим кодека определяется значением RFCI в OCS-кадре. Другие табличные поля в пакете данных могут добавляться факультативно. Они, однако, должны быть пригодными для интерпретации приемником. Поле IP Header содержит информации для реконфигурации IP-пакета Header. Некоторые информации OCS-кадра могли бы быть переданы через GTP заголовок расширения, это зависит, однако, от стандартизации или, соответственно, реализации в сети связи.
Фигура 6 показывает табличные информации для разделения на различные RAB частичные потоки.
Фигура 7 показывает, как IP-пакет передается от мобильного терминала (1) через отдельные узлы сети к другому мобильному терминалу (11). Подлежащий передаче IP-пакет разделяется мобильным терминалом (1) на различные частичные потоки RAB (12). При этом значения для TFCI, TFCI req. и возможно другие значения заполняются значениями, которые происходят из IP-пакета. Частичные потоки RAB (12) транспортируют IP-пакет к RNC (2). Сжатие заголовков, например, заголовков IP/UDP/RTP через воздушный интерфейс является факультативным. В RNC (2) значение для TFCI заменяют соответствующим значением для RFCI и значение для TFCI req. соответствующим ему значением для RFCI req. RNC (2) имеет для этого подходящую таблицу или матрицу. В качестве результата разделенные на частичные потоки RAB (12) IP-пакеты преобразуют в OCS-кадры. После этого контроллером RNC создается заголовок GTP-U и ставится перед OCS-кадром (13) и направляется дальше через узел Serving GPRS Support (SGSN) (3) к узлу Gateway GPRS Support (GGSN) (4). GGSN (4) направляет кадр дальше к устройству смены указания режима кодека (DCF) (5). В случае центрального (DCF) (5) оно заменяет значения RFCI и RFCI req. между обоими мобильными терминалами (1, 11). Дополнительно (DCF) (5) сравнивает значение ARM req. в IP-пакете со значением RFCI req. и при известных условиях заменяет его. При одном DCF (5) на один GGSN (4) DCF (5) удаляет значения RFCI и RFCI req. и переписывает значение AMR req. значением RFCI req. Если имеется только один IP-пакет на GGSN (4) и он вставляет заголовок GTP-U (плюс заголовок расширения GTP-U) и посылает пакет в направлении приемника RNC (2) при вызове между двумя мобильными терминалами (1, 11). Перед этим IP-пакет направляется через приемник GGSN (4) к приемнику DCF (5) и для мобильного терминала (11) устанавливаются согласованные значения RFCI и RFCI req. и снова посылаются обратно к GGSN (4). Если приемником является неподвижная станция (15), то IP-пакет направляется сразу дальше от GGSN (4).
GGSN (4), вероятно, может заменять заголовок GTP-U и отсылать OCS-кадр (13) к SGSN (3), который направляет его дальше к RNC (2). RNC (2) заменяет значение RFCI на соответствующее значение TFCI и значение RFCI req. на соответствующее значение TFCI req. и делит пакет на несколько RAB частичных потоков (14), которые направляют дальше IP-пакет через воздушный интерфейс к мобильному терминалу (11).
Фигура 8 показывает преобразование и отсылку IP-пакета при вызовах между мобильным терминалом (1) и неподвижной станцией (15). При вызовах от мобильного терминала (1) к неподвижной станции (15) DCF (5) преобразует IP-пакет в OCS-кадр и наоборот. IP-пакет, который посылается по линии связи абонента с центральным узлом (от мобильного терминала к RNC), разделяется мобильным терминалом (1) на RAB частичные потоки (12) и направляется дальше к RNC (2). Значения для TFCI, TFCI req. и факультативные значения происходят при этом из IP-пакета (значение AMR и AMR req.). IP-пакет данных Header и зашифрованные данные также берутся из IP-пакета. Сжатие заголовков, например, заголовков IP/UDP/RTP через воздушный интерфейс является факультативным. RNC (2) заменяет значение TFCI на соответствующее значение RFCI и TFCI req. на соответствующее значение и RFCI req. Тем самым RAB частичные потоки (12) являются преобразованными в OCS-кадр. После этого RNC (2) ставит перед OCS-кадром заголовок GTP-U Header и направляет дальше через SGSN (3) к GGSN (4). GGSN (4) расформировывает OCS-кадр (13) и узнает, например, через идентификатор туннельной конечной точки (Tunnel Endpoint Identifier) заголовка GTP-U Header, что OCS-кадр с GTP-U (13), который перед этим должен преобразовываться в IP-пакет, должен передаваться к неподвижной станции (15). Для преобразования GGSN (4) направляет дальше OCS-кадр (13) без заголовка GTP-U Header к DCF (5). DCF (5) преобразует кадр и направляет его обратно к GGSN (4). Наконец, от GGSN (4) IP-пакет посылается дальше в направлении неподвижной станции (15). Альтернативно IP пакет мог бы непосредственно, без необходимости обратного направления к GGSN (4), направляться дальше посредством DCF (5) в направлении неподвижной станции (15).
Если GGSN (4) получает обратно IP-пакет от неподвижной станции (15), то он маркируется специальным контекстом PDP, согласно, например, IP-адресу или TFT-фильтру, если активирован более, чем один контекст PDP для мобильного терминала (1). С маркировкой узел GGSN (4) знает, что он должен направлять IP-пакет дальше к DCF (5), чтобы он там преобразовывался в OCS-кадр. Вместе с идентификатором, который опрашивает соответствующие друг другу RFCIs и RFCI req., IP-пакет направляют дальше для преобразования в OCS-кадр к DCF (5) и после этого обратно к GGSN (4). Затем перед OCS-кадром устанавливают следующий заголовок GTP-U Header и посылают к SGSN (3), который направляет этот кадр (13) к RNC (2). После того как заголовок GTP-U Header был удален, RNC (2) заменяет значение RFCI соответствующим ему значением TFCI и значение RFCI req. соответствующим ему значением TFCI req., разделяет IP-пакет RAB на частичные потоки (12) и передает это к мобильному терминалу (1), который объединяет их снова вместе.
Выполнение команды смены режима кодека в мобильном терминале
Запрос для преобразования в цифровую форму данных с другим режимом кодека получают от мобильной сети радиосвязи непосредственно через приложение, которое находится в мобильном терминале, компьютере или тому подобном. Смена режима кодека вызывается RNC (2). Это может происходить в направлении связи абонента с центральным узлом через мобильный терминал (1, 11), который запрашивает посредством значения TFCI req. определенный режим кодека под наблюдением RNC, и в направлении от центрального узла к абоненту от принимающего мобильного терминала (1, 11) требуют через значение RPCI req. применять другой режим кодека. Это значение наблюдается RNC (2) и, при известных обстоятельствах, корректируется прежде, чем он заменяет его на значение TFCI req. Замена может быть вызвана также мобильным терминалом (например, полем заголовка RTP полезная нагрузка (payload) Header ARM req.), под наблюдением RNC (2). Из-за сообщений качества воздушных интерфейсов, которые передаются от принимающего кодированные данные мобильного терминала (11) на обслуживающий RNC (2), или посредством инициатора (триггера), как, например, время дня, RNC (2) может затребовать на передающем мобильном терминале (1) замену режима кодека, которая реализуется модифацией значения RFCI req. OCS-кадра, которое посылается к передающему мобильному терминалу. RCN (2) может влиять на запрос о замене режима кодека через SGSN (3) согласно актуальной ситуации (например, актуально применяемой ширины полосы и времени дня). Мобильный терминал получает запрос на замену режима кодека через значение TFCI req. Приложение в мобильном терминале получает тот же самый запрос на смену режима кодека через значение поля из IP-пакета, как, например, поле заголовка RTN полезная нагрузка (payload) Header AMR req. IF1. После этого преобразованный в цифровую форму IP-пакет направляют дальше с запрошенным режимом кодека, к низкому уровню (Lower Layer). Lower Layer может интерпретировать поле IP-пакета, которое содержит информации о примененном режиме кодека. В качестве результата он проверяет полученные IP пакеты по режиму кодека, который коррелирует со значением TFCI req., и или пропускает IP пакет или отбрасывает его. Мобильный терминал кодирует данные с режимом кодека, который был запрошен от RNC (2). С другой стороны, качество вызова вследствие потерянных пакетов драматически падает.
Выполнение команды смены режима кодека в DCF
DCF получает запрос на замену режима кодека в виде значения RFCI req. Приложение получает тот же запрос в виде соответствующего поля в IP-пакете. Приложение, которое находится на неподвижной станции, кодирует после этого данные с запрошенным режимом кодека, который имеется из соответствующего поля в IP-пакете. После этого IP-пакет с запрошенным режимом кодека через GGSN (4) передают к DCF (5).
В качестве результата DCF (5) контролирует в этом полученном IP-пакете режим кодека, коррелирует ли он со значением RFCI req. и пропускает пакет или отбрасывает его. Передача IP-пакетов через воздушный интерфейс может происходить с перекодированием или без перекодирования.
Фигура 9 показывает вид пакета данных на отдельных станциях при вызове между двумя мобильными терминалами. Последовательность полей устанавливают на основе реализации и стандартизации. Информацию (значение RFCI/TFCI и значение AMR, значение RFCI req./TFCI req. и значение AMR req.) о режиме кодека передают в настоящем примере дважды. Для устранения этого между мобильным терминалом (1, 11) и DCF модифицируют заголовок RTP полезная нагрузка (payload.) Header (содержит значение AMR и значение AMR req.), это означает, что изменяют протокол IEFT.
Фигура 10 показывает вид пакета данных на отдельных станциях при вызове между мобильным терминалом и неподвижной станцией. Последовательность полей устанавливается на основе реализации и стандартизации.
1. Способ для передачи IP-пакетов между сетевым радиоконтроллером (RNC) (2) и последующим устройством сети мобильной радиосвязи, отличающийся тем, что подлежащий передаче IP-пакет содержит первый указатель режима кодека, который показывает с каким режимом кодека проводилась передача от мобильного терминала (МТ) (1) к первому сетевому радиоконтроллеру (RNC) (2), что проходимое IP-пакетом на пути через сеть мобильной радиосвязи устройство замены указателя режима кодека (DCF) (5) производит замену содержащегося в пакете данных первого указателя режима кодека на второй указатель режима кодека, известный упомянутому последующему устройству или мобильному терминалу (МТ) (1), соответствующий согласно запомненной таблице в устройстве замены указателя режима кодека (DCF) (5) первому указателю режима кодека, и что IP-пакет, который содержит второй указатель режима кодека, пересылают дальше к упомянутому последующему устройству.
2. Способ по п.1, отличающийся тем, что в качестве последующего устройства сети мобильной радиосвязи при вызове между двумя мобильными терминалами (1, 11) используют сетевой радиоконтроллер (RNC) (2).
3. Способ по любому из предыдущих пунктов, отличающийся тем, что в качестве последующего устройства сети мобильной радиосвязи используют интерфейс (шлюз) при вызове между мобильным терминалом (1) и неподвижной станцией (15).
4. Способ по п.1, отличающийся тем, что в таблице устройства замены указателя режима кодека (5) при инициализации соединения между двумя мобильными терминалами (МТ) (1, 11) запоминают по крайней мере первый указатель режима кодека и относящийся к нему второй указатель режима кодека.
5. Способ по п.1, отличающийся тем, что в пакете данных, передаваемом от мобильного терминала, содержащем указатель режима кодека в виде значения индикатора комбинации транспортных форматов (TFCI) и значения адаптивного кодирования с переменной скоростью (AMR), принимающим пакет данных сетевым радиоконтроллером (RNC) (2) заменяют значение TFCI на указатель режима кодека в виде значения индикатора комбинации подпотоков RAB (RFCI).
6. Способ по п.5, отличающийся тем, что индикатор комбинации транспортных форматов (TFCI) и индикатор RFCI представляют режим кодека.
7. Способ по п.1, отличающийся тем, что для вызовов между мобильными терминалами (МТ) (1, 11) сетевой радиоконтроллер (RNC) (2) выполнен с возможностью выдавать SDU параметры, которые представляют заданный режим кодека со значением RFCI, которое устройством замены указателя режима кодека (DCF) (5) заменяют значением RFCI и запрошенным значением RFCI.
8. Способ по п.2, отличающийся тем, что IP-пакет преобразуют в формат кадра оптимизированной поддержки кодека (OCSF) для транспортировки в GTP (протокол туннелирования GPRS) туннеле и разделяют на частичные потоки RAB (12) для транспортировки между сетевым радиоконтроллером (RNC) (2) и мобильным терминалом (МТ) (1).
9. Способ по п.8, отличающийся тем, что вид режимов кодека указан в кадре оптимизированной поддержки кодека (OCSF) посредством значения RFCI, что режим, с которым передатчик планирует кодировать данные в кадре оптимизированной поддержки кодека (OCSF), указывают посредством запрашиваемого значения RFCI, что последовательность полей в кадр OCSF зависит от реализации и стандартизации и что при необходимости добавляют в кадр OCSF другие поля, если приемник подготовлен для их интерпретации.
10. Способ по п.1, отличающийся тем, что посланный мобильным терминалом (МТ) (1) IP-пакет разделяют на частичные потоки носителя радиодоступа (RAB) (12) и снабжают значениями для TFCI и запрашиваемого TFCI и посылают к сетевому радиоконтроллеру (RNC) (2).
11. Способ по п.10, отличающийся тем, что в сетевом контроллере (RNC) (2) значение TFCI и значение запрашиваемого TFCI заменяют соответствующим значению RFCI значением запрашиваемого RFCI кадра OCSF.
12. Способ по п.8, отличающийся тем, что перед кадром OCSF сетевым радиоконтроллером (RNC) (2) подставляют заголовок GTP-U и направляют дальше к шлюзовому узлу поддержки GPRS (GGSN) (4) через обслуживающий узел поддержки GPRS (SGSN) (3).
13. Способ по п.8, отличающийся тем, что кадр OCSF от узла GGSN (4) направляют дальше к устройству замены указателя режима кодека (DCF) (5), что соответствующие друг другу значения RFCI и значения запрошенного RFCI корректируют режимом кодека принимающего мобильного терминала (МТ) (1), что модифицированный кадр OCSF посылают обратно на узел GGSN (4).
14. Способ по п.1, отличающийся тем, что IP пакет модифицируют устройством замены указателя режима кодека (DCF) (5), что узлом GGSN (4), по меньшей мере, еще раз запрашивают устройство замены указателя режима кодека (DCF) (5) для генерации кадра OCSF, что участвует по крайней мере один узел GGSN (4).
15. Способ по п.12, отличающийся тем, что узлом GGSN (4) модифицируют или соответственно заменяют заголовок GTP-U и передают кадр OCSF к узлу SGSN (3), который направляет это дальше к сетевому радиоконтроллеру (RNC) (2), что сетевым радиоконтроллером (RNC) (2) значение RFCI заменяют соответствующим ему значением TFCI, что значение запрошенного RFCI заменяют или соответственно модифицируют на значение запрошенного TFCI, что IP-пакет посылают через частичные потоки RAB (12) на мобильный терминал (МТ) (1).
16. Способ по п.1, отличающийся тем, что кадр OCSF до того, как его передают к неподвижной станции (15), преобразуют устройством замены указателя режима кодека (DCF) (5) в IP-пакет, что IP-пакет передают устройством замены указателя режима кодека (DCF) (5) к узлу GGSN (4) или непосредственно в направлении неподвижной станции (FT) (15).
17. Способ по п.1, отличающийся тем, что замену режима кодека вызывают сетевым радиоконтроллером (RNC) (2), что замену режима кодека в мобильном терминале (МТ) (1) вызывают под наблюдением сетевого радиоконтроллера (RNC) (2).
18. Устройство для преобразования передаваемых между терминалами пакетов данных, кодированных согласованными режимами кодеков, отличающееся тем, что устройство замены указателя режима кодека (DCF) (5) выполнено с возможностью хранения таблицы для сравнения значения RFCI со значением RFCI, содержащимся в упомянутой таблице, причем (DCF) (5) дополнительно содержит блок для преобразования IP-пакетов данных в кадры OCSF и для сравнения приведенных в упомянутой таблице значений (RFCI) со значениями RFCI, указанными в пакетах данных, и блок для обратного преобразования кадра OCSF в IP-пакеты данных.
19. Устройство по п.18, отличающееся тем, что устройство является блоком узла GGSN (4) или другого сетевого узла.
20. Устройство по п.18, отличающееся тем, что устройство DGF (5) является отдельным узлом с доступом к нему через IP-протокол.
