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

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

Иллюстрации

Показать все

Реферат

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

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

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

Некоторые из главных целей развития стандарта высокоскоростного пакетного доступа (HSPA) включают в себя повышение скоростей передачи данных, увеличение пропускной способности и покрытия системы, совершенствование поддержки услуг пакетной передачи, уменьшение времени задержки, снижение затрат оператора и обратную совместимость. Удовлетворение этих целей требует развития протокола радиоинтерфейса и сетевой архитектуры. Более конкретно, удовлетворение этих целей имеет требуемый набор улучшений и архитектурных изменений в функциональность уровня 2 (L2) (т.е. в управление радиолинией (RLC) и управление доступом к среде (MAC)).

Некоторые из улучшений L2 включают в себя гибкий размер блоков протокольных данных RLC (PDU), сегментацию/конкатенацию и мультиплексирование высокоскоростного MAC (MAC-hs). В стандарте универсального наземного радиодоступа (UTRA) версии 6 (R6) RLC-объекты в режиме подтверждения приема (AM) могут использовать только фиксированный размер RLC PDU. Помимо этого, MAC-hs-подуровень в узле B может поддерживать только конкатенацию MAC-d PDU. Улучшения L2 в UTRA версии 7 (R7) приводят к значительным изменениям RLC/MAC для признаков R6.

Изменения архитектуры усовершенствованных MAC-hs (MAC-ehs) на стороне UTRAN включают в себя добавление объекта мультиплексирования (MUX) по идентификатору логического канала (LCH-ID). Объект LCH-ID MUX мультиплексирует логические каналы в очередь по приоритету. Архитектура MAC-ehs дополнительно включает в себя функциональность сегментации очереди по приоритету и мультиплексирование блоков полезных данных MAC-ehs из различных очередей по приоритету в MAC-ehs PDU.

Изменения архитектуры MAC-ehs на стороне беспроводного модуля приема/передачи (WTRU) включают в себя разбор блоков полезных данных MAC-ehs из MAC-ehs PDU. Дополнительно, после переупорядочения, блоки полезных данных MAC-ehs перенаправляются в объект демультиплексирования LCH-ID. Этот объект демультиплексирования LCH-ID маршрутизирует блоки полезных данных MAC-ehs в корректный объект повторной сборки на основе идентификатора логического канала. Архитектура MAC-ehs в WTRU также включает в себя объект повторной сборки, который повторно собирает сегментированные блоки служебных данных (SDU) MAC-ehs и перенаправляет полные MAC-ehs SDU на верхние уровни.

В настоящее время, когда однонаправленные радиоканалы устанавливаются или переконфигурируются через служебные сигналы управления радиоресурсами (RRC), информационный элемент (IE) "Информация отображения для однонаправленного радиоканала (RB)" присутствует. "Информация отображения для RB" содержит информацию об экземпляре RLC и транспортных каналах, соответствующих однонаправленному радиоканалу (RB).

В IE "Информация отображения для RB" могут быть добавлены новые информационные элементы (IE), которые указывают, поддерживает ли логический канал экземпляра RLC гибкие RLC PDU или поддерживают ли MAC-подуровни MAC-hs или MAC-ehs. Для цели настоящего изобретения, эти IE будут называться "RLC-конфигурация нисходящей линии связи (DL)" и "MAC-hs-конфигурация DL". MAC-hs-конфигурация должна быть одинаковой для всех RB, отображенных на высокоскоростной совместно используемый канал нисходящей линии связи (HS-DSCH), в противном случае возникает недопустимая конфигурация.

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

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

В традиционной системе (т.е. системе R6), когда передача обслуживания осуществляется, сообщение управления радиоресурсами (RRC) может переносить индикатор сброса MAC-уровня. В частности, когда передача обслуживания между узлами B или внутри узла B осуществляется, данные в MAC-hs в исходном узле B удаляются, и MAC-hs в WTRU должен быть сброшен. При приеме индикатора сброса WTRU должен выполнять следующую последовательность функций:

1) очищать программный буфер гибридных автоматических запросов на повторную передачу (HARQ) для всех сконфигурированных процессов HARQ;

2) останавливать все активные таймеры отключения переупорядочения (T1) и присваивать всем таймерам T1 начальное значение;

3) начинать порядковый номер передачи (TSN) со значения 0 для следующей передачи по каждому сконфигурированному процессу HARQ;

4) инициализировать переменные RcvWindow_UpperEdge и next_expected_TSN их начальными значениями;

5) разбирать все MAC-hs PDU в буфере переупорядочения и доставлять все MAC-d PDU в объект MAC-d; и

