Результат интеллектуальной деятельности: ВОССТАНОВЛЕНИЕ УПРАВЛЕНИЯ ПОЛЬЗОВАТЕЛЬСКИМ ОБОРУДОВАНИЕМ ПРИ НАЛИЧИИ ОТКАЗА ЛИНИИ СВЯЗИ МЕЖДУ УЗЛАМИ УПРАВЛЕНИЯ С КОММУТАЦИЕЙ ПАКЕТОВ И С КОММУТАЦИЕЙ КАНАЛОВ

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

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

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

Как показано на фиг. 1, пользовательское оборудование (UE) 101 может взаимодействовать в цифровой области (то есть через приемопередачу пакетов данных) с помощью системы 100 с развитой коммутацией пакетов (EPS) с использованием механизмов радиодоступа, предоставляемых развитой универсальной наземной сетью 103 радиодоступа (E-UTRAN). Интерфейс между UE и E-UTRAN обозначен "LTE-Uu". Это новейшее оборудование предоставляет услуги связи для UE 101 (одновременно голосовую и другую информацию) посредством технологии с коммутацией пакетов (PS). Сигнализация управления, связанная с UE, осуществляется с помощью объекта 105 управления мобильностью (ММЕ) с поддержкой информации о подписке, предоставляемой домашним сервером 107 абонента (HSS). ММЕ 105 поддерживает связь с E-UTRAN 103 через интерфейс S1-MME. ММЕ 105 взаимодействует с HSS 107 через интерфейс S6A. ММЕ может также взаимодействовать с одним или более другими ММЕ посредством интерфейса S10.

Управление полезной нагрузкой пользователя осуществляется с помощью обслуживающего шлюза (S-GW) 109 и шлюза 111 сети пакетной передачи данных (PDN) (P-GW). S-GW 109 соединяется с E-UTRAN через Sl-U-интерфейс, и S-GW 109 соединяется с P-GW 111 через интерфейс S5. P-GW 111 может взаимодействовать через интерфейс Gx с функцией 113 правил политики и начисления счетов (PCRF).

Услуги 115 Интернет-протокола (IP) оператора (например, мультимедийная подсистема (IMS) (Интернет-протокола) и т.д.) может распространяться с помощью P-GW 111 через интерфейс SGi, и PCRP 113 может взаимодействовать с 1Р-услугами 115 оператора через интерфейс Rx.

Система также предусматривает взаимодействие с технологией унаследованной системы. Например, ММЕ 105 может взаимодействовать с обслуживающим узлом 117 поддержки GPRS (услуги пакетной радиосвязи общего назначения) (SGSN) через интерфейс S3. Для поддержки линий связи с коммутацией каналов (CS) выполнен центр 119 коммутации мобильной связи (MSC), который может поддерживать связь с ММЕ 105 посредством двух различных интерфейсов: интерфейса SGs и интерфейса Sv.

Так как развертывание нового типа системы является постепенным процессом, вводятся в действие механизмы, которые позволяют новой системе (например, на основе PS) сосуществовать с унаследованными системами (например, на основе CS), которые были уже введены в действие, и полезно (а иногда и необходимо), чтобы услугу UE можно было переключать с одного типа поддержки услуги на другой, основываясь на своем перемещении и типе поддержки услуги, которая доступна в любой конкретной зоне. Поэтому настоящие варианты осуществления позволяют UE получить услугу не только из самого современного оборудования с коммутацией пакетов, но также и из унаследованных систем, которые используют технологию CS. Регистрация для домена CS выполняется с помощью ММЕ 105 и центра 119 коммутации мобильной связи (MSC) (унаследованной системы) посредством взаимодействия с иллюстрированным интерфейсом SGs. Как известно в данной области техники, отдельная непрерывность голосового вызова на радиоинтерфейсе (SRVCC) является процессом/технологией, с помощью которой продолжающийся речевой вызов, который в текущий момент времени обрабатывается с помощью мультимедийной подсистемы (IMS) на основе VoIP (голосовая связь через 1Р)/1Р (Интернет-протокол) в домене с коммутацией пакетов данных может перейти в домен с коммутацией каналов унаследованной системы. Функция SRVCC выполняется посредством иллюстрированного интерфейса Sv.

Как показано на фиг. 2а, сеть 3GPP можно также организовать, используя многочисленные ММЕ, обслуживающие одинаковые зоны отслеживания сети радиосвязи долгосрочного развития (LTE). Организация многочисленных ММЕ упоминается как "ММЕ-пул".

В примере, показанном на фиг. 2а, первый ММЕ-пул 201 содержит ММЕ 1 и 2 и обслуживает зоны 1 и 2 обслуживания развитого узла В (eNB), обозначенные как пул-зона 1 PS. Второй ММЕ-пул 203 содержит ММЕ 3, 4 и 5 и обслуживает зоны 3, 4, 5 и 6 обслуживания eNB, обозначенные как пул-зона 2 PS. Хотя это не показано в этом примере, следует отметить, что один или более eNB могут находиться в более чем одной пул-зоне PS (например, зона 3 может находиться в пул-зоне 1 PS и в пул-зоне 2 PS).

Как показано на фиг. 2b, сеть 3GPP можно также организовать, используя многочисленные SGSN, обслуживающие одинаковые зоны маршрутизации сети радиосвязи GERAN (сети радиодоступа EDGE (усовершенствованной технологии передачи данных для развития GSM) GSM (глобальной системы мобильной связи))/UTRAN. Организация многочисленных SGSN упоминается как "SGSN-пул". Аналогичным образом, сеть 3GPP может включать в себя организацию многочисленных MSC, обслуживающих одинаковые зоны местоположения сети радиосвязи GERAN/UTRAN, причем эта организация упоминается как "MSC-пул".

В примере, показанном на фиг. 2b, первый MSC-пул 205 содержит MSC 1, 2 и 3 и обслуживает зоны 1, 2, 5 и 6 обслуживания узла RAN, обозначенные как пул-зона 1 CS. Второй MSC-пул 207 содержит MSC 4, 5 и 6 и обслуживает зоны 2, 3, 6 и 7 обслуживания узла RAN, обозначенные как пул-зона 2 CS. Следует отметить, что две из зон обслуживания узла RAN, а именно зоны 2 и 6, находятся в пул-зоне 1 CS и в пул-зоне 2 CS.

Фиг. 2b дополнительно иллюстрирует первый SGSN-пул 209, который содержит SGSN 1 и 2 и обслуживает зоны 1 и 5 обслуживания узла RAN, обозначенные как пул-зона 1 PS. Второй SGSN-пул 211 содержит SGSN 3, 4 и 5 и обслуживает зоны 2, 3, 6 и 7 обслуживания узла RAN, обозначенные как пул-зона 2 PS.

На фиг. 2b также показан единственный MSC 213, обслуживающий зоны 4 и 8 обслуживания RAN; и также показывают единственный SGSN 215, обслуживающий зоны 4 и 8 обслуживания RAN.

Процедура восстановления обслуживания, инициированная ММЕ

Существует два различных сценария отказа, применимых к интерфейсу SGs, который может инициировать ММЕ для выполнения перерегистрации UE в домене CS либо в ранее обслуживающем MSC или в новом MSC. Случай, включающий в себя новый MSC, требует, чтобы применялся MSC-пул. Эти два случая представляют собой:

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

Перезапуск MSC или ММЕ: это обнаруживается в результате индикации перезапуска при связи между узлами после того, как оба узла переходят снова в рабочее состояние.

Когда ММЕ принимает индикатор из обслуживающего MSC/VLR относительно того, что произошел перезапуск VLR, или если VLR больше не обслуживается, если больше не существует ассоциаций протокола передачи с управлением потоком (SCTP) при обслуживании с помощью этого VLR в течение заданного периода времени, то ММЕ инициирует процедуру восстановления SGs следующим образом:

1) после получения комбинированного запроса на обновление зоны отслеживания (ТА) или периодического запроса на обновление зоны отслеживания из UE, которое подключено к обеим услугам EPS и не EPS, ММЕ может отправить запрос в UE на повторное подключение услуг не EPS, или альтернативно UE может сразу выполнить обновление информации о местоположении (LU) для процедуры услуг не EPS в отношении регистра местоположения посетителей (VLR),

