СПОСОБ И УСТРОЙСТВА ДЛЯ ПРЕДОСТАВЛЕНИЯ ОТЧЕТОВ О СОСТОЯНИИ ПРИЕМА

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

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

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

Известно, что для обеспечения надежного приема приемник блока данных выполнен с возможностью периодически отправлять отчеты о состоянии приема отправителю блока данных. Например, в контексте так называемой технологии LTE-WLAN агрегирования, было предложено иметь возможность конфигурировать устройство пользователя (UE) периодически отправлять PDCP (протокол конвергенции пакетных данных) информацию о состоянии PDUs, что также может упоминаться как управление PDUs.

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

Задачей настоящего изобретения является обеспечение усовершенствованной концепции отправки отчетов о состоянии приема.

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

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

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

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

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

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

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

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

фиг. 2 показывает пример архитектуры протокола LTE-WLAN агрегирования;

фиг. 3 показывает первый вариант этапов способа согласно настоящему изобретению;

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

фиг. 5 показывает третий вариант осуществления этапов способа согласно настоящему изобретению;

фиг. 6 показывает четвертый вариант этапов способа согласно настоящему изобретению;

фиг. 7 показывает пятый вариант осуществления этапа способа согласно настоящему изобретению;

фиг. 8 показывает шестой вариант осуществления этапов способа согласно настоящему изобретению.

Подробное описание

На фиг. 1 показана система, содержащая устройство 100 связи, выполненное с возможностью отправлять блоки 120 данных, например, блоки данных протокола (PDU), ассоциированные с заданным протоколом связи, например, PDCP, в дополнительное устройство 110 связи, выпаленное с возможностью принимать блоки 120 данных.

Устройство 100 связи может быть установлено в сетевом узле сети связи или может быть таким узлом, например, узлом доступа системы беспроводной связи, например, базовой станцией. Согласно варианту осуществления устройство 100 связи установлено в eNodeB. Устройство 100 связи содержит интерфейс 101, например, выполненный с возможностью передавать и принимать данные беспроводной связи, и часть 102 управления, которая, в свою очередь, может содержать процессор 103 и память 104.

Устройство 110 связи может быть частью одной и той же сети связи, например, мобильной станцией системы беспроводной связи. Согласно варианту осуществления устройство 110 является устройством пользователя (UE) системы беспроводной связи, например, LTE. Устройство 110 содержит интерфейс 111, например, выполненный с возможностью передавать и принимать данные беспроводной связи, и часть 112 управления, которая, в свою очередь, может содержать процессор 113 и память 114.

Согласно варианту осуществления устройство 110 связи выполнено с возможностью принимать блок 120 данных, и может быть конфигурируемым для предоставления периодического отчета о состоянии приема, то есть, выполнено с возможностью отправлять отчеты 130 о состоянии приема, которые предоставляют информацию о состоянии приема отправленных блоков 120 данных. Например, порядковые номера (SN) могут быть использованы для различения отдельных блоков данных, и отчеты о состоянии приема могут предоставлять информацию о состоянии приема с использованием таких SNs. Информация о состоянии приема может быть выбрана любым подходящим или соответствующим способом, например, посредством различия таких состояний, как «приняты» или «пропущены».

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

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

Предпочтительно, в ответ на конфигурирование и при приеме блоков 120 данных, устройство 110 затем периодически отправляет отчеты о состоянии приема первого типа в соответствии с упомянутым ассоциированным значением упомянутого первого параметра периодичности предоставления отчета и отчеты о состоянии приема упомянутого второго типа в соответствии с упомянутым ассоциированным значением упомянутого второго параметра периодичности предоставления отчета.

Параметр периодичности предоставления отчета может быть выбран любым подходящим или соответствующим способом. Например, его можно выбрать для указания периода времени, например, указанный в миллисекундах, упомянутый период времени указывает временной интервал между последовательными передачами соответствующих отчетов о состоянии. Однако периодичность предоставления отчета также может быть выбрана для указания частоты, например, указанная в 1/s, упомянутая частота указывает частоту повторения соответствующих отчетов о состоянии приема.

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

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

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

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

