Обновление/повторный выбор соты во время расширенного состояния канала доступа прямой линии связи соты (cell_fach)

Обновление/повторный выбор соты во время расширенного состояния канала доступа прямой линии связи соты (cell_fach)

Иллюстрации

Показать все

Реферат

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

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

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

Блоки беспроводной передачи/приема, или, иначе, беспроводные приемопередающие устройства (WTRU) в UTRAN могут быть в незанятом режиме или соединенном режиме. На основании мобильности и активности WTRU, во время соединенного режима, универсальная наземная сеть радиодоступа (UTRAN) может предписывать WTRU переходить между некоторым количеством подсостояний управления ресурсами радиосвязи (RRC): состояниями Cell_РСН (канала поискового вызова соты), URA_РСН (канала поискового вызова универсальной сети радиодоступа), Cell_FACH (канала доступа прямой линии связи соты) и Cell_DCH (выделенного канала соты). Связь плоскости пользователя между WTRU и UTRAN возможна только во время состояния Cell_FACH и Cell_DCH. Состояние Cell_DCH характеризуется выделенными каналами как на восходящей линии связи, так и на нисходящей линии связи. На стороне WTRU это соответствует непрерывной передаче и приему и может быть затруднительным по требованиям к питанию пользователя. Состояние Cell_FACH не использует выделенные каналы и, таким образом, предоставляет возможность лучшей потребляемой мощности за счет более низкой пропускной способности восходящей линии связи и нисходящей линии связи.

Состояние Cell_FACH хорошо приспособлено для потока обмена сигнализации (например, передачи сообщения CELL UPDATE (ОБНОВЛЕНИЕ СОТЫ)) и для приложений, требующих очень низкой пропускной способности восходящей линии связи. Связь по восходящей линии связи достигается через канал с произвольным доступом (RACH), который отображается в физический канал с произвольным доступом (PRACH). RACH является основанным на конфликтах каналом с процедурой линейного нарастания мощности для захвата канала и для настройки мощности передачи. Связь по нисходящей линии связи происходит через прямой канал доступа (FACH), который отображается в дополнительный общий физический канал управления (S-CCPCH). Системная информация, включающая в себя подробности настроек для каналов восходящей линии связи (то есть RACH) и нисходящей линии связи (то есть FACH), которые должны использоваться в Cell_FACH, считывается из широковещательного канала (ВСН).

В состоянии Cell_FACH мобильность обрабатывается автономно посредством WTRU. Концепция мягкой эстафетной передачи обслуживания в настоящее время (что касается версии 6 стандарта партнерства третьего поколения (3GPP)) не существует в пределах Cell_FACH. WTRU делает замеры независимо и определяет, в какой соте следует базироваться.

Возможность использования высокоскоростного пакетного доступа по нисходящей линии связи (HSDPA) в состоянии Cell_FACH (то есть состоянии расширенного Cell_FACH) была изучена органами стандартизации. HSDPA является признаком, который был введен в версии 5 спецификации 3GPP для работы в состоянии Cell_DCH. HSDPA пытается улучшить использование совместно используемой емкости нисходящей линии связи посредством использования трех ключевых концепций: адаптивных модуляции и кодирования (АМС), повторных передач с использованием схемы гибридного автоматического запроса на повторение (HARQ) и планирования Узла Б все работает на очень высокой скорости.

Каждому WTRU, имеющему соединение HSDPA, назначается временный идентификатор радиосети HS-DSCH (H-RNTI). H-RNTI уникален в пределах соты и назначается обслуживающим контроллером радиосети (SRNC). WTRU прикрепляется к единственной обслуживающей соте (то есть Узлу Б). WTRU должен сообщать о ресурсах физического канала для использования (информацию о высокоскоростном физическом, совместно используемом канале нисходящей линии связи (HS-PDSCH)), а также о том, каким образом настраивать процессы HARQ и память HARQ.

В результате мобильности, WTRU может переключаться с одной обслуживающей соты (исходного Узла Б) на другую (целевой Узел Б). UTRAN управляет согласованиями по времени этого переключения. SRNC должен останавливать отправку данных на исходный Узел Б и начинать отправку данных на целевой Узел Б с новой конфигурацией. Одновременно RNC должен отправлять управляющее сообщение (сообщение RRC) для установления в исходное состояние сущности (объекта) управления доступом к среде передачи HS-DSCH (MAC-hs) в WTRU.

Установка в исходное состояние MAC-hs вызывала бы очистку от старых данных программных буферов для всех сконфигурированных процессов HARQ; остановку всех активных таймеров разблокировки переупорядочения (Т1) и установку всех таймеров (Т1) в их начальное значение; начинание порядкового номера передачи (TSN) со значения 0 для следующей передачи в каждом сконфигурированном процессе HARQ; инициализацию переменных RcvWindow_UpperEdge и next_expected_TSN в их начальные значения; разборку всех модулей данных протокола (PDU) MAC-hs в буфере переупорядочения и выдачу всех PDU управления доступом к среде передачи выделенного канала (MAC-d) в сущность MAC-d; очистку от старых данных буфера переупорядочения; и в некоторых случаях, указание всем сущностям управления радиосвязью (RLC) режима подтверждения (AM), отображаемым в высокоскоростной совместно используемый канал нисходящей линии связи (HS-DSCH), что следует формировать отчет о состоянии.

