Обработка сбоев в линии радиосвязи и при передаче обслуживания

Обработка сбоев в линии радиосвязи и при передаче обслуживания

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Настоящее изобретение относится к системам беспроводной связи.

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

В сети усовершенствованного универсального наземного радиодоступа (E-UTRAN) стадии 2, случаи, когда беспроводной модуль приема/передачи (WTRU) выбирает соту, которая принадлежит этому же eNodeB, после сбоя в линии радиосвязи (RL), приводятся как случаи для дополнительного изучения (FFS). Было предложено, чтобы в том случае, если WTRU выбрал другую соту из одного и того же eNodeB, активность не могла возобновляться без взаимодействия между WTRU и eNodeB. В настоящее время, сеть радиодоступа 2 (RAN2) определяет, что если WTRU выбирает соту из другого eNodeB, он должен проходить через режим бездействия на уровне управления радиоресурсами (RRC).

В настоящее время, решения RAN2 относительно сбоя в RL определяются на основе двух фаз. Эти две фазы управляют режимом, связанным со сбоем в RL, и показаны на Фиг.1.

Первая фаза начинается, когда обнаружена проблема радиосвязи, которая приводит к обнаружению сбоя в RL. В результате нет основанной на WTRU мобильности на основе таймера или другого (к примеру, подсчета) критерия (T₁).

Вторая фаза начинается, когда обнаружен сбой в линии радиосвязи, который приводит к режиму бездействия RRC. По-прежнему доступна основанная на WTRU мобильность, которая основана на таймере (T₂).

Таблица 1 ниже описывает, как мобильность в настоящий момент обрабатывается относительно сбоя в RL.

Таблица 1 Мобильность и сбой в линии радиосвязи
Случаи	Первая фаза	Вторая фаза	T 2 истек
UE возвращается в ту же соту	Продолжать, как если бы проблемы радиосвязи не возникли	Активность не может быть возобновлена без взаимодействия между UE и eNodeB, Процедурой, которая должна использоваться, является FFS,Обычно не через RRC_IDLE	Прохождение через RRC_IDLE
UE выбирает другую соту из этого же eNodeB	Нет данных	FFS	Прохождение через RRC_IDLE
UE выбирает соту другого eNodeB	Нет данных	Прохождение через RRC_IDLE	Прохождение через RRC_IDLE

Недавний предложенный проект делит передачу обслуживания на две (2) фазы, аналогичные сбою в RL, и предлагает аналогичную процедуру обработки сбоев при передаче обслуживания.

В первой фазе WTRU пытается синхронизироваться и осуществлять доступ к целевой соте, к примеру, в течение таймера T1. Во второй фазе WTRU прервал передачу обслуживания, поскольку в ее ходе произошел сбой, и пытается повторно устанавливать потерянное соединение с сетью, к примеру, в течение таймера T2. После второй фазы UE переходит к RRC_IDLE.

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

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

Вторая фаза начинается при обнаружении сбоя при передаче обслуживания, который приводит к RRC_IDLE. Основанная на WTRU мобильность по-прежнему доступна на основе таймера (Ta).

Таблица 2 описывает, как обрабатывается мобильность относительно сбоя при передаче обслуживания.

Таблица 2 Мобильность и сбой при передаче обслуживания
Случаи	Первая фаза	Вторая фаза	T 2 истек
UE входит в целевую соту	Продолжать, как если бы проблемы радиосвязи не возникли	Активность не может быть возобновлена без взаимодействия между UE и eNodeB, UE выполняет процедуру произвольного доступа согласно 10.1.5	Прохождение через RRC_IDLE
UE возвращается в исходную соту	Нет данных	Активность не может быть возобновлена без взаимодействия между UE и eNodeB, UE выполняет процедуру произвольного доступа согласно 10.1.5	Прохождение через RRC_IDLE
UE выбирает соту, отличную от целевой или исходной соты	Нет данных	Прохождение через RRC_IDLE	Прохождение через RRC_IDLE