Операция управления периодичностью передачи отчетов о состоянии приема может быть выполнена любым подходящим или соответствующим способом. Например, данная операция может содержать использование первого таймера для управления отправкой отчетов о состоянии приема первого типа и второго таймера для управления отправкой отчетов о состоянии приема второго типа. Два таймера могут запускаться одновременно после конфигурации, но согласно предпочтительному варианту осуществления первый таймер и упомянутый второй таймер изначально запускают с заданным смещением. Смещение предпочтительно выбирают таким образом, что запуск отправки отчета о состоянии приема первого типа не совпадает с запуском отчета о состоянии приема второго типа. Смещение может быть задано или быть частью операции конфигурации устройства 110, например, выполненное элементом информации конфигурации, отправленным устройством 100. В качестве примера, если значение, конфигурированное для первой периодичности предоставления отчета, составляет 200 ms, и значение, конфигурированное для второй периодичности предоставления отчета, составляет 50 ms, то смещение может, например, быть установлено на 25 ms.

Операция управления может содержать:

- определение, что упомянутый первый таймер достиг условия запуска (например, когда таймер истек)

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

- перезапуск упомянутого первого таймера.

Кроме того, операция управления может содержать:

- определение, что упомянутый второй таймер достиг условия запуска (например, когда таймер истек)

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

- перезапуск упомянутого второго таймера.

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

Кроме того, операция управления может содержать:

- прием сообщения, запрашивающего отправку отчета о состоянии приема упомянутого первого типа,

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

- перезапуск первого таймера. Операция управления может быть такой, что перезапускают только первый таймер, но также возможно, что перезапускают и первый, и второй таймер. Если оба таймера должны быть перезапущены, один из них предпочтительно перезапускают с заданным смещением относительно другого. Это смещение может быть выбрано таким же образом, как описано выше для начального запуска, или его можно выбрать иным образом. Предпочтительно, смещение сконфигурировано (например, информационным элементом, отправленным из устройства 100 в устройство 110), и такое же смещение используют для начального запуска обоих таймеров и для перезапуска обоих таймеров.

Кроме того, операция управления может содержать:

- прием сообщения, запрашивающего отправку отчета о состоянии приема упомянутого второго типа,

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

- перезапуск второго таймера. Операция управления может быть такой, что перезапускают только второй таймер, но также возможно, что и первый, и второй таймер будут перезапущены. Если оба таймера должны быть перезапущены, один из них предпочтительно перезапускают с заданным смещением относительно другого. Это смещение может быть выбрано таким же, как описано выше для начального запуска, или его можно выбрать как отличающееся. Предпочтительно, смещение сконфигурировано (например, информационным элементом, отправленным из устройства 100 в устройство 110), и такое же смещение используют для начального запуска обоих таймеров и для перезапуска обоих таймеров.

Как описано выше, описанная концепция позволяет отправлять два разных типа отчетов о состоянии приема параллельно, каждый из которых имеет конфигурируемую периодичность. Для более эффективного использования ресурсов передачи операция может управляться таким образом, что она содержит отправку только одного из отчетов о состоянии первого и второго типов в течение заданного периода времени. Например, этот период времени может быть временным интервалом передачи (TTI), так что способ содержит отправку только одного из отчетов о состоянии первого и второго типов в пределах одного и того же временного интервала передачи. Однако период времени также может быть продолжительнее, например, с использованием множества TTIs.

Описанные концепции также могут быть реализованы в виде компьютерного программного продукта, содержащего программный код, который должен быть выполнен процессором (например, процессором 113) устройства связи, такого как устройство 110, для выполнения способа в соответствии с любым из вышеописанных вариантов осуществления способа.

Описанные в настоящем документе концепции также могут быть реализованы в виде компьютерного программного продукта, содержащего программный код, который должен быть выполнен процессором (например, процессором 103) узла сети связи, например устройством 100, для выполнения способа в соответствии с любым из вышеописанных вариантов осуществления способа.

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

