Способы и система для выполнения передачи обслуживания в системе беспроводной связи

Способы и система для выполнения передачи обслуживания в системе беспроводной связи

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение имеет отношение к системам беспроводной связи. Конкретнее, настоящее изобретение имеет отношение к способу и системе для выполнения передачи обслуживания в системе долгосрочного развития (LTE).

УРОВЕНЬ ТЕХНИКИ

LTE для системы четвертого поколения (4G) сейчас рассматривается для развития нового радиоинтерфейса и архитектуры радиосети, которое обеспечивает высокую скорость передачи данных, низкую задержку, оптимизацию пакетов и улучшенную пропускную способность и покрытие системы. Для системы LTE вместо использования множественного доступа с кодовым разделением каналов (CDMA), который в настоящее время используется в системе 3G, предлагаются для использования множественный доступ с ортогональным частотным разделением каналов (OFDMA) и множественный доступ с разделением каналов по частоте (FDMA) в передачах нисходящей линии связи и восходящей линии связи соответственно. Вследствие изменения во многих особенностях в системе LTE должны быть пересмотрены процедуры передачи обслуживания внутри LTE и связанные операции.

Управление мобильностью пользовательского оборудования (UE) в режиме LTE_ACTIVE оперирует всеми необходимыми этапами для плавной передачи обслуживания в системе LTE, например принятие решения о передаче обслуживания внутри LTE на стороне сети-источника (то есть управление и оценка измерений UE и усовершенствованного узла Б (eNode-B), принимая во внимание специфичные для UE ограничения области), подготовка радиоресурсов на стороне сети-получателя, указание UE взаимодействовать с новыми радиоресурсами, освобождение радиоресурсов на стороне сети-источника и т.п. Механизм управления мобильностью UE также оперирует передачей контекстных данных между вовлеченными узлами и обновлением связей узлов на плоскости управления (C-plane) и плоскости пользователя (U-plane).

Фиг.1 - схема сигнализации в процессе 100 передачи обслуживания, предложенная в настоящее время для системы LTE. UE 152 и источник eNode-B 154 выполняют измерения и обмениваются отчетами об измерениях (этап 102). Источник eNode-B 154 принимает решение о передаче обслуживания на основе отчетов об измерениях (этап 104). Источник eNode-B 154 затем отправляет запрос на передачу обслуживания получателю eNode-B 156 (этап 106). Решение о передаче обслуживания и последующие процедуры до завершения передачи обслуживания выполняются без привлечения объекта 158 управления мобильностью/объекта 158 плоскости пользователя (MME/UPE) (то есть сообщения о подготовке передачи обслуживания непосредственно передаются между источником eNode-B 154 и получателем eNode-B 156).

Получатель eNode-B 156 выполняет управление допуском для UE 152 (этап 108). Если получатель eNode-B 156 может принять UE 152, то получатель eNode-B 156 отправляет ответ передачи обслуживания источнику eNode-B 154 (этап 110). Источник eNode-B 154 отправляет команду передачи обслуживания к UE 152 (этап 112). Для плавной передачи обслуживания устанавливается туннель U-плоскости между источником eNode-B 154 и получателем eNode-B 156.

UE 152 и получатель eNode-B 156 затем обмениваются сигналами уровня 1 и 2 (L1/L2) (этап 114). Во время выполнения передачи обслуживания данные пользователя могут перенаправляться от источника eNode-B 154 к получателю eNode-B 156. Перенаправление может происходить зависящим от службы и специфичным для реализации способом. Перенаправление данных пользователя от источника eNode-B 154 к получателю eNode-B 156 должно происходить так долго, пока принимаются пакеты на источнике eNode-B 154 от UPE 158.

После того, как установлено соединение с получателем eNode-B 156, UE 152 отправляет сообщение о завершении передачи обслуживания к получателю eNode-B 156 (этап 116). Получатель eNode-B 156 отправляет сообщение о завершении передачи обслуживания к MME/UPE 158 (этап 118). MME/UPE 158 затем отправляет подтверждение завершения передачи обслуживания (ACK) получателю eNode-B 156 (этап 120). После того, как MME/UPE 158 информируется получателем eNode-B 156, что UE 152 получил доступ на получателе eNode-B 156, с помощью сообщения о завершении передачи обслуживания, канал U-плоскости переключается MME/UPE 158 с источника eNode-B 154 на получателя eNode-B 156.