2) после приема комбинированной ТА/LA (обновления или периодического обновления зоны отслеживания из UE, которое подключено к услуге не EPS) ММЕ может также:

а: отправить запрос в UE на повторное подключение к услугам не EPS и затем выбрать альтернативный доступный VLR, чтобы предоставить UE услуги CS во время последующей процедуры комбинированного обновления TA/LA;

b: или сразу выполнить обновление информации о местоположении для процедуры предоставления услуг не EPS в отношении альтернативного доступного VLR,

3) после приема транспортного сообщения уровня, не связанного с предоставлением доступа (NAS) восходящей линии связи из UE, которое подключено для предоставления услуги не EPS, если регистр местоположения посетителей (VLR), обслуживающий UE, больше не обслуживает, ММЕ может отправить запрос в UE для повторного подключения к услугам не EPS и затем выбрать альтернативный доступный VLR, чтобы обслуживать UE для службы коротких сообщений (SMS) МО и других услуг CS во время последующей процедуры обновления комбинированной ТА/LA. Для получения более подробной информации смотри 3GPP TS 29.118. Эта процедура, хотя и не указана в данном стандарте, является функционально жизнеспособным подходом для случаев обработки, в которых UE находится уже в состоянии ECM-CONNECTED (ЕСМ подсоединено).

Для интерфейса Sv, так как нет никакой процедуры регистрации в отношении к MSC для заданного UE, который отличается от интерфейса SGs, где ассоциация SGs должна быть установлена прежде, чем можно будет продолжить процедуры возврата в исходный режим CS, ММЕ будет обеспечивать контакт с MSC только тогда, когда потребуется хэндовер SRVCC при переходе от сети с коммутацией пакетов к сети с коммутацией каналов ("SRVCC PS to CS"); то есть, когда UE будет перемещаться в зону покрытия 2G/3G и покидать зону покрытия LTE, где происходящий голосовой узел должен быть передан из домена PS в домен CS. Таким образом, когда функциональные возможности SRVCC были активизированы и был обнаружен отказ тракта в интерфейсе Sv при попытке сделать запрос SRVCC при переходе от PS-сети к CS-сети в отношении выбранного MSC, ММЕ пытается выполнить процедуру "SRVCC PS to CS" для любого другого доступного MSC с использованием интерфейса Sv. Конечно, для этого требуется, чтобы не было более чем одного MSC, обслуживающего Sv и местоположение UE (то есть, должен быть развернут MSC-пул). Но в случае, когда MSC не доступен для ММЕ, должна быть запущена процедура восстановления, инициированная ММЕ; в противном случае голосовой вызов будет завершен в связи с тем, что UE покинет зону покрытия LTE.

Восстановление SGs, инициированное MSC (для получения дополнительной информации смотри 3GPP TS 23.007, глава 26)

Когда VLR должен отправить пейджинговый запрос в UE для предоставления услуги CS мобильного получателя сообщения (МТ) (например, после получения входящего вызова CS), если VLR обнаруживает, что ММЕ, обслуживающий UE, больше не обслуживает, VLR должен отправить пейджинговый запрос SGs с индикатором восстановления CS в альтернативный ММЕ в одном и том же ММЕ-пуле. VLR должен сбалансировать нагрузку пейджинговых запросов среди доступных ММЕ в пуле во время процедуры восстановления во избежание чрезмерной загруженности одного или только нескольких ММЕ в пуле.

VLR может узнать о наборе ММЕ, которые относятся к одному и тому же ММЕ-пулу, по локальной конфигурации или путем проверки ID группы ММЕ в пределах названия ММЕ, о котором ММЕ передают сигналы в VLR в виде сообщений SGsAP-LOCATION-UDATE-REQUEST, SGsAP-RESET-INDICATION или SGs АР-RESET-АСК. ММЕ должен отправить сообщение SGsAP-RESET-INDICATION в VLR после перезапуска.

VLR может обнаружить, что ММЕ больше не обслуживает, если больше нет SCTP-ассоциаций, которые обслуживаются этим ММЕ.

ММЕ должен принять пейджинговый запрос SGs и выполнить следующие действия после получения пейджингового запроса SGs, который включает в себя индикатор восстановления CS:

- если международный идентификатор мобильного абонента (IMSI) неизвестен ММЕ, или если IMSI известен, и UE отмечен как управление мобильностью EPS (EMM)-DEREGISTERED, то ММЕ должен отправить пейджинговый запрос с информацией о местоположении, предоставленной VLR, независимо от значения индикатора "ММЕ-Reset". Если никакой такой информации о местоположении не предоставлено, ММЕ может отправить пейджинговый запрос в UE во всех зонах отслеживания, соответствующих этому ММЕ, или в зонах отслеживания, обслуживаемых ММЕ и VLR, или может отклонить пейджинговый запрос, исходя из политики оператора. Пейджинговый запрос должен включать в себя IMSI и индикатор домена CN, установленный на "PS" для отправки запроса в UE с целью повторного подключения;

- если IMSI известен ММЕ, и UE рассматривается как подключенный одновременно к услугам EPS и не EPS или только для SMS (для пейджингового запроса SGs с "индикатором SMS"), то ММЕ должен отправить пейджинговый запрос в UE на основании информации о местоположении, хранящейся в ММЕ.

После получения пейджингового запроса, включающего в себя IMSI и индикатор домена CN, установленный на "PS", UE повторно подключается к одному ММЕ из пула (который, в частности, не обязательно должен быть ММЕ, который инициировал процедуру поискового вызова по отношению к UE), и устанавливается новая ассоциация SGs с VLR. Этот VLR может быть не таким VLR, который инициировал процедуру поискового вызова SGs (например, если для GERAN или UTRAN применяется соединение внутри домена узлов RAN с многочисленными узлами CN (смотри 3GPP TS 23.236)).

Если новая ассоциация SGs устанавливается по отношению к одному и тому же VLR, VLR должен повторить пейджинговый запрос SGs после того, как UE повторно подключится к услугам не EPS. Затем предоставляется услуга CS МТ или SMS в соответствии с обычными процедурами.

Если новая ассоциация SGs устанавливается по отношению к другому VLR, услуга CS МТ может предоставляться через новый VLR, используя повторную попытку роуминга для завершения мобильной связи или перенаправление роуминга для завершения мобильной связи (смотри 3GPP TS 23.018); продолжающаяся МТ SMS повторно передается с помощью SMS-SC с использованием существующих процедур SMS (SMS-оповещение).

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

В сценарии, в котором ММЕ не имеет возможности достичь MSC, UE не обслуживается совместными процедурами, но вместо этого ограничивается только услугами развитого пакетного ядра (ЕРС). Кроме того, в таких случаях будет невозможен хэндовер "SRVCC PS to CS".

Существующие модели поведения, заданные в современных спецификациях 3GPP, не являются оптимальными в случае, если ошибка связи является локальной по отношению к ММЕ в ММЕ-пуле, и существуют другие ММЕ в том же самом пуле, которые имеют соединение с подходящим(и) MSC. В этом случае неоптимальным является то, что UE отвергает услуги CS, несмотря на то, что MSC является/являются доступными для ММЕ-пул а при использовании другого ММЕ.

Когда ММЕ страдает от нарушений связности со всеми MSC, то есть когда больше не существует какой-либо связности в интерфейсе SGs, ММЕ больше не будет принимать какой-либо вызов МТ (МТ Call) или обслуживать вызов, инициируемый мобильным объектом (МО) для обслуживаемых UE, которые подключаются комбинированным образом. При этом SRVCC будет также невозможна.

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

В данном документе отмечено, что при этом подходе существуют некоторые проблемы.

Если ошибка связности SGs/Sv является общей для всех ММЕ в ММЕ-пуле, новый ММЕ также будет не в состоянии выполнять сигнализацию SGs/Sv. Результатом будет то, что новый ММЕ будет также отрицать комбинированное подключение UE. При этом SRVCC будет также невозможна. Кроме того, перемещение UE из одного ММЕ в другой будет вызывать дополнительную сигнализацию.

