Результат интеллектуальной деятельности: ОБРАТНО СОВМЕСТИМЫЙ ПОДХОД К ПОЛЯМ УРОВНЯ ПРОТОКОЛА

РОДСТВЕННАЯ ЗАЯВКА

Данная заявка испрашивает приоритет и преимущество предварительной заявки США № 61/442492, озаглавленной "BACKWARDS-COMPATIBLE APPROACH TO EXTEND LENGTH AND SEQUENCE NUMBER FIELDS", поданной 14 февраля 2011 г., которая полностью включается в этот документ посредством ссылки.

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

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

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

Примеры стеков протоколов LTE (Проект долгосрочного развития) в 3GPP (Проект партнерства 3^го поколения) для плоскостей управления и пользователя иллюстрируются на фиг. 1. Один или несколько этих уровней реализуются в узлах в LTE. Например, в типичном UE (пользовательское оборудование) реализуются все уровни стеков протоколов плоскости управления и пользователя. В типичном eNB (или в более общем смысле - сетевом узле) реализуются все уровни протокола плоскости пользователя и все уровни протокола плоскости управления, за исключением уровня NAS.

В соответствии с 3GPP недавно заданы новые категории UE в LTE Rel-10, так что скоростей передачи данных вплоть до 3 и 1,5 Гбит/с можно достичь соответственно в нисходящей линии связи и восходящей линии связи. Это обеспечивается путем увеличения количества уровней для пространственного мультиплексирования и количества несущих, которое может конфигурироваться для одного UE. При этих улучшениях максимальный размер транспортного блока (TB) увеличивается до 299852 битов (37482 октетов) на физическом уровне (PHY), а количество транспортных блоков, которое можно отправить в одном субкадре, увеличивается до 10.

Однако форматы протокола плоскости пользователя, заданные для LTE Rel-8/9, не полностью поддерживают передачу на высоких скоростях передачи данных, предлагаемых усовершенствованным физическим уровнем. Это применяется ко всем трем подуровням уровня L2 (канального), то есть уровню MAC (Управление доступом к среде передачи), уровню RLC (Управление радиосвязью) и уровню PDCP (Протокол конвергенции пакетных данных).

Размер SDU (Блок служебных данных) MAC, заключенного в PDU (протокольный блок данных) MAC, может сигнализироваться в поле длины (L) подзаголовка MAC, исключая случай, когда SDU MAC включается последним в PDU MAC (то есть без каких-либо последующих данных, управления или заполнения), для которого поле L не включается. Примеры структур существующего подзаголовка MAC иллюстрируются на фиг. 2A, 2B и 2C.

Подзаголовок MAC включает в себя два зарезервированных бита (R), 1-битное поле расширения (E) и 5-битное поле логического канала (LCID). Поле E используется для указания, присутствуют ли еще поля в подзаголовке MAC. Когда поле E не задано, подзаголовок MAC включает в себя поля R/R/E/LCID, как проиллюстрировано на фиг. 2C. Последний подзаголовок в PDU MAC и подзаголовки для элементов управления MAC фиксированного размера соответствуют этой структуре.

Для других SDU MAC, то есть когда задается поле E, соответствующий подзаголовок MAC также включает в себя 1-битное поле формата (F) и 7- и 15-битное поле L, как проиллюстрировано на фиг. 2A и 2B соответственно. То есть, когда задается поле E, подзаголовок MAC включает в себя поля R/R/E/LCID/F/L. Поле F указывает размер поля L. Когда задается поле F, размер поля L равен 15 битам, как проиллюстрировано на фиг. 2B, а когда поле F не задается, размер поля L равен 7 битам, как проиллюстрировано на фиг. 2A.

Как проиллюстрировано на фиг. 3, PDU MAC включает в себя заголовок MAC, ноль или более элементов управления MAC, ноль или более SDU MAC и необязательное заполнение. Заголовок PDU MAC включает в себя один или несколько подзаголовков MAC, в которых каждый подзаголовок MAC соответствует одному из SDU MAC, элемента управления или заполнения. Весь PDU MAC - заголовок, элементы управления, SDU и заполнение - перемещается в транспортном блоке физического уровня (L1).

Ссылаясь снова на фиг. 2A-2C, отметим, что поле L имеет длину не более 15 битов. Таким образом, максимальный поддерживаемый размер SDU MAC, включая поле L, составляет 32767 октетов. Поле L включается во все PDU MAC, имеющие больше одного подзаголовка MAC. Например, если PDU MAC включает в себя больше 2 октетов заполнения в дополнение к данным, то размер SDU MAC для данных нужно указывать с помощью поля L. В соответствии со спецификацией Rel-8/9 каждое кодовое слово L1 содержит ровно один PDU MAC (транспортный блок). Учитывая ограничения поля L, уровень MAC не может заполнить PDU MAC одним SDU MAC для данных. С другой стороны, не разрешено наличие нескольких SDU MAC для новых данных на каждый логический канал и на каждый транспортный блок. При этих ограничениях следствием является то, что уровень MAC не может использовать большие транспортные форматы, предлагаемые физическим уровнем.

В некоторых системах, поддерживающих RLC, каждый из SDU RLC в PDU RLC ассоциируется с 11-битным полем индикатора длины "LI". Это ограничивает возможность объединения, когда SDU RLC или оставшаяся часть сегментированного SDU RLC превышает 2047 октетов. Последний SDU RLC не содержит поля LI и поэтому ограничивается только максимальным размером PDU RLC. Если объединение SDU RLC невозможно, то уровень RLC вместо этого может сформировать несколько PDU RLC. К сожалению, это расходует больше SN (порядковые номера) RLC.

Это может быть проблематичным, поскольку SN RLC является 10-битным полем (1024 значения), что ограничивает используемый размер окна до 511 PDU RLC. То есть передатчик RLC может сформировать и передать вплоть до 511 PDU RLC перед приемом кумулятивного сообщения о состоянии. Как будет обсуждаться позднее, это становится особенно ограничивающим, когда объединение SDU RLC невозможно. Кроме того, размер PDU RLC ограничивается полями SO (смещение сегментации) RLC - SOstart и SOend - которые имеют по 15 битов каждое. Таким образом, размер PDU RLC ограничивается максимальным размером SDU MAC с полем L.