Освобождение радиоресурсов на источнике eNode-B 154 инициируется сообщением об освобождении ресурса, отправляемом получателем eNode-B 156 (этап 122). После приема сообщения об освобождении ресурса от получателя eNode-B 156 источник eNode-B 154 освобождает радиоресурсы для UE 152 (этап 124). UE 152 выполняет обновление положения с помощью MME/UPE 158 (этап 126).

Вышеприведенная процедура 100 передачи обслуживания внутри LTE не предоставляет подробностей о команде передачи обслуживания (например, конфигурации UE 152 на основе требования получателя eNode-B) и подробностей о работе UE после того, как UE принимает команду передачи обслуживания (например, передача данных между источником eNode-B 154 и UE 152, и управление радиосвязью (RLC), и сброс гибридного автоматического запроса на повторение (HARQ), и идентификация интервала порядкового номера (SN) по протоколу конвергенции пакетных данных (PDCP) с помощью UE 152). Вышеприведенная процедура 100 передачи обслуживания внутри LTE также не предоставляет подробностей о настройке синхронизации UE для синхронных и асинхронных eNode-B и подробностей для эффективного планирования ресурсов на получателе eNode-B для передачи UE.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение имеет отношение к способу и системе для выполнения передачи обслуживания в системе LTE. Источник eNode-B принимает решение о передаче обслуживания на основе измерений и отправляет запрос на передачу обслуживания к получателю eNode-B. Получатель eNode-B отправляет ответ передачи обслуживания источнику eNode-B, указывающий, что следует начинать передачу обслуживания. Источник eNode-B затем отправляет команду передачи обслуживания модулю беспроводной передачи/приема (WTRU). Команда передачи обслуживания включает в себя по меньшей мере одну из информации о реконфигурации, информации касательно настройки синхронизации, относительной разницы синхронизации между источником eNode-B и получателем eNode-B информации касательно процесса начального планирования на получателе eNode-B и информации об измерении для получателя eNode-B. WTRU затем обращается к получателю eNode-B и обменивается сигналами уровня 1/2 для выполнения синхронизации нисходящей линии связи, настройки синхронизации и выделения ресурсов восходящей линии связи и нисходящей линии связи на основе информации, включенной в команду передачи обслуживания.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг.1 - схема сигнализации в процессе передачи обслуживания, предложенная в настоящее время для системы LTE; и

Фиг.2 - схема сигнализации процесса передачи обслуживания внутри LTE в соответствии с настоящим изобретением.

ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

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

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

Фиг.2 - схема сигнализации процесса 200 передачи обслуживания внутри LTE в соответствии с настоящим изобретением. WTRU 252 и источник eNode-B 254 каждый выполняют по меньшей мере одно измерение, и WTRU 252 отправляет отчет об измерении источнику eNode-B 254 (этап 202). Источник eNode-B 254 принимает решение о передаче обслуживания на основе отчета об измерении и результата своего собственного измерения (этап 204). Источник eNode-B 254 затем отправляет запрос на передачу обслуживания получателю eNode-B 256 (этап 206). Получатель eNode-B 256 выполняет управление допуском для WTRU 252 (этап 208). Если получатель eNode-B 256 может принять WTRU 252, то получатель eNode-B 256 отправляет ответ передачи обслуживания источнику eNode-B 254, указывающий, что следует начинать передачу обслуживания (этап 210). Источник eNode-B 254 затем отправляет команду передачи обслуживания к WTRU 252 (этап 212).

