СПОСОБ И УСТРОЙСТВО УЛУЧШЕНИЯ RLC ДЛЯ ГИБКОГО РАЗМЕРА PDU RLC Российский патент 2012 года по МПК H04L12/56 

ОБЛАСТЬ ТЕХНИКИ

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

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

Развитие высокоскоростного пакетного доступа (HSPA +) здесь относится к стандартам технологии радиодоступа Проекта Партнерства Третьего поколения (3GPP), эволюционного улучшения стандартов высокоскоростного пакетного доступа в нисходящей линии связи (HSDPA) и высокоскоростного пакетного доступа в восходящей линии связи (HSUPA), используемых в Универсальных системах мобильной связи (UMTS) систем беспроводной связи. Некоторые из усовершенствований к HSDPA (Выпуск 5 Стандарта UMTS 3GPP) и HSUPA (Выпуск 6 Стандарта UMTS 3GPP), предложенные как часть HSPA+, включают в себя более высокие скорости передачи данных, более высокую емкость системы и покрытие, улучшенную поддержку пакетных услуг, сниженное время ожидания, сниженную стоимость операций и обратную совместимость с предшествующими 3GPP системами. Здесь предшествующие 3GPP системы обычно относятся к любому одному или более предшествующим Стандартам 3GPP от Выпуска 6 и ранее. Достижение этих усовершенствований затрагивает развитие и протокола радиоинтерфейса, и сетевой архитектуры.

Следующий список включает релевантые аббревиатуры:

3GPP - Проекта партнерства третьего поколения

AM - режим подтверждения

AMD - данные режима подтверждения

ARQ - Запрос автоматического повторения

CN - Основная сеть

CP - Плоскость управления

CS - С коммутацией каналов

DL - Нисходящая линия связи

HARQ - Гибридный автоматический запрос повторной передачи

HSDPA - Высокоскоростной пакетный доступ нисходящей линии связи

HSUPA - Высокоскоростной пакетный доступ восходящей линии связи

IP - Протокол Internet

LCID - Идентификатор логического канала

LTE - Долгосрочное развитие

MAC - Управление доступом к среде передачи данных

PDCP - Протокол сходимости пакетных данных

PDU - Модуль пакетных данных

PHY - Физический

PS - С коммутацией пакетов

QoS - Качество обслуживания

RAN - Сеть радиодоступа

RLC - управление линией радиосвязи

RNC - Контроллер радиосети

CRNC - Управляющий RNC

SRNC - Обслуживающий RNC

RNS - Подсистема радиосети

RoHC - Надежное сжатие заголовка

RRC - Управление радиоресурсами

RRM - Координация радиоресурсов

Rx - Прием/принимающий

SAP - Обслуживающая точка доступа

SDU - Блок служебных данных

SN - Порядковый номер

TB - Транспортный блок

TBS - Набор транспортных блоков

TF - Транспортный формат

TFC - Комбинация транспортного формата

TFRC - Комбинация ресурсов транспортного формата

ТМ - Прозрачный режим

ТМ - Данные прозрачного режима

Tx - Передача/передающий

UE - Пользовательское оборудование

UL - Восходящая линия связи

UM - Режим без подтверждения

UMD - Данные режима без подтверждения

UP - Плоскость пользователя

UMTS - Универсальная система мобильной связи

UTRAN - Универсальная наземная сеть радиодоступа

WTRU - Модуль беспроводного приема/передачи

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

Некоторые из основных функций протокола MAC:

• отображение канала блоков пакетных данных (PDU) MAC на физические каналы

• мультиплексирование данных высокого уровня в блоки пакетных данных (PDU)

• качество обслуживания (QoS), которое принимает во внимание приоритет данных для планирования и регулирования скорости

• адаптация линии связи для QoS и мультиплексирования

• гибридный автоматический запрос повторной передачи (HARQ) для управления быстрыми ретрансляциями для исправления ошибок.

Уровень MAC объединяет данные высокого уровня в PDU MAC. MAC PDU, которые отправляются на физическом уровне (PHY), называют транспортными блоками (TB). Набор TB, упомянутый как набор транспортных блоков (TBS), отправляют каждый интервал времени (TTI) по уровню PHY с соответствующим форматом транспортировки (TF), который описывает атрибуты физического уровня для этого TBS. Если TBS получается комбинированием или мультиплексированием данных от более чем одного логического канала RLC, то используется комбинация TF, известная как комбинация формата транспортировки (TFC). Как часть адаптации линии связи уровень MAC выполняет выбор TFC, основанный на приоритете логического канала RLC, заполнении буфера RLC, физических условиях канала и мультиплексировании логического канала. Упоминание здесь выбора TFC MAC является общим и может включать в себя, например, выбор комбинации ресурсов формата транспортировки (TFRC) в высокоскоростном MAC (MAC-hs) протокола в HSDPA.

Протокол RLC на Уровне 2 оказывает большое влияние на время задержки и пропускную способность данных. Протокол RLC в предшествующих системах 3GPP, включая Выпуск 6 и более ранние, физически расположен в узле контроллера радиосети (RNC).

Некоторые из основных функций передачи (Tx) протокола RLC, которые имеют место в объекте Tx RLC, следующие:

• макроразнесение для разрешения соединения UE одновременно с двумя или более ячейками и прием данных (опционально)

• сегментация высокоуровневых однонаправленных радиоканалов

• соединение высокоуровневых однонаправленных радиоканалов

• обнаружение ошибок и восстановление PDU, принятых с ошибкой

• ARQ c HARQ поддержкой для быстрых ретрансляций PDU, принятых с ошибкой.

Некоторые из основных функций приема (Rx) протокола RLC, которые имеют место в объекте Rx RLC, следующие:

• обнаружение дублирования PDU

• последовательная доставка PDU

• обнаружение ошибок и восстановление PDU, принятых с ошибками

• ARQ c HARQ поддержкой для быстрых ретрансляций PDU, принятых с ошибкой

• повторная сборка данных высокого уровня из принятых PDU.

Три режима работы для уровня RLC - это режим с подтверждением (AM), режим без подтверждения (UM) и прозрачный режим (ТМ). В режиме AM, который включает в себя передачу некоторых данных высокого уровня плоскости пользователя, протокол RLC двунаправлен таким образом, что управляющую информацию и информацию о состоянии отправляют от Rx RLC объекта к Tx RLC объекту. В работе с ТМ и UM, которые включают в себя передачу некоторых сигнальных данных управления радиоресурсами (RRC) управляющей плоскости, протокол RLC является однонаправленным, так что Tx RLC объект и Rx RLC объект независимы, без обмена управляющей информацией и информацией о состоянии. Кроме того, некоторые из функций, например ARQ с поддержкой HARQ, и обнаружение ошибок, и восстановление, обычно используются только в работе с AM.

Размеры PDU RLC определяются уровнем RRC на основе требований долгосрочного качества обслуживания (QoS) прикладных данных, транспортируемых по логическим каналам RLC. Согласно предшествующим системам 3GPP, включая Выпуск 6 и более ранние, уровень RLC конфигурируется на полустатической основе уровнем RRC с предопределенными размерами PDU RLC. Таким образом, размер PDU RLC фиксируется на полустатической основе верхними уровнями и для PDU RLC назначаются порядковые номера (SN). Данные PDU AM RLC нумеруются по модулю целыми порядковыми номерами (SN) циклически через поле от 0 до 4095.

Типы PDU RLC - это ДАННЫЕ, УПРАВЛЕНИЕ и СОСТОЯНИЕ. PDU ДАННЫЕ используются для передачи данных пользователя, совмещенной информации СОСТОЯНИЯ и бита опроса, когда RLC работает в AM, где бит опроса используется для запроса отчета о состоянии от приемника. PDU УПРАВЛЕНИЕ используется для команд СБРОСА RLC и подтверждения СБРОСА (ACK). PDU СОСТОЯНИЕ используется для обмена информацией о состоянии между двумя объектами RLC, работающими в AM, и может включать в себя суперполя (SUFI) различных типов, включая, например, SUFI Размер Окна и SUFI Перемещение Окна Приема (MRW).

Окно передачи относится к группе PDU, которые обрабатываются для передачи или передаются в настоящий момент. Точно так же окно приема обычно относится к группе PDU, принимаемых или обрабатываемых в приемнике. Размер окна передачи или приема обычно относится к количеству PDU, которые соответственно передаются или принимаются системой. Размерами окна передачи и приема необходимо управлять, используя управление потоком, чтобы не испытывать перегрузку системы и нежелательные частоты потерь пакетов. Вообще говоря, как только PDU успешно принят в приемнике, новый PDU может быть добавлен в окно приема и/или передачи.

Окно передачи RLC составлено из нижней границы и верхней границы. Нижняя граница состоит из SN переданного PDU с самым низким SN, а верхняя граница состоит из SN переданного PDU с самым высоким SN. RLC конфигурируется с максимальным размером окна передачи таким образом, что максимальное число PDU, переданных от нижней границы до верхней границы, не должно превысить максимальный размер окна. Окно приема RLC конфигурируется аналогично. Нижняя граница окна приема RLC есть SN, следующий за последним номером последовательно принятого PDU, и верхняя граница является SN принятого PDU с самым высоким порядковым номером.