PDCP поддерживает SDU PDCP вплоть до 8188 октетов по размеру, что приводит к максимальному размеру PDU данных PDCP в 8190 октетов, включая заголовок. Отметим, что размер PDCP SDU может ограничиваться только сверху, но едва ли возможно принудительно задать нижний предел. Типичные размеры SDU PDCP (например, IP-пакета) составляют около 1500 октетов. Дополнительно следует отметить, что PDU PDCP, превышающие 2047 октетов, требуют особой обработки на уровне RLC, как указано выше.

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

Неограничивающий аспект раскрытого объекта изобретения ориентирован на способ, выполняемый на сетевом узле беспроводной сети. Базовая станция является примером сетевого узла. Способ содержит определение, использовать ли расширенный заголовок для уровня протокола при беспроводной связи с мобильным терминалом. Уровень протокола может быть уровнем выше физического (L1) уровня. Способ также содержит использование расширенного заголовка для уровня протокола при передаче и приеме протокольного блока данных (PDU) уровня протокола, когда определяется, что нужно использовать расширенный заголовок. Расширенный заголовок содержит унаследованное поле индикатора (L-I) с заранее установленным количеством битов индикатора для использования при указании значения характеристики PDU. Может иметь место унаследованное пороговое значение индикатора, ассоциированное с характеристикой, причем унаследованное пороговое значение индикатора является максимальным значением характеристики, которое может указываться унаследованным полем L-I индикатора. Расширенный заголовок содержит расширенное поле индикатора (E-I), которое может логически объединяться с унаследованным полем L-I индикатора, так что объединение E-I/L-I содержит достаточное количество битов для задания значения характеристики PDU за пределами унаследованного порогового значения индикатора.

Другой неограничивающий аспект раскрытого объекта изобретения ориентирован на способ, выполняемый на мобильном терминале беспроводной сети. Пользовательское оборудование является примером сетевого узла. Способ содержит определение, использовать ли расширенный заголовок для уровня протокола при беспроводной связи с сетевым узлом. Уровень протокола может быть уровнем выше физического (L1) уровня. Способ также содержит использование расширенного заголовка для уровня протокола при передаче и приеме протокольного блока данных (PDU) уровня протокола, когда определяется, что нужно использовать расширенный заголовок. Расширенный заголовок содержит унаследованное поле индикатора (L-I) с заранее установленным количеством битов индикатора для использования при указании значения характеристики PDU. Может иметь место унаследованное пороговое значение индикатора, ассоциированное с характеристикой, причем унаследованное пороговое значение индикатора является максимальным значением характеристики, которое может указываться унаследованным полем L-I индикатора. Расширенный заголовок содержит расширенное поле индикатора (E-I), которое может логически объединяться с унаследованным полем L-I индикатора, так что объединение E-I/L-I содержит достаточное количество битов для задания значения характеристики PDU за пределами унаследованного порогового значения индикатора.

Другой неограничивающий аспект раскрытого объекта изобретения ориентирован на сетевой узел, например базовую станцию беспроводной сети. Сетевой узел содержит множество блоков уровня протокола, структурированных для связи с мобильным терминалом. Множество блоков уровня протокола содержит блок RRC, структурированный для выполнения функций, ассоциированных с уровнем RRC, блок PDCP, структурированный для выполнения функций, ассоциированных с уровнем PDCP, блок RLC, структурированный для выполнения функций, ассоциированных с уровнем RLC, и блок MAC, структурированный для выполнения функций, ассоциированных с уровнем MAC. По меньшей мере один блок уровня протокола структурирован для определения, использовать ли расширенный заголовок для уровня протокола при беспроводной связи с мобильным терминалом, и для использования расширенного заголовка для уровня протокола при передаче и приеме протокольного блока данных (PDU) уровня протокола. Уровень протокола может быть уровнем выше физического (L1) уровня. Расширенный заголовок содержит унаследованное поле индикатора (L-I) с заранее установленным количеством битов индикатора для использования при указании значения характеристики PDU. Может иметь место унаследованное пороговое значение индикатора, ассоциированное с характеристикой, причем унаследованное пороговое значение индикатора является максимальным значением характеристики, которое может указываться унаследованным полем L-I индикатора. Расширенный заголовок содержит расширенное поле индикатора (E-I), которое может логически объединяться с унаследованным полем L-I индикатора, так что объединение E-I/L-I содержит достаточное количество битов для задания значения характеристики PDU за пределами унаследованного порогового значения индикатора.

Другой неограничивающий аспект раскрытого объекта изобретения ориентирован на мобильный терминал, например пользовательское оборудование в беспроводной сети. Мобильный терминал содержит множество блоков уровня протокола, структурированных для связи с сетевым узлом. Множество блоков уровня протокола содержит блок RRC, структурированный для выполнения функций, ассоциированных с уровнем RRC, блок PDCP, структурированный для выполнения функций, ассоциированных с уровнем PDCP, блок RLC, структурированный для выполнения функций, ассоциированных с уровнем RLC, и блок MAC, структурированный для выполнения функций, ассоциированных с уровнем MAC. По меньшей мере один блок уровня протокола структурирован для определения, использовать ли расширенный заголовок для уровня протокола при беспроводной связи с сетевым узлом, и для использования расширенного заголовка для уровня протокола при передаче и приеме протокольного блока данных (PDU) уровня протокола. Уровень протокола может быть уровнем выше физического (L1) уровня. Расширенный заголовок содержит унаследованное поле индикатора (L-I) с заранее установленным количеством битов индикатора для использования при указании значения характеристики PDU. Может иметь место унаследованное пороговое значение индикатора, ассоциированное с характеристикой, причем унаследованное пороговое значение индикатора является максимальным значением характеристики, которое может указываться унаследованным полем L-I индикатора. Расширенный заголовок содержит расширенное поле индикатора (E-I), которое может логически объединяться с унаследованным полем L-I индикатора, так что объединение E-I/L-I содержит достаточное количество битов для задания значения характеристики PDU за пределами унаследованного порогового значения индикатора.

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

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

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

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

Фиг. 1 иллюстрирует примерный стек протоколов LTE для плоскостей управления и пользователя;

Фиг. 2A, 2B и 2C иллюстрируют соответственно унаследованные подзаголовки MAC с полем L длины из 7 битов, 15 битов и для элементов управления MAC фиксированного размера;