Команда передачи обслуживания должна включать в себя по меньшей мере одно из информации о реконфигурации для уровня управления радиоресурсами (RRC), управления радиосвязью (RLC), управления доступом к среде передачи (MAC) и физического (PHY) уровня, информации касательно настройки синхронизации, когда передается обслуживание от источника eNode-B 254 к получателю eNode-B 256 (то есть, следует ли WTRU 252 выполнять настройку синхронизации автономно или с использованием процедуры канала с произвольным доступом (RACH), нужно ли использовать RACH, будет использоваться случайная или назначенная подпись доступа, или т.п.), относительной разницы синхронизации между eNode-B (или сотами) для автономной настройки синхронизации, информации касательно процедуры начального планирования радиоресурсов на получателе eNode-B 256, информации об измерении для получателя eNode-B 256, и т.п. Информация касательно процедуры начального планирования на получателе eNode-B 256 указывает, следует ли использовать процедуру доступа к RACH для запроса выделения ресурсов, или получатель eNode-B 256 может планировать ресурсы для WTRU 252 без получения явного запроса выделения ресурсов от WTRU 252. В качестве альтернативы измерение и другая информация о конфигурации может отправляться к WTRU 252 с помощью получателя eNode-B 256 после приема сообщения о завершении передачи обслуживания от WTRU 252 на этапе 226.

Для плавной передачи обслуживания устанавливается туннель U-плоскости между источником eNode-B 254 и получателем eNode-B 256. После отправки команды передачи обслуживания источник eNode-B 254 может перенаправить данные пользователя к получателю eNode-B 256. Перенаправление может происходить зависящим от службы и специфичным для реализации способом.

После приема команды передачи обслуживания от источника eNode-B 254 WTRU 252 может продолжить передавать и принимать данные от источника eNode-B 254. Процесс передачи данных зависит от того, используется ли синхронизированная передача обслуживания или несинхронизированная передача обслуживания.

Когда используется процедура синхронизированной передачи обслуживания (то есть источник eNode-B 254 и получатель eNode-B 256 синхронизированы или относительная разница синхронизации известна WTRU 252), источник eNode-B 254 и WTRU 252 может продолжить передавать и принимать данные после приема команды передачи обслуживания до некоторого момента передачи обслуживания (t_HO), который сигнализируется с помощью команды передачи обслуживания. Переданные данные после приема команды передачи обслуживания предпочтительно ограничиваются неполными блоками служебных данных (SDU) (то есть протокольным блоком данных RLC (PDU)), переданными до того, как была отправлена команда передачи обслуживания. Управляющее сообщение RLC отправляется к WTRU 252 для указания порядкового номера (SN) у успешно принятого SDU и интервал SDU. SN может быть SN PDCP или другими типами SN. SN, общий для успешно принятых SDU и неуспешно принятых SDU, может включаться в управляющее сообщение RLC.

Когда используется процедура несинхронизированной передачи обслуживания (то есть источник eNode-B 254 и получатель eNode-B 256 не синхронизированы или относительная разница синхронизации не известна WTRU 252), источник eNode-B 254 прекращает передачу, как только источник eNode-B 254 отправляет команду передачи обслуживания к WTRU 252. WTRU 252 также прекращает передачу пакетов данных к источнику eNode-B 254, как только WTRU 252 принимает команду передачи обслуживания. В качестве альтернативы источник eNode-B 254 может продолжать передачу пакетов данных, пока WTRU 252 переключается на получателя eNode-B 254.

После приема команды передачи обслуживания WTRU 252 обращается к получателю eNode-B 256 и обменивается сигналами уровня 1/2 (L1/L2) с получателем eNode-B 256 для выполнения синхронизации нисходящей линии связи, настройки синхронизации (то есть синхронизации восходящей линии связи) и выделения ресурсов восходящей линии связи и нисходящей линии связи на основе информации, включенной в команду передачи обслуживания.

Для настройки синхронизации (то есть синхронизации восходящей линии связи) WTRU 252 реализует один из двух вариантов. Предпочтительно сеть решает, какой вариант использовать.

В соответствии с первым вариантом WTRU 252 автономно выполняет настройку синхронизации на основе относительной разницы синхронизации между источником eNode-B 254 (или сотой) и получателем eNode-B 256 (или сотами) (этап 214а). Информация об относительной разнице синхронизации предпочтительно включается в команду передачи обслуживания.