У окна приема также есть максимальный размер окна, где максимальный ожидаемый SN PDU равен SN нижней границы плюс максимальный сконфигурированный размер окна. Окнами передачи и приема управляют, используя передачу и прием переменных состояния, в соответствии с нижеследующим описанием.

Среди технологий для управления потоком имеются управление потоком RNC/Узлом B, управление потоком RLC и уведомление о состоянии RLC. Управление потоком RNC/Узлом B относится к процедурам минимизации данных нисходящей линии связи, буферизованных в Узле B. Как правило, данные, предназначенные для UE, передаются из Основной Сети (CN) через контроллер радиосети источника (SRNC) и Узел B, и дрейфовый контроллер радиосети (DRNC) в ситуации дрейфа, когда выполняется передача обслуживания UE в соту с другой подсистемой радиосети (RNS). Узел B предоставляет кредиты (разрешения на передачу очередного пакета данных) распределения для SRNC, и DRNC в состоянии дрейфа, позволяя SRNC отправлять эквивалентное число PDU в Узел B, так что этот RNC не может отправить больше PDU, пока не будет предоставлено больше кредитов. Управление потоком RLC относится к управлению передачей пакетов, включающему в себя размер окна, между Tx RLC объектом и Rx RLC объектом. Отчет о состоянии RLC позволяет приемнику сообщать информацию о состоянии передатчику при запросе передатчика.

Согласно стандартам 3GPP различные параметры управления потоком протокола RLC сигнализируются уровню RLC верхними уровнями, включая следующие параметры:

• окно_Опроса

• сконфигурированный_Размер_Окна_Tx

• сконфигурированный_Размер_Окна_Rx

Эти параметры, дополнительно детально описанные в дальнейшем, используются уровнем RLC наряду с различными переменными состояния RLC для управления потоком, чтобы конфигурировать размер окна приема и передачи. Согласно предшествующим системам 3GPP такие переменные состояния RLC зависят от SN. Например, следующие переменные состояния передатчика RLC зависят от SN:

• VT(S) - переменная состояния отправки, содержащая SN следующих PDU данных AM, которые будут переданы впервые

• VT(A) - переменная состояния подтверждения, содержащая SN, следующий за SN последнего в последовательности подтвержденного PDU AMD, и формирующая нижнюю границу окна передачи

• VT(MS) - переменная состояния максимальной отправки, содержащая SN первого PDU данных AM, который может быть отклонен одноранговым приемником

• VT(WS) - переменная состояния размера окна передачи

Все арифметические операции над VT(S), VT(A), VT(MS), VR(R), VR(H) и VR(MR) зависят от одного или более SN. Следующие переменные состояния приемника RLC также зависят от SN:

• VR(R) - переменная состояния приема, содержащая SN, следующий за последним принятым в последовательности PDU данных AM

• VR(H) - переменная состояния наивысшего ожидаемого состояния, содержащая SN, следующий за самым высоким SN любого принятого PDU данных AM

• VR(MR) - переменная состояния приемлемого максимума, содержащая SN первого PDU данных AM, который должен быть отклонен приемником.

В предшествующих системах 3GPP многие функции, необходимые для поддержки сервиса передачи данных, такие как управление потоком RNC/Узла B, управление потоком данных RLC и сообщение о состояниях RLC, базировались на SN или фактически на числе PDU, когда размер PDU RLC фиксирован. Причина этого состоит в том, что размер окна приема и передачи можно точно определить, используя число PDU и известный и фиксированный размер PDU. Однако в предложениях для HSPA + RLC может конфигурироваться верхними уровнями, чтобы сделать возможными гибкие размеры PDU RLC. Если верхние уровни, например уровень RRC, формируют гибкую операцию размера PDU RLC, то размер PDU RLC является переменным до полустатически заданного максимального размера полезной нагрузки PDU RLC.

Очевидно, что операции RLC на основе существующего SN не могут эффективно работать с гибким размером PDU RLC. Причина состоит в том, что использование числа PDU для определения размера окна будет, при переменном размере окна, иметь результатом возможное переполнение буфера в RNC и недозагрузку буфера в Узле B. Соответственно, было бы выгодно обеспечить дополнительные способы для конфигурирования размера окна для операций с гибким размером PDU RLC.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

Раскрыты улучшения протокола управления линией радиосвязи (RLC) для развития высокоскоростного пакетного доступа (HSPA +) и других беспроводных систем, например систем долгосрочного развития (LTE), где разрешен переменный размер блока пакетных данных (PDU) RLC. Когда размеры PDU RLC не фиксированы, управление потоком контроллера радиосети (RNC)/Узла B, управление потоком RLC, уведомления о состоянии и опрашивающие механизмы делаются не только зависящими от порядковых номеров (SN) или числа PDU, но и конфигурируются с возможностью использования способов на основе подсчета байтов. Предложенные способы на основе подсчета байтов для RLC применяются к обмену данными как по восходящей линии связи, так и по нисходящей линии связи.

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

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

фиг.1 показывает структуру суперполя (SUFI) в блоке пакетных данных (PDU) СОСТОЯНИЕ RLC;

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

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

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

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

ДЕТАЛЬНОЕ ОПИСАНИЕ

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

Здесь представлены способы на основе подсчета байтов для улучшения управления потоком контроллера радиосети (RNC)/Узла B, управления потоком радиоканала (RLC) и механизмов опроса для гибкого размера блока пакетных данных (PDU) RLC. Предложенные улучшения делают возможным эффективное выполнение функций RLC при гибком размере PDU RLC, улучшая предшествующие функции RLC, основанные на порядковых номерах (SN), которые были разработаны для фиксированного размера PDU RLC.

Предложенные улучшения RLC применяются и к нисходящей линии связи (от UE к Универсальной наземной Сети радиодоступа (UTRAN)), и к восходящей линии (от UTRAN к UE) связи и могут использоваться в любых системах беспроводной связи, включая в себя, без ограничения, расширение высокоскоростного пакетного доступа (HSPA +), систем долгосрочного развития (LTE) и широкополосного множественного доступа с кодовым разделением (WCDMA). Для беспроводных систем, таких как LTE, UTRAN эквивалентен развитому UTRAN (E-UTRAN).

Предложенные улучшения RLC могут использоваться в архитектуре, где RLC работает или полностью в Узле B, или частично в RNC и частично в Узле B. Предложенные улучшения RLC преимущественно описаны здесь в отношении HSPA+. Многие функции и параметры основаны на функциях и параметрах для HSDPA и HSUPA и могут быть поняты во взаимосвязи с техническими спецификациями (TS), включая техническую спецификацию 3GPP Протокола RLC для Выпуска 7 (см. 3GPP TS 25.322 V. 7.2.0), которая тем самым включена в настоящее описание. Предполагается, что RLC может быть конфигурирован более высокими уровнями для поддержки гибкого размера PDU при заданном максимальном размере полезной нагрузки PDU RLC. Также предполагается, что максимальный размер PDU RLC может быть выведен из заданного максимального размера полезной нагрузки PDU RLC. Альтернативно, максимальный размер PDU RLC может быть задан напрямую. Кроме того, термины «байты» и «октеты» используются взаимозаменяемо, также как термины «передатчик» и «отправитель».

Одна или более следующих метрик могут использоваться, поодиночке или в комбинации, для определения и управления размером окна, когда гибкий размер PDU RLC конфигурируется посредством RRC:

• число байтов

• число блоков, где каждый блок есть фиксированное число байтов

• количество PDU или порядковые номера (SN).

Метрики, используемые для определения окна, сигнализируются и оговариваются во время установки RRC, процедур конфигурации и реконфигурации однонаправленного радиоканала. Метрики для размера окна, перечисленные выше, могут быть применены во всем обмене сообщениями, который обновляет окно для управления потоком во время соединения. Например, метрики размера окна могут быть включены в суперполе Размер Окна (SUFI) и SUFI Перемещение Окна Приема (MRW) в PDU УПРАВЛЕНИЕ или СОСТОЯНИЕ RLC.

В случае режима подтверждения (AM) RLC, для поддержки гибкого размера PDU RLC в конфигурации RRC и реконфигурации RLC с элементами информации однонаправленного радиоканала (Информация RLC), любое одно или более из следующей информации может обеспечиваться посредством RRC для RLC для сигнализации использования гибкого размера PDU RLC:

• информация ВЫБОР о режиме нисходящей линии связи RLC, включающая в себя новый индикатор для гибкого режима размера PDU RLC в дополнение к другим режимам RLC. Когда указан режим гибкого размера PDU RLC, объекты RLC могут интерпретировать другие параметры протокола RLC в соответствии с этим режимом.

• любой другой новый информационный элемент как часть информации RLC может также использоваться, чтобы указать режим гибкого размера PDU RLC

• информация о размере PDU нисходящей линии связи (DL) RLC в битах может быть многократно использована и интерпретирована в контексте режима гибкого размера PDU RLC, как следует ниже:

• как параметр масштаба RLC в октетах (после деления количества бит на 8), отправленный специально для масштабирования или умножения других параметров протокола, заданных в числе PDU, как описано далее, где параметр масштаба RLC имеет одинаковое значение в объекте получения (Rx) RLC и объекте передачи (Tx) RLC, или