6) очищать буфер переупорядочения.

С появлением новых улучшений L2, новые процедуры должны быть заданы для того, чтобы оптимизировать и минимизировать потерю данных в ходе передачи обслуживания между сотами R7 или между сотой R7 и сотой R6. В частности, процедуры, которые направлены на сброс объекта MAC-hs, должны быть модифицированы, чтобы учитывать новые улучшения L2.

Помимо этого, невозможно предположить, что все узлы B R6 будут модернизированы одновременно в узлы B R7. Следовательно, передачи обслуживания между сотами R6 и R7 могут осуществляться часто. Вследствие функциональных изменений RLC и MAC, должны быть заданы способы для того, чтобы выполнять передачи обслуживания с минимальной потерей качества и данных между этими сотами. В частности, на стороне WTRU, MAC-hs и RLC должны выполнять функциональные изменения в ходе передач обслуживания.

Сущность изобретения

Раскрыты способ и устройство для управления оптимизацией процедур передачи обслуживания между сотой UTRA R6 (т.е. нижним уровнем) и сотой UTRA R7 (т.е. верхним уровнем). Когда WTRU перемещается между сотой R6 и сотой R7 или между сотами R7, передача обслуживания инициируется от исходного узла B к целевому узлу B. В соте R7 поддерживается усовершенствованная функциональность MAC, включающая в себя гибкий размер RLC PDU и MAC-hs-сегментацию и мультиплексирование различных очередей по приоритету в WTRU. Изменения, которые выполняются в WRTU, обусловлены тем фактом, что WRTU перемещается между сотами R6 и R7. Когда WRTU перемещается между этими сотами, сеть должна переконфигурировать WRTU с новыми конфигурациями. После передачи обслуживания, MAC-уровень и/или RLC-уровень переконфигурируются или сбрасываются на основе функциональности, поддерживаемой посредством целевого узла B.

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

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

Фиг.1A - это примерная блок-схема WTRU, который перемещается между сотами R6 и R7 и выполнен с возможностью работать с новыми RLC- и MAC-hs-подуровнями, когда сообщение передачи обслуживания принимается в ходе процедуры смены обслуживающей соты;

Фиг.1B - это подробная схема MAC-модуля в WTRU по фиг.1A; и

Фиг.2 - это блок-схема последовательности операций процедуры передачи обслуживания WTRU, реализованной в WTRU по фиг.1A.

Подробное описание изобретения

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

Когда упоминается далее, сота R7 включает в себя узлы B и RNC, которые имеют усовершенствованные признаки L2. По всему этому изобретению, сота R7 может ссылаться на старшие версии, которые поддерживают усовершенствованный L2. Когда упоминается далее, сота R6 включает в себя узел B и RNC, которые не поддерживают усовершенствованные признаки L2. Это может включать в себя узлы B R7 без признаков L2 и любую из предыдущих версий по стандарту партнерского проекта третьего поколения (3GPP). R7 MAC-hs в этом изобретении упоминается как усовершенствованный MAC-hs (т.е. MAC-ehs).

Термин «сброс RLC» также упоминается как повторное установление RLC. Эти термины используются взаимозаменяемо.

Следующие термины используются по всему описанию и задаются кратко. Блок полезных данных MAC-ehs - это MAC-ehs SDU или сегмент MAC-ehs SDU, содержащийся в MAC-ehs PDU. PDU переупорядочения MAC-ehs является набором блоков полезных данных MAC-ehs в MAC-ehs PDU, который принадлежит одной очереди по приоритету. Усовершенствованная сота - это сота, которая поддерживает улучшения L2. Неусовершенствованная сота - это сота, которая не поддерживает улучшения L2.

Раскрыты изменения в процедуре сброса MAC-hs или MAC-ehs, процедуре переконфигурирования MAC-hs или MAC-ehs и процедуре оценки повторного установления RLC.

В данном документе раскрыты способ и устройство, которые направлены на оптимизацию сценариев передачи обслуживания, процедур сброса MAC-hs-объектов и RLC-объектов для поддержки передачи обслуживания между сотами R7 и между сотами R6 и R7. Следует понимать, что ссылки на соты R6 или узлы B R6 направлены на соты и узлы B, которые не поддерживают улучшенные признаки L2, такие как MAC-сегментация и гибкий размер RLC PDU. Раскрытый способ и устройство применимы как к восходящей линии связи (UL), так и к нисходящей линии связи (DL), а также к другим беспроводным технологиям, таким как стандарт долгосрочного развития (LTE) и другим системам с плоской архитектурой, таким как широкополосный множественный доступ с кодовым разделением (WCDMA) R8.