Фиг. 3 иллюстрирует пример унаследованного PDU MAC;

Фиг. 4 иллюстрирует вариант осуществления узлов передатчика и приемника в беспроводной сети;

Фиг. 5 иллюстрирует вариант осуществления мобильного терминала;

Фиг. 6 иллюстрирует вариант осуществления сетевого узла в беспроводной сети;

Фиг. 7A и 7B иллюстрируют примеры расширенных подзаголовков MAC;

Фиг. 8 иллюстрирует примерный PDU MAC с расширенным заголовком MAC;

Фиг. 9A и 9B иллюстрируют дополнительные примеры расширенных подзаголовков MAC;

Фиг. 10 иллюстрирует примерный способ для управления сетевым узлом в беспроводной сети;

Фиг. 11 иллюстрирует примерный процесс для определения, использовать ли расширенный заголовок уровня протокола на сетевом узле;

Фиг. 12 иллюстрирует другой примерный процесс для определения, использовать ли расширенный заголовок уровня протокола на сетевом узле;

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

Фиг. 14 иллюстрирует примерный способ для управления мобильным терминалом в беспроводной сети; и

Фиг. 15 иллюстрирует примерный процесс для определения, использовать ли расширенный заголовок уровня протокола на мобильном терминале.

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

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

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

Таким образом, например, нужно будет принять во внимание, что блок-схемы в этом документе могут представлять концептуальные представления пояснительных схем, воплощающих принципы этой технологии. Аналогично должно быть принято во внимание, что любые блок-схемы алгоритмов, диаграммы переходов, псевдокод и тому подобное представляют различные процессы, которые большей частью могут быть представлены на машиночитаемом носителе и могут выполняться компьютером или процессором независимо от того, показан ли явно такой компьютер или процессор.

Функции различных элементов, включающих в себя функциональные блоки, обозначенные или описанные как "процессоры" или "контроллеры", могут обеспечиваться посредством специализированных аппаратных средств, а также аппаратных средств, допускающих выполнение ассоциированного программного обеспечения. Будучи обеспеченными процессором, функции могут предоставляться единственным специализированным процессором, единственным общим процессором или множеством отдельных процессоров, некоторые из которых могут быть совместно используемыми или распределенными. Более того, явное использование термина "процессор" или "контроллер" не следует толковать исключительно для ссылки на аппаратные средства, допускающие выполнение программного обеспечения, и может включать в себя без ограничения оборудование с цифровым процессором сигналов (сокращенно "DSP"), постоянное запоминающее устройство (сокращенно "ROM") для хранения программного обеспечения, оперативное запоминающее устройство (сокращенно "RAM") и энергонезависимое запоминающее устройство.

В этом раскрытии изобретения 3GPP в основном используется в качестве примеров с целью объяснения. Однако, объем этого раскрытия изобретения не ограничивается набором систем беспроводных сетей 3GPP и может включать в себя много областей систем беспроводных сетей. Также базовая станция (например RBS, Узел Б, eNB) будет использоваться в качестве примера узла, который включает в себя один или несколько блоков канального уровня, в которых может выполняться описанный способ, чтобы отдать предпочтение измерениям. Однако следует отметить, что раскрытый объект изобретения применим к блокам канального уровня любого узла в сети, такого как мобильный терминал (например, UE).

В этом раскрытии изобретения будут использоваться термины "унаследованный" и "усовершенствованный". Контекст, в котором используются эти термины, предназначен, чтобы разъяснить значения. Таким образом, фиг. 2A, 2B и 2C могут описываться как показывающие примеры структур унаследованного подзаголовка MAC.

Как указывалось ранее, структуры существующего подзаголовка канальных уровней, например MAC, RLC, PDCP, могут не подходить для больших транспортных форматов, предлагаемых нижними уровнями. Это может вызывать проблемы на уровне MAC. Например, если размер транспортного блока, предоставленного физическим уровнем, больше 32767 октетов, то есть если физический уровень предоставляет усовершенствованный TB, то унаследованный уровень MAC не может заполнить усовершенствованный TB одним SDU MAC для одного логического канала, что может привести к чрезмерному заполнению.

Проблемы могут возникать на уровне RLC из-за неспособности унаследованного уровня MAC использовать усовершенствованный TB. Например, наличие нескольких SDU MAC на каждый PDU MAC с тем же успехом может привести к нескольким PDU RLC. Но в целом подразумевается, что намерением протоколов MAC/RLC было иметь только один новый PDU RLC на каждый логический канал на каждый TB.

Наличие многих PDU RLC, сформированных на каждый TB и субкадр, также может привести к нехватке порядковых номеров RLC. Например, предположим, что формируются два новых PDU RLC на каждую компонентную несущую и на каждый TB, соответственно приводя к 20 PDU RLC на каждый субкадр (5 обслуживающих сот с двумя или более кодовыми словами (MIMO) в каждой). В результате пространство порядковых номеров RLC занимается за 511/20≈25 миллисекунд. Это означает, что передатчик RLC может отправить новые данные только в течение 3 RTT HARQ (Периоды приема-передачи гибридного автоматического запроса на повторение) перед исчерпанием порядковых номеров RLC. Если отчет о состоянии RLC, подтверждающий самые старые PDU RLC, ожидающие выполнения, еще не принят к тому времени, то протокол RLC останавливается. Это означает, что уровень RLC не может предоставить новые данные нижним уровням, что в свою очередь вызывает недоиспользование назначенных радиоресурсов, и максимальные скорости передачи данных, заданные для усовершенствованного TB, например, Rel-10 в LTE, не будут достигнуты.

На уровне PDCP можно запустить 2048 PDU PDCP при текущем пространстве порядковых номеров PDCP. При размере IP-пакета в 1500 байт это соответствует ~3 Мбайт. С предполагаемым RTT PDCP в 25 мс это ограничивает теоретическую пропускную способность приблизительно до 980 Мбит/с (3 Мбайт x 8 битов/байт/0,025 с). Это значительно ниже пиковой скорости, обеспечиваемой физическим уровнем в LTE Rel-10. Отметим, что невозможно или по меньшей мере не рекомендуется запускать более 2048 PDU PDCP, чтобы избежать неопределенности во время передачи обслуживания. Если пакеты PDCP нельзя однозначно идентифицировать во время передачи обслуживания, то может возникнуть потеря данных и десинхронизация HFN (Номер гиперкадра), приводящие к значительному ухудшению производительности.