Затем UE будет пытаться выполнить изменение доступа для того, чтобы получить CS, подключенную к системе 2G/3G (ориентированной на передачу голосовых сообщений) или будет альтернативно оставаться в доступе LTE и больше не сможет использовать услуги CS (ориентированные на передачу данных). Продолжающийся вызов с поддержкой голосовой связи LTE (VoLTE) может быть также прекращен при выходе из зоны покрытия LTE.

Если UE остается в доступе LTE, поведение системы связи подвергается риску вхождения в цикл с никогда не заканчивающейся последовательностью выполнения процедуры TAU интер-ММЕ, влияющей на все UE, которые делают запросы для получения услуг, которые относятся к интерфейсу (I/F) SGs.

В случае, если проблема является локальной только для некоторых ММЕ в ММЕ-пуле, подход будет успешным, и UE в конечном счете будет зарегистрировано ММЕ, который имеет возможность передавать сигналы в I/F SGs.

Однако вместе с этим возникнет проблема выравнивания нагрузки, так как UE, которые ориентированы на передачу данных и которые решают остаться обслуживаемыми с доступом LTE, перемещаются из ММЕ, который потерял связность SGs, в ММЕ, который не имеет этой проблемы. Результат состоит в том, что все UE, которые отправляют запрос "Circuit Switched FallBack" (возврат в исходный режим коммутации каналов) (CSFB -называется так потому, что этот признак обеспечивает услуги голосовой связи, которые будут предоставляться оборудованию, которое позволяет осуществлять пакетную передачу данных посредством унаследованных сетевых элементов с коммутацией каналов), концентрируются в некоторых ММЕ в пуле, тем самым делая распределение UE и результирующую нагрузку узла больше не рандомизированными во всех узлах в пуле.

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

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

Раскрытие изобретения

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

В соответствии с одним из ряда аспектов настоящего изобретения вышеизложенные и другие задачи решены в технологии (например, способы, устройство, считываемые процессором носители информации), которая восстанавливает управление пользовательским оборудованием при наличии отказа линии связи между сетевым узлом, который обеспечивает управление соединениями с коммутацией пакетов, и сетевым узлом, который обеспечивает управление соединениями с коммутацией каналов. В некоторых, но не обязательно во всех вариантах осуществления, услуга связи предоставляется UE обслуживающим ММЕ и обслуживающим MSC в системе связи. В некоторый момент времени обнаруживается, что одна или более линий связи, которые обеспечивают связь между обслуживающим ММЕ и обслуживающим MSC, вышли из строя. В пределах сети идентифицируются/идентифицируется другие/другой ММЕ и/или MSC, которые имеют/который имеет полностью функционирующие линии связи с обслуживающим MSC и/или обслуживающим ММЕ. Сигнализация выполняется для того, чтобы установить идентифицированные ММЕ и/или MSC, или любой другой тип объекта, который может служить в качестве ретрансляционного ММЕ и/или ретрансляционного MSC. Управление UE продолжается с помощью ретрансляционного ММЕ, осуществляющего обмен сообщениями с обслуживающим MSC или ретрансляционным MSC, и/или с помощью ретрансляционного MSC, осуществляющего обмен сообщениями с обслуживающим ММЕ или ретрансляционным ММЕ, и, кроме того, с помощью ретрансляционного ММЕ, ретранслирующего сообщения в обслуживающий ММЕ, и/или с помощью ретрансляционного MSC, ретранслирующего сообщения в обслуживающий MSC.

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

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

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

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

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

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

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

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

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

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

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

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

обслуживающего узла первого типа, отправляющего в первый ретрансляционный узел одно или больше сообщений, которые направляются в обслуживающий узел второго типа; и

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

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

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

фиг. 1 - схема UE, получающего услугу связи из развитой системы передачи данных с коммутацией пакетов;

фиг. 2а - схема части сети 3GPP, которая включает в себя ММЕ-пулы;

фиг. 2b - схема части сети 3GPP, которая включает в себя MSC-пулы и SGSN-пулы;

фиг. 3 - диаграмма сигнализации, на которой пейджинговый запрос "МТ Call" принимается в другом ММЕ, при этом обслуживающий ММЕ продолжает функционировать с поддержкой ретрансляционной сигнализации;

фиг. 4 - диаграмма сигнализации, на которой пейджинговый запрос "МТ Call" принимается в другом ММЕ, причем обслуживающий ММЕ использует только начальную ретрансляционную сигнализацию;

фиг. 5 - диаграмма сигнализации, на которой запрос "Combined Attach/TAU" (Комбинированное подключение/TAU) обрабатывается в ММЕ без какого-либо I/F SGs в обслуживающем ММЕ, и в дальнейшем происходит вызов "МТ Call";

фиг. 6 - диаграмма сигнализации, иллюстрирующая использование другого ММЕ для ретрансляции сообщения Sv в случае, когда отсутствует функциональный I/F Sv в обслуживающем ММЕ;

фиг. 7 - блок-схема универсального узла, который может быть любым одним из: eNB, ММЕ или MSC в примерных вариантах осуществления в соответствии с изобретением;

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

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

Осуществление изобретения

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

Различные аспекты настоящего изобретения будут теперь описаны более подробно в связи с рядом примерных вариантов осуществления. Для облегчения понимания изобретения многие аспекты изобретения описаны с учетом последовательностей действий, которые будут выполняться элементами компьютерной системы или другими аппаратными средствами, которые способны исполнять запрограммированные инструкции. Следует принимать во внимание, что в каждом из вариантов осуществления различные действия могут быть выполнены с помощью специализированных схем (например, аналоговых и/или дискретных логических элементов, соединенных между собой с возможностью выполнения специальной функции), с помощью одного или более процессоров, запрограммированных с помощью подходящего набора инструкций или с помощью комбинации и того и другого. Выражение "схема, выполненная с возможностью" выполнения одного или более описанных действий, используется в данном документе в отношении любого такого варианта осуществления (то есть одной или более специализированных схем и/или одного или более запрограммированных процессоров). Кроме того, настоящее изобретение можно дополнительно рассматривать как полностью воплощенным в любой форме машиночитаемого носителя информации, такого как твердотельная память, магнитный диск или оптический диск, содержащий соответствующий набор компьютерных инструкций, которые будут предписывать процессору выполнять технологии, описанные в данном документе. Таким образом, различные аспекты изобретения могут быть воплощены во многих различных формах, и все такие формы рассматриваются как входящие в объем настоящего изобретения. Для каждого из различных аспектов изобретения любая такая форма вариантов осуществления, как описано выше, может упоминаться здесь как "логическая схема, выполненная с возможностью" выполнять описанное действие или, альтернативно, как "логическая схема, которая" выполняет описанное действие.

Как уже упоминалось в разделе "Уровень техники", желательно выполнить технологию (например, способы, устройства, считываемый процессором носитель информации и т.д.), которая позволила бы обеспечить механизм резервирования для установления повторного соединения между, с одной стороны, объектом, таким как ММЕ, и, с другой стороны, объектом, таким как MSC, когда возникают проблемы у первоначально используемого механизма повторного соединения.

В одном аспекте эта задача решена с помощью технологий, в которых используются другой ММЕ или любой другой сетевой объект, такой как прокси сообщения SGs/Sv, для ретрансляции сообщения SGs/Sv в обслуживающую MSC или в доступный MSC (для процедур восстановления инициированных ММЕ, например, для периодического TAU).

Аналогичным образом, другой аспект механизма резервирования включает в себя использование другого MSC или любого другого сетевого объекта, такого как прокси сообщения SGs/Sv, для ретрансляции сообщения SGs/Sv в обслуживающий ММЕ или в доступный ММЕ, (который затем перенаправляет сообщение SGs/Sv в обслуживающий ММЕ). Например, это можно применять в случае процедур восстановления, инициированных MSC (например, МТ Call).

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