Фиг.1A - это примерная блок-схема WTRU 100, который перемещается между сотами R6 и R7 и выполнен с возможностью работать с новыми RLC- и MAC-hs-подуровнями, когда сообщение передачи обслуживания принимается в ходе процедуры смены обслуживающей соты. Как показано на фиг.1A, WTRU 100 включает в себя RRC-модуль 105, RLC-модуль 110, MAC-модуль 115 и модуль 120 физического уровня 1 (PHY). Смена обслуживающей соты может проводиться через RRC-сообщение переконфигурирования однонаправленного радиоканала, RRC-сообщение переконфигурирования транспортного канала или RRC-сообщение переконфигурирования физического канала.

WTRU 100 работает в системе беспроводной связи, включающей в себя целевой узел B, исходный узел B, управляющий RNC (CRNC) и исходный RNC (SRNC) (не показан). SRNC может включать в себя RLC-модуль и RRC-модуль (не показаны).

Передача обслуживания внутри соты R7

В архитектуре R7, MAC-hs содержит новые функциональности, которые включают в себя MAC-hs-сегментацию и мультиплексирование различных очередей по приоритету в узле B. Функциональность RLC остается в контроллере радиосети (RNC) и поддерживает гибкие размеры PDU. Заголовок R7 MAC-hs значительно отличается от заголовка R6 MAC-hs. В LTE и других системах с плоской архитектурой WCDMA, функциональность RLC находится в узле B. В UL, функциональность RLC находится в WTRU.

Когда осуществляется передача обслуживания, объект MAC-hs в исходном узле B удаляется, и новый объект MAC-hs устанавливается в целевом узле B. Когда осуществляется новая конфигурация, максимальный размер RLC PDU может регулироваться для целевого узла B. Это выполняется посредством одного или комбинации следующих способов: 1) назначать значение по умолчанию для начального размера RLC PDU; 2) сохранять существующий размер RLC PDU; или 3) задавать новый размер RLC PDU на основе характеристик канала целевого узла B. Это применимо в случае, когда узел B сообщает максимальный размер RLC PDU в RLC-объект в RNC. Сообщения с индикатором качества канала (CQI), которые отправляются в целевой узел B в ходе передачи обслуживания, могут предлагать хорошую оценку характеристик канала. В свою очередь, целевой узел B может предоставлять обратную связь в RLC-объект в RNC, чтобы задавать обновленный размер RLC PDU до инициирования передачи по новой соте. Любые традиционные способы могут использоваться для того, чтобы предоставлять информацию обратной связи в целевой узел B в ходе смены обслуживающей соты HS-DSCH.

Когда новый MAC-hs устанавливается в целевом узле B, MAC-hs на стороне WTRU предпочтительно синхронизируется с целевым узлом B. Следовательно, WTRU предпочтительно также сбрасывает объект MAC-hs в WTRU.

Вследствие изменений функциональности MAC-hs-подуровня, процедура сброса R6 модифицируется так, чтобы учитывать факт, что после HARQ-приема функция разборки MAC-hs PDU используется перед переупорядочением. После переупорядочения функция повторной сборки добавляется в существующую функцию разборки.

Традиционная процедура сброса R6 MAC-hs изменяется посредством разборки всех MAC-hs PDU в буфере переупорядочения, повторной сборки сегментированных пакетов, которые могут быть успешно повторно собраны в блоках служебных данных MAC-hs (SDU), доставки всех готовых MAC-hs SDU на верхние уровни и отбрасывания частично принятых MAC-hs SDU.

Более конкретно, вследствие изменений в архитектуре, предлагается обновить процедуру сброса MAC-ehs. В данное время активации или во время индикации, WTRU должен обрабатывать PDU переупорядочения MAC-ehs, ожидающие в буфере переупорядочения. Все PDU переупорядочения MAC-ehs должны быть разобраны или демультиплексированы в блоки полезных данных MAC-ehs. Блоки полезных данных MAC-ehs затем передаются в модуль повторной сборки. После того, как объект повторной сборки обрабатывает все блоки полезных данных MAC-ehs и повторно собирает сегментированные блоки полезных данных MAC-ehs в MAC-ehs SDU, которые могут быть повторно собраны, объект повторной сборки должен обеспечивать то, что любой оставшийся сохраненный сегмент(ы) MAC-hs SDU удаляется из объекта повторной сборки. В завершение, готовые PDU доставляются на верхние уровни в соответствующих логических каналах или потоках MAC-d/c.