Кроме того, в настоящий момент разрешено использовать не основанный на конкуренции произвольный доступ в ходе передачи обслуживания. По сути, текущая процедура не основанного на конкуренции произвольного доступа, показанная на Фиг.3, включает в себя назначение преамбулы произвольного доступа через выделенную передачу служебных сигналов в нисходящей линии связи (DL), при этом eNodeB назначает для WTRU шести (6)-битовую преамбулу неконкурентного произвольного доступа (т.е. преамбулу произвольного доступа, которая не находится в пределах набора, передаваемого в широковещательном режиме по BCH). Преамбула передается в служебных сигналах через команду передачи обслуживания (HO), формируемую посредством целевого eNodeB, и отправляется из исходного eNodeB для передачи обслуживания с помощью передачи служебных сигналов на уровне управления доступом к среде (MAC) (к примеру, по каналу управления уровня 1 (L1)/уровня 2 управления (L2) или по пакетному модулю данных (PDU) уровня управления MAC) в случае поступления данных DL.

WTRU затем передает назначенную преамбулу неконкурентного произвольного доступа по RACH в восходящей линии связи. Ответ произвольного доступа от eNB отправляется по DL-SCH. Ответ является полусинхронным (в рамках гибкого окна, размер которого составляет один или более интервалов времени передачи (TTI)) с сообщением 1 и адресуется либо в C-RNTI, либо в RA-RNTI (FFS) по каналу управления L1/L2.

Ответ произвольного доступа включает в себя, по меньшей мере, информацию о временном совмещении и начальное разрешение на передачу по UL для передачи обслуживания и информацию о временном совмещении для поступления данных DL. Дополнительно, идентификатор RA-преамбулы адресуется во временной идентификатор радиосети в области маршрутизации (RA-RNTI) по каналу управления L1/L2.

Ответ предназначен только для одного WTRU в одном сообщении по совместно используемому каналу нисходящей линии связи (DL-SCH), если он адресуется в RNTI соты (C-RNTI) по каналу управления L1/L2, или для одного или нескольких WTRU в одном сообщении DL-SCH, если он адресуется в RA-RNTI по каналу управления L1/L2.

Существует потребность в усовершенствованном способе и устройстве для обработки сбоев в линии радиосвязи и при передаче обслуживания.

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

Раскрытые способ и устройство используются для обработки сбоев в RL и при передаче обслуживания на основе контекстных сведений передачи и процедур RACH, которые совершенствуют процедуры обработки сбоев. После сбоя в RL, беспроводной модуль приема/передачи (WTRU) включает идентификацию усовершенствованного узла B (eNB) и/или соты в качестве информационного элемента (IE) в запрос на установление RRC-соединения и/или в сообщение обновления соты или любое другое RRC-сообщение наряду с идентификацией WTRU.

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

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

Фиг.1 иллюстрирует традиционный сбой в линии радиосвязи;

Фиг.2 иллюстрирует традиционный сбой при передаче обслуживания;

Фиг.3 иллюстрирует традиционную процедуру не основанного на конкуренции произвольного доступа;

Фиг.4 иллюстрирует схему системы беспроводной связи; и

Фиг.5 иллюстрирует блок-схему последовательности операций раскрытого способа обработки сбоя в линии радиосвязи.

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

При дальнейшем упоминании термин "беспроводной модуль приема/передачи (WTRU)" включает в себя, но не только, пользовательское оборудование (UE), мобильную станцию, стационарный или мобильный абонентский модуль, пейджер, сотовый телефон, персональное цифровое устройство (PDA), компьютер или любой другой тип пользовательского устройства, допускающего работу в беспроводном окружении. Когда упоминается далее, термин "базовая станция" включает в себя, но не только, узел B, контроллер узла, точку доступа (AP) или любой другой тип интерфейсного устройства, выполненного с возможностью работы в беспроводном окружении.

На Фиг.4 сеть (NW) 10 беспроводной связи LTE, например, содержит один или более WTRU 20, каждый из которых включает в себя процессор 21, один или более узлов B 30, каждый из которых включает в себя процессор 31, и одну или более сот 40. Каждая сота 40 содержит один или более узлов B (NB или eNB) 30. Процессоры 21 и 31 выполнены с возможностью реализовывать раскрытый способ обработки сбоя в линии радиосвязи (RL) и при передаче обслуживания.

В раскрытом способе контекстная информация относится к любому из контекста управления радиоресурсами (RRC), контекста безопасности, контекста протокола конвергенции пакетных данных (PDCP) или контекста любого уровня, который может продолжаться во время мобильности. Для краткости, тем не менее, термин "контекст" или "RRC-контекст" могут использоваться для каждого из типов контекста, раскрытых выше.