В неограничивающем аспекте настоящего раскрытия изобретения решаются вышеописанные и другие проблемы, ассоциированные с унаследованными системами. Предоставляются обратно совместимые способ (способы), блок (блоки) и/или система (системы) для расширения одного или нескольких полей заголовка протокола. Примеры таких полей включают в себя длину и порядковые номера. Для каждого унаследованного поля, которое нужно расширить, расширение не обязательно достигается путем непосредственного расширения поля побитово-смежным способом. То есть существующее унаследованное поле, намеченное для расширения, не обязательно расширяется само. Вместо этого унаследованное поле логически объединяется с другими полями в структуре заголовка.

В другом неограничивающем аспекте способ (способы), блок (блоки) и/или система (системы) предоставляются для обеспечения эффективной передачи данных (с низкой служебной нагрузкой) для сценариев, где TB являются небольшими (например, низкоскоростные услуги или плохое покрытие), и для управления тем, используются ли передатчиком обычные (не расширенные) или расширенные поля. В некоторых аспектах использование расширений полей заголовка выбирается динамически, например, на основе текущего размера транспортного блока физического (L1) уровня. В некоторых других аспектах использование полустатистически конфигурируется верхними уровнями, например RRC. Описанные аспекты гарантируют, что приемник в любой момент времени знает формат полей, используемых передатчиком, то есть приемнику было бы известно, расширены поля или нет.

Фиг. 4 иллюстрирует вариант осуществления передатчика 400-T и приемника 400-R в беспроводной сети. Каждый из передатчика 400-T и приемника 400-R включает в себя блок 420 RRC (управление радиоресурсами), блок 430 PDCP, блок 440 RLC, блок 450 MAC и блок 460 PHY, каждый из которых структурирован для выполнения функций уровней RRC, PDCP, RLC, MAC и PHY протокола соответственно. Дополнительные подробности об этих блоках будут предоставлены в сочетании с описаниями одного или нескольких способов предоставления обратно совместимых подходов к полям уровней протокола.

Отметим, что фиг. 4 является логическим представлением передатчика 400-T и приемника 400-R. Таким образом, каждый из блока 420 RRC, блока 430 PDCP, блока 440 RLC, блока 450 MAC и блока 460 PHY не должен быть физически отдельным от каждого из других блоков. Всецело предполагается, что любая комбинация блоков может быть объединено в одно физическое устройство. Кроме того, каждый из блоков может быть реализован в нескольких физических компонентах, функционально структурированных и соединенных друг с другом для выполнения соответствующей функции блока. Кроме того, в той части, в какой некоторые из блоков совместно используют общие признаки, несколько блоков могут совместно использовать общие компоненты.

Хотя и не показано явно, также предполагается, что один или оба из передатчика 400-T и приемника 400-R в целом могут быть реализованы в виде комбинации аппаратных и программных компонентов. Например, передатчик 400-T и/или приемник 400-R может включать в себя один или несколько процессоров, которые, как описано выше, сами могут быть комбинациями аппаратных средств и программного обеспечения, структурированными для выполнения функций, ассоциированных с блоками.

Также следует отметить, что узел беспроводной сети может функционировать как передатчик 400-T, а также как приемник 400-R. Например, фиг. 5 иллюстрирует вариант осуществления мобильного терминала 500 (например, UE), который включает в себя процессор 510, структурированный для управления общим процессом мобильного терминала 500, запоминающее устройство 520, структурированное для хранения и выборки данных и команд, и приемопередатчик 530 для обработки сигналов, принятых одной или несколькими антеннами 540, и для обработки сигналов, которые нужно передать от одной или нескольких антенн 540. Мобильный терминал 500 функционирует в качестве передатчика 400-T на восходящей линии связи и в качестве приемника 400-R на нисходящей линии связи.

Хотя и не показано, мобильный терминал 500 может включать в себя один или несколько из блока 420 RRC, блока 430 PDCP, блока 440 RLC, блока 450 MAC и блока 460 PHY, проиллюстрированных на фиг. 4. Один или несколько блоков из фиг. 4 также могут быть реализованы посредством комбинации аппаратных средств и программного обеспечения. Например, процессор 510 может исполнять команды программирования, сохраненные на неизменяемом со временем (невременном) машиночитаемом носителе, например запоминающем устройстве 520, чтобы выполнять функции блоков. Команды программирования также могут приниматься не постоянным во времени способом и сохраняться на неизменяемом со временем машиночитаемом носителе, доступном мобильному терминалу 500. Например, можно сохранять и принимать обновления.

В качестве другого примера фиг. 6 иллюстрирует вариант осуществления сетевого узла 600, например базовой станции (например, eNB) в беспроводной сети. Сетевой узел 600 включает в себя процессор 610, структурированный для управления общим процессом сетевого узла 600, запоминающее устройство 620, структурированное для хранения и выборки данных и команд, приемопередатчик 630 для обработки сигналов, принятых одной или несколькими антеннами 640, и для обработки сигналов, которые нужно передать от одной или нескольких антенн 640, и сетевой интерфейс 650, структурированный для взаимодействия с узлами базовой сети. Во время нисходящей линии связи сетевой узел 600 функционирует в качестве передатчика 400-T, а во время восходящей линии связи сетевой узел 600 функционирует в качестве приемника 400-R.

Хотя и не показано, сетевой узел 600 может включать в себя один или несколько из блока 420 RRC, блока 430 PDCP, блока 440 RLC, блока 450 MAC и блока 460 PHY, проиллюстрированных на фиг. 4. Один или несколько блоков из фиг. 4 также могут быть реализованы посредством комбинации аппаратных средств и программного обеспечения. Например, процессор 610 может исполнять команды программирования, сохраненные на неизменяемом со временем машиночитаемом носителе, например запоминающем устройстве 620, чтобы выполнять функции блоков. Команды программирования также могут приниматься промежуточным способом и сохраняться на неизменяемом со временем машиночитаемом носителе, доступном сетевому узлу 600. Например, можно сохранять и принимать обновления.

