Возврат в сеть с коммутацией каналов

Изобретение относится к беспроводной связи. Технический результат заключается в обеспечении возврата в сеть с коммутацией каналов (CSFB) для оборудования пользователя (UE). Объект управления мобильностью (ММЕ) принимает от UE индикатор оптимизированной характеристики CSFB. ММЕ принимает тип запрашиваемой услуги, ассоциированный с UE. ММЕ инициирует передачу обслуживания с непрерывностью одиночного голосового радиовызова (SR-VCC) режима для UE в сеть с коммутацией каналов на основе оптимизированной характеристики CSFB для UE. ММЕ передает сообщение запроса протокола приложения S1 (S1-АР) в развернутый узел В (eNB). Сообщение S1AP может включать в себя индикатор оптимизированной характеристики CSFB и индикатор непрерывности одиночного голосового радиовызова (SRVCC) для UE. ММЕ принимает от UE сообщение запроса передачи обслуживания. 3 н. и 21 з.п. ф-лы, 7 ил.

 

Уровень техники

В технологии беспроводной мобильной связи используются различные стандарты и протоколы для передачи данных между узлом (например, станцией передачи) и беспроводным устройством (например, мобильным устройством). Некоторые беспроводные устройства выполняют обмен данными, используя множественный доступ с ортогональным частотным разделением каналов (OFDMA) при передаче по нисходящему каналу передачи (DL) и множественный доступ с частотным разделением одной несущей (SC-FDMA) при передаче по восходящему каналу передачи (UL). Стандарты и протоколы, в которых используется мультиплексирование с ортогональным частотным разделением (OFDM) для передачи сигналов, включают в себя Долгосрочное развитие (LTE) Проекта партнерства третьего поколения (3GPP), стандарт 802.16 Институт инженеров по электротехнике и радиоэлектронике (IEEE) (например, 802.16e, 802.16m), который известен для промышленных групп, как WiMAX (Общемировая совместимость широкополосного беспроводного доступа), и стандарт 802.11 IEEE, который обычно известен для промышленных групп как WiFi.

В сети радио доступа (RAN) 3GPP систем LTE узел может представлять собой комбинацию узла BS Развернутой универсальной наземной сети радиодоступа (e-UTRAN) (также обычно обозначаемого как развернутый Node В, расширенный Node В, eNodeB или eNB) в контроллерах радиосети (RNC), которые сообщаются с беспроводным устройством, известным, как оборудование пользователя (UE). При передаче по нисходящему каналу (DL) передача может представлять собой передачу данных из узла (например, eNodeB) в беспроводное устройство (например, UE), и передача по восходящему каналу передачи (UL) может представлять собой передачу данных из беспроводного устройства в узел.

Краткое описание чертежей

Свойства и преимущества раскрытия будут понятны из подробного описания, которое представлено ниже, которое следует рассматривать совместно с приложенными чертежами, которые вместе иллюстрируют, в качестве примера, свойства раскрытия; и на которых:

фиг. 1 - показана процедура усовершенствованной технологии перевода входящего вызова на мобильный терминал (МТ) в режим с коммутацией каналов (eCSFB) в соответствии с примером;

фиг. 2 - показана процедура усовершенствованной технологии перевода вызова, инициированного мобильным терминалом (МО) в режим с коммутацией каналов (eCSFB) в соответствии с примером;

фиг. 3 - показана процедура усовершенствованной технологии перевода в режим с коммутацией каналов (eCSFB), которая включает в себя поддержание непрерывности одиночного голосового радиовызова (SRVCC) в соответствии с примером;

фиг. 4 - представлена функция объекта администрирования мобильностью (ММЕ), который во время работы способствует возврату в режим с коммутацией каналов (CSFB) для оборудования пользователя (UE), в соответствии с примером;

фиг. 5 - представлена функция развернутого узла В (eNB) который во время работы способствует возврату в режим с коммутацией каналов (CSFB) для оборудования пользователя (UE), в соответствии с примером;

фиг. 6 - представлена блок-схема последовательности операций способа, который способствует возврату в режим с коммутацией каналов (CSFB) для оборудования пользователя (UE), в соответствии с примером; и

фиг. 7 показана схема беспроводного устройства (например, UE) в соответствии с примером.

Далее будет сделана ссылка, например, на примерные варианты осуществления, и конкретная технология будет использоваться здесь для их описания. Тем не менее, следует понимать, что таким образом, не предполагается никаких ограничений в отношении объема изобретения.

Подробное описание изобретения

Перед тем, как настоящее изобретение будет раскрыто и описано, следует понимать, что данное изобретение не ограничено раскрытыми здесь конкретными структурами, этапами обработки или материалами, но оно расширяется на его эквиваленты, которые будут понятны для специалистов в соответствующих областях техники. Следует также понимать, что используемая здесь терминология используется с целью описания только конкретных примеров и не предназначена для ограничения. Одинаковые номера ссылочных позиций на разных чертежах представляют одинаковый элемент. Номера, представленные в блок-схемах последовательности операций и для описания обработки, представлены для ясности при описании этапов и операций и не обязательно обозначают конкретный порядок или последовательность.

Примерные варианты осуществления

Исходный обзор вариантов осуществления технологии представлен ниже, и затем конкретные варианты осуществления технологии будут более подробно описаны дополнительно. Такое исходное краткое описание предназначено для того, чтобы помочь читателям быстрее понять технологию, но не предназначено для идентификации ключевых свойств или существенных свойств технологии, и при этом это не предназначено для ограничения объема заявленного предмета изобретения.

Описана технология, которая способствует возврату в режим с коммутацией каналов (CSFB) для оборудования пользователя (UE). Объект администрирования мобильностью (ММЕ) может принимать оптимизированный индикатор возможностей CSFB из UE, который определяет оптимизированную возможность CSFB этого UE. ММЕ может принимать индикатор оптимизированной возможности CSFB из UE через приложенное сообщение запроса, сообщение запроса обновления области отслеживания (TAU), или сообщение запроса расширенной услуги. В другом примере ММЕ может идентифицировать оптимизированный индикатор возможности CSFB на основе обновления сообщения о подтверждении местоположения, которое принимают из опорного абонентского сервера (HSS), сообщение подтверждения обновления местоположения, включающее в себя профиль абонента UE, который обозначает оптимизированную возможность CSFB этого UE. Индикатор оптимизированных возможностей CSFB может быть установлен в "0", для обозначения того, что UE не поддерживает CSFB на основе SRVCC, или в "1", для обозначения того, что UE поддерживает CSFB на основе SRVCC. Кроме того, ММЕ может принимать запрашиваемый тип услуги, ассоциированный с UE. В одном примере ММЕ может принимать запрашиваемый тип услуги из центра коммутации мобильной связи (MSC) через сообщение пейджингового запроса. Запрашиваемый тип услуги может представлять собой один из следующего: голосовые данные, видеоданные, неструктурированные данные вспомогательной услуги (USSD), услугу определения местоположения (LCS) или неизвестный.

ММЕ может инициировать передачу UE в сеть с коммутацией каналов при поддержании непрерывности одиночного голосового радиовызова (SRVCC) на основе оптимизированных возможностей CSFB UE. ММЕ может передавать сообщение запроса протокола приложения S1 (S1-АР) в развернутый узел В (eNB), в котором сообщение запроса S1-АР включает в себя индикатор возможности оптимизированного CSFB и индикатор непрерывности одиночного голосового радиовызова (SRVCC) для UE, в котором ММЕ выбирает индикатор SRVCC на основе запрашиваемого типа услуги. Индикатор SRVCC уведомляет eNB в отношении того, следует или нет инициировать SRVCC/video SRVCC (vSRVCC), в котором индикатор SRVCC равен "0", для обозначения для eNB, что не ожидается SRVCC/vSRVCC или традиционный CSFB, при котором индикатор SRVCC, равный "1", обозначает для eNB, что ожидается SRVCC, в котором индикатор SRVCC, равный "2", обозначает для eNB, что ожидается vSRVCC. ММЕ может принимать требуемое сообщение на передачу режима из eNB, в котором eNB конфигурируют для передачи сообщения, требуемого для перевода режима в ММЕ, когда перевод режима UE SRVCC в сеть с коммутируемыми каналами инициируется сетью с коммутируемыми пакетами, на основе частично оптимизированного индикатора о возможностях CSFB и индикатора SRVCC. Процедура перевода режима из сети с коммутацией пакетов в цепь с коммутацией каналов (PS-CS) может быть инициирована, даже когда отсутствует носитель CQI=1, ассоциированный с UE.

Возврат в режим с коммутацией каналов (CSFB) представляет собой технологию, с помощью которой голосовые услуги и услуги коротких сообщений (SMS) доставляют в устройство LTE, используя Глобальную систему мобильной связи (GSM) или другую сеть с коммутацией каналов. Другими словами, даже при том, что устройство LTE позволяет принимать передаваемые данные из сети с коммутацией пакетов, устройства LTE переключаются обратно или выполняют возврат к сети с коммутацией каналов. В общем, сети с коммутацией пакетов являются более новыми и могут обеспечивать расширенные возможности по сравнению с более старыми сетями с коммутацией каналов. Сети с коммутацией пакетов представляют собой сеть на основе пакетов и все сети Протокола Интернет (IP). Пакеты могут быть переданы по адресу места назначения и при приеме пакеты повторно компонуют для формирования сообщения. С другой стороны, в сети с коммутацией каналов используются специально установленные соединения из точки в точку во время голосовых вызовов. Когда устройство LTE перемещается в пределах сети с коммутацией каналов (в противоположность сети с коммутацией пакетов), устройство LTE может завершать голосовые вызовы путем возврата к сети с коммутацией каналов (например, сети 2G или 3G). Когда устройство LTE возвращается обратно к сети с коммутацией пакетов, устройство LTE может вернуться к использованию сети с коммутацией пакетов, принятой по умолчанию. Поэтому, CSFB обеспечивает устройства LTE с возможностью использования старых сетей с коммутацией каналов, когда более новые сети с коммутацией пакетов недоступны в текущем местоположении устройства LTE.

Непрерывность одиночного голосового радиовызова (SRVCC) представляет собой схему, которая обеспечивает передачу режима из режима передачи пакетных данных в режим передачи данных голосового вызова с коммутацией каналов. SRVCC позволяет без стыков переводить вызовы в области передачи пакетов по LTE в старые системы голосового вызова с коммутацией каналов, такие как GSM, Универсальная мобильная система телекоммуникаций (UMTS) или Множественный доступ с кодовым разделением каналов (CDMA). Другими словами, SRVCC обеспечивает возможность перевода голосового вызова из режима "голос по IP" (VoIP) или из области мультимедийной подсистемы IP (IMS) в старую сеть (например, в сеть с коммутацией каналов). Сетевые операторы используют SRVCC для выполнения перевода режима при поддержании качества услуги (QoS) и для обеспечения приемлемой непрерывности вызова экстренных вызовов.

Перевод из сети LTE в старую сеть (например, сеть с коммутацией каналов) может происходить, когда мобильное устройство движется за пределы области охвата LTE. Когда UE, выполненное с возможностью SRVCC, через которое выполняется голосовой вызов, определяет, что UE движется за пределы области охвата LTE, UE уведомляет сеть LTE об этом. Сеть LTE определяет, что голосовой вызов должен быть переведен в старую сеть. Сеть LTE уведомляет сервер центра коммутации мобильной связи (MSC) о необходимости переключения голосового вызова из области пакетной передачи в область коммутации каналов и инициирует передачу режима голосового носителя LTE в старую сеть. Сервер MSC устанавливает путь носителя для UE в старой сети и уведомляет ядро IMS, что голосовой вызов UE перемещается из области пакетной передачи в область коммутации каналов. Когда UE прибывает в старую сеть, UE переключает свою внутреннюю обработку голоса, например, a VoIP на традиционную передачу голоса по каналу, и голосовой вызов продолжается. Когда UE возвращается обратно в область услуги LTE, голосовой вызов переводят обратно в сеть LTE аналогичным образом.