Некоторые аспекты улучшения (которые служат в качестве резервного) для процедуры восстановления SGs или Sv, инициируемой ММЕ, когда невозможно выбрать другой доступный MSC для выполнения восстановления SGs, представляют собой:

1) обслуживающий ММЕ (уже существующий) поддерживает зарегистрированный UE, но использует другой ММЕ в ММЕ-пуле или любой другой сетевой объект в качестве линии связи (прокси или ретрансляционной), чтобы достичь MSC при возникновении событий, инициированных UE (например, после приема периодического запроса TAU, комбинированного запроса TAU, запроса на обслуживание, сообщения относительно транспортировки NAS UL или после запроса SRVCC). Любая последующая сигнализация SGs/Sv для этого UE затем ретранслируется через этот прокси/ретрансляционный ММЕ (выбранный с помощью обслуживающего ММЕ);

2) ММЕ, который сталкивается с общим отказом SGs/Sv, может применять логику, которая перемещает регистрацию UE в другой ММЕ в ММЕ-пуле, где выбранный "новый" ММЕ не сталкивается с общим отказом SGs/Sv.

Использовать ли альтернативный вариант #1 или #2 является вопросом политики оператора и, возможно, продолжительностью отказа SGs. Перемещение UE имеет последствия с момента его подключения PS, и перемещение многочисленных UE может также вызвать неравномерное распределение нагрузки в пуле. Выбор альтернативного ММЕ, имеющего свой интерфейс SGs в рабочем состоянии, может базироваться на информации относительно эксплуатации и поддержки сетей (О&М). Альтернативно, в более продвинутых вариантах осуществления ММЕ сразу после обнаружения полного отказа тракта SGs/Sv или отказа тракта по всему интерфейсу SGs по отношению к зарегистрированному MSC отправляет широковещательное сообщение (новый тип сообщения, которое предпочтительно называется "запрос на опрос SGs/Sv") по отношению ко всем ММЕ в пуле для опроса относительно того, является ли доступным любой другой ММЕ для связи SGs/Sv. В ответ на получение запроса на опрос SGs/Sv другие ММЕ в пуле передают отчет о своем статусе SGs/Sv.

Другое улучшение в некоторых, но не обязательно во всех вариантах осуществления, процедуры SGs, инициированной MSC, включает в себя, в дополнение к тому, что указано в главе 26 TS 23.007, когда другой ММЕ должен быть выбран в качестве получателя пейджингового запроса SGs:

Когда ММЕ принимает запрос "SGs-Paging-Request" (пейджинговый запрос SGs) с флагом восстановления CS, он ретранслирует пейджинговый запрос SGs в текущий обслуживающий ММЕ путем инкапсуляции пейджингового запроса SGs через новое сообщение GTPv2, которое предпочтительно называется "прямой передачей", поверх интерфейса между ММЕ. В качестве альтернативы, ретрансляционный ММЕ ретранслирует пейджинговый запрос SGs АР между конечными точками (одноранговыми узлами сети) I/F S10, используя непосредственно стек протоколов, который отличается от стека протоколов на основе GTP, обычно используемого в I/F S10. ММЕ сможет найти обслуживающий ММЕ, используя полностью квалифицированное доменное имя (FQDN) ММЕ, и любая последующая SGs для этого UE будет ретранслироваться через этот ретрансляционный ММЕ (выбранный MSC) или любой другой ретрансляционный ММЕ путем инкапсуляции последующих сообщений SGs через новое сообщение GTPv2 (предпочтительно называемое "прямой передачей") поверх интерфейса между ММЕ. В качестве альтернативы, ретрансляционный ММЕ ретранслирует сигнализацию SGs между конечными точками (одноранговыми узлами сети) I/F S10, используя непосредственно стек протоколов, который отличается от стека протоколов на основе GTP, который обычно используется в I/F S10. Это основано на аспекте примерных вариантов осуществления, в которых FQDN обслуживающего ММЕ добавляется в сообщение "SGs-Paging-Request" и в другие сообщения SGs, отправленные из MSC в ММЕ. В дополнение, это основано на аспекте примерных вариантов осуществления, в которых идентификатор, обслуживающий MSC, добавляется в сообщение SGs (например, "SGs-Service-Request" (запрос на обслуживание SGs) и другие сообщения SGs, отправленные из ММЕ в MSC), и дополнительно основано на новой индикации в этих сообщениях SGs при их отправке из ММЕ в MSC (например, "SGs-Location-Update-Request" (запрос на обновление местоположения SGs), "SGs-Service-Request" и т.д.), чтобы обслуживающий MSC мог узнать, что сообщение исходит из обслуживающего ММЕ, а не из прокси/ретрансляционного ММЕ. Следует отметить, что такой индикатор добавляется с помощью обслуживающего ММЕ.

После возникновения отказа сети при поддержании связи с текущим обслуживающим ММЕ таким образом, чтобы предотвратить MSC, где зарегистрировано UE, от выполнения процедуры "SRVCC PS to CS" (как определено в разделе 6.4.3.1 3GPP TS 23.216) или от отправки пейджингового запроса SGs, подвергшийся негативному воздействию MSC, предполагая, что он находится в MSC-пуле, применяет процесс восстановления, в котором он использует возможности сигнализации из другого MSC в пуле или, альтернативно, из любого другого сетевого объекта, способного служить в качестве ретранслятора для достижения (то есть поддержания связи с) подходящего ММЕ, где зарегистрировано UE. Выбор альтернативного MSC, который имеет интерфейс SGs или Sv в рабочем состоянии, может быть основан на информации О&М. В качестве альтернативы, в более продвинутых вариантах осуществления после того, как MSC обнаружит полный отказ тракта SGs/Sv или отказ тракта во всем интерфейсе SGs в отношении обслуживающего ММЕ, он отправляет широковещательное сообщение (новый тип сообщения, который предпочтительно называется "запросом на опрос SGs/запросом на опрос Sv") в отношении всех MSC, находящихся в пуле, чтобы произвести опрос относительно того, является ли другой MSC доступным для связи SGs или Sv. В ответ на получение ими сообщения с запросом на опрос SGs/Sv другие MSC в пуле передают отчет о своем статусе SGs в ответном сообщении. Эту информацию можно затем использовать в качестве основы для выбора.

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

Примеры, включающие использование другого ММЕ для ретрансляции сообщения SGs

В этом классе примеров будут рассмотрены два различных случая:

A) Прием пейджингового запроса "МТ Call" в другом ММЕ

B) Обработка сообщения "Combined Attach/TAU" в ММЕ без какого-либо I/F SGs Каждый из них описан подробно ниже. В каждом из случаев

- Ретрансляционный ММЕ может функционировать в соответствии с любой из следующих альтернативных процедур:

- Ретрансляционный ММЕ запускает процедуру обновления информации о местоположении в отношении MSC, и, в результате, принимая во внимание MSC, ретрансляционный ММЕ становится ММЕ, ассоциированным с SGs.

Или

- Ретрансляционный ММЕ действует исключительно как ретрансляционный узел, пересылающий только сообщения SGs между MSC и обслуживающим ММЕ. Этот альтернативный вариант требует внесения изменений (по состоянию на момент написания данного документа) в существующий протокол SGs. MSC должен обеспечить идентичность обслуживающего ММЕ при отправке сообщения SGs из MS С в ММЕ, быть информированным и допускать, что сообщение SGs будет ретранслироваться через другой ММЕ, отличный от обслуживающего ММЕ. ММЕ должен обеспечить идентичность обслуживающего MSC при отправке сообщения SGs из ММЕ в MSC и индикацию для того, чтобы указать, что сообщение SGs ретранслируется через другой ММЕ, отличный от обслуживающего ММЕ. Однако по сравнению с первым альтернативным вариантом запаздывание уменьшается (из-за меньшей сигнализации).

Случай А1: Прием пейджингового запроса "МТ Call" в другом ММЕ с помощью обслуживающего ММЕ, который продолжает работать с поддержкой ретрансляционной сигнализации.