Ссылаясь снова на фиг. 4, блоки передатчика 400-T и/или приемника 400-R могут выполнять способ, который обеспечивает обратную совместимость с уровнями протокола. Когда нужен один или несколько бит для поля заголовка, например, полей длины или полей порядкового номера, традиционный подход состоит в добавлении битов к существующему полю. Но если нет неиспользуемых (зарезервированных) битов на любой стороне поля заголовка или если рассматриваемое поле заголовка не является последним полем заголовка в заголовке, то соседние поля заголовка нужно сдвигать в направлении неиспользуемого бита или добавленных битов. Недостаток этого подхода состоит в том, что поля заголовка, которые были выровнены по октету (см. поле LCID на фиг. 2A, 2B, 2C), требуют, чтобы содержимое сдвигалось по битам во время кодирования и декодирования заголовка. Кроме того, этот подход не обязательно является обратно совместимым, если приемник не поддерживает новый формат.

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

Например, в подзаголовке MAC в соответствии с LTE Rel-8/9, проиллюстрированном на фиг. 2A, 2B и 2C, имеется два зарезервированных (R) бита. Однако в аспекте настоящего раскрытия изобретения один или оба из них могут использоваться для расширения поля заголовка, например поля длины (L). Если поле L расширяется непосредственно с использованием традиционного подхода, то потребовалось бы сдвигать все поля перед полем L. Вместо этого предпочтительный подход состоит в логическом присоединении спереди или сзади одного или обоих битов R к битам унаследованного поля L, чтобы образовать поле расширенной длины (EL), сохраняя при этом положения всех существующих полей.

Фиг. 7A и 7B иллюстрируют примеры расширенных подзаголовков MAC, в которых поле L расширяется на один бит. Оба подзаголовка имеют структуры R/EL/E/LCID/F/L. На этих фигурах один из двух зарезервированных битов (R-битов) используется в качестве бита поля расширенной длины (EL). Когда используются расширенные заголовки, унаследованное поле L из 7 или 15 битов можно расширить с помощью бита EL. Таким образом, получается 8-битный (когда не задано поле F формата, см. фиг. 7A) или 16-битный индикатор длины (когда задается поле F формата, см. фиг. 7B). Фиг. 8 иллюстрирует PDU MAC вместе с примером расширенного заголовка MAC, который включает в себя структуры расширенного подзаголовка MAC, проиллюстрированные на фиг. 7A и 7B.

Конечно, признается, что любой размер, указанный расширенным 8-битным полем L длины на фиг. 7A, также может указываться унаследованным 15-битным полем L длины в структуре унаследованного подзаголовка MAC, проиллюстрированной на фиг. 2B. Однако преимущество патентоспособной структуры подзаголовка, проиллюстрированной на фиг. 7A, перед унаследованной структурой, проиллюстрированной на фиг. 2B, состоит в том, что структура на фиг. 7A требует на один октет меньше.

Если поле EL используется в качестве самого старшего бита для поля L, то форматы заголовка у UE Rel-8/9 и UE Rel-10 совершенно одинаковые, когда длина SDU MAC не превышает размер, который может указываться форматом унаследованного заголовка, содержащим 15 битов. Причина в том, что R-бит в UE Rel-8/9 всегда устанавливается в 0.

Фиг. 9A и 9B иллюстрируют альтернативные примеры расширенных подзаголовков MAC со структурами EL/R/E/LCID/F/L, в которых поле L расширяется на один бит. На этих фигурах бит EL помещается в крайний левый бит первого октета. Это удобно, поскольку не требуется сдвига битов при объединении бита EL с полем L.

Хотя и не проиллюстрировано, вариант осуществления расширенного подзаголовка MAC может включать в себя расширенные подзаголовки MAC из фиг. 9A и 9B. Хотя также не проиллюстрировано, поле формата (F) можно расширить с использованием битов R. Поле F можно расширить вместо или в дополнение к полю L.

Изменение форматов заголовка и расширение текущих полей длины и порядкового номера для всех UE Rel-10 не обязательно. Поскольку расширение полей длины или порядкового номера в L2 обычно подразумевает увеличенную служебную нагрузку, желательно поддерживать как унаследованный формат для унаследованных скоростей передачи данных, так и расширенный формат для новых очень высоких скоростей. Поддержка унаследованного формата также необходима для UE в унаследованных сетях Rel-8/9.

Фиг. 10 иллюстрирует примерный способ 1000 для управления сетевым узлом 600, например базовой станцией в беспроводной сети, чтобы обеспечить обратную совместимость на уровнях протокола. На этапе 1010 сетевой узел 600 определяет, использовать ли расширенный заголовок для уровня протокола при беспроводной связи с мобильным терминалом 500. Любой уровень протокола выше уровня L1 может принять такое решение. Точнее говоря, любой из блока 420 RRC, блока 430 PDCP, блока 440 RLC и блока 450 MAC сетевого узла 600 может решить, использовать ли расширенный заголовок. Например, блок 450 MAC может решить использовать расширенный заголовок MAC, который проиллюстрирован на фиг. 8.

Для простоты ссылки фраза "блок уровня протокола" будет использоваться для ссылки в общем на любой блок, соответствующий уровням протокола выше уровня L1. Таким образом, на этапе 1010 можно сказать, что блок уровня протокола определяет, нужно ли использовать расширенный заголовок. Как упоминалось, любой из блоков 420, 430, 440, 450 уровня протокола, а также блок 460 PHY, проиллюстрированный на фиг. 4, может быть комбинацией процессора 610, исполняющего команды, сохраненные в запоминающем устройстве 620 сетевого узла 600. Когда определяется, что будет использоваться расширенный заголовок, блок уровня протокола на этапе 1020 использует расширенный заголовок для уровня протокола, который будет использоваться при передаче и приеме протокольных блоков данных уровня протокола к мобильному терминалу 500 и от него. Когда не определяется, что будет использоваться расширенный заголовок, блок уровня протокола на этапе 1030 использует унаследованный заголовок.

В качестве примерной иллюстрации использования расширенного заголовка на этапе 1010 блок 450 MAC может определить, что расширенный заголовок MAC будет использоваться для расширения поля L длины одного из SDU MAC. Затем на этапе 1020 блок 450 MAC может использовать расширенное поле EL длины, соответствующее SDU в расширенном заголовке MAC. В качестве другой примерной иллюстрации на этапе 1010 блок RLC 440 может определить, что поле SN порядкового номера следует расширить с использованием расширенного заголовка RLC. Затем на этапе 1020 блок 440 RLC может использовать поле E-SN (расширенный порядковый номер) в расширенном заголовке RLC.

