Способ и устройство улучшения rlc для гибкого размера pdu rlc

Способ и устройство улучшения rlc для гибкого размера pdu rlc

Иллюстрации

Показать все

Реферат

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

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

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

Развитие высокоскоростного пакетного доступа (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 больше, чем Ми