СПОСОБ, УСТРОЙСТВО И СИСТЕМА ДЛЯ УСТАНОВЛЕНИЯ КАНАЛА-НОСИТЕЛЯ В GSM-СЕТИ
METHOD, APPARATUS AND SYSTEM FOR CARRIER CHANNEL SETUP IN GSM NETWORK

По данной заявке приоритет испрашивается по тайской патентной заявке номер 200710006885 6, поданной 2 февраля 2007 года, и китайской патентной заявке номер 200710105889.X, поданной 1 июня 2007 года, которые полностью содержатся по ссылке в данном документе.
Область техники, к которой относится изобретение
Настоящее изобретение относится к технологии интерфейса GSM-сети, в частности к способу, устройству и системе для установления канала-носителя для GSM-сети.
Предшествующий уровень техники
В традиционной сетевой системе по стандарту глобальной системы для мобильной связи (GSM) сторона контроллера базовых станций (BSC) должна преобразовывать речь стороны беспроводной связи из сжатых кодов (таких как HR/FR/EFR-коды) в несжатые коды G.711. Медиашлюз (MGW) на стороне базовой сети должен преобразовывать несжатые коды G.711 в сжатые коды по схеме адаптивного многоскоростного кодирования (AMR). Кроме того, MGW должен преобразовывать режим канала-носителя между TDM-каналом-носителем на одной стороне и IP-каналом-носителем на другой стороне. Чтобы реализовывать эти преобразования, блок транскодирования и адаптации скорости (TRAU) или транскодер (TC) в типичном варианте вставлен в BSC системы GSM-сети, и TC вставлен в MGW для соответствующих преобразований речевых кодов и режимов канала-носителя. Такие преобразования могут снижать качество речи, расходовать множество дорогостоящих ресурсов TC и увеличивать затраты на оборудование. Вместе с тем, поскольку кодирование G.711 используется в A-интерфейсе, каждый тракт вызовов занимает полосу пропускания в 64 Кбит, вызывая нерациональное расходование ресурсов передачи по линиям дальней связи от BSC к MGW.
Чтобы экономить ресурс TDM-передачи между BSC и MGW, усовершенствованный способ, предложенный в настоящее время, заключается в том, чтобы перемещать TRAU из стороны BSC к стороне MGW, чтобы располагать TRAU вместе с MGW, и Ater-интерфейс предоставляется между BSC и TRAU для передачи речи и данных в формате TRAU-кадров. Поскольку каждый вызов Ater-интерфейса занимает полосу пропускания только в 16 Кбит, четыре вызова могут быть мультиплексированы в один временной слот TDM, сохраняя ценный ресурс передачи по линиям дальней связи между BSC и MGW.
Хотя вышеупомянутый усовершенствованный способ разрешает проблему нерационального расходования ресурса передачи по линиям дальней связи между BSC и MGW, TC по-прежнему должны вставляться как в TRAU, так и в MGW для преобразования режимов канала-носителя, что также приводит к ухудшению качества речи и нерациональному расходованию ресурсов TC вследствие нескольких преобразований кода.
Сущность изобретения
Вариант осуществления настоящего изобретения предоставляет способ для установления канала-носителя в GSM-сети, чтобы повышать качество речи.
Другой вариант осуществления настоящего изобретения предоставляет устройство управления базовой станцией, чтобы повышать качество речи.
Другой вариант осуществления настоящего изобретения дополнительно предоставляет устройство медиашлюза, чтобы повышать качество речи.
Другой вариант осуществления настоящего изобретения дополнительно предоставляет сервер центра коммутации мобильной связи, чтобы повышать качество речи.
Другой вариант осуществления настоящего изобретения дополнительно предоставляет систему для установления канала-носителя для GSM-сети, чтобы повышать качество речи.
Чтобы добиться вышеупомянутых целей, технические решения согласно вариантам осуществления настоящего изобретения конкретно реализуются следующим образом.
Способ для установления канала-носителя для GSM-сети включает в себя следующие этапы:
- прием посредством медиашлюза сообщения для добавления конечной точки стороны беспроводной связи, назначение IP-адреса и номера порта для вызова и передача ответного сообщения, содержащего эти IP-адрес и номер порта, назначенные для вызова; и
- получение посредством медиашлюза IP-адреса и номера порта, назначенных для вызова посредством подсистемы базовых станций стороны беспроводной связи, и установление IP-канала-носителя с подсистемой базовых станций стороны беспроводной связи.
Устройство управления базовой станцией включает в себя:
- приемный модуль, выполненный с возможностью принимать сообщение с назначением и передавать его в обрабатывающий модуль;
- обрабатывающий модуль, выполненный с возможностью принимать сообщение с назначением, получать IP-адрес и номер порта медиашлюза, содержащиеся в сообщении, назначать IP-адрес и номер порта для вызова, инициировать установление IP-канала-носителя и передавать сообщение с ответом на назначение, содержащее IP-адрес и номер порта, назначенные для вызова посредством оборудования, в передающий модуль; и
- передающий модуль, выполненный с возможностью принимать и передавать сообщение с ответом на назначение.
Медиашлюз включает в себя:
- приемный модуль, выполненный с возможностью принимать сообщение для добавления конечной точки стороны беспроводной связи и сообщение модификации канала-носителя и типа кода и передавать их в обрабатывающий модуль;
- обрабатывающий модуль, выполненный с возможностью принимать сообщение для добавления конечной точки стороны беспроводной связи, назначать IP-адрес и номер порта для вызова, выводить ответное сообщение, содержащее IP-адрес и номер порта, назначенные для вызова, в передающий модуль; принимать сообщение модификации канала-носителя и типа кода, получать информацию об IP-адресе и номере порта, назначенных для вызова посредством подсистемы базовых станций стороны беспроводной связи, содержащуюся в сообщении, и устанавливать IP-канал-носитель с подсистемой базовых станций стороны беспроводной связи; и
- передающий модуль, выполненный с возможностью принимать и передавать ответное сообщение.
Сервер центра коммутации мобильной связи включает в себя:
- приемный модуль, выполненный с возможностью принимать запрос на установление вызова, содержащий информацию о типах кода, поддерживаемых посредством мобильной станции, передаваемый посредством мобильной станции, причем ответное сообщение содержит IP-адрес и номер порта, назначенные для вызова, возвращаемые посредством медиашлюза, и сообщение с ответом на назначение, возвращаемое посредством подсистемы базовых станций стороны беспроводной связи, и передавать его в обрабатывающий модуль;
- обрабатывающий модуль, выполненный с возможностью устанавливать список приоритетов типов кода согласно сообщению с запросом на установление вызова, передавать сообщение для добавления конечной точки стороны беспроводной связи в передающий модуль; формировать сообщение с назначением согласно принимаемому ответному сообщению и списку приоритетов типов кода и выводить сообщение с назначением в передающий модуль; проводить согласование типа кода согласно принимаемому сообщению с ответом на назначение и выводить информацию, содержащую IP-адрес и номер порта, назначенные для вызова посредством подсистемы базовых станций стороны беспроводной связи, в передающий модуль; и
- передающий модуль, выполненный с возможностью принимать и передавать в медиашлюз сообщение для добавления конечной точки стороны беспроводной связи и информацию, содержащую IP-адрес и номер порта, назначенные для вызова посредством контроллера базовых станций, выводимого посредством обрабатывающего модуля; принимать сообщение с назначением, выводимое посредством обрабатывающего модуля, и передавать его в подсистему базовой станции стороны беспроводной связи.
Система для установления канала-носителя для GSM-сети включает в себя контроллер базовых станций, сервер центра коммутации мобильной связи и медиашлюз. Сервер центра коммутации мобильной связи дополнительно выполнен с возможностью реализовывать основанные на IP интерфейсы между контроллером базовых станций и медиашлюзом, при этом:
- сервер центра коммутации мобильной связи выполнен с возможностью принимать сообщение с запросом на установление вызова, содержащее информацию о типах кода, поддерживаемых посредством самой мобильной станции, передавать сообщение для добавления конечной точки стороне беспроводной связи в медиашлюз, принимать ответное сообщение, содержащее IP-адрес и номер порта, назначенные для вызова, возвращаемое посредством медиашлюза, передавать сообщение с назначением в контроллер базовых станций; принимать сообщение с ответом на назначение, возвращаемое посредством контроллера базовых станций, проводить согласование типа кода и передавать информацию, содержащую IP-адрес и номер порта, назначенные для вызова посредством контроллера базовых станций, в медиашлюз;
- медиашлюз выполнен с возможностью принимать сообщение для добавления конечной точки стороны беспроводной связи, передаваемое посредством сервера центра коммутации мобильной связи, возвращать ответное сообщение, содержащее IP-адрес и номер порта, назначенные для вызова, возвращаемое посредством сервера центра коммутации мобильной связи; принимать информацию об IP-адресе и номере порта, назначенных для вызова посредством контроллера базовых станций, и устанавливать IP-канал-носитель с контроллером базовых станций; и
- контроллер базовых станций выполнен с возможностью прозрачно передавать сообщение с запросом на установление вызова в сервер центра коммутации мобильной связи, принимать сообщение с назначением, передаваемое посредством сервера центра коммутации мобильной связи, получать IP-адрес и номер порта медиашлюза, содержащиеся в сообщении, назначать IP-адрес и номер порта для вызова, инициировать установление IP-канала-носителя и передавать сообщение с ответом на назначение, содержащее IP-адрес и номер порта, назначенные для вызова посредством контроллера базовых станций, в сервер центра коммутации мобильной связи.
Как можно видеть из вышеозначенных технических решений, с помощью способа, оборудования и системы для установления канала-носителя GSM-сети в вариантах осуществления настоящего изобретения, посредством использования IP-канала-носителя в A-интерфейсе между BSC и MGW для того, чтобы напрямую передавать речевые HR/FR/EFR-коды со сжатием в A-интерфейсе, эффективно снижается нерациональное расходование ресурсов TC, реализуется работа в режиме без транскодера (TrFO) для полного тракта или половины тракта речевого канала между BSC на вызывающей и вызываемой сторонах, повышается качество речи и сокращаются затраты на оборудование.
Перечень чертежей
Фиг.1 - это схема, иллюстрирующая архитектуру GSM-сети в варианте осуществления способа настоящего изобретения.
Фиг.2 - это схема, иллюстрирующая улучшенную структуру GSM-сети на вызывающей/вызываемой стороне в варианте осуществления способа настоящего изобретения.
Фиг.3 - это схема, иллюстрирующая структуру системы GSM-сети с основанными на IP интерфейсами согласно варианту осуществления настоящего изобретения.
Фиг.4 - это другая схема, иллюстрирующая архитектуру BSC согласно варианту осуществления настоящего изобретения.
Фиг.5 - это другая схема, иллюстрирующая архитектуру BSC согласно варианту осуществления настоящего изобретения.
Фиг.6 - это схема, иллюстрирующая архитектуру MGW согласно варианту осуществления настоящего изобретения.
Фиг.7 - это другая схема, иллюстрирующая архитектуру MGW согласно варианту осуществления настоящего изобретения.
Фиг.8 - это схема, иллюстрирующая архитектуру MSC-сервера согласно варианту осуществления настоящего изобретения.
Фиг.9 - это схема, иллюстрирующая структуру системы GSM-сети с основанным на IP A-интерфейсом согласно первому варианту осуществления настоящего изобретения.
Фиг.10 - это схема, иллюстрирующая иерархическую структуру стека протоколов плоскости служебных сигналов и плоскости канала-носителя A-интерфейса системы, показанной на фиг.9, согласно варианту осуществления настоящего изобретения.
Фиг.11 - это схема, иллюстрирующая структуру системы GSM-сети с основанным на IP A-интерфейсом согласно второму варианту осуществления настоящего изобретения.
Фиг.12 - это схема, иллюстрирующая структуру инкапсуляции речевых сообщений в Abis-интерфейсе согласно второму варианту осуществления настоящего изобретения.
Фиг.13 - это схема, иллюстрирующая процедуру вызова 2G-2G согласно второму варианту осуществления настоящего изобретения.
Фиг.14 - это схема, иллюстрирующая первую архитектуру стека протоколов пользовательской плоскости Nb-интерфейса согласно второму варианту осуществления настоящего изобретения.
Фиг.15 - это схема, иллюстрирующая структуру организации сетей для межсетевого взаимодействия 2G и 3G согласно второму варианту осуществления настоящего изобретения.
Фиг.16 - это схема, иллюстрирующая вторую архитектуру стека протоколов пользовательской плоскости в Nb-интерфейсе согласно второму варианту осуществления настоящего изобретения.
Фиг.17 - это схема, иллюстрирующая третью архитектуру стека протоколов пользовательской плоскости в Nb-интерфейсе согласно второму варианту осуществления настоящего изобретения.
Фиг.18 - это схема, иллюстрирующая структуру системы GSM-сети с основанным на IP Ater-интерфейсом согласно третьему варианту осуществления настоящего изобретения.
Фиг.19 - это схема, иллюстрирующая структуру системы основанной на IP GSM-сети согласно четвертому варианту осуществления настоящего изобретения.
Фиг.20 - это схема, иллюстрирующая структуру системы основанной на IP GSM-сети согласно пятому варианту осуществления настоящего изобретения.
Фиг.21 - это схема, иллюстрирующая процедуру обработки передачи служебных сигналов с помощью TC, размещенного на стороне BSC, согласно варианту осуществления настоящего изобретения.
Фиг.22 - это схема, иллюстрирующая процедуру обработки передачи служебных сигналов с помощью TC, размещенного на стороне MGW, согласно варианту осуществления настоящего изобретения.
Подробное описание изобретения
Чтобы прояснить цели, технические решения и преимущества настоящего изобретения, подробное описание настоящего изобретения предоставляется ниже со ссылкой на чертежи и варианты осуществления.
GSM-система, заданная организацией по стандартизации с названием Партнерский проект в области систем связи третьего поколения (3GPP), главным образом состоит из трех частей: подсистема коммутации мобильной связи (MSS), подсистема базовых станций (BSS) и мобильная станция (MS). Фиг.1 - это схема, иллюстрирующая архитектуру GSM-сети в сценарии применения варианта осуществления способа настоящего изобретения. Как показано на фиг.1, система включает в себя MSS, BSS и MS. MSS реализует основные коммутирующие функции GSM и одновременно управляет данными абонентов и базой данных, требуемой для мобильности. MSS также управляет обменом данными между мобильными абонентами GSM и обменом данными между мобильным абонентом GSM и абонентом другой сети связи. MSS включает в себя сервер центра коммутации мобильной связи (MSC) и MGW. BSS включает в себя BSC и базовую приемо-передающую станцию (BTS). BSC взаимодействует с беспроводной сетью и отвечает за управление беспроводной сетью и беспроводными ресурсами. BSC также отвечает за управление установлением, подключением и отключением беспроводных соединений для вызывающих/вызываемых MS и BTS на вызывающей/вызываемой стороне, предоставление таких функций, как речевое кодирование, преобразование типа кода и адаптация скорости. BTS выполняет преобразование между BSC и беспроводным каналом и осуществляет беспроводную передачу по радиоинтерфейсу между BTS и MS и реализует соответствующие функции управления.
Интерфейс между BTS и BSC - это Abis-интерфейс, который передает сообщения с данными и речью GSM с помощь кодов мультиплексирования с временным разделением каналов (TDM) и кадров протокола модуля канального кодека (CCU). Каждый CCU-канал занимает полосу пропускания 16 Кбит. Форматы речевого кодирования включают в себя кодирование с половинной скоростью (HR), полноскоростное кодирование (FR) и кодирование по стандарту улучшенного полноскоростного кодирования (EFR). Интерфейс между BSS и MSC-сервером - это A-интерфейс. На стороне MGW, где MGW соединяется с BSC, A-интерфейс между BSC и MGW - это конечная точка стороны беспроводной связи MGW, которая передает речь и данные с помощью протокола TDM G.711. Способ кодирования - это G.711, и каждый вызов занимает полосу пропускания 64 Кбит/с.
На стороне MSS, MSC-сервер и MGW используют режим 3GPP R4, в котором канал-носитель и управление разделяются. Все управление передачей служебных сигналов обрабатывается посредством MSC-сервера, а все каналы-носители обрабатываются посредством MGW. Nb-интерфейс используется между MGW и другим MGW. Способом кодирования в типичном варианте является AMR-кодирование. Режим передачи по Интернет-протоколу (IP) используется для того, чтобы повышать эффективность передачи и экономить полосу пропускания. Nc-интерфейс используется между MSC-сервером и MGW. A-интерфейс используется между MSC-сервером и BSC для переноса сообщений, таких как сообщения о запросах на установление соединения пользователя и сообщения о командах разъединения, посредством передачи служебных сигналов компонента приложений подсистемы базовых станций (BSSAP). После обработки посредством BSC сообщения отправляются в BTS. Сообщения BSSAP задаются посредством технических требований GSM08.08. Nc-интерфейс используется между MSC-сервером и другим MSC-сервером для того, чтобы разрешать проблему раздельного управления вызовами и управления каналами-носителями, используя протокол управления вызовами независимо от каналов-носителей (BICC). Перенос служебных сигналов управления вызовами по различным сетям предлагается для приложений телефонных услуг, которые могут предоставлять хорошую прозрачность для реализации услуг существующих телефонных сетей с коммутацией каналов в NGN.
Фиг.2 - это схема, иллюстрирующая улучшенную структуру GSM-сети на вызывающей/вызываемой стороне в сценарии применения варианта осуществления способа настоящего изобретения. Как показано на фиг.2, Ater-интерфейс используется между BSC и TRAU для того, чтобы передавать речь и данные в формате TRAU-кадров. Первоначальные интерфейсы и режимы канала-носителя между TRAU и MGW остаются неизменяемыми. Поскольку каждый вызов в Ater-интерфейсе занимает полосу пропускания только в 16 Кбит, четыре вызова могут быть мультиплексированы в один временной слот TDM, тем самым экономя ценные ресурсы передачи по линиям дальней связи между BSC и MGW.
Варианты осуществления настоящего изобретения могут эффективно уменьшать нерациональное использование ресурсов TC и достигать TrFO по половине тракта или по полному тракту для телефонного канала посредством реализации основанного на IP A-интерфейса между BSC и MGW и передачи напрямую сжатых речевых кодов стороны беспроводной связи, таких как HR/FR/EFR-коды.
Настоящее изобретение предлагает систему для установления канала-носителя для GSM-сети. Изменение интерфейсов GSM-сети в основанные на IP интерфейсы включает в себя установление IP-канала-носителя и реализацию согласования типа кода. Мультимедийные услуги и служебные сигналы передаются через IP-канал-носитель, и проблема ухудшения качества речи вследствие транскодирования TC разрешается.
Фиг.3 - это схема, иллюстрирующая структуру системы GSM-сети с основанными на IP интерфейсами согласно варианту осуществления настоящего изобретения. Ссылаясь на фиг.3, система включает в себя MS, BTS, BSC, MSC-сервер и MGW.
MS выполнена с возможностью передавать сообщение с запросом на установление вызова, переносящее информацию о типах кода, которые она поддерживает, в BSC и принимать сообщение, возвращаемое посредством MSC-сервера, указывающее то, что вызов обрабатывается.
BTS выполнена с возможностью прозрачно передавать сообщение с запросом на установление вызова, отправляемое посредством MS, и сообщение, отправляемое посредством MSC-сервера, указывающее то, что вызов обрабатывается.
BSC выполнена с возможностью устанавливать IP-канал-носитель с MGW и реализовывать преобразование типа кода, принимать сообщение с запросом на установление вызова, передаваемое посредством MS, прозрачно передавать его в MSC-сервер, принимать и перенаправлять сообщение, передаваемое посредством MSC-сервера, указывающее то, что вызов обрабатывается; и принимать сообщение с назначением, передаваемое посредством MSC-сервера. Если интерфейс между BSC и MGW определен как A-интерфейс, IP-адрес и номер порта стороны беспроводной связи MGW получаются, и собственный IP-адрес и номер порта назначаются для вызова, и устанавливается IP-канал-носитель.
Если интерфейс между BSC и MGW определен как Ater-интерфейс, установление канала Ater-интерфейса между BSC и MGW согласовывается с использованием внутриполосной передачи служебных сигналов плоскости канала-носителя через служебные сигналы TRAU (внутриполосная передача служебных сигналов между BSC и MGW может быть установлена заранее). IP-адрес и номер порта, назначенные для вызова посредством MGW, получаются, и собственный IP-адрес и номер порта назначаются для вызова. MGW получает IP-адрес и номер порта, назначенные для вызова посредством BSC, через канал Ater-интерфейса, и устанавливается IP-канал-носитель. Альтернативно Ater-интерфейс между BSC и MGW моделируется как A-интерфейс, и BSC принимает сообщение с назначением, получает IP-адрес и номер порта стороны беспроводной связи MGW и назначает собственный IP-адрес и номер порта стороны Ater-интерфейса для вызова, и устанавливается IP-канал-носитель.
Сообщение с назначением, передаваемое посредством MSC-сервера, принимается. Тип кода выбирается согласно списку приоритетов типов кода или собственной политике, и тип кода, выбранный посредством BSC, возвращается в MSC-сервер через сообщение с ответом на назначение. Если выбранный тип кода соответствует типу кода с наивысшим приоритетом в списке приоритетов типов кода, TrFO в этом сегменте реализуется, и прозрачная передача мультимедийного потока выполняется; иначе сообщение для изменения типа кода принимается от MSC-сервера, и выполняется преобразование типа кода между типом кода, выбранным посредством BSC, и типом кода, требуемым посредством MSC-сервера.
MSC-сервер разделяет канал-носитель и управление и выполнен с возможностью: обрабатывать компонент управления передачей служебных сигналов, передавать информацию об IP-канале-носители, такую как IP-адрес и номер порта, посредством расширенных служебных сигналов BSSAP, принимать сообщение с запросом на установление вызова, передаваемое посредством MS, извлекать информацию о типе кода в сообщении с запросом на установление вызова, находить пересечение с типами кода, которые он поддерживает, и устанавливать список приоритетов типов кода; передавать сообщение в MS, указывающее то, что вызов обрабатывается, передавать сообщение в MGW для добавления конечной точки стороны беспроводной связи и принимать ответное сообщение, возвращаемое посредством MGW; передавать или принимать сообщение, переносящее список приоритетов информации о типе кода, в или от других MSC-серверов и выполнять согласование типа кода для реализации TrFO; передавать сообщение с назначением в BSC и принимать сообщение с ответом на назначение, содержащее информацию о выбранном типе кода, передаваемое от BSC; выполнять согласование типа кода и передавать сообщение модификации канала-носителя и типа кода в MGW, причем сообщение модификации канала-носителя и типа кода переносит информацию IP-адреса и номера порта, назначенных для вызова посредством BSC; и распространять сообщение для изменения типа кода в BSC или MGW по мере необходимости, если функция преобразования типа кода реализуется в BSC.
MGW выполнен с возможностью: устанавливать IP-канал-носитель с BSC и выполнять преобразование типа кода, принимать сообщение для добавления конечной точки стороны беспроводной связи, передаваемое посредством MSC-сервера, передавать ответное сообщение, содержащее IP-адрес и номер порта, назначенные для вызова в MSC-сервер, принимать сообщение модификации канала-носителя и типа кода, передаваемое посредством MSC-сервера, получать IP-адрес и номер порта, назначенные для вызова посредством BSC, и устанавливать IP-канал-носитель; модифицировать тип кода для соответствующей конечной точки, как инструктировано в соответствии с сообщением.
В системе, показанной на фиг.3, MGW могут быть одним MGW или могут быть различными MGW. Когда MGW - это различные MGW, процесс установления соединения по IP-каналу-носителю для A-интерфейса между BSC на другой стороне и MGW аналогичен процессу системы, показанной на фиг.3, и описание процесса повторяется.
Кроме того, MSC-сервер(ы) могут быть одним MSC-сервером или могут быть различными MSC-серверами. Когда MSC-серверы - это различные MSC-серверы, Nc-интерфейс используется между MSC-серверами, и Nb-интерфейс используется между MGW. MSC-сервер на вызывающей стороне передает информацию инициализации (IAM) в MSC-сервер на вызываемой стороне, и MSC-сервер на вызываемой стороне возвращает информацию об IP-канале-носители, чтобы устанавливать IP-канал-носитель между стороной Nb-интерфейса MGW на вызывающей стороне и стороной Nb-интерфейса MGW на вызываемой стороне. BICC и протокол управления IP-каналом-носителем (IPBCP) могут быть рассмотрены более подробно. Процесс установления соединения по IP-каналу-носителю между стороной беспроводной связи MGW и BSC как на вызывающей стороне, так и на вызываемой стороне аналогичен процесс установления соединения по IP-каналу-носителю между стороной беспроводной связи MGW и BSC на вызывающей стороне или вызываемой стороне, при этом согласование типа кода требуется для установления TrFO и установления IP-канала-носителя. Отличие состоит в том, что: если обе стороны - это IP-каналы-носители, должно быть выполнено согласование TrFO по полному тракту для речевого канала; но если только одна сторона - это IP-канал-носитель, может быть установлен только речевой канал с TrFO по половине тракта.
На фиг.3 сообщение с ответом на назначение должно включать в себя такую информацию, как информация о типе кода, выбранном посредством BSC, IP-адрес и номер порта, назначенные для вызова посредством BSC.
В практических вариантах применения альтернативно согласование и модификация типа кода могут быть выполнены после установления IP-канала-носителя посредством BSC с помощью MGW. Конкретный процесс описывается следующим образом.
Сначала устройства управления базовой станцией, такие как BSC, удаляют TRAU-инкапсуляцию (т.е. обработку завершения TRAU) принимаемых данных стороны беспроводной связи, чтобы получать рабочие данные (полезную нагрузку) после кодирования речи со сжатием. После этого рабочие данные после кодирования речи со сжатием инкапсулируются в IP-пакетах, передаваемых в MGW через A-интерфейс между BSC и MGW. MGW продолжает выполнять обработку передачи услуг.
При реализации процесса удаления TRAU-инкапсуляции, описанной выше, способ кодирования речи со сжатием текущего кадра может быть получен согласно определенному биту в нем. После этого данные подвергаются соответствующей обработке согласно полученному способу кодирования. Например для способа FR-кодирования, речь FR 20 мс имеет ровно 260 битов, и D1-D260 - это конечные речевые кодированные со сжатием рабочие данные. Для способа EFR-кодирования не EFR-кодированные речевые данные для контроля циклическим избыточным кодом (CRC) в 260 битов должны быть удалены для того, чтобы получать конечные 244 бита данных, соответствующих речи EFR в 20 мс, и так далее.
В практических вариантах применения, после того как MGW принимает речевые кодированные со сжатием рабочие данные (т.е. рабочие данные после кодирования со сжатием), передаваемые через IP-пакеты посредством BSC, по меньшей мере, одна из следующих двух обработок дополнительно может быть выполнена:
(1) определение того, является ли способ кодирования со сжатием, используемый для речевых кодированных со сжатием рабочих данных, таким же, как способ кодирования со сжатием, используемый на приемной стороне данных (Nb-интерфейс или A-интерфейс на другой стороне); и
(2) определение того, является ли способ инкапсуляции, используемый для речевых кодированных со сжатием рабочих данных, таким же, как способ инкапсуляции, используемый на приемной стороне данных.
В определениях, описанных выше, если результат определения является положительным, данные непосредственно передаются приемной стороне данных. Иначе, по меньшей мере, один из способов кодирования со сжатием и способов инкапсуляции данных, которые определены как отличающиеся, преобразуется в способ кодирования со сжатием и/или способ инкапсуляции, используемый на приемной стороне, и затем передается приемной стороне.
Чтобы MGW мог идентифицировать и определять способ кодирования со сжатием, используемый для речевых кодированных со сжатием рабочих данных, соответствующая обработка может быть следующей. Сначала BSC передает способ кодирования со сжатием, используемый для принимаемых речевых кодированных со сжатием рабочих данных, в MSC-сервер. После этого MSC-сервер передает способ кодирования со сжатием, используемый для данных, в MGW, так чтобы MGW знал соответствующий способ кодирования со сжатием.
Кроме того, чтобы MGW и BSC распознавали информацию канала-носителя принимаемых данных, информация канала-носителя, используемого для передаваемых данных, также может быть передана в MSC-сервер посредством BSC и передана посредством MSC-сервера в MGW. Информация канала-носителя, используемого для передаваемых данных, альтернативно может быть передана в MSC-сервер посредством MGW и передана посредством MSC-сервера в BSC.
Процессы передачи услуг, предоставляемые в вариантах осуществления настоящего изобретения, включают в себя процесс передачи услуг в системе мобильной связи второго поколения и процесс передачи услуг между системами мобильной связи второго и третьего поколения, которые описываются, соответственно, далее.
В системе мобильной связи второго поколения для односкоростного кодирования передача услуг между MGW на стороне вызывающего пользователя и MGW на стороне вызываемого пользователя не реализуется с помощью способа инкапсуляции в пользовательской плоскости. Другими словами, операция инкапсуляции в пользовательской плоскости не проводится в MGW.
В системе мобильной связи второго поколения и системе мобильной связи третьего поколения, если односкоростное кодирование используется между MGW на стороне вызывающего пользователя и MGW на стороне вызываемого пользователя, передача услуг между этими двумя MGW не реализуется с помощью способа инкапсуляции в пользовательской плоскости. Другими словами, операция инкапсуляции в пользовательской плоскости не проводится в MGW. Если многоскоростное кодирование используется, передача услуг реализуется с помощью способа инкапсуляции в пользовательской плоскости. Другими словами, соответствующая операция инкапсуляции в пользовательской плоскости должна быть выполнена в MGW.
При обработке, описанной выше, способ инкапсуляции по протоколу передачи в реальном времени (RTP) используется для передачи услуг между BSC и MGW.
Далее следует пример, в котором Abis-интерфейс между BTS и BSC - это TDM-канал-носитель. В BSC, только преобразование от TDM-канала-носителя в IP-канал-носитель и завершение TRAU, т.е. обработка удаления TRAU-инкапсуляции, выполняются без транскодирования. Другими словами, между BSC и MGW передаются кодированные со сжатием данные GSM. Соответствующим способом кодирования со сжатием может быть HR-кодирование, FR-кодирование, EFR-кодирование или AMR-кодирование (адаптивная скорость). В BSC кодируемые со сжатием речевые рабочие данные GSM инкапсулируются как RTP-сообщения и передаются в MGW. Преобразование кодека TC более не должно оставаться в BSC.
Фиг.4 - это схема, иллюстрирующая архитектуру BSC согласно варианту осуществления настоящего изобретения. Ссылаясь на фиг.4, устройство включает в себя:
- приемный модуль, выполненный с возможностью принимать сообщение с назначением и передавать сообщение с назначением в обрабатывающий модуль;
- обрабатывающий модуль, выполненный с возможностью принимать сообщение с назначением, получать IP-адрес и номер порта конечной точки стороны беспроводной связи медиашлюза, содержащиеся в сообщении, назначать IP-адрес и номер порта для вызова, инициировать установление IP-канала-носителя и передавать сообщение с ответом на назначение, содержащее IP-адрес и номер порта, назначенные для вызова посредством оборудования, в передающий модуль; и
- передающий модуль, выполненный с возможностью принимать и передавать сообщение с ответом на назначение.
После приема сообщения с назначением обрабатывающий модуль дополнительно может выбирать тип кода согласно очередности по приоритету в списке приоритетов типов кода или предустановленной политике и передавать выбранный тип кода в сообщении с ответом на назначение в MSC-сервер через передающий модуль.
В практических вариантах применения BSC также может быть выполнен с возможностью удалять TRAU-инкапсуляцию принимаемых данных стороны беспроводной связи, чтобы получать речевые кодированные со сжатием рабочие данные и инкапсулировать речевые кодированные со сжатием рабочие данные в IP-пакетах. Он также может быть выполнен с возможностью передавать информацию о способе кодирования со сжатием, используемом для передачи данных в пользовательской плоскости, и/или информацию канала-носителя в MSC-сервер, и MSC-сервер передает информацию о способе кодирования со сжатием и/или информацию канала-носителя данных в MGW. Вместе с тем, он также может принимать информацию о способе кодирования со сжатием и/или информацию канала-носителя, передаваемую посредством MGW через MSC-сервер.
Фиг.5 - это другая схема, иллюстрирующая архитектуру BSC согласно варианту осуществления настоящего изобретения. Ссылаясь на фиг.5, BSC включает в себя следующие модули:
(1) модуль завершения TRAU, выполненный с возможностью удалять TRAU-инкапсуляцию из принимаемых данных стороны беспроводной связи и получать речевые кодированные со сжатием рабочие данные;
(2) модуль инкапсуляции данных, выполненный с возможностью инкапсулировать речевые кодированные со сжатием рабочие данные, полученные посредством обработки посредством модуля завершения TRAU, в IP-пакетах и передавать их в первый модуль передачи данных; и
(3) первый модуль передачи данных, выполненный с возможностью передавать IP-пакеты, инкапсулированные посредством модуля инкапсуляции данных, в медиашлюз.
Необязательно BSC дополнительно включает в себя, по меньшей мере, один из модулей передачи способа кодирования со сжатием, первый модуль приема информации канала-носителя и первый модуль передачи информации канала-носителя.
Модуль передачи способа кодирования со сжатием выполнен с возможностью передавать информацию о способе кодирования со сжатием, используемым для данных, передаваемых в пользовательской плоскости, в MSC-сервер.
Первый модуль приема информации канала-носителя выполнен с возможностью принимать информацию канала-носителя, используемого для данных, передаваемых посредством MGW от MGW через MSC-сервер.
Первый модуль передачи информации канала-носителя выполнен с возможностью передавать информацию канала-носителя, используемого для данных, передаваемых в пользовательской плоскости, в MSC-сервер.
В практических вариантах применения модуль транскодирования и адаптации скорости, модуль завершения и модуль инкапсуляции данных также могут быть включены в обрабатывающий модуль как субмодули обрабатывающего модуля.
В практических вариантах применения обрабатывающий модуль дополнительно может включать в себя модуль преобразования кода для преобразования типов кода согласно сообщению изменения кода, распространяемому посредством сервера центра коммутации мобильной связи.
Фиг.6 - это схема, иллюстрирующая архитектуру MGW согласно варианту осуществления настоящего изобретения. Ссылаясь на фиг.6, MGW включает в себя:
- приемный модуль, выполненный с возможностью принимать сообщение для добавления конечной точки стороны беспроводной связи, принимать сообщение модификации канала-носителя и типа кода и передавать их в обрабатывающий модуль;
- обрабатывающий модуль, выполненный с возможностью принимать сообщение для добавления конечной точки стороны беспроводной связи, назначать IP-адрес и номер порта для вызова, выводить ответное сообщение, содержащее IP-адрес и номер порта, назначенные для вызова, в передающий модуль; принимать сообщение модификации канала-носителя и типа кода, получать информацию IP-адрес и номер порта, назначенные для вызова посредством BSC, и устанавливать IP-канал-носитель с BSC; и
- передающий модуль, выполненный с возможностью принимать и передавать ответное сообщение.
В практических вариантах применения MGW дополнительно может быть выполнен с возможностью продолжать передачу IP-пакетов, переносящих речевые кодированные со сжатием рабочие данные с удаленными инкапсуляциями TRAU, после получения IP-пакетов через A-интерфейс между устройством управления базовой станцией и медиашлюзом. Он дополнительно может обмениваться данными с MSC-сервером, чтобы получать информацию о способе кодирования со сжатием от MSC-сервера, которая принимается от BSC, и распознавать соответствующий способ кодирования со сжатием. Также он передает информацию канала-носителя, используемого для локально передаваемых данных, в MSC-сервер, чтобы передавать информацию канала-носителя в BSC через MSC-сервер. Таким образом, он сообщает информацию канала-носителя, назначенного для вызова посредством MGW в конечной точке стороны беспроводной связи, в MSC-сервер, и информация канала-носителя затем распространяется в BSC, чтобы давать возможность каждому MGW и BSC устанавливать канал-носитель между собой после получения информации канала-носителя друг от друга.
Фиг.7 - это другая схема, иллюстрирующая архитектуру MGW согласно варианту осуществления настоящего изобретения. Ссылаясь на фиг.7, MGW может включать в себя следующие модули:
(1) модуль приема данных, выполненный с возможностью принимать речевые кодированные со сжатием рабочие данные, содержащиеся в IP-пакетах, передаваемых через A-интерфейс;
(2) обрабатывающий модуль преобразования, выполненный с возможностью преобразовывать способ кодирования со сжатием и/или способ инкапсуляции данных в IP-пакетах в способ кодирования со сжатием и/или способ инкапсуляции, используемый на приемной стороне, а затем включать данные в IP-пакеты, т.е. выполнять соответствующую обработку преобразования между двумя сторонами MGW; и
(3) второй модуль передачи данных, выполненный с возможностью передавать IP-пакеты, обрабатываемые посредством обрабатывающего модуля преобразования, в MGW, где находится приемная сторона данных.
Необязательно MGW дополнительно может включать в себя обрабатывающий модуль определения для определения, являются ли способ кодирования со сжатием и/или способ инкапсуляции, используемый для данных в IP-пакетах, такими же, как способ кодирования со сжатием и/или способ инкапсуляции, используемый на приемной стороне данных. Если способы кодирования со сжатием и/или способы инкапсуляции являются одинаковыми, IP-пакеты передаются напрямую в модуль передачи данных. Иначе, IP-пакеты передаются в обрабатывающий модуль преобразования. Таким образом, MGW может выбирать, чтобы определять, по меньшей мере, один из способов кодирования со сжатием и способов инкапсуляции, используемых для соответствующих данных между двумя сторонами MGW, чтобы выполнять соответствующую обработку преобразования согласно результату определения.
Необязательно MGW дополнительно может включать в себя, по меньшей мере, один из модулей приема способа кодирования со сжатием, второй модуль передачи информации канала-носителя и второй модуль приема информации канала-носителя.
Модуль приема способа кодирования со сжатием выполнен с возможностью принимать от MSC-сервера способ кодирования со сжатием, используемый для данных, передаваемых в пользовательской плоскости, посредством BSC и предоставлять способ кодирования со сжатием в модуль определения способа кодирования со сжатием.
Второй модуль передачи информации канала-носителя выполнен с возможностью передавать информацию канала-носителя, используемого для данных, передаваемых посредством MGW в MSC-сервер, чтобы передавать информацию канала-носителя в BSC через MSC-сервер.
Второй модуль приема информации канала-носителя выполнен с возможностью принимать от MSC-сервера информацию канала-носителя, используемого для данных, передаваемых посредством BSC в пользовательской плоскости, и предоставлять ее в модуль передачи данных.
Необязательно MGW дополнительно может включать в себя модуль согласования информации канала-носителя для согласования информации канала-носителя, используемого в ходе передачи данных, с MGW на противоположном конце.
Фиг.8 - это схема, иллюстрирующая архитектуру MSC-сервера согласно варианту осуществления настоящего изобретения. Ссылаясь на фиг.8, MSC-сервер включает в себя:
- приемный модуль, выполненный с возможностью принимать запрос на установление вызова, содержащий информацию о типах кода, поддерживаемых им, передаваемую посредством MS, ответное сообщение, содержащее IP-адрес и номер порта, назначенные для вызова, возвращаемое посредством конечной точки стороны беспроводной связи MGW, и сообщение с ответом на назначение, возвращаемое посредством BSC, и передавать их в обрабатывающий модуль;
- обрабатывающий модуль, выполненный с возможностью устанавливать список приоритетов типов кода согласно сообщению с запросом на установление вызова, передавать в передающий модуль сообщение для добавления конечной точки стороны беспроводной связи; формировать сообщение с назначением согласно принимаемому ответному сообщению и списку приоритетов типов кода и выводить его в передающий модуль; проводить согласование типа кода согласно принимаемому сообщению с ответом на назначение и выводить сообщение модификации канала-носителя и типа кода, содержащее информацию IP-адреса и номера порта, назначенных для вызова посредством контроллера базовых станций, в передающий модуль; и
- передающий модуль, выполненный с возможностью принимать и передавать в конечную точку стороны беспроводной связи MGW сообщение для добавления конечной точки стороны беспроводной связи и сообщение модификации канала-носителя и типа кода, содержащее информацию IP-адреса и номера порта, назначенных для вызова посредством контроллера базовых станций, которое выводится посредством обрабатывающего модуля; и принимать сообщение с назначением, выводимое посредством обрабатывающего модуля, и передавать его в BSC.
На основе системы, показанной на фиг.3, семь вариантов осуществления проиллюстрированы ниже с тем, чтобы подробно описывать конкретные реализации вариантов применения настоящего изобретения в ходе реализации GSM-сети с основанными на IP интерфейсами. На схемах, показывающих структуры системы согласно семи вариантам осуществления настоящего изобретения, пунктирные линии означают служебную информацию, а сплошные линии означают информацию канала-носителя.
Первый вариант осуществления
Фиг.9 - это схема, иллюстрирующая структуру GSM-сети с основанным на IP A-интерфейсом в первом варианте осуществления настоящего изобретения. Посредством рассмотрения BTS, BSC, MSC-сервера и MGW, включенных в вызывающую сторону, в качестве примера настоящий вариант осуществления иллюстрирует, что транскодирование TC размещается на стороне BSC, и A-интерфейс основан на IP. Основанный на IP A-интерфейс на вызываемой стороне аналогичен интерфейсу на вызывающей стороне и не описывается подробно. Ссылаясь на фиг.9, интерфейс между BTS и BSC - это Abis-интерфейс, а интерфейс между BSC и MGW - это A-интерфейс. На стороне MGW, где MGW соединяется с BSC, находится конечная точка стороны беспроводной связи MGW. Интерфейс между MGW и MSC-сервером - это Mc-интерфейс.
Плоскость управления A-интерфейса основана на протоколе передачи сигналов (Sigtran), указанном в стандартах. В настоящем варианте осуществления, чтобы реализовывать основанный на IP A-интерфейс, необходимо расширять функцию управления основанными на IP речевыми ресурсами плоскости управления A-интерфейса и дополнять обязательную информацию BSSAP. Например, дополненное BSSAP-сообщение имеет возможность передавать информацию об IP-канале-носителе, такую как IP-адреса и номера портов.
MS инициирует вызов, содержащий информацию о поддерживаемых типах кода, который передается прозрачно через BTS. BSC принимает сообщение с запросом на установление вызова и передает его в MSC-сервер через служебные сигналы BSSAP. MSC-сервер получает информацию о типах кода, поддерживаемых посредством вызывающей стороны, находит пересечение с типами кода, поддерживаемыми посредством MSC-сервера, и формирует список приоритетов типов кода. MSC-сервер передает сообщение для добавления конечной точки стороны беспроводной связи в MGW через Mc-интерфейс. MGW принимает сообщение для добавления конечной точки стороны беспроводной связи, назначает IP-адрес и номер порта для вызова и возвращает ответное сообщение с IP-адресом и номером порта, назначенными для вызова посредством MGW, в MSC-сервер через Mc-интерфейс. MSC-сервер принимает ответное сообщение от MGW. MSC-сервер передает сообщение с назначением, содержащее IP-адрес, номер порта, назначенные для вызова посредством MGW, и список приоритетов типов кода MSC-сервера в BSC через служебные сигналы BSSAP. BSC принимает сообщение с назначением, назначает IP-адрес и номер порта собственной стороны для вызова и инициирует установление IP-канала-носителя. Вместе с тем BSC выбирает типы кода согласно списку приоритетов информации о типах кода или собственной политики и возвращает сообщение с ответом на назначение, содержащее информацию о типе кода, выбранном посредством BSC, и IP-адрес и номер порта, назначенные для вызова посредством BSC, в MSC-сервер. MSC-сервер принимает сообщение с ответом на назначение, получает из сообщения IP-адрес и номер порта, назначенные для вызова посредством BSC, и передает сообщение модификации канала-носителя и типа кода в конечную точку стороны беспроводной связи MGW. Конечная точка стороны беспроводной связи MGW может устанавливать IP-канал-носитель с BSC после того, как она получает IP-адрес и номер порта, назначенные для вызова посредством BSC. Вместе с тем MSC-сервер принимает сообщение с ответом на назначение, получает тип кода, выбранный посредством BSC, из сообщения, помещает тип кода, выбранный посредством BSC на вызывающей стороне, на первую позицию в списке приоритетов типов кода и затем передает список приоритетов типов кода в MSC-сервер на вызываемой стороне. В обратном процессе передачи типы кода конечных точек, связанных с MGW в тракте, указываются или изменяются на оптимальный тип кода, а именно, тип кода, выбранный посредством BSC. MSC-сервер на вызываемой стороне распространяет полученный список приоритетов типов кода в BSC на вызываемой стороне. Если BSC на вызываемой стороне поддерживает тип кода, выбранный посредством BSC на вызывающей стороне, и выбирает оптимальный тип кода, реализуется речевой канал TrFO по полному тракту. Иначе BSC на вызываемой стороне возвращает выбранный тип кода в MSC-сервер на вызываемой стороне с сообщением с ответом на назначение. MSC-сервер на вызываемой стороне затем распространяет сообщение для изменения типа кода в BSC на вызываемой стороне или в BSC на вызывающей стороне через MSC-сервер на вызывающей стороне. BSC на вызываемой стороне, MGW на вызываемой стороне, BSC на вызывающей стороне или MGW на вызывающей стороне проводят преобразование между типом кода, выбранным на вызывающей стороне, и типом кода, выбранным на вызываемой стороне, после приема сообщения для изменения типа кода.
Если между MGW на вызываемой стороне и BSC на вызываемой стороне предусмотрен TDM-канал-носитель, и BSC на вызываемой стороне поддерживает тип кода, выбранный посредством BSC на вызывающей стороне, и выбирает оптимальный тип кода, MSC-сервер на вызываемой стороне распространяет сообщение преобразования формата канала-носителя в MGW на вызываемой стороне, на которой выполняется преобразование формата канала-носителя из IP в TDM. Здесь, MSC-сервер на вызываемой стороне возвращает согласованный тип кода в MSC-сервер на вызывающей стороне, и TrFO может быть реализована на вызываемой стороне. Иначе, если BSC на вызываемой стороне не поддерживает тип кода, выбранный посредством BSC на вызывающей стороне, MSC-сервер на вызываемой стороне выбирает один тип кода из типов кода, поддерживаемых посредством BSC на вызывающей стороне, согласно определенным правилам, возвращает выбранный тип кода в MSC-сервер на вызывающей стороне и распространяет выбранный тип кода в MGW на вызываемой стороне с помощью сообщения модификации типа кода. Преобразование типа кода и преобразование формата канала-носителя из IP в TDM осуществляется одновременно в MGW на вызываемой стороне. Аналогично, если между MGW на вызывающей стороне и BSC на вызывающей стороне являются TDM-каналом-носителем, преобразование типа кода и преобразование формата канала-носителя из IP в TDM осуществляется одновременно в MGW на вызывающей стороне. Тем не менее, процессы согласования типа кода между MSC-серверами отличаются. MSC-сервер на вызывающей стороне указывает, что тип кода, выбранный посредством BSC на вызываемой стороне, должен быть возвращен в сообщении, отправляемом в MSC-сервер на вызываемой стороне. Поэтому MSC-сервер на вызываемой стороне передает информацию о типе кода, выбранном посредством BSC на вызываемой стороне, в MSC-сервер на вызывающей стороне, и модифицирует типы кода конечных точек, связанных с MGW в тракте, в тип кода, выбранный посредством BSC на вызываемой стороне. Затем MSC-сервер на вызывающей стороне распространяет информацию о типе кода, выбранном посредством BSC на вызываемой стороне, в конечные точки Nb-интерфейса MGW на вызывающей стороне, а именно в конечные точки на обеих сторонах базовой сети. Таким образом, обеспечивается то, что типы кода являются одинаковыми для всех частей IP-канала-носителя, и TC вставляется только в точку преобразования TDM-IP.
Фиг.10 - это схема, иллюстрирующая иерархическую структуру стека протоколов плоскости служебных сигналов и плоскости канала-носителя A-интерфейса системы, показанной на фиг.9, согласно варианту осуществления настоящего изобретения. Ссылаясь на фиг.10, нижний уровень стека протоколов плоскости служебных сигналов A-интерфейса - это уровень управления доступом к среде (MAC). Если протоколом физического уровня не является Ethernet с пропускной способностью в сто мегабитов или в один гигабит, а является протоколом соединения "точка-точка" по технологии "пакет-по-SONET/SDH/GE" (Gigabit Ethernet) (POS) или "IP-по-E1", нижний уровень - это уровень протокола соединения "точка-точка" (PPP). Отсюда и далее, второй уровень - это IP-уровень, третий уровень - это уровень протокола управления потоковой передачей (SCTP), четвертый уровень - это уровень пользовательской адаптации M3 (M3UA), пятый уровень - это уровень протокола управления тонкими клиентами (SCCP) и верхний уровень - это BSSAP-уровень. Служебные сигналы передаются последовательно между уровнями. В настоящем варианте осуществления протокол BSSAP BSSAP-уровня и функция управления основанными на IP речевыми ресурсами должны расширяться соответствующим образом.
Если IP-интерфейс - это Ethernet с пропускной способностью в сто мегабитов или в один гигабит, нижний уровень стека протоколов плоскости канала-носителя A-интерфейса - это MAC-уровень. Если IP-интерфейс - это POS-интерфейс или IP-по-E1-интерфейс, нижний уровень - это уровень PPP. Отсюда и далее второй уровень - это IP-уровень, третий уровень - это уровень протокола пользовательских данных (UDP) и четвертый уровень - это уровень протокола передачи в реальном времени (RTP). Информация канала-носителя передается последовательно между уровнями.
В практических вариантах применения речевые кадры на основе IP-протокола также могут быть переданы посредством изменения исходного TDM-канала-носителя Abis-интерфейса между BTS и BSC на IP-канал-носитель. Это может дополнительно сокращать временную задержку, вызываемую посредством преобразования сетевого канала-носителя, и увеличивать коэффициент использования ресурсов передачи.
Кроме того, MSC-серверы на вызывающей и вызываемой стороне в варианте осуществления могут быть одним MSC-сервером или могут быть различными MSC-серверами. Когда MSC-серверы - это различные MSC-серверы, после получения типа кода, выбранного посредством соответствующего BSC, MSC-сервер на одной стороне согласовывает кодирование с MSC-сервером на другой стороне. Если нет согласованного типа кода, который обе стороны допускают, TC вставляется только в BSC на одной стороне для транскодирования.
Как видно из вышеописанных вариантов осуществления настоящего изобретения, IP-канал-носитель устанавливается в A-интерфейсе между BSC и MGW через MSC-сервер, что фактически сокращает число преобразований форматов речевого кодирования и даже исключает необходимость такого преобразования, уменьшает задержку на передачу речи, увеличивает качество передачи речи и экономит ресурсы TC. Вместе с тем, поскольку IP-канал-носитель используется, ценные ресурсы передачи по линиям дальней связи между BSC и MGW экономятся. Например, в существующей системе GSM-сети до 4 TC требуются между BSC на вызывающей и вызываемой сторонах для преобразования различных типов кода и каналов-носителей. После того как IP-канал-носитель установлен в A-интерфейсе, ни одного или только 1 TC требуется между BSC на вызывающей и вызываемой сторонах для преобразования типов кода, и преобразование канала-носителя не требуется. Если Abis-интерфейс дополнительно изменяется так, чтобы быть IP-каналом-носителем, преобразование канала-носителя не требуется по всему тракту вызова между MS на вызывающей и вызываемой сторонах.
В первом варианте осуществления, описанном выше, TC располагаются на стороне BSC. В практических вариантах применения TC альтернативно могут располагаться на стороне MGW, и IP-канал-носитель реализуется для A-интерфейса. В случае если TC располагаются на стороне MGW, TRAU-кадры могут завершаться на стороне BSC или на стороне MGW. Конкретные реализации поясняются ниже в связи со вторым и третьим вариантами осуществления, соответственно.
Второй вариант осуществления
Фиг.11 - это схема, иллюстрирующая структуру GSM-сети с основанным на IP A-интерфейсом во втором варианте осуществления настоящего изобретения. В настоящем варианте осуществления BTS, BSC, MSC-сервер и MGW, включенные в вызывающую сторону, рассматриваются в качестве примера. MSC-серверы и MGW на вызывающей стороне и вызываемой стороне могут быть одним MSC-сервером и одним MGW, соответственно. TC располагаются на стороне MGW, и TRAU-кадры завершаются на стороне BSC. Таким образом, между BSC и MGW находится A-интерфейс, который реализует IP-канал-носитель, и инкапсуляция и передача услуг, которые должны быть переданы, реализуется с использованием основанного на IP способа инкапсуляции между BSC и MGW. Например, услуги, которые должны быть переданы, такие как кодированные со сжатием услуги передачи речи, инкапсулируются в IP-сообщениях, основанных на IP сообщениях протокола пользовательских данных или основанных на IP RTP-сообщениях.
Плоскость управления A-интерфейса основана на канале-носителе по протоколу Sigtran, указанном в стандартах. Функция управления ресурсами речевого IP-канала-носителя должна быть расширена. Информация BSSAP дополняется так, чтобы предоставлять расширенную информацию BSSAP для того, чтобы передавать информацию об IP-канале-носителе, такую как IP-адреса и номера портов. Плоскость услуг A-интерфейса использует IP-канал-носитель.
Установление соединения по IP-каналу-носителю в A-интерфейсе системы, показанной на фиг.11, аналогично показанному по фиг.9 с отличием в том, что все преобразования типа кода выполняются в MGW вместо BSC. После того как BSC выбирает тип кода, BSC включает информацию о типе кода, выбранном посредством BSC в сообщение с ответом на назначение MSC-сервера через служебные сигналы BSSAP, и MSC-сервер отвечает за согласование типа кода. Если BSC на вызываемой стороне поддерживает тип кода, выбранный посредством BSC на вызывающей стороне, и выбран оптимальный тип кода, реализуется TrFO речевого канала. Иначе, MSC-сервер на вызываемой стороне принимает сообщение с ответом на назначение BSC на вызываемой стороне и распространяет тип кода, выбранный посредством BSC на вызываемой стороне, в конечную точку стороны беспроводной связи MGW на вызываемой стороне через команду модификации типа кода посредством Mc-интерфейса. Альтернативно MSC-сервер на вызываемой стороне перенаправляет тип кода, выбранный посредством BSC на вызываемой стороне, в MSC-сервер на вызывающей стороне. MSC-сервер на вызывающей стороне распространяет тип кода, выбранный посредством BSC на вызываемой стороне, в конечную точку на стороне Nb для MGW на вызывающей стороне через команду изменения типа кода. После приема команды MGW сравнивает тип кода с типом кода, выбранным посредством BSC на вызывающей стороне. Если они не совпадают, TC вставляются.
Иерархическая структура стека протоколов на плоскости служебных сигналов A/Ater-интерфейса является такой же, как показанная на фиг.10.
Если только одна сторона A-интерфейса на вызывающей/вызываемой стороне основана на IP, в то время как другая сторона имеет тип TDM, преобразование типа кода всегда осуществляется в MGW, A-интерфейс которого имеет тип TDM. Конкретная реализация аналогична реализации по первому варианту осуществления.
Аналогично исходный TDM-канал-носитель в Abis-интерфейсе между BTS и BSC также может быть заменен на IP-канал-носитель, чтобы дополнительно уменьшать временную задержку, вызываемую посредством преобразования сетевого канала-носителя, и повышать коэффициент использования ресурсов передачи.
В случае если TC располагаются на стороне MGW, и TRAU-кадры завершаются на стороне BSC, вариант осуществления настоящего изобретения также предоставляет подробные решения по реализации для A-интерфейса, Nb-интерфейса и Mc-интерфейса, которые описываются поочередно ниже.
I. Стек речевых протоколов в A-интерфейсе
Фиг.12 - это схема, иллюстрирующая структуру инкапсуляции речевых сообщений в Abis-интерфейсе согласно второму варианту осуществления настоящего изобретения. Ссылаясь на фиг.12, независимо от того, основан Abis-интерфейс на IP или TDM, TRAU в BSC равномерно инкапсулирует речевые сообщения в Abis-интерфейсе в формат RTP-инкапсуляции без какой-либо пользовательской плоскости (UP), что включает в себя снизу вверх уровень MAC-уровень или PPP-протокола, IP-уровень, UDP-уровень, RTP-уровень и уровень рабочих данных.
Соответствующий нижний уровень - это MAC-уровень для интерфейса FE (Fast Ethernet) или GE (Gigabit Ethernet) и является PPP-уровнем для интерфейса IP-по-E1 и POS.
Для способа EFR-, FR- или HR-кодирования уровень рабочих данных соответствующего верхнего уровня переносит рабочие данные речевых сообщений. Для его формата инкапсуляции с конкретным порядком следования байтов способ инкапсуляции, заданный в стандарте Европейского института стандартизации в области телекоммуникаций (ETSI), может использоваться (ETSI ts_101318). Для способа AMR-кодирования, поскольку это кодирование речи с переменной скоростью с процессом регулирования скорости внутриполосной речи, способ инкапсуляции, заданный в стандарте в формате запроса на комментарии Инженерной группы по развитию Интернета (IETF RFC3267), используется для соответствующего уровня рабочих данных.
В вариантах осуществления настоящего изобретения, чтобы быть в соответствии с TRAU, время передачи пакета для услуги передачи речи может быть равномерно установлено равным конкретно 20 мс.
Рассматривая GSM в качестве примера, часто используемые способы кодирования включают в себя EFR, FR, HR или AMR. Каждая из тактовых частот для EFR и FR составляет 8000 Гц. Тип рабочих данных (PT) для FR является статическим 3. PT для EFR является динамическим (96-127).
В случае способа FR-кодирования соответствующая обработка является относительно простой вследствие статического PT.
В случае способа EFR-кодирования, благодаря PT EFR-кодирования для A-интерфейса, служебные сигналы BSSAP должны быть расширены так, чтобы PT EFR между BSC и MGW согласовывался между MSC-сервером и BSC. Альтернативно соответствующий PT предварительно конфигурируется в MSC-сервере и затем распространяется в BSC и MGW через BSSAP-сообщение и Mc-сообщение. Альтернативно соответствующий PT (со значением в диапазоне 96-127) определяется посредством конфигураций BSC и MGW и является достаточным для того, чтобы поддерживать обе стороны одинаковыми.
Для других способов кодирования, таких как HR, он может быть реализован в отношении способа определения PT, описанного выше, например, в соответствии с EFR или с использованием динамического PT, подробное описание которого опускается.
Определения значений PT, соответствующих различным способам кодирования и услугам передачи данных, конкретно могут быть следующие значения:
FR: 3;
EFR: 96-127;
HR: 96-127;
AMR: 96-127;
DATA(услуга передачи данных): 96-127;
RED(избыточность): 96-127;
Для каждого из EFR, HR, AMR или услуг передачи данных значения избыточности данных являются динамическими PT с конкретными значениями, совместно распространяемыми в MGW и BSC посредством MSC-сервера.
Соответствующее PTIME (время передачи пакета): 20 мс.
DTX (прерывистая передача): Как для BSS, так и для MGW требуется поддержка.
II. Реализация Mc-интерфейса
MSC-сервер предоставляет информацию канала-носителя A-интерфейса в MGW через Mc-интерфейс.
В частности BSC сообщает собственную информацию канала-носителя, такую как IP-адрес и номер порта, в MSC-сервер через расширенное BSSAP-сообщение, и MSC-сервер распространяет информацию канала-носителя из BSC и результат согласования типа кода в MGW. Вместе с тем MSC-сервер дополнительно принимает информацию канала-носителя MGW, передаваемую из MGW, и распространяет ее в BSC.
Для других способов кодирования сообщение формата SDP (протокол описания сеанса) информации канала-носителя, распространяемой посредством MSC-сервера, задается следующим образом:
(1) FR-кодирование
c=IN IP4 10.10.10.1;
m=audio 49120 RTP/AVP 3;
a=ptime:20;
где c означает информацию о соединении, m означает имя мультимедиа и адрес передачи, и a=ptime означает время передачи пакета.
(2) EFR-кодирование
c=IN IP4 10.10.10.1;
m=audio 49120 RTP/AVP 98;
a=rtpmap:98 GSM-EFR/8000;
a=ptime:20;
где a=rtpmap означает строки атрибутов мультимедиа, а именно имя для кодирования.
(3) HR-кодирование
c=IN IP4 10.10.10.1;
m=audio 49120 RTP/AVP 98;
a=rtpmap:98 GSM-HR/8000;
a=ptime:20;
(4) AMR-кодирование
См. подробное определение RFC3267.
c=IN IP4 10.10.10.1;
m=audio 49120 RTP/AVP 97;
a=rtpmap:97 AMR/8000/1;
a=fmtp:97 mode-set=0,2,5,7;
a=maxptime:20;
(5) Услуга передачи данных
c=IN IP4 10.10.10.1;
m=DATA 49120 RTP/AVP 97;
SERVER гарантирует, что вышеупомянутые PT отличаются от друг друга.
III. Реализация Nb-интерфейса
Соответствующий PT согласовывается посредством Nb-интерфейса с использованием IPBCP.
Чтобы реализовывать TrFO, обработка в Nb-интерфейсе должна поддерживаться согласованной с обработкой в A-интерфейсе в максимально возможной степени. Для вызова 2G-2G используется способ инкапсуляции без UP, будь то односкоростное кодирование или многоскоростное кодирование. Для вызова 2G-3G способ инкапсуляции, согласованный со способом в A-интерфейсе, используется для односкоростного кодирования, и способ инкапсуляции с UP используется в случае, если как 2G, так и 3G используют AMR-кодирование.
(1) Процедура вызова для односкоростного кодирования/декодирования
Фиг.13 - это схема, иллюстрирующая процедуру вызова 2G-2G согласно второму варианту осуществления настоящего изобретения. Ссылаясь на фиг.13, вызов из BSC1 в BSC2 - это внутристанционный вызов, и вызов из BSC1 в BSC3 - это межстанционный вызов. Будь то внутри- или межстанционный вызов, способ инкапсуляции UP не используется для односкоростного кодирования/декодирования (HR/FR/EFR). Вместо этого используется режим, в котором речевые сообщения инкапсулируются непосредственно в RTP-сообщениях.
Фиг.14 - это первая схема, иллюстрирующая архитектуру стека протоколов пользовательской плоскости в Nb-интерфейсе согласно второму варианту осуществления настоящего изобретения. Ссылаясь теперь на фиг.14, которая является способом инкапсуляции рабочих данных для односкоростного кодирования, соответствующим фиг.13, предусмотрены снизу вверх: MAC-уровень или уровень PPP-протокола, IP-уровень, UDP-уровень, RTP-уровень и уровень рабочих данных. Уровень рабочих данных конкретно может включать в себя данные способа HR-, FR- или EFR-кодирования.
(2) Многоскоростное кодирование/декодирование
Фиг.15 - это схема, иллюстрирующая структуру организации сетей для межсетевого взаимодействия 2G и 3G согласно второму варианту осуществления настоящего изобретения. Фиг.16 - это вторая схема, иллюстрирующая архитектуру стека протоколов пользовательской плоскости в Nb-интерфейсе согласно второму варианту осуществления настоящего изобретения. Ссылаясь теперь на фиг.15, которая показывает также вызов 2G-2G между BSC1 и BSC2. Когда AMR-кодирование/декодирование приспособлено, соответствующий формат инкапсуляции - это способ инкапсуляции, указанный посредством RFC3267, показанным на фиг.16, а не формат инкапсуляции UP.
Вызов между BSC1 и RNC1 и вызов между RNC2 и BSC2 на фиг.15 - это вызовы 2G-3G. Для вызова 2G-3G, в случае если используется AMR-кодирование/декодирование, соответствующий способ инкапсуляции UP показывается на фиг.17. Фиг.17 - это третья схема, иллюстрирующая архитектуру стека протоколов пользовательской плоскости в Nb-интерфейсе согласно второму варианту осуществления настоящего изобретения. В отличие от фиг.16 рабочие данные AMR на фиг.17 - это рабочие данные AMR. Когда абонент 2G - это вызывающий абонент, направление UP в Nb-интерфейсе рядом со стороной 2G - это CN/Outgoing (исходящее направление базовой сети). Когда абонент 2G - это вызываемый абонент, направление UP в Nb-интерфейсе рядом со стороной 2G - это CN/Incoming (входящее направление базовой сети). Таким образом, MGW на стороне 2G должен выполнять преобразование от способа инкапсуляции AMR без UP (A-интерфейс) к способу инкапсуляции AMR с UP.
После того как A-интерфейс становится основанным на IP, если межстанционный Nb-интерфейс использует режим AMR с UP, информация канала-носителя в Nb-интерфейсе для согласования в Nb-интерфейсе с IPBCP следующая:
c=INIP4 192.168.153.21;
m=audio 764 RTP/AVP 96;
a=ptime:20;
a=rtpmap:96 VND.3GPP.IUFP/16000.
После того как A-интерфейс становится основанным на IP, если Nb-интерфейс не использует режим AMR с UP, согласование IPBCP может подчиняться, но не только, следующим дополнениям, соответственно, согласно способам кодирования и типам услуги передачи данных:
(1) Для вызова 2G-2G, если межстанционный Nb-интерфейс использует AMR без UP способа RFC3267, информация канала-носителя, согласованная с IPBCP, следующая:
c=INIP4 192.168.153.21;
m=audio 764 RTP/AVP 96;
a=ptime:20;
a=rtpmap:96 AMR/8000/1;
(2) Если RF-кодирование используется между станциями, где PT - это статический PT, информация канала-носителя, согласованная с IPBCP, следующая:
c=INIP4 192.168.153.21;
m=audio 764 RTP/AVP 3;
a=ptime:20;
(3) Если EFR-кодирование используется между станциями, PT - это динамический PT, и информация канала-носителя, согласованная с IPBCP, следующая:
c=INIP4 192.168.153.21;
m=audio 764 RTP/AVP 97;
a=ptime:20;
a=rtpmap:96 GSM-EFR/8000;
(4) Если HR-кодирование используется между станциями, PT - это динамический PT, и информация канала-носителя, согласованная с IPBCP, следующая:
c=INIP4 192.168.153.21;
m=audio 764 RTP/AVP 97;
a=ptime:20;
a=rtpmap:96 GSM-HR/8000;
(5) Для межстанционной услуги передачи данных с UP в 5 мс, информация канала-носителя, согласованная с IPBCP, следующая:
c=INIP4 192.168.153.21;
m=audio 764 RTP/AVP 96;
a=ptime:5;
a=rtpmap:96 VND.3GPP.IUFP/16000;
(6) Для межстанционной услуги передачи данных согласно G.711 в 20 мс, информация канала-носителя, согласованная с IPBCP, следующая:
c=INIP4 192.168.153.21;
m=audio 764 RTP/AVP 0;
a=ptime:20;
или:
c=IN IP4 192.168.153.21;
m=audio 764 RTP/AVP 8;
a=ptime:20.
Следует отметить, что информация конкретного IP-адреса и номера порта в вышеприведенной информации SDP является только примерной и может варьироваться в практических вариантах применения. Если информация PT типа нагрузки для RTP - это динамический PT в диапазоне 96-127, он может варьироваться аналогичным образом в практических вариантах применения.
В вариантах осуществления настоящего изобретения формат инкапсуляции данных в Nb-интерфейсе конкретно может быть следующим. Для услуг передачи данных 2G-2G используется пакетирование по 20 мс, и режим согласно стандарту RFC2198 используется для избыточности. Для услуг передачи данных 2G-3G используется способ инкапсуляции G.711 с UP в 5 мс.
Третий вариант осуществления
Фиг.18 - это схема, иллюстрирующая структуру системы для реализации основанного на IP Ater-интерфейса в GSM-сети согласно третьему варианту осуществления настоящего изобретения. Фиг.18 отличается от фиг.11 тем, что TRAU-кадры, передаваемые посредством системы, показанной на фиг.18, завершаются на стороне MGW. Другими словами, интерфейс между BSC и MGW соответствует Ater-интерфейсу в исходной GSM-системе.
Поскольку TRAU-кадры завершаются на стороне MGW, интерфейс между BSC и MGW - это Ater-интерфейс. Кроме того, A-интерфейс в исходной GSM-системе перешел во внутреннюю часть MGW. Канал-носитель Sigtran используется для передачи служебных сигналов по A-интерфейсу. Режим IP-канала-носителя используется для передачи служебных сигналов по Ater-интерфейсу. Служебные сигналы между BSC и MSC-сервером могут передаваться непосредственно через IP или могут быть перенаправлены через IP посредством MGW. Предусмотрено два способа для MSC-сервера, чтобы управлять установлением схемы плоскости IP-канала-носителя Ater-интерфейса:
(1) MSC-сервер не управляет установлением схемы плоскости IP-канала-носителя Ater-интерфейса. Для режима внутриполосной передачи служебных сигналов плоскости канала-носителя, MGW и BSC ведут согласование для того, чтобы устанавливать канал Ater-интерфейса через служебные сигналы TRAU. MGW получает тип речевого кода BSC посредством разрешения TRAU-кадров Ater-интерфейса и сравнивает его с типом кода базовой сети. Если типы кода не соответствуют друг другу, TC вставляется для преобразования речевого кодирования.
(2) MSC-сервер управляет установлением схемы плоскости IP-канала-носителя Ater-интерфейса. Функция управления ресурсами режима речевого IP-канала-носителя и информация, связанная с IP-каналом-носителем протокола BSSAP, дополняется, и Ater-интерфейс моделируется как A-интерфейс в первоначальной системе. Установление схемы плоскости IP-канала-носителя Ater-интерфейса аналогично установлению по фиг.9. Отличие заключается в том, что после того как MGW и BSC устанавливают IP-канал-носитель, MSC-сервер получает тип кода, выбранный посредством BSC, и затем распространяет его в конечную точку MGW, соответствующего стороне BSC, тем самым обеспечивая то, что тип кода на стороне BSC соответствует типу кода конечной точки MGW, соответствующего BSC. Затем MGW сравнивает типы кода на обеих сторонах на предмет согласованности. Если они являются согласованными, TrFO речевого канала реализуется. Иначе, TC вставляется для транскодирования.
По сравнению с фиг.10 пятый TRAU-уровень добавляется в стек протоколов плоскости канала-носителя A/Ater-интерфейса системы, показанной на фиг.18.
Как можно видеть из вышеописанных вариантов осуществления, ни обработка TRAU-кадров, ни преобразование речевого кодирования не требуются в BSC, выполняется только прозрачная передача TRAU-кадров.
В первом, втором и третьем вариантах осуществления, описанных выше, передаваемые TRAU-кадры завершаются посредством BSC или MGW. Дополнительно TRAU-кадры также могут быть отменены по всей сети, т.е. основанные на IP речевые кадры выводятся непосредственно в BTS.
Конкретные реализации описываются ниже с помощью четвертого и пятого вариантов осуществления, соответственно.
Четвертый вариант осуществления
Фиг.19 - это схема, иллюстрирующая структуру основанной на IP GSM-сети согласно четвертому варианту осуществления настоящего изобретения. Как показано на фиг.19, установление соединения по IP-каналу-носителю между BSC и MGW аналогично установлению по фиг.9. Протокол BSSAP должен быть дополнен по мере необходимости для передачи информации об IP-канале-носителе, такой как IP-адрес и номер порта. Если тип кода на стороне MGW в BSC вызывающей стороны является несогласованным с типом на вызываемой стороне для BSC вызываемой стороны, TC вставляется на стороне MGW для транскодирования. После того как соединение по IP-каналу-носителю установлен, BTS выводит основанные на IP речевые кадры, такие как IP/UDP/RTP/VOICE-сообщения, и BSC принимает речевые кадры, чтобы перенаправлять их в MGW.
В вышеописанном варианте осуществления, поскольку преобразование режима канала-носителя не требуется, временная задержка передачи уменьшается, и качество передачи речи повышается.
Дополнительно в вышеописанном варианте осуществления, после того как соединение по IP-каналу-носителю установлено, BSC альтернативно может не участвовать в перенаправлении речевых кадров, и речевые кадры передаются непосредственно между BTS и MGW, что дополнительно уменьшает временную задержку, вызываемую посредством перенаправления речевых кадров в BSC, и экономит производительность обработки BSC, которая подробно описывается в пятом варианте осуществления.
Пятый вариант осуществления
Фиг.20 - это схема, иллюстрирующая структуру основанной на IP GSM-сети согласно пятому варианту осуществления настоящего изобретения. BSC обменивается служебными сигналами с BTS и MSC-сервером через канал передачи служебных сигналов, такой как процедура доступа к линии связи по D-каналу (LAPD) и BSSAP, соответственно, и не участвует в перенаправлении речевых кадров на плоскости канала-носителя. В настоящем варианте осуществления, для того чтобы устанавливать соединение по каналу-носителю между BTS и MGW, протокол BSSAP и протокол LAPD должны быть расширены в отношении информации об IP-канале-носителе. Установление соединения по каналу-носителю аналогично установлению по фиг.9. Отличие заключается в следующем. BSC принимает сообщение с назначением и получает информацию об IP-канале-носителе и затем передает ее в BTS через служебные сигналы LAPD. BTS получает IP-адрес и номер порта, назначенные для вызова посредством стороны беспроводной связи MGW, и назначает IP-адрес и номер порта BTS на своей стороне для вызова. BTS сообщает информацию об IP-канале-носителе (IP-адрес и номер порта), назначенную для вызова, в BSC. BSC затем передает IP-адрес и номер порта, назначенные посредством BTS, переносимые в сообщении с ответом на назначение, в MSC-сервер. MSC-сервер затем указывает их для MGW. BTS и MGW могут устанавливать канал-носитель, если они оба знают IP-адрес и номер порта друг друга. Тип кода, используемый посредством BTS, т.е. выбранный тип кода, переносимый в сообщении с ответом на назначение BSC, полностью управляется посредством BSC. MSC-сервер распространяет тип кода BTS, выбранный посредством стороны беспроводной связи, в MGW, чтобы гарантировать то, что тип кода конечной точки стороны беспроводной связи MGW всегда соответствует типу кода, используемому посредством BTS. MSC-сервер проводит согласование типа кода для полного тракта речевого канала. Если согласование успешно выполняется, TrFO реализуется. Если согласование завершается ошибкой, выбирается MGW на вызывающей стороне или MGW на вызываемой стороне, в который вставляется TC для преобразования типа кода.
В практических вариантах применения MS также может переключаться между различными BTS. BSC передает уведомления в MSC-сервер, чтобы уведомлять MSC-сервер о новых IP-адресах и номерах портов BTS. MSC-сервер принимает уведомления, распространяет уведомления для изменения канала-носителя MGW и выполняет переключение канала-носителя.
Шестой и седьмой варианты осуществления излагаются ниже для того, чтобы пояснять процедуру управления передачей служебных сигналов по настоящему изобретению.
Шестой вариант осуществления
Фиг.21 - это схема, иллюстрирующая процедуру передачи служебных сигналов для размещения TC на стороне BSC согласно варианту осуществления настоящего изобретения. В настоящем варианте осуществления TC располагается в BSC, BSC преобразует речевое кодирование, и соединение по IP-каналу-носителю устанавливается в вызывающем абоненте. Ссылаясь на фиг.21, процедура включает в себя следующие этапы.
На этапе 211 MS инициирует вызов, который перенаправляется в MSC-сервер через BTS и BSC.
На этапе 212 MSC-сервер возвращает сообщение MS, указывающее то, что запрос на установление вызова обрабатывается.
На этапе 213 MSC-сервер передает сообщение в MGW для добавления конечной точки стороны беспроводной связи.
На этапах 211-213 сообщение с запросом на установление вызова, принимаемое посредством MSC-сервера, содержит информацию о типах кода, поддерживаемых посредством самой MS. Как обнаруживается, пересечение между типами кода и типами кода, поддерживаемыми посредством MSC-сервера, формирует список приоритетов типов кода, и конечная точка стороны беспроводной связи добавляется в MGW через Mc-интерфейс.
На этапе 214 MGW принимает сообщение для добавления конечной точки стороны беспроводной связи и возвращает ответное сообщение.
На этом этапе MGW принимает сообщение для добавления конечной точки стороны беспроводной связи, назначает IP-адрес и номер порта для вызова, и ответное сообщение включает в себя IP-адрес и номер порта, назначенные для вызова посредством MGW.
На этапе 215 MSC-сервер принимает ответное сообщение и передает сообщение с назначением в BSC. Сообщение содержит IP-адрес и номер порта, назначенные для вызова посредством MGW, и список приоритетов типов кода MSC-сервера.
На этапе 216 BSC принимает сообщение с назначением, возвращает сообщение с ответом на назначение, содержащее назначенную информацию об IP-канале-носителе и выбранный тип кода.
На этом этапе BSC принимает ответное сообщение, получает IP-адрес и номер порта, назначенные посредством MGW для вызова, назначает IP-адрес и номер порта собственной стороны для вызова и инициирует установление IP-канала-носителя одновременно. Выбор типа кода посредством BSC, который должен быть использован им, может быть выбором типа кода согласно порядку очередности в списке приоритетов типов кода, предоставляемом посредством MSC-сервера, или согласно собственной политике. BSC возвращает сообщение с ответом на назначение в MSC-сервер, который содержит тип кода, выбранный посредством BSC, и IP-адрес и номер порта, назначенные посредством BSC для вызова. MSC-сервер инициирует согласование типа кода для вызова по полному речевому каналу через следующие этапы.
BSC выбирает тип кода и передает информацию о типе кода в MSC-сервер. MSC-сервер передает обратно тип кода, выбранный посредством BSC, и помещает тип кода, выбранный посредством BSC на вызывающей стороне, в первую позицию списка приоритетов типов кода для распространения в BSC на вызываемой стороне. Если BSC на вызываемой стороне поддерживает и выбирает тип кода, выбранный посредством BSC на вызывающей стороне, речевой канал TrFO по полному тракту может быть реализован. Иначе тип кода, выбранный посредством BSC на вызываемой стороне, является несогласованным с очередностью по приоритету в списке приоритетов типов кода MSC-сервера, преобразование типа кода должно быть выполнено в BSC на вызываемой стороне. Например, вызывающий абонент назначает FR/EFR, и BSC на вызывающей стороне выбирает FR. MSC-сервер на вызывающей стороне передает FR обратно. Вызываемая MS поддерживает HR/FR/EFR. MSC-сервер на вызываемой стороне распространяет FR/HR/EFR в BSC на вызываемой стороне. Если BSC на вызываемой стороне выбирает FR, то тип кода, выбранный посредством BSC на вызывающей стороне, соответствует предпочтительному типу кода, рекомендуемому посредством MSC-сервера на вызывающей стороне, и речевой канал TrFO по полному тракту может быть реализован без вставки TC для преобразования типа кода. Если BSC на вызываемой стороне выбирает HR, который возвращается в MSC-сервер на вызываемой стороне через сообщение с ответом на назначение. MSC-сервер на вызываемой стороне обнаруживает, что TrFO не может быть реализована в собственном сегменте, через анализ и определение и распространяет сообщение модификации типа кода BSC на вызываемой стороне, чтобы инструктировать BSC на вызываемой стороне реализовывать преобразование типа кода между FR и HR.
В практических вариантах применения, после того как соединение по IP-каналу-носителю установлено, если BSC должен изменять выбранный тип кода, вследствие таких причин, как пропускная способность беспроводной сети, BSC изменяет выбранный тип кода самостоятельно и сообщает его в MSC-сервер, и повторное согласование типа кода инициируется. Процесс является аналогичным согласованию типа кода в ходе установления вызова. Отличие состоит в том, что случай, при котором MSC-сервер на вызываемой стороне передает предпочтительный тип кода в MSC-сервер на вызывающей стороне, может возникать. После того как тип кода BSC на одной стороне изменяется, TrFO полного речевого канала может быть прекращена. Тем не менее, возможно то, что исходный вызов без использования TrFO становится вызовом TrFO через повторное согласование.
Седьмой вариант осуществления
Фиг.22 - это схема, иллюстрирующая процедуру передачи служебных сигналов для размещения TC на стороне MGW согласно варианту осуществления настоящего изобретения. Ссылаясь на фиг.22, процедура включает в себя следующие этапы.
На этапе 221 MS инициирует вызов, который перенаправляется в MSC-сервер через BTS и BSC.
На этапе 222 MSC-сервер возвращает сообщение MS, указывающее то, что запрос на установление вызова обрабатывается.
На этапе 223 MSC-сервер передает сообщение в MGW для добавления конечной точки стороны беспроводной связи.
На этапах 221-223 сообщение с запросом на установление вызова, принимаемое посредством MSC-сервера, содержит информацию о типах кода, поддерживаемых посредством самой MS, обнаруживается, что пересечение между типами кода и типами кода, поддерживаемыми посредством MSC-сервера, формирует список приоритетов типов кода, и конечная точка стороны беспроводной связи добавляется в MGW через Mc-интерфейс.
На этапе 224 MGW принимает сообщение для добавления конечной точки стороны беспроводной связи и возвращает ответное сообщение.
На этом этапе MGW принимает сообщение для добавления конечной точки стороны беспроводной связи, назначает IP-адрес и номер порта для вызова, и ответное сообщение включает в себя IP-адрес и номер порта, назначенные посредством MGW для вызова.
На этапе 225 MSC-сервер принимает ответное сообщение и передает в BSC сообщение с назначением, которое содержит IP-адрес и номер порта, назначенные посредством MGW для вызова, и список приоритетов типов кода MSC-сервера.
На этапе 226 BSC принимает сообщение с назначением и возвращает сообщение с ответом на назначение.
На этом этапе BSC принимает сообщение с назначением, получает из сообщения с назначением IP-адрес и номер порта, назначенные посредством MGW для вызова, назначает IP-адрес и номер порта собственной стороны для вызова и устанавливает IP-канал-носитель. Выбор типа кода посредством BSC, который используется им, может быть выбором типа кода согласно порядку очередности в списке приоритетов типов кода, предоставляемом посредством MSC-сервера, или согласно собственной политике. Сообщение с ответом на назначение, содержащее информацию о типе кода, выбранном посредством BSC, и IP-адрес и номер порта, назначенные для вызова посредством BSC, передается в MSC-сервер.
На этапе 227 MSC-сервер принимает сообщение с ответом на назначение, получает информацию об IP-адресе и номере порта, назначенных посредством BSC для вызова, формирует сообщение модификации канала-носителя и типа кода и передает его в конечную точку стороны беспроводной связи MGW.
На этапе 228 конечная точка стороны беспроводной связи MGW принимает информацию об IP-канале-носителе и сообщение модификации типа кода, выполняет соответствующую обработку и возвращает ответное сообщение.
На этом этапе, после того как MGW получает информацию об IP-канале-носителе стороны беспроводной связи, указанную посредством BSC, MGW может инициировать установление канала-носителя с BSC/BTS на стороне беспроводной связи. Конечная точка стороны беспроводной связи MGW принимает сообщение модификации типа кода, модифицирует тип кода конечной точки согласно типу кода, инструктированному в сообщении, и возвращает ответное сообщение в MSC-сервер.
Обработка служебных сигналов на вызываемой стороне аналогична обработке на вызывающей стороне. Тип кода конечной точки стороны беспроводной сети BSC должен быть обеспечен согласованным с типом кода конечной точки стороны BSC MGW посредством сообщения модификации типа кода. MGW должен только сравнивать типы кода Nb-интерфейса и A/Ater-интерфейса для определения их согласованности. Если типы кода являются несогласованными, TC преобразования типа кода вставляются; иначе преобразование типа кода TC не вставляется, и речевой канал TrFO по половине тракта или по полному тракту не реализуется.
После того как соединение по IP-каналу-носителю установлено, BSC инициирует запрос на изменение типа кода, когда типы кода должны быть изменены или переключены. После изменения типов кода конечных точек, соответствующих всем MGW, MSC-сервер передает сообщение с ответом по изменению типа кода в BSC. BSC изменяет типы кода.
В вариантах осуществления настоящего изобретения посредством использования IP-передачи между BSS и MSS, цель экономии ресурсов передачи может быть достигнута с помощью признака мультиплексирования пакетов IP. В практических вариантах применения эффективность передачи может быть дополнительно повышена с помощью релевантных технологий, таких как протокол передачи в реальном времени в сжатом формате (CRTP), мультиплексирование по протоколу передачи в реальном времени (RTP-мультиплексирование), мультиплексирование по протоколу соединения "точка-точка" (PPPMUX) и мультиплексирование IP-заголовков.
Цели, технические решения и преимущества настоящего изобретения подробно описаны в связи с вышеприведенными предпочтительными вариантами осуществления. Подразумевается, что примерные варианты осуществления, предоставляемые выше, являются только предпочтительными вариантами осуществления настоящего изобретения и не имеют намерение ограничивать объем настоящего изобретения. Любые модификации, эквивалентные замены и усовершенствования в рамках принципов настоящего изобретения должны содержаться в объеме настоящего изобретения.