Отметим, что когда "используется" расширенное поле, это не обязательно подразумевает, что расширенное поле устанавливается в фиксированное значение. Значение бита или бит расширенного поля будет зависеть от конкретных обстоятельств. Когда используется расширенное поле, нужно указать, что поле не игнорируется, когда записывается расширенный заголовок, и также не игнорируется, когда расширенный заголовок считывается.

В одном аспекте расширенный заголовок включает в себя унаследованное поле индикатора (L-I) с заранее установленным количеством бит индикатора для использования при указании значения характеристики PDU. Также имеется унаследованное пороговое значение индикатора, ассоциированное с характеристикой. Унаследованное пороговое значение индикатора может описываться максимальным значением характеристики, которое может указываться унаследованным полем L-I индикатора.

Расширенный заголовок также содержит расширенное поле индикатора (E-I), которое может логически объединяться с унаследованным полем L-I индикатора. Логическое объединение E-I/L-I включает в себя достаточное количество битов для задания значения характеристики за пределами унаследованного порогового значения индикатора. Поскольку комбинация E-I/L-I объединяется логически, биты поля E-I и биты поля L-I не должны быть побитово-смежными друг с другом. Они также могут занимать разные октеты расширенного заголовка.

В качестве иллюстрации используется поле L в подзаголовке SDU MAC. Как проиллюстрировано на фиг. 2A и 2B и описано выше, поле L - которое является примером унаследованного поля L-I индикатора - указывает размер одного из SDU MAC, включенных в PDU MAC. Поскольку унаследованное поле L имеет длину либо 7, либо 15 бит, есть некоторый максимальный размер SDU, за пределами которого размер нельзя указать с помощью унаследованного поля L. Унаследованное пороговое значение в этом случае с унаследованным полем L может быть унаследованным размером транспортного блока, то есть максимальным размером TB, который может указываться унаследованным полем L.

Но как проиллюстрировано на фиг. 7A, 7B, 9A и 9B и также описано выше, поле EL - которое является примером поля E-I - может логически объединяться с полем L. Комбинация EL-L может указывать размер SDU MAC за пределами порогового значения, которое было возможно с одним унаследованным полем L. Отметим, что поля EL и L являются побитово-несмежными. Они также занимают разные октеты.

Также следует отметить следующее. На фиг. 7A, 7B, 9A и 9B позиция бита поля EL в расширенном заголовке MAC соответствует одной из позиции бита зарезервированных бит R унаследованного заголовка MAC. Таким образом, с точки зрения унаследованного оборудования, такого как UE Rel 8/9, структура расширенного заголовка MAC соответствует структуре унаследованного заголовка MAC. Это дает возможность обратной совместимости, что является существенным преимуществом.

В целом можно сказать, что расширенное поле E-I индикатора содержит один или несколько битов, и позиции битов поля E-I расширенного заголовка соответствуют позициям зарезервированных битов унаследованного заголовка уровня протокола. Таким образом, когда унаследованное оборудование рассматривает расширенный заголовок с точки зрения унаследованного оборудования, структура расширенного заголовка соответствует структуре унаследованного заголовка.

В одном аспекте предложенного способа выбор формата выполняется динамически, где расширенные заголовки используются только тогда, когда они нужны. Например, на уровне MAC динамический выбор размера поля L может выполняться на основе размера транспортного блока или размера SDU MAC. Это возможно, поскольку поле L зависит только от текущего размера TB, а передающие и принимающие объекты - например, сетевой узел 600 и мобильный терминал 500 - знают размеры TB.

Фиг. 11 иллюстрирует примерный процесс для реализации этапа 1010, чтобы определить, использовать ли расширенный заголовок, чтобы формат мог выбираться динамически - то есть выбираться при необходимости. Как видно на этапе 1110, на уровне протокола, например уровне MAC, определяется, превышает ли размер транспортного блока на уровне L1 (физическом) унаследованный пороговый размер транспортного блока. Напомним, что уровень протокола иерархически находится над уровнем L1. Блок 450 MAC может выполнить это определение. Хотя блок MAC 450 наиболее вероятен, любой из блока 420 RRC, блока 430 PDCP и блока 440 RLC также может выполнить это определение. Для удобства предполагается, что уровень протокола для этапов, проиллюстрированных на фиг. 11, является уровнем MAC.

Ссылаясь снова на фиг. 10, способ 1000 переходит к использованию расширенного заголовка на этапе 1020, когда определяется, что будет использоваться расширенный заголовок (ветвь ДА на фиг. 11). Таким образом, когда расширенный заголовок является расширенным заголовком MAC, этап 1020 использования расширенного заголовка MAC может описываться как использующий расширенное поле EL длины расширенного заголовка MAC, так что логическое объединение EL/L включает в себя достаточное количество битов для задания размера TB больше, чем унаследованный пороговый размер TB. Будет использоваться поле EL. То, будет ли каждый бит поля EL установлен в ноль или единицу, будет зависеть от размера SDU MAC, но поле не игнорируется. Логическое объединение может быть таким, что бит (биты) поля EL объединяются, чтобы стать самым старшим битом (битами) логического объединения EL/L. Конечно, бит (биты) EL также могут объединяться, чтобы стать самым младшим битом (битами).

Отметим, что когда размер TB, указанный физическим уровнем, превышает размер, который может указываться унаследованным полем L, поле длины можно расширить на один или два зарезервированных бита. Фактическое расширение может выполняться с использованием либо неиспользуемого в настоящее время, то есть зарезервированного бита, либо битов унаследованного заголовка. Как упоминалось выше, когда расширение выполняется с использованием зарезервированных битов, расширенный заголовок соответствует структуре унаследованного заголовка с точки зрения унаследованного оборудования.

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

Одним преимуществом (которых может быть несколько) динамически расширяемых полей заголовка является то, что для UE нижней категории, не поддерживающих самые высокие скорости передачи битов, например UE Rel-8/9, не предоставляются самые большие размеры TB. Поэтому нет никаких проблем функциональной совместимости, потому что на практике UE нижней категории не должны реализовывать расширенные заголовки. Кроме того, динамически расширяемые поля заголовка минимизируют служебную нагрузку заголовка для UE, которые не поддерживают очень высокие скорости передачи данных, но работают в условиях радиосвязи или условиях нагрузки, препятствующих использованию больших транспортных блоков.