Когда сбой в RL обнаружен посредством WTRU 20, WTRU 20 начинает процедуры мобильности (т.е. осуществляет повторный выбор сот). В обычной процедуре повторного выбора сот, WTRU 20 повторно выбирает любую доступную соту после сбоя в RL и через обновление соты или запрос на установление соединения согласно управлению радиоресурсами (RRC) WTRU 20 отправляет свои идентификация WTRU eNodeB в (eNB) 30. ENB 30 с использованием принимаемых идентификации WTRU обнаруживает, находилось ли WTRU 20 под управлением этого eNB 30 до того, как возник сбой в линии радиосвязи.

Раскрыты способ и устройство, в которых после сбоя в линии радиосвязи (RL) или при передаче обслуживания (HO), WTRU 20 включает свои идентификации WTRU (к примеру, TMSI/IMSI/IMEI или любые другие идентификации UE) и идентификация eNB и/или идентификация соты в качестве информационного элемента (IE) в запрос на установление RRC-соединения, сообщение обновления соты или любом другое RRC-сообщение.

Как только WTRU 20 ожидает вызова в eNB (т.е. целевом eNB) после повторного выбора сот, информация, включенная в IE, передается в целевой eNB. Если целевой eNB, в котором ожидает вызова WTRU 20, отличается от eNB, для которого WTRU 20 ожидал вызова до сбоя в RL (т.е. исходного eNB), то целевой eNB контактирует с исходным eNB с использованием идентификации eNB и/или идентификатора соты, включенного в IE, чтобы информировать исходный eNB 20 об идентификации WTRU. Целевой eNB затем запрашивает исходный eNB, чтобы передавать контекстные параметры WTRU 20. Альтернативно, целевой eNB также может информировать исходный eNB об идентификации соты.

Если исходный eNB находит контекстную информацию, которая совпадает с идентификацией WTRU 20, исходный eNB передает контекстную информацию в целевой eNB. Целевой eNB затем может отправлять ответ на обновление соты WTRU 20, запрос на установление RRC-соединения или любую другую, инициированную посредством WTRU процедуру RRC, указывающую то, что WTRU 20 может повторно использовать предыдущий контекст.

Если контекст не найден посредством исходного eNB, целевой eNB выполняет процедуры обновления соты/установления RRC-соединения или любую другую процедуру RRC. В этом случае, когда целевой eNB принимает запрос на повторное установление RRC-соединения от WTRU 20, он передает в служебных сигналах все параметры уровня 1 и уровня 2/3, которые он должен передавать в служебных сигналах для нового RRC-соединения. WTRU 20 затем может удалять всю сохраненную контекстную информацию, которая применима к старой соте. Альтернативно, если контекст не найден, WTRU 20 может переходить в режим бездействия RRC, не дожидаясь истечения таймера T2, и возобновлять процедуры или ожидать истечения таймера T2 для того, чтобы переходить в режим бездействия RRC.

Раскрытый IE, содержащий информацию о eNB, в котором WTRU 20 последний раз ожидал вызова, может быть включен посредством WTRU 20. В соответствии с этой альтернативой, процессор 21 включает идентификацию eNB и/или идентификацию соты в IE только после обнаружения сбоя при передаче обслуживания.

Если целевой eNB, в котором ожидает вызова WTRU 20, является идентичным исходному eNB до сбоя и если eNB находит контекст для WTRU 20 (eNB находит его посредством проверки того, имеет ли он контекст, который совпадает с идентификацией WTRU 20), то eNB при приеме RRC CONNECTION REQUEST (запрос на установление RRC-соединения) от WTRU 20 (или при приеме любой другой инициированной посредством WTRU процедуры RRC) может указывать WTRU 20 использовать ту же контекстную информацию, которую он имел до того, как возник сбой. В противном случае, eNB может передавать в служебных сигналах все параметры уровня 1 и уровня 2/3 для WTRU 20, которые eNB должен передавать в служебных сигналах для нового RRC-соединения. WTRU 20 затем может удалять всю сохраненную контекстную информацию.