В процедуре передачи видеоданных SRVCC (vSRVCC) в традиционной сети, как определено в Технической спецификации 3GPP (TS) 23.213 секция 6.2.2, радио и сетевые ресурсы для голосового вызова UE или видеовызова в целевой сети радиодоступа (RAN) могут быть выделены, когда сервер MSC принимает SRVCC сообщение запроса на перевод из режима с коммутацией пакетов (PS) в режим с коммутацией каналов (CS). Когда UE принимает передачу режима (НО) из сообщения-команды e-UTRAN, UE знает, что радио- и сетевые ресурсы для голосового вызова или видеовызова были зарезервированы в целевой RAN. Поэтому, когда UE настраивается на целевую RAN, UE может пропустить процедуру выделения радиоресурса с целевой RAN, что позволяет сэкономить время и ресурсы во время VSRVCC.

В представленном выше решении, когда e-UTRAN принимает протокол приложения S1 (S1AP) с индикатором CSFB из объекта администрирования мобильностью (ММЕ), EUTRAN может анализировать развернутый пакетный носитель системы (EPS) этого UE для определения, присутствует ли носитель CQI=1. Если носитель CQI=1 отсутствует, EUTRAN не инициирует процедуру SRVCC, тогда как EUTRAN инициирует процедуру SRVCC, в случае присутствия носителя CQI=1.

В другом известном решении введена улучшенная или оптимизированная процедура CSFB, которая комбинирует CSFB и SRVCC. В этом решении носитель EPS CQI=1 совершенно отсутствует для UE. Если EUTRAN не знает, поддерживает ли UE расширенный CSFB при приеме сообщения S1-АР (с индикатором CSFB) из ММЕ, EUTRAN не инициирует процедуру SRVCC. Однако, в предыдущем решении, сетевые элементы (например, ММЕ) не знают, поддерживает ли UE расширенный CSFB или только существующий CSFB. Поэтому, настоящая технология описывает информирование сетевых элементов (например, ММЕ и eNB) с расширенными возможностями CSFB для UE.

Поскольку отсутствует носитель № CQI=1 для eNB в другом известном решении, eNB может запрашивать выделение ресурсов для голосовых вызовов в сообщении запроса перевода режима в целевую RAN. eNB может запрашивать выделение ресурсов для голосовых вызовов по умолчанию. Другими словами, расширенная процедура CSFB в другом известном решении предполагает, что процедура SRVCC используется только для голосовых вызовов и не учитывает другие услуги, такие как видеовызовы, услуги по определению местоположения (LC) или данные неструктурированной вспомогательной услуги (USSD). Если UE запрашивает vSRVCC (то есть, видеовызов в противоположность голосовому вызову), когда UE настраивается на целевую RAN, назначенный носитель TS 11 для голосового вызова не может использоваться для видеовызова. Другими словами, носитель TS 11 назначают для UE, но, тем не менее, он не может использоваться. В этом случае UE может синхронизироваться с целевой RAN для выделения ресурсов, но такая дополнительная передача сигналов может привести к потере времени и радиоресурсов. Аналогично, если UE запрашивает LC или USSD, выделение носителя TS 11 не совместимо с этими двумя видами услуг. В результате, выделение носителя TS 11 по умолчанию в этих ситуациях приводит к напрасной растрате радиоресурсов в целевой RAN.

Как более подробно описано ниже, для устранения неправильного выделения ресурсов для целевой RAN во время улучшенной или оптимизированной процедуры CSFB (то есть, комбинация CSFB и SRVCC), сетевой элемент (например, ММЕ или eNB) может определять запрашиваемый тип услуги для UE. Запрашиваемый тип услуги может включать в себя голосовую связь, передачу видеоданных, LCS или USSD. В одном примере UE может непосредственно информировать UE о запрашиваемом типе услуги, когда расширенная процедура CSFB поддерживается UE. Когда сетевой элемент идентифицирует тип запрашиваемой услуги UE, которое инициирует расширенную процедуру CSFB, сетевой элемент может запрашивать в целевой RAN точное выделение ресурсов (то есть, выделение ресурсов, которое соответствует запрашиваемому типу услуги UE). В результате, можно исключить неправильное выделение ресурсов (то есть, выделение ресурсов, которое не совместимо с запрашиваемым типом услуги UE) и выделение ресурсов не требует повторного согласования после настройки UE на целевую RAN.

Для возврата в режим с коммутацией каналов (CSFB) с входящим мобильным вызовом (МТ) центр коммутации мобильной связи (MSC) может идентифицировать точный тип услуги по входящим данным или по входящему вызову, и не назначает неправильный носитель с коммутацией каналов (CS) для оборудования пользователя (UE). В пейджинговом сообщении запроса, передаваемом из MSC в объект администрирования мобильностью (ММЕ), может быть включен точный тип услуги (например, голосовые данные, видеоданные, USSD, LC или неизвестный). Поэтому, ММЕ может определять точный тип услуги, который инициирует CSFB на основе пейджингового сообщения запроса, принятого из MSC. Когда ММЕ определяет точный тип услуги, может быть воплощено либо первое решение для МТ eCSFB, или второе решение для МТ eCSFB, как описано более подробно ниже.

В первом решении ММЕ может передавать сообщение протокола приложения S1 (S1-АР) с индикатором CSFB в развернутый узел В (eNB) после приема пейджингового сообщения запроса с точным типом услуги из MSC. Индикатор CSFB может уведомлять eNB о том, что для UE требуется CSFB. Когда eNB принимает сообщение S1-АР с индикатором CSFB из ММЕ, eNB может определять, следует или нет инициировать процедуру SRVCC для голоса в соответствии с индикацией возможностей SRVCC UE в индикаторе группы свойства (FGI). eNB может принимать FGI непосредственно из UE. Если UE выполнено с возможностью SRVCC, eNB может инициировать процедуру SRVCC путем передачи требуемого сообщения мобильного терминала в ММЕ. Когда ММЕ принимает требуемое сообщение о передаче режима из eNB, если запрашиваемый тип услуги представляет собой голосовую услугу, ММЕ (также называется ММЕ источника) может инициировать процедуру перевода режима с коммутации пакетов (PS) на коммутацию каналов (CS) для голосового запроса, путем передачи сообщения запроса SRVCC PS в CS в MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN прозрачный контейнер из источника в цель, контексты ММ, показатель аварийного вызова и индикатор CSFB. Сервер MSC может перейти к процедуре SRVCC для подготовки ресурсов для передачи голоса помимо сигналов. Если запрашиваемый тип услуги представляет собой передачу видеоданных, ММЕ источника может инициировать процедуру перевода режима PS-CS для запрашиваемого видеовызова, путем передачи в MSC сообщения запроса SRVCC PS в CS. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB и флаг vSRVCC. Сервер MSC может перейти к процедуре vSRVCC для подготовки ресурсов для видеоданных, помимо передачи сигналов. Если запрашиваемый тип услуги является другим, чем голосовые данные или видеоданные, ММЕ источника может передавать сообщение запроса SRVCC PS в CS, в сервер MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB и "ни голоса, ни видео". Сервер MSC может перейти к ненормальной процедуре SRVCC, для подготовки ресурсов для передачи сигналов.

Во втором решении, в соответствии с принятым типом услуги пейджингового сообщения запроса, ММЕ может использовать новый индикатор SRVCC для уведомления eNB о том, следует ли инициировать SRVCC/vSRVCC или нет. В качестве неограничительных примеров, новый индикатор SRVCC может быть равен "0" для обозначения того, что не ожидаются ни SRVCC/vSRVCC, ни обычный CSFB, "1" для обозначения, что ожидается SRVCC, или "2", для обозначения, что ожидается vSRVCC. eNB может выполнить специфичное действие на основе индикатора SRVCC, включенного в сообщение S1-АР. Например, если ожидается SRVCC, eNB может инициировать процедуру SRVCC, как дополнительно определено в 3GPPTS 23.216. Если ожидается vSRVCC, eNB может инициировать процедуру vSRVCC, как дополнительно определено в 3GPPTS 23.216. Если не ожидается ни SRVCC/vSRVCC, ни традиционный CSFB, eNB может перейти к традиционному CSFB, как дополнительно определено в 3GPP TS 23.272, секции 6.2, 6.3 и 6.4. Когда ММЕ принимает сообщение требования перевода режима из eNB, если запрашиваемый тип услуги представляет собой голосовую услугу, ММЕ источника может инициировать процедуру передачи PS-CS для голосового запроса путем передачи сообщения запроса SRVCC PS в CS, в сервер MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, показание аварийной ситуации и индикатор CSFB. Сервер MSC может перейти к процедуре SRVCC для подготовки ресурсов для голосового вызова, помимо сигналов. Если запрашиваемый тип услуги представляет собой передачу видеоданных, ММЕ источника может инициировать процедуру перевода режима PS-CS для запрашиваемого видеовызова, путем передачи сообщения запроса SRVCC PS в CS, в сервер MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB и флаг vSRVCC. Сервер MSC может перейти к процедуре vSRVCC, для подготовки ресурсов для передачи сигналов, помимо видеоданных.

На фиг. 1 иллюстрируется пример процедуры усовершенствованной технологии перевода входящего вызова на мобильный терминал в режим с коммутацией каналов (МТ) (eCSFB). В частности, со ссылкой на фиг. 1, может быть описано первое решение для МТ eCSFB или второе решение для МТ eCSFB, как описано выше.

Что касается первого решения для МТ eCSFB, на этапе 1а, центр 110 коммутации мобильной связи (MSC), обеспечивающий непрерывность одиночного голосового радиовызова (SRVCC), может передавать пейджинговое сообщение запроса в объект 108 администрирования мобильностью (ММЕ) через интерфейс SG. Пейджинговое сообщение запроса может включать в себя тип услуги, такой как голосовая услуга, передача видеоданных, услуга определения местоположения (LCS), неструктурированные вспомогательные данные услуги (USSD), или неизвестный. Если оборудование 102 пользователя (UE) находится в подключенном режиме, ММЕ 108 может передавать в UE 102 пейджинговое сообщение - уведомление CS. Если UE 102 находится в режиме ожидания, ММЕ 108 может передавать пейджинговое сообщение в каждый eNodeB 104, и eNodeB 104 может перенаправлять пейджинговое сообщение в UE 102.

Если UE 102 находится в режиме ОЖИДАНИЯ, ММЕ 108 может передавать сообщение запроса услуги SG в MSC 110, содержащий показатель того, что UE 102 находилось в режиме ОЖИДАНИЯ. Когда MSC 110 принимает сообщение запроса услуги SG, MSC 110 может прекратить повторную передачу пейджингового сообщения интерфейса SG.

Если UE 102 находится в режиме ПОДКЛЮЧЕНО, ММЕ 108 может передавать сообщение запроса услуги SG в MSC 110, содержащий показатель, что UE 102 находится в подключенном режиме. MSC 110 может использовать такой показатель режима подключено для начала перенаправления вызовов по таймеру без ответа в UE 102, и MSC 110 должен передавать индикацию предупреждения пользователя для вызывающей стороны. Когда MSC 110 принимает сообщение запроса услуги SG, MSC 110 может прекратить повторную передачу пейджингового сообщения интерфейса SG.

На этапе 1b UE 102 может передавать расширенное сообщение запроса услуги в ММЕ 108 для возврата CS из мобильного терминала (CSFB). Расширенное сообщение запроса на услугу может быть инкапсулировано в сообщениях управления радиоресурсом (RRC) и протокола приложения S1 (S1-AP).