• как указание максимального размера PDU RLC в режиме гибкого размера PDU RLC, где максимальный размер PDU RLC может, в свою очередь, дополнительно использоваться как параметр масштаба RLC, описанный выше

• параметры протокола, сигнализируемые верхними уровнями, например, от RRC к RLC, включающие в себя, без ограничения, PDU_Опрос, SDU_Опрос, Сконфигурированный_Размер_Окна_Тх и Сконфигурированный_Размер_Окна_Rx (см. 3GPP TS 25.322 V. 7.1.0 Секция 9.6), могут задаваться и интерпретироваться следующими двумя способами:

• в числах PDU, или блоках служебных данных (SDU) в случае SDU_ОПРОС, которое является целочисленным значением, из которого RLC может вывести размер окна в октетах, выполняя математическое вычисление. Например, конкретное количество PDU (или SDU, в случае SDU_ОПРОС) может быть перемножено с параметром масштаба RLC в октетах, как определено верхними уровнями.

• в единицах байтов, где новое поле может быть определено для этой опции, чтобы хранить параметр протокола в байтах.

В PDU RLC СОСТОЯНИЕ, Суперполе (SUFI) Размер Окна, используемое приемником, чтобы конфигурировать размер окна передатчика, конфигурируют с возможностью предоставлять количество в октетах. Это расширение используется, когда режим гибкого размера PDU RLC установлен посредством RRC, как описано выше, и может задаваться двумя способами:

• в числах PDU, из которых RLC выводит эквивалентное количество в октетах, выполняя математическое вычисление. Например, конкретное число PDU может быть перемножено с параметром масштаба RLC в октетах, определенных верхними уровнями, как описано выше

• в единицах байтов как новый SUFI с компонентами: тип, длина и значение. Например, в настоящий момент неиспользуемое или зарезервированное поле типа длиной 4 бита, например биты 1000, показанные в Таблице 1, может использоваться, чтобы ввести новый тип SUFI для задания числа байтов, SUFI БАЙТЫ_ОКНА, как показано в Таблице и на фиг.1, где компонент длины SUFI определен достаточно большим, чтобы хранить значение SUFI в байтах наибольшего возможного размера окна.

Бит Описание 0000 Нет Больше Данных(NO_MORE) 0001 Размер Окна (ОКНО) 0010 Подтверждение (ACK) 0011 Список (LIST) 0100 Битовый массив (BITMAP) 0101 Список Отношений (Rlist) 0110 Перемещение Окна Приема (MRW) 0111 Подтверждение Перемещения Окна Приема (MRW ACK) 1000 Байты Размера Окна (БАЙТЫ_ОКНА) 1001-1111 Зарезервировано (PDU с этим кодированием недопустимы для этого варианта протокола)

Таблица: Определение нового типа SUFI 1000 для SUFI БАЙТЫ_ОКНА, добавленного к существующим полям типа SUFI, длина которых составляет 4 бита

Управление потоком RNC/Узла B

Улучшения к управлению потоком RNC/Узла B описаны здесь для случая, в котором объект RLC находится в RNC. Однако подобные улучшения могут быть определены и там, где объект RLC находится в RNC и Узле B. Согласно существующим стандартам 3GPP, как описано в 3GPP TS 25.425 для протоколов плоскости пользователя интерфейса Iur UTRAN для потоков данных Общего Канала Транспорта между RNC и Узлом B и в 3GPP TS 24.435 для протоколов плоскости пользователя интерфейса Iur UTRAN для потоков данных Общего Канала Транспорта между двумя RNC, объект данных MAC (MAC-d) может быть сохранен в RNC, чтобы принимать PDU RLC и отправлять их высокоскоростному объекту MAC (MAC-hs) в Узел B после применения соответствующей информации заголовка. В предшествующих системах 3GPP Узел B отправляет кадры распределения емкости к обслуживающему RNC (SRNC) и, возможно, RNC (CRNC) управления, указывая максимальный размер PDU и количество PDU, которое можно отправить. Дополнительно, параметры можно отправить так, чтобы распределение было периодическим для фиксированного числа периодов или для неопределенного промежутка времени.

Количество PDU MAC, отправленное от RNC в Узел B, и соответствующий интервал времени передачи регулируются алгоритмом управления потоком, который основан на схеме распределения кредита (разрешение на передачу очередного пакета данных). Кредит представляет число PDU MAC-d, которые могут быть переданы. RNC запрашивает кредиты, и Узел B предоставляет их наряду с заданным интервалом времени для передачи.

Когда размер PDU RLC является переменным, размер PDU MAC-d является, следовательно, также переменным. Таким образом, этого недостаточно, чтобы определить число кредитов в терминах числа PDU MAC-d. Есть множество возможных методов выполнения управления потоком данных RNC/Узла B с переменным размером PDU MAC-d. Можно исключить управление потоком RNC/Узла B, однако это будет зависеть от пользовательских протоколов данных, таких как протокол управления транспортом (TCP), для выполнения управления потоком для сети и дополнительной обработки взаимодействия между окном TCP и окном RLC.

Альтернативно, распределение кредита может быть указано в байтах вместо числа PDU, что можно сделать двумя способами. Для задания числа байтов кредитов вместо числа PDU к существующим кадрам может быть добавлено новое поле. Альтернативно, индикация может сигнализироваться при настройке, или реконфигурации однонаправленного радиоканала, или в каждом соответствующем кадре управления, используя существующий кадр управления или новый кадр управления, который указывает, что распределение является фактически байтовым распределением, путем умножения кредита на максимальный размер PDU в байтах, выдавая итог в байтах. Соответственно, максимальное число PDU, которое может быть передано от RNC в Узел B, не будет равно сигнализированному кредиту в терминах числа PDU, но будет ограничено общим количеством байтов в PDU. Используя основанную на байтах технологию, RNC может опционально поддерживать преобразование SN PDU в его длину в байтах. Как только RNC принимает распределение кредита от Узла B, ему разрешается передать столько PDU, сколько он может, не нарушая ограничения длины в байтах, заданного новым распределением кредита на основании длины в байтах.

Фиг.2 показывает блок-схему последовательности операций управления потоком данных RNC/Узла B, использующего основанное на байтах распределение кредита. Узел B сигнализирует о распределении кредита в байтах (этап 205). RNC принимает распределение кредита в байтах (этап 210). RNC сохраняет преобразование SN PDU в длину PDU в байтах (этап 220) и передает PDU, не превышая принятого распределения кредита (этап 220).

Управление потоком RLC

Управление потоком RLC достигается посредством перемещения окна Tx RLC, когда PDU в нижней границе используемого окна (Tx) передачи положительно подтверждается и, следовательно, принимается правильно, все еще оставаясь в пределах, определяемых максимальным размером окна. PDU в нижней границе окна Tx определяют как PDU, следующий за последним подтвержденным PDU в последовательности. Для случая, когда конфигурируется гибкий размер PDU RLC, соответствующие этапы должны быть выполнены так, чтобы не был нарушен максимальный предел размера окна. Размер окна Tx указан в терминах байтов.

Фиг.3 показывает блок-схему последовательности операций способа обновления окна 300 передачи (Tx) RLC. Вслед за инициализацией и установкой RLC выполняется операция Tx RLC (этап 305). Операция Tx RLC может быть, например, приемом информации о состоянии и управляющей информацией от приемника RLC.

Объект RLC Tx решает, удалить ли один или более PDU из используемого окна Tx и увеличить ли нижнюю границу используемого окна Tx (этап 310).

Один или более PDU может быть удален, если:

• PDU были положительно подтверждены приемником, или

• PDU были негативно подтверждены приемником, но передатчик RLC решает забраковать этот PDU по другим причинам, например превышения приемником максимального числа повторений передачи, или

• в результате отбраковки по таймеру в передатчике.

Для простоты описания используется следующая система обозначений для конкретных величин, связанных с объектом Tx RLC:

• TxWMAX: длина в байтах максимального размера окна

• TxWUTIL: длина в байтах используемого окна Tx, или альтернативно, длина в байтах пакетов, которые подтверждены в пределах окна, ограниченного переменными состояния V(A) и V(T)

• TxL: длина в байтах одного или более PDU, которые отбраковываются (отбрасываются) из-за процедуры отбраковки SDU RLC или из-за приема одного или более подтверждений

• TxN: длина в байтах следующего одного или более PDU, которые будут переданы впервые

Объект Tx RLC вычисляет следующую величину длины окна (WL) (этап 315):

WL = TxWUTIL - TxL + TxN. Уравнение (1)

Объект Tx RLC определяет, является ли величина WL меньшей, чем максимальный размер окна TxWMAX (этап 320). Если WL не меньше, чем TxWMAX, то следующий один или более PDU не передается, и верхняя граница окна не увеличивается (этап 325). Если WL меньше, чем TxWMAX, то передаются следующий один или более PDU, и верхняя граница окна увеличивается (этап 330).

Подобный способ управления потоком данных RLC применяют в объекте Rx RLC, когда конфигурируется гибкий размер PDU RLC, чтобы гарантировать, что не нарушен максимальный предел размера окна. Размер окна Rx указан в терминах байтов. В соответствии с настоящим раскрытием фиг.4 показывает блок-схему последовательности операций способа 400 обновления окна приема (Rx) RLC. После инициализации и настройки RLC выполняется (этап 405) операция Rx RLC. Операция Rx RLC может быть, например, приемом нового PDU. Rx объект RLC решает, увеличить ли нижнюю границу окна Rx (этап 410). Rx объект RLC может увеличить нижнюю границу своего окна Rx и, таким образом, уменьшить RxWUTIL, если:

• он принимает PDU с SN следующим за номером последнего последовательно принятого PDU, или

• он принимает Перемещение Окна Приема (MRW) от объекта Tx RLC.

Для простоты описания используется следующая система обозначений для конкретных величин, связанных с объектом RLC Rx:

• RxWMAX: длина в байтах максимального размера окна

• RxWUTIL: длина в байтах используемого окна Rx

• RxD: длина в байтах одного или более PDU, которые удалены из окна приема вследствие последовательного приема

• RxN: длина в байтах следующего одного или большего количества PDU, которые будут приняты впервые.

RLC Rx объект вычисляет следующую величину длины окна (WL) (этап 415):

WL = RxWUTIL + RxN- RxD. Уравнение (2)

Объект Rx RLC определяет, является ли величина WL меньшей, чем максимальный размер окна RxWMAX (этап 420). Если WL не меньше, чем RxWMAX, то следующий PDU не принимают, и верхняя граница окна Rx не увеличивается (этап 425). Если WL меньше, чем RxWMAX, то принимают следующий PDU, без отбрасывания PDU с SN, следующим за самым высоким принятым SN, и увеличивают (430) верхнюю границу окна Rx.

Далее описана настройка переменных состояния передатчика и приемника RLC с использованием способов, основанных на октете. Когда уровнем RRC установлен режим гибкого размера PDU RLC и RLC работает в AM, PDU данных AM RLC нумеруются по модулю целыми порядковыми номерами (SN) циклически через поле. Обычно это поле находится в пределах от 0 до 4095, хотя различное максимальное значение может быть конфигурировано посредством RRC или других верхних уровней. Напомним, что модуль SN влияет на арифметические действия на VT(S), VT(A), VT(MS), VR(R), VR(H) и VR(MR).

Параметр или переменная состояния Максимальный_Размер_Окна_Tx в октетах могут поддерживаться передатчиком RLC. Этот параметр первоначально установлен равным в октетах параметру протокола Сконфигурированный_Размер_Окна_Tx, отправленному верхними уровнями, и может быть обновлен позже до величины октетов, заданной SUFI Размер Окна в PDU СОСТОЯНИЕ RLC. Переменная состояния VT(WS) может быть выведена из Максимальный_Размер_Окна_Tx в октетах и может быть установлена равной наибольшему неотрицательному целому числу, не превышающему 4095 (или максимальному значению, конфигурированному RRC/высшими уровнями), так что длина в октетах окна, ограниченного VT(A) и VT(A) +VT(WS), не превышает Максимальный_Размер_Окна_Tx в октетах. Переменная состояния VT(WS) обновляется при обновлении Максимальный_Размер_Окна_Tx в октетах. Альтернативно, Переменная состояния VT(WS) может быть выведена как наибольшее неотрицательное целое число, не большее чем 4095 (или максимальное значение, конфигурированное RRC/высшими уровнями), так что длина в октетах окна, ограниченного VT(A) и VT(A) +VT(WS), не превышает:

• параметр протокола Сконфигурированный_Размер_Окна_Tx в октетах, и

• SUFI Размер Окна, ссылающийся на количество октетов в PDU СОСТОЯНИЯ RLC, как определено выше.

Переменная состояния VT(MS) - это SN, вычисленный как VT(MS) = VT(A) + VT(WS), где VT(WS) выводится, как описано выше. Переменная состояния VR(MR) является SN, выведенным из Сконфигурированный_Размер_Окна_Rx в октетах, отправленного верхними уровнями, так что длина в октетах окна, ограниченного VR(R) и VR(MR), является наибольшей, но не превышающей Сконфигурированный_Размер_Окна_Rx в октетах.

Улучшение создания PDU RLC

На фиг.5 отображена блок-схема последовательности операций способа создания 500 улучшенного, основанного на октетах, PDU RLC для восходящей и нисходящей линии связи на основании следующих параметров:

• Текущий_Кредит: В восходящей линии связи - это объем данных, который может быть передан на основании адаптации линии связи MAC и отправляемый MAC в RLC UE или в Узел B в системах с неструктурированной архитектурой, таких как системы (LTE) долгосрочного развития и Выпуск 8 систем широкополосного множественного доступа с кодовым разделением (WCDMA). В нисходящей линии связи это является результатом сложения оставшегося распределения кредита и любого нового распределения кредита, отправленного от Узла B в RNC. Эта величина представлена в октетах.

• Доступные_Данные: Данные, доступные для передачи в объекте RLC. Эта величина представлена в октетах.

• Неиспользованное_Окно: Это длина окна, ограниченного посредством VT(S) и VT(MS) в передатчике RLC. Эта величина представлена в октетах.

• Максимальный_Размер_ PDU _RLC: Это максимальный размер PDU RLC, сконфигурированный верхними уровнями, например уровнем RRC.

• Минимальный_Размер_ PDU _RLC: Это параметр, сконфигурированный верхними уровнями, например уровнем RRC, который определяет минимальный размер PDU RLC. Альтернативно, верхние уровни могут определять минимальный размер полезной нагрузки PDU RLC, из которого может быть выведен Минимальный_Размер_PDU_RLC.

После инициирования генерации PDU RLC в каждом интервале времени передачи (TTI) вычисляются следующие величины (этап 505):

X = Min (Текущий_Кредит, Доступные_Данные,

Неиспользованное_Окно} Уравнение (3)

N = Floor {X/Максимальный_Размер_ PDU _RLC} Уравнение (4)

L = X mod Максимальный_Размер_ PDU _RLC Уравнение (5)

где функция Min {•} возвращает минимальное значение из набора, функция Floor {•} возвращает ближайшее меньшее целочисленное значение и a mod b - остаток от целочисленного деления a по модулю b. Генерируется (этап 505) N PDU RLC с размером Максимальный_Размер_ PDU _RLC. Опционально, если L отлично от нуля, один дополнительный PDU RLC может быть создан для TTI. Определяют, является ли X равным параметрам Неиспользованное_Окно или Текущий_Кредит (этап 510). Если да, то определяют, больше ли L, чем параметр Минимальный_Размер_PDU_RLC, или X равно Доступные_Данные (515). Если L больше, чем Минимальный_Размер_PDU_RLC, или X равно Доступные_Данные, то генерируется PDU RLC с длиной L (520). Также если X не равно Неиспользованное_Окно или Текущий_Кредит, то генерируется PDU RLC с длиной L (520). Опционально, если L меньше, чем Минимальный_Размер_PDU_RLC, может быть создан PDU RLC с Минимальный_Размер_PDU_RLC. Сгенерированный PDU RLC сохраняют в буфере для передачи (525). Способ 500 может быть повторен в каждом TTI, или, альтернативно, когда данные являются доступными, или запрашиваются нижними уровнями (530).

В результате описанного выше способа 500 число PDU с длинной, равной максимальному размеру PDU RLC, сгенерированному в этом промежутке времени, который обычно является TTI, или некоторой другой системой указания периодов времени, равно самому большому неотрицательному целому числу, меньшему, чем Min {Текущий_Кредит, Доступные_Данные, Неиспользованное_Окно}/Максимальный_Размер_ PDU _RLC. Если Min (Текущий_Кредит, Доступные_Данные, Неиспользованное_Окно} = Текущий_Кредит, то другой PDU RLC может также быть сгенерирован в тот же самый период с размером, равным Min {Текущий_Кредит, Неиспользованное_Окно, Доступные_Данные} mod Максимальный_Размер_ PDU _RLC. Если Min (Текущий_Кредит, Доступные_Данные, Неиспользованное_Окно} = Доступные_Данные, то другой PDU RLC может также быть сгенерирован в тот же самый период с размером, равным Min {Текущий_Кредит, Неиспользованное_Окно, Доступные_Данные} mod Максимальный_Размер_ PDU _RLC. Если Min {Текущий_Кредит, Доступные_Данные, Неиспользованное_Окно) = Неиспользованное_Окно, то другой PDU RLC может также быть сгенерирован в тот же самый период с размером, равным Min {Текущий_Кредит, Неиспользованное_Окно, Доступные_Данные} mod Максимальный_Размер_ PDU _RLC, если, и только если длина этого PDU больше, чем Минимальный_Размер_ PDU _RLC.

Создание PDU RLC переменного размера может также быть применено без ограничений Минимальный_Размер_PDU_RLC и/или Максимальный_Размер_ PDU _RLC.

Альтернативно, также возможно определить максимальное и минимальное ограничение размера PDU RLC и позволить передатчику выбирать размер с этими ограничениями, не требуя зависимости на основе TTI к адаптации линии связи уровня MAC. Альтернативно, PDU RLC размера X может быть создан в системе, где параметры Минимальный_Размер_PDU_RLC и Максимальный_Размер_PDU_RLC не определены.

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

• переменные состояния передатчика RLC: VT(S), VT(A), VT(MS), VT(WS)

• переменные состояния приемника RLC: VR(R), VR(H), VR(MR)