В соответствии со вторым вариантом используется традиционная процедура доступа к RACH для настройки синхронизации (этап 214b). WTRU отправляет преамбулу RACH получателю eNode-B, а получатель eNode-B вычисляет ошибку синхронизации на основе переданной преамбулы RACH и отправляет WTRU информацию об ошибке синхронизации для синхронизации восходящей линии связи.

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

Отдельная (назначенная) подпись преамбулы RACH может быть зарезервирована для цели передачи обслуживания, чтобы указывать, что отправитель является WTRU, передающим обслуживание (то есть WTRU, подвергающимся процессу передачи обслуживания). Эта назначенная подпись преамбулы RACH указывается в команде передачи обслуживания. После приема зарезервированной подписи преамбулы RACH получатель eNode-B 256 распознает, что отправитель является WTRU, передающим обслуживание, и может предоставить приоритет передающему обслуживание WTRU. Это может предотвратить процесс произвольного доступа, который является причиной большого времени перерыва во время передачи обслуживания. В качестве альтернативы сообщение RACH, следующее за преамбулой RACH, может явно указывать, что отправитель является WTRU, передающим обслуживание. Передающему обслуживание WTRU предпочтительно назначается больший приоритет для доступа к eNode-B (соте), чем WTRU, который не передает обслуживание, вследствие смены состояний. Процедура RACH, использующая зарезервированную подпись преамбулы RACH, может использоваться либо в синхронизированной, либо в несинхронизированной передаче обслуживания eNode-B (или соты). Распределение физических радиоресурсов для отправки зарезервированной подписи преамбулы RACH к получателю eNode-B 256 также может включаться в команду передачи обслуживания для уменьшения задержки для произвольного доступа.

Процедура произвольного доступа может использоваться для разных целей. Процедура произвольного доступа может использоваться для запуска обмена информацией между WTRU и сетью, которая требует смены состояний с состояния LTE_idle на состояние LTE_ACTIVE. Процедура произвольного доступа может использоваться для настройки синхронизации во время передачи обслуживания и затем для запроса доступа к новой соте. Когда процедура произвольного доступа используется во время передачи обслуживания, следует минимизировать задержку, вызванную процедурой произвольного доступа. Поэтому должны быть отличия (например, назначение приоритета передающему обслуживание WTRU) между произвольным доступом к получателю eNode-B (соте) во время передачи обслуживания и произвольным доступом к источнику eNode-B (соте) в не связанной с передачей обслуживания ситуации из-за смены состояний с состояния LTE-Idle на состояние LTE-Active в не связанном с передачей обслуживания случае.

После приема подписи преамбулы RACH от WTRU получатель eNode B оценивает значение настройки синхронизации и отправляет это значение обратно к WTRU (этап 216).

После выполнения настройки синхронизации (либо автономно, либо посредством передачи преамбулы RACH) WTRU 202 может отправить запрос выделения радиоресурсов к получателю eNode-B 256 (этап 218). Запрос предпочтительно отправляется посредством сообщения RACH, следующего за преамбулой RACH. Получатель eNode-B 256 затем планирует ресурсы нисходящей линии связи и восходящей линии связи для WTRU 252 (этап 220). В качестве альтернативы получатель eNode-B 256 может планировать ресурсы для WTRU 252 без приема явного запроса от WTRU 252. Планирование ресурсов может происходить в любое время после того, как получатель eNode-B 256 признает WTRU на этапе 208. Например, для процедуры синхронизированной передачи обслуживания получатель eNode-B 256 может планировать ресурсы восходящей линии связи и нисходящей линии связи после некоторого предопределенного времени (раньше, чем ожидаемое время для переключения eNode-B).