На этапе 1c ММЕ 108 может передавать сообщение запроса S1-АР в eNodeB 104, которое включает в себя индикатор возврата к CS. Индикатор CSFB уведомляет eNodeB 104 о том, что для UE 102 требуется CSFB. Сообщение запроса S1-АР может включать в себя точный тип услуги (например, передачу голосовых данных, видеоданных, USSD, LC, неизвестный).

На этапе 2а, eNodeB 104 может, в случае необходимости, запрашивать отчет об измерениях из UE 102 для определения целевой соты Универсальной наземной сети радиодоступа (UTRAN) или целевой соты сети Глобальной системы мобильной связи (GSM) с повышенной скоростью передачи данных для сети радиодоступа - развития GSM (GERAN), для которой должен был выполняться перевод режима пакетной коммутации (PS).

На этапе 2b, на основе отчетов об измерениях UE, индикатора возврата к CS на этапе 1c и возможностей SRVCC UE, Е UTRAN источника может определять инициировать передачу режима SRVCC в UTRAN/GERAN с помощью сообщения о требуемой передаче режима в ММЕ 108.

На этапе 2c, когда ММЕ 108 принимает сообщение о требуемой передаче режима из eNB 104, если запрашиваемый тип услуги представляет собой передачу голосовых услуг, ММЕ 108 источника может инициировать процедуру перевода режима из коммутации пакетов (PS) на коммутацию каналов (CS) для запроса передачи голоса путем передачи сообщения запроса SRVCC PS в CS в сервере 110 MSC. Сообщение запроса SRVCC PS в CS может включать в себя международную идентичность мобильного абонента (IMSI), целевой идентификатор (ID), номер передачи сеанса для SRVCC (STN-SR), номер корреляции цифровых интегрированных услуг сети мобильной станции (ISDN) (C-MSISDN), прозрачный контейнер из источника в цель, контекст ММ, индикацию экстренной ситуации и индикатор CSFB. Если запрашиваемый тип услуги представляет собой передачу видеоданных, ММЕ 108 источника может инициировать процедуру перевода режима PS-CS для запрашиваемого видеовызова, путем передачи сообщения запроса SRVCC PS в CS, в сервер 110 MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB и флаг vSRVCC.

Если запрашиваемый тип услуги представляет собой другой, чем голосовые данные или видеоданные, ММЕ 108 источника может передавать сообщение запроса SRVCC PS в CS, в сервер 110 MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB, и "не голосовые и не видеоданные". ММЕ 108 не требуется удалять носитель QCI=1, поскольку процедура SRVCC выполняется в соответствии с CSFB и при этом отсутствует носитель QCI=1.

На этапе 2D, когда сервер 110 MSC принимает сообщение запроса SRVCC PS в CS, сервер 110 MSC может идентифицировать тип услуги, который инициирует eCSFB. Если тип услуги представляет собой передачу голосовых данных, сервер 110 MSC может продолжить процедуру SRVCC для подготовки ресурсов для передачи голосовых данных. Если тип услуги представляет собой передачу видеоданных, сервер 110 MSC может перейти к процедуре vSRVCC для подготовки ресурсов для видеоданных, помимо передачи сигналов. Если тип услуги представляет собой "не голосовые данные и не видеоданные", сервер MSC 110 может перейти к ненормальной процедуре SRVCC для подготовки только ресурсов сигналов. Поскольку SRVCC выполняется в соответствии с CSFB, SRVCC MSC 110 не инициирует процедуру переноса сеанса в IMS и только инициирует подготовку к традиционному переводу режима CS. Если SRVCC MSC 110 не представляет собой целевой MSC 112, тогда SRVCC MSC 110 может взаимодействовать с запросом на передачу режима PS-CS, с запросом на передачу CS через MSC путем передачи сообщения запроса на подготовку к передаче режима в целевой MSC 112.

На этапе 2е сервер 110 MSC может передавать сообщение ответа SRVCC PS в CS (прозрачный контейнер из цели в источник) в ММЕ 108 источника.

На этапе 2f, ММЕ 108 источника может передавать сообщение-команду на передачу режима (прозрачный контейнер из цели в источник) в источник e-UTRAN (или eNodeB 104) и затем в UE 102. Сообщение-команда на передачу режима может включать в себя информацию о голосовом компоненте.

На этапе 2g UE 102 может передавать сообщение о завершении перемещения/перевода режима в систему базовой станции (BSS)/подсистему 106 радиосети (RNS).

На этапе 2h BSS/RNS 106 может перенаправлять сообщение о завершении перемещения/перевода режима в MSC 110 SRVCC.

На этапе 3 UE 102 может передавать пейджинговое сообщение отклика в MSC 110.

На этапе 4 MSC 110 может пропустить процедуру аутентификации, поскольку UE 102 и ММЕ 108, соответственно, генерируют контекст защиты CS во время процедуры SRVCC. Другими словами, MSC 110 не должно передавать сообщение запроса аутентификации в UE 102, и UE 102 не должно передавать ответное сообщение на аутентификацию в MSC 110.

На этапе 5, после приема сообщения о завершении перемещения/перевода режима из RNS/BSS 106 на этапе 2h, применимые процедуры вызова CS продолжаются. Как дополнительно описано в 3GPP TS 24.008, UE 102 может генерировать случай вызова для SRVCC при Tl=0, который аналогичен случаю завершенного вызова во время процедуры SRVCC НО, то есть, случай вызова имеет Tl=0 и Tl Flag=1. Для исключения коллизии на стороне UE MSC 110 может передавать установочное сообщение с Tl=1 и Tl Flag=0, в противоположность установочному сообщению с Tl=0 и Tl Flag=0.

На этапе 6 UE 102 может передавать подтвержденное сообщение вызова в MSC 110.

На этапе 7, поскольку носитель радиодоступа CS (RAB) уже был предварительно выделен во время процедуры подготовки к передаче режима SRVCC, MSC 110 может пропускать процедуру назначения CS RAB. Другими словами, MSC 110 не должен выполнять назначение RAB с BSS/RNS 106, и BSS/RNS 106 не должен выполнять установку RAB с UE 102.

На этапе 8, UE 102 может передавать сообщение предупреждения в MSC 110.

На этапе 9 MSC 110 может передавать сообщение разъединения (Tl=0, Tl Flag=0), для разъединения случая фиктивного вызова, формируемого во время процедуры SRVCC.

Что касается второго решения для МТ eCSFB, на этапе 1a, MSC 110 может передавать пейджинговое сообщение запроса в ММЕ 108 через интерфейс SG. Пейджинговое сообщение запроса может включать в себя тип услуги (например, голосовые данные, видеоданные, USSD, LC, неизвестный). Если UE 102 находится в подключенном режиме, ММЕ 108 может передавать пейджинговое сообщение с уведомлением CS в UE 102. Если UE 102 находится в состоянии ожидания, ММЕ 108 может передавать пейджинговое сообщение в каждый eNodeB 104, и eNodeB 104 может перенаправлять пейджинговое сообщение в UE 102.

Если UE 102 находится в режиме ожидания, ММЕ 108 может передавать сообщение запроса услуги SG в MSC 110, содержащее индикацию, что UE 102 находится в режиме ожидания. Когда MSC 110 принимает сообщение запроса услуги SG, MSC 110 может прекратить повторную передачу пейджингового сообщения интерфейса SG.

Если UE 102 находится в подключенном режиме, ММЕ 108 может передавать сообщение запроса на услугу SG в MSC 110, содержащее индикацию того, что UE 102 находилось в подключенном режиме. MSC 110 может использовать такую соединенный индикацию подключенного режима для начала перенаправления вызова в таймер без ответа для UE 102, и MSC 110 должен передавать индикацию пользователя, предупреждающую вызывающую сторону. Когда MSC 110 принимает сообщение запроса на услугу SG, MSC 110 может прекратить повторную передачу пейджингового сообщения интерфейса SG.

На этапе 1b UE 102 может передавать сообщение запроса на расширенную услугу в ММЕ 108 для входящего мобильного возврата CS (CSFB). Сообщение запроса расширенной услуги может быть инкапсулировано в управление радиоресурсом (RRC) и в сообщении протокола приложения S1 (S1-AP).

На этапе 1c ММЕ 108 может передавать сообщение запроса S1-АР в eNodeB 104, которое включает в себя индикатор возврата в CS.

В соответствии с принятым типом услуги в пейджинговом сообщении запроса, ММЕ 108 может использовать новый индикатор SRVCC для уведомления eNodeB 104 о том, следует или нет инициировать SRVCC/vSRVCC. В качестве неограничительных примеров, новый индикатор SRVCC может быть равным "0" для обозначения того, что не ожидаются ни SRVCC/vSRVCC, ни традиционный CSFB, "1" для обозначения того, что ожидается SRVCC, или "2" для обозначения того, что ожидается vSRVCC. eNodeB 104 может выполнять конкретное действие на основе индикатора SRVCC, включенного в сообщение S1-АР. Например, если ожидается SRVCC, eNodeB 104 может инициировать процедуру SRVCC, как дополнительно определено в 3GPP TS 23.216. Если ожидается vSRVCC, eNodeB 104 может инициировать процедуру vSRVCC, как дополнительно определено в 3GPP TS 23.216. Если не ожидается ни SRVCC/vSRVCC, ни традиционный CSFB, eNodeB 104 может перейти к традиционному CSFB, как дополнительно определено в 3GPP TS 23.272, секции 6.2, 6.3 и 6.4.

На этапе 2а eNodeB 104 может, в случае необходимости, запросить отчет об измерениях из UE 102 для определения целевой соты GERAN/UTRAN, в которой должен быть выполнен перевод режима с коммутацией пакетов (PS).

На этапе 2b, на основе отчетов об измерениях UE, индикатора возврата к CS на этапе 1c и возможностей SRVCC UE, Е UTRAN источника (или eNodeB 104) может определять инициировать передачу режима SRVCC UE 102 в UTRAN/GERAN путем сообщения требуемого перевода режима в ММЕ 108.

На этапе 2c, когда ММЕ 108 принимает сообщение требуемого перевода режима из eNB 104, если запрашиваемый тип услуги представляет собой голосовые данные, ММЕ 108 источника может инициировать процедуру перевода режима PS-CS для запроса голосовых данных путем передачи сообщения запроса SRVCC PS в CS в сервер 110 MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, С-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикацию аварийной ситуации и индикатор CSFB. Сервер MSC 110 может перейти к процедуре SRVCC для подготовки ресурсов для передачи голосовых данных помимо сигналов. Если запрашиваемый тип услуги представляет собой видеоданные, ММЕ 108 источника может инициировать процедуру передачи PS-CS для запрашиваемого видеовызова, путем передачи сообщения запроса SRVCC PS в CS, в сервер MSC 110. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB и флаг vSRVCC. Затем сервер 110 MSC может перейти к процедуре vSRVCC для подготовки ресурсов для передачи видеоданных помимо сигналов. ММЕ 108 не требуется удалять носитель QCI=1, поскольку процедура SRVCC выполняется в соответствии с CSFB, и при этом отсутствует носитель QCI=1.

На этапе 2d, когда сервер 110 MSC принимает сообщение запроса SRVCC PS в CS, сервер 110 MSC может идентифицировать тип услуги, которая инициирует eCSFB. Если тип услуги представляет собой передачу голосовых данных, сервер 110 MSC может перейти к процедуре SRVCC для подготовки ресурсов для голосовых данных. Если тип услуги представляет собой видеоданные, сервер 110 MSC может перейти к процедуре vSRVCC для подготовки ресурсов для передачи видеоданных помимо сигналов. Поскольку SRVCC выполняется в соответствии с CSFB, SRVCC MSC 110 не инициирует процедуру передачи сеанса в IMS и только инициирует подготовку к передаче традиционного режима CS. Если SRVCC MSC 110 не представляет собой целевой MSC 112, тогда SRVCC MSC 110 может взаимодействовать с запросом на передачу режима PS-CS с запросом на передачу CS между MSC путем передачи сообщения запроса на подготовку на передачу в целевой MSC 112.