Например, процедура сброса MAC-ehs может принимать следующую форму для архитектуры MAC-ehs, если сброс MAC-модуля 115 запрашивается посредством верхних уровней, то WTRU 100 во время активации, указанное посредством верхних уровней, должен:

a) очищать программные буферы HARQ для всех сконфигурированных процессов HARQ;

b) останавливать все активные таймеры отключения переупорядочения (T1) и присваивать всем таймерам T1 начальное значение;

c) начинать TSN со значения 0 для следующей передачи по каждому сконфигурированному процессу HARQ (и каждой очереди по приоритету);

d) инициализировать переменные RcvWindow_UpperEdge и next_expected_TSN их начальными значениями;

e) доставлять все PDU переупорядочения в очереди переупорядочения в модули демультиплексирования LCH-ID и/или демультиплексировать блоки полезных данных MAC-ehs и маршрутизировать их в корректный модуль повторной сборки на основе идентификатора логического канала;

f) выполнять повторную сборку сегментированных MAC-ehs SDU и доставлять готовые MAC-ehs SDU (MAC PDU) на верхние уровни;

g) отбрасывать все сохраненные PDU переупорядочения (или сегменты MAC-hs SDU) из модулей повторной сборки;

h) очищать очереди переупорядочения; и

i) необязательно указывать все RLC-объекты режима подтверждения приема (AM), отображенные на HS-DSCH, чтобы формировать отчет о состоянии, если сброс MAC-hs инициирован вследствие приема IE "Индикатор сброса MAC-hs" посредством верхних уровней.

Другая архитектура MAC-ehs может существовать, если после функциональности переупорядочения следует функция разборки SDU, объект повторной сборки и, в завершение, объект демультиплексирования LCH-ID. Функция разборки может быть частью объекта повторной сборки, при этом только объект повторной сборки должен существовать в архитектуре MAC-ehs. Например, процедура сброса MAC-ehs может принимать следующую форму для этой архитектуры MAC-ehs.

Фиг.1B - это подробная схема MAC-модуля 115 в WTRU 100 по фиг.1A. Как показано на фиг.1B, MAC-модуль 115 включает в себя множество модулей 130A и 130B демультиплексирования LCH-ID, модули 135A и 135B повторной сборки, очереди 140A и 140B переупорядочения, модуль 145 распределения очереди переупорядочения, модуль 150 разборки и HARQ-модуль 155. Очереди 140A и 140B переупорядочения используются для того, чтобы выполнять переупорядочение принимаемых MAC PDU-ehs, так что повторная сборка может быть выполнена, и данные могут доставляться по порядку на верхние уровни. HARQ-модуль 155 включает в себя, по меньшей мере, один программный буфер HARQ (не показан).

Ссылаясь на фиг.1B, если сброс объекта MAC-ehs запрашивается посредством верхних уровней, WTRU 100 во время активации, указанное посредством верхних уровней, должен:

a) очищать программный буфер HARQ в HARQ-модуле 155 для всех сконфигурированных процессов HARQ;

b) останавливать все активные таймеры отключения переупорядочения (T1) и присваивать всем таймерам T1 начальное значение;

c) начинать TSN со значения 0 для следующей передачи по каждому сконфигурированному процессу HARQ (и каждой очереди по приоритету);

d) инициализировать переменные RcvWindow_UpperEdge и next_expected_TSN их начальными значениями;

e) все PDU переупорядочения в очередях 140A и 140B переупорядочения доставляются в модуль 150 разборки; и/или

f) модуль 150 разборки разбирает все PDU переупорядочения в MAC-hs SDU или сегменты MAC-hs SDU и доставляет их в модули 135A и 135B повторной сборки; или

g) если имеется только модуль 135 повторной сборки, данные из очередей переупорядочения доставляются в модуль 135 повторной сборки. Модули 135A и 135B повторной сборки выполняют повторную сборку сегментированных MAC-ehs SDU и доставляют готовые MAC-ehs SDU в модули 130A и 130B демультиплексирования LCH-ID, каждый из которых доставляет готовые SDU в корректный логический канал или поток MAC-d/c;

g) отбрасывать все сохраненные PDU переупорядочения (или сегменты MAC-hs SDU) из модулей 135A и 135B повторной сборки; и

h) очищать очереди 140A and 140B переупорядочения.

Необязательно, в случае передачи обслуживания внутри узла B (т.е. передачи обслуживания между секторами одного узла B), процедуру сброса MAC-hs, описанную выше, вероятно, не придется выполнять. В этом случае передача обслуживания выполняется так, как описано в традиционной системе R6.