Следует понимать, что обстоятельства, связанные с этим примером, не означают, что обслуживающий ММЕ полностью не способен использовать интерфейс SGs. Скорее всего, обслуживающий ММЕ может по-прежнему иметь ассоциацию SGs по отношению к одному или более другим MSC, в то время как для конкретного UE повреждается тракт сигнализации между зарегистрированным MSC и обслуживающим ММЕ, поэтому текущий обслуживающий MSC выбирает другой ММЕ для того, чтобы доставить пейджинговый запрос SGs (на основании существующего требования в 3GPP TS 23.007) или выбрать прокси MS С, который обеспечивает тракт сигнализации между этим прокси и обслуживающим ММЕ.

Сигнализация и обработка, которая к ней относится, связанные с этим примером, будут теперь описаны со ссылкой на диаграмму сигнализации, показанную на фиг. 3.

Этап 300-1: Ретрансляционный ММЕ принимает пейджинговый запрос "МТ Call" через I/F SGs из MSC, объединенного или необъединенного в пул, причем это происходит в ответ на обнаружение MSC отказа линии связи. Функциональные возможности, необходимые для того, чтобы MSC мог использовать другой ММЕ (ретрансляционный ММЕ) в ММЕ-пуле при "МТ Call", описаны в главе 5.1.2.2 TS 29.118 3GPP и в главе 26 TS 23.007 3GPP. Если MSC обслуживает UE, которое работает с другими ММЕ в ММЕ-пуле, то MSC принимает FQDN для каждого из других ММЕ. MSC может идентифицировать другие ММЕ в ММЕ-пуле, основываясь на том факте, что компонент ID группы ММЕ (ММЕ Group ID) FQDN является для всех элементов ММЕ-пула. Если MSC в текущий момент времени не обслуживает UE из каждого из других ММЕ в ММЕ-пуле, то MSC может использовать исторические данные (включая кэшированные FQDNS) из предыдущей связи с ММЕ из ММЕ-пула или может быть сконфигурирован в помощью информации относительно элементов ММЕ-пула. Такая конфигурация может быть либо локальной по отношению к узлу, либо внешней посредством, например, DNS.

Этап 300-2: MSC предоставляет имя FQDN обслуживающему ММЕ. Используя FQDN, ретрансляционный ММЕ отправляет запрос DNS, чтобы получить адрес обслуживающего ММЕ.

Этап 300-3: Ретрансляционный ММЕ ретранслирует пейджинговый запрос SGsAP по I/F S10 в обслуживающий ММЕ путем инкапсуляции "SGs-Paging-Request" в новое сообщение (предпочтительно называемое прямой передачей "SGs"). Альтернативно, ретрансляционный ММЕ ретранслирует пейджинговый запрос SGs АР между конечными точками (одноранговыми узлами сети) I/F S10, используя непосредственно стек протоколов, отличный от стека протоколов на основе GTP, обычно используемого в I/F S10.

Этап 300-4: Обслуживающий ММЕ принимает и выполняет пейджинговый запрос SGsAP и, в результате, отправляет пейджинговое сообщение S1AP с параметром Domain=CS.

Этап 300-5: UE, как описано в 3GPP TS 23.272, отвечает на запрос расширенного обслуживания.

Этап 300-6: Обслуживающий ММЕ информирует ретрансляционный ММЕ через прямую передачу SGs (прямая передача SGs представляет собой контейнер сообщения, который несет в себе сообщение SGs "SGsAP-ServiceRequest"), относительно того, что UE уже обнаружено и находится в режиме "подключено" через прямую передачу SGs. Например, этот обмен сообщениями может происходить в виде сообщения "SGsAP-Service Request". Основная идея заключается в том, что для процедуры поискового вызова выполняется обычная сигнализация. Однако эта технология отличается от традиционной технологии тем, что обычная процедура поискового вызова ММЕ разделяется на два узла, в которых 1) обслуживающий ММЕ выполняет сигнализацию обычной процедуры поискового вызова в интерфейсе S1-MME по отношению к eNB; и 2) ретрансляционный ММЕ выполняет сигнализацию обычной процедуры поискового вызова в интерфейсе SG. Для того чтобы обеспечить разбиение ММЕ, была введена новая сигнализация поверх существующего интерфейса S10. Эта сигнализация может характеризоваться как "туннелирование" сигнализации, которая относится к CSFB между двумя узлами ММЕ. Это "туннелирование" упоминается в данном документе как "прямая передача SGs". Подразумевая эти изменения, сигнализация, кратко изложенная с помощью описанных этапов, должна следовать стандартизированной сигнализации для CSFB, как определено 3GPP TS 23,272 и TS 23.007. В сообщении SGs (например, "SGs-Service-Request") обслуживающий ММЕ указывает MSC, что сообщение SGs ретранслируется через другой ММЕ, отличный от обслуживающего ММЕ.

Этап 300-7: В качестве альтернативы этапам 300-8 - 300-11, приведенным ниже (и, следовательно, показанным пунктирной линией), ретрансляционный ММЕ перенаправляет сообщение "SGsAP-Service Request" в MSC. Следовательно, обслуживающий ММЕ продолжает оставаться ММЕ, связанным с SGs, в виде MSC (то есть не нужна процедура обновления информации о местоположении), и процедура продолжается на этапе 300-12.

Этап 300-8: Ретрансляционный ММЕ запускает процедуру обновления информации о местоположении с учетом MSC, чтобы стать ММЕ, ассоциированным с SGs.

Этап 300-9: В результате приема обновления информации о местоположении MSC повторно передает пейджинговый запрос "МТ Call". Это описано в главе 2 TS 23.007 3GPP.

Этап 300-10: В результате приема повторно переданного пейджингового запроса "МТ Call", ретрансляционный ММЕ теперь непосредственно отвечает на запрос на обслуживание. Это выполняется в соответствии с процедурами, специфицированными в 3GPP TS 23.272.

Этап 300-11: Наконец, ретрансляционный ММЕ также перенаправляет сообщение, принятое на этапе 300-9 в обслуживающий ММЕ, тем самым запуская продолжение процедуры CSFB для обслуживающего ММЕ.

Этап 300-12: Например, процедура CSFB продолжается так, как специфицировано b TS 23.272 3GPP.

Случай А2: Прием пейджингового запроса "МТ Call" в другом ММЕ с помощью обслуживающего ММЕ использует только начальную ретрансляционную сигнализацию.

В вариантах осуществления, которые включают в себя MSC-пул и в которых обслуживающий ММЕ имеет по меньшей мере один рабочий I/F SGs, обслуживающий ММЕ может использовать другой MSC для повторной регистрации UE. Ретрансляционный ММЕ узнает о том, что он получает инструкции:

- через явное сообщение, отправленное из обслуживающего ММЕ в ретрансляционный ММЕ и показывающее, что обслуживающий ММЕ будет продолжать "МТ Call" путем выполнения регистрации CS по отношению к другому доступному MSC, или

- неявным образом, что означает, что ретрансляционный ММЕ не принимает какую-либо прямую передачу SGs из обслуживающего ММЕ.

В таком случае ретрансляционный ММЕ запрещает этапы 300-8 - 300-10, как описано выше.

Сигнализация и обработка, которая к ней относится, связанные с этим примером, будут теперь описаны со ссылкой на диаграмму сигнализации, показанную на фиг. 4.

Этап 400-1: Пейджинговый запрос "МТ Call" принимается через I/F SGs из объединенного в пул MSC, который выполняется в ответ на MSC, который обнаружил отказа линии связи. Функциональные возможности, необходимые для создания MSC, который использует другой ММЕ (ретрансляционный ММЕ) в ММЕ-пуле при "МТ Call", описаны, например, в главе 5.1.2.2 3GPP TS 29.118 и главе 26 3GPP TS 23.007. Если MSC обслуживает UE, управляемое другими ММЕ в ММЕ-пуле, то MS С принял FQDN для каждого из других ММЕ. MSC может идентифицировать другие ММЕ в ММЕ-пуле, основываясь на том факте, что компонент ID группы ММЕ FQDN равен для всех элементов ММЕ-пула. Если MSC в текущий момент времени не обслуживает UE из каждого из других ММЕ в ММЕ-пуле, то MSC может либо использовать исторические данные (включая кэшированные FQDN) из предыдущей связи с ММЕ из ММЕ-пула, либо его можно сконфигурировать с помощью информации относительно элементов ММЕ-пула. Такая конфигурация может быть либо локальной для узла, либо внешней посредством, например, DNS.