VT(WS) поддерживается в терминах максимального числа PDU и первоначально конфигурируется более высокими уровнями на основе параметра Сконфигурированный_Размер_Окна_Передачи, представленного в числах PDU. Это значение может соответствовать максимальному числу PDU, разрешенному для окна, и/или максимальному числу PDU, ограниченному числом бит, используемых для порядкового номера. Например, если используются 12 бит, то может поддерживаться до 2¹² или 4096 PDU. Опционально, при гибком размере PDU RLC, можно воспрепятствовать обновлению VT(WS) приемником, используя SUFI ОКНО. Вычисление VT(MS) предпочтительно остается тем же самым, где VT(MS) = VT(A) + VT(WS). Другие переменные состояния приемника могут также сохраняться и обрабатываться согласно предшествующим стандартам 3GPP.

В дополнение к этим переменным также поддерживаются и обрабатываются переменные, относящиеся к подсчету байтов для передатчика и приемника. Некоторые переменные, которые могут использоваться, упомянуты ниже, и принято, что они будут поддерживаться в терминах байтов. Названия этих переменных используются для целей описания, но могут быть также использованы любые названия. Эти переменные включают в себя:

• Сконфигурированный_В_Байтах_Размер_Окна_Tx - Этот параметр протокола указывает и максимальный разрешенный размер окна передачи в октетах, и значение для переменной состояния VT(WS)_байты. Эта переменная может быть конфигурирована, например, любым из следующих способов: более высокими уровнями, сетью, может быть предварительно сконфигурированной в UE или определяться UE на основе требований памяти или категории UE.

• VT(WS)_байты - размер окна передачи, заданный в октетах. Эта переменная состояния содержит размер в октетах, который должен использоваться для окна передачи. Опционально, VT(WS)_байты должен быть равным полю WSN, когда передатчик принимает PDU СОСТОЯНИЕ, включающий в себя SUFI БАЙТ_ОКНО. Начальное значение и максимальное значение для этой переменной состояния заданы посредством Сконфигурированный_В_Байтах_Размер_Окна_Tx.

• Использованное_Окно: длина в байтах использованного окна TX. Для каждой новой передачи количество байтов увеличивается на размер PDU RLC, который будет передан впервые. Для каждого отбракованного PDU количество байтов уменьшается на размер PDU RCL, который будет отбрасываться.

• RxWMAX: длина в байтах максимального размера окна Rx, обеспечиваемого в октетах более высокими уровнями.

• RxWUTIL: длина в байтах использованного окна Rx. Переменная будет увеличена на размер полученного PDU RLC при приеме нового PDU RLC и будет уменьшена на размер PDU RLC, когда PDU RLC удаляют из буфера.

• RxN: длина в байтах полученного PDU для того же самого времени

Комбинация старых и новых переменных состояния позволяет RLC управлять окнами Tx и Rx в терминах максимального количества позволенных байтов, а также в терминах максимального числа позволенных PDU (ограниченного числом порядковых номеров, доступных для передачи).

Процедура RLC, измененная посредством введения гибкого размера PDU RLC

Как описано в настоящем раскрытии, некоторые из процедур в 3GPP TS, 25.322 V7.1.0 могут быть обновлены, чтобы поддерживать и управлять окнами Tx и Rx при гибком размере PDU RLC, включая следующие процедуры:

• передача PDU AMD

• предоставление PDU AMD нижнему уровню

• прием PDU AMD приемником

• прием PDU AMD приемником

• прием PDU AMD вне окна приема

Могут быть обновлены процедуры, связанные с реконфигурацией и повторной инициализацией переменных состояния Tx и Rx.

Передача PDU данных в режиме подтверждения (AMD)

Для фиксированного PDU RLC, когда PDU AMD повторно передаются, передатчик должен гарантировать, что SN PDU AMD меньше, чем переменная максимальной отправки VT(MS). SN повторно передаваемого PDU AMD может быть больше, чем VT(MS), если размер окна был обновлен приемником, используя SUFI ОКНО.

При гибком размере PDU RLC передатчик может также проверять, используя переменную состояния VT(WS)_байты, что использование окна Tx вплоть до PDU AMD, который должен повторно передаваться, не превышает максимальный размер окна в байтах. Переменная состояния Использованное_Окно есть общий размер переданных PDU RLC в буфере повторной передачи. Поэтому, когда это условие проверяется, использование вплоть до повторно переданного SN должно вычисляться независимо. Если Использованное_Окно будет меньше, чем VT(WS)_байты, то условие будет выполнено автоматически, однако, если Использованное_Окно будет больше, чем VT(WS)_байт, использование буфера вплоть до PDU AMD должно быть вычислено, чтобы гарантировать, что оно не будет превышать VT(WS)_байт. Так опционально вычисляется использование буфера, если Использованное_Окно превышает переменную состояния VT(WS) _байт.

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

• если сконфигурирован фиксированный размер PDU RLC, то:

• для каждого PDU AMD, который был негативно подтвержден:

• если SN PDU AMD меньше, чем VT(MS), то:

• планируют PDU AMD для повторной передачи;

• если сконфигурирован гибкий размер PDU RLC, то:

• для каждого PDU AMD, который был негативно подтвержден:

• если (1) использование окна вплоть до SN PDU AMD меньше, чем VT(WS)_байт, причем это условие всегда выполняется, если Использование_Окна <VT(WS)_байт, или вычислено как использованное окно вплоть до SN и (2) опционально, если SN PDU AMD меньше, чем VT (M), то:

• планируют PDU AMD для повторной передачи.

Предоставление PDU AMD нижним уровням

Одно из условий, разрешающее передачу PDU AMD, заключается в том, что SN PDU AMD является меньшим, чем переменная состояния VT(MS). Когда сконфигурирован гибкий размер PDU RLC, дополнительная проверка условия, что использование окна для передачи или повторной передачи PDU не превышает максимальный размер окна в байтах, должна также быть подтверждена. Нижние уровни включают в себя уровень MAC и физический уровень.

Согласно одной технологии, если один или более PDU AMD планировался для передачи или повторной передачи (см., например, 3GPP TS 25.322 подпунктов V7.1.0 11.3.2), то отправитель может:

• не предоставлять любой PDU AMD, который не позволено передавать, нижним уровням. Когда сконфигурирован фиксированный размер PDU RLC, PDU AMD разрешены к передаче, если PDU AMD имеет SN <VT(MS) или если PDU AMD имеет SN, равный VT(S)-1. Если сконфигурирован гибкий размер PDU RLC, то PDU AMD разрешен к передаче, если (1) он имеет SN <VT(MS) или, опционально, PDU AMD имеет SN, равный VT(S)-1, и (2), если переданный PDU AMD не вызовет использования окна, определенного как Используемое_Окно+ размер PDU AMD, превышающего VT(WS)_байт. Дополнительно, PDU AMD разрешен к передаче, если PDU AMD не ограничен к передаче локальной функцией приостановки (см., например, 3GPP TS 25.322 подпункт V7.1.0).

• информировать нижние уровни о количестве PDU AMD, планируемых для передачи или повторной передачи и разрешенных к передаче или повторной передаче. Опционально, если сконфигурирован гибкий размер PDU RLC, отправитель может информировать нижние уровни о числе запланированных байтов.

• устанавливать информационное наполнение PDU AMD согласно, например, 3GPP TS 25.322 подпунктов V7.1.0 11.3.2.1.

• предоставлять нижним уровням запрошенное число PDU AMD. Опционально, если сконфигурирован гибкий размер PDU RLC, отправитель может также предоставить нижним уровням число байтов, запрошенных нижними уровнями.

• обрабатывать повторные передачи с более высоким приоритетом, чем PDU AMD, передаваемые впервые.

• обновлять переменные состояния для каждого PDU AMD, передаваемого нижнему уровню (см., например, 3GPP TS 25.322 подпункт V7.1.0 9.4 для переменных состояний) кроме VT(DAT), которая считает число раз, когда PDU AMD планировался к передаче и которая была уже обновлена, когда устанавливается содержимое PDU AMD (см., например, 3GPP TS 25.322 подпункт V7.1.0 11.3.2).

• если установлен гибкий размер PDU RLC, то обновлять переменную Используемое_Окно, следовательно, обновляя переменные, связанные со слежением за подсчетом байтов.

• если (1) - бит опроса, используемый передатчиком для запроса отчета о состоянии от приемника, установлен на "1" в любом PDU AMD, и (2) - установлен Таймер_Опрос, таймер отслеживания PDU AMD, содержащих запрос, как указано нижними уровнями, запускается таймер Таймер_Опрос (см., например, 3GPP TS 25.322 подпункт V7.1.0 9.5).

• буферизировать PDU AMD, которые не передаются нижним уровням согласно конфигурации отбраковки (см., например, 3GPP TS 25.322 подпункт V7.1.0 9.7.3).

Прием PDU AMD приемником

Обновлена процедура, связанная с приемом PDU AMD приемником, так, чтобы включать в себя и обновлять переменные состояния приемника, связанные с подсчетом байтов при гибком размере PDU RLC. Улучшенная процедура определена следующим образом. По получении PDU AMD приемник должен:

• в UE:

• если размер PDU нисходящей линии связи AMD еще не был установлен, тогда