Настоящие примеры будут описаны в контексте интеграции LTE и WLAN. Следует, однако, понимать, что описанные в настоящем изобретении технические задачи и решения одинаково применимы к сетям беспроводного доступа и устройству пользователя (UE), реализующим другие технологии и стандарты доступа. LTE и WLAN используют в качестве примеров технологий, в соответствующих сценариях применения настоящего изобретения, и использование LTE и WLAN в описании особенно полезно для понимания технической задачи и ее решений.

LTE-WLAN агрегирование (LWA) представляет собой признак, в котором UE может принимать и передавать с использованием линий связи, как в eNB, так и WLAN. Этот признак описан 3GPP в релизе 13, как часть [RP-150510], пересмотренная в [RP-151114]. Существуют различные варианты архитектуры для LTE-WLAN агрегирования. В варианте архитектуры разделенного канала, обозначенной также параметром 3C, данные разделяют на PDCP уровне. Для направления нисходящей линии это разделение выполняют в eNB. еNB может динамически решать, как маршрутизировать PDUs PDCP в UE, либо непосредственно в UE, используя LTE RLC, LTE MAC и LTE PHY, либо через транзитный канал в WLAN, и затем в UE с использованием 802.11 MAC и 802.11 PHY.

На фиг. 2 показана предполагаемая архитектура протокола для LTE-WLAN агрегирования. Точка окончания WLAN (WT) в сети может быть реализована WLAN точкой доступа (AP) и/или контроллером доступа (AC) или другим сетевым узлом. Протокол интерфейса между eNB и WT обозначен Xw.

В настоящее время рабочее предположение в 3GPP RAN2 заключается в представлении нового PDCP формата отчета о состоянии, который могут использовать периодически или на основании опроса посредством eNB. Посредством PDCP предоставления отчета о состоянии, как правило, UE информирует eNB о PDCP состоянии приема в UE.

Унаследованный отчет содержит поле для первого отсутствующего порядкового номера (FMS), который установлен на первый отсутствующий SDU PDCP и поле битовой карты длины в битах, равное количеству SNs PDCP, от, и не включающую в себя первый отсутствующий SDU PDCP, до и, включающий в себя последний вне последовательности SDUs PDCP, округленные до следующего кратного 8. Далее приведено пояснение, как FMS и битовая карта могут быть использованы eNB:

FMS: посредством использования FMS поля eNB знает, сколько данных находится в обработке, то есть, в передаче и в процессах переупорядочения между eNB и UE PDCP. Эта информация полезна, так что eNB ограничивает свои передачи и не обеспечивает больше, чем ½ объема PDCP SN для обработки. Более того, PDCP среднюю скорость приема можно оценить, сравнивая, как обрабатывают данные FMS поля между последующими отчетами. Поскольку скорость приема RLC (LTE) известна в eNB (на основании обратной связи RLC), eNB также может оценить WLAN скорость приема. Аналогично, eNB может оценивать объем обрабатываемых данных по WLAN линии (= отправленные данные - FMS +1 - данные, отправленные, но не принятые через LTE RLC). Обе эти части информации могут быть полезны для eNB для управления потоком и многоканального планирования (LTE или WLAN) PDCP данных.

Битовая карта: уже имея только информацию о FMS, после хендовера LTE в одном соединении eNB выполнил PDCP повторные передачи (всех данных между отправленным самым высоким SN и FMS). Некоторые из данных, возможно, уже были приняты UE, однако, из-за RLC сбоя доставки после хендовера. Условием для внедрения битовой карты является указание, какой SN еще не принят, и какой SN уже принят Битовая карта предоставляет возможность выполнять выборочные повторные передачи. Если также учитываются выборочные повторные передачи LWA на PDCP уровне, то использование битовой карты также представляется полезной (или список отсутствующих SNs ниже наивысшего принятого SN, но это может привести к увеличению объема служебной сигнализации, чем битовая карта). Эти выборочные PDCP повторные передачи могут быть выполнены, например, когда PDU был потерян в WLAN. Устранение этого разрыва с помощью LTE PDCP может повысить производительность конечного пользователя. Это может быть реализовано до использования eNB, при выполнении таких повторных передач.