Этап 400-2: MSC предоставляет имя FQDN обслуживающего ММЕ. Используя FQDN, ретрансляционный ММЕ отправляет запрос DNS для того, чтобы получить адрес обслуживающего ММЕ.

Этап 400-3: ретрансляционный ММЕ ретранслирует пейджинговый запрос SGsAP через I/F S10 в обслуживающий ММЕ, используя вновь определенную "прямую передачу SGs".

Этап 400-4: Так как обслуживающий ММЕ имеет по меньшей мере один работающий I/F SGs по отношению к другому MSC в MSC-пуле, он использует команду IMSI Detach для разъединения UE для того, чтобы повторно зарегистрировать UE в другом MSC.

Этап 400-5: UE выдает комбинированный запрос TAU, как описано, например, в главе 5.5.2.3.2 3GPP TS 24.301.

Этап 400-6: обслуживающий ММЕ информирует ретрансляционный ММЕ о том, что UE будет обслуживаться обслуживающим ММЕ путем повторной регистрации, тем самым запрещая любые дальнейшие действия со стороны ретрансляционного ММЕ. Строго говоря, этот этап не является необходимым, так как ретрансляционный ММЕ не меняет своего состояния. Тем не менее, это может быть полезным для выполнения этого этапа, а также следующего этапа.

Этап 400-7: Ретрансляционный ММЕ в свою очередь информирует обслуживающий MSC о том, что UE будет зарегистрирован с помощью другого MSC. Эта информация позволяет обслуживающему MSC остановить в текущий момент времени выполнение повторных попыток поискового вызова, которые в противном случае он будет делать в случае отсутствия ответа.

Этап 400-8: Обслуживающий ММЕ запускает процедуру обновления информации о местоположении для повторной регистрации UE в резервном MSC.

Этап 400-9: В ответ на прием сообщения обновления информации о местоположении резервный MS С использует либо повторную попытку роуминга МТ, либо перенаправляет роуминг МТ для того, чтобы запустить передачу пейджингового запроса "МТ Call" из обслуживающего MSC в резервный MSC. Это действие описано в главе 26 3GPP TS 23.007 и 3GPP TS 23.018.

Этап 400-10: В результате пейджингового запроса "МТ Call", передаваемого из обслуживающего MSC в резервный MSC, пейджинговый запрос "МТ Call" повторно передается с помощью резервного MSC в направлении обслуживающего ММЕ. Такой характер поведения соответствует процедурам, указанным в главе 26 3GPP TS 23.007.

Этап 400-11: В ответ на прием пейджингового запроса "МТ Call", обслуживающий ММЕ отправляет запрос на обслуживание. Это соответствует процедурам, указанным в 3GPP TS 23.272.

Этап 400-12: Наконец, процедура CSFB продолжается в обычном порядке. Для получения более подробной информации смотри, например, 3GPP TS 23.272.

Случай В: Обработка запроса "Combined Attach/TAU" в ММЕ без какого-либо I/F SGs в обслуживающем ММЕ и в дальнейшем происходит вызов "МТ Call"

Сигнализация и обработка, которая к ней относится, связанные с этим примером, будут теперь описаны со ссылкой на диаграмму сигнализации, показанную на фиг. 5.

Этап 500-1: Запрос "Combined Attach/TAU" отправляется UE и принимается в обслуживающем ММЕ, который в этом примере является ММЕ с полным отказом I/F SGs. Этот процесс соответствует, например, 3GPP TS 23.272.

Этап 500-2: Обслуживающий ММЕ может получить информацию относительно статуса I/F SGs из всех других ММЕ в пуле и, основываясь на этой информации, выбирает ММЕ (ретрансляционный ММЕ), который имеет рабочий I/F SGs по отношению к ассоциированному MSC. Затем обслуживающий ММЕ отправляет запрос на обновление информации о местоположении SGsAP, выбранный ретрансляционным ММЕ путем инкапсуляции запроса на обновление информации о местоположения SGsAP в новое сообщение, которое предпочтительно называется "прямой передачей". В качестве альтернативы, запрос обновления информации о местоположении SGsAP отправляется между конечными точками (одноранговыми узлами сети) I/F S10 непосредственно с использованием стека протоколов, который отличается от стека протоколов на основе GTP, обычно используемого в I/F S10. Обслуживающий ММЕ включает в себя идентификатор MSC и индикатор MSC относительно того, что сообщение SGs ретранслируется через другой ММЕ, отличный от обслуживающего ММЕ.

В альтернативных вариантах осуществления обслуживающий ММЕ может получить информацию относительно статуса I/F SGs путем отправки широковещательного сообщения для опроса всех других ММЕ (предпочтительно параллельно) для того, чтобы найти подходящий ретрансляционный ММЕ.

Этап 500-3: ретрансляционный ММЕ выполняет процедуру обновления информации о местоположении для регистрации (или в некоторых случаях для повторной регистрации) UE в MSC, поэтому с точки зрения MSC ретрансляционный ММЕ становится обслуживающим ММЕ. Процедура обновления информации о местоположении может соответствовать, например, процедурам, описанным в 3GPP TS 23.272 и 29.118.

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

Этап 500-4: Ретрансляционный ММЕ отправляет сообщение Location Update Accept (Обновление местоположения выполнено) в обслуживающий ММЕ.

Этап 500-5: Обслуживающий ММЕ отправляет сообщение "Combined Attach/TAU accept" (Комбинированное подключение/TAU выполнено) в UE. Это выполняется в соответствии с процедурами, определенными в 3GPP TS 23.272.

В некоторый более поздний момент времени (смотри истекшее время 501) пейджинговый запрос "МТ Call" отправляется объединенным или необъединенным в пул MSC через I/F SGs в направлении ретрансляционного ММЕ, так как он является ассоциированным ММЕ, как это видно из MSC. Другими словами, ретрансляционный ММЕ представляет себя как обслуживающий ММЕ в обслуживающем MSC. Преимущество этого подхода состоит в том, что он обеспечивает механизм, посредством которого унаследованный MSC может взаимодействовать с ретрансляционным ММЕ.

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

Поэтому случай использования может быть предназначен для начальной процедуры комбинированного подключения или TAU, где обслуживающий ММЕ еще не установил ассоциацию SGs для данного UE, поэтому обслуживающий ММЕ может использовать ретрансляционный ММЕ для выполнения процедуры регистрации. Она будет аналогичной варианту использования вызова "МТ Call":

1) ретрансляционный ММЕ может вести себя как настоящий ретранслятор, просто пересылающий сообщения путем извлечения сообщения SGs, включенного в прямую передачу SGs и затем отправляющий извлеченное сообщение SGs в MSC, поэтому MSC будет знать о том, что UE находится под управлением обслуживающего ММЕ, а не ретрансляционного ММЕ; или

2) ретрансляционный ММЕ ведет себя как обслуживающий ММЕ, поэтому MSC считает, что UE находится под управлением ретрансляционного ММЕ, не зная о том, что ретрансляционным ММЕ является фактически ретрансляционным ММЕ. Следовательно, для последующего вызова "МТ Call", для случая 1, MSC может выбрать другой ММЕ в качестве ретрансляционного ММЕ; для случая 2, MSC будет непосредственно поддерживать связь с ретрансляционным ММЕ, так как он считает, что он является обслуживающим ММЕ для UE.

Этап 500-6: Ретрансляционный ММЕ принимает пейджинговый запрос "МТ Call" из объединенного или необъединенного в пул MSC. Это выполняется в соответствии с процедурами, описанными в 3GPP TS 23.272.

Альтернативно, MSC может использовать альтернативное сообщение и информацию, принятую на этапе 500-3 для ретрансляции пейджингового запроса "МТ Call" в обслуживающий ММЕ через ретрансляционный ММЕ (то есть, используя ретрансляционный ММЕ только в целях ретрансляции).