• установить размер PDU нисходящей линии связи AMD в размер принятого PDU.

• обновить переменные состояния приемника VR(R), VR(H) и VR(MR) для каждого принятого PDU AMD (см., например, 3GPP TS 7 625.322 V7.1.0 пункт 9.4);

• если сконфигурирован гибкий размер PDU RLC, тогда

• обновить переменную состояния RxWUTIL, устанавливая RxWUTIL, равную RxWUTIL, плюс размер новых принятых PDU RLC, минус размер PDU RLC, удаленных из буфера вследствие упорядоченного приема.

Прием PDU AMD вне окна приема

Если сконфигурирован фиксированный размер PDU RLC, то при приеме PDU AMD с SN вне интервала VR(R) <SN <VR(MR) приемник должен:

• отбраковать этот PDU AMD;

• если бит опроса в отбраковываемом PDU AMD установлен на "1", то:

• инициировать процедуру передачи PDU СОСТОЯНИЕ.

Если сконфигурирован гибкий размер PDU RLC, то при приеме нового PDU AMD, чей размер, просуммированный с RxWUTIL, превышает RxWMAX (где RxWMAX <RxWUTIL + вновь принятый размер PDU AMD или RxN), или при приеме PDU AMD с SN вне интервала VR(R) <SN <VR(MR) приемник должен:

• отбраковать этот PDU AMD

• если бит опроса в отбраковываемом PDU AMD установлен на "1", то:

• инициировать процедуру передачи PDU СОСТОЯНИЕ.

Отчет о Состоянии RLC

Отчеты о состоянии RLC, содержащие информацию о подтверждении для поддержки ARQ, могут быть вызваны в различных сценариях объектами Tx RLC и Rx RLC. Чтобы обработать гибкий размер PDU RLC, объекты Tx RLC и Rx RLC могут поддерживать преобразование SN PDU RLC в соответствующую длину PDU в байтах. Это разрешает вычисление и поддержание длины используемого окна управления потоком в байтах или других, как описано выше, основанных на байтах метриках.

Эквивалентный параметр для каждого PDU PDU_Опрос, верхнего предела для переменной состояния VT (PDU) для отслеживания опросов, может быть сконфигурирован в терминах байтов. В этом случае передатчик может иметь механизм опроса количества PDU, и/или механизм опроса количества байтов, так что передатчик опрашивает приемник на каждый байт Байты_Опрос. Для целей описания здесь предполагается, что параметр опроса, предоставляемый более высокими уровнями, называется Байты_Опрос. Сконфигурированный для опроса, передатчик RLC может запустить отчет о состоянии посредством установки бита опроса в конкретном PDU следующим образом:

• Передатчик RLC содержит счетчик общего количества байтов, переданных в PDU, начиная с передачи последнего PDU, содержащего бит опроса, где последний PDU, содержащий бит опроса, может быть обусловлен любым типом триггера опроса, включая в себя, например, PDU_Опрос, SDU_ОПРОС или Байты_Опрос, или альтернативно, может быть ограничен последним PDU, содержащим бит опроса, вызванный механизмом опроса байтов.

• Когда счетчик достигает или превышает значение Байты_Опрос, передатчик RLC устанавливает бит опроса в PDU (или, альтернативно, следующем PDU), вызвавшем значение счетчика, равное или большее значению Байты_Опрос, и сбрасывает счетчик.

Здесь установка бита опроса относится к запросу опроса, так что запрос опроса может состоять из SUFI PDU ОПРОС или может состоять из установки бита опроса в PDU RLC AMD. Общее количество байтов, переданных в PDU, может относиться к размеру PDU, переданных впервые. Альтернативно, оно может относиться к размеру всех переданных PDU, включая повторные передачи. Подсчитанное общее количество переданных байтов может учитывать только первую передачу PDU режима подтверждения данных (AMD) RLC, сегмент PDU AMD RLC или часть SDU RLC, где повторные передачи этих частей данных могут не учитываться.

Параметры протокола PDU_Опрос и SDU_ОПРОС сигнализируются верхними уровнями, например RRC к уровню RLC для указания интервала подсчета PDU. Дополнительно, более высокими уровнями может быть сигнализирован и сконфигурирован параметр протокола Байты_Опрос в октетах. Процедуры опроса в передатчике RLC могут включать в себя следующее:

• Передатчик RLC хранит счетчик переменной Октеты_Опрос для отслеживания общего количества байтов, переданных в PDU, начиная с передачи последнего PDU, содержащего бит опроса, который, возможно, был вызван, например, приемом параметров PDU_Опрос, SDU_ОПРОС или Байты_Опрос от более высоких уровней. Октеты_Опрос может альтернативно следить за общим количеством переданных байтов, следующих за последним PDU, содержащим бит опроса, установленный только благодаря механизму опроса.

Счетчик Октеты_Опрос может опционально считать только PDU данных RLC таким образом, что управляющие PDU RLC не считаются. Когда счетчик Октеты_Опрос достигает интервального значения Байты_Опрос, передатчик RLC устанавливает бит опроса в PDU (или опционально, следующем PDU), который вызывает превышение счетчика Октеты_Опрос порогового значения Байты_Опрос, и сбрасывает счетчик Октеты_Опрос. Счетчик Октеты_Опрос может также быть сброшен, если бит опроса установлен вследствие других условий опроса, например приема PDU_Опрос.

Когда гибкие размеры PDU RLC поддерживаются для AM RLC, режим гибкого размера PDU RLC устанавливается уровнем RRC и опрос на основе окон конфигурируется верхними уровнями, параметр протокола Окно_Опроса сигнализируется верхними уровнями RLC, чтобы указать передатчику опросить приемник. Окно_Опроса может быть задан в терминах процента окна или в терминах числа байтов. Опрос запускается передатчиком для каждого PDU AMD, когда значение К больше или равно параметру Окно_Опроса, где К - процент окна передачи, определенный как

K = Использованное_Окно/Максимальный_Размер_Окна_Тх (в октетах) Уравнение (6)

где Использованное_Окно - длина в октетах окна, ограниченного переменными состояния VT(A) и VT(S). Использованное_Окно представляет собой используемый буфер данных, находящихся в буфере передачи. Если Окно_Опроса задан в терминах числа байтов, K есть эквивалент Использованное_Окно. Поэтому передатчик запускает запрос опроса, если Использованное_Окно превысит число байтов в Окно_Опроса, сигнализированных сетью.

Передатчик RLC может запустить отчет о состоянии, устанавливая бит опроса, когда используемый/использованный размер окна Tx выше конкретного порога, сконфигурированного системой, в терминах числа байтов или процента от максимального размера окна. Приемник RLC может запустить отчет о состоянии, когда используемый/использованный размер окна Tx выше конкретного порога, сконфигурированного системой, в терминах числа байтов или процента от максимального размера окна. Окно_Опроса указывает, когда передатчик должен опросить приемник в случае, когда "опрос на основе окон" сконфигурирован верхними уровнями. Опрос запускается для каждого PDU AMD, когда значение J больше, чем параметр Окно_Опроса, где J - процент окна передачи, определяемый как

Уравнение (7)

где константа 4096 является модулем для AM, как описано в 3GPP TS 25. 322 V7. 1. 0 подпункт 9. 4 и VT(S) - начальное значение Окно_Опроса до предоставления PDU AMD нижним уровням.

Если гибкий размер PDU RLC сконфигурирован, опрос также запускается для каждого PDU AMD, когда значение K больше, чем параметр Окно_Опроса, где K определено как

Уравнение (8)

Хотя настоящее раскрытие описано в контексте объектов передачи (Tx) RLC и приема (Rx) RLC, оно применимо к нисходящей линии связи (UE к UTRAN/E-UTRAN) и восходящей линии связи (UTRAN/E-UTRAN к UE). Например, в восходящей линии связи, конфигурация/реконфигурация параметра Сконфигурированный_Размер_Окна_Тх вызовет:

• вывод в UE переменной состояния VT(WS) из Сконфигурированный_Размер_Окна_Тх, как описано выше.

• обновление в UE переменной состояния VT(MS), как описано выше.

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

1. Способ улучшения операций управления линией радиосвязи (RLC) в объекте RLC, выполненном с возможностью поддерживать гибкий размер блока пакетных данных (PDU).

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

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

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

5. Способ по любому из предыдущих вариантов осуществления, при этом определение и управление размера окна дополнительно базируется на последовательных номерах блоков пакетных данных (PDU).

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

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

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

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

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

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

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

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

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

15. Способ по варианту осуществления 14, в котором применение метрик размера окна во всем обмене сообщениями таково, что обмен сообщениями включает суперполе Размер Окна (SUFI) в PDU управления и состояния RLC.

16. Способ по любому из вариантов осуществления 14-15, в котором применение метрик размера окна во всем обмене сообщениями таково, что обмен сообщениями включает SUFI Перемещение Окна Приема (MRW) в PDU управления и состояния RLC.

17. Способ по любому из предыдущих вариантов осуществления, при этом объект RLC работает в режиме подтверждения (AM).

18. Способ по варианту осуществления 17, дополнительно содержащий прием элементов информации однонаправленного радиоканала от объекта управления радиоресурсов (RRC), включающих в себя информацию о режиме ВЫБОР нисходящей линии связи RLC, включающую в себя новый индикатор для режима гибкого размера PDU RLC, в дополнение к другим режимам RLC.