Этапы 2е-9 на фиг. 1 аналогичны описанию этапов 2е-9, представленному выше.

Для возврата в режим с коммутацией каналов (CSFB), запрашиваемый входящий мобильный вызов (МО), когда объект администрирования мобильностью (ММЕ) знает точный тип услуги, которая инициирует CSFB из оборудования пользователя (UE) в сообщении запроса расширенной услуги, может быть воплощено либо первое решение для МО Ecsfb, или второе решение для МО eCSFB, как дополнительно описано ниже.

В первом решении ММЕ может передавать сообщение протокола приложения S1 (S1-АР) с индикатором CSFB в развернутый узел В (eNB) после приема сообщения запроса на расширенную услугу с точным типом услуги. Когда eNB принимает сообщение S1-АР с индикатором CSFB, eNB может определять, следует или нет инициировать процедуру SRVCC для передачи голосовых данных, в соответствии с индикацией возможностей SRVCC UE в индикаторе группы свойства (FGI). eNB может принимать FGI непосредственно из UE. Если UE позволяет выполнять SRVCC, eNB может инициировать процедуру SRVCC, путем передачи сообщения, запрашивающего передачу режима, в ММЕ. Когда ММЕ принимает сообщение запроса на передачу режима из eNB, если тип запрашиваемой услуги представляет собой голосовые данные, ММЕ источника может инициировать процедуру передачи из коммутации пакетов (PS) на коммутацию каналов (CS) для передачи запроса на предоставление голосовых данных, путем передачи сообщения запроса SRVCC PS в CS в сервер центра коммутации мобильной передачи связи (MSC). Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, показатель аварийной ситуации и индикатор CSFB. Сервер MSC может перейти к процедуре SRVCC, для подготовки ресурсов для передачи голосовых данных, помимо сигналов. Если запрашиваемый тип услуги представляет собой видеоданные, ММЕ источника может инициировать процедуру перевода режима PS-CS для запрашиваемого видеовызова путем передачи сообщения запроса SRVCC PS в CS для сервера MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, С-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB и флаг vSRVCC. Сервер MSC может перейти к процедуре vSRVCC для подготовки ресурсов для передачи видеоданных, помимо сигналов. Если запрашиваемый тип услуги представляет собой другой, чем передача голосовых данных или видеоданных, ММЕ источника может передавать сообщение запроса SRVCC PS в CS в сервер MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, С-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB, и "не голосовые, не видеоданные". Сервер MSC может перейти к ненормальной процедуре SRVCC для подготовки только ресурсов для передачи сигналов.

Во втором решении, в соответствии с принятым типом услуги, ММЕ может использовать новый индикатор SRVCC для уведомления eNB о том, следует ли инициировать SRVCC/vSRVCC или нет. В качестве неограничительных примеров, новый индикатор SRVCC может быть равен "0" для обозначения того, что не ожидается ни SRVCC/vSRVCC, ни традиционный CSFB, и "1" для обозначения того, что ожидается SRVCC, или "2" для обозначения того, что ожидается vSRVCC. eNB может выполнять конкретное действие на основе индикатора SRVCC, включенного в сообщение S1-AP. Например, если ожидается SRVCC, eNB может инициировать процедуру SRVCC, как дополнительно определено в 3GPPTS 23.216. Если ожидается vSRVCC, eNB может инициировать процедуру vSRVCC, как дополнительно определено в 3GPP TS 23.216. Если не ожидается ни SRVCC/Vsrvcc, ни традиционный CSFB, eNB может перейти к традиционному CSFB, как дополнительно определено в 3GPP TS 23.272, секции 6.2, 6.3 и 6.4. Когда ММЕ принимает сообщение запроса на передачу режима из eNB, если запрашиваемый тип услуги представляет собой передачу голосовых данных, ММЕ источника может инициировать процедуру перевода режима PS-CS для голосового запроса, путем передачи сообщения запроса SRVCC PS в CS, в сервер MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикацию аварийной ситуации и индикатор CSFB. Сервер MSC может перейти к процедуре SRVCC для подготовки ресурсов для передачи голосовых данных помимо сигналов. Если запрашиваемый тип услуги представляет собой передачу видеоданных, ММЕ источника может инициировать процедуру перевода режима PS-CS для запрашиваемого видеовызова, путем передачи сообщения запроса SRVCC PS в CS, в сервер MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, С-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB и флаг vSRVCC. Сервер MSC может перейти к процедуре vSRVCC, для подготовки ресурсов для передачи видеоданных помимо сигналов.

При eCSFB инициированном мобильным вызовом (МО) UE может передавать сообщение запроса расширенной услуги с типом услуги в ММЕ. ММЕ может передавать сообщение запроса S1-АР с индикатором SRVCC. Сообщение S1-АР может обозначать для eNB, что UE должно быть переведено в UTRAN/GERAN. Когда eNB принимает сообщение запроса S1AP, eNB может выполнять одно из двух действий. Если UE обозначает возможности SRVCC в FGI, и индикатор SRVCC из ММЕ не только обозначает традиционный CSFB, eNB может инициировать процедуру SRVCC/vSRVCC, даже при том, что отсутствует носитель CQI=1 для eNB. Если UE обозначает возможности SRVCC в FGI, но индикатор SRVCC из ММЕ только обозначает традиционный CSFB, eNB не инициирует процедуру SRVCC/vSRVCC, а скорее переходит к традиционной процедуре CSFB, как определено в TS 23.272. Для SRVCC, поскольку отсутствует носитель CQI=1 для процедуры, инициированной CSFB, в ММЕ нет необходимости удалять носитель CQI=1. Для vSRVCC, поскольку отсутствует носитель CQI=1 и носитель PS, помеченный vSRVCC для процедуры инициирования CSFB, для ММЕ нет необходимости удалять носитель CQI=1, и носитель PS, помеченный vSRVCC.

На фиг. 2 иллюстрируется пример процедуры, инициированного мобильным вызовом (МО) возврата к усовершенствованной технологии перевода в режим с коммутацией каналов (eCSFB). В частности, со ссылкой на фиг. 2, можно представить первое решение для МО eCSFB или второе решение для МО eCSFB, как описано выше.

Что касается первого решения для МО eCSFB на этапе 1а, оборудование 202 пользователя (UE) может передавать сообщение запроса на расширенную услугу в объект 208 мобильного администрирования (ММЕ) для возврата к CS по вызову из мобильного терминала. Сообщение запроса на расширенную услугу может включать в себя тип услуги, такой как передача голосовых данных, видеоданных, услуг по определению местоположения (LC), данных неструктурированной вспомогательной услуги (USSD), или неизвестный.

На этапе 1b, ММЕ 208 может передавать сообщение запроса S1-АР в eNodeB 204, который включает в себя индикатор возврата к CS.

На этапе 2а, eNodeB 204, в случае необходимости, может запрашивать отчет об измерениях из UE 202 для определения целевой соты GERAN/UTRAN, в которую должен быть выполнен перевод режима с коммутацией пакетов (PS).

На этапе 2b, на основе отчетов об измерениях UE, индикатора возврата к CS на этапе 1b и возможностей SRVCC UE источник Е UTRAN может определять инициировать передачу режима SRVCC в UTRAN/GERAN путем подачи сообщения о требуемой передаче режима в ММЕ 208.

На этапе 2c, когда ММЕ 208 принимает сообщение запроса о передаче режима из eNB 204, если запрашиваемый тип услуги представляет собой голосовые данные, ММЕ 208 источника может инициировать процедуру из сети с коммутацией пакетов (PS) в сеть с коммутацией каналов (CS) для запроса на передачу режима голосовых данных, путем передачи сообщения запроса SRVCC PS в CS, в сервер 210 MSC. Сообщение запроса SRVCC PS в CS может включать в себя международную идентичность абонента мобильной связи (IMSI), целевой идентификатор (ID), номер передачи сеанса для SRVCC (STN-SR), номер корреляции цифровой сети интегрированных услуг мобильной станции (ISDN) (C-MSISDN), прозрачный контейнер из источника в цель, контекст ММ, индикацию аварийной ситуации и индикатор CSFB. Если запрашиваемый тип услуги представляет собой видеоданные, ММЕ 208 источника может инициировать процедуру перевода режима PS-CS для запрашиваемого видеовызова, путем передачи сообщения запроса PS SRVCC в CS, в сервер 210 MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, C-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB и флаг vSRVCC. Если тип запрашиваемой услуги является другим, чем голосовые данные или видеоданные, ММЕ 208 источника может передавать сообщение запроса SRVCC PS в CS, в сервер 210 MSC. Сообщение запроса SRVCC PS в CS может включать в себя IMSI, целевой ID, STN-SR, С-MSISDN, прозрачный контейнера из источника в цель, контекст ММ, индикатор CSFB и не голосовые, не видео данные. ММЕ 208 не требуется удалять носитель QCI=1, поскольку процедура SRVCC соответствует CSFB и здесь отсутствует носитель QCI=1.

На этапе 2d, когда сервер 210 MSC принимает сообщение запроса SRVCC PS в CS, сервер 210 MSC может идентифицировать тип услуги, который инициирует CSFB. Если тип услуги представляет собой голосовые данные, сервер 210 MSC может перейти к процедуре SRVCC для подготовки ресурсов для голосовых данных. Если тип услуги представляет собой видеоданные, сервер 210 MSC может перейти к процедуре vSRVCC, для подготовки ресурсов для видеоданных, помимо передачи сигналов. Если тип услуги представляет собой "не голосовые данные, не видеоданные", сервер 210 MSC может перейти к ненормальной процедуре SRVCC для подготовки ресурсов только для передачи сигналов. Поскольку SRVCC соответствует CSFB, SRVCC MSC 210 не инициирует процедуру передачи сеанса в IMS и только инициирует подготовку традиционного CS. Если SRVCC MSC 210 не является целевым MSC 212, тогда SRVCC MSC 210 может взаимодействовать с запросом на передачу режима PS-CS с запросом на передачу CS между MSC, путем передачи сообщения запроса на подготовку к передаче режима в целевой MSC 212.

На этапе 2е, ММЕ 208 источника может передавать сообщение-команду на передачу режима (прозрачный контейнер из цели в источник) в e-UTRAN источника (или eNodeB 204) и затем в UE 202. Сообщение-команда на передачу режима может включать в себя информацию о голосовом компоненте.

На этапе 2g, UE 202 может передавать сообщение о завершении перемещения/перевода режима в систему базовой станции (BSS)/подсистему 206 радиосети (RNS).

На этапе 2h, BSS/RNS 206 может перенаправлять сообщение о завершении перемещения/перевода режима в SRVCC MSC 210.

На этапе 3, UE 202 может передавать сообщение запроса на услугу СМ в MSC 210.

На этапе 4, MSC 210 может пропускать процедуру аутентификации, поскольку UE 202 и ММЕ 208, соответственно, генерируют контекст безопасности CS во время процедуры SRVCC. Другими словами, MSC 210 не должен передавать сообщение запроса на аутентификацию в UE 202, и UE 202 не должен передавать сообщение ответа на аутентификацию в MSC 210.

На этапе 5, UE 202 может принимать сообщение приема услуги СМ, из MSC 210, и UE 202 может впоследствии перейти к процедурам вызова CS.

На этапе 6, UE 202 может перейти к процедуре вызова CS, путем передачи установочного сообщения с Tl=0 и Tl Flag=0 в MSC 210. Как дополнительно описано в 3GPP TS 24.008, UE 202 может генерировать случай вызова для SRVCC с Tl=0, что аналогично завершенному случаю вызова во время процедуры SRVCC НО, то есть, случай вызова с Tl=0 и Tl Flag=1.

На этапе 7, MSC 210 может передавать сообщение процедуры вызова в UE 202.