Передача обслуживания между сотами R6 и R7

L2-усовершенствованные соты (т.е. соты R7) поддерживают гибкий размер RLC PDU, тогда как неусовершенствованные соты (т.е. соты R6) имеют фиксированный размер RLC PDU. Это подразумевает, что когда передача обслуживания в и из сот R7 осуществляется, затронутые RLC-объекты в RNC и WTRU должны быть переконфигурированы в старые RLC-объекты. Помимо этого, MAC-hs-подуровни должны быть переконфигурированы, чтобы декодировать корректные форматы заголовка и поддерживать новые или старые функциональности.

Если требуется повторное установление RLC-объекта, может возникать значительная потеря данных. Таким образом, желательно минимизировать эту потерю данных.

Последовательность событий для процедуры передачи обслуживания

Фиг.2 - это блок-схема последовательности операций процедуры 200 передачи обслуживания WTRU, реализованной в WTRU 100 по фиг.1. На этапе 205, RRC-модуль 105 в WTRU 100 принимает команду передачи обслуживания RRC, чтобы инициировать процедуру передачи обслуживания. На этапе 210, модуль 120 физического уровня (PHY) 1 (L1) инструктируется посредством RRC-модуля 105 устанавливать новые радиолинии, указанные в команде передачи обслуживания RRC. Эта последовательность событий аналогична традиционной процедуре до этапа сброса MAC-hs.

На этапе 215, RRC-модуль 105 отправляет запрос на сброс MAC-hs и/или на переконфигурирование MAC-hs в MAC-модуль 115 в WTRU 100, по мере необходимости. Если переконфигурирование MAC-hs требуется, то переконфигурирование MAC-hs выполняется так, как пояснено подробно ниже. Параметр индикатора сброса MAC-hs RRC-модуля 105 к примитиву MAC может необязательно быть дополнен так, чтобы указывать переконфигурирование MAC-hs.

Как только MAC-модуль 115 выполняет сброс MAC-hs и/или переконфигурирование MAC-hs (этап 220), и очереди 140A и 140B переупорядочения в MAC-модуле 115 очищаются (этап 225), сообщение с запросом состояния RLC может быть отправлено в RLC-модуль 110 из MAC-модуля 115 (этап 230). На этапе 235, RLC-модуль 110 затем формирует отчет о состоянии для всех экземпляров RLC в режиме подтверждения приема (AM), отображенных на HS-DSCH, после того как каждый из RLC PDU обработан посредством RLC-модуля 110. Необязательно, сообщение с запросом состояния RLC не отправляется в RLC-модуль 110.

Если требуется сброс RLC, RRC-модуль 105 отправляет сообщение с запросом на повторное установление (т.е. сообщение сброса RLC) в RLC-модуль 110 (этап 240). Частичный или полный сброс RLC затем выполняется в результате этого запроса, как описано подробно ниже. Следующие варианты могут быть доступными для индикатора сброса RLC:

1) индикатор RLC не отправляется в RLC-модуль 110;

2) индикатор полного сброса отправляется в RLC-модуль 110; или

3) индикатор частичного сброса отправляется в RLC-модуль 110.

Индикатор сброса/переконфигурирования RLC может быть сообщен посредством управляющего примитива RLC (CRLC)-Config-Req или может быть явно сообщен посредством MAC-hs с последним перенаправленным MAC SDU. Альтернативно, индикатор сброса/переконфигурирования RLC может быть сообщен посредством MAC-hs с помощью STATUS-Report-Req. Обработка RLC всех очищенных SDU предпочтительно выполняется перед сбросом RLC или отчетом о состоянии.

Если несинхронизированная передача обслуживания выполняется, этапы 220-230 выполняются, как только RRC-сообщение принимается. Если синхронизированная передача обслуживания выполняется, этапы 220-230 выполняются в данное время активации.

Способ передачи служебных сигналов в WTRU

После того как RRC в RNC принял решение выполнять смену обслуживающего узла B, RNC должен уведомлять WTRU о том, что требуется сброс/переконфигурирование для MAC-hs-подуровня или RLC-объекта приема, если применимо. Один или комбинация следующих вариантов предпочтительно выполняется:

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

1a) сброс или переконфигурирование MAC-hs. Дополнительный бит (т.е. индикатор переконфигурирования MAC-hs) добавляется в RRC-сообщение, указывающее операцию R6 или R7 MAC-hs после передачи обслуживания;

1b) индикатор сброса RLC, чтобы указывать частичный или полный сброс;