При попытке передать HSDPA во время состояния расширенного Cell_FACH возникает много проблем, на решение которых должны быть направлены усилия. В настоящее время HSDPA стандартизован для работы только в состоянии Cell_DCH. WTRU использует переменную HS_DSCH_RECEPTION для проверки, разрешен или нет прием HSDPA. В состоянии расширенного Cell_FACH WTRU принимает общую информацию о настройках канала в широковещательной системной информации. Однако никакая информация о конфигурации HSDPA не переносится в широковещательной информации.

Состояние расширенного Cell_FACH будет использовать однонаправленные радиоканалы сигнализации нисходящей линии связи в общих логических каналах (общем канале управления (CCCH) и общем канале потока обмена (CTCH)). Типичные сообщения RRC, переносимые по этим однонаправленным радиоканалам, включают в себя сообщение RRC CONNECTION SETUP (НАСТОЙКА СОЕДИНЕНИЯ RRC) и сообщение CELL UPDATE CONFIRM (ПОДТВЕРЖДЕНИЕ ОБНОВЛЕНИЯ СОТЫ). Первое сообщение ставит проблему, так как подробности конфигурации HSDPA включены вовнутрь этого сообщения. Что касается Cell_DCH, WTRU ожидают до считывания подробностей конфигурации перед предоставлением возможности связи HSDPA. Это невозможно для расширенного Cell_FACH, так как сообщение должно приниматься с использованием связи HSDPA. Традиционные спецификации версии 6 3GPP не обеспечивают поддержку для работы HS-DSCH в Cell_FACH.

Когда WTRU находится в состоянии расширенного Cell_FACH, WTRU будет выполнять процедуру обновления соты по некоторому количеству причин (например, повторный выбор соты, неисправность линии радиосвязи, невосстановимая ошибка управления радиосвязью (RLC) и т.п.). Что касается процедуры обновления соты, могут возникать многие затруднения. Например, WTRU может запрашиваться, чтобы переходить на расширенный Cell_FACH, но он требует способа для извлечения информации о конфигурации HSDPA. Процедуры повторного выбора соты управляются посредством WTRU. Как результат, UTRAN не способна выполнять своевременную и синхронизированную установку в исходное состояние MAC-hs. Фактически, после повторного выбора соты исходный Узел Б продолжал бы отправлять информацию в WTRU, даже если последний прекратил прослушивание. UTRAN осведомлялась бы об изменении только после приема сообщения CELL UPDATE. Дополнительная проблема может возникать, если WTRU требуется отправлять отчет о состоянии RLC в результате установления в исходное состояние MAC-hs. После повторного выбора соты UTRAN уведомляется сообщением CELL UPDATE. UTRAN отвечает сообщением CELL UPDATE CONFIRM с использованием выделенного канала управления (DCCH). Сообщение должно отправляться в выделенный WTRU, но WTRU еще не был назначен выделенный H-RNTI (информация, типично, содержалась бы внутри самого сообщения).

Когда WTRU находится в состоянии расширенного Cell_FACH, обычно полезно, чтобы функциональные возможности MAC-c/sh были сокращены. В частности, идентификатор (ID) WTRU уже переносится в заголовке MAC-hs, и, как результат, ему не нужно повторяться в заголовке MAC.

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

Настоящее изобретение имеет отношение к способу и устройству для обновления соты, во время состояния Cell_FACH. После выбора целевой соты системная информация считывается из целевой соты. Системная информация включает в себя общую системную информацию о HS-DSCH, если поддерживается в целевой соте. H-RNTI и C-RNTI, принятые в исходной соте, очищаются, и переменная HS_DSCH_RECEPTION управления ресурсами радиосвязи (RRC) используется для управления приемом HS_DSCH. Сущность MAC-hs конфигурируется на основании общей системной информации о HS-DSCH. Передача HSDPA затем принимается в целевой соте. Сообщение CELL UPDATE отправляется для уведомления об изменении соты. Передача HSDPA может приниматься с использованием широковещательной передачи общего H-RNTI в системной информации, зарезервированного H-RNTI согласно запросу в сообщении CELL UPDATE или временного идентификатора, который является подмножеством U-RNTI. Вслед за повторным выбором соты, неисправностью линии радиосвязи или невосстановимой ошибкой RLC сущность MAC-hs может устанавливаться в исходное состояние.

КРАТКИЙ ПЕРЕЧЕНЬ ЧЕРТЕЖЕЙ

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

фиг.1 показывает примерные WTRU и UTRAN;

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

фиг.3 - блок-схема примерной последовательности операций для обновления соты в соответствии с еще одним вариантом осуществления;

фиг.4 - блок-схема примерной последовательности операций для обновления соты в соответствии с еще одним другим вариантом осуществления;

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