Получатель eNode-B 256 отправляет выделение ресурсов восходящей линии связи к WTRU 252 (этап 222). Этот ресурс восходящей линии связи используется для отправки сообщения о завершении передачи обслуживания на этапе 226, а не для передачи данных. WTRU 252 предпочтительно сбрасывает параметры RLC и HARQ после приема выделения ресурсов восходящей линии связи от получателя eNode-B 256 (этап 224). В качестве альтернативы WTRU 252 может сбрасывать параметры RLC и HARQ после приема и обработки команды передачи обслуживания на этапе 212. Эти параметры, относящиеся к передаче к получателю eNode-B 256 (или соте), включаются в команду передачи обслуживания.

WTRU 252 отправляет сообщение о завершении передачи обслуживания к получателю eNode-B 256 (этап 226). WTRU 252 предпочтительно включает в себя начальный SN PDCP в восходящей линии связи, который необходимо передать, в сообщение о завершении передачи обслуживания. При желании WTRU 252 может отправлять управляющее сообщение RLC получателю eNode-B 256 после сообщения о завершении передачи обслуживания для указания успешно переданных SDU и интервала SDU.

Получатель eNode-B 256 отправляет информацию о планировании ресурсов восходящей линии связи и нисходящей линии связи для передачи данных и сообщения RRC к WTRU (этап 228). Сообщение RRC включает в себя по меньшей мере одно из информации о реконфигурации однонаправленного канала радиодоступа (RAB), начального SN PDCP в нисходящей линии связи, управляющего сообщения RLC и связанной с измерением информации. Часть или вся вышеупомянутая информация может при желании отправляться как часть команды передачи обслуживания или первый пакет от получателя eNode-B 256.

Получатель eNode-B 256 отправляет сообщение о завершении передачи обслуживания к MME/UPE 258 для информирования, что WTRU 252 получил доступ на получателе eNode-B 256 (этап 230). MME/UPE 258 затем отправляет подтверждение завершения передачи обслуживания (ACK) получателю eNode-B 256 и переключает информационный канал U-плоскости с источника eNode-B 254 на получателя eNode-B 256 (этап 232). Освобождение радиоресурсов на источнике eNode-B 254 инициируется сообщением об освобождении ресурса, отправляемом получателем eNode-B 256 (этап 234). После приема сообщения об освобождении ресурса от получателя eNode-B 256 источник eNode-B 254 освобождает радиоресурсы для WTRU 252 (этап 236).

Случай сбоя передачи обслуживания объясняется ниже с помощью ссылки на фиг. 2. Когда WTRU 252 не может успешно передать обслуживание, WTRU 252 может обратиться к процедуре отказа линии радиосвязи (RL) или повторного выбора соты. Если команда передачи обслуживания терпит неудачу на этапе 212, то источник eNode-B 254 информирует получателя eNode-B 256 о таком сбое. Получатель eNode-B 256 планирует любые ресурсы восходящей линии связи и нисходящей линии связи для WTRU 252 после этапа 208. При выполнении повторного выбора соты в случае сбоя передачи обслуживания WTRU 252 может сначала попытаться получить доступ к изначально подключенной соте в рамках источника eNode-B 254. Если это не удается, то WTRU 252 может попытаться получить доступ к другим сотам в рамках источника eNode-B. Если это также не удается, то WTRU 252 может попытаться получить доступ к другим сотам, не включенным в источник eNode-B, на основе результата измерения.

Источник eNode-B 254 поддерживает таймер для определения времени, если сообщение о завершении передачи обслуживания не принято после заранее установленного времени после сбоя команды передачи обслуживания. Источник eNode-B 254 может сбрасывать контекст RRC, контекст PDCP, параметры RLC и HARQ, относящиеся к WTRU 252, если заканчивается таймер сбоя передачи обслуживания. Источник eNode-B затем освобождает радиоресурсы для WTRU 252.

Когда выполняется повторный выбор соты с помощью WTRU 252, идентификатор (ID) соты-источника или eNode-B отправляется с помощью WTRU 252 к любому eNode-B как часть информации о временном идентификаторе радиосети (RNTI) в LTE для обнаружения, обращается ли WTRU 252 к исходной соте или к любым другим сотам. На источнике eNode-B уровень MAC источника eNode-B информирует его уровень RRC о сбое передачи обслуживания, если уровень MAC обнаруживает неудавшуюся передачу команды передачи обслуживания.

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