Этап 500-7: ретрансляционный ММЕ запоминает идентичность обслуживающего ММЕ, для которого он ранее транслировал сигнализацию обновления информации о местоположения SGsAP ("SGsAP Location Update") для IMSI, и выбирает тот же самый ММЕ.

Или в соответствии с другим альтернативным вариантом, MSC предоставляет имя FQDN через обслуживающий ММЕ. Через опрос DNS имя FQDN используется ретрансляционным ММЕ для того, чтобы получить адрес обслуживающего ММЕ.

Этап 500-8: Ретрансляционный ММЕ ретранслирует SGsAP Paging Request (Пейджинговый запрос SGsAP) через I/F S10 в обслуживающий ММЕ.

Этап 500-9: Обслуживающий ММЕ принимает и выполняет запрос "SGsAP Paging Request" (Пейджинговый запрос SGsAP) и, в результате, отправляет сообщение "S1AP Paging" (Поиск S1 АР) при Domain=CS.

Этап 500-10: UE отправляет ответ с сообщением "Extended Service Request" (Запрос расширенного обслуживания). Это выполняется в соответствии с 3GPP TS 23.272.

Этап 500-11: Обслуживающий ММЕ информирует ретрансляционный ММЕ о том, что UE теперь выполнил поисковый вызов и находится в режиме "подключено". Этот этап информирования может быть выполнен в виде сообщения "SGsAP-Service Request".

Этап 500-12: Ретрансляционный ММЕ отвечает MSC с помощью запроса на обслуживание SGsAP ("SGsAP Service Request"). Хотя запрос на обслуживание SGsAP известен сам по себе, его использование здесь отличается от традиционной технологии по меньшей мере тем, что он отправляется через ретрансляционный ММЕ, а не непосредственно из ММЕ, ассоциированного с SGs.

Этап 500-13: Наконец, ретрансляционный ММЕ поддерживает связь с обслуживающим ММЕ, чтобы заставить его продолжить выполнять процедуру CSFB.

Этап 500-14: Соответственно, обслуживающий ММЕ продолжает выполнять процедуру CSFB, как описано в 3GPP TS 23.272.

Пример, включающий в себя использование другого ММЕ для ретрансляции сообщений Sv в случае, когда отсутствует действующий I/F Sv в обслуживающем ММЕ.

Соответствующая сигнализация и обработка, которая к ней относится, связанные с этим примером, будут теперь описаны со ссылкой на диаграмму сигнализации, показанную на фиг. 6. Следует отметить, что ради ясности были опущены аспекты, не относящиеся к делу, например, взаимодействие с SGSN.

Этап 600-1: В некоторый момент времени при обслуживании UE eNB отправляет сообщение "Handover Required" (Требуется хэндовер) в обслуживающий ММЕ. Это сообщение включает в себя индикацию НО SRVCC. Эта сигнализация выполняется в соответствии с процессами, определенными в 3GPP TS 23.216.

Этап 600-2: В некоторых вариантах осуществления обслуживающий ММЕ получает информацию относительно статуса I/F Sv из всех других ММЕ в пуле и, основываясь на этой информации, выбирает ММЕ (ретрансляционный ММЕ), который имеет рабочий I/f Sv по отношению к выбранному MSC. Сообщение "SRVCC PS to CS Request", включающее в себя идентичность выбранного MSC, отправляется затем в ретрансляционный ММЕ.

Обслуживающий ММЕ может получать информацию относительно статуса I/F Sv с помощью другого средства или с помощью проверки (предпочтительно параллельной) всех других ММЕ (например, путем отправки широковещательного сообщения для опроса всех других ММЕ) для того, чтобы найти подходящий ретрансляционный ММЕ.

Этап 600-3: Ретрансляционный ММЕ ретранслирует сообщение "SRVCC PS to CS Request" в MSC. Этапы для выполнения процедуры "SRVCC PS to CS Request" описаны в 3GPP TS 23.216. Однако традиционная технология не учитывает использование другого (ретрансляционного) ММЕ, действующего от имени обслуживающего ММЕ в качестве составной части процесса. В качестве части компенсации этого различия, ретрансляционный ММЕ информирует MSC о том, что он (то есть ретрансляционный ММЕ) действует как ретранслятор сообщений Sv и информирует MS С об идентичности обслуживающего ММЕ. Следует отметить, что исполняя роль только как ретранслятор информации, ретрансляционный ММЕ не сохраняет данные о поступающих запросах.

Этап 600-4: MSC отправляет сообщение "SRVCC PS to CS Response" в ретрансляционный ММЕ.

Этап 600-5: Ретрансляционный ММЕ ретранслирует сообщение "SRVCC PS to CS Response" в обслуживающий ММЕ.

Этап 600-6: Обслуживающий ММЕ отправляет сообщение "Handover Command" (Команда хэндовера) в eNB. Этот аспект выполнен в соответствии с процедурами, описанными в 3GPP TS 23.216.

Этап 600-7: После того как UE, в качестве части выполнения хэндовера из EUTRAN, настроит услуги радиосвязи на 2G или 3G в домене CS (смотри этап 601), MSC отправляет сообщение "SRVCC PS to CS Complete Notification" (Уведомление о выполнении SRVCC при переходе от сети с коммутацией пакетов к сети с коммутацией каналов) в ретрансляционный ММЕ. Это сообщение включает в себя идентичность обслуживающего ММЕ.

Этап 600-8: Ретрансляционный ММЕ ретранслирует сообщение "SRVCC PS to CS Complete Notification" в обслуживающий ММЕ.

Этап 600-9: Обслуживающий ММЕ отправляет ответ с сообщением "SRVCC PS to CS Complete Acknowledge" (Подтверждение о выполнении SRVCC при переходе от сети с коммутацией пакетов к сети с коммутацией каналов) в ретрансляционный ММЕ.

Этап 600-10: Ретрансляционный ММЕ ретранслирует сообщение "SRVCC PS to CS Complete Acknowledge" в MSC.

Различные варианты осуществления, которые соответствуют настоящему изобретению, обеспечивают ряд преимуществ по сравнению с традиционной технологией устранения ошибок. Преимущества, которые присутствуют в некоторых вариантах осуществления, включают в себя, при потере ММЕ связности 1/F SGs, возможность поддерживать зарегистрированное UE. В случаях, когда ММЕ потерял свою связность I/F Sv, некоторые варианты осуществления позволяют выполнить SRVCC.

Аспекты, которые относятся к этим преимуществам, представляют собой меры предосторожности, которые позволяют ММЕ обслуживать UE через другой ММЕ в ММЕ-пуле.

Полученный в результате эффект от изменения режима работы (по сравнению с традиционной технологией) представляет собой:

- Отсутствие резкого скачка в сигнализации NAS: так как UE остается зарегистрированным одним и тем же ММЕ, отсутствует резкий скачок в сигнализации UE для UE, зарегистрированных ММЕ.

- Можно изолировать для того, чтобы воздействовать только на ММЕ-пул: различные аспекты полностью содержатся в пределах ММЕ-пула. Можно использовать для расширения и усиления концепции ММЕ-пула.

- Можно использовать для предоставления MSC-пула возможностей ретрансляции: это позволяет MSC MSC-пула использовать альтернативные маршруты для успешного выполнения сигнализации для услуг МТ.

- Отсутствие резкого скачка в нагрузке сигнализации в HSS: так как UE остается зарегистрированным тем же самым ММЕ, отсутствует всплеск перемещения UE из перегруженного ММЕ в другие ММЕ, и, следовательно, отсутствует всплеск сигнализации регистрации UE в каждом HSS.

- Предотвращение поиска на основе IMSI с доменом Core Network (Базовая сеть), установленным на PS: Это позволяет избежать серьезного воздействия на существующую услугу PS.

- Когда ретрансляционный ММЕ функционирует как истинный ретранслятор, предотвращается сигнализация для повторной регистрации CS.

