Способ мобильной связи и система передачи информации, касающейся возможностей сети
Способ мобильной связей и система передачи информации между мобильным терминалом и элементом сети мобильной связи. Мобильный терминал передает информацию, касающуюся желательности и/или возможности поддерживать бесшовный роуминг (VCC), к элементу сети во время связи, и элемент сети принимает информацию от мобильного терминала, чтобы использовать информацию как основу для принятия решения о привязке вызова мобильного терминала. 2 н. и 14 з.п. ф-лы, 2 ил.
Область техники, к которой относится изобретение
Настоящее изобретение, в целом, относится к способам и системам мобильной связи. Более конкретно, но не для исключения, настоящее изобретение относится к передаче информации, касающейся возможностей сети передавать речевую информацию через часть сети с пакетной коммутацией, к услугам бесшовного роуминга и/или к передаче информации, касающейся способности терминала к поддержке.
Уровень техники
Общее описание VCC и его сопутствующих процедур происхождения вызова
Услуга бесшовного роуминга (VCC) Проекта партнерства 3-го поколения (3GPP) обеспечивает возможность передачи пути прохождения речевого вызова между доменом с коммутацией каналов, Circuit-Switched (CS) и доменами мультимедийных подсистем на базе протокола Интернет, Internet Protocol (IP) Multimedia Subsystem (IMS), и наоборот. Услуга предполагает наличие оборудования пользователя (UE), способного поддерживать две отдельные ветви вызова, связанные с одним и тем же соединением для речевого вызова (одна - через домен CS и одна - через домен IMS). Чтобы облегчить передачу вызовов между доменами, все речевые вызовы CS и IMS для оборудования пользователя, способного поддерживать VCC, привязываются к домену IMS абонента.
На фиг. 1 показана функциональная архитектура для VCC. Эта архитектура, показанная на фиг. 1, подобна существующей эталонной архитектуре 3GPP, в которой элемент функции управления бесшовным роумингом, Call Continuity Control Function, (CCCF) реализуется как прикладной сервер, Application Server, (AS) на базе протокола установления соединений, Session Initiation Protocol, (SIP). На момент написания не было согласовано, должны ли CCCF и функция выбора сетевого домена, Network Domain Selection, (NeDS) быть совмещены. Однако, фиг. 1 предполагает, что CCCF и NeDS совмещены и поэтому на чертеже показан только интерфейс управления услугами IMS, IMS Service Control, (ISC).
Оборудование пользователя регистрируется с помощью CCCF одновременно с регистрацией оборудования пользователя в IMS, следуя процедуре, определенной в 3GPP TS 23.288 для регистрации прикладного сервера с помощью критериев фильтров, установленных так, что регистрация 3-ей стороны требуется через интерфейс управления услугами IMS (ISC).
CCCF существует для каждого случая бесшовного роуминга в системе и управляет установлением ветвей вызова, требующихся для передачи вызова между доменами CS и IMS. Если оборудование пользователя вовлечено в многочисленные вызовы, все требующие VCC, то для каждого вызова существует отдельный CCCF.
Регистрация VCC
В течение и после процедуры регистрации IMS производится обмен информацией VCC между оборудованием пользователя и CCCF.
Он содержит:
от оборудования пользователя => CCCF
статус оборудования пользователя CS (отключенное, подключенное-в ожидании/ подключенное-активное)
предпочтения пользователя
от CCCF => оборудование пользователя
CCCF PSI и сопутствующий номер маршрута CS
политику оператора
Точный механизм обмена информацией пока еще не определен, но обмен информацией после регистрации, вероятно, должен быть обработан взаимным процессом SIP/уведомления, то есть, оборудование пользователя подписывается на информацию от CCCF и CCCF подписывается на информацию от оборудования пользователя. Каждый будет, в свою очередь, уведомляться после начальной подписки и по мере изменений информации.
Вызовы, исходящие из домена IMS
Во время исходящего вызова из домена IMS, SIP INVITE направляется через элемент функции управления сеансом вызова, Call Session Control Function, (CSCF) к CCCF, используя начальные критерии фильтрации. CCCF регистрирует событие вызова, например, назначает ссылочный номер вызова, и регистрирует маршрут, на котором следует оставаться при передаче сигнала пути прохождения вызова, и направляет вызов обратно к обслуживающему CSCF (S-CSCF) так, чтобы S-CSCF мог выполнить обработку завершения в доменах IMS/CS, как определено в 3GPP.TS 23.228. Привязка IMS вызовов VCC, исходящих из домена IMS, независима от того, является ли оборудование пользователя подключенным к CS или отключенным от него.
Если терминал неспособен поддерживать процедуры VCC, но пользователь является подписчиком на услуги VCC, отсутствие у терминала способности поддержки VCC может быть сообщено CCCF во время регистрации IMS. В этом случае CCCF может решить не привязывать вызов к IMS. Учитывая, что как S-CSCF, так и CCCF расположены в домашней сети пользователя, и что канал IMS обозначается конечными точками, является спорным, будет ли большая выгода в отсутствии привязки IMS вызова IMS, исходящего от абонента VCC.
Вызовы, исходящие из домена CS
Механизм, действующий по умолчанию, (только подмандатный механизм) для привязки IMS вызовов VCC, исходящих из домена CS, состоит в использовании переключений заказных приложений для улучшенной логики мобильных сетей, Customized Applications for Mobile network Enhanced Logic, (CAMEL) в посещаемом коммутируемом центре мобильной связи, Visited Mobile Switched Center, (VMSC). Это означает, что возможно привязывать вызовы, даже если оборудование пользователя не имеет регистрации IMS на момент начала вызова.
Если терминал неспособен поддерживать процедуры VCC, но пользователь является подписчиком на услуги VCC, CCCF для вызова не может знать об отсутствии у терминала способности поддерживать VCC, поскольку никакой обмен предварительной информацией VCC между оборудованием пользователя и CCCF был невозможен.
На фиг. 2 показан поток сообщений для вызовов VCC, исходящих из CS.
1.Сообщение SETUP управления вызовом посылается от оборудования пользователя к VMSC.
2. Переключение исходящей информации о подписке на CAMEL, Originating Camel Subscription Information, (O-CSI) в элементе функции коммутации обслуживания gsm Service Switching Function (SSF) в центре VMSC посылает сообщение InitialDP для функции gsmSCF CCCF.
3. CCCF создает мультимедийный номер маршрутизации по протоколу Интернет (IP) (IMRN), который gsmSCF возвращает в VMSC в сообщении CONNECT (CCCF отмечает информацию, требующуюся, чтобы закончить вызов вызываемого абонента).
4. VMSC направляет вызов в направлении MGCF в домашней сети IMS пользователя, используя IMRN.
5. MGCF инициирует SIP INVITE в направлении опрашиваемого CSCF, Interrogating CSCF (I-CSCF).
6. I-CSCF восстанавливает из домашнего сервера абонента, Home Subscriber Server, (HSS) CCCF, связанный с IMRN, и направляет дальше SIP INVITE.
7. CCCF прекращает входящую ветвь и инициирует исходящую ветвь в направлении первоначального вызываемого абонента, действуя как каскадно действующий агент пользователя, Back-to-Back User Agent, (B2BUA).
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Соответственно, настоящее изобретение было разработано, чтобы решить упомянутые выше проблемы и/или устранить упомянутые выше недостатки и обеспечить, по меньшей мере, описанные ниже преимущества. Особенность настоящего изобретения состоит в улучшении услуги бесшовного роуминга.
В соответствии с особенностью настоящего изобретения обеспечивается способ и система передачи информации между мобильным терминалом и элементом сети в сети мобильной связи. Мобильный терминал передает элементу сети информацию, касающуюся желательности и/или возможности поддержки бесшовного роуминга во время связи, и элемент сети принимает информацию от мобильного терминала, чтобы использовать информацию как основу для решения, привязывать ли вызов мобильного терминала или нет.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Приведенные выше и другие особенности, признаки и преимущества настоящего изобретения будут более понятны из последующего подробного описания, рассматриваемого совместно с сопроводительными чертежами, на которых:
Фиг.1 - схематическое представление функциональной архитектуры VCC, в которой может быть реализовано настоящее изобретение; и
Фиг.2 - схематическое представление потока сообщений для вызовов VCC, берущих начало из домена CS.
ПОДРОБНОЕ ОПИСАНИЕ ПРИМЕРОВ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
Примеры вариантов осуществления будут далее описаны подробно со ссылкой на приложенные чертежи. В нижеследующем описании подробное описание известных функций и конфигураций, включенных сюда, было опущено для ясности и краткости.
Выше дано общее описание регистрации бесшовного роуминга (VCC) и передачи вызова.
При описании процедуры вызовов VCC, исходящих из CS, технический отчет TR 23.806 заявляет:
"Если оборудование пользователя находится в месте, где VCC невозможен и/или нежелателен, gsmSCF дает команду центру VMSC на продолжение с использованием обычных процедур прохождения вызова."
Это подразумевает, что при некоторых обстоятельствах, зависящих от местоположения оборудования пользователя, CCCF не должен привязывать вызов к IMS.
Преимущества при отсутствии привязки являются следующими:
уменьшение ненужной передачи сигналов в сети (вызов, привязанный к IMS, всегда будет направляться к домену IMS вызываемого абонента, даже если он должен быть закончен в домене CS);
можно уменьшить время ожидания на установку соединения (благодаря сокращению передачи сигналов вызова);
возможность иметь более оптимизированную маршрутизацию вызова (по сравнению со случаем, когда вызов привязывается к IMS); и
можно в результате повысить качество речи для вызывающего абонента (из-за сокращения переключения кодека в плоскости пользователя).
Дополнительно, при условии, что VCC является услугой на подписной основе, возможно, что абонент VCC может использовать терминал, который не имеет возможностей для VCC (например, стандартный терминал 2G с универсальным модулем идентификации абонента, Universal Subscriber Identity Module, (USIM)). В этом случае использование VCC может быть невозможно, независимо от местоположения оборудования пользователя, поэтому будет желательно не привязывать к IMS никакие вызовы, сделанные этим терминалом.
Предложенная здесь идея стремится решить проблему, что хотя не всегда желательно привязывать к IMS вызов от абонента VCC, исходящий из CS, в настоящее время нет никакого механизма, позволяющего не иметь такую привязку. Предложение описывает механизм, посредством которого желательность/возможность использования VCC в пределах вызова сообщается обслуживающей сетью на оборудование пользователя через широковещательную передачу системной информации или во время передачи сигналов для регистрации, и сообщенные оборудованием пользователя в направлении сообщения CCCF в домашней сети через SETUP и InitialDP посылаются в момент установления соединения CS.
Необязательная привязка к IMS вызовов абонентов VCC, исходящих из CS
При описании процедуры для вызовов VCC, исходящих из CS, технический отчет TR 23.806 3GPP заявляет: "Если оборудование пользователя находится в месте, где VCC невозможен и/или нежелателен, gsmSCF дает команду центру VMSC на продолжение с использованием обычных процедур прохождения вызова."
Это подразумевает, что при некоторых обстоятельствах, зависящих от местоположения оборудования пользователя, gsmSCF в CCCF не должна привязывать вызов к IMS. Неясно, однако:
a) как CCCF, расположенный в домашней сети UE, может знать, находится ли оборудование пользователя в месте, где VCC возможен/желателен;
b) как оборудование пользователя может сообщить CCCF в своей домашней сети, находится ли оно в местоположении, где VCC возможен/желателен;
c) как оборудование пользователя может знать, находится ли оно в месте, где VCC возможен/желателен.
Как указывалось выше, преимущества отсутствия привязки состоят в следующем:
уменьшение ненужной передачи сигналов в сети (вызов, привязанный к IMS, всегда будет направляться к домену IMS вызываемого абонента, даже если он должен быть закончен в домене CS);
можно уменьшить время ожидания на установку соединения (благодаря сокращению передачи сигналов вызова);
возможность иметь более оптимизированную маршрутизацию вызова (по сравнению со случаем, когда вызов привязывается к IMS); и
можно в результате повысить качество речи для вызывающего абонента (из-за сокращения переключения кодека в плоскости пользователя).
Дополнительно, при условии, что VCC является услугой на подписной основе, возможно, что абонент VCC может использовать терминал, который не имеет возможностей для VCC (например, стандартный терминал 2G). В этом случае использование VCC может быть невозможно, независимо от местоположения оборудования пользователя, поэтому будет желательно не привязывать к IMS никакие вызовы, сделанные этим терминалом. Если оборудование пользователя не зарегистрировано IMS на момент установки соединения, у CCCF нет никакого способа, чтобы знать, является ли терминал вызывающего абонента VCC способным к поддержке процедуры VCC.
Учитывая вышесказанное, существуют, по меньшей мере, две проблемы, которые должны решаться при определении, привязывать ли к IMS вызов от абонента VCC, исходящий из CS.
1. Желательно ли использовать при вызове VCC. Это должно быть решено в CCCF, основываясь на предпочтениях абонента VCC и политике оператора домашней сети.
2. Возможно ли использовать VCC при вызове. Это зависит не только от местоположения. Для оборудования пользователя должна иметься возможность указать решение о возможности VCC, основанное на пригодности терминала к поддержке VCC. Кроме того, обслуживающая сеть должна иметь возможность указать, возможно ли использование VCC, основываясь, например, на ее способности поддерживать передачу речи по IP-протоколу (VoIP) через сеть с пакетной коммутацией (PS).
Оборудование пользователя может определить желательность/возможность VCC, основываясь на четырех факторах:
1. Возможности терминала VCC.
2. Предпочтение VCC у пользователя.
3. Возможность поддержки VoIP присоединенной сетью PS.
4. Доступность локальных сетей доступа к связям по протоколу IP, IP-Connectivity Access Networks, (IP-CAN) (например, активная точка беспроводной локальной сети (WLAN)).
В случае 3, сеть должна информировать оборудование пользователя о возможности поддержки сети по технологии VoIP. Это может быть сделано, например, через широковещательную информационную систему или во время обновления зоны маршрутизации или через систему пакетной радиосвязи общего пользования (GPRS), подключенную для передачи сигналов. Предпочтение пользователя VCC (случай 2) может быть привязано к доступности локальных сетей IP-CAN (случай 4), например, так чтобы вызовы, сделанные в зонах, где никакие подходящие сети IP-CAN не обнаружены, не могли привязываться.
Дополнительно, случаи 1 и 2 могут рассматриваться как полустатическая информация, которая не должна изменяться в течение продолжительности вызова, тогда как случаи 3 и 4 могут рассматриваться как динамическая информация, которая может изменяться по мере движения терминала в течение продолжительности вызова.
Сообщение от обслуживающей сети на оборудование пользователя о возможности/ желательности VCC
Чтобы помочь оборудованию пользователя решить, возможен ли VCC в его текущем местоположении, обслуживающая сеть может послать признак того, поддерживает ли она VoIP, через свой домен PS. После приема этой информации оборудование пользователя может принять решение, указать ли во время установления соединения на возможность/желательность привязки вызова к CCCF.
Ниже будут описаны другие применения концепции передачи оборудованию пользователя сигналов о способности сети к работе по технологии VoIP.
Введение информации в сигнальные сообщения Non-Access Stratum (NAS)
Информация может передаваться во время регистрации оборудования пользователя в сообщении Routing Update Accept или Attach Accept. Оба сообщения включают информационный элемент Network Feature Support, который имеет доступными два запасных бита (как описано в разделе 10.5.5.23 TS 24.008 3GPP). В этом случае информация могла быть привязана к индивидуальным абонентам, но ее разрешающая способность будет на уровне Location Area.
Введение информации в широковещательную передачу системной информации, System Information Broadcast
Информация может распространяться через широковещательную передачу системной информации, System Information Broadcast. Это должно обеспечить большую (на уровне ячеек) разрешающую способность и облегчить более динамичное управление локальным речевым трафиком между доменами PS и CS, но может быть неподходящим для индивидуальных абонентов.
Этот способ дополнительно распространяется на процедуры радиосети, Radio Network, которая передает системную информацию через специализированную передачу сигналов, например процедуры передачи UTRAN Mobility Information сети радиодоступа UMTS Radio Access Network.
Посылка информации на оборудование пользователя через неструктурированные дополнительные служебные данные (USSD)
Также должно быть возможно посылать на оборудование пользователя информацию о способности поддержки обслуживающей сетью технологии VoIP через USSD.
Посылка информации на оборудование пользователя через службу коротких сообщений (SMS)
Также должно быть возможно послать на оборудование пользователя информацию о способности поддержки обслуживающей сетью технологии VoIP через SMS.
Сообщение от оборудования пользователя к CCCF о возможности/желательности VCC
Чтобы CCCF/gsmSCF мог принять решение о привязке исходящего вызова CS от абонента VCC, оборудование пользователя должно послать признак того, является ли желательным/возможным поддержка VCC во время вызова.
Введение информации в Classmark 2
Одним из способов посылки признака того, желательна ли/возможна ли поддержка VCC во время вызова, может быть введение информации о возможности/желательности в сигнальное сообщение NAS между оборудованием пользователя и сетью, например, вызов уточнения местоположения и вызов обслуживания модуля конфигурации CM (Configuration Module). Classmark 2, как определено в 3GPP TS 24.008, посылается в этих сообщениях и имеет один запасной бит, доступный в каждом из октетов 3, 4 и 5. Информация о способности поддержки VCC может быть также предоставлена сети сети через процедуру изменения кода категории обслуживания (classmark), описанную в TS 44.108, раздел 3.4.10.
Classmark 2 автоматически вводится в сообщение InitialDP (смотрите сообщение 2 на фиг. 2), так что при приеме сообщения InitialDP gsmSCF в CCCF может проверить бит(-ы) возможности/желательности VCC и отреагировать соответственно, то есть, либо путем посылки сообщения CONNECT, содержащего IMRN, дающего команду VMSC на маршрутизацию вызова в направлении домена IMS пользователя для привязки, либо путем передачи сообщения продолжения, так чтобы вызов маршрутизировался обычным путем.
Настоящее изобретение предусматривает, что один или два бита из этих запасных битов должны использоваться для указания сети о возможности/желательности VCC. Если использовались два запасных бита, возможно указать отдельно, был ли возможен VCC (например, на основе способности терминала и/или предпочтении пользователя) и был ли VCC желателен (например, на основе доступности IP-CAN в зоне вызывающего оборудования пользователя во время установления соединения). В этом случае CCCF в домашней сети может принять решение, аннулировать ли признак, что VCC был нежелателен, и осуществить привязку вызова в случае, когда пользователь продолжает затем перемещаться в зоне покрытия соответствующей сети IP-CAN.
Classmark 2 может быть также расширен и способность оборудования пользователя поддерживать VCC указана в расширении в этом коде категории обслуживания, чтобы передача сигналов способности поддержки VCC не израсходовала все остающиеся запасные биты в коде категории обслуживания.
Введение информации в сообщение SETUP
Альтернативный способ достижения посылки признака желательности/возможности поддержки VCC во время вызова для оборудования пользователя может состоять во введении признака возможности/желательности VCC в сообщение SETUP, посланное как часть протокола управления соединениями (Call Control) в течение процедуры установления соединения (смотрите сообщение 1 в потоке сообщений на фиг. 2). GsmSSF в VMSC может затем ввести этот признак в сообщение InitialDP, посылаемое в направлении gsmSCF, в CCCF (смотрите сообщение 2 на фиг. 2), так чтобы он мог соответственно отреагировать, то есть, либо путем посылки сообщения CONNECT, содержащего IMRN, дающего команду VMSC на маршрутизацию вызова в направлении домена IMS пользователя для привязки, либо путем передачи сообщение продолжения, так чтобы вызов маршрутизировался обычным путем.
Протокол 3GPP Call Control определен в 3GPP TS 24.008. Формат сообщения SETUP в случае установления мобильного исходящего соединения показан в таблице 9.70a документа 3GPP TS 24.008. Одним из информационных элементов, содержащихся в сообщении SETUP от UE, является Call Control Capabilities (описанный в таблице 10.5.89 документа 3GPP TS 24.008). Цель этого информационного элемента состоит в том, чтобы идентифицировать способность управления трафиком мобильной станции. Информационный элемент имеет длину четыре октета. Он имеет один запасной бит в октете 3 и четыре запасных бита в октете 4. Когда в VMSC запущены услуги CAMEL, gsmSSF вводит часть информации из сообщения SETUP в сообщение InitialDP, посланное gsmSCF. Предложено, чтобы способность/возможность поддержки VCC была добавлена в InitialDP ниже InilialDPArgExtension, определенного в разделе 6.1.1 документа 3GPP TS 29.078.
Также предложено, чтобы один или два запасных бита могли использоваться, как описано выше.
Введение информации в Classmark 3
Дальнейшей альтернативой может быть введение информации VCC оборудования пользователя о возможности/желательности использования VCC в Classmark 3. В настоящее время эта информация не содержится в сообщении InitialDP, но могла бы быть добавлена таким же образом, как предложено выше для сообщения SETUP.
Введение информации в Classmark (2 или 3) и в сообщение SETUP
Чтобы облегчить процесс принятия решения CCCF, другая альтернатива может состоять во введении полустатической информации (смотрите выше) в код категории обслуживания (например, Classmark 2) и динамической информации в сообщении SETUP, посылаемое во время установления соединения. CCCF может затем выбрать, привязывать ли вызов, основываясь на том, была ли возможность/желательность поддержки VCC статической (то есть такой, что изменение в ходе вызова маловероятно) или динамической (то есть такой, что изменение в ходе вызова более вероятно/в зависимости от предпочтения/политики обслуживающей сети).
Передача информации на CCCF через GPRS
Если невозможно передать информацию на CCCF/gsmSCF через домен с коммутацией каналов, информация о возможности/ желательности поддержки VCC может быть сообщена непосредственно на CCCF, используя способы и процедуры, поддерживаемые в GPRS, и через использование протокола приложений для беспроводной связи, Wireless Application Protocol (WAP). В случае обращения к CCCF/GSMSCF непосредственно через GPRS, должен быть обеспечен адрес CCCF/gsmSCF, так чтобы оборудование пользователя могло направить способ GPRS на этот адрес. Этот адрес может быть в форме конкретного заранее определенного названия пункта доступа, Access Point Name (APN).
Если CCCF не принял от оборудования пользователя признак, что VCC возможен, он может принять решение не привязывать вызов. Это будет означать, что для оборудования пользователя, не поддерживающего VCC, вызов не может быть привязан, даже если оно использовало SIM абонента с VCC.
Передача информации на CCCF через SMS
Если невозможно передать информацию на CCCF/GSMSCF как часть обычной регистрации CCCF/gsmSCF или как часть обычной регистрации CS или передачи сигналов управления соединением, информация о возможности/желательности поддержки VCC может быть передана непосредственно на CCCF, используя SMS. В этом случае должен быть предоставлен адрес CCCF/gsmSCF, так чтобы оборудование пользователя могло направить СМ на этот адрес. Информация может быть, например, в форме числа Е164. Если CCCF не получил от оборудования пользователя признак, что VCC возможен, он может принять решение не привязывать вызов. Это должно означать, что оборудование пользователя, не поддерживающее VCC, не должно иметь привязанных вызовов, даже если оно использовало SIM подписчика на использование VCC.
Передача информации на CCCF через информационный вызов CS
Если невозможно передать информацию на CCCF/gsmSCF через IMS или как часть обычной регистрации CS или передачи сигналов управления сигналов управления вызовами, информация о возможности/желательности VCC может быть передана непосредственно на CCCF, используя информационный вызов CS. В этом случае должен быть предоставлен адрес CCCF/gsmSCF, так чтобы оборудование пользователя могло направить информационный вызов CS на этот адрес. Например, это может быть в форме номера Е164. Если CCCF не получил от оборудования пользователя признак, что FCC возможен, он может принять решение не привязывать вызов. Это должно означать, что оборудование пользователя, не поддерживающее FCC, не должно иметь привязанных вызовов, даже если оно использовало SIM подписчика на использование VCC.
Передача информации во время регистрации IMS на CCCF, используя тег признака
Когда IMS доступен, способность оборудования пользователя поддерживать VCC должна быть указана путем использования определенного тега признака, называемого +g.3gpp.vcc-capble, или тега с подобным индикативным названием. Если CCCF.gsmSCF не принимает такой признак способности оборудования пользователя поддерживать VCC, он может принять решение не привязывать вызов. Это должно означать, что оборудование пользователя, не поддерживающее VCC, не должно иметь привязанных вызовов, даже если оно использовало SIM подписчика на использование VCC.
Необязательная привязка IMS для вызовов, заканчивающихся в CS, исходящих из домена CS
Точно так же, как для вызовов с VCC, исходящих из CS, как описано выше, оборудование пользователя может включать информацию поддержки VCC в Classmark 2 или Classmark 3 для вызовов, заканчивающихся в CS, исходящих из домена CS. В этом случае решение о привязке принимается CCCF после приема сообщения InitialDP от GMSC, на который был маршрутизирован входящий вызов. Это является другим применением идеи о включении статической (смотрите ниже) информации о способности работы с VCC в Classmark 2 или в Classmark 3.
Далее будут описаны другие применения элементом сети передачи на мобильный терминал информации, касающейся способностей сети передавать речевую информацию через часть сети с пакетной коммутацией.
В основном, концепция сети 3GPP, являющейся способной сообщать о своей способности передачи речи на основе протокола IP, Voice over IP (VoIP), для ее сети с пакетной коммутацией, Packet Switched (PS), является основополагающей для терминала пользователя, способного решать, должен ли речевой вызов устанавливаться через домен с коммутацией каналов, Circuit Switched (CS), или через домен IMS. До редакции 6 стандарта 3GPP UMTS, VoIP не поддерживалась через домен IMS из-за сочетания недостаточной ширины полосы, доступной в сетях доступа, и неадекватного описания IMS. Начиная с редакции 6 с более полно охарактеризованной IMS и введения улучшенного доступа к пакетной передаче в восходящем звене связи, Enhanced Packet Uplink Packet Access, должно быть возможным поддерживать VoIP через IMS от сетей 3GPP IP-Connectivity Access Networks (IP-CAN). Однако по причинам управления трафиком некоторые сети могут иногда предпочесть не предлагать поддержку VoIP в сетях PS. В этом случае было бы желательно направлять речевые вызовы так, чтобы они проходили через домен CS. Это может быть достигнуто путем сообщения о способности сети PS к работе с VoIP.
Описанное выше применение является типовым применением для передачи сигналов о способности сети к работе с VoIP.
Другим возможным применением является рабочая позиция этапа 2 CSI (объединенные услуги CS и IMS, Combined CS and IMS), в настоящее время разрабатываемая группой по 3GPP, а также рабочие позиции улучшения IMS.
Этап 1 CSI предназначен для того, чтобы часть речевого вызова, Voice Call, всегда передавалась через домен CS. На этапе 1 CSI имеется только вызов CSI, обозначенный конечными точками, то есть оборудование пользователя обеих сторон должно быть способно поддерживать объединение сеансов связи CS и PS.
На этапе 2 CSI смысл заключается в том, что полностью подготовленное для работы с IMS оборудование пользователя в сети IMS, которое может поддерживать VoIP, будет проводить сеансы VoIP + передача данных на оборудовании пользователя, поддерживающем CSI. Таким образом, в то время, как одна сторона может работать по сценарию VoIP, другая сторона может использовать сеансы CS и PS.
Исходя из этого существует высокая вероятность, что на этапе 2 CSI такое оборудование пользователя, поддерживающее IMS, станет также оборудованием пользователя, способным работать с CSI.
Поскольку для оборудования пользователя, способного работать с IMS и CSI, чтобы сделать "разумный" выбор, инициировать ли сеансы VoIP + данные или инициировать вызов CSI, оборудование пользователя должно знать способность к работе с VoIP сети/LA/RA/элемента, оно в настоящее время регистрируется и выжидает.
Обратное также справедливо для оборудования пользователя, способного поддерживать CSI, делающего вызов на оборудование пользователя, которое полностью способно к работе как с IMS, так и CSI.
a. Независимо от того, находится ли это вызываемое оборудование пользователя в сети, поддерживающей VoIP, это может означать, что независимо от того, является ли вызов полностью под контролем сеансов связи IMS или если вызванное оборудование пользователя не находится в сети, поддерживающей VoIP, вызов может затем быть предложен как вызов CSI (то есть, с объединенными сеансами PS с вызовом CS). Таким образом, с этой точки зрения, способность оборудования поддерживать CSI должна быть известна не только NETWORK, но эта способность поддерживать VoIP в NETWORK, где вызываемое оборудование пользователя находится физически, также должна быть известна процессам вызова NE.
b. Даже если вызванное оборудование пользователя находится в сети, поддерживающей VoIP (или в части сети, поддерживающей VoIP), оборудованию пользователя может быть предоставлен выбор, закончить ли вызов через VoIP или через CSI. Для этого оборудование пользователя/пользователь должны знать, способна ли NETWORK (или эта часть NETWORK) поддерживать VoIP.
Чтобы дополнительно проиллюстрировать вышеупомянутый пункт, рассматривается следующий коммерческий аспект. Существует подогреваемое желание операторов NETWORK все больше и больше продвигаться к обеспечению услуг через домен PS. В этом направлении, очевидно, что операторы NETWORK будут пытаться продавать VoIP в максимально возможной степени и, вероятно, со скидкой в цене, чтобы стимулировать использование пользователями этой услуги. Пользователя, знающего, что он/она находится в физическом положении, которое позволяет работу с VoIP, можно убедить использовать VoIP вместо создания домена Voice Call over CS. Таким образом, необходимость в указании способности NETWORK/LA/RA/элемента поддерживать VoIP состоит в том, чтобы оборудование пользователя было физически зарегистрировано или выжидало.
Хотя настоящее изобретение было показано и описано со ссылкой на определенные примеры его осуществления, специалистам в данной области техники должно быть понятно, что в них по форме и в деталях могут быть внесены различные изменения без отхода от сущности и объема настоящего изобретения, как они определены в прилагаемой формуле изобретения и ее эквивалентах. Должно быть понятно, что описанные выше варианты осуществления представлены только для примера и в объеме прилагаемой формулы изобретения возможны многочисленные изменения или модификации.
1. Способ передачи информации между мобильным терминалом и элементом сети мобильной сети, содержащий этапы, на которых:
передают информацию, касающуюся желательности и/или возможности поддерживать бесшовный роуминг (VCC), от мобильного терминала к элементу сети в течение связи;
принимают информацию в элементе сети и
принимают решение о привязке вызова мобильного терминала, основываясь на принятой информации.
2. Способ по п.1, в котором желательность и/или возможность поддержки бесшовного роуминга основывается на одном или более следующих факторах:
i) способность мобильного терминала к работе с VCC;
ii) предпочтение пользователем VCC;
iii) способность подключенной сети с пакетной коммутацией (PS) поддерживать технологию передачи речи по IP-протоколу, Voice over Internet Protocol (VoIP); и
iv) доступность местных сетей IP-Connectivity Access Network (IP-CAN).
3. Способ по п.2, содержащий также этап информирования мобильного терминала о способности элемента сети поддерживать VoIP.
4. Способ по п.3, в котором информация содержится, по меньшей мере, в сообщении Non-Access Stratum (NAS) или classmark 2 или сообщении установки или classmark 3.
5. Способ согласно любому из предшествующих пунктов, в котором информация передается от подвижного терминала к элементу с функциями управления сеансами и маршрутизацией, Call Continuity Control Function (CCCF).
6. Способ по п.1, в котором упомянутая информация передается от мобильного терминала одним из следующих способов:
используя систему пакетной радиосвязи общего пользования, General Packet Radio Service (GPRS);
используя домен с коммутацией пакетов, Packet-Switched (PS);
используя механизм уведомления протокола инициирования сеансов, Session Initiation Protocol (SIP) Notify;
используя механизм идентификатора услуг связи, Communication Service ID;
используя службу коротких сообщений, Short Messaging Service (SMS); или
используя информационный вызов домена с коммутацией каналов, Circuit Switced (CS).
7. Способ по п.1, содержащий также
элемент сети, обеспечивающий мобильный терминал адресом элемента сети.
8. Способ по п.2, содержащий также
информацию, касающуюся способности мобильного терминала к работе с VCC во время регистрации в мультимедийной подсистеме на основе протокола Интернет, Internet Multimedia Subsystem (IMS), или используя тег признака. (IMS).
9. Система передачи информации в мобильных сетях связи, содержащая: мобильный терминал для передачи информации, касающейся желательности и/или возможности поддерживать бесшовный роуминг, Voice Call Continuity (VCC), во время связи; и
элемент сети для приема информации от мобильного терминала и принятия решения о привязке вызова мобильного терминала на основе принятой информации.
10. Система по п.9, в которой информация, касающаяся желательности и/или возможности поддержки VCC, основана на одном или более следующих факторов:
i) способность терминала поддерживать VCC;
ii) предпочтение пользователя VCC;
iii) способность подключенной сети с пакетной коммутацией (PS) поддерживать технологию передачи речи по IP-протоколу, Voice over Internet Protocol (VoIP); и
iv) доступность местных сетей IP-Connectivity Access Network (IP-CAN).
11. Система по п.10, содержащая также
элемент сети для информирования мобильного терминала о способности поддерживать VoIP.
12. Система по п.9, в которой информация содержится, по меньшей мере, в сигнальном сообщении Non-Access Stratum (NAS) или classmark 2 или сообщении установки или classmark 3.
13. Система по п.9, в которой информация передается от мобильного терминала к элементу с функциями управления сеансами и маршрутизацией (CCCF).
14. Система по п.9, в которой упомянутая информация передается от мобильного терминала одним из следующих способов:
используя систему пакетной радиосвязи общего пользования, General Packet Radio Service (GPRS);
используя домен с коммутацией пакетов, Packet-Switched (PS);
используя механизм уведомления протокола инициирования сеансов, Session Initiation Protocol (SIP) Notify;
используя механизм идентификатора услуг связи, Communication Service ID;
используя службу коротких сообщений, Short Messaging Service (SMS); или
используя информационный вызов домена с коммутацией каналов, Circuit Switced (CS).
15. Система по п.11, в которой элемент сети обеспечивает мобильный терминал адресом элемента сети.
16. Система по п.10, в которой информация, касающаяся способности терминала к работе с VCC, передается во время регистрации в мультимедийной подсистеме на основе протокола Интернет, Internet Multimedia Subsystem (IMS), или используя тег признака.