1. Способ для выполнения передачи обслуживания в системе беспроводной связи.

2. Способ по варианту 1 осуществления, содержащий WTRU и источник eNode-B, выполняющий измерения.

3. Способ по варианту 2 осуществления, содержащий источник eNode-B, принимающий решение о передаче обслуживания на основе измерений.

4. Способ по варианту 3 осуществления, содержащий источник eNode-B, отправляющий запрос на передачу обслуживания к получателю eNode-B.

5. Способ по варианту 4 осуществления, содержащий получатель eNode-B, отправляющий ответ передачи обслуживания источнику eNode-B, указывающий, что следует начинать передачу обслуживания.

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

7. Способ по варианту 6 осуществления, в котором информация о реконфигурации предназначена по меньшей мере для одного из уровня RRC, уровня RLC, уровня MAC и физического уровня.

8. Способ по любому из вариантов 6-7 осуществления, в котором команда передачи обслуживания указывает, что получатель eNode-B планирует ресурс для WTRU на основе процедуры доступа к RACH.

9. Способ по любому из вариантов 6-8 осуществления, в котором команда передачи обслуживания указывает, что получатель eNode-B планирует ресурс для WTRU без приема явного запроса выделения ресурсов от WTRU.

10. Способ по любому из вариантов 6-9 осуществления, дополнительно содержащий источник eNode-B, перенаправляющий данные пользователя к получателю eNode-B.

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

12. Способ по любому из вариантов 6-9 осуществления, в котором WTRU и источник eNode-B продолжают передавать и принимать данные после того, как WTRU принимает команду передачи обслуживания.

13. Способ по варианту осуществления 12, в котором WTRU и источник eNode-B продолжают передавать и принимать данные до времени передачи обслуживания, которое сигнализируется посредством команды передачи обслуживания.

14. Способ по любому из вариантов 12-13 осуществления, в котором переданные данные являются неполным SDU.

15. Способ по варианту 14 осуществления, в котором источник eNode-B отправляет сообщение RLC к WTRU, включающее в себя SN, для указания успешно принятого SDU и неуспешно принятого SDU.

16. Способ по варианту 15 осуществления, в котором SN является SN PDCP или обычным SN.

17. Способ по любому из вариантов 6-9 осуществления, в котором источник eNode-B прекращает передачу данных к WTRU, как только источник eNode-B отправляет команду передачи обслуживания к WTRU, и WTRU прекращает передачу данных к источнику eNode-B, как только WTRU принимает команду передачи обслуживания.

18. Способ по любому из вариантов 6-9 осуществления, в котором источник eNode-B продолжает передачу данных, пока WTRU не переключится на получателя eNode-B.

19. Способ по любому из вариантов 6-18 осуществления, дополнительно содержащий WTRU, выполняющий настройку синхронизации с получателем eNode-B.

20. Способ по варианту 19 осуществления, в котором WTRU автономно выполняет настройку синхронизации на основе относительной разницы синхронизации между источником eNode-B и получателем eNode-B.

21. Способ по любому из вариантов 19-20 осуществления, в котором информация об относительной разнице синхронизации включается в команду передачи обслуживания.

22. Способ по любому из вариантов 19-21 осуществления, в котором WTRU использует процедуру доступа к RACH для настройки синхронизации.

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

24. Способ по варианту 23 осуществления, в котором отдельная подпись преамбулы RACH резервируется для цели передачи обслуживания.

25. Способ по варианту 24 осуществления, в котором зарезервированная подпись преамбулы RACH указывается в команде передачи обслуживания.

26. Способ по любому из вариантов 6-25 осуществления, дополнительно содержащий получателя eNode-B, выделяющего ресурс восходящей линии связи для передачи сообщения о завершении передачи обслуживания для WTRU.

27. Способ по варианту 26 осуществления, в котором получатель eNode-B планирует ресурс восходящей линии связи на основе запроса выделения ресурсов от WTRU.

28. Способ по варианту 27 осуществления, в котором запрос выделения ресурсов отправляется через RACH.