На этапе 8, поскольку носитель радиодоступа CS (RAB) уже предварительно выделен во время процедуры подготовки к передаче режима SRVCC, MSC 110 может пропускать процедуру выделения CS RAB. Другими словами, MSC 210 не должен выполнять назначение RAB с BSS/RNS 206, и BSS/RNS 206 не должен выполнять установку RAB с UE 202.

На этапе 9, MSC 210 может передавать сообщение предупреждения в UE 202.

На этапе 10, MSC 210 может передавать сообщение разъединения (Tl=0, Tl Flag=0) для разъединения в случае фиктивного вызова, сформированного во время процедуры SRVCC.

Что касается второго решения для МО eCSFB, на этапе 1a, UE 202 может передавать сообщение запроса на расширенную услугу в ММЕ 208 для возврата к CS, инициированного входящим мобильным вызовом. Сообщение запроса на расширенную услугу может включать в себя точный тип услуги (например, передача голосовых данных, видеоданных, USSD, LC, неизвестное).

На этапе 1b, ММЕ 208 может передавать сообщение запроса S1-АР в eNodeB 204, который включает в себя индикатор возврата к CS. В соответствии с принятым типом услуги, ММЕ 208 может использовать новый индикатор SRVCC для уведомления eNodeB 204 о том, следует ли инициировать SRVCC/vSRVCC или нет. В качестве неограничительных примеров, новый индикатор SRVCC может быть равен "0" для обозначения того, что не ожидается ни SRVCC/vSRVCC, ни традиционный CSFB, "1" для обозначения, что ожидается SRVCC, или "2" для обозначения того, что ожидается vSRVCC. eNodeB 204 может выполнять конкретное действие на основе индикатора SRVCC, включенного в сообщение S1-АР. Например, если ожидается SRVCC, eNodeB 204 может инициировать процедуру SRVCC, как дополнительно определено в 3GPPTS 23.216. Если ожидается vSRVCC, eNodeB 204 может инициировать процедуру vSRVCC, как дополнительно определено в 3GPP TS 23.216. Если не ожидаются ни SRVCC/VsrvcC, ни традиционный CSFB, eNodeB 204 может перейти к традиционному CSFB, как дополнительно определено в 3GPPTS 23.272, секции 6.2, 6.3 и 6.4.

На этапе 2а, eNodeB 204 может, в случае необходимости, запросить отчет об измерениях из UE 202 для определения целевой соты GERAN/UTRAN, в которую выполняется перевод режима, с коммутацией пакетов (PS).

На этапе 2b, на основе отчетов об измерениях UE, индикатора возврата к CS на этапе 1b и возможностей SRVCC UE в индикаторе группы свойства (FGI), Е UTRAN источника может определять инициировать передачу режима SRVCC или vSRVCC для UTRAN/GERAN, путем передачи сообщения запроса на передачу режима в ММЕ 208.

На этапе 2c, когда ММЕ 208 принимает сообщение запроса на передачу режима из eNB 204, если запрашиваемый тип услуги представляет собой передачу голосовых данных, ММЕ 208 источник может инициировать процедуру перевода режима с коммутации пакетов (PS) на коммутацию каналов (CS) для передачи запроса голосовых данных, путем передачи сообщения запроса SRVCC PS в CS, в сервер 210 MSC. Сообщение запроса SRVCC PS в CS может включать в себя международную идентичность абонента мобильной связи (IMSI), целевой идентификатор (ID), номер передачи сеанса для SRVCC (STN-SR), номер корреляции цифровой сети интегрированных услуг мобильной станции (ISDN) (C-MSISDN), прозрачный контейнер из источника в цель, контекст ММ, индикацию аварийной ситуации и индикатор CSFB. Если запрашиваемый тип услуги представляет собой передачу видеоданных, ММЕ 208 источник может инициировать процедуру перевода режима PS-CS для запрашиваемого видеовызова путем передачи сообщения запроса SRVCC PS в CS, в сервер 210 MSC. Сообщение запроса SRVCC PS В CS может включать в себя IMSI, целевой ID, STN-SR, С-MSISDN, прозрачный контейнер из источника в цель, контекст ММ, индикатор CSFB и флаг vSRVCC. Сервер 210 MSC может перейти к процедуре vSRVCC для подготовки ресурсов для передачи видеоданных помимо сигналов. ММЕ 208 не требуется удалять носитель QCI=1, поскольку процедура SRVCC соответствует CSFB и в ней отсутствует носитель QCI=1.

На этапе 2d, когда сервер 210 MSC принимает сообщение запроса SRVCC PS в CS, сервер 210 MSC может идентифицировать тип услуги, который инициирует eCSFB. Если тип услуги представляет собой передачу голосовых данных, сервер 210 MSC может перейти к процедуре SRVCC для подготовки ресурсов для передачи голосовых данных. Если тип услуги представляет собой передачу видеоданных, сервер 210 MSC может перейти к процедуре vSRVCC, для подготовки ресурсов к передаче видеоданных, помимо передачи сигналов. Поскольку SRVCC соответствует CSFB, SRVCC MSC 110 не инициирует процедуру передачи сеанса в IMS и только инициирует подготовку к передаче традиционной CS. Если SRVCC MSC 210 не является целевым MSC 212, тогда SRVCC MSC 210 может взаимодействовать с запросом на передачу PS-CS, с запросом на передачу режима CS MSC, путем передачи сообщения запроса на подготовку передачу режима в целевой MSC 212.

Этапы 2е-10 на фиг. 2 аналогичны описанию этапов от 2е по 10, представленным выше.

На фиг. 3 иллюстрируется примерная процедура усовершенствованной технологии перевода в режим с коммутацией каналов (CSFB), которая включает в себя процедуру непрерывности одиночного голосового радиовызова (SRVCC). Другими словами, улучшенная процедура CSFB комбинирует CSFB с SRVCC. В частности, на фиг. 3 описаны несколько технологий, в которых возможности расширенной CSFB в UE передают в различные элементы сети, такие как eNB и ММЕ. Когда UE поддерживает расширенные возможности CSFB, EUTRAN может инициировать процедуру SRVCC путем приема сообщения S1AP с индикатором возврата к CS из ММЕ. Индикация поддержки UE расширенных возможностей CSFB может быть включена в сообщение S1AP. Если сообщение S1AP обозначает, что UE не поддерживает расширенные возможности CSFB, тогда eNB не инициирует процедуру SRVCC. В случае расширенного CSFB не существует носитель CQI=1 для UE в e-UTRAN. Например, в первой технологии, расширенные возможности CSFB в UE передают в сетевые элементы через сообщение запроса расширенной услуги. Во второй технологии расширенные возможности CSFB UE определяют на основе профиля подписки UE. В третьей технологии расширенные возможности CSFB UE передают в сетевые элементы через сообщение слоя без доступа (NAS). В четвертой технологии расширенные возможности CSFB UE определяют через индикатор группы свойства (FGI).

Что касается фиг. 3 и первой технологии, на этапе 1, центр 310 коммутации мобильной связи (MSC) или регистр определения местоположения посетителя (VLR) может принимать инициатор для процедуры, инициированной сетью с коммутацией каналов (CS).

На этапе 1a, MSC 310 может отвечать путем передачи пейджингового сообщения запроса в объект 308 администрирования мобильностью (ММЕ) через интерфейс SG. Для вызова независимой вспомогательной услуги пейджинговое сообщение запроса может включать в себя идентификатор услуги SS. Если ММЕ 308 не возвращает индикацию "ТОЛЬКО SMS" в UE 302 во время прикрепления комбинированной области отслеживания (ТА), или процедура обновления области определения местоположения (LA), ММЕ 308 может передавать пейджинговое сообщение в UE 302.

Для вызова независимой вспомогательной услуги пейджинговое сообщение запроса может включать в себя ID услуги SS. ID услуги SS может использоваться для обозначения типа вспомогательной услуги в UE. ID услуги SS может быть включен в пейджинговое сообщение запроса, когда UE 302 находится в активном режиме.

Если ММЕ 308 возвратил индикацию "ТОЛЬКО SMS", UE 302 во время процедуры прикрепления или комбинирования области отслеживания (ТА) или процедуры обновления области местоположения (LA), ММЕ 308 не передает пейджинговое сообщение в UE 302, и ММЕ 308 передает пейджинговое сообщение отказа CS в MSC 310 для остановки процедуры пейджингового сообщения, прекращая, таким образом, процедуру CSFB.

Если UE 302 находится в подключенном режиме, ММЕ 308 может передавать в CS пейджинговое сообщение с уведомлением в UE 302. Если UE 302 находится в режиме ожидания, ММЕ 308 может передавать пейджинговое сообщение в каждый eNodeB 304, и eNodeB 304 могут перенаправлять пейджинговое сообщение в UE 302.

На этапе 1b, UE 302 может передавать сообщение запроса расширенной услуги (с отказом от нее или приемом ее) в ММЕ 308 для возврата к CS с входящим мобильным вызовом. Сообщение запроса расширенной услуги может быть инкапсулировано в сообщения управления радио ресурсом (RRC) S1-АР. Сообщение запроса расширенной услуги может включать в себя индикатор расширенной CSFB, если UE поддерживает эту функцию (то есть, если UE поддерживает расширенный CSFB).

На этапе 1c, после приема запроса расширенной услуги (с отказом) для возврата к CS с входящим мобильным вызовом, с индикатором расширенного CSFB, ММЕ 308 может передавать пейджинговое сообщение отказа в MSC 310, для остановки процедуры пейджинговых сообщения в CS, прекращая, таким образом, процедуру CSFB.

На этапе 1d, ММЕ 308 может передавать сообщение запроса S1-АР в eNodeB 304, который включает в себя возможности радиосвязи UE и индикатор улучшенного возврата к CS. Такое сообщение запроса S1-АР может обозначать для eNodeB 304, что UE 302 должно переместиться в UTRAN/GERAN.

На этапе 1e, eNodeB 304 может отвечать, передавая ответное сообщение S1-AP.

На этапе 2 может выполняться этап необязательного отчета об измерениях и этап запроса, как дополнительно определено в 3GPP TS 23.272. Эти этапы дополнительно определены в пункте 7.3 для случая поддержки перевода режима в PS, и пункт 7.4 для случая без поддержки перевода режима в PS.

На этапе 3, на основе отчетов об измерениях UE, индикатора перехода к расширенной CS, и возможностей SRVCC UE на этапе 1d, источник E-UTRAN (или eNodeB 304) может определять инициировать передачу режима SRVCC UE в UTRAN/GERAN. Если UE 302 не поддерживает SRVCC, тогда может быть выполнена процедура традиционного CSFB.

E-UTRAN может инициировать передачу режима SRVCC в UTRAN/GERAN для CSFB, когда отсутствует носитель QCI=1, и носитель помеченных видеоданных vSRVCC. ММЕ 308 может передавать сообщение запроса SRVCC PS в CS с индикацией CSFB о том, что SRVCC соответствует CSFB. ММЕ 308 не требуется выполнять разделение носителей от других носителей PS. ММЕ 308 не удаляет носитель QCI=1, и носитель видеоданных, помеченный vSRVCC, поскольку процедура SRVCC соответствует CSFB, и здесь отсутствует носитель QCI=1, и носитель видеоданных, помеченный vSRVCC. Поскольку SRVCC соответствует CSFB, MSC 310 не инициирует процедуру передачи сеанса и только инициирует подготовку к переводу в к традиционной CS.

На этапе 4, после завершения приема сообщения перемещения/перевода режима из RNS/BSS 306 на этапе 3, процедура CS может продолжиться.

Как показано на фиг. 3 и во второй технологии, ММЕ 308 может определять возможности расширенного CSFB UE на основе профиля подписки UE. ММЕ 308 может принимать профиль подписки из опорного абонентского сервера (HSS). В одном примере профиль подписки может быть включен в обновленное сообщение подтверждения местоположения, как дополнительно определено в 3GPPTS 23.401 секция 5.3.2.1. В другом примере расширенные возможности CSFB UE могут быть предоставлены в ММЕ 308 во время процедуры прикрепления.