Блок-схема последовательности операций раскрытого способа, используемого посредством процессора 21 WTRU 20 для того, чтобы обрабатывать сбой в RL, описана ниже. После обнаружения сбоя в RL (этап 500) WTRU 20 проводит процедуру начального доступа для получения доступа к выбранному целевому eNB (этап 501). WTRU 20 затем передает IE в целевой eNB, включающий в себя, по меньшей мере, идентификатор eNB для исходного eNB, в котором WTRU 20 ранее ожидал вызова (этап 502). WTRU 20 затем принимает RRC-контекст от целевого eNB (этап 503) после того, как контекст получен посредством целевого eNB, например, от исходного eNB.

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

Если целевой eNB, в котором ожидает вызова WTRU 20, является идентичным исходному eNB, в котором WTRU 20 ожидал вызова перед передачей обслуживания, то после приема RRC CONNECTION REQUEST от WTRU 20 или после приема любых других инициированных посредством WTRU процедур RRC может указывать WTRU 20 использовать ту же контекстную информацию, которую он имел до того, как возник сбой.

Специалисты в данной области техники должны признавать, что ожидание вызова посредством WTRU 20 в той же соте или в том же eNB, в котором он ожидал вызова до сбоя в RL, помогает в сохранении сетевых ресурсов. По сути, раскрытый способ альтернативно может включать в себя, что WTRU 20 в ходе процедуры выбора соты после сбоя в RL учитывает идентификация исходного eNB, тем самым предпочитая соты из исходного eNB сотам из другого eNB. В соответствии с этой альтернативой, может быть предпочтительным, чтобы WTRU 20 расставлял приоритет в обнаруженном eNB в следующем порядке: последняя сота, в которой он ранее ожидал вызова; сота из того же eNodeB, в котором он ранее ожидал вызова; и сота из любого другого eNodeB.

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

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

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

Важный аспект возможности извлекать контекст состоит в том, чтобы WTRU ожидал вызова в соте и отправлял сообщение 1 (т.е. преамбулу произвольного доступа) в процедуре RACH как можно быстрее. Если есть задержка в этом процессе, eNB может удалять контекст, что делает процедуру извлечения контекста бесполезной. Соответственно, способ для совершенствования процедуры канала с произвольным доступом (RACH) раскрывается для сбоев в RL и при передаче обслуживания. В соответствии с этим способом, специально предназначенная подпись выделяется для WTRU 20 в ходе процедуры передачи обслуживания. Выделенная специально предназначенная подпись затем используется для осуществления доступа к исходной соте после сбоя в RL или при передаче обслуживания. Например, команда HO (или любое служебное сообщение) назначает для WTRU 20 две специально предназначенные подписи, одна из которых должна использоваться посредством WTRU 20 для того, чтобы осуществлять доступ к целевой соте, а другая должна использоваться посредством WTRU 20 для того, чтобы осуществлять доступ к исходной соте (или любой другой соте) в случае, если возникает сбой (к примеру, если WTRU 20 не управлял тем, чтобы осуществлять доступ к целевой соте).

Если передача обслуживания завершена успешно, WTRU 20 может (неявно или явно) выдавать подпись обратно в сеть в сообщении подтверждения передачи обслуживания. В случае сбоя в ходе процедуры передачи обслуживания, WTRU 20 может использовать эту вторую специально предназначенную подпись и пытаться осуществлять доступ к сети как можно быстрее. Поскольку WTRU 20 использует специально предназначенную подпись, он может быстрее восстанавливаться после сбоя.

Альтернативно, набор специально предназначенных подписей передается в широковещательном режиме в наборе широковещательного канала (BCH) исключительно для сбоя в RL, который используется посредством WTRU 20 в случае сбоя в RL или при передаче обслуживания. В другой альтернативе, набор универсальных специально предназначенных подписей, допустимых во всех сотах, может использоваться для сбоев в RL. Этот набор универсальных специально предназначенных подписей может отправляться в сообщении передачи обслуживания или передаваться в широковещательном режиме в сообщениях системной информации. WTRU затем может использовать эту универсальную, специально предназначенную подпись после сбоя для осуществления доступа к любой соте.

Раскрывается альтернативная процедура RACH, в которой вместо выделения специально предназначенной подписи для WTRU 20, которая используется в случае сбоя, по меньшей мере, одна из подписей (к примеру, преамбула произвольного доступа) в текущем наборе, передаваемых в широковещательном режиме по BCH, может быть идентифицирована/резервирована для осуществления доступа к соте после сбоя. В соответствии с этой альтернативой, WTRU 20 получает зарезервированные подписи из BCH (или команда передачи обслуживания (HO) может сообщать для WTRU 20 зарезервированные подписи, которые должны использоваться в случае сбоя). После того как WTRU 20 распознает зарезервированные подписи, WTRU 20 использует эти зарезервированные подписи в случае, если он подвергается сбою в RL или при передаче обслуживания.