29. Способ по варианту 26 осуществления, в котором получатель eNode-B планирует ресурс восходящей линии связи без получения запроса от WTRU.

30. Способ по любому из вариантов 6-29 осуществления, дополнительно содержащий WTRU, сбрасывающий RLC и HARQ после получения ресурса восходящей линии связи от получателя eNode-B.

31. Способ по любому из вариантов 6-29 осуществления, дополнительно содержащий WTRU, сбрасывающий RLC и HARQ после приема команды передачи обслуживания.

32. Способ по любому из вариантов 6-31 осуществления, дополнительно содержащий WTRU, отправляющий сообщение о завершении передачи обслуживания к получателю eNode-B, причем сообщение о завершении передачи обслуживания включает в себя SN PDCP в восходящей линии связи, который нужно передать.

33. Способ по варианту 32 осуществления, дополнительно содержащий WTRU, отправляющий управляющее сообщение RLC к получателю eNode-B после сообщения о завершении передачи обслуживания, чтобы указать успешно переданный SDU и интервал SDU.

34. Способ по любому из вариантов 6-33 осуществления, дополнительно содержащий получателя eNode-B, отправляющего информацию о планировании восходящей линии связи и нисходящей линии связи для передачи данных и сообщение RRC к WTRU, причем сообщение RRC включает в себя по меньшей мере одно из информации о реконфигурации RAB, начального SN PDCP в нисходящей линии связи, управляющего сообщения RLC и связанной с измерением информации.

35. Способ по любому из вариантов 6-34 осуществления, дополнительно содержащий WTRU, выполняющий процедуру отказа линии радиосвязи, когда команда передачи обслуживания доставлена неуспешно.

36. Способ по любому из вариантов 6-35 осуществления, в котором источник eNode-B поддерживает таймер для ограничения времени передачи, если сообщение о завершении передачи обслуживания не принимается до заранее установленного момента времени после того, как команда передачи обслуживания доставлена неуспешно.

37. Способ по варианту 36 осуществления, в котором источник eNode-B сбрасывает контекст RRC, контекст PDCP, параметры RLC и HARQ, относящиеся к WTRU, если заканчивается таймер.

38. Способ по любому из вариантов 6-37 осуществления, дополнительно содержащий WTRU, выполняющий процедуру повторного выбора соты, когда команда передачи обслуживания доставлена неуспешно.

39. Способ по варианту 38 осуществления, в котором WTRU сначала пытается получить доступ к изначально подключенной соте в источнике eNode-B.

40. Способ по варианту 39 осуществления, в котором WTRU пытается получить доступ к другой соте в источнике eNode-B, если WTRU не удается получить доступ к изначально подключенной соте.

41. Способ по варианту 40 осуществления, в котором WTRU пытается получить доступ к другой соте, не включенной в источник eNode-B, если WTRU не удается получить доступ к упомянутой другой соте в источнике eNode-B.

42. Способ по любому из вариантов 38-41 осуществления, в котором WTRU отправляет ID источника eNode-B к получателю eNode-B во время повторного выбора соты.

43. Система беспроводной связи для выполнения передачи обслуживания.

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

45. Система по варианту 44 осуществления, содержащая получателя eNode-B.

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

47. Система по варианту 46 осуществления, в которой информация о реконфигурации предназначена по меньшей мере для одного из уровня RRC, уровня RLC, уровня MAC и физического уровня.

48. Система по любому из вариантов 46-47 осуществления, в которой команда передачи обслуживания указывает, что получатель eNode-B планирует ресурс для WTRU, используя процедуру доступа к RACH.

49. Система по любому из вариантов 46-48 осуществления, в которой команда передачи обслуживания указывает, что получатель eNode-B планирует ресурс для WTRU без приема явного запроса выделения ресурсов от WTRU.

50. Система по любому из вариантов 46-49 осуществления, в которой источник eNode-B сконфигурирован для перенаправления данных пользователя к получателю eNode-B после отправки команды передачи обслуживания к WTRU.

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

