Изобретение относится к системе, обеспечивающей дополнительные услуги и процедуры управления транскодером для обработки трафика между абонентами в сети связи. В частности, изобретение относится к системе для реализации способа пересылки вызова цифровым мобильным абонентам в цифровой сотовой телефонной радиосистеме.
Сотовая радиотелефонная система обычно содержит сеть сопрягающихся радиоячеек, которые обеспечивают полное покрытие географической зоны, подлежащей обслуживанию. Каждая ячейка имеет базовую станцию (БС), которая обеспечивает связь с одной или более мобильными станциями (МС) через соответствующие радиоканалы. Набор радиоканалов, выделенных данной ячейке во избежание взаимных помех, отличается от наборов, используемых в соседних ячейках. Группы БС управляются соответствующими коммутационными центрами услуг мобильной связи (МЦС), каждый из которых эквивалентен местному телефонному коммутатору в коммутируемой телефонной сети общего пользования (ТСОП). Таким образом на МЦС возложены такие задачи обработки трафика, как коммутация, маршрутизация и начисление платы за вызовы, а также двухсторонний обмен с ТСОП и другими сетями.
Во всех широко известных сотовых системах, таких как Северный Мобильный Телефон (NMT), Система Связи Общего Доступа (TACS), Американская Цифровая Система (ADC), Глобальная Система Мобильной Связи (GSM) и Персональная Цифровая Сотовая Система (PDC) (обычно называемая Японской Цифровой Сотовой Системой (JDC)), использованы стандартизированные способы обеспечения базовых и дополнительных услуг для перемещающихся абонентов. Используемый в этой заявке термин "базовые услуги" относится к способности сети связи просто устанавливать вызов и к таким услугам, как трехстороннее соединение, которые предоставляются всем абонентам без необходимости заключения с ними специального договора. Термин "дополнительные услуги" относится к тем возможностям мобильных, а также стационарных сетей, которые выходят за рамки "базовых услуг" и требуют заключения специального договора с абонентом, прежде чем эти услуги могут быть оказаны.
Специальные дополнительные услуги абоненту можно разделить на два типа: те, которые видоизменяют или дополняют процесс генерации вызова (в описании они называются "услуги A-абонента"); и те, которые видоизменяют и дополняют процесс завершения вызова (они называются "услуги B-абонента"). Услуги A-абонента включают запрещение исходных вызовов и закрытые схемы нумерации абонентов. Услуги B-абонента можно разделить на безусловно активизируемые услуги, то есть те, которые активизируются независимо от состояния вызываемого абонента или сети, и услуги, активация которых зависит от конкретного состояния или условия, имеющего место у абонента или в сети. Безусловные услуги B-абонента включают запрещение входящих вызовов и безусловную пересылку вызовов. Условные услуги B-абонента включают пересылку вызова в состоянии "занято", пересылку вызова в состоянии "абонент не отвечает", пересылку вызова в состоянии перегрузки и ожидания вызова.
Для слежения за МС в качестве узла сети радиосвязи может быть предусмотрена база данных, называемая регистратором исходного местоположения (РИМ). Когда пользователь (МС) заключает с оператором договор на получение услуг связи, информация об абоненте, такая как дополнительная услуга (и), выбранная пользователем, вводится в РИМ этого оператора. Также РИМ запоминает информацию о местоположении МС, включая информацию, идентифицирующую МЦС, обслуживающий текущее местоположение МС. Эта информация обновляется по мере перемещения МС из-за того, что МС посылает информацию о своем местоположении на свой РИМ с помощью МЦС. Таким образом, когда МС попадает в зону нового МЦС, он регистрируется у этого МЦС, который затем запрашивает из РИМ данные о МС и информирует РИМ той зоны МЦС, в которой в настоящий момент находится МС.
РИМ принимает участие в организации специальных дополнительных услуг абоненту, заключающееся в том, что дополнительно к запоминанию текущего местоположения перемещающегося абонента РИМ может также запоминать категории абонентов и номера пересылки вызовов (называемые C-номерами). РИМ обновляет информацию о категории абонента и C-номера в своей памяти, если на это имеется запрос со стороны уполномоченного на это терминала. РИМ передает отобранные части этой информации опрашивающему МЦС в случае регистрации перемещающегося МС, и в шлюзовый МЦС (GMS) - в случае вызова в МС, как более подробно объяснено ниже.
В обычной сети услуги A-абонента и условные услуги B-абонента обеспечиваются МЦС на основе категорий абонентов, подаваемых РИМ в МЦС "абонента-визитера" в момент регистрации. Безусловные услуги B-абонента активизируются РИМ, поскольку вызов в МС всегда означает, что первый подсоединенный МЦС (то есть, GMS) обращается к РИМ для того, чтобы узнать, где находится абонент. Таким образом РИМ находится в лучшем положении для организации безусловных услуг, таких как посылка в GMS C-номера, на который должна быть безусловно выполнена пересылка вызова.
Для того чтобы стандартизировать связь между РИМ и МЦС, в сотовых радиотелефонных системах применены Modile Application Part (MAP) and Translation Capabilities Application Part (TCAP) of the communications protocol (Прикладная часть по мобильным объектам (MAP) и Прикладная часть по возможностям трансляции (TCAP) протокола обмена), известные как CCITT Signalling System N 7 (Система передачи сигналов CCITT N 7). При этом рекомендации Q. 701-Q.707, Q.711-Q.714, Q.771-Q.775 из "Blue Book" CCITT (Международный консультативный комитет по телеграфии и телефонии) включены в эту заявку в качестве ссылки. Некоторые из вариантов протоколов MAP и TCAP используются с различными сотовыми стандартами (GSM, ADC, PDC и т.д.). MAP обеспечивает процедуры передачи сигналов для обмена между МС. Сетевая часть PDC описана в стандартных Internode Specifications for Digital Mobile Communications Network, TTC JJ70.10, Ver. 3.2 (Межузловые Спецификации для цифровой мобильной сети связи) TTC JJ70.10, Ver. 3.2).
Согласно различным описанным вариантам осуществления изобретения существующие каналы передачи сигналов систем радиосвязи используются для передачи простых сообщений о запросах, относящихся к конкретной инициируемой абонентом дополнительной услуге, в которой у мобильного абонента возникла потребность. Передача сигнала запроса для такой услуги от МС в сеть, а также передача сигнала подтверждения от сети к МС, указывающего, был или нет удовлетворен запрос на эту услугу, осуществляется через "Уровень 3". "Уровень 3" - термин, определяющий, где и в каких логических каналах передается и принимается конкретное сообщение. "Уровень 3" описывается, например, в Recomendations Q.930 в CCITT's "Blue Book", Fascicle VI. 11, "Digital Subscriber Signalling System N 1 (DSS 1), Network Layer, User Network Managment".
Можно рассматривать систему связи как, по меньшей мере, трехуровневую. Уровень 1 - это физический уровень, который определяет параметры физического канала связи, например, разнесение радиочастот, характеристики модуляции несущей и т. п. Уровень 2 определяет способ, необходимый для точной передачи информации в рамках ограничений физического канала Уровня 1, например, исправление и обнаружение ошибок и т.п. Уровень 3 определяет процедуры для прозрачной передачи информации через канальный уровень Уровня 2.
Обсуждение конкретных вариантов аппаратурной реализации систем радиосвязи выходят за рамки данного описания, но специалистам должно быть очевидно, что данное изобретение можно применить в любой системе, где между мобильной и портативной станцией и сетью происходит передача сигналов для дополнительных услуг. Одним из примеров системы радиосвязи является сотовая сеть связи, в которой МЦС подсоединен между PSTN и одной или более базовыми станциями, которые передают и принимают сигналы от МС. Когда установлено соединение для вызова, то имеет место обмен через канал трафика, в то время как по каналу управления обычно осуществляется начальная установка соединения для вызова и передача вызова от одной ВС к другой. Технические характеристики каналов трафика и управления могут соответствовать применяемому стандарту для конкретно реализованной системы, например, GSM, ADC, PDC и т. п. Аппаратурная конфигурация подобных базовых и мобильных станций раскрыта в патенте США N 5119397.
Если будут разработаны новые дополнительные услуги, то их можно будет быстро ввести путем использования концепции сети, известной как Интеллектуальная сеть (ИС). Идея ИС заключается в создании интеллектуальных узлов (I-узлов) в сети, к которым могут обращаться за информацией другие узлы в сети и которые могут обновлять свою информацию с помощью других узлов, I-узлы представляют собой оборудование для обработки данных, подсоединенное к другим узлам только через каналы для передачи сигналов, I-узлы не имеют коммутируемых соединений пользователя для речи или для передачи данных пользователя. Следовательно, они могут быть доступны через каналы данных только из других конкретных узлов в сети, например, таких как служебные коммутационные узлы (СКУ) в PTSN.
Новые услуги вводятся путем добавления новых программных модулей в I-узлы, причем каждый из них соответствует функциональной сущности IN. Например, узел управления услугами (УУУ) представляет собой узел в сети, где размещается большинство логических схем, а СКУ представляет собой узел, который обрабатывает коммутационные функции, необходимые для введения в действие услуг, инициированных УУУ. Эти узлы соответствуют функциональным объектам, которые были определены стандартами IN, представленными в CCITT Recomendations Q. 1218. В УУУ также реализована функция служебных данных (ФСД), где хранятся служебные данные, необходимые для УУУ. Обмен между СКФ и ФУУ (и между СКУ и УУУ) выполняется в соответствии с протоколом, который называется "Intellegent Network Application Part" (INAP) (Прикладная часть интеллектуальной сети) и также является частью CCITT N 7.
Технические решения по интеллектуальной сети в стационарном сетевом оборудовании обеспечивают быстрый ввод новых услуг в результате функционального разделения между ФУУ и СКФ, при котором все логические операции по конкретным услугам реализуются в ФУУ, а ФУУ выполняет лишь общие коммутационные функции (например, непрерывный контроль и сообщение о появлениях вызовов; установка новых ветвей и разъединение ветвей) под управлением ФУУ. В то же время техническое решение согласно концепции IN нельзя использовать в сотовом оборудовании из-за конфликта между рабочими стратегиями ФУУ и РИМ, SDF и РИМ, ФУУ и МЦС. ФУУ выполняет те же функции, что и РИМ, но при этом отличается по технической реализации и интерфейсам. То же самое можно сказать о SDF и РИМ, а также о ФУУ и МЦС.
Например, ФУУ предназначена для управления всеми услугами в интеллектуальной сети, но такая структура противоречит стандартам сотовой связи, которые однозначно требуют, чтобы в РИМ содержалась информация, необходимая для активизации таких услуг, как безусловная пересылка вызова и запрещение входящих вызовов. Подобным же образом SDF выполняет функцию хранения данных абонента в интеллектуальной сети, но в сотовой сети данные абонента всегда хранятся в РИМ.
В цифровой сотовой телефонной сети речь между терминалами пересылается в цифровой форме, например, от генерирующего вызов цифрового МС на телефон в ТСОП или на другой МС. Входной аналоговый речевой сигнал у цифрового МС преобразуется в цифровую форму в соответствии с алгоритмом речевого кодирования, который удовлетворяет используемому стандарту. PDC система использует алгоритм речевого кодирования, который является представителем класса речевых кодеров, известных как кодо-возбуждаемые линейные предиктивные кодеры (CELP-кодеры), или возбуждаемые векторной суммой линейные кодеры (VSELP-кодеры). VSELP-кодер преобразует аналоговый речевой сигнал в цифровой речевой сигнал, принимая во внимание ожидаемое распределение частоты и амплитуды человеческого голоса. Таким образом можно сжать полосу частот речи 3,1 килогерц (кГц) до всего лишь 6,7 килобит в секунду (кбит/с), что много меньше 64 кбит/с, которые потребовались бы, если бы использовалась обычная импульсно-кодовая модуляция (ИКМ). С другой стороны, кодированная таким образом речь не может быть использована другими без преобразования кодированного сигнала в обычный цифровой речевой сигнал с использованием устройства, называемого транскодер или кодек.
Кроме речевого кодирования во многих системах используется также канальное кодирование, например, канальный кодер PDC берет VSELP цифровой речевой сигнал, имеющий скорость передачи данных 6,7 кбит/с, и преобразует его в канально-кодированный сигнал, имеющий скорость передачи 11,2 кбит/с, который может проходить через сеть без ограничений, например, от одного МЦС к другому по каналу со скоростью передачи 64 кбит/с. Понятно, что 11,2 кбит/с означает передачу с полной скоростью, но можно также использовать и передачу канально-кодированного сигнала, получаемого из цифрового речевого сигнала от PSI-CELP речевого кодера, с половинной (5,6 кбит/с) скоростью.
При вызове между двумя цифровыми МС правильные процедуры управления транскодером, используемые для обработки трафика, получаются только в том случае, если гарантируется выполнение процедур абонентских узлов цифровой сети с интегрированными услугами (ISUP) и процедур преобразования данных сквозным образом, то есть, если вызов в любой момент времени остается полностью внутри сети PDC. В таком случае как вызывающий абонент, так и конечный абонент подсоединяются к соединению с VSELP-речевым или канальным кодированием со скоростью передачи 11,2 кбит/с. Теоретически в вызывающем МС можно преобразовать речевую кодированную и канально-кодированную информацию со скоростью передачи 11,2 кбит/с в вызов 64 кбит/с и затем преобразовать информацию обратно на конечном МС. На практике качество речи ухудшается, так что необходимо синхронизировать оба речевых кодера друг с другом и установить для них режим "соединение через кодек".
На фиг. 1a изображены транскодеры в режиме "соединение через кодек". Ссылочные символы A, B и C представляют VSELP-речевые кодированные и канально-кодированные вызовы. Ссылочные символы D и F представляют соединения для передачи сигналов от МС-A к МЦС-A и от МС-B к МЦС-B соответственно. Ссылочный символ G представляет соединение для передачи сигналов MAP.
На фиг. 1b изображена диаграмма передачи сигналов для вызова между двумя цифровыми МС, где вызывающий МЦС принимает сообщение SETUP (установка) от вызывающего МС и анализирует номер вызываемого абонента. Транскодер на вызывающем МЦС будет установлен на "речь" независимо от того, получен или нет результат "вызов к МС". Важно, что можно услышать любые появляющиеся акустические сигналы или сообщения, а также обрабатывать ситуацию, когда осуществляется пересылка вызова.
В ISUP сообщения содержат дополнительную информацию, касающуюся конкретных данных мобильной связи. Начальное адресное сообщение (НАС) содержит требования к носителю передачи (ТНП) или неограниченную цифровую информацию, а также информацию, представляющую пропускную способность передачи, включая сведения о том, что может передаваться либо "речь", либо "речь и данные", что данные представляют собой данные со скоростью передачи 11,2 кбит/с или подвергаются VSELP кодированию, что стандарт кодирования представляет либо нет стандарт, определенный для данной сети. НАС также содержит данные ссылки вызова (ВС), идентифицирующие вызов в вызывающем МЦС, и код узла передачи сигналов (КУС) вызывающего МЦС, и информацию о коде сети (КС), идентифицирующую вызывающую сеть.
При приеме НАС конечный МЦС передает сигнал поискового вызова на вызываемый МС и размещает СВ. Конечный МЦС посылает назад свои СВ и КУС в полном адресном сообщении (ПАС). Вызывающий МЦС принимает ПАС и запоминает значение СВ из ПАС. КУС из ПАС отбрасывается, и вместо этого КУС конечного МЦС получают из сообщения запроса установки кодекса (CODEC SET REQ), которое посылается для запроса транзитного соединения. В этот момент конечный МЦС имеет достаточно информации, чтобы инициировать MAP обмен с вызывающим МЦС, но вызывающий МЦС не имеет достаточно информации, чтобы начать такой обмен до получения сообщения от конечного МЦС.
Установка конечного вызова продолжается обычным образом, пока от МС не будет принято сообщение о соединении (CONN). В этот момент установка вызова приостанавливается, и в то же время инициируются процедуры управления транскодером. Из анализа полученного НАС и служебной информации пользователя конечный МЦС узнает, что вызов идет от другого цифрового МС и устанавливает свой транскодер в режим "соединение через кодек". Затем конечный транскодер начинает посылать блоки речи и синхронизации (PC). Используя КУС, КС и СВ, полученные в НАС, конечный МЦС посылает сообщение MAP CODEC SET REQ, запрашивая переключение вызывающего транскодера в режим "соединение через кодек". В конечном МЦС запускается таймер Tcodec, ожидающий сообщения подтверждения установки кодека (CODEC SET ACK).
При приеме сообщения CODEC SET REQ в вызывающем МЦС, вызывающий транскодер начинает посылать PC блоки в схему речи. Когда это сделано, вызывающий МЦС посылает сообщение CODEC SET ACK обратно в конечный МЦС, используя СВ, запомненную ранее, и КУС и КС, полученные в сообщении CODEC SET REQ. При приеме сообщения CODEC SET ACK установка вызова продолжается при посылке ответного сообщения (ОТС). Если сообщение CODEC SET ACK не принято, прежде чем истекло время Tcodec, то тогда вызов отсоединяется конечным МЦС. MAP сообщения посылаются непосредственно между конечным МС и вызывающим МС с использованием КУС, КС и СВ, посылаемых во время фазы установки вызова.
В известной PDC сети, показанной на фиг. 2, вызывающий МЦС, обозначенный как МЦС-A, поддерживает радиосвязь с вызывающим цифровым МС, обозначенным как МС-A, который включает в себя речевой кодер и канальный кодер. Вызов, генерируемый МС-A, устанавливается от МЦС-A до конечного МЦС, обозначенного как МЦС-B, через тракт или соединение 10: МЦС-B поддерживает радиосвязь с конечным цифровым МС, обозначенным как МС-B, который включает в себя канальный декодер и речевой декодер. МЦС-A использует MAP интерфейс для запроса РИМ по поводу текущего местоположения МС-B и приема номера перемещающегося МС-B, который МС-A использует для маршрутизации вызова к МС-B через соединение 10 и МЦС-B. На фиг. 2 показана типичная ситуация, когда пересылка вызова не активируется МС-B, так как сеть работает в режиме "соединение через кодек" и VSELP или CELP данные проходят через соединение 10 как данные Уровня 1.
Заданные информационные элементы в сигнальных сообщениях стандарта PDC не полностью подходят для процедур управления транскодером и некоторых дополнительных услуг. Например, процедуры управления транскодером, определенные для системы PDC, неадекватны для случая трафика, когда конечный МС переслал вызовы на другой цифровой МС.
Такая ситуация показана на фиг. 3. Если в МЦС-B активизирована услуга пересылки вызова, то логическое устройство в МЦС-B вызывает считывание в память его категории (которая была обновлена от РИМ через MAP интерфейс, когда МС-B переместился в зону, обслуживаемую МЦВ-B) информации о том, что МС-B переслал вызовы по конкретному C-номеру, заданному в памяти. В ответ на эту ситуацию МЦВ-B направляет этот вызов на цифровой МС-C (на который пересылается вызов), имеющий C-номер, через соединение 12 и МЦС, на который пересылается вызов, обозначенный как МЦС-C, тем самым окончательно выполняя дополнительную услугу.
Когда пересылается такой вызов, то МЦС-C автоматического коммутатора, на который пересылается вызов, трудно идентифицировать вызывающий МЦС-A автоматического коммутатора и идентифицировать вызывающую СВ информацию. Для того чтобы конечной МЦС цифрового МС мог адресоваться к вызывающему МЦС другого цифрового МС, конечным МЦС должен быть определен не только КУС, но также и идентификатор сети вызывающего МЦС. В существующей спецификации стандарта PDC на I-узел конечный МЦС извлекает идентификатор сети вызывающего МЦС из информации о "зоне тарифа", входящей в НАС, посылаемое из вызывающего МЦС на конечный МЦС. В частности, идентификатор сети вызывающей МЦС извлекается из КС данных и данных зоны сообщения (ЗС) в НАС.
Однако, в другом известном варианте трафика, показанном на фиг. 3, информационный элемент "Зона тарифа" НАС, посылаемый МЦС-B, не может быть использован МЦС-C для извлечения идентификатора сети вызывающего МЦС-A, поскольку ветвь пересылки является независимой. Таким образом информация "Зона тарифа" в НАС, посылаемая МЦС-B на МЦС-C, относится к пересылаемому абоненту МС-B, а не к абоненту МС- A, генерирующему вызов.
Кроме того, как показано на фиг. 3 и 4, когда инициируется пересылка вызова, сообщение запроса установки кодека для запроса речевого и канального кодирования не достигнет конечного пункта назначения МЦС-A, поскольку данные КУС в НАС используются для адресации МЦС-A, а данные КС в НАС используются для адресации МЦС-B. Причина этого состоит в том, что пересылающему вызов абоненту МС-B начисляется плата за ветвь пересылки вызова. Кроме того, поскольку пересылающий МЦС-B может принадлежать сети, отличающейся от сети вызывающего МЦС-A, то пересылка вызова может оказаться невозможной для обработки с помощью процедур управления транскодером одной сети.
Другой упомянутой выше проблемой, связанной с пересылкой вызова, является обращение по ссылке вызова согласно ISUP для обмена между различными автоматическими коммутаторами и сетями. Согласно стандарту PDC и существующей спецификации I-узла в ISUP конечный МЦС-B посылает полное адресное сообщение (ПАС) в вызывающий МЦС-A. Сообщение ПАС включает в себя КУС конечного МЦС-B, а также СВ, распределяемую МЦС-B. Параметры КУС и СВ используются МЦС-A при посылке сообщения подтверждения установки кодека на МЦС-B для подтверждения того, что запрос на речевое и канальное кодирование был принят.
Как показано на фиг. 5, если абонент МС-B передает вызовы другому цифровому МС, подсоединенному к МЦС-C, то КУС и СВ, хранящиеся в вызывающем МЦС-A, будут теми же, что и (в прошлом) конечного МЦС-B. Поскольку МЦС-C - это конечный МЦС пересылаемого вызова, то сообщение подтверждения установки кодека, которое посылается из МЦС-A в МЦС-C, содержит СВ МЦС-B вместо СВ МЦС-C. Другими словами, СВ сообщения запроса установки кодека не соответствует СВ сообщения подтверждения установки кодека. Поскольку в МЦС-C не будет получен ответ с СВ, распределенной МЦС- C, время таймера, запускаемого в МЦС-C для обработки вызова, истечет, то процедура установки окажется безуспешной и вызов будет отсоединен.
Как показано на фиг. 3, данные VSELP или CELP декодируются в МЦС-A и проходят через соединение 10, МЦС-B и соединение 12, как обычные данные РСМ. МЦС-C вновь кодирует информацию, используя как речевое, так и канальное кодирование, и подает вновь закодированную информацию в МЦ-C. При CELP/VSELP кодировании в речевой кодер должны подаваться только аналоговые речевые сигналы, то есть два кодера не должны быть соединены последовательно. Таким образом известный стандарт PDC обеспечивает установку ветви пересылки между МЦС-B и МЦС-C и МЦ-C в качестве независимого вызова. МЦС-A декодирует данные речи для передачи в МЦС-C, который вновь кодирует эти данные для передачи в МЦ-C. Для пересылки вызова передающий МЦС изменяет TMR либо на "речь", либо на аудиосигнал 3,1 кГц. Когда вызов пересылается, оба абонента будут иметь транскодер, подсоединенный в режиме "речь", что может привести к ухудшению качества речи. В результате такого дополнительного декодирования/кодирования качество речи ухудшается, поскольку при CELP/VSELP кодировании качество речи достигается лишь за счет более низкой скорости передачи в битах.
Сущность изобретения
Согласно изобретению, появляется возможность избежать декодирования речи в существующей сети стандарта PDC при пересылке вызова от одного цифрового терминала или сети к другому. Способ пересылки вызова, предложенный заявителем, не имеет двух недостатков, присущих существующему стандарту PDC: он обеспечивает идентификацию вызывающего автоматического коммутатора и ссылку исходящего вызова, когда вызов пересылается из одной цифровой сети в другую.
Целью изобретения является устранение ненужного речевого и канального кодирования и декодирования при пересылке вызова из одной цифровой сети в другую.
Еще одной целью изобретения является предоставление возможности существующим стандартом цифровой сети поддерживать операции пересылки вызова и одновременно повысить качество речи.
Согласно изобретению, эти и другие цели достигаются посредством обеспечения точной идентификации сети и обращения по ссылке вызова во время операции пересылки вызова. Правильная идентификация сети реализуется посредством использования нового информационного элемента, содержащего код сети вызывающего МЦС, который не будет изменяться во время установки вызова сети, даже если инициирована пересылка вызова. Точное обращение по ссылке вызова реализуется посредством использования услуг Transaction Capability Application Part (TCAP), которые предусматривают, что от вызывающего МЦС на нужный конечный МЦС всегда будет посылаться обратный результат, подтверждающий сообщение запроса установки кодека.
Краткое описание чертежей
В дальнейшем изобретение поясняется описанием конкретного варианта его воплощения со ссылками на сопровождающие чертежи, на которых:
фиг. 1a, 1b показывают известный процесс установки вызова между мобильными станциями;
фиг. 2 показывает маршрутизацию вызова в известной сети мобильной связи без активации дополнительной услуги пересылки вызова;
фиг. 3 показывает дополнительную услугу пересылки вызова в известной мобильной сети связи;
фиг. 4 показывает последовательности сообщений в сети в случае пересылки вызова, согласно изобретению;
фиг. 5 изображает последовательности сообщений в сети в случае пересылки вызова, согласно изобретению;
фиг. 6 показывает дополнительную услугу пересылки вызова в мобильной сети связи, согласно изобретению;
фиг. 7 показывает поле характеристического номера вызывающей стороны, модифицированное для включения в него информационного элемента "адрес МЦС", согласно изобретению.
Подробное описание предпочтительного варианта осуществления изобретения
Пересылка вызова выдвигает специфические проблемы управления транскодером в сети, которые решаются с помощью изобретения. В качестве примера вызывающий МЦС обозначен как МЦС-A; МЦС, который пересылает вызов, обозначен как МЦС-B, и в МЦС, на который были переданы вызовы, обозначен как МЦС-C. Однако, изобретение не ограничивается использованием этих обозначений, а применимо к любому типу или количеству сетевых элементов, вовлеченных в операцию пересылки вызова.
Изобретение (фиг. 6) обеспечивает прохождение VSELP или CELP данных через объединение 10 в виде данных Уровня 1, но эта информация не декодируется в МЦС-A. Вместо этого через сеть для данного вызова устанавливается режим "соединение через кодек", так что VSELP или CELP данные проходят через соединение 12 в виде данных Уровня 1 на МЦС-C, который просто пересылает информацию на МЦ-C. В результате удается избежать дополнительного декодирования/кодирования, которое ухудшает качество речи.
Когда в цифровой сотовой сети типа системы PDC между цифровыми МС активизируется пересылка вызова, вызов, который направляется МЦС-B на МЦС-C, обрабатывается как независимый вызов из МЦС-A. Таким образом, сеть или автоматический коммутатор, на который направлен вызов, например, МЦС-B, для третьей стороны, например, МЦС-C, должен выполнить соответствующую обработку, так чтобы сигналы, относящиеся к направляемому вызову, воздействовали на вызывающую сторону, чтобы у вызывающей сети не было необходимости узнавать, что была активизирована пересылка вызова.
Идентификация сети является одной из частей способа обработки, которую сеть должна выполнить во время операции пересылки вызова. Для обеспечения точной идентификации сети вызывающего МЦС-A во время операции пересылки вызова, данные, которые используются для адресации МЦС-A из отвечающего мобильного абонента МЦ-C, четко отделяются от других данных. То есть информационный элемент "Зона тарифа" в НАС для адресации МЦС-A не используется. Вместо этого в ISUP НАС вводится новый информационный элемент под названием "адрес МЦС", который содержит код сети МЦС-A.
Иллюстрацией части формата ISUP НАС является поле характеристического номера вызывающей стороны. Это поле (фиг. 7) модифицировано, чтобы включить информационный элемент "адрес МЦС". "Адрес МЦС" во время установки вызова в сети не изменяется, даже если активизирована пересылка вызова. Таким образом адрес МЦС-A может быть всегда точно найден и установка вызова будет успешной.
Другой частью процесса обработки, которую должна выполнить сеть во время операции пересылки вызова, является обращение по ссылке вызова конечного МЦС с помощью вызывающего МЦС. Указанная выше проблема в известных процессах обращения по ссылке вызова для пересылки вызова состоит в том, что СВ конечного МЦС посылается в вызывающий МЦС через ISUP в ПАС сообщении. ПАС посылается в вызывающий МЦС-A перед пересылкой вызова, так что "конечный" МЦС в соответствии с ПАС сообщением не является МЦС-C, на который пересылается, а скорее является пересылающим МЦС-B. Таким образом ПАС сообщение не всегда указывает МЦС-C, на который направляет ответ МЦ-C, на который пересылается вызов.
Проблемы обращения по ссылке вызова разрешаются не путем посылки СВ через ISUP от конечного МЦС-B на вызывающий МЦС-A в ПАС сообщении. Вместо этого используются услуги ТСАР. Одной из возможностей ТСАР, которая обеспечивает большое разнообразие применений для передачи информации между узлами в сотовой сети, является диалоговая обработка, при которой два пользователя могут обмениваться большими объемами информации. ТСАР диалог может быть либо структурированным, либо неструктурированным. Неструктурированный диалог, который не требует ответа от пользователя, обычно используется для сетевого управления. Структурированный ТСАР диалог, который требует ответа от пользователя или дает ответы пользователю, предпочтителен для процедур MAP "контроль через кодек" в сети.
ТСАР включает операции четырех различных классов, атрибуты которых показаны в Таблице 1.
Операция ТСАР Класса 4 обычно используется для "запроса установки кодека" и определяется в соответствии с Таблицей II. Используя операцию ТСАР Класса 4 "запрос установки кодека" посылается конечным МЦС-B на вызывающий МЦС-А, но обратный результат от вызывающего МЦС-A назад к конечному МЦС не посылается.
Известное сообщение подтверждения установки кодека определяется в соответствии с Таблицей III.
Вместо этого согласно одному аспекту изобретения заявителя для "запроса установки кодека" используется операция TCAP Класса 1. Таким образом обратный результат от вызывающего МЦС-A, подтверждающий "запрос установки кодека", всегда посылается на наружный конечный МЦС, что обеспечивается обычными возможностями TCAP. Используя структурированный диалог ТСАР, вызывающий МЦС-A может также, если необходимо, реагировать на отклоненный запрос.
Операция "запроса установки кодека", согласно изобретению, определяется в соответствии с Таблицей IV, с использованием существующей спецификации I-узла.
В качестве альтернативы использования структурированной ТСАР процедуры, описанной в Таблице IV, то есть, использования неструктурированного диалога, к каждому из сообщений "запроса установки кодека" и "подтвержения запроса установки кодека" (подтверждение установки кодека) Класса 4 TTC JJ 70.10 Ver. 3 может быть добавлено поле. Добавленные поля можно назвать ИВ, для "идентификации вызова", как показано в Таблице V для сообщения "запроса установки кодека", и они могут представлять ссылку вызова, распределяемую МЦС-C (действительным конечным МЦС).
Добавление полей ИВ, которые обычно имеют такой же формат, как поля IIСВ, позволяет использовать операции Класса 4, но инициатор выполнения операции автоматически получает ответ, если операция будет успешной. Правильная ссылка вызова будет всегда возвращаться к инициатору операции. Добавление ИВ полей удовлетворяет требованиям Класса 4, изначально идентифицируя вызов и оставаясь без изменений.
В соответствии с альтернативным вариантом изобретения "запрос установки кодека" определяется путем использования Abstract Syntax Notation 1 (ASN.1) (Абстрактной синтаксической системы обозначений 1), которая представляет собой язык для описания структурированной информации, рекомендованной Международным Консультативным Комитетом по Телеграфии и Телефонии (CCITT). "Запрос установки кодека" в системе обозначений ASN.1 показан ниже:
Формальное описание ASN.1
CodecSetupRequest::= OPERATION
(запрос установки кодека) (работа)
PARAMETER (параметр)
call Reference CallReference
(ссылка вызова)
codecStatus CodecStatus
(состояние кодека)
RESULT (результат)
ERRORS (ошибки) CodecFailure
(отказ кодека)
Информационные элементы СВ и КУС, которые обычно посылаются в ПАС сообщении, могут быть удалены из ПАС сообщения, поскольку эти информационные элементы участвуют в обмене при использовании других сообщений. Это освобождает место в ПАС сообщении для дополнительной информации.
Описанное выше изобретение позволяет осуществлять пересылку вызова, поддерживаемую в сети со стандартом PDC, обеспечивая при этом более высокое качество речи посредством того, что удается избежать ненужного декодирования речи, когда вызов направляется от одной сети (или автоматического коммутатора) на другую. В ISUP НАС добавляется новый информационный элемент под названием "адрес МЦС", который содержит код сети вызывающего МЦС, так что адрес вызывающего МЦС может быть правильно определен конечным МЦС или, если была инициирована пересылка вызова, то тем МЦС, который принимает вызовы, пересылаемые от указанного конечного МЦС. Для операции "запроса установки кодека" используется структурированный диалог Класса 1 ТСАР, так что сигнал обратного результата, подтверждающий "запрос установки кодека", посылается на нужный приемник в конечном МЦС или, если была инициирована пересылка вызова, в МЦС, на который пересылается вызов.
Очевидно, что изобретение Заявителя не ограничивается описанными и проиллюстрированными конкретными вариантами его воплощения. Иными словами, изобретение может быть использовано в любой цифровой сотовой системе связи, например, такой как D-AMPS (ADC) или GSM. Естественно, что предложенное техническое решение можно использовать и для многоступенчатой пересылки вызова типа A-B ⇒ C ⇒ D, A-B ⇒ C ⇒ D ⇒ E и т.д. Где "А" представляет вызывающий абонент, перемещающийся в зоне, обслуживаемой МЦС-A, "B" представляет абонента, перемещающегося в зоне, обслуживаемой МЦС-B, абонент "B" которого переслал свои вызовы другому абоненту "C", перемещающемуся в зоне, обслуживаемой МЦС-C, абонент C которого, в свою очередь, переслал свои вызовы следующему абоненту "D", перемещающемуся в зоне, обслуживаемой МЦС-D и т.д. Предполагается, что данное изобретение охватывает все модификации, лежащие в пределах объема изобретения.
Изобретение относится к технике связи. Технический результат состоит в разработке новых дополнительных услуг. Цифровая сотовая система связи поддерживает передачу вызовов при лучшем качестве речи посредством того, что удается избежать ненужного декодирования речи, когда вызов пересылается от одной сети (или автоматического коммутатора) на другую. В начальное адресное сообщение добавляется новый информационный элемент, который содержит код сети вызывающего коммутационного центра услуг мобильной связи (МЦС), так что адрес вызывающего МЦС может быть правильно определен в конечном МЦС или, если была инициирована пересылка вызова, то тем МЦС, на который пересылается вызов. Для посылки запроса на речевое кодирование в вызывающий МЦС используется структурированный диалог, при котором сигнал обратного результата, подтверждающий запрос, посылается на нужный приемник в конечном МЦС или, если была инициирована пересылка вызова, то в МЦС, в который пересылается вызов. 2 с. и 7 з.п. ф-лы, 7 ил., 5 табл.
| US 5119397 A, 02.06.1992 | |||
| Система радиосвязи с подвижными объектами | 1983 |
|
SU1185625A1 |
| Автоматический огнетушитель | 0 |
|
SU92A1 |
| СТЕНД ДЛЯ ИСПЫТАНИЯ БАЛЛОНОВ ДЛЯ СЖИЖЕННЫХ ГАЗОВ | 0 |
|
SU332345A1 |