фиг.6 - блок-схема альтернативной последовательности операций по отношению к последовательности операций на фиг.5; и

фиг.7 - структурная схема примерного устройства.

ПОДРОБНОЕ ОПИСАНИЕ

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

Когда указывается ссылкой в дальнейшем, терминология «сущность MAC-hs» включает в себя не только традиционную сущность MAC-hs, но также сущность высокоскоростного MAC, которая поддерживает прием по HS-DSCH в состояниях CELL_FACH, CELL_PCH и URA_PCH, которая также известна как «усовершенствованная сущность MAC-hs (MAC-ehs)».

Фиг.1 показывает примерные WTRU 110 и UTRAN, включающую в себя Узлы Б 120a, 120b. Фиг.1, для простоты, иллюстрирует только две соты 122a, 122b и два Узла Б 120a, 120b. Для передач HSDPA WTRU 110 принимает идентификатор WTRU (то есть H-RNTI) и информацию о конфигурации HSDPA из UTRAN. Способы для назначения информации о конфигурации H-RNTI и HSDPA на WTRU 110 в состоянии Cell_FACH пояснены в дальнейшем.

В состоянии Cell_DCH каждый WTRU с активной связью HSDPA наделяется уникальным (специфичным соте) H-RNTI. Однако это не всегда возможно в состоянии Cell_FACH. Было предложено использовать оба, общий H-RNTI и выделенный H-RNTI, во время состояния Cell_FACH. Передача CCCH, отображаемая в HS-DSCH, использует общий H-RNTI, а передачи DCCH и DTCH, отображаемые в HS-DSCH, используют выделенный H-RNTI. Общий H-RNTI может широковещательно передаваться в качестве части системной информации посредством добавления нового элемента информации в традиционный блок системной информации (SIB) или посредством определения нового SIB и ассоциативно связанного плана.

Информация касательно выделенного H-RNTI может переноситься в сообщениях RRC. Однако возникает проблема, если WTRU 110 еще не имеет выделенного H-RNTI, а сообщение RRC нисходящей линии связи (например, CELL UPDATE CONFIRM) отправляется с использованием DCCH, отображаемого в HS-DSCH, во время состояния Cell_FACH. В соответствии с одним из вариантов осуществления сообщение RRC, включающее в себя идентификатор WTRU (например, сообщение CELL UPDATE CONFIRM), может отправляться через CCCH поверх HS-DSCH с использованием общего H-RNTI, а выделенный H-RNTI может быть включен в сообщение RRC. В качестве альтернативы, сообщение RRC (например, сообщение CELL UPDATE CONFIRM) может отправляться с использованием DCCH поверх FACH, а заголовок MAC-c включает в себя идентификатор WTRU.

В качестве альтернативы, банк зарезервированных H-RNTI (RH-RNTI) может использоваться исключительно для цели сообщений DCCH, передаваемых через HS-DSCH, когда WTRU 110 не имеет выделенного H-RNTI. Банк RH-RNTI может широковещательно передаваться в качестве системной информации и может индексироваться. WTRU 110 произвольным образом выбирает один из индексов RH-RNTI и отправляет эту информацию в сообщении CELL UPDATE. Сообщение CELL UPDATE может расширяться, чтобы включать в себя новый элемент информации (IE), который включает в себя индекс RH-RNTI. UTRAN отвечает сообщением CELL UPDATE CONFIRM через DCCH, который отображается в HS-DSCH, с использованием индексированного RH-RNTI (то есть индексированный RH-RNTI сигнализируется в HS-SCCH). Конфликт адресов может возникать, если многочисленные WTRU выбирают один и тот же RH-RNTI. UTRAN удостоверяется, что многочисленные WTRU не выбирают один и тот же RH-RNTI. Если возникает конфликт адресов, UTRAN может просто удерживаться от отправки сообщения CELL UPDATE CONFIRM и ожидать повторной передачи сообщения CELL UPDATE.

В качестве альтернативы, при назначении U-RNTI, U-RNTI может назначаться в известном смысле, чтобы WTRU 110 мог использовать подмножество U-RNTI (например, последние значащие 16 битов) в качестве временного выделенного H-RNTI, и этот временный H-RNTI может использоваться для передач по DCCH (например, передачи сообщения CELL UPDATE CONFIRM) через HS-DSCH. UTRAN ответственна за предотвращение конфликта адресов в этом случае.

Чтобы WTRU 110 принимал передачу HSDPA, WTRU 110 требуется информация о конфигурации HSDPA из UTRAN. Типично, информация о конфигурации HSDPA поставляется в сообщении RRC (таком как сообщение RRC CONNECTION SETUP (УСТАНОВИТЬ СОЕДИНЕНИЕ RRC), сообщение CELL UPDATE CONFIRM или тому подобное). Для WTRU 110 в состоянии Cell_FACH HSDPA должен быть сконфигурирован как раз перед тем, как эти сообщения RRC могут быть приняты.