52. Система по любому из вариантов 46-51 осуществления, в которой WTRU и источник eNode-B продолжают передавать и принимать данные после того, как WTRU принимает команду передачи обслуживания.

53. Система по любому из вариантов 46-51 осуществления, в которой WTRU и источник eNode-B продолжают передавать и принимать данные до момента передачи обслуживания, который сигнализируется посредством команды передачи обслуживания.

54. Система по любому из вариантов 52-53 осуществления, в которой переданные данные являются неполным SDU.

55. Система по варианту 54 осуществления, в которой источник eNode-B отправляет сообщение RLC к WTRU, включающее в себя SN, для указания успешно принятого SDU и неуспешно принятого SDU.

56. Система по варианту 55 осуществления, в которой SN является SN PDCP или обычным SN.

57. Система по любому из вариантов 46-51 осуществления, в которой источник eNode-B прекращает передачу данных к WTRU, как только источник eNode-B отправляет команду передачи обслуживания к WTRU, и WTRU прекращает передачу данных к источнику eNode-B, как только WTRU принимает команду передачи обслуживания.

58. Система по любому из вариантов 46-51 осуществления, в котором источник eNode-B продолжает передачу данных, пока WTRU не переключится на получателя eNode-B.

59. Система по любому из вариантов 46-58 осуществления, в которой WTRU сконфигурирован для выполнения настройки синхронизации с получателем eNode-B.

60. Система по варианту 59 осуществления, в которой WTRU сконфигурирован для автономного выполнения настройки синхронизации на основе относительной разницы синхронизации между источником eNode-B и получателем eNode-B.

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

62. Система по любому из вариантов 59-61 осуществления, в которой WTRU сконфигурирован для использования процедуры доступа к RACH для настройки синхронизации.

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

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

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

66. Система по любому из вариантов 46-65 осуществления, в которой получатель eNode-B сконфигурирован для выделения ресурса восходящей линии связи для передачи сообщения о завершении передачи обслуживания для WTRU.

67. Система по варианту 66 осуществления, в которой получатель eNode-B сконфигурирован для планирования ресурса восходящей линии связи на основе запроса выделения ресурсов от WTRU.

68. Система по варианту 67 осуществления, в которой запрос выделения ресурсов отправляется через RACH.

69. Система по варианту 66 осуществления, в которой получатель eNode-B сконфигурирован для планирования ресурса восходящей линии связи без получения запроса от WTRU.

70. Система по любому из вариантов 66-69 осуществления, в которой WTRU сконфигурирован для сбора RLC и HARQ после получения ресурса восходящей линии связи от получателя eNode-B.

71. Система по любому из вариантов 46-70 осуществления, в которой WTRU сконфигурирован для сбора RLC и HARQ после получения команды передачи обслуживания.

72. Система по любому из вариантов 46-71 осуществления, в которой WTRU сконфигурирован для отправки сообщения о завершении передачи обслуживания к получателю eNode-B, причем сообщение о завершении передачи обслуживания включает в себя SN PDCP в восходящей линии связи, который нужно передать.

73. Система по варианту 72 осуществления, в которой WTRU сконфигурирован для отправки управляющего сообщения RLC к получателю eNode-B после сообщения о завершении передачи обслуживания, чтобы указать успешно переданный SDU и интервал SDU.

74. Система по любому из вариантов 46-73 осуществления, в которой eNode-B сконфигурирован для отправки информации о планировании восходящей линии связи и нисходящей линии связи для передачи данных и сообщение RRC к WTRU, причем сообщение RRC включает в себя по меньшей мере одно из информации о реконфигурации RAB, начального SN PDCP в нисходящей линии связи, управляющего сообщения RLC и связанной с измерением информации.

75. Система по любому из вариантов 46-74 осуществления, в которой WTRU сконфигурирован для выполнения процедуры отказа линии радиосвязи, когда команда передачи обслуживания доставлена неуспешно.

76. Система по любому из вариантов 46-75 осуществления, в которой источник eNode-B включает в себя таймер для ограничения времени передачи, если сообщение о завершении передачи обслуживания не принимается до заранее установленного момента врем