На этапе 1, MSC 310 или VLR может принимать инициатор для процедуры, инициированной сетью с коммутацией каналов (CS).

На этапе 1a, MSC 310 может отвечать путем передачи пейджингового сообщения запроса в ММЕ 308 через интерфейс SG.

На этапе 1b, UE 302 может передавать сообщение запроса расширенной услуги (с отклонением или приемом его) в ММЕ 308 для возврата к CS с входящим мобильным вызовом. Сообщение запроса расширенной услуги может быть инкапсулировано в сообщения управления радиоресурсом (RRC) и в сообщения S1-AP.

На этапе 1c, после приема запроса расширенной услуги (с отклонением) для возврата к CS, с входящим мобильным вызовом, ММЕ 308 может передавать пейджинговое сообщение отклонения в MSC 310 для остановки процедуры пейджингового сообщения CS, останавливая, таким образом, процедуру CSFB.

На этапе 1d, ММЕ 308 может передавать сообщение запроса S1-АР в eNodeB 304, которое включает в себя возможности радиосвязи UE и расширенный индикатор возврата к CS для UE. Как пояснялось выше, ММЕ 308 может заранее определять индикатор возврата к расширенной CS на основе профиля подписки UE, который был принят из HSS. Такое сообщение запроса S1-АР может обозначать для eNodeB 304, что UE 302 должно быть перемещено в UTRAN/GERAN.

На этапе 1e, eNodeB 304 может отвечать ответным сообщением S1-AP.

Этапы 2, 3 и 4 на фиг. 3 являются такими же, как описаны выше.

Как представлено на фиг. 3 и в третьей технологии, ММЕ 308 может определять расширенные возможности CSFB UE на основе сообщения запроса прикрепления или сообщения обновления области отслеживания (TAU), принятого в ММЕ 308. Другими словами, ММЕ 308 может принимать сетевые возможности UE в сообщении NAS во время прикрепления или процедуры TAU, и сетевые возможности UE могут обозначать расширенные возможности CSFB UE. В одном примере сообщение NAS может включать в себя "1" для обозначения того, что UE 302 поддерживает расширенный CSFB, или "0" для обозначения того, что UE 302 не поддерживает расширенный CSFB. Процедура прикрепления дополнительно определена в 3GPP TS 23.401 секции 5.3.2.1, и процедура обновления области отслеживания (TAU) дополнительно определена в 3GPP TS 23.401 секции 5.3.3.1.

На этапе 1 MSC 310 или VLR может принимать инициатор для процедуры коммутации каналов (CS) инициированной сети.

На этапе 1a, MSC 310 может отвечать путем передачи пейджингового сообщения запроса в ММЕ 308 через интерфейс SG.

На этапе 1b, UE 302 может передавать сообщение запроса расширенной услуги (с отклонением или приемом) в ММЕ 308 для возврата к CS с входящим мобильным вызовом. Сообщение запроса расширенной услуги может быть инкапсулировано в сообщения управления радиоресурсом (RRC) и S1-AP.

На этапе 1c, после приема запроса расширенной услуги (с отклонением) для возврата к CS с входящим мобильным вызовом, ММЕ 308 может передавать пейджинговое сообщение отклонения в MSC 310 для остановки пейджинговой процедуры CS, останавливая, таким образом, процедуру CSFB.

На этапе 1d, ММЕ 308 может передавать сообщение запроса S1-АР в eNodeB 304, который включает в себя возможности радиосвязи UE и расширенный индикатор возврата к CS для UE. Расширенный индикатор возврата к CS может быть включен в сообщение запроса S1-АР, если расширенный индикатор возврата к CS в возможностях сети UE установлен как true. Как пояснялось ранее, ММЕ 308 может заранее определять расширенный индикатор возврата к CS на основе приема сообщения NAS из UE 302 во время процедуры прикрепления или процедуры TAU. Такое сообщение запроса S1-AP может обозначать для eNodeB 304, что UE 302 следует переместить в UTRAN/GERAN.

На этапе 1e, eNodeB 304 может отвечать, используя ответное сообщение S1-AP.

Этапы 2, 3 и 4 на фиг. 3 являются такими, как описано выше.

Как представлено на фиг. 3 и в четвертой технологии, eNodeB 304 может определять расширенные возможности CSFB UE на основе индикатора группы свойства (FGI), принятого из UE 302. В другом примере расширенные возможности CSFB UE могут быть включены в параметры возможности радиодоступа UE, предусмотренные в eNodeB 304 из UE 302. eNodeB 304 может предоставлять для UE расширенные возможности CSFB для ММЕ 308. Индикаторы группы свойства (FGI) и возможности UE-EUTRA дополнительно определены в 3GPP TS 36.331 секция В.1.

На этапе 1, MSC 310 или VLR может принимать инициатор для процедуры коммутации каналов (CS), инициированной сетью.

На этапе 1a, MSC 310 может отвечать путем передачи пейджингового сообщения запроса в ММЕ 308 через интерфейс SG.

На этапе 1b, UE 302 может передавать сообщение запроса расширенной услуги (с отклонением или приемом) в ММЕ 308 для возврата к CS с входящим мобильным вызовом. Сообщение запроса расширенной услуги может быть инкапсулировано в сообщения управления радиоресурсом (RRC) и S1-AP.

На этапе 1c, после приема запроса расширенной услуги (с отклонением) для возврата к CS с входящим мобильным вызовом ММЕ 308 может передавать пейджинговое сообщение отклонения в MSC 310 для остановки пейджинговой процедуры CS, останавливая, таким образом, процедуру CSFB.

На этапе 1d, ММЕ 308 может передавать сообщение запроса S1-АР в eNodeB 304, которое включает в себя возможности радиосвязи UE. Сообщение запроса S1-АР может обозначать для eNodeB 304, что UE 302 должно быть перемещено в UTRAN/GERAN.

На этапе 1e, eNodeB 304 может отвечать ответным сообщением S1-AP.

На этапе 2 могут быть выполнены этап необязательной отчетности об измерениях и этап запроса, как дополнительно определено в 3GPP TS 23.272. Эти этапы дополнительно определены в пункте 7.3 для случая передачи PS с поддержкой, и в пункте 7.4 для случая PS с поддержкой.

На этапе 3, на основе отчетов об измерениях UE, расширенного индикатора возврата к CS, и возможностей SRVCC UE на этапе 1d, источник Е UTRAN (или eNodeB 304) может определять инициировать передачу режима SRVCC UE в UTRAN/GERAN. Как пояснялось выше, eNodeB 304 может определять расширенный индикатор возврата к CS на основе FGI, принятого из UE 302. Другими словами, в этом случае, eNodeB 304 может принимать расширенный индикатор возврата к CS из UE 302, а не из ММЕ 308.

E-UTRAN может инициировать передачу режима SRVCC в UTRAN/GERAN для CSFB, когда отсутствует носитель QCI=1, и помеченный носитель видеоданных vSRVCC. Требуемое сообщение перевода режима, передаваемое из eNB 304 в ММЕ 308, может включать в себя индикатор для расширенных возможностей CSFB, где ММЕ 308 интерпретирует индикатор, что SRVCC соответствует CSFB. ММЕ 308 может передавать сообщение запроса SRVCC PS в CS с индикацией CSFB о том, что SRVCC соответствует CSFB. ММЕ 308 не требуется выполнять отделение носителя от других носителей PS. ММЕ 308 не удаляет носитель QCI=1, и помеченный носитель видеоданных vSRVCC, как процедуру SRVCC - из-за CSFB и из-за отсутствия носителя QCI=1, и помеченный носитель видеоданных vSRVCC. Поскольку SRVCC соответствует CSFB, MSC 310 не инициирует процедуру передачи сеанса и только инициирует подготовку к традиционной передаче режима CS.

На этапе 4, после приема сообщения о завершении перемещения/перевода режима из RNS/BSS 306 на этапе 3, процедура CS может продолжиться.

В другом примере предоставляют функцию 400 объекта администрирования мобильностью (ММЕ), содержащего один или больше процессоров, сконфигурированных так, чтобы способствовать возврату в режим коммутации каналов (CSFB) для оборудования пользователя (UE), как показано в блок-схеме последовательности операций на фиг. 4. Эти функции могут быть воплощены, как способ, или функции могут быть выполнены, как инструкции в устройстве, где инструкции включены, по меньшей мере, в один считываемый компьютером носитель информации или один непереходный считываемый устройством носитель информации. Один или больше процессоров могут быть сконфигурированы для приема оптимизированного индикатора возможностей CSFB из UE, который определяет оптимизированную возможность CSFB UE, как в блоке 410. Один или больше процессоров могут быть сконфигурированы для приема типа запрашиваемой услуги, ассоциированной с UE, как в блоке 420. Один или больше процессоров могут быть сконфигурированы для инициирования передачи режима UE с непрерывностью одиночного голосового радиовызова (SRVCC) в сеть с коммутацией каналов на основе оптимизированной возможности CSFB UE, как в блоке 430. Один или больше процессоров могут быть сконфигурированы для передачи сообщения запроса протокола приложения S1 (S1-АР) в развернутый узел В (eNB), в котором сообщение запроса S1-АР включает в себя индикатор оптимизированной возможности CSFB и индикатор непрерывности одного голосового радиовызова (SRVCC) для UE, в котором ММЕ выбирает индикатор SRVCC на основе запрашиваемого типа услуги, как в блоке 440. Один или больше процессоров могут быть сконфигурированы для приема сообщения запроса перевода режима из eNB, где eNB сконфигурирован для передачи сообщения запроса на передачу в ММЕ, когда перевод режима SRVCC UE в сеть с коммутацией каналов инициируется сетью с коммутацией пакетов на основе частично оптимизированного индикатора возможности CSFB и индикатора SRVCC, как в блоке 450.

В одном примере один или больше процессоров дополнительно сконфигурированы для приема оптимизированного индикатора возможностей CSFB из UE через сообщение запроса прикрепления или сообщение запроса обновления области отслеживания (TAU). В другом примере один или больше процессоров дополнительно сконфигурированы для приема оптимизированного индикатора возможностей CSFB из UE через расширенное сообщение запроса услуги. В еще одном, другом примере, один или больше процессоров дополнительно сконфигурированы для идентификации оптимизированного индикатора возможностей CSFB на основе сообщения подтверждения обновленного местоположения, которое принимают из опорного абонентского сервера (HSS), сообщение подтверждения обновленного местоположения, включающее в себя профиль абонента UE, который обозначает оптимизированную возможность CSFB UE.

В одном примере один или больше процессоров дополнительно выполнены с возможностью принимать тип запрашиваемой услуги из центра коммутации мобильной связи (MSC) через пейджинговое сообщение запроса. В другом примере индикатор оптимизированных возможностей CSFB равен "0" для обозначения того, что UE не поддерживает SRVCC на основе CSFB, или "1" для обозначения того, что UE не поддерживает CSFB на основе SRVCC. В еще одном примере один или больше процессоров дополнительно выполнены с возможностью приема сообщения запроса расширенной услуги из UE для вызова, инициированного мобильным терминалом (МО). Кроме того, один или больше процессоров дополнительно выполнены с возможностью приема пейджингового сообщения запроса из центра коммутации мобильной передачи связи (MSC) для вызова с входящим мобильным вызовом (МТ).