Максимальный размер битовой карты составляет ½ от SN пространства. Для 15-битного SN максимальный размер составляет, таким образом, 2 КВ. Для UT Cat5 с максимальной теоретической UL скоростью передачи 75376 бит/TTI может вызвать к объему служебной сигнализации, равной 21% в пределах этого TTI, что довольно значительно, поэтому предпочтительно избегать частотной обратной связи, включающей в себя битовую карту.

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

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

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

В одном варианте осуществления первая периодичность кратна другой периодичности. Это позволяет уменьшить сигнализацию.

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

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

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

В одном варианте осуществления UE будет отбрасывать передачу данных формата с меньшей информацией (например, только FMS), если одновременно отправляют данные формата с большей информацией (например, унаследованный формат, то есть, FMS и битовую карту), например, в том же TTI.

В одном варианте осуществления два различных таймера (например, называемые t-StatusReportType1 и t-StatusReportType2 и будут описаны более подробно далее в настоящем документе) используют в реализации PDCP UE для синхронизации передач отчетов о состоянии на основании различных форматов.

В другом варианте осуществления UE сконфигурировано с временным сдвигом между начальными точками периодичности предоставления отчета двух форматов. Например, если один таймер уже запущен и начал отсчет в момент времени t1, второй таймер запускается в момент времени t2 = t1 + величина смещения.

В одном варианте осуществления UE перезапускает периодический таймер после передачи PDCP отчета, который был инициирован eNB опросом. В одной версии этого варианта осуществления UE будет только перезапускать периодический таймер для типа отчета, который был опрошен. Например, если eNB сконфигурировал UE для отправки периодического отчета с битовой картой + FMS каждые 100 ms, а также UE отправлять периодический отчет только с FMS каждые 50 ms и eNB опросил UE получить отчет с FMS + битовая карта, тогда UE перезапустит таймер, используемый для определения момента времени отправки отчета с FMS + битовая карта (но не таймер для определения момента времени отправки отчета только с FMS). В качестве альтернативы, UE может перезапускать все периодические таймеры при опросе любого отчета, то есть, в примере, приведенном выше, UE затем перезапускает как таймер, используемый для определения момента времени отправки отчета с FMS + битовая карта, так и таймер, используемый для определения момента времени отправки отчета только с FMS.

Ниже приведен пример элемента информации конфигурации, в частности, сообщение конфигурации управления радиоресурсами (RRC), в котором особо выделяют новую концепцию двух независимых параметров периодичности предоставления отчета:

PDCP-Config ::= SEQUENCE {

discardTimer ENUMERATED {

ms50, ms100, ms150, ms300, ms500,

ms750, ms1500, infinity

} OPTIONAL, -- Cond Setup

rlc-AM SEQUENCE {

statusReportRequired BOOLEAN

} OPTIONAL, -- Cond Rlc-AM

rlc-UM SEQUENCE {

pdcp-SN-Size ENUMERATED {len7bits, len12bits}

} OPTIONAL, -- Cond Rlc-UM

headerCompression CHOICE {

notUsed NULL,

rohc SEQUENCE {

maxCID INTEGER (1..16383) DEFAULT 15,

profiles SEQUENCE {

profile0x0001 BOOLEAN,

profile0x0002 BOOLEAN,

profile0x0003 BOOLEAN,

profile0x0004 BOOLEAN,

profile0x0006 BOOLEAN,

profile0x0101 BOOLEAN,

profile0x0102 BOOLEAN,

profile0x0103 BOOLEAN,

profile0x0104 BOOLEAN

},

...

}

},

...,

[[ rn-IntegrityProtection-r10 ENUMERATED {enabled} OPTIONAL -- Cond RN

]],

[[ pdcp-SN-Size-v1130 ENUMERATED {len15bits} OPTIONAL -- Cond Rlc-AM2

]],

[[ ul-DataSplitDRB-ViaSCG-r12 BOOLEAN OPTIONAL, -- Need ON

t-Reordering-r12 ENUMERATED {

ms0, ms20, ms40, ms60, ms80, ms100, ms120, ms140,

ms160, ms180, ms200, ms220, ms240, ms260, ms280, ms300,

ms500, ms750, spare14, spare13, spare12, spare11, spare10,

spare9, spare8, spare7, spare6, spare5, spare4, spare3,

spare2, spare1} OPTIONAL -- Cond SetupS

]],

[[ statusFeedbackRequired-r13 BOOLEAN OPTIONAL, -- Need ON

statusPDU-TypeForPolling-r13 ENUMERATED {type1, type2} OPTIONAL,

statusPDU-PeriodicityType1-r13 ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500, ms1000, ms2000, ms5000, ms10000, ms20000, ms50000,

spare4, spare3, spare2, spare1} OPTIONAL

statusPDU-PeriodicityType2-r13 ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500, ms1000, ms2000, ms5000, ms10000, ms20000, ms50000,

spare4, spare3, spare2, spare1} OPTIONAL

]]

}

Кроме того, в следующем примере предоставляют пример указания элемента управления в соответствии с двумя таймерами, при этом LWA отчет о состоянии является примером отчета о состояния приема:

Когда t-StatusReportType1 истекает (если сконфигурировано), UE должно:

- если LWA канал конфигурирован верхними уровнями, отправлять PDCP отчет о состоянии по восходящей линии связи (statusFeedback [3]):

- компилировать и передавать PDCP отчет о состоянии типа 1, то есть, унаследованный PDCP отчет о состоянии, как указано в подпункте 5.3.1;

- запустить t-StatusReportType1.

Когда t-StatusReportType2 истекает (если сконфигурировано), UE должно:

- если LWA канал конфигурирован верхними уровнями, отправлять PDCP отчет о состоянии по восходящей линии связи (statusFeedback [3]):

- компилировать и передать отчет о PDCP состоянии типа 2, то есть, LWA PDCP отчет о состоянии, как указано в подпункте 5.x.1;

- запустить t-StatusReportType2.

Когда значение t-StatusReportType1 сконфигурировано или переконфигурировано верхними уровнями, UE должно:

- если t-StatusReportType1 запущен:

- остановить и перезапустить t-StatusReportType1;

- если t-StatusReportType1 не запущен:

- запустить t-StatusReportType1;

Когда значение t-StatusReportType2 сконфигурировано или переконфигурировано верхними уровнями, UE должно:

- если t-StatusReportType2 запущен:

- остановить и перезапустить t-StatusReportType2;

- если t-StatusReportType2 не запущен:

- запустить t-StatusReportType2;

Описание таймера:

b) t-StatusReportType1

Длительность таймера конфигурируют верхними уровнями (statusPDU-PeriodicityType1 [3]). По конфигурации, данный таймер используют для инициирования передачи отчета о состоянии типа 1 для LWA, как указано в подпункте 5.x.

c) t-StatusReportType2

Длительность таймера конфигурируют верхними уровнями (statusPDU-PeriodicityType2 [3]). По конфигурации, этот таймер используют для инициирования передачи отчета о состоянии типа 2 для LWA, как указано в подпункте 5.x.

Можно отметить, что конфигурация смещения по времени не рассмотрена в предшествующем примере.

Ниже приведен пример, включающий в себя конфигурацию смещения по времени.

-- ASN1START

