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

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

Иллюстрации

Показать все

Реферат

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

В технологии беспроводной мобильной связи используются различные стандарты и протоколы для передачи данных между узлом (например, станцией передачи) и беспроводным устройством (например, мобильным устройством). Некоторые беспроводные устройства выполняют обмен данными, используя множественный доступ с ортогональным частотным разделением каналов (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 или нет. В качестве неограничительных пр