В одной конфигурации сеть с коммутацией каналов представляет собой Универсальную наземную сеть радиодоступа (UTRAN) или сеть Глобальной системы мобильной связи (GSM) с повышенной скоростью передачи данных для сети радиодоступа - развития GSM (GERAN). В другой конфигурации запрашиваемый тип услуги представляет собой один из следующих: передачу голосовых данных, видеоданных, неструктурированных вспомогательных данных услуги (USSD), услуги определения местоположения (LC) или неизвестный. В еще одной конфигурации индикатор SRVCC уведомляет eNB о том, следует или нет инициировать SRVCC/video SRVCC (vSRVCC), в котором индикатор SRVCC равен "0", для обозначения в eNB, что не ожидается SRVCC/vSRVCC или традиционный CSFB, в котором индикатор SRVCC равен "1" для обозначения для eNB, что ожидается SRVCC, в котором индикатор SRVCC равен "2" для обозначения для eNB, что ожидается vSRVCC.

В одном примере один или больше процессоров дополнительно выполнены с возможностью инициирования процедуры перевода режима из сети с коммутацией пакетов в сеть с коммутацией каналов (PS-CS), где отсутствует носитель CQI=1, ассоциированный с UE. В другом примере один или больше процессоров дополнительно выполнены с возможностью инициирования процедуры перевода режима из сети с коммутацией пакетов в сеть с коммутацией каналов (PS-CS), когда запрашиваемый тип услуги представляет собой передачу голосовых данных или видеоданных, путем передачи сообщения запроса из PS в CS с целью SRVCC для сервера мобильного центра передачи данных (MSC), где сообщение запроса из PS в CS включает в себя индикатор оптимизированных возможностей CSFB.

Другой пример обеспечивает функцию 500 развернутого узла В (eNB), содержащего один или больше процессоров, сконфигурированных для того, чтобы способствовать оптимизированному возврату к коммутации каналов (CSFB) для оборудования пользователя (UE), как показано в блок-схеме последовательности операций на фиг. 5. Такие функции могут быть воплощены, как способ, или функции могут быть выполнены, как инструкции в устройстве, где эти инструкции включены в, по меньшей мере, в один считываемый компьютером носитель информации или один непереходный считываемый устройством носитель информации. Один или больше процессоров могут быть сконфигурированы для приема индикатора оптимизированных возможностей CSFB, который определяет оптимизированные возможности CSFB для UE, как в блоке 510. Один или больше процессоров могут быть сконфигурированы для приема индикатора непрерывности одного голосового радиовызова (SRVCC) для UE, как в блоке 520. Один или больше процессоров могут быть сконфигурированы для инициирования перевода режима SRVCC UE в сеть с коммутацией каналов, частично, на основе индикатора оптимизированном возможности CSFB и индикатора SRVCC, как в блоке 530. Один или больше процессоров могут быть сконфигурированы для перевода режима сообщения запроса на передачу в объект администрирования мобильностью (ММЕ), когда передачу режима SRVCC инициирует сеть с коммутацией пакетов, как в блоке 540.

В одном примере один или больше процессоров, дополнительно выполнены с возможностью приема индикатора оптимизированных возможностей CSFB из UE через индикатор группы свойств (FGI). В другом примере один или больше процессоров дополнительно выполнены с возможностью инициирования перевода режима SRVCC UE в сеть с коммутацией каналов, когда отсутствует носитель CQI=1, ассоциированный с UE. В еще одном, другом примере, один или больше процессоров дополнительно выполнены с возможностью приема индикатора оптимизированных возможностей CSFB из ММЕ.

В одной конфигурации индикатор SRVCC уведомляет eNB о том, следует ли инициировать SRVCC/video SRVCC (vSRVCC), в котором индикатор SRVCC равен "0" для обозначения для eNB о том, что не ожидается SRVCC/vSRVCC или традиционный CSFB, в котором индикатор SRVCC равен "1" для обозначения для eNB о том, что ожидается SRVCC, в котором индикатор SRVCC равен "2" для обозначения для eNB, что ожидается vSRVCC. В другой конфигурации сеть с коммутацией каналов представляет собой Универсальную наземную сеть радиодоступа (UTRAN) или сеть Глобальной системы мобильной связи (GSM) с повышенной скоростью передачи данных для сети радиодоступа - развития GSM (GERAN).

Другой пример направлен на способ 600, который способствует оптимизированному возврату коммутации каналов (CSFB), как показано в блок-схеме последовательности операций на фиг. 6. Способ может выполняться, как инструкции в устройстве, где инструкции включены, по меньшей мере, в один считываемый компьютером носитель информации или один непереходный считываемый устройством носитель информации. Способ может включать в себя операцию передачи из оборудования пользователя (UE) индикатора оптимизированных возможностей CSFB в объект администрирования мобильностью (ММЕ), как в блоке 610. Способ может включать в себя операцию передачи из UE запрашиваемого типа услуги в ММЕ, в котором ММЕ выполнен с возможностью способствовать передаче режима UE с непрерывностью одиночного голосового радиовызова (SRVCC) в сеть с коммутацией каналов на основе частично оптимизированной возможности CSFB и запрашиваемого типа услуги, как в блоке 620.

В одном примере способ может включать в себя операцию передачи индикатора оптимизированной возможности CSFB из UE в ММЕ через сообщение запроса прикрепления или сообщение запроса обновления области отслеживания (TAU). В другом примере способ может включать в себя операцию передачи, по меньшей мере, одного из индикатора оптимизированной возможности CSFB или типа запрашиваемой услуги из UE в ММЕ через сообщение запроса расширенной услуги. В еще одном, другом примере, индикатор оптимизированной возможности CSFB равен "0" для обозначения того, что UE не поддерживает SRVCC на основе CSFB или "1" для обозначения того, что UE поддерживает SRVCC на основе CSFB. Кроме того, запрашиваемый тип услуги представляет собой один из следующего: голосовые данные, видеоданные, неструктурные вспомогательные данные услуги (USSD), услуга определения местоположения (LC) или неизвестный.

На фиг. 7 представлена иллюстрация примера беспроводного устройства, такого как оборудование пользователя (UE), мобильная станция (MS), мобильное беспроводное устройство, устройство мобильной передачи данных, планшетный компьютер, телефонная трубка, или другой тип беспроводного устройства. Беспроводное устройство может включать в себя одну или больше антенн, сконфигурированных для обмена данными с узлом или станцией передачи, такой как базовая станция (BS), развернутый узел В (eNB), модуль в основной полосе пропускания (BBU), удаленный радиокаскад (RRH), удаленное радиооборудование (RRE), станция релейной передачи (RS), радиооборудование (RE), удаленный радиомодуль (RRU), центральный модуль обработки (СРМ) или другой тип точки доступа беспроводной глобальной вычислительной сети (WWAN). Беспроводное устройство может быть выполнено с возможностью обмена данными с использованием, по меньшей мере, одного стандарта беспроводной передачи данных, включающего в себя 3GPP LTE, WiMAX, Высокоскоростной Пакетный Доступ (HSPA), Bluetooth и WiFi. Беспроводное устройство может выполнять обмен данными, используя отдельные антенны для каждого стандарта беспроводной передачи данных или совместно используемые антенны для множества стандартов беспроводной передачи данных. Беспроводное устройство может связываться с беспроводной локальной сетью (WLAN), беспроводной персональной вычислительной сетью (WPAN) и/или WWAN.

На фиг. 7 также представлена иллюстрация микрофона и одного или больше громкоговорителей, которые можно использовать для ввода и выхода аудиоданных из беспроводного устройства. Экран дисплея может представлять собой экран жидкокристаллического дисплея (LCD), или экран дисплея другого типа, такой как дисплей на органических светодиодах (OLED). Экран дисплея может быть выполнен, как сенсорный экран. В сенсорном экране может использоваться емкостная, резистивная или другой тип технологии сенсорного экрана. Процессор приложения и графический процессор могут быть соединены с внутренним запоминающим устройством для обеспечения обработки и возможности отображения. Порт энергозависимого запоминающего устройства также можно использовать для предоставления возможностей ввода/вывода данных для пользователя. Порт энергонезависимого запоминающего устройства также можно использовать для расширения возможностей запоминающего устройства беспроводного устройства. Клавиатура может быть интегрирована с беспроводным устройством или беспроводно соединена с беспроводным устройством для обеспечения дополнительных возможностей ввода пользователя. Виртуальная клавиатура также может быть предусмотрена, используя сенсорный экран.

Различные технологии или определенные аспекты, или их части могут принимать форму программного кода (то есть, инструкции), воплощенного на физических носителях информации, таких как гибкие диски, запоминающее устройство на компакт-дисках, предназначенное только для чтения (CD-ROM), приводах жестких дисков, непереходных носителях информации, считываемых компьютером, или любых других считываемых устройством носителей информации, в которых, когда программный код загружают в и выполняют в устройстве, таком как компьютер, устройство становится устройством для выполнения на практике различных технологий. Схема может включать в себя аппаратные средства, встроенное программное обеспечение, программный код, исполнительный код, компьютерные инструкции и/или программное обеспечение. Носитель информации, считываемый непереходным компьютером, может представлять собой считываемый компьютером носитель информации, который не включает в себя сигнал. В случае выполнения программного кода на программируемых компьютерах, вычислительное устройство может включать в себя процессор, носитель информации, считываемый процессором (включая в себя энергозависимое и энергонезависимое запоминающее устройство и/или элементы сохранения), по меньшей мере, одно устройство ввода, и, по меньшей мере, одно устройство вывода. Энергозависимое и энергонезависимое запоминающее устройство и/или элементы сохранения могут представлять собой оперативное запоминающее устройство (RAM), стираемое программируемое постоянное запоминающее устройство (EPROM), привод флэш, оптический привод, привод магнитного жесткого диска, привод твердотельного устройства или другой носитель для сохранения электронных данных. Узел и беспроводное устройство также могут включать в себя модуль приемопередатчика (то есть, приемопередатчик), модуль счетчика (то есть, счетчик), модуль обработки (то есть, процессор), и/или модуль часов (то есть, часы), или модуль таймера (то есть, таймер). Одна или больше программ, которые могут воплощать или использовать различные технологии, описанные здесь, могут использовать программный интерфейс приложения (API), повторно используемые элементы управления и т.п. Такие программы могут быть воплощены на высоком уровне процедурного или объектно-ориентированного языка программирования, для связи с компьютерной системой. Однако, программа (программы) может быть воплощена на языке ассемблер или на машинном языке, если требуется. В любом случае, язык может быть компилируемым или интерпретируемым языком, и может быть скомбинирован с аппаратными воплощениями.

Используемый здесь термин «процессор» может включать в себя процессоры общего назначения, специализированные процессоры, такие как VLSI, FPGA или другие типы специализированных процессоров, а также процессоры, работающие в основной полосе пропускания, используемые в приемопередатчиках для передачи, приема и обработки беспроводной передачи данных.

Следует понимать, что многие из функциональных модулей, описанных в данном описании, были помечены как модули, для того, чтобы более конкретно подчеркнуть их независимость при воплощении. Например, модуль может быть воплощен, как аппаратная схема, содержащая специальные большие интегральные схемы (VLSI) или матрицы логических элементов, полупроводниковые приборы, имеющиеся в наличии, такие как логические микросхемы, транзисторы или другие дискретные компоненты. Модуль также может быть воплощен в программируемых устройствах, таких как программируемые пользователем матрицы логических элементов, программируемая матрица логических элементов, программируемые логические устройства и т.п.

Модули также могут быть воплощены в виде программных средств для выполнения различными типами процессоров. Идентифицированный модуль исполнительного кода может, например, содержать один или больше физических или логических блоков компьютерных инструкций, которые могут, например, быть организованы, как объект, процедура или функция. Однако, исполнительные операции идентифицированного модуля не обязательно должны быть физически расположены вместе, но могут содержать разделенные инструкции, сохраняемые в разных местоположениях, которые, при их логическом соединении вместе составляют модуль и достигают установленного назначения этого модуля.