Общая системная информации о HS-DSCH может отправляться в качестве части широковещательной системной информации. Широковещательная информация может включать в себя возможность расширенного Cell_FACH (то есть индикацию, что сота поддерживает WTRU с расширенным Cell_FACH), информацию о высокоскоростном общем физическом совместно используемом канале нисходящей линии связи (HS-PDSCH) (например, код скремблирования и каналообразующий код HS-SCCH, информацию обратной связи индикатора качества канала (CQI) и т.д.), общую информацию о HARQ (например, количество процессов HARQ и разбиение памяти и т.д.) и, не обязательно, RH-RNTI, которые должны использоваться для отправки сообщений DCCH, когда нет в распоряжении выделенного H-RNTI. Широковещательная системная информация может включать в себя набор устанавливаемых по умолчанию общих конфигураций HSDPA, и WTRU может выбирать одну из них (например, на основании своего начального идентификатора WTRU).

После приема информации о конфигурации HSDPA WTRU 110 конфигурирует сущность MAC-hs. Отдельная сущность MAC-hs может конфигурироваться для каждого адреса RNTI. Например, если WTRU 110 в состоянии расширенного Cell_FACH сконфигурирован общим H-RNTI и выделенным H-RNTI, могут быть сконфигурированы две отдельные сущности MAC-hs (одна для общего H-RNTI и другая для выделенного H-RNTI).

В качестве альтернативы, единственная сущность MAC-hs может быть настроена для каждого WTRU, и поток обмена изолируется сохранением в разных очередях по приоритету на основании логического канала. Узлу B потребовалось бы изменять H-RNTI, используемый для передачи, в зависимости от очереди по приоритету, выбранной планировщиком.

WTRU 110 оценивает переменную HS_DSCH_RECEPTION при многочисленных обстоятельствах, как определено в техническом описании (TS) 3GPP 25.331. Переменная HS_DSCH_RECEPTION обозначает «процедуры приема высокоскоростного совместно используемого канала управления (HS-SCCH) и HS-DSCH являются действующими». Когда переменная HS_DSCH_RECEPTION оценена FALSE, она вынуждает WTRU 110 выполнять полную установку в исходное состояние HSDPA (в том числе установку в исходное состояние MAC-hs и очистку всех ресурсов HARQ). Переменная HS_DSCH_RECEPTION будет устанавливаться в TRUE, когда удовлетворены определенные условия. Для того чтобы задействовать HSDPA в состоянии Cell_FACH, переменная HS_DSCH_RECEPTION должна давать оценку TRUE, когда удовлетворены следующие три условия: (1) WTRU находится в состоянии расширенного Cell_FACH; (2) линия радиосвязи нисходящей линии связи сконфигурирована в качестве обслуживающей линии радиосвязи HS-DSCH; и (3) есть по меньшей мере один однонаправленный канал радиосвязи, отображаемый в HS-DSCH. Должно быть отмечено, что переменная «HS_DSCH_RECEPTION» может быть такой же переменной, как таковая в состоянии CELL_DCH, или новые переменные могут быть определены для WTRU, работающих в состоянии CELL_FACH. Также должно быть отмечено, что переменная «HS_DSCH_RECEPTION» может указываться ссылкой в качестве разных наименований, или другая переменная может использоваться для той же самой функции.

Процедуры обновления соты пояснены в дальнейшем. Фиг.2 - блок-схема примерной последовательности 200 операций для обновления соты в соответствии с одним из вариантов осуществления. В этом примере WTRU 110 перемещается из исходной соты 122a с поддержкой расширенного Cell_FACH в целевую соту 122b с поддержкой расширенного Cell_FACH. WTRU 110 в состоянии расширенного Cell_FACH выбирает целевую соту 122b (этап 202). WTRU 110 прекращает передачу и прием в исходной соте 122a и очищает C-RNTI и H-RNTI, используемые в исходной соте 122a (этап 204). WTRU 110 считывает системную информацию из целевой соты 122b и определяет возможность целевого Узла Б (этап 206).

Если целевой Узел Б 120b имеет возможность расширенного Cell_FACH, выполняются следующие этапы. Если целевой Узел Б 120b не имеет возможности расширенного Cell_FACH (то есть повторного выбора с соты с расширенным Cell_FACH на соту без расширенного Cell_FACH), выполняется последовательность 300 операций по фиг.3. WTRU 110 может выполнять установку в исходное состояние MAC-hs (этап 208). Это будет очищать от старых данных программные буферы и начинать последовательность операций разборки. Установка в исходное состояние MAC-hs может быть обязана выполняться для обеих, очереди общих H-RNTI и очереди выделенных H-RNTI.

WTRU 110 может всегда выполнять установку в исходное состояние MAC-hs для обоих, общего H-RNTI и выделенного H-RNTI. В качестве альтернативы, WTRU 110 может выполнять установку в исходное состояние MAC-hs, только когда повторный выбор соты имеет результатом изменение соты между Узлами Б или изменение соты внутри Узла Б для Узла Б, который не поддерживает сохранение MAC-hs. В этом случае изменение соты внутри Узла Б не имеет следствием установку в исходное состояние MAC-hs, если Узел Б может поддерживать сущность MAC-hs. Это требует некоторой индикации на WTRU 110 о идентичности и возможности Узла Б, которая может широковещательно передаваться в качестве части системной информации в виде нового элемента информации в существующий SIB или в виде нового SIB.

