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

Формула изобретения

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

принимают сообщение сброса усовершенствованного высокоскоростного MAC (MAC-ehs) от модуля управления радиоресурсами (RRC);

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

останавливают таймер отключения переупорядочения и таймер переупорядочения MAC-ehs, находящийся в очереди переупорядочения МАС-модуля, при этом очередь переупорядочения выполняет переупорядочение принимаемых блоков протокольных данных (PDU) MAC-ehs с использованием, по меньшей мере, одной переменной;

устанавливают таймеры и переменную на их начальные значения;

доставляют все PDU переупорядочения в очереди переупорядочения в модуль повторной сборки, находящийся в МАС-модуле;

посредством модуля повторной сборки выполняют повторную сборку сегментированных блоков служебных данных (SDU) MAC-ehs и доставляют успешно повторно собранные MAC-ehs SDU в модуль демультиплексирования идентификатора логического канала (LCH-ID), находящийся в МАС-модуле;

посредством модуля демультиплексирования LCH-ID доставляют готовые MAC SDU в корректный логический канал или поток MAC;

отбрасывают сохраненные сегменты MAC-ehs SDU из модуля повторной сборки; и очищают очередь переупорядочения.

2. Беспроводной модуль передачи/приема (WTRU), содержащий:

модуль управления радиоресурсами (RRC); и

модуль управления доступом к среде (MAC), содержащий:

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

очередь переупорядочения, включающую в себя таймер отключения переупорядочения и таймер переупорядочения усовершенствованного высокоскоростного MAC (MAC-ehs); модуль повторной сборки; и

модуль демультиплексирования идентификатора логического канала (LCH-ID), при этом МАС-модуль выполнен с возможностью:

принимать сообщение сброса MAC-ehs от RRC-модуля;

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

останавливать таймер отключения переупорядочения и таймер переупорядочения MAC-ehs, при этом очередь переупорядочения выполняет переупорядочение принимаемых блоков протокольных данных MAC-ehs (PDU) с использованием, по меньшей мере, одной переменной;

устанавливать таймеры и переменную на их начальные значения;

доставлять все PDU переупорядочения в очереди переупорядочения в модуль повторной сборки, при этом модуль повторной сборки выполняет повторную сборку сегментированных блоков служебных данных (SDU) MAC-ehs, доставляет успешно повторно собранные MAC-ehs SDU в модуль демультиплексирования LCH-ID, который доставляет готовые MAC SDU в корректный логический канал или поток MAC, отбрасывает сохраненные сегменты MAC-ehs SDU из модуля повторной сборки; и

очищать очередь переупорядочения.

3. Способ выполнения переконфигурирования высокоскоростного управления доступом к среде (MAC-hs) или усовершенствованного MAC-hs (MAC-ehs) в беспроводном модуле приема/передачи (WTRU),

при этом способ содержит этапы, на которых:

принимают сообщение передачи обслуживания согласно управлению радиоресурсами (RRC), указывающее новое значение конфигурации MAC-hs или MAC-ehs в нисходящей линии связи (DL).

4. Способ по п.3, в котором WTRU определяет из RRC-сообщения, что переконфигурирование MAC произошло, когда MAC изменяется с MAC-hs на MAC-ehs или с MAC-ehs на MAC-hs.

5. Способ по п.4, в котором в сообщении передачи обслуживания RRC устанавливается индикатор сброса MAC-hs/ehs.

6. Способ по п.5, в котором WTRU выполняет сброс MAC-hs или MAC-ehs до переконфигурирования MAC-hs/ehs, если индикатор сброса MAC-ehs или MAC-hs присутствует.

7. Способ по п.5, в котором осуществляется неопределенный режим работы WTRU, если сброс MAC-hs или MAC-ehs не установлен в сообщении передачи обслуживания RRC, и произошло переконфигурирование MAC-hs/ehs.

Описание изобретения к патенту

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

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

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