Использование расширенных заголовков также может полустатистически конфигурироваться посредством сигнализации верхнего уровня. Сигнализация RRC является одним неограничивающим примером сигнализации верхнего уровня. Может существовать одна или несколько конфигураций верхнего уровня для указания, что расширяются многие поля, включая, например, поле L MAC, SO RLC, поля SOstart и SOend, поля LI RLC и SN RLC и, наконец, поле SN PDCP.

В одном варианте осуществления сетевой узел 600 конфигурирует мобильный терминал 500 для использования расширенного заголовка для уровня или уровней протокола. То есть для мобильного терминала 500 использование расширенных форматов может конфигурироваться с помощью верхних уровней. Это может быть справедливо как для восходящей линии связи, так и для нисходящей линии связи. Например, сетевой узел 600 (например, eNB) может конфигурировать использование расширенных заголовков в мобильном терминале 500 (например, UE) путем отправки мобильному терминалу 500 конфигурационного сообщения в виде команд RRC. Уровень RRC в мобильном терминале 500 может конфигурировать использование расширенных заголовков. Сообщение RRC является одним видом конфигурационных сообщений. Другие включают в себя элементы управления MAC, специальный RNTI по PDCCH, специальные форматы выделения и так далее.

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

Как видно, на этапе 1210 определяется, приведет ли передача, использующая расширенный заголовок, к достаточно большей пропускной способности, нежели передача без использования расширенного заголовка. Например, может определяться, приведет ли передача с расширением полей на уровне протокола к достаточно большей пропускной способности, нежели передача без расширения полей. Для удобства это называется первым условием. Для простой речевой связи может иметь место незначительная разница или никакой разницы в пропускной способности, поэтому первое условие может не выполняться. Для применений с большой полосой пропускания, например потоковой передачи видео, первое условие может выполняться, то есть расширения полей, если используются, могли бы привести к значительно большей пропускной способности.

На этапе 1220 определяется, доступны ли достаточные ресурсы передачи для передачи с использованием расширенного заголовка, например передачи с расширением полей. Это называется вторым условием. Ресурсы передачи могут включать в себя количество доступных несущих, количество доступных блоков ресурсов на каждое UE на несущей, можно ли использовать конфигурацию MIMO (несколько входов и несколько выходов), и так далее. Если сетевой узел 600 в настоящее время обслуживает много мобильных терминалов 500, то у него может не быть достаточной полосы пропускания, доступной для предоставления, например, запрошенной услуги потоковой передачи видео.

На этапе 1230 проверяется третье условие, удовлетворит ли передача, использующая расширенный заголовок, например передача с расширением полей, требованию минимального качества обслуживания (QoS), ассоциированного с передачей. В качестве иллюстрации, потоковая передача видео требует относительно высокой пропускной способности, означая, что может использоваться менее надежная MCS (схема модуляции и кодирования). Но при менее надежной MCS также увеличиваются вероятности ошибок, например BER (частота появления ошибочных битов). Когда имеются значительные помехи (например, когда UE находится на границе соты), BER может быть слишком высокой для потоковой передачи видео - то есть требование к минимальному QoS может не выполняться для потоковой передачи видео для UE на границе соты. Когда третье условие не выполняется, то есть когда требование к минимальному QoS выполнить маловероятно, определяется, что использование расширенного заголовка для того уровня протокола не будет использоваться.

На фиг. 12, когда выполняется любое одно или несколько из первого, второго и третьего условий, определяется, что расширенный заголовок нужно использовать для уровня протокола. Сетевой узел 600, определивший полустатически, что будут использоваться расширенные заголовки для одного или нескольких уровней протокола, конфигурирует мобильный терминал 500 на этапе 1240. Конфигурация может выполняться посредством отправки конфигурационного сообщения в виде сообщения RRC, элементов управления MAC, RNTI по PDCCH и так далее.

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

Неисчерпывающий список полей, которые могут указываться для расширения, включает в себя поле L MAC; SO RLC (смещение сегментации), поля SOstart и SOend, поля LI RLC (индикатор длины) и SN RLC (порядковый номер); и поля SN PDCP и FMS (первый отсутствующий SN PDCP). Таким образом, в расширенных заголовках, соответствующих блокам данных (управляющий/пользовательский SDU/PDU) уровней протокола, любое одно или несколько из следующих полей может использоваться соответствующими блоками 420, 430, 440, 450 уровня протокола в одной реализации этапа 1020, чтобы конфигурировать расширенные заголовки уровней протокола:

В расширенном заголовке PDCP блока данных PDCP:

расширенное поле порядкового номера (ESN PDCP), которое нужно логически объединить с унаследованным полем порядкового номера (SN PDCP);

расширенное поле первого отсутствующего SN PDCP (EFMS), которое нужно логически объединить с унаследованным полем первого отсутствующего SN PDCP (FMS);

В расширенном заголовке RLC блока данных RLC:

расширенное поле смещения сегмента (ESO RLC), которое нужно логически объединить с унаследованным полем смещения сегмента (SO RLC);

расширенное поле начала смещения сегмента (ESOstart RLC), которое нужно логически объединить с унаследованным полем начала смещения сегмента (SOstart RLC);

расширенное поле окончания смещения сегмента (ESOend RLC), которое нужно логически объединить с унаследованным полем окончания смещения сегмента (SOend RLC);

расширенное поле индикатора длины (ELI RLC), которое нужно логически объединить с унаследованным полем индикатора длины (LI RLC);

расширенное поле порядкового номера (ESN RLC), которое нужно логически объединить с унаследованным полем порядкового номера (SN RLC);

В расширенном заголовке MAC блока данных MAC:

расширенное поле длины (EL MAC), которое нужно логически объединить с унаследованным полем длины (L MAC); и

расширенное поле формата (EF MAC), которое нужно логически объединить с унаследованным полем формата (F MAC).