19. Способ по любому из вариантов осуществления 17-18, дополнительно содержащий прием элементов информации однонаправленного радиоканала от объекта управления радиоресурсов (RRC), включающих в себя информационный элемент, указывающий режим гибкого размера PDU RLC.

20. Способ по любому из вариантов осуществления 17-19, дополнительно содержащий прием элементов информации однонаправленного радиоканала от объекта управления радиоресурсов (RRC), включающих в себя информацию о размере PDU в нисходящей линии связи RLC, указывающую одно из параметра Масштаба RLC в октетах или максимального размера PDU RLC в режиме гибкого размера PDU RLC.

21. Способ по любому из вариантов осуществления 17-20, дополнительно содержащий прием элементов информации однонаправленного радиоканала от объекта управления радиоресурсов (RRC), включающих в себя параметры протокола, сигнализируемые RRC, включая PDU_Опрос, SDU_Опрос, Сконфигурированный_Размер_Окна_Тх, и Сконфигурированный_Размер_Окна_Rx.

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

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

24. Способ по любому из вариантов осуществления 17-22, дополнительно содержащий прием от объекта RRC суперполя (SUFI) Размер Окна, ссылающегося на величину в октетах в PDU СОСТОЯНИЕ RLC.

25. Способ по варианту осуществления 24, в котором SUFI Размер Окна определяют в числах PDU.

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

27. Способ по варианту осуществления 24, в котором SUFI Размер Окна задается в единицах байтов как новое SUFI БАЙТЫ_ОКНА с элементами тип, длина и значение.

28. Способ улучшения операций управления линией радиосвязи (RLC) в объекте RLC, выполненном с возможностью поддержки гибкого размера блока пакетных данных (PDU) с максимальным размером PDU RLC, включающий в себя выполнение управления потоком данных RLC, используя метрики на основе подсчета байтов.

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

30. Способ по любому из вариантов осуществления 28-29, в котором объект RLC конфигурируют как объект передачи RLC в передатчике, дополнительно содержащий обновление окна передачи RLC после выполнения операции передачи RLC, если один или более PDU были положительно подтверждены приемником.

31. Способ по любому из вариантов осуществления 28-29, в котором объект RLC конфигурируют как объект передачи RLC в передатчике, дополнительно содержащий обновление окна передачи RLC после выполнения операции передачи RLC, если один или более PDU были негативно подтверждены приемником в результате превышения приемником максимального числа повторений.

32. Способ по любому из вариантов осуществления 28-29, в котором объект RLC конфигурируют как объект передачи RLC в передатчике, дополнительно содержащий обновление окна передачи RLC после выполнения операции передачи RLC в результате отбраковки на основе таймера в передатчике.

33. Способ по любому из вариантов осуществления 30-32, в котором обновление окна передачи RLC включает в себя удаление одного или более PDU из используемого окна передачи и увеличение нижней границы используемого окна передачи.

34. Способ по варианту осуществления 33, дополнительно содержащий определение параметра TxWMAX, равного длине в байтах максимального размера окна; TxWUTIL, равного одному из длины в байтах используемого окна передачи или длины в байтах пакетов, которые подтверждены в пределах окна, ограниченного переменными состояния передачи V(A) и V(T); TxL, равного одному из длины в байтах одного или более PDU, которые отбраковываются процедурой отбраковки SDU RLC или длине в байтах при приеме одного или более подтверждений; и TxN, равного длине в байтах следующего одного или более PDU, которые будут переданы впервые.

35. Способ по варианту осуществления 34, дополнительно содержащий вычисление величины длины окна (WL) WL = TxWUTIL - TxL + TxN.

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

37. Способ по любому из вариантов осуществления 28-29, в котором объект RLC конфигурируют как объект приема RLC, дополнительно содержащий обновление окна приема RLC после выполнения операции приема RLC, если объект приема RLC принимает один или более PDU с порядковым номером, следующим за номером последнего последовательно принятого PDU.

38. Способ по вариантам осуществления 28-29, в котором объект RLC конфигурируют как объект приема RLC, дополнительно содержащий обновление окна приема RLC после выполнения операции приема RLC, если объект приема RLC принимает инструкцию Перемещение Окна Приема (MRW) от объекта передачи RLC.

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

40. Способ по варианту осуществления 39, дополнительно содержащий определение параметров: RxWMAX, равного длине в байтах максимального размера окна; RxWUTIL, равного длине в байтах используемого окна приема; RxD, равного длине в байтах одного или более PDU, которые удалены из окна приема RLC вследствие последовательности приема; и RxN, равного длине в байтах следующего одного или более PDU, которые будут приняты впервые.

41. Способ по варианту осуществления 40, дополнительно содержащий вычисление величины длины окна (WL) WL = RxWUTIL + RxN-RxD.

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

43. Способ по любому из вариантов осуществления 28-41, дополнительно содержащий создание PDU RLC в каждый интервал времени посредством определения параметров: Текущий_Кредит, равного объему данных, который может быть передан на основе адаптации линии связи MAC в восходящей линии связи, и результату сложения остающегося распределения кредита и принятого нового распределения кредита в октетах в нисходящей линии связи; Доступные_Данные, равного данным, доступным для передачи PDU RLC, форматированных в октетах; Неиспользованное_Окно, равного длине окна, ограниченного переменными состояния VT(S) и VT(MS) в передатчике RLC, представленной в октетах; Максимальный_Размер_PDU_RLC, равного максимальному размеру PDU RLC, как сконфигурировано верхними уровнями; и Минимальный_Размер_PDU_RLC, равного параметру, сконфигурированному верхними уровнями, который определяет минимальный размер PDU RLC или минимальный размер полезной нагрузки PDU RLC.

44. Способ по варианту осуществления 43, дополнительно содержащий вычисление параметра X = Min {Текущий_Кредит, Доступные_Данные, Неиспользованное_Окно}, где

Min {•} возвращает минимальное значение из набора.

45. Способ по любому из вариантов осуществления 43-44, дополнительно содержащий вычисление параметра N = Floor {X/Максимальный_Размер_PDU_RLC), в котором Floor {•} возвращает ближайшее низшее целочисленное значение и a mod b.

46. Способ по любому из вариантов осуществления 43-45, дополнительно содержащий вычисление L=X mod Максимальный_Размер_PDU_RLC, в котором возвращается остаток от целочисленного деления а по модулю b.

47. Способ по любому из вариантов осуществления 45-46, дополнительно содержащий генерацию N PDU с длиной, равной Максимальный_Размер_PDU_RLC.

48. Способ по варианту осуществления 47, дополнительно содержащий генерацию другого PDU RLC длины L, если X не равно Неиспользованное_Окно или Текущий_Кредит.

49. Способ как в любом из вариантов осуществления 47-48, дополнительно содержащий генерацию другого PDU RLC длины L, если X равно Неиспользованное_Окно или Текущий_Кредит и L больше, чем Минимальный_Размер_PDU_RLC, или если X равно Доступные_Данные.

50. Способ по любому из вариантов осуществления 47-49, дополнительно содержащий генерацию другого PDU RLC с длиной Минимальный_Размер_PDU_RLC, если X равно Неиспользованное_Окно или Текущий_Кредит и L не больше Минимальный_Размер_PDU_RLC.

51. Способ по любому из вариантов осуществления 47-50, дополнительно содержащий сохранение сгенерированных PDU RLC в буфере для передачи.

52. Способ по любому из вариантов осуществления 43-51, в котором интервал времени определяется умножением интервала времени передачи (TTI) на 1 или кратное.

53. Способ по любому из вариантов осуществления 43-51, в котором интервал времени определяется моментами времени, когда данные доступны для передачи или запрашиваются из нижних уровней.

54. Способ по любому из вариантов осуществления 43-53, в котором Максимальный_Размер_PDU_RLC и Минимальный_Размер_PDU_RLC не конфигурируются верхними уровнями.

55. Способ по любому из вариантов осуществления 28-54, дополнительно содержащий поддержку переменных состояния, причем переменные состояния задаются и интерпретируются в терминах числа PDU и единиц байтов.

56. Способ по варианту осуществления 55, в котором объект RLC конфигурируют как объект передачи RLC, содержащий поддержку переменной состояния Максимальный_Размер_Окна_Тх, представляющую максимальный размер окна передачи в октетах.

57. Способ по варианту осуществления 56, дополнительно содержащий обновление переменной состояния Максимальный_Размер_Окна_Тх до количества октет, заданного суперполем (SUFI) Размер Окна в принятом PDU состояния RLC.

58. Способ по любому из вариантов осуществления 56-57, дополнительно содержащий поддержку следующих переменных состояния: переменная состояния отправка VT(S), переменная состояния подтверждение VT(A), переменная состояния максимальная отправка VT(MS) и переменная состояния размер окна передачи VT(WS).

59. Способ по варианту осуществления 58, дополнительно содержащий обновление переменных состояния VT(S), VT(A), VT(MS) и VT(WS), основанное на переменной состояния Максимальный_Размер_Окна_Тх в октетах.