В качестве альтернативы, WTRU 110 может выполнять установку в исходное состояние MAC-hs только для случая, где используются очереди с переупорядочением. Если WTRU 110 в расширенном Cell_FACH не использует очереди с переупорядочением (для потока обмена по общему H-RNTI или выделенному H-RNTI), то установка в исходное состояние MAC-hs не требуется. По выбору, WTRU 110 может решить очистить от старых данных программные буферы HARQ вместо выполнения установки в исходное состояние MAC-hs.

В качестве альтернативы, WTRU 110 может выполнять установку в исходное состояние MAC-hs, только когда используются очереди с переупорядочением, и повторный выбор соты имеет результатом изменение соты между Узлами Б или изменение соты внутри Узла Б для Узла Б, который не поддерживает сохранение MAC-hs.

WTRU 110, в таком случае, устанавливает связь HSDPA, а также связь RACH и отправляет сообщение CELL UPDATE в UTRAN, чтобы уведомить об изменении соты (этап 210). По выбору WTRU 110 может выбирать индекс RH-RNTI и поставлять эту информацию в сообщении CELL UPDATE. WTRU 110 начинает прием нисходящей линии связи. WTRU 110 разыскивает свой H-RNTI в HS-SCCH. Выбор H-RNTI зависит от правил для назначения H-RNTI, как пояснено выше. WTRU 110 может использовать общий H-RNTI, широковещательно передаваемый в системной информации, может использовать RH-RNTI, согласно требованию в сообщении CELL UPDATE, или может использовать временный H-RNTI на основании подмножества U-RNTI.

UTRAN принимает сообщение CELL UPDATE, прекращает отправку данных на исходный Узел Б, уведомляет исходный Узел Б, что следует удалить старую сущность MAC-hs, и устанавливает новую сущность MAC-hs в целевом Узле Б (этап 212). UTRAN отправляет сообщение CELL UPDATE CONFIRM в WTRU 110 через целевой Узел Б с информацией о настройках для связи HSDPA (в частности, выделенном H-RNTI) (этап 214). H-RNTI, используемый для сообщения CELL UPDATE CONFIRM, зависит от правил для назначения H-RNTI. UTRAN может использовать общий H-RNTI, широковещательно передаваемый в системной информации, может использовать RH-RNTI согласно требованию в сообщении CELL UPDATE, или может использовать временный H-RNTI на основании подмножества U-RNTI. В качестве альтернативы, сообщение CELL UPDATE CONFIRM может отправляться через FACH.

WTRU 110 устанавливает HSDPA с информацией о конфигурации, включенной в сообщение CELL UPDATE CONFIRM (этап 216). WTRU 110 отвечает сообщением RRC (например, PHYSICAL CHANNEL RECONFIGURATION COMPLETE (ЗАВЕРШЕНИЕ РЕКОНФИГУРИРОВАНИЯ ФИЗИЧЕСКОГО КАНАЛА) или UTRAN MOBILITY INFORMATION CONFIRM (ПОДТВЕРЖДЕНИЕ ИНФОРМАЦИИ О МОБИЛЬНОСТИ UTRAN)), в зависимости от того, были или нет изменены параметры физического уровня) (этап 218).

В дополнение, качество функционирования может улучшаться, если WTRU 110 отправляет отчет о состоянии RLC, чтобы предоставить UTRAN возможность узнавать, какие PDU требуют передачи после установки в исходное состояние MAC-hs WTRU. Отчет о состоянии RLC может отправляться до отправки сообщения CELL UPDATE, но после выбора целевой соты 122b. Для этого последовательность 200 операций модифицируется. Например, после выбора целевой соты 122b WTRU 110 прекращает прием в исходной соте 122a. WTRU 110 затем выполняет установку в исходное состояние MAC-hs. WTRU 110 затем отправляет отчет о состоянии RLC в исходный Узел Б 120a, выдавая порядковый номер последнего принятого PDU. WTRU 110 затем останавливает передачу в исходной соте 122a и продолжает с этапа 210. В качестве альтернативы, WTRU 110 может включать в себя информацию о состоянии RLC в качестве IE в сообщении CELL UPDATE. Эта информация включает в себя последний порядковый номер, принятый в WTRU 110. В качестве альтернативы, WTRU 110 может ожидать до приема сообщения CELL UPDATE CONFIRM, чтобы отправить состояние RLC в UTRAN, дающее указание порядкового номера последнего принятого PDU. Информация о состоянии может быть включена в сообщение PHYSICAL CHANNEL RECONFIGURATION COMPLETE или сообщение UTRAN MOBILITY INFORMATION CONFIRM.