Конфигурация может существовать в расчете на однонаправленные радиоканалы данных (DRB), на определенный режим RLC (с подтверждением/без подтверждения) или на направление DL (нисходящая линия связи) или UL (восходящая линия связи). В некоторых сценариях может быть так, что TB более крупные в DL (или UL), чем в UL (или DL), и расширенное поле заголовка может быть необходимо в одном направлении, но не в другом. Например, в LTE Rel-10 в DL поддерживаются более крупные TB, чем в UL.

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

Фиг. 13 иллюстрирует примерный процесс для предоставления информации о формате заголовка при передаче обслуживания. Этапы 1310, 1320 и 1330 выполняются на исходной соте, а этапы 1340, 1350 и 1360 выполняются на целевой соте. Обе соты могут быть сетевыми узлами. Иными словами, сетевой узел 600 может быть исходной сотой в одном случае и целевой сотой - в другом. На этапе 1310 исходная сота определяет, будет ли происходить передача обслуживания мобильного терминала 500, например UE, в целевую соту. Если это так, то на этапе 1320 исходная сота извещает целевую соту о формате заголовка, используемом между исходной сотой и мобильным терминалом, а целевая сота на этапе 1340 принимает это извещение. Эта связь может выполняться по интерфейсу X2 между ними.

Предпочтительно, чтобы мобильный терминал 500 информировался о том, нужно ли использовать расширенные поля заголовка после передачи обслуживания в целевую соту. Таким образом, на этапе 1350 целевая сота определяет, будет ли использоваться формат расширенного заголовка. Целевая сота может информировать исходную соту об этом решении - да или нет - а исходная сота в свою очередь может уведомить мобильный терминал на этапе 1330. В качестве альтернативы целевая сота может напрямую уведомить мобильный терминал 500 о решении на этапе 1360.

Фиг. 14 иллюстрирует примерный способ 1400 для управления мобильным терминалом 500, например пользовательским оборудованием, чтобы обеспечить обратную совместимость на уровнях протокола. Проиллюстрированные этапы аналогичны этапам способа 1000 для управления сетевым узлом. Это должно стать небольшой неожиданностью, поскольку мобильный терминал 500 и сетевой узел 600 должны использовать одинаковые конфигурации заголовка при связи друг с другом.

На этапе 1410 мобильный терминал 500 определяет, использовать ли расширенный заголовок для уровня протокола при беспроводной связи с сетевым узлом 600. Как и в случае с сетевым узлом 600, любой уровень протокола выше уровня L1 может принять такое решение. Как упоминалось, любой из блоков 420, 430, 440, 450 уровня протокола, а также блок 460 PHY, проиллюстрированный на фиг. 4, может быть комбинацией процессора 610, исполняющего команды, сохраненные в запоминающем устройстве 620 сетевого узла 600.

Когда определяется, что будет использоваться расширенный заголовок, блок уровня протокола мобильного терминала на этапе 1420 использует расширенный заголовок для уровня протокола, который будет использоваться при передаче и приеме протокольных блоков данных уровня протокола к сетевому узлу 600 и от него. Примером является блок 450 MAC, определяющий, что расширенный заголовок MAC будет использоваться для расширения поля L длины одного из SDU MAC, как описано выше. Снова термин "используется" служит для указания, что поле не игнорируется. Состав расширенных подзаголовков для мобильного терминала 500 является таким же или аналогичным составу расширителей сетевого узла 600. Соответственно, подробное описание здесь будет пропущено.

Как указано выше, использование расширенного заголовка может определяться динамически - то есть использоваться при необходимости. На уровне MAC динамический выбор размера поля L может выполняться на основе размера транспортного блока или размера SDU MAC, поскольку сетевой узел 600 и мобильный терминал 500 знают размеры TB. Таким образом, фиг. 11 также представляет примерный процесс для реализации этапа 1410, чтобы определить, использовать ли расширенный заголовок, чтобы формат мог выбираться динамически.

Как также указано выше, расширенный заголовок может использоваться полустатически, например, посредством сигнализации верхнего уровня. В одном из описанных выше вариантов осуществления сетевой узел 600 определяет использование расширенных заголовков в мобильном терминале 500 и конфигурирует использование расширенных заголовков в мобильном терминале 500 в конфигурационном сообщении, например, см. этап 1240 на фиг. 12. Конфигурационное сообщение может быть в виде сообщений RRC, элемента управления MAC, специального RNTI по PDCCH, специального формата выделения и так далее.

Фиг. 15 иллюстрирует примерный процесс для реализации этапа 1410, чтобы определить, использовать ли расширенный заголовок уровня протокола. Мобильный терминал 500 принимает конфигурационное сообщение (например, сообщение RRC) от сетевого узла 600 на этапе 1510. На этапе 1520 блок 420, 430, 440, 450 уровня протокола определяет, указывает ли конфигурационное сообщение, что будет использоваться расширенный заголовок для одного или нескольких уровней протокола.

Когда конфигурационное сообщение включает в себя конфигурацию расширенного заголовка, то есть указывается использование расширенного заголовка или заголовков, то этап 1420 по конфигурированию расширенного заголовка может выполняться блоками уровня протокола в соответствии с принятым конфигурационным сообщением. То есть в расширенных заголовках, соответствующих блокам данных (управляющий/пользовательский SDU/PDU) уровней протокола, любое одно или несколько из следующих полей может использоваться соответствующими блоками 420, 430, 440, 450 уровня протокола при реализации этапа 1420 на основе принятого конфигурационного сообщения. Поля, которые можно расширить для каждого из уровней протокола, являются такими же или аналогичными сетевому узлу 600, и соответственно не будут повторяться.

Как правило, сеть и терминал должны иметь очень хорошее понимание, когда точно используются форматы расширенного заголовка. В одном или нескольких вариантах осуществления два объекта связи (например, UE и eNB) синхронно применяют реконфигурацию форматов заголовка. Этого можно добиться с помощью синхронизированной процедуры (например, передачи обслуживания на основе произвольного доступа в LTE). В качестве альтернативы реконфигурация может связываться с временем активизации. Время активизации может быть точной временной привязкой или относительной к моменту, когда принимается команда конфигурации.

У раскрытого объекта изобретения есть много преимуществ. Некоторые (не обязательно исчерпывающие) преимущества включают в себя следующие. В некоторых из предложенных аспектов расширяются поля в заголовках уровней протокола, что может быть полезным, когда размеры транспортного блока, превышающие унаследованные поля длины, предоставляются физическим уровнем.

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