Некоторые из главных целей развития стандарта высокоскоростного пакетного доступа (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, которые успешно приняты. Это может минимизировать дублированную передачу. Тем не менее, требуется способ для того, чтобы идентифицировать RLC SDU (нумерация RLC SDU). Необязательно, эта функция может быть выполнена посредством уровня протокола сходимости пакетных данных (PDCP) вместо RLC-уровня. Если процесс восстановления данных обрабатывается посредством PDCP, эквивалентом RLC SDU является PDCP SDU. Как упомянуто выше, сторона передающего устройства должна использовать отчет о состоянии для того, чтобы повторно передавать SDU, которые не приняты успешно, и отбрасывать SDU, которые указаны как успешно принятые в соответствии с отчетом о состоянии, на RLC-уровне или на PDCP-уровне.

В приемной стороне, после того, как MAC сброшен, и все успешно принятые пакеты, включая все пакеты в очереди переупорядочения, доставлены в RLC, могут осуществляться следующие этапы. Приемная сторона обрабатывает все RLC PDU. Необязательно, приемная сторона формирует отчеты о состоянии RLC для каждого экземпляра AM RLC, если используется для того, чтобы минимизировать потерю данных. Приемная сторона отправляет RLC PDU, которые могут быть успешно собраны в RLC SDU, на верхние уровни. Приемная сторона отбрасывает RLC PDU, которые не могут быть собраны в RLC SDU. Необязательно, если последовательная доставка поддерживается, RLC SDU, которые не являются последовательными, могут быть сохранены на приемной стороне, поскольку отсутствующие SDU должны быть повторно переданы из целевого узла B. Необязательно, это может быть выполнено на PDCP-уровне. Более конкретно, если эта функциональность выполняется в PDCP, процедура, описанная непосредственно выше, должна быть заменена на PDCP SDU. Более конкретно, PDCP должен сохранять PDCP SDU, которые не являются последовательными, до тех пор пока отсутствующие SDU не переданы повторно из целевого узла B. RLC-уровень затем может быть переконфигурирован к новой конфигурации RLC при одновременном сбрасывании переменных состояния и задании конфигурируемых параметров, применимых к приемной стороне, равными значениям по умолчанию. Функциональность дублированного обнаружения может быть добавлена. Дублированные RLC SDU могут быть удалены и не переданы на верхние уровни. Этот этап может необязательно быть выполнен посредством верхних уровней.

Вариант 2

В соответствии с вариантом 2, можно не допускать сброса RLC.

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

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

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

- принимают сообщение сброса усовершенствованного высокоскоростного MAC (MAC-ehs) от модуля управления радиоресурсами (RRC);

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

- останавливают таймер отключения переупорядочения и таймер переупорядочения MAC-ehs, находящийся в очереди переупорядочения MAC-модуля, при этом очередь переупорядочения выполняет переупорядочение принимаемых блоков протокольных данных MAC-ehs (PDU) с использованием, по меньшей мере, одной переменной;

- устанавливают таймеры и переменную на их начальные значения;

- доставляют все PDU переупорядочения в очереди переупорядочения в модуль повторной сборки, находящийся в MAC-модуле;

- посредством модуля повторной сборки выполняют повторную сборку сегментированных блоков служебных данных (SDU) MAC-ehs и доставляют успешно повторно собранные MAC-ehs SDU в модуль демультиплексирования по идентификатору логического канала (LCH-ID), находящийся в MAC-модуле;

- посредством модуля демультиплексирования LCH-ID доставляют готовые MAC SDU в корректный логический канал или поток MAC;

- отбрасывают сохраненные сегменты MAC-ehs SDU из модуля повторной сборки; и

- очищают очередь переупорядочения.

2. Беспроводной модуль передачи/приема (WTRU), содержащий:

- модуль управления радиоресурсами (RRC), выполненный с возможностью принимать сообщение передачи обслуживания RRC, указывающее то, что переконфигурирование между фиксированными и гибкими размерами блоков протокольных данных (PDU) управления радиолинией (RLC) произошло; и

- модуль управления радиолинией (RLC), при этом RRC-модуль определяет то, следует или нет отправлять сообщение повторного установления RLC в RLC-модуль.

3. WTRU по варианту осуществления 2, в котором RRC определяет, требуется ли повторное установление RLC, если сообщение передачи обслуживания RRC указывает, что конфигурация RLC изменилась с гибкого размера RLC PDU на фиксированный размер RLC PDU.

4. Способ выполнения переконфигурирования высокоскоростного управления доступом к среде (MAC-hs) или усовершенствованного MAC-hs (MAC-ehs) в беспроводном модуле приема/передачи (WTRU), при этом способ содержит этапы, на которых:

- принимают сообщение передачи обслуживания согласно управлению радиоресурсами (RRC), указывающее новое значение конфигурации MAC-hs или MAC-ehs в нисходящей линии связи (DL).

5. Способ по варианту осуществления 4, в котором WTRU определяет из RRC-сообщения, что переконфигурирование MAC произошло, когда MAC изменяется с MAC-hs на MAC-ehs или с MAC-ehs на MAC-hs.

6. Способ по любому из вариантов осуществления 4 и 5, в котором индикатор сброса MAC-hs/ehs задается в сообщении передачи обслуживания RRC.

7. Способ по варианту осуществления 6, в котором WTRU выполняет сброс MAC-hs или MAC-ehs до переконфигурирования MAC-hs/ehs, если индикатор сброса MAC-ehs или MAC-hs присутствует.

8. Способ по варианту осуществления 6, в котором неопределенный режим работы WTRU возникает, если сброс MAC-hs или MAC-ehs не задан в сообщении передачи обслуживания RRC, и переконфигурирование MAC-hs/ehs выполнено.

9. Способ минимизации потери данных в ходе процедуры передачи обслуживания, при этом способ содержит этапы, на которых:

- отбрасывают блоки служебных данных (SDU), которые успешно переданы, причем SDU соответствуют SDU управления радиолинией (RLC); и

- сохраняют SDU, которые не отброшены в буфере передачи RLC.

10. Способ по варианту осуществления 9, дополнительно содержащий этап, на котором:

- отбрасывают все RLC PDU в буфере повторной передачи.

11. Способ по варианту осуществления 10, дополнительно содержащий этапы, на которых:

- сбрасывают переменные состояния, ассоциированные с передающей стороной RLC;

- сбрасывают номер гиперкадра (HFN) и

- устанавливают новую конфигурацию RLC.

12. Способ минимизации потери данных в ходе процедуры передачи обслуживания, при этом способ содержит этапы, на которых:

- отбрасывают блоки служебных данных (SDU), которые успешно переданы, причем SDU соответствуют SDU по протоколу сходимости пакетных данных (PDCP); и

- сохраняют SDU, которые не отброшены в буфере передачи PDCP.

13. Способ по варианту осуществления 12, дополнительно содержащий этап, на котором:

- отбрасывают все блоки протокольных данных (PDU) управления радиолинией (RLC) в буфере повторной передачи.

14. Способ по варианту осуществления 13, дополнительно содержащий этапы, на которых:

- сбрасывают переменные состояния, ассоциированные с передающей стороной RLC;

- сбрасывают номер гиперкадра (HFN) и

- устанавливают новую конфигурацию RLC.

15. Способ минимизации потери данных в ходе процедуры передачи обслуживания, при этом способ содержит этапы, на которых:

- отбрасывают блоки служебных данных (SDU), которые успешно переданы, до первого неуспешно переданного SDU; и

- сохраняют SDU, которые не отброшены в буфере передачи управления радиолинией (RLC), причем SDU соответствуют RLC SDU.

16. Способ по варианту осуществления 15, дополнительно содержащий этап, на котором:

- отбрасывают все RLC PDU в буфере повторной передачи.

17. Способ по варианту осуществления 16, дополнительно содержащий этапы, на которых:

- сбрасывают переменные состояния, ассоциированные с передающей стороной RLC;

- сбрасывают номер гиперкадра (HFN) и

- устанавливают новую конфигурацию RLC.

18. Способ минимизации потери данных в ходе процедуры передачи обслуживания, при этом способ содержит этапы, на которых:

- отбрасывают блоки служебных данных (SDU), которые успешно переданы, до первого неуспешно переданного SDU; и

- сохраняют SDU, которые не отброшены в буфере передачи протокола сходимости пакетных данных (PDCP), причем SDU соответствуют PDCP SDU.

19. Способ по варианту осуществления 18, дополнительно содержащий этап, на котором:

- отбрасывают все RLC PDU в буфере повторной передачи.

20. Способ по варианту осуществления 19, дополнительно содержащий этапы, на которых:

- сбрасывают переменные состояния, ассоциированные с передающей стороной RLC;

- сбрасывают номер гиперкадра (HFN) и

- устанавливают новую конфигурацию RLC.

21. Способ отправки отчета о состоянии блока служебных данных (SDU), когда передача обслуживания осуществлена, при этом способ содержит этапы, на которых:

- подтверждают прием успешно принятых SDU и

- отрицательно подтверждают прием неуспешно принятых SDU, при этом отчет о состоянии SDU соответствует отчету о состоянии SDU управления радиолинией (RLC).

22. Способ по варианту осуществления 21, дополнительно содержащий этап, на котором:

- отбрасывают SDU, прием которых подтвержден в принимаемом отчете о состоянии RLC SDU во время передачи обслуживания.

23. Способ отправки отчета о состоянии блока служебных данных (SDU), когда передача обслуживания осуществлена, при этом способ содержит этапы, на которых:

- подтверждают прием успешно принятых SDU и

- отрицательно подтверждают прием неуспешно принятых SDU, при этом отчет о состоянии SDU соответствует отчету о состоянии SDU по протоколу сходимости пакетных данных (PDCP).

24. Способ по варианту осуществления 23, дополнительно содержащий этап, на котором:

- отбрасывают SDU, прием которых подтвержден в принимаемом отчете о состоянии PDCP SDU во время передачи обслуживания.

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

- повторно передают SDU по новой соте, при этом SDU соответствуют SDU управления радиолинией (RLC).

26. Способ по варианту осуществления 25, дополнительно содержащий этап, на котором:

- повторно передают все SDU, прием которых не подтвержден.

27. Способ по варианту осуществления 25, дополнительно содержащий этап, на котором:

- повторно передают все SDU с первого неуспешно переданного SDU.

28. Способ по варианту осуществления 25, дополнительно содержащий этап, на котором:

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

29. Способ по варианту осуществления 25, дополнительно содержащий этап, на котором:

- повторно передают SDU, которые сохранены в буфере передачи RLC SDU.

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

- повторно передают SDU по новой соте, при этом SDU соответствуют SDU по протоколу сходимости пакетных данных (PDCP).

31. Способ по варианту осуществления 30, дополнительно содержащий этап, на котором:

- повторно передают все SDU, прием которых не подтвержден.

32. Способ по варианту осуществления 30, дополнительно содержащий этап, на котором:

- повторно передают все SDU с первого неуспешно переданного SDU.

33. Способ по варианту осуществления 30, дополнительно содержащий этап, на котором:

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

34. Способ по варианту осуществления 30, дополнительно содержащий этап, на котором:

- повторно передают SDU, которые сохранены в буфере передачи PDCP SDU.

35. Способ обработки блоков служебных данных (SDU), когда передача обслуживания осуществлена, при этом способ содержит этапы, на которых:

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

- отправляют все успешно собранные RLC SDU на верхние уровни;

- отбрасывают все RLC PDU, которые не могут быть собраны в RLC SDU; и

- сохраняют все внеочередные SDU в буфере приема RLC SDU.

36. Способ по варианту осуществления 35, дополнительно содержащий этапы, на которых:

- сбрасывают переменные приемника и номер гиперкадра (HFN);

- устанавливают новую конфигурацию управления доступом к среде (MAC) и

- устанавливают новую конфигурацию RLC.

37. Способ по варианту осуществления 36, дополнительно содержащий этап, на котором:

- собирают отчет о состоянии SDU, указывающий успешно и неуспешно принятые SDU, причем отчет о состоянии SDU соответствует отчету о состоянии RLC SDU.

38. Способ обработки блоков служебных данных (SDU), когда передача обслуживания осуществлена, при этом способ содержит этапы, на которых:

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

- отправляют все успешно собранные RLC SDU на верхние уровни;

- отбрасывают все RLC PDU, которые не могут быть собраны в RLC SDU; и

- сохраняют все внеочередные SDU в буфере приема SDU по протоколу сходимости пакетных данных (PDCP).

39. Способ по варианту осуществления 38, дополнительно содержащий этапы, на которых:

- сбрасывают переменные приемника и номер гиперкадра (HFN);

- устанавливают новую конфигурацию управления доступом к среде (MAC) и

- устанавливают новую конфигурацию RLC.

40. Способ по варианту осуществления 39, дополнительно содержащий этап, на котором:

- собирают отчет о состоянии SDU, указывающий успешно и неуспешно принятые SDU, причем отчет о состоянии SDU соответствует отчету о состоянии PDCP SDU.

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

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

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