По выбору установка в исходное состояние MAC-hs может быть убрана и замещена индикацией установки в исходное состояние из UTRAN, выполняемой в сообщении CELL UPDATE CONFIRM. В сообщении CELL UPDATE WTRU 110 может информировать UTRAN о своем использовании очередей с переупорядочением (и обязательна ли установка в исходное состояние). Так как UTRAN управляет процедурой, она может гарантировать, что изменение соты внутри Узла Б (с сохранением MAC-hs) не дает в результате установку в исходное состояние MAC-hs, и WTRU 110 без очередей с переупорядочением не будет вызывать установку в исходное состояние MAC-hs. Вместо установки MAC-hs в исходное состояние WTRU 110 может очищать от старых данных свои программные буферы HARQ.

Фиг.3 - блок-схема примерной последовательности 300 операций для обновления соты в соответствии с еще одним вариантом осуществления. В этом варианте осуществления WTRU 110 перемещается из исходной соты 122a с поддержкой расширенного Cell_FACH в целевую соту 122b без поддержки расширенного Cell_FACH. WTRU 110 выбирает целевую соту 122b (этап 302). WTRU 110 останавливает передачу и прием в исходной соте 122a и очищает C-RNTI и H-RNTI, используемые в исходной соте 122a (этап 304). WTRU 110 считывает системную информацию из целевой соты 122b и определяет возможность целевого Узла Б (этап 306). Если целевой Узел Б не имеет возможности расширенного Cell_FACH, WTRU 110 выполняет установку в исходное состояние MAC-hs (этап 308).

WTRU 110 устанавливает связь S-CCPCH и RACH и отправляет сообщение CELL UPDATE в UTRAN, чтобы уведомить об изменении соты (этап 310). WTRU 110 начинает прием нисходящей линии связи по выбранному S-CCPCH.

UTRAN принимает сообщение CELL UPDATE, прекращает отправку данных на исходный Узел Б и уведомляет исходный Узел Б, что следует удалить сущность MAC-hs (этап 312). UTRAN отправляет CELL UPDATE CONFIRM в целевом Узле Б с информацией касательно изменения отображения однонаправленных радиоканалов поверх FACH с использованием S-CCPCH (этап 314). WTRU 110 реконфигурирует однонаправленные радиоканалы для использования FACH поверх выбранного S-CCPCH (этап 316). WTRU 110 отправляет ответное сообщение RRC (например, сообщение RADIO BEARER RECONFIGURATION COMPLETE (ЗАВЕРШЕНИЕ РЕКОНФИГУРИРОВАНИЯ ОДНОНАПРАВЛЕННОГО РАДИОКАНАЛА)) (этап 318).

WTRU 110 имеет три варианта выбора для состояния RLC в UTRAN, как изложено в варианте осуществления, где WTRU перемещается из исходной соты с поддержкой расширенного Cell_FACH в целевую соту с поддержкой расширенного Cell_FACH.

Фиг.4 - блок-схема примерной последовательности 400 операций для обновления соты в соответствии с еще одним другим вариантом осуществления. В этом варианте осуществления WTRU 110 перемещается из исходной соты 122a без поддержки расширенного Cell_FACH в целевую соту 122b с поддержкой расширенного Cell_FACH. WTRU 110 выбирает целевую соту 122b (этап 402). WTRU 110 останавливает передачу и прием в исходной соте 122a и очищает C-RNTI, используемый в исходной соте 122a (этап 404). WTRU 110 считывает системную информацию из целевой соты 122b и определяет возможность целевого Узла Б (этап 406). Если целевой Узел Б имеет возможность расширенного Cell_FACH, WTRU 110 устанавливает связь HSDPA, а также связь RACH (этап 408). Если целевой Узел Б не имеет возможности расширенного Cell_FACH, выполняется традиционная процедура повторного выбора соты.

WTRU 110 отправляет сообщение CELL UPDATE в UTRAN, чтобы уведомить об изменении соты (этап 410). По выбору WTRU 110 может выбирать индекс RH-RNTI и поставлять эту информацию в сообщении CELL UPDATE. WTRU 110 начинает прием нисходящей линии связи. WTRU 110 разыскивает свой H-RNTI в HS-SCCH. Выбор H-RNTI зависит от правил для назначения H-RNTI. WTRU 110 может использовать общий H-RNTI нисходящей линии связи в качестве обнаруживаемого в системной информации, может использовать RH-RNTI согласно требованию в сообщении CELL UPDATE, или может использовать временный H-RNTI на основании подмножества U-RNTI.

UTRAN принимает сообщение CELL UPDATE и прекращает отправку данных на исходный Узел Б (этап 412). UTRAN отправляет CELL UPDATE CONFIRM в WTRU через целевой Узел Б с информацией о настройках для связи HSDPA (в частности, выделенном H-RNTI), а также информацией касательно изменения отображения FACH в HS-DSCH (этап 414). H-RNTI, используемый для сообщения CELL UPDATE CONFIRM, зависит от правил для назначения H-RNTI. UTRAN может использовать общий H-RNTI нисходящей линии связи в качестве широковещательного в системной информации, может использовать RH-RNTI, согласно требованию в сообщении CELL UPDATE, которое может использоваться, или может использовать временный H-RNTI на основании подмножества U-RNTI.