PDCP-Config ::= SEQUENCE {

discardTimer ENUMERATED {

ms50, ms100, ms150, ms300, ms500,

ms750, ms1500, infinity

} OPTIONAL, -- Cond Setup

rlc-AM SEQUENCE {

statusReportRequired BOOLEAN

} OPTIONAL, -- Cond Rlc-AM

rlc-UM SEQUENCE {

pdcp-SN-Size ENUMERATED {len7bits, len12bits}

} OPTIONAL, -- Cond Rlc-UM

headerCompression CHOICE {

notUsed NULL,

rohc SEQUENCE {

maxCID INTEGER (1..16383) DEFAULT 15,

profiles SEQUENCE {

profile0x0001 BOOLEAN,

profile0x0002 BOOLEAN,

profile0x0003 BOOLEAN,

profile0x0004 BOOLEAN,

profile0x0006 BOOLEAN,

profile0x0101 BOOLEAN,

profile0x0102 BOOLEAN,

profile0x0103 BOOLEAN,

profile0x0104 BOOLEAN

},

...

}

},

...,

[[ rn-IntegrityProtection-r10 ENUMERATED {enabled} OPTIONAL -- Cond RN

]],

[[ pdcp-SN-Size-v1130 ENUMERATED {len15bits} OPTIONAL -- Cond Rlc-AM2

]],

[[ ul-DataSplitDRB-ViaSCG-r12 BOOLEAN OPTIONAL, -- Need ON

t-Reordering-r12 ENUMERATED {

ms0, ms20, ms40, ms60, ms80, ms100, ms120, ms140,

ms160, ms180, ms200, ms220, ms240, ms260, ms280, ms300,

ms500, ms750, spare14, spare13, spare12, spare11, spare10,

spare9, spare8, spare7, spare6, spare5, spare4, spare3,

spare2, spare1} OPTIONAL -- Cond SetupS

]],

[[ ul-DataSplitThreshold-r13 CHOICE {

release NULL,

setup ENUMERATED {

b0, b100, b200, b400, b800, b1600, b3200, b6400, b12800,

b25600, b51200, b102400, b204800, b409600, b819200,

spare1}

} OPTIONAL, -- Need ON

pdcp-SN-Size-v13xx ENUMERATED {len18bits} OPTIONAL, -- Cond Rlc-AM3

statusFeedback CHOICE {

release NULL,

setup SEQUENCE {

statusPDU-TypeForPolling-r13 ENUMERATED {type1, type2} OPTIONAL,

statusPDU-TypeForPeriodic-r13 ENUMERATED {type1, type2} OPTIONAL, statusPDU-Periodicity-Type1-r13 ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500,

ms1000, ms2000, ms5000, ms10000, ms20000, ms50000,

spare4, spare3, spare2, spare1} OPTIONAL

statusPDU-Periodicity-Type2-r13 ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500,

ms1000, ms2000, ms5000, ms10000, ms20000, ms50000,

spare4, spare3, spare2, spare1} OPTIONAL

statusPDU-PeriodOffset-r13 ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500,

ms1000, ms2000, ms5000, ms10000, ms20000, spare5,

spare4, spare3, spare2, spare1} OPTIONAL -- Cond Lwa-TwoPeriodicReports

}

} OPTIONAL -- Need ON

]]

}

-- ASN1STOP

Как видно, в информационный элемент добавлено поле «statusPDU-PeriodOffset».

Затем спецификация элемента управления для таймеров может быть изменена следующим образом:

Когда значение t-StatusReportType1 или t-StatusReportType2 сконфигурировано или переконфигурировано верхними уровнями, UE должно:

- если t-StatusReportType1 запущен:

- остановить и перезапустить t-StatusReportType1;

- если t-StatusReportType1 не запущен:

- запустить t-StatusReportType1;

- если t-StatusReportType2 запущен:

- остановить и перезапустить t-StatusReportType2 после смещения PDU-PeriodOffset по времени, если сконфигурировано [3], по сравнению с запуском t-StatusReportType1;

- если t-StatusReportType2 не запущен:

- запустить t-StatusReportType2 после смещения PDU-PeriodOffset по времени, если сконфигурировано [3], по сравнению с запуском t-StatusReportType1;