1c) два бита, чтобы указывать одно из следующего:

i) сброс MAC-hs;

ii) переконфигурирование MAC-hs;

iii) сброс RLC или

iv) действие не требуется;

1d) дополнительное поле, указывающее то, что изменение соты с R6 на R7 или наоборот произошло; или

1e) дополнительная информация не добавляется в сообщение передачи обслуживания RRC кроме традиционного индикатора сброса MAC-hs.

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

2a) если переконфигурирование MAC-hs или сброс RLC сообщается явно (т.е. через служебные сигналы 1a, 1b или 1c выше), WTRU выполняет указанные задачи в порядке, описанном выше;

2b) если только сброс MAC-hs задан равным TRUE, и дополнительные информационные биты не добавляются в сообщение передачи обслуживания RRC (т.е. служебные сигналы 1e), то WTRU основывает свое решение на системной информации от исходной и целевой соты из RRC-сообщений. В частности, WTRU неявно считывает/получает информацию о признаках поддержки исходной и целевой соты;

i) если WTRU обнаруживает, что происходит изменение с R6 на R7 или с R7 на R6, WTRU делает вывод, что необходимо переконфигурирование MAC-hs. Помимо этого, WTRU может также делать вывод, требуется ли сброс или повторное установление RLC. WRTU может делать вывод, что произошло изменение с R6 на R7 или наоборот, через информацию, предоставленную в IE "Информация отображения для RB" в сообщении передачи обслуживания RRC, т.е. то, сконфигурирован ли MAC-ehs или MAC-hs и поддерживает ли новый RLC-объект гибкие или фиксированные RLC PDU. WRTU сравнивает новую конфигурацию с существующей и делает вывод, что изменение произошло;

ii) сброс RLC может не требоваться, когда происходит изменение с R6 на R7. Эта информация может быть сконфигурирована посредством верхних уровней. Верхние уровни могут указывать, что не требуется сброс RLC или требуется полный/частичный сброс RLC между конкретными версиями;

2c) если только индикатор переконфигурирования MAC-hs добавляется в RRC-сообщение (т.е. служебные сигналы 1a выше), WTRU может делать вывод, что сброс RLC также требуется;

2d) альтернативно, если только индикатор сброса RLC добавляется в RRC-сообщение (т.е. служебные сигналы 1b выше), WTRU делает вывод, что требуется переконфигурирование MAC-hs;

2e) если индикатор сброса MAC-hs задан равным TRUE, и дополнительное поле в RRC-сообщении указывает, что исходные и целевые соты поддерживают различные версии (т.е. служебные сигналы 1d выше), то WTRU определяет, требуется ли переконфигурирование MAC-hs и/или требуется частичный или полный сброс RLC.

Способы выполнения переконфигурирования MAC-hs

Переконфигурирование MAC-hs выполняет изменение функциональности MAC-hs от старого MAC-hs на новый MAC-hs. В частности, если WTRU перемещается между сотами R6 и R7, формат заголовка и функциональность MAC-hs изменяются. Следовательно, требуется способ для того, чтобы выполнять это изменение.

Первоначально, выполняется процедура сброса MAC-hs. Как только буферы очищены, переменные сброшены и успешные MAC-hs SDU доставлены на верхние уровни, MAC-уровень переконфигурирует свою функциональность.

Если происходит изменение с R6 на R7, может осуществляться следующая последовательность событий:

1) выполняется сброс MAC-hs;

2) после сброса процессов HARQ, MAC-уровень конфигурируется так, чтобы поддерживать формат заголовка MAC-ehs;

3) функциональность демультиплексирования очередей по приоритету добавляется до очередей переупорядочения. Необязательно, функциональность демультиплексирования всегда может присутствовать, когда MAC-hs установлен (при условии, что WTRU поддерживает R7), поскольку в сотах R6 только одна очередь переупорядочения присутствует в каждом MAC-hs PDU;

4) функциональность повторной сборки (и демультиплексирования логических каналов) добавляется к существующему функциональному блоку разборки в каждой очереди переупорядочения. Необязательно, функциональность повторной сборки всегда может присутствовать, когда MAC-hs установлен (при условии, что WTRU поддерживает R7), поскольку в сотах R6 нет записей в очереди переупорядочения, имеющих идентификаторы сегментации.

Если происходит изменение с R7 на R6, может осуществляться следующая последовательность событий:

1) выполняется сброс MAC-ehs, как задано для сот UTRA R7;

2) после сброса процессов HARQ, MAC-hs конфигурируется поддерживать формат заголовка R6;