WTRU 110 устанавливает HSDPA с информацией о конфигурации, включенной в сообщение CELL UPDATE CONFIRM (этап 416). WTRU 110 отправляет ответное сообщение RRC (например, сообщение TRANSPORT CHANNEL RECONFIGURATION COMPLETE) (этап 418). WTRU 110 может отправлять отчет о состоянии RLC в UTRAN, как изложено в варианте осуществления, в тех случаях, когда WTRU перемещается из исходной соты с поддержкой расширенного Cell_FACH в целевую соту с поддержкой расширенного Cell_FACH.

Фиг.5 - блок-схема примерной последовательности 500 операций для обновления соты в соответствии с еще одним другим вариантом осуществления. В этом варианте осуществления WTRU 110 переходит из состояния Cell_DCH в состояние расширенного Cell_FACH. Так как WTRU 110 уже находится в состоянии Cell_DCH, WTRU 110 уже имеет в распоряжении выделенный H-RNTI и правильную конфигурацию HSDPA. Предпочтительнее, чем установка в исходное состояние MAC-hs и пересоздание уже существующей линии связи HSPDA, WTRU 110 может продолжать использовать сконфигурированную настройку HSDPA.

При обнаружении неисправности линии радиосвязи или невосстановимой ошибки RLC WTRU 110 останавливает передачу и прием в соте (этап 502). WTRU 110 считывает системную информацию из целевой соты 122b (этап 504). Если целевой Узел Б имеет возможность расширенного Cell_FACH, выполняются следующие этапы. Если целевой Узел Б не имеет возможности расширенного Cell_FACH, выполняется традиционная процедура повторного выбора соты. WTRU 110 устанавливает связь RACH (этап 506). WTRU 110 отправляет сообщение CELL UPDATE в UTRAN и ожидает сообщения CELL UPDATE CONFIRM через HS-DSCH с использованием существующего выделенного H-RNTI (этап 508). UTRAN принимает сообщение CELL UPDATE и отвечает сообщением CELL UPDATE CONFIRM с новой конфигурацией однонаправленного радиоканала (этап 510). H-RNTI, используемый для сообщения CELL UPDATE CONFIRM, является тем же самым выделенным H-RNTI, который использовался в состоянии Cell_DCH. WTRU 110 реконфигурирует однонаправленные радиоканалы и отправляет ответное сообщение RRC (например, сообщение RADIO BEARER RECONFIGURATION COMPLETE) (этап 512). WTRU 110 может отправлять отчет о состоянии RLC в UTRAN, как изложено в варианте осуществления, в тех случаях, когда WTRU перемещается из исходной соты с поддержкой расширенного Cell_FACH в целевую соту с поддержкой расширенного Cell_FACH.

В качестве альтернативы, сущность MAC-hs может устанавливаться в исходное состояние, и может использоваться новая конфигурация HSDPA. Фиг.6 - блок-схема альтернативной последовательности 600 операций по отношению к последовательности 500 операций на фиг.5, где WTRU использует общий H-RNTI вместо выделенного H-RNTI. WTRU 110 переходит из состояния Cell_DCH в исходной соте 122a в состояние расширенного Cell_FACH в целевой соте 122b. Исходная и целевая сота может быть одной и той же сотой. При обнаружении неисправности линии радиосвязи или невосстановимой ошибки RLC WTRU 110 останавливает передачу и прием в соте и выполняет установку в исходное состояние MAC-hs (этап 602). WTRU 110 считывает системную информацию из целевой соты 122b (этап 604). Если целевой Узел Б имеет возможность расширенного Cell_FACH, выполняются следующие этапы. Если целевой Узел Б не имеет возможности расширенного Cell_FACH, выполняется традиционная процедура повторного выбора соты. WTRU очищает C-RNTI и H-RNTI и выполняет установку в исходное состояние MAC-hs (этап 605). WTRU 110 устанавливает связь HSDPA, а также связь RACH (этап 606). WTRU 110 отправляет сообщение CELL UPDATE в UTRAN и ожидает сообщения CELL UPDATE CONFIRM через HS-DSCH с использованием общего H-RNTI (этап 608).

UTRAN принимает сообщение CELL UPDATE и выполняет установку в исходное состояние MAC-hs в исходной соте (этап 610). UTRAN отвечает сообщением CELL UPDATE CONFIRM с новой конфигурацией однонаправленного радиоканала (этап 612). H-RNTI, используемый для сообщения CELL UPDATE CONFIRM, является выбранным общим H-RNTI. WTRU 110 реконфигурирует однонаправленные радиоканалы и отвечает сообщением RRC (например, сообщением RADIO BEARER RECONFIGURATION COMPLETE) (этап 614). WTRU 110 может отправлять отчет о состоянии RLC в UTRAN, как изложено в варианте осуществления, в тех случаях, когда WTRU перемещается из исходной соты с поддержкой расширенного Cell_FACH в целевую соту с поддержкой расширенного Cell_FACH.