В каждом варианте осуществления различные аспекты можно выполнить с помощью узлов, соединенных между собой (например, eNBS, ММЕ, MSC), таких как универсальный узел 701, изображенный на фиг. 7. Каждый узел включает в себя один или более процессоров 703, и способ можно выполнить на основании компьютерной программы, содержащей инструкции 705, которые, при их исполнении одним или более процессорами 703, выполняют способ в соответствии со значением узла, как описано выше, по отношению к любому одному или комбинации вариантов осуществления (например, когда узел является обслуживающим ММЕ, он выполняет этапы в соответствии с работой обслуживающего ММЕ, как описано выше; когда узел является ретрансляционным ММЕ, он выполняет этапы в соответствии с работой ретрансляционного ММЕ, как описано выше; когда узел является MSC, он выполняет этапы в соответствии с этапами MSC, как описано выше, и т.д.). Программа 705 является исполняемой на одном или более программируемых процессорах 703. Прикладная программа может быть реализована на процедурном или объектно-ориентированном языке программирования, или, при необходимости, на ассемблере, или машинном языке. В любом случае язык может быть компилируемым или интерпретируемым языком. Программа может быть программой для полной установки или программой для обновления. В последнем случае программа представляет собой программу для обновления, которая обновляет программируемое устройство, ранее запрограммированные части выполнения способа до состояния, в котором устройство подходит для выполнения всего способа.

Программа 705 может быть записана на считываемом процессором носителе 707 информации. Носитель 707 информации может представлять собой любую память, адаптированную к записи компьютерных инструкций. Таким образом, носитель для хранения данных может иметь любую форму энергонезависимой памяти, включающей в себя посредством примера, а не ограничения, устройства полупроводниковой памяти, такие как EPROM, EEPROM и устройства флэш-памяти; магнитные диски, такие как внутренние жесткие диски и съемные диски; магнитооптические диски; и диски CDROM. Носитель 707 информации соединен в рабочем состоянии с одним или более процессорами 703 для того, чтобы процессор(ы) 703 имели возможность считывать и в некоторых случаях записывать данные и инструкции на носитель 707 информации.

Узел 701 дополнительно включает в себя интерфейс 709, подсоединенный в рабочем состоянии к одному или более процессорам 703 для того, чтобы обеспечить связь между узлом 701 и другими узлами или сетевыми элементами (не показаны). Интерфейс 709 может, например, и без ограничения, действовать как любой один или более из следующих интерфейсов: S1-MME; S3; S4, S6a; S10; S11; SG; Sv.

В зависимости от типа рассматриваемого узла, узел 701 может включать в себя другую схему и/или элементы 711 программы, которые могут быть также подсоединены в рабочем состоянии к одному или более процессорам 703. Описание любых других таких схем и/или элементов 711 программы известно специалистам в данной области техники, а также за пределами объема вариантов осуществления заявителя, и поэтому их описание здесь не требуется.

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

В некоторых, но не обязательно во всех вариантах осуществления, услуга связи предоставляется UE обслуживающим ММЕ и обслуживающим MSC в системе связи (этап 801). В некоторый момент времени обнаруживается, что одна или более линий связи, которые обеспечивают связь между обслуживающим ММЕ и обслуживающим MSC, вышли из строя (этап 803). В пределах сети идентифицируются/идентифицируется другие/другой ММЕ и/или MSC, которые имеют/который имеет полностью функционирующие линии связи с обслуживающим MSC и/или обслуживающим ММЕ (этап 805). Сигнализация выполняется для того, чтобы установить идентифицированный ММЕ и/или MSC в качестве ретрансляционного ММЕ и/или ретрансляционного MSC (этап 807). Управление UE продолжается с помощью ретрансляционного ММЕ, осуществляющего обмен сообщениями с обслуживающим MSC, или ретрансляционным MSC, и/или с помощью ретрансляционного MSC, осуществляющего обмен сообщениями с обслуживающим ММЕ или ретрансляционным ММЕ, и, кроме того, с помощью ретрансляционного ММЕ, ретранслирующего сообщения в обслуживающий ММЕ, и/или с помощью ретрансляционного MSC, ретранслирующего сообщения в обслуживающий MSC (этап 809).

Следует понимать, что конкретная сигнализация, определенная этапом 807, и функциональные возможности управления UE на этапе 809 могут находиться, например, в соответствии с любым из вариантов осуществления, описанных выше со ссылкой на фиг. 3, 4, 5 и/или 6.

Различные аспекты вариантов осуществления были описаны в соответствии с изобретением по отношению к ММЕ, SGSN и MSC. Однако использование этих примеров не предназначено для ограничения объема различных аспектов изобретения. Например, одни и те же принципы могут быть применены к интерфейсу S11, который находится между ММЕ и обслуживающим шлюзом (S-GW), а также к интерфейсу S4, который находится между SGSN и S-GW. В частности, когда S-GW обнаруживает, что ММЕ или SGSN являются недоступными, инициируется сообщение уведомления о данных нисходящей линии связи из-за приема данных нисходящей линии связи в плоскости пользователя или из-за приема сигнальных сообщений в плоскости управления (например, создать/обновить/удалить сообщение запроса носителя), оно должно включать в себя FQDN обслуживающего ММЕ (то есть идентификатор ММЕ), или FQDN обслуживающего SGSN (то есть идентификатор SGSN) в сообщении уведомления о данных нисходящей линии связи, и отправить его в другой альтернативный ММЕ или SGSN, чтобы позволить такому прокси ММЕ или SGSN передать эти сообщения в правильные ММЕ или SGSN.

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

ММЕ

MSC

SGSN

S-GWS

eNBS

Для иллюстрации таких вариантов осуществления на фиг. 9 показана, с одной стороны, блок-схема последовательности этапов/процессов, выполняемых схемой в соответствии с некоторыми, но не обязательно со всеми примерными вариантами осуществления изобретения с целью восстановления возможности управления UE сети. С другой стороны, фиг. 9 можно рассматривать для изображения средства 900 для восстановления возможности управления UE сети, где изображенные прямоугольники представляют собой схему, сконфигурированную для выполнения описанных функций.

В некоторых, но не обязательно во всех вариантах осуществления, услуга связи предоставляется UE обслуживающим узлом первого типа и обслуживающим узлом второго типа в системе связи (этап 901). В некоторый момент времени обнаруживается, что одна или более линий связи, которые обеспечивают связь между обслуживающим узлом первого типа и обслуживающим узлом второго типа, вышли из строя (этап 903). Другой узел первого типа и/или узел второго типа идентифицируются/идентифицируется в пределах сети, которые имеют/который имеет полностью функционирующие линии связи с обслуживающим узлом второго типа и/или обслуживающим узлом первого типа (этап 905). Сигнализация выполняется для того, чтобы установить идентифицированный узел первого типа и/или узел второго типа в качестве ретрансляционного узла первого типа и/или ретрансляционного узла второго типа (этап 907). Управление UE продолжается с помощью ретрансляционного узла первого типа, осуществляющего обмен сообщениями с обслуживающим узлом второго типа или ретрансляционным узлом второго типа, и/или с помощью ретрансляционного узла второго типа, осуществляющего обмен сообщениями ретрансляционным узлом второго типа с обслуживающим узлом первого типа или ретрансляционным узлом первого типа, и, кроме того, с помощью ретрансляционного узла первого типа, ретранслирующего сообщения в обслуживающий узел первого типа, и/или с помощью ретрансляционного узла второго типа, ретранслирующего сообщения в обслуживающий узел второго типа (этап 909).

Следует понимать, что конкретная сигнализация, определенная на этапе 907, и функциональные возможности управления UE на этапе 909 могут находиться, например, в соответствии с любым из вариантов осуществления, описанных выше со ссылкой на фиг. 3, 4, 5 и/или 6.

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

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

3GPP TS 23.401 версии 12.2.0 2013-09

3GPP TS 23.272 версии 12.0.0 2013-09

3GPP TS 23.216 версии 12.0.0 2013-09

3GPP TS 29.274 версии 12.2.0 2013-09

3GPPTS 29.118 версии 12.2.0 2013-09

3GPP TS 23.007 версии 12.1.0 2013-09

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