3) функциональность демультиплексирования очередей по приоритету удаляется. Необязательно, функциональность демультиплексирования сохраняется в MAC-hs, поскольку в сотах R6 только одна очередь переупорядочения должна присутствовать в каждом MAC-hs PDU;

4) функциональность повторной сборки удаляется. Необязательно, повторная сборка остается неактивной в MAC-hs, поскольку в сотах R6 нет записей в очереди переупорядочения, имеющих идентификаторы сегментации.

Процедура переконфигурирования MAC-hs

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

WTRU может изменять свою конфигурацию MAC-hs с усовершенствованной конфигурации на обычную конфигурацию или наоборот, если скомандовано посредством верхних уровней. Это может происходить, например, в течение сценария передачи обслуживания. Процедура, которая направлена на переконфигурирование MAC-hs между MAC-hs и MAC-ehs, описывается ниже.

Процедура переконфигурирования базируется на информации, предоставляемой в WTRU через RRC-сообщения, которые содержат IE для конфигураций MAC-hs или MAC-ehs или эквивалентный им IE, включенный в IE "Информация отображения для RB", и IE имеется, когда RB устанавливается или переконфигурируется.

Процедура переконфигурирования может осуществляться при: описании универсальных действий при получении IE "Информация отображения для RB"; новом определении, которое направлено на действия по получению IE "MAC-hs-конфигурация DL" или эквивалентного ему IE; или другом предусмотренном действии, которое направлено на другую конфигурацию MAC.

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

a) если "MAC-hs-конфигурация DL" устанавливается в значение "усовершенствованная", а ранее сохраненное значение равно "обычная" (т.е. если конфигурация изменяется от обычной на усовершенствованную):

1) сбрасывать объект MAC-hs и

2) конфигурировать MAC-hs или MAC-ehs согласно IE "MAC-hs-конфигурация DL";

b) иначе, если "MAC-hs-конфигурация DL" устанавливается в значение "обычная", а ранее сохраненное значение равно "усовершенствованная" (т.е. если конфигурация изменяется от усовершенствованной на обычную):

1) сбрасывать объект MAC-ehs и

2) конфигурировать MAC-hs или MAC-ehs согласно IE "MAC-hs-конфигурация DL".

В необязательном варианте осуществления, если переконфигурирование MAC-hs выполняется во время передачи обслуживания, существующий индикатор сброса MAC-hs может использоваться одновременно с изменением конфигурации. Тем не менее, процедура должна обеспечивать, что индикатор сброса MAC-hs считывается и выполняется до переконфигурирования MAC-hs. В этом варианте осуществления, может быть выполнена необязательная проверка. Если переконфигурирование MAC-hs выполняется и индикатор сброса MAC-hs не задан, то режим работы WTRU может быть неопределенным, или MAC независимо выполняет сброс.

Необязательно, переконфигурирование MAC от обычной на усовершенствованную и наоборот может быть указано в технических требованиях MAC (3GPP 25.321). Этапы могут быть указаны как часть существующей процедуры MAC-hs или MAC-ehs. Более конкретно, когда сброс MAC-hs или MAC-ehs запрашивается посредством верхних уровней вследствие переконфигурирования от обычного на усовершенствованный MAC-hs или наоборот, следующее может быть прояснено в процедуре сброса MAC-ehs и/или MAC-hs. Если переконфигурирование произошло (или необязательно это может применяться ко всем случаям), все очищенные PDU переупорядочения или MAC-hs PDU должны быть обработаны с использованием старой конфигурации, существующей до индикатора сброса.

Альтернативно, процедура переконфигурирования может быть указана в новом разделе технических требований MAC (3GPP 25.321) или как часть процедуры переконфигурирования параметров MAC-hs/MAC-ehs. Способ направлен, в частности, на переконфигурирование MAC-hs на MAC-ehs или наоборот, упорядоченное посредством верхних уровней. Более конкретно, следующее может быть задано и указано:

MAC-hs/ehs-объект может быть переконфигурирован (модифицирован) посредством верхних уровней от обычного на усовершенствованный или наоборот.

Когда MAC-hs/ehs-объект переконфигурируется посредством верхних уровней, WTRU должен сбрасывать MAC-hs/ehs-объект (все пакеты в очередях переупорядочения должны быть обработаны с использованием старой конфигурации до переконфигурирования).