Раскрывается другая альтернатива, в которой используются более высокие классы доступа для обработки сбоев в RL. В соответствии с этой альтернативой, WTRU 20 ассоциирует обработку сбоев в RL с услугой с более высоким классом доступа и, следовательно, он должен завершать повторный выбор для сети с меньшей потерей мощности и с более высоким приоритетом. В этом сценарии, когда WTRU 20 пытается осуществлять доступ к соте после сбоя в RL, поскольку WTRU 20 должен иметь услугу с более высоким классом доступа и, следовательно, он должен пытаться осуществлять доступ к сети 10 с меньшим или без интервала потери мощности между своими различными попытками RACH. По сути, WTRU 20 после сбоя в RL может иметь более высокую вероятность осуществления доступа к сети по сравнению с другими WTRU с услугой с более низким классом доступа, которые имеют большие интервалы потери мощности.

В другом альтернативном способе доступа RACH, WTRU 20 повышает свою мощность быстрее, так что сеть имеет большую вероятность его обнаружения и тем самым отдает приоритет данному WTRU 20. Таблица 3 описывает мобильность WTRU 20 во время сбоя в RL в соответствии с этим раскрытым способом.

Таблица 3 Мобильность и сбой в линии радиосвязи
Случаи	Первая фаза	Вторая фаза	T 2 истек	Приоритет выбора соты
UE возвращается в ту же соту	Продолжать, как если бы проблемы радиосвязи не возникли	Активность не может быть возобновлена без взаимодействия между UE и eNodeB. Процедурой, которая должна использоваться, является FFS. Обычно не через RRC_IDLE	Прохождение через RRC_IDLE	1
UE выбирает другую соту из этого же eNodeB	Нет данных	Активность не может быть возобновлена без взаимодействия между WTRU и eNodeB	Прохождение через RRC_IDLE	2
UE выбирает соту другого eNodeB	Нет данных	Активность не может быть возобновлена без взаимодействия между UE и eNodeB. Процедурой, которая должна использоваться, является FFS. Обычно не через RRC_IDLE	Прохождение через RRC_IDLE	3

Для второй фазы, чтобы возобновлять активность, когда WTRU 20 возвращается в ту же соту или когда WTRU 20 выбирает другую соту из этого же eNodeB или другого eNB, раскрывается способ, при котором WTRU 20 осуществляет доступ к соте через процедуру произвольного доступа. Идентификации не связанного с предоставлением доступа уровня (NAS), используемые в процедуре произвольного доступа, также используются посредством eNB для того, чтобы определять, имеет ли eNB сохраненный RRC-контекст для этого WTRU 20. Если eNB находит RRC-контекст, который совпадает с идентификацией WTRU 20, eNB отправляет в ответ на RRC CONNECTION REQUEST сообщение (к примеру, RRC CONNECTION RESPONSE) или любые другие инициированные посредством WTRU процедуры RRC, указывающие WTRU 20 повторно использовать RRC-контекст, который он хранит.

Если eNB не находит RRC-контекст, который совпадает с идентификацией WTRU 20, новый eNB контактирует непосредственно с предыдущим eNB, где ожидался вызов, с использованием идентификации eNB, передаваемых посредством WTRU 20. Как раскрыто выше, альтернативно, eNB может извлекать идентификация WTRU или контекст WTRU из объекта управления мобильностью (MME).

Если контекст обнаруживается в старом eNB и передается, он отправляет в ответ на RRC CONNECTION REQUEST сообщение (к примеру, RRC CONNECTION RESPONSE) или любые другие, инициированные посредством WTRU процедуры RRC, указывающие WTRU 20 повторно использовать RRC-контекст, который он хранит. Если контекст не находится в новом или в старом eNB, осуществляется процедура установления RRC-соединения, и WTRU 20 отбрасывает RRC-контексты, которые он хранит. В этом случае, когда сеть отправляет ответ в инициированную посредством WTRU 20 процедуру RRC, сеть 10 указывает, может ли WTRU 20 устанавливать стек с использованием старой контекстной информации, которую он имел перед сбоем, или сеть 10 передает новые параметры в ответном сообщении для WTRU 20, чтобы устанавливать его стек. Как только WTRU 20 принимает ответное сообщение из сети 10 и обрабатывает его, WTRU 20 передает сообщение завершения в сеть 10, указывающее сети 10 то, что он завершил конфигурирование на своей стороне.