60. Способ по варианту осуществления 55, в котором объект RLC конфигурируют как объект приема RLC, содержащий поддержку переменной состояния Максимальный_Размер_Окна_Rx, представляющей максимальный размер окна приема в октетах.

61. Способ по варианту осуществления 60, дополнительно содержащий прием переменной состояния Максимальный_Размер_Окна_Rx от верхних уровней.

62. Способ по варианту осуществления 61, дополнительно содержащий поддержку следующих переменных состояния: переменной состояния прием VR(R), переменной состояния наивысший ожидаемый VR(H) и переменной состояния максимально допустимый прием VR(MR).

63. Способ по варианту осуществления 62, дополнительно содержащий обновление переменных состояния VR(R), VR(H) и VR(MR), основанное на переменной состояния Максимальный_Размер_Окна_Rx в октетах.

64. Способ по любому из вариантов осуществления 28-63, дополнительно содержащий определение и управление механизмами опроса RLC, использующими метрики на основе подсчета байтов.

65. Способ по варианту осуществления 64, дополнительно содержащий определение параметра Текущий_Кредит, равного количеству данных, которое может быть передано на основе адаптации линии связи MAC в восходящей линии связи, и результату сложения остающегося распределения кредита и принятого нового распределения кредита в октетах в нисходящей линии связи; Доступные_Данные, равного данным, доступным для передачи в октетах в формате RLC PDU; Неиспользованное_Окно, равного длине окна, ограниченного переменными состояниями VT(S) и VT(MS) в передатчике RLC, представленного в октетах.

66. Способ по варианту осуществления 65, дополнительно содержащий вычисление параметра X = Min [Текущий_Кредит, Доступные_Данные, Неиспользованное_Окно}.

67. Способ по варианту осуществления 66, дополнительно содержащий запуск опроса в PDU режима подтверждения данных (AMD), когда используемый размер окна в октетах больше, чем X.

68. Способ по любому из вариантов осуществления 28-67, дополнительно содержащий запуск опроса в PDU AMD каждый раз, когда общая сумма переданных данных превышает известное предопределенное количество октетов или блоков данных.

69. Способ по варианту осуществления 68, дополнительно содержащий использование параметра протокола Окно_Опроса для опроса приемника, когда опрос на основе окон конфигурируется верхними уровнями.

70. Способ по варианту осуществления 68, дополнительно содержащий запуск опроса для каждого PDU режима подтверждения данных (AMD), когда процент окна передачи K больше или равен Окно_Опроса, где K определен как K = Использованное_Окно/Максимальный_Размер_Окна_Тх в октетах, где Использованное_Окно - длина в октетах окна, ограниченного переменными состояниями VT(A) и VT(S).

71. Способ по любому из вариантов осуществления 28-70, в котором параметры протокола PDU_Опрос и SDU_Опрос принимаются в объекте передачи RLC от верхних уровней для указания интервала подсчета PDU.

72. Способ по любому из вариантов осуществления 28-71, в котором параметр протокола Байты_Опроса в октетах конфигурирован для указания интервала подсчета байтов между опросами.

73. Способ по варианту осуществления 72, дополнительно содержащий поддержку объектом передачи RLC счетчика переменной Октеты_Опрос общего количества байтов переданных в PDU, начиная с передачи последнего PDU, запустившего запрос опроса.

74. Способ по варианту осуществления 72, дополнительно содержащий запуск объектом передачи RLC запроса опроса в PDU, сделавшего счетчик Октеты_Опрос выше, чем Байты_Опроса, и сброс счетчика Октеты_Опрос, когда счетчик Октеты_Опрос становится больше или равен значению Байты_Опроса.

75. Способ по любому из вариантов осуществления 73-74, в котором счетчик Октеты_Опрос считает общее количество байтов первых переданных PDU.

76. Способ по любому из вариантов осуществления 73-74, в котором счетчик Октеты_Опрос считает общее количество байтов всех переданных PDU, включая повторные передачи.

77. Способ по любому из вариантов осуществления 73-76, в котором запуск запроса опроса включает в себя установку бита опроса в PDU, сделавшего счетчик Октеты_Опрос выше, чем Байты_Опроса.

78. Способ по любому из вариантов осуществления 73-76, в котором запуск запроса опроса включает в себя отправку PDU ОПРОС в приемник.

79. Способ по варианту осуществления 78, в котором последний PDU, запустивший запрос опроса, обусловлен механизмом Байты_Опроса.

80. Способ по варианту осуществления 78, в котором последний PDU, запустивший запрос опроса, обусловлен PDU_Опрос или SDU_Опрос.

81. Способ по любому из вариантов осуществления 67-68, в котором параметр протокола Окно_Опроса принимают в объекте передачи RLC от верхних уровней.

82. Способ по варианту осуществления 81, дополнительно содержащий использование Окно_Опроса для опроса приемника, когда опрос на основе окон конфигурируется посредством верхних уровней.

83. Способ по варианту осуществления 82, дополнительно содержащий запуск опроса передатчиком для каждого PDU режима подтверждения данных (AMD), когда значение J больше, чем или равно Окно_Опроса, где J определяют как

где 4096 является модулем для режима подтверждения (AM) и VT(S), VT(A) и VT(WS) являются переменными состояния.

84. Способ по варианту осуществления 83, дополнительно содержащий запуск опроса для каждого PDU AMD, когда значение K больше или равно Окно_Опроса, где K определяют как

85. Способ по любому из предыдущих вариантов осуществления, выполняемый объектом RLC.

86. Беспроводной модуль приема/передачи (WTRU), содержащий объект RLC по варианту осуществления 85.

87. Узел B, содержащий объект RLC по варианту осуществления 85.

88. Контроллер радиосети (RNC), содержащий объект RLC по варианту осуществления 85.

89. Способ управления потоком нисходящей линии связи для контроллера радиосети (RNC)/Узла B, в котором поддерживают гибкий размер блока пакетных данных (PDU) управления линией радиосвязи (RLC), содержащий сигнализацию распределений кредитов в байтах.

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

91. Способ по любому из вариантов осуществления 89-90, дополнительно содержащий исключение информации кадра, задающей число PDU кредита.

92. Способ по любому из вариантов осуществления 89-91, выполняемый объектом RLC.

93. Узел B, содержащий объект RLC по варианту осуществления 92.

94. Способ управления потоком данных нисходящей линии связи для (RNC)/Узла B, в котором поддерживают гибкий размер блока пакетных данных (PDU) управления линией радиосвязи (RLC), содержащий прием распределения кредита в байтах.

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

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

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

99. Способ по любому из вариантов осуществления 94-98, дополнительно содержащий сохранение отображения SN PDU на ассоциированную длину в байтах.

100. Способ по варианту осуществления 99, дополнительно содержащий передачу PDU без превышения принятых распределений кредита.

101. Способ по любому из вариантов осуществления 94-100, выполняемый объектом RLC.

102. Контроллер радиосети (RNC), содержащий объект RLC по варианту осуществления 101.

103. RNC варианта осуществления 102, выполненный как обслуживающий RNC (SRNC).

104. RNC варианта осуществления 102, выполненный как дрейфовый RNC (DRNC).

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

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

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

Изобретение относится к системам связи. Технический результат заключается в повышении эффективности обработки блоков пакетных данных (PDU) переменного размера протокола управления линией радиосвязи (RLC) в системах беспроводной связи. Когда гибкие размеры PDU RLC конфигурируются верхними уровнями, управление потоком контроллера радиосети (RNC)/Узла В, управление потоком RLC, отчеты о состоянии и механизмы опроса конфигурируются с возможностью использования метрик на основе подсчета байтов для предотвращения возможных недозаполнений буфера в Узле В и переполнений буфера в RNC. Предложенные улучшения для RLC применяются к обмену данными и по восходящей, и по нисходящей линиям связи. 2 н. и 14 з.п. ф-лы, 5 ил.

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

2. Способ по п.1, в котором кредит является числом PDU.

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

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

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

6. Способ по п.1, в котором упомянутое определение выполняется контроллером радиосети (RNC).

7. Способ по п.6, в котором RNC является обслуживающим RNC (SRNC).

8. Способ по п.6, в котором RNC является дрейфовым RNC (DRNC).

9. Сетевой объект, содержащий:
приемник, сконфигурированный с возможностью принимать индикатор того, что сконфигурирован гибкий размер блока пакетных данных (PDU); и
процессор, сконфигурированный с возможностью определять распределение пропускной способности посредством умножения кредита на максимальный размер PDU.

10. Сетевой объект по п.9, в котором кредит является числом PDU.

11. Сетевой объект по п.9, в котором распределение пропускной способности вычисляется как число октетов.

12. Сетевой объект по п.9, в котором приемник дополнительно сконфигурирован с возможностью приема кадра, содержащего информацию, задающую число байтов кредита.

13. Сетевой объект по п.12, в котором процессор дополнительно сконфигурирован с возможностью:
сохранять отображение порядкового номера (SN) PDU на ассоциированную длину в байтах; и
передавать PDU без превышения числа байтов кредита.

14. Сетевой объект по п.9, в котором упомянутое определение выполняется с помощью контроллера радиосети (RNC).

15. Сетевой объект по п.14, в котором RNC является обслуживающим NRC (SRNC).

16. Сетевой объект по п.14, в котором RNC является дрейфовым RNC (DRNC).