Альтернативно для цели этой процедуры, сброс может быть заменен посредством удаления всех PDU переупорядочения или MAC-hs PDU из очереди переупорядочения и доставки их выходному объекту, где выходной объект - это объект выше объекта переупорядочения (например, для MAC-hs это может быть объект разборки, а для MAC-ehs это может быть объект демультиплексирования LCH-ID или объект повторной сборки). Отметим, что процедура сброса по-прежнему может выполняться после переконфигурирования вследствие явного индикатора сброса MAC-hs в команде передачи обслуживания. Затем использование конфигурации нового MAC-hs или MAC-ehs начинается во время активации, указанное посредством верхних уровней.

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

a) Переключение с сот R6 на соты R7 без полного сброса RLC.

При переключении с сот R6 на соты R7 полный сброс может не выполняться вследствие того, что новый RLC может быть сконфигурирован поддерживать гибкие размеры PDU. Это называется частичным сбросом. Если заголовки RLC не имеют каких-либо значительных изменений, существующие фиксированные RLC PDU предпочтительно обрабатываются как гибкие PDU в новом RLC. Следовательно, RLC-объект предпочтительно сохраняет существующие порядковые номера и соответствующие RLC PDU. Тем не менее, некоторые переменные предпочтительно повторно инициализируются или изменяются, чтобы поддерживать новые RLC-объекты. Эти переменные предпочтительно включают в себя, но не только, один или комбинацию таймеров, переменные, которые направлены на поддержку окна приема и передачи, критерии для отчета о состоянии и другие переменные состояния, применимые к R7.

Если сброс требуется, способ, аналогичный приведенному ниже, может быть выполнен.

b) Переключение с сот R7 на соты R6, когда сброс RLC требуется.

Изменение обслуживающей соты с соты R7 на соту R6 может требовать сброса RLC вследствие того, что R6 RLC не сконфигурирован обрабатывать гибкие размеры RLC PDU. Следовательно, RLC PDU в RLC-объекте предпочтительно удаляются на передающей стороне и обрабатываются на приемной стороне до того, как сброс применяется. Чтобы оптимизировать процедуру сброса и минимизировать потерю данных, один из следующих двух вариантов предпочтительно выполняется. Дополнительно, в других системах, где функциональность RLC включена в узел B, таких как LTE или R8 WCDMA с плоской архитектурой, когда происходит передача обслуживания между узлами B, RLC-объект в WRTU, вероятно, должен быть сброшен или повторно установлен, и потеря данных должна быть минимизирована. Варианты, описанные ниже, также применимы к таким системам.

Вариант 1

Передающая сторона сбрасывает переменные состояния, указанные для отправителя. Передающая сторона задает конфигурируемые параметры, применимые к передающей стороне нового RLC-объекта. Передающая сторона сбрасывает номер гиперкадра (HFN). Передающая сторона отбрасывает SDU, которые успешно переданы в приемное устройство для каждого AM RLC-объекта (т.е. все RLC PDU, соответствующие SDU, прием которых положительно подтвержден, и альтернативно уведомляют верхние уровни, что эти SDU успешно переданы).

Альтернативно, передающая сторона может отбрасывать все SDU, которые успешно переданы, до первого неуспешного SDU. Все SDU, которые имеют один или более RLC PDU без подтверждения приема, сохраняются в буфере передачи, причем буфер передачи может находиться в RLC-объекте или на верхних уровнях, таких как протокол сходимости пакетных данных (PDCP). Передающая сторона отбрасывает все RLC PDU и все управляющие PDU на передающей стороне. Как только процедура сброса завершена, RLC SDU, которые не отброшены, могут быть переданы через целевой узел B по новой конфигурации RLC в целевом узле B.

Этот способ минимизирует потерю данных, и неуспешные SDU повторно передаются. Поскольку передающая сторона не принимала конечное состояние PDU от приемной стороны, передающая сторона не имеет актуальной информации о состоянии. Это может приводить к дублированной передаче RLC SDU. Следовательно, функциональность обнаружения дублирования может быть добавлена на приемной стороне.

Необязательно, способ может быть реализован с тем, чтобы получать информацию конечного состояния от приемной стороны до сброса RLC. Приемная сторона, после сброса и/или переконфигурирования MAC-hs, инициирует отчет о состоянии для всех объектов AM RLC, отображенных на HS-DSCH. Отчеты о состоянии основаны на RLC PDU. Тем не менее, передающая сторона должна ожидать, чтобы принимать состояние RLC PDU до сброса RLC. Это может задерживать процедуру передачи обслуживания.

Альтернативно, приемная сторона может передавать состояние RLC SDU передающей стороне. Передающая сторона затем может отбрасывать все остальные RLC SDU, которые успешно приняты. Это может минимизировать дублированную передачу. Тем не менее, требуется сп