Таблица 4 ниже описывает мобильность WTRU 20 во время сбоя при передаче обслуживания в соответствии с раскрытым способом.

Таблица 4 Мобильность и сбой при передаче обслуживания
Случаи	Первая фаза	Вторая фаза	T 2 истек	Приоритет выбора соты
UE входит в целевую соту	Продолжать, как если бы проблемы радиосвязи не возникли	Активность не может быть возобновлена без взаимодействия между UE и eNodeB	Прохождение через RRC_IDLE	1
UE возвращается в исходную соту	Нет данных	Активность не может быть возобновлена без взаимодействия между UE и eNodeB	Прохождение через RRC_IDLE	2
UE выбирает другую соту из этого же eNodeB	Нет данных	Активность не может быть возобновлена без взаимодействия между UE и eNodeB. Процедурой, которая должна использоваться, является FFS. Обычно не через RRC_IDLE	Прохождение через RRC_IDLE	3
UE выбирает соту другого eNodeB	Нет данных	Активность не может быть возобновлена без взаимодействия между UE и eNodeB. Процедурой, которая должна использоваться, является FFS. Обычно не через RRC_IDLE	Прохождение через RRC_IDLE	4

Для второй фазы, чтобы возобновлять активность, когда WTRU 20 возвращается в ту же соту или когда WTRU 20 выбирает другую соту из этого же eNB или другого eNB, раскрывается способ, при котором WTRU 20 осуществляет доступ к соте через процедуру произвольного доступа. Идентификации не связанного с предоставлением доступа уровня (NAS), используемые в процедуре произвольного доступа, также используются посредством eNB для того, чтобы определять, имеет ли eNB сохраненный RRC-контекст для WTRU 20. Если eNB находит RRC-контекст, который совпадает с идентификацией WTRU 20, eNB отправляет в ответ на RRC CONNECTION REQUEST сообщение (к примеру, RRC CONNECTION RESPONSE) или любые другие инициированные посредством WTRU процедуры RRC, указывающие WTRU 20 повторно использовать RRC-контекст, который он хранит.

Если eNB не находит RRC-контекст, который совпадает с идентификацией WTRU 20, новый eNB контактирует непосредственно с предыдущим eNB, где ожидался вызов, с использованием идентификации eNB, передаваемых посредством WTRU 20. Как раскрыто выше, альтернативно, eNB может извлекать идентификацию WTRU или контекст WTRU из MME.

Если контекст находится в старом eNB и передается, он отправляет в ответ на RRC CONNECTION REQUEST сообщение (к примеру, RRC CONNECTION RESPONSE) или любые другие, инициированные посредством WTRU процедуры RRC, указывающие WTRU 20 повторно использовать RRC-контекст, который он хранит. Если контекст не находится в новом или в старом eNB, осуществляется обычная процедура установления RRC-соединения и WTRU 20 предпочтительно отбрасывает RRC-контексты, которые он хранит. Следует отметить, что использование приоритета столбца выбора соты в таблицах 3 и 4 является альтернативным способом и что независимо от приоритета раскрытая процедура по-прежнему применима, если используются другие приоритеты для выбора/повторного соты.

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

1. Способ беспроводной связи, реализованный в беспроводном модуле приема/передачи (WTRU), содержащий этапы, на которых:

обнаруживают сбой, включающий в себя, по меньшей мере, одно из сбоев в линии радиосвязи (RL) и при передаче обслуживания (HO);

передают идентификацию беспроводного модуля приема/передачи (WTRU) и информационный элемент (IE), включающий в себя, по меньшей мере, одно из идентификаций исходного узла B и идентификаций исходной соты, чтобы осуществлять доступ к целевому узлу; и

принимают контекстную информацию от целевого узла B, по меньшей мере, частично на основе IE.

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

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

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

5. Способ по варианту осуществления 4, в котором целевой узел B и целевая сота отличаются от исходного узла B и исходной соты.

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