Действительно, модуль исполняемого кода может представлять собой одну инструкцию или множество инструкций, и может даже быть распределен по нескольким разным сегментам кода, среди разных программ, и между несколькими запоминающими устройствами. Аналогично, данные операции могут быть идентифицированы и могут быть представлены здесь в пределах модулей, и могут быть воплощены в любой соответствующей форме и организованы в пределах любого соответствующего типа структуры данных. Данные операции могут быть собраны, как одиночный набор данных, или могут быть распределены по разным местоположениям, включая в себя в различных устройствах сохранения, и могут существовать, по меньшей мере, частично, просто, как электронные сигналы в системе или в сети. Модули могут быть пассивными или активными, включая в себя агенты, работающие для выполнения заданных функций.

Во всем данном описании ссылка на "пример" или "примерный" означает, что конкретное свойство, структура или характеристика, описанные совместно примером, включена в, по меньшей мере, один вариант осуществления настоящего изобретения. Таким образом, появление фраз "в примере" или слово "примерный" в различных частях, в данном описании, не обязательно все обозначают один и тот же вариант осуществления.

Используемое здесь множество элементов, структурных элементов, составляющих элементов и/или материалов, может быть представлено в общем списке для удобства. Однако, эти списки не следует рассматривать, как если бы каждый элемент этого списка был индивидуально идентифицирован, как отдельный и единственный элемент. Таким образом, ни один индивидуальный элемент такого списка не следует рассматривать, как фактически эквивалентный любому другому элементу того же списка исключительно на основе его представления в общей группе без указания противоположного. Кроме того, различные варианты осуществления и пример настоящего изобретения могут относиться здесь, вместе с альтернативами, к различным компонентам. Следует понимать, что такие варианты осуществления, примеры и альтернативы не следует рассматривать, как фактически эквивалентные друг другу, но их следует рассматривать, как отдельные и автономные представления настоящего изобретения.

Кроме того, описанные свойства, структуры или характеристики могут быть скомбинированы любым соответствующим образом в одном или больше вариантах осуществления. В следующем описании, представлены множество конкретных деталей, таких как примеры компоновок, расстояний, примеры сети и т.д., для предоставления полного понимания вариантов осуществления изобретения. Для специалиста в соответствующей области техники будет понятно, однако, что изобретение может быть выполнено на практике без одной или больше конкретных деталей, или с использованием других способов, компонентов, компоновок и т.д. В других случаях, хорошо известные структуры, материалы или операции не показаны и не описаны подробно, для исключения загромождения аспектами изобретения.

В то время как представленные выше примеры являются иллюстративными для принципов настоящего изобретения в одном или больше конкретных вариантах применения, для специалистов обычного уровня в данной области техники будет понятно, что различные модификации по форме, использованию и деталям варианта осуществления могут быть выполнены без использования изобретательности, и без выхода за пределы принципов и концепций изобретения. В соответствии с этим, не предполагается, что изобретение будет ограничено чем-либо, за исключением формулы изобретения, представленной ниже.

1. Объект управления мобильностью (ММЕ), характеризующийся тем, что выполнен с возможностью обеспечивать возврат в сеть с коммутацией каналов (CSFB) для оборудования пользователя (UE), причем ММЕ содержит один или более процессоров, выполненных с возможностью:

принимать от UE индикатор оптимизированной характеристики CSFB, определяющий оптимизированную характеристику CSFB для UE;

принимать тип запрашиваемой услуги, связанный с UE;

инициировать передачу обслуживания с непрерывностью одиночного голосового радиовызова (SRVCC) для UE в сеть с коммутацией каналов на основе оптимизированной характеристики CSFB для UE;

передавать сообщение запроса протокола приложения S1 (S1-АР) в развернутый узел В (eNB), причем сообщение запроса S1-АР включает в себя индикатор оптимизированной характеристики CSFB и индикатор непрерывности одиночного голосового радиовызова (SRVCC) для UE, при этом ММЕ выполнен с возможностью выбора индикатора SRVCC на основе типа запрашиваемой услуги; и

принимать от UE сообщение о необходимости передачи обслуживания, при этом eNB выполнен с возможностью передавать в ММЕ сообщение о необходимости передачи обслуживания при инициировании передачи обслуживания SRVCC для UE в сеть с коммутацией каналов сетью с коммутацией пакетов частично на основе индикатора оптимизированной характеристики CSFB и индикатора SRVCC.

2. ММЕ по п. 1, в котором один или более процессоров дополнительно выполнены с возможностью принимать от UE индикатор оптимизированной характеристики CSFB через сообщение запроса прикрепления или сообщение запроса на обновление области отслеживания (TAU).

3. ММЕ по п. 1, в котором один или более процессоров дополнительно выполнены с возможностью принимать от UE индикатор оптимизированной характеристики CSFB через сообщение запроса расширенной услуги.

4. ММЕ по п. 1, в котором один или более процессоров дополнительно выполнены с возможностью идентифицировать индикатор оптимизированной характеристики CSFB на основе сообщения подтверждения обновления местоположения, принимаемого от опорного абонентского сервера (HSS), причем сообщение подтверждения обновления местоположения включает в себя профиль абонента UE, указывающий оптимизированную характеристику CSFB для UE.

5. ММЕ по п. 1, в котором один или более процессоров дополнительно выполнены с возможностью принимать тип запрашиваемой услуги от центра мобильной коммутации (MSC) через сообщение запроса вызова.

6. ММЕ по п. 1, в котором индикатор оптимизированной характеристики CSFB равен "0" для указания, что UE не поддерживает CSFB на основе SRVCC, или "1" для указания, что UE поддерживает CSFB на основе SRVCC.

7. ММЕ по п. 1, в котором один или более процессоров дополнительно выполнены с возможностью принимать от UE сообщение запроса расширенной услуги для мобильного инициируемого (МО) вызова.

8. ММЕ по п. 1, в котором один или более процессоров дополнительно выполнены с возможностью принимать сообщение запроса вызова от центра мобильной коммутации (MSC) для мобильного завершаемого (МТ) вызова.

9. ММЕ по п. 1, в котором сеть с коммутацией каналов представляет собой Универсальную наземную сеть радиодоступа (UTRAN) или Глобальную систему мобильной связи (GSM) с повышенной скоростью передачи данных для сети радиодоступа развития GSM (GERAN).

10. ММЕ по п. 1, в котором тип запрашиваемой услуги представляет собой одно из: голосовых данных, видеоданных, неструктурированных вспомогательных данных услуги (USSD), услуги определения местоположения (LCS) или неизвестного типа.

11. ММЕ по п. 1, в котором индикатор SRVCC выполнен с возможностью уведомлять eNB, следует ли инициировать SRVCC/видео SRVCC (vSRVCC), причем индикатор SRVCC равен "0" для указания для eNB, что не ожидается ни SRVCC/vSRVCC, ни традиционного CSFB, индикатор SRVCC равен "1" для указания для eNB, что ожидается SRVCC, индикатор SRVCC равен "2" для указания для eNB, что ожидается vSRVCC.

12. ММЕ по п. 1, в котором один или более процессоров дополнительно выполнены с возможностью инициировать процедуру передачи облуживания из сети с коммутацией пакетов в сеть с коммутацией каналов (PS-CS), когда отсутствует носитель с CQI=1, ассоциированный с UE.

13. ММЕ по п. 1, в котором один или более процессоров дополнительно выполнены с возможностью инициировать процедуру передачи обслуживания из сети с коммутацией пакетов в сеть с коммутацией каналов (PS-CS), когда тип запрашиваемой услуги представляет собой голосовые данные или видеоданные, путем передачи сообщения запроса PS в CS с целью SRVCC в сервер центра мобильной коммутации (MSC), при этом сообщение запроса PS в CS включает в себя индикатор оптимизированной характеристики CSFB.

14. Развернутый узел В (eNB), характеризующийся тем, что выполнен с возможностью обеспечивать оптимизированный возврат в сеть с коммутацией каналов (CSFB) для оборудования пользователя (UE), при этом eNB содержит один или более процессоров, выполненных с возможностью:

принимать индикатор оптимизированной характеристики CSFB, который определяет оптимизированную характеристику CSFB для UE;

принимать индикатор непрерывности одиночного голосового радиовызова (SRVCC) для UE;

инициировать передачу обслуживания SRVCC для UE в сеть с коммутацией каналов частично на основе индикатора оптимизированной характеристики CSFB и индикатора SRVCC; и

передавать сообщение о необходимости передачи обслуживания в объект управления мобильностью (ММЕ) при инициировании сетью с коммутацией пакетов передачи обслуживания SRVCC;

при этом индикатор оптимизированной характеристики CSFB и индикатор SRVCC принимаются на eNB посредством сообщения запроса протокола приложения S1 (S1-АР) от объекта управления мобильностью (ММЕ), причем индикатор SRVCC выбран на основе типа запрашиваемой услуги, связанного с UE.

15. eNB по п. 14, в котором один или более процессоров дополнительно выполнены с возможностью принимать от UE индикатор оптимизированной характеристики CSFB через индикатор выделенной группы (FGI).

16. eNB по п. 14, в котором один или более процессоров дополнительно выполнены с возможностью инициировать передачу обслуживания SRVCC для UE в сеть с коммутацией каналов, когда отсутствует носитель с CQI=1, ассоциированный с UE.

17. eNB по п. 14, в котором один или более процессоров дополнительно выполнены с возможностью принимать от ММЕ индикатор оптимизированной характеристики CSFB.

18. eNB по п. 14, в котором индикатор SRVCC выполнен с возможностью уведомлять eNB, следует ли инициировать SRVCC/видео SRVCC (vSRVCC), причем индикатор SRVCC равен "0" для указания для eNB, что не ожидается ни SRVCC/vSRVCC, ни традиционного CSFB, индикатор SRVCC равен "1" для указания для eNB, что ожидается SRVCC, индикатор SRVCC равен "2" для указания для eNB, что ожидается vSRVCC.

19. eNB по п. 14, в котором сеть с коммутацией каналов представляет собой Универсальную наземную сеть радиодоступа (UTRAN) или Глобальную систему мобильной связи (GSM) с повышенной скоростью передачи данных для сети радиодоступа развития GSM (GERAN).

20. Способ обеспечения оптимизированного возврата в сеть с коммутацией каналов (CSFB), содержащий этапы, на которых:

передают от оборудования пользователя (UE) индикатор оптимизированной характеристики CSFB в объект управления мобильностью (ММЕ); и

передают от UE тип запрашиваемой услуги в ММЕ, при этом ММЕ выполнен с возможностью инициировать передачу обслуживания с непрерывностью одиночного голосового радиовызова (SRVCC) для UE в сеть с коммутацией каналов частично на основе оптимизированной характеристики CSFB и типа запрашиваемой услуги и передавать сообщение запроса протокола приложения S1 (S1-АР) в развернутый узел В (eNB) для передачи обслуживания SRVCC, причем сообщение запроса S1-АР включает в себя указанный индикатор оптимизированной характеристики CSFB и индикатор непрерывности одиночного голосового радиовызова (SRVCC), основанный на типе запрашиваемой услуги.

21. Способ по п. 20, дополнительно содержащий этап, на котором: передают индикатор оптимизированной характеристики CSFB от UE в ММЕ через сообщение запроса прикрепления или сообщение запроса обновления области отслеживания (TAU).

22. Способ по п. 20, дополнительно содержащий этап, на котором: передают по меньшей мере одно из индикатора оптимизированной характеристики CSFB или типа запрашиваемой услуги из UE в ММЕ через сообщение запроса расширенной услуги.

23. Способ по п. 20, в котором индикатор оптимизированной характеристики CSFB равен "0" для указания, что UE не поддерживает CSFB на основе SRVCC, или "1" для указания, что UE поддерживает CSFB на основе SRVCC.

24. Способ по п. 20, в котором тип запрашиваемой услуги представляет собой один из: голосовых данных, видеоданных, неструктурированных вспомогательных данных услуги (USSD), услуги определения местоположения (LCS) или неизвестного типа.