Фиг.7 - структурная схема примерного устройства 700 (WTRU 110 или Узла Б 120a, 120b). Устройство 700 включает в себя приемопередатчик 702, сущность 704 MAC-hs и контроллер 706. Приемопередатчик 702 передает и принимает сигналы через физическую среду. Сущность 704 MAC-hs предназначена для связи HSDPA. Контроллер 706 (например, сущность RRC) управляет приемопередатчиком 702 и сущностью 704 MAC-hs для выполнения процедур 200-600 для обновления соты и для передачи и приема, во время состояния Cell_FACH. Контроллер 706 сконфигурирован, чтобы во время состояния Cell_FACH выбирать целевую соту 122b, считывать системную информацию из целевой соты 122b, очищать RNTI, принятый в исходной соте 122a, соответственно устанавливать переменную управления HS_DSCH_RECEPTION и конфигурировать связь HSDPA на основании общей системной информации о HS-DSCH, включенной в системную информацию, устанавливать в исходное состояние сущность MAC-hs и т.д.

ВАРИАНТЫ ОСУЩЕСТВЛЕНИЯ

1. Способ выполнения повторного выбора соты во время состояния Cell_FACH, когда целевая сота поддерживает расширенный Cell_FACH.

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

3. Способ по варианту 2 осуществления, содержащий этап, на котором считывают системную информацию из целевой соты, системная информация включает в себя общую системную информацию о HS-DSCH.

4. Способ по любому одному из вариантов 2-3 осуществления, содержащий этап, на котором очищают RNTI, принятый в исходной соте.

5. Способ по любому одному из вариантов 2-4 осуществления, содержащий этап, на котором разрешают прием HS-DSCH посредством того, что устанавливают переменную приема HS-DSCH в TRUE.

6. Способ по любому одному из вариантов 2-5 осуществления, содержащий этап, на котором устанавливают связь RACH.

7. Способ по любому одному из вариантов 2-6 осуществления, содержащий этап, на котором отправляют сообщение CELL UPDATE.

8. Способ по любому одному из вариантов 3-7 осуществления, содержащий этап, на котором конфигурируют сущность MAC-hs на основании общей системной информации о HS-DSCH.

9. Способ по варианту 8 осуществления, содержащий этап, на котором принимают передачу HSDPA в целевой соте.

10. Способ по любому одному из вариантов 7-9 осуществления, в котором индекс к одному из множества RH-RNTI включен в сообщение CELL UPDATE.

11. Способ по варианту 10 осуществления, в котором передача HSDPA принимается с использованием RH-RNTI согласно запросу в сообщении CELL UPDATE.

12. Способ по варианту 9 осуществления, в котором передача HSDPA принимается с использованием временного идентификатора, который является подмножеством U-RNTI.

13. Способ по любому одному из вариантов 3-12 осуществления, дополнительно содержащий этап, на котором устанавливают в исходное состояние сущность MAC-hs.

14. Способ по варианту 13 осуществления, в котором сущность MAC-hs устанавливается в исходное состояние для обоих, общего H-RNTI и выделенного H-RNTI, если общий H-RNTI и выделенный H-RNTI сконфигурированы разными сущностями MAC-hs.

15. Способ по варианту 13 осуществления, в котором сущность MAC-hs устанавливается в исходное состояние, только когда повторный выбор соты имеет результатом изменение соты между Узлами Б.

16. Способ по варианту 13 осуществления, в котором сущность MAC-hs устанавливается в исходное состояние, только когда повторный выбор соты имеет результатом изменение соты внутри Узла Б для Узла Б, который не поддерживает сохранение MAC-hs.

17. Способ по варианту 13 осуществления, в котором сущность MAC-hs устанавливается в исходное состояние, только если используются очереди с переупорядочением.

18. Способ по варианту 13 осуществления, в котором сущность MAC-hs устанавливается в исходное состояние, только если используются очереди с переупорядочением, и повторный выбор соты имеет результатом изменение соты между Узлами Б или изменение соты внутри Узла Б для Узла Б, который не поддерживает сохранение MAC-hs.

19. Способ по любому одному из вариантов 3-12 осуществления, дополнительно содержащий этап, на котором устанавливают в исходное состояние сущность MAC-hs в соответствии с индикацией из сети.

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

21. Способ по любому одному из вариантов 2-20 осуществления, дополнительно содержащий этап, на котором отправляют отчет о состоянии RLC при повторном выборе соты.

22. Способ по варианту 21 осуществления, в котором отчет о состоянии RLC отправляют до отправки сообщения CELL UPDATE и после выбора целевой соты.

23. Способ по варианту 21 осуществления, в котором отчет о состоянии RLC включен в сообщение CELL UPDATE.

24. Способ по варианту 21 осуществления, в котором отчет о состоянии RLC отправляют после приема сообщения CELL UPDATE CONFIRM.

25. Способ по любому одному из вариантов 3-24 осуществления, в котором системная информация включает в себя