7. Способ по любому из вариантов осуществления 1-6, в котором контекстная информация включает в себя индикатор, чтобы использовать сохраненную контекстную информацию.

8. Способ по любому из вариантов осуществления 1-6, в котором контекстная информация включает в себя контекстную информацию, отличную от сохраненной контекстной информации.

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

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

11. Способ по варианту осуществления 10, в котором, по меньшей мере, одна специально предназначенная подпись принимается через команду передачи обслуживания.

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

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

14. Способ по любому предшествующему варианту осуществления, в котором, по меньшей мере, одна специально предназначенная подпись из набора подписей резервируется по широковещательному каналу для осуществления доступа к любой соте из любого узла B после сбоя в RL или при передаче обслуживания.

15. Способ по варианту осуществления 14, в котором набор подписей, зарезервированных для выделенного доступа, принимается в команде передачи обслуживания.

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

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

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

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

Надлежащие процессоры включают в себя, в качестве примера, процессор общего назначения, процессор специального назначения, традиционный процессор, процессор цифровых сигналов (DSP), множество микропроцессоров, один или более микропроцессоров в ассоциации с ядром DSP, контроллер, микроконтроллер, специализированные интегральные схемы (ASIC), схемы программируемых пользователем вентильных матриц (FPGA), любой другой тип интегральной схемы (IC) и/или конечный автомат.

Процессор, связанный с программным обеспечением, может быть использован для того, чтобы реализовывать радиочастотное приемопередающее устройство для использования в беспроводном модуле приема-передачи (WTRU), абонентском устройстве (UE), терминале, базовой станции, контроллере радиосети (RNC) или любом хост-компьютере. WTRU может использоваться вместе с модулями, реализованными в аппаратных средствах и/или программном обеспечении, такими как камера, модуль видеокамеры, видеофон, спикерфон, вибрационное устройство, динамик, микрофон, телевизионное приемопередающее устройство, гарнитура громкой связи, клавиатура, модуль Bluetooth®, частотно-модулированный (FM) радиомодуль, жидкокристаллический дисплей (LCD), дисплей на органических светоизлучающих диодах (OLED), цифровой музыкальный проигрыватель, мультимедийный проигрыватель, модуль устройства видеоигр, Интернет-обозреватель и/или любой модуль беспроводной локальной вычислительной сети (WLAN) или по стандарту сверхширокополосной радиосвязи (UWB).

1. Способ беспроводной связи между беспроводным модулем приема/передачи (WTRU) и целевым усовершенствованным узлом В (eNB), реализованный в WTRU, при этом способ содержит этапы, на которых:обнаруживают сбой связи;передают идентификацию WTRU и идентификацию исходной соты в целевой eNB в ответ на обнаруженный сбой связи; ипринимают индикатор от целевого eNB, который разрешает возобновление соединения посредством WTRU.

2. Способ по п.1, дополнительно содержащий этап, на котором осуществляют повторный выбор сот для выбора целевого eNB.

3. Способ по п.2, дополнительно содержащий этап, на котором выбирают eNB в качестве целевого eNB на основе идентификации исходной соты.

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

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

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

7. Способ по п.1, в котором сбоем связи является, по меньшей мере, одно из сбоя в линии радиосвязи (RL) или при передаче обслуживания (НО).

8. Способ по п.1, в котором индикатор от целевого eNB основан на идентификации WTRU, совпадающей с контекстом.

9. Беспроводной модуль передачи/приема (WTRU), содержащий:средство для обнаружения сбоя связи;средство для передачи идентификации WTRU и идентификации исходной соты в целевой усовершенствованный узел В (eNB) в ответ на обнаруженный сбой связи; исредство для приема индикатора от целевого eNB, который разрешает возобновление соединения посредством WTRU.

10. Беспроводной модуль передачи/приема (WTRU) по п.9, в котором идентификация исходной соты связана с исходным eNB, в котором WTRU ожидал вызова до обнаруженного сбоя связи.

11. Беспроводной модуль передачи/приема (WTRU) по п.9, в котором сбоем связи является, по меньшей мере, один из сбоя в линии радиосвязи (RL) или при передаче обслуживания (НО).

12. Беспроводной модуль передачи/приема (WTRU) по п.9, дополнительно содержащий средство для осуществления повторного выбора сот так, чтобы выбрать целево