СПОСОБ ДЛЯ УПРАВЛЕНИЯ ОПЕРАЦИЯМИ DRX В РЕЖИМЕ УСТАНОВЛЕННОГО СОЕДИНЕНИЯ Российский патент 2019 года по МПК H04W52/02 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

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

Узкополосный Интернет Вещей (NB-IoT) является узкополосной (полоса пропускания 180 кГц) системой, разработанной для сотового Интернета Вещей (IoT) Проектом Партнерства Третьего Поколения (3GPP). Система основана на системах Долгосрочного Развития (LTE), и направлена на оптимизированную архитектуру сети и усовершенствованное покрытие внутри помещения для массивного числа устройств с любой из следующих характеристик: низкая пропускная способность (например, 2 Кбит/с); низкая чувствительность к задержке (например, ~10 секунд); сверхнизкая стоимость устройства (например, ниже 5 долларов); и никое энергопотребление устройства (например, время работы от батареи 10 лет).

Предполагается, что каждая сота (например, ~1 км²) в данной системе будет обслуживать тысячи (например, ~50000) устройств, таких как датчики, измерительные устройства, исполнительные устройства, и другие устройства. Предполагается, что данная система способна обеспечивать хорошее покрытие для своих устройств, которые часто располагаются глубоко внутри помещений (например, под землей в подвалах, или даже встроены в стены здания) и которые имеют ограниченную или отсутствующую возможность зарядки батареи. Несмотря на то, что предполагается много разных типов устройств, для простоты, они будут взаимозаменяемым образом именоваться в данном документе оборудованием пользователя (UE) или беспроводными устройствами.

Для того, чтобы сделать возможным развертывание NB-IoT, используя только одну повторно-обрабатываемую несущую GSM, и обеспечение более низких производственных затрат для NB-IoT UE, полоса пропускания была уменьшена до одного физического блока ресурсов (PRB) размером в 180 кГц, разделенного на несколько поднесущих.

Применительно к дуплексной связи с частотным разделением (FDD) (т.е., передатчик и приемник работают на разных несущих частотах), в UE требуется поддержка только полудуплексного режима. Более низкая сложность устройств (например, только одна цепь передачи/приема) означает, что некоторое повторение также может потребоваться в нормальном покрытии. Кроме того, чтобы ослабить сложность UE, рабочим допущением является наличие планирования между субкадрами. Т.е., сначала передача планируется по Улучшенному Физическому Каналу Управления Нисходящей Линии Связи (E-PDCCH, также известному как узкополосный Физический Канал Управления Нисходящей Линии Связи (NB-PDCCH или NPDCCH). Затем, первая передача фактических данных по узкополосному Физическому Совместно Используемому Каналу Нисходящей Линии Связи (NB-PDSCH или NPDSCH) выполняется после итоговой передачи NB-PDCCH. Сходным образом, применительно к передаче данных восходящей линии связи (UL), информация касательно ресурсов, планируемых сетью и требуемых UE для UL передачи, сначала переносится по NB-PDCCH, и затем первая передача фактических данных посредством UE по узкополосному Физическому Совместно Используемому Каналу (NB-PUSCH или NPUSCH) выполняется после итоговой передачи NP-PDCCH. Другими словами, применительно к обоим случаям выше, отсутствует одновременный прием канала управления и прием/передача канала данных с точки зрения UE.

В унаследованных системах связи, подобных Высокоскоростному Пакетному Доступу (HSPA) и LTE, поддерживается процедура повторной передачи, именуемая Гибридным Автоматическим Запросом Повторной Передачи (HARQ) с мягким объединением. После того, как блок данных передается в одном направлении (например, между UE и базовой станцией радиосвязи), отклик по результату декодирования обычно передается в обратном направлении, обозначенный как сообщение отклика HARQ. Данное сообщение отклика, как правило, является либо «бинарным» результатом декодирования, либо сообщением предоставления/назначения планирования. В случае, когда отклик является «бинарным» результатом декодирования, отклик может быть в форме квитирования (ACK), указывающего, что декодирование блока данных было успешным, или отрицательного квитирования (NACK), указывающего, что декодирование блока данных было неуспешным. В случае, когда отклик является в форме сообщения предоставления/назначения планирования, сообщение предоставления/назначения планирования может запрашивать либо повторную передачу (в случае, когда декодирование блока данных является неуспешным, сходно с NACK, описанной выше), либо передачу нового блока данных, что в неявной форме квитирует то, что предыдущий блок данных был успешно декодирован (сходно с ACK, описанной выше).

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

Как правило, несколько так-называемых процессов HARQ используются параллельно (например, в HSPA и LTE). Процесс HARQ является объектом паузы и ожидания (SAW) HARQ, который независимым образом переносит пакеты данных и ожидает отклика HARQ перед тем, как передается либо повторная передача, либо новая передача. В унаследованной LTE FDD, как правило восемь процессов HARQ поддерживаются из расчета на направление. Тоже самое применяется к HSPA с 2 мс UL интервалом времени передачи (TTI).

Синхронные операции HARQ означают, что повторные передачи происходят в фиксированное время после предыдущей передачи. В синхронной операции HARQ, с другой стороны, повторные передачи могут происходить в любое время после предыдущей передачи. Как в унаследованном LTE, так и в HSPA, UL использует синхронный HARQ, а нисходящая линия связи (DL) использует асинхронный HARQ.

Чтобы уменьшить потребление батареи UE, используется концепция прерывистого приема (DRX) в режиме установленного соединения, которая позволяет UE переходить в спящий режим (т.е., не требуется прием и/или передача) во время режима установленного соединения в LTE. Основная идея состоит в том, что когда не было никакой активности передачи и/или приема (например, нет передач/повторных передач и нет отложенных повторных передач) в течение периода времени, UE может переходить в спящий режим, и ему требуется только периодически пробуждаться на короткую величину времени каждый цикл DRX, чтобы осуществлять мониторинг канала управления DL. Если становятся доступными новые данные UL, UE может пробуждаться в любое время, но ему требуется проинформировать сеть через сконфигурированные ресурсы UL (например, запрос планирования может быть инициирован для отправки по Физическому Каналу Управления Восходящей Линии Связи (PUCCH)).

Операция DRX определяется в 3GPP TS 36.321, v. 13.0.0 для унаследованного LTE и управление ей осуществляется посредством набора таймеров/параметров, которые являются либо предварительно определенными, либо отправленными UE. В частности: onDurationTimer, drxStartOffset (из longDRX-CycleStartOffset в 3GPP TS 36.331, v. 13.0.0); longDRX-Cycle (из longDRX-CycleStartOffset в 3GPP TS 36.331, v. 13.3.0); shortDRX-Cycle; drxShortCycleTimer, drx-InactivityTimer, HARQ-RTT-Timer; и drx-RetransmissionTimer. В данном документе, цитирование конкретной версии стандарта (например, TS 36.331, v. 13.0.0) предназначено в качестве показательных версий, доступных на момент первоначальной подачи заявки. Тем не менее, другие версии также могут применяться, при необходимости.

Фигура 1 иллюстрирует пример работы UE в течение DRX в режиме установленного соединения. В частности, Фигура 1 (которая воспроизведена из 3GPP TS 36.321, v. 13.0.0) иллюстрирует, когда UE требуется пробуждаться и осуществлять мониторинг канала управления DL (обозначенного на PDCCH в примере Фигуры 1, но может быть PDCCH и/или ePDCCH) в течение цикла 105 DRX в режиме установленного соединения. В целом, в течение цикла 105 DRX UE осуществляет мониторинг канала управления DL в течение OnDuration периода 110 и спит в течение Возможности для DRX 115. Если новые данные запланированы (либо в UL, либо DL) в течение OnDuration времени 105, UE выходит из DRX и запускает таймер, именуемый drx-InactivityTimer.

Фигура 2 иллюстрирует пример унаследованной операции DRX. Если новые данные 205 запланированы (посредством канала 210 управления DL), drx-InactivityTimer 215 будет перезапущен, иначе он в конечном счете истечет и UE войдет в DRX. В примере Фигуры 2, UE входит в DRX по истечению drx-InactivityTimer 215, если оно не обнаружило PDCCH в течение продолжительности drx-InactivityTimer 215. В дополнение, Фигура 2 иллюстрирует смещение 220 между данными 205 HARQ (показанными в примере Фигуры 2 в качестве «Новых Данных» 205) и откликом 225 HARQ (показанным на Фигуре 2 в качестве передачи 225 ACK в UL 230). В LTE, смещение между данными 205 HARQ и откликом 225 HARQ всегда составляет N+4, т.е., всегда 4 мс (или эквивалентно субкадров) после передачи данных в момент N времени.

Фигура 3 иллюстрирует пример унаследованной операции DRX, если присутствуют повторные передачи DL. В таком сценарии, UE использует два других таймера: HARQ-RTT-Timer 305 и drx-RetransmissionTimer 310 чтобы контролировать повторную передачу(и). Отметим, что эти таймеры являются независимыми от drx-InactivityTimer 215. Когда повторная передача (показанная на Фигуре 3 как ReTx 315) успешно декодируется, drx-RetransmissionTimer 310 останавливается/отменяется, как показано в примере Фигуры 3. Отметим, что в примере Фигуры 3, после «Новых Данных» 205 может присутствовать активность в отношении других процессов HARQ UL/DL, сигнализируемых по PDCCH. Если новые данные запланированы по любому из них, drx-InactivityTimer 215 перезапускается.

Фигура 4 иллюстрирует пример унаследованной операции DRX, когда присутствует повторная передача UL. В примере Фигуры 4, UE принимает предоставление 405 UL по каналу 410 управления DL в то время как работает OnDuration Таймер 410. По приему предоставления 405 UL, UE останавливает OnDuration Таймер 410 и запускает drx-InactivityTimer 215. В примере Фигуры 4, UE выполняет передачу 420 UL (показанную как «Новые Данные» в примере Фигуры 4), ассоциированную с предоставлением 405 UL. После выполнения передачи 420 UL, UE будет входить в DRX по истечению drx-InactivityTimer 215, если оно не обнаружило PDCCH в течение продолжительности drx-InactivityTimer 215.

В унаследованном LTE, таймеры повторной передачи не требуются, если присутствует повторная передача 425 UL, поскольку используется синхронный HARQ. Синхронный HARQ обеспечивает точный хронометраж того, когда запланированы отклик HARQ (например, ACK 435 и/или NACK 430) и повторная передача. Новое предоставление по каналу 410 управления DL (например, PDCCH) также может быть дано в том же самом субкадре, когда NACK 430 отправляется по Физическому Канала Индикатора Гибридного ARQ (PHICH), и тогда повторная передача именуется «адаптивной». Смещения N+4 между предоставлением 405 UL и передачей 420 UL, между передачей 420 восходящей линии связи и NACK 430, между NACK 430 и повторной передачей 425 UL, и между повторной передачей 425 UL и ACK 435 показаны в качестве элементов 220a, 220b, 220c, и 220d, соответственно.

Отметим, что в примере Фигуры 4, после предоставления 405 UL может присутствовать активность в отношении других процессов HARQ UL/DL, сигнализируемых по каналу 410 управления нисходящей линии связи (например, PDCCH). Если новые данные запланированы по любому из них, drx-InactivityTimer перезапускается (если используется/запущен). Отметим также, что в некоторых случаях ACK 435 также может быть неявным квитированием, например, если выдается предоставление для новых данных применительно к процессу HARQ.

В 3GPP Редакции 13, продолжилась работа в отношении улучшенной Связи Машинного Типа (eMTC), в результате которой были внесены изменения в операции HARQ в сравнении с унаследованным LTE. Было принято решение о том, что поддерживаются три параллельных процесса HARQ. В дополнение, HARQ UL был изменен с синхронного на асинхронный, и отклик HARQ является только неявным и принимается по M-PDCCH (т.е., не существует канала PHICH) самое ранее N+4 после передачи PUSCH. В результате, требуются изменения в отношении того, каким образом UE должно входить в DRX, когда присутствует повторная передача, поскольку хронометраж отклика HARQ более не является фиксированным.

В другом рабочем вопросе в 3GPP Редакции 13, связанной с лицензированным вспомогательным доступом (LAA), также было идентифицировано, что HARQ UL требуется изменить с синхронного на асинхронный в сравнении с унаследованным LTE. Влияние этого описывается подробно в 3GPP TR 36.889, v. 13.0.0 (и, в частности, в разделе 7.2.2.2), который во всей своей полноте включен в настоящее описание посредством ссылки.

В LTE/eMTC все параметры DRX являются конфигурируемыми полу-статически в UE на основании сигнализации Управления Радио Ресурсами (RRC). Некоторое динамическое изменение поддерживается через сигнализацию Управления Доступом к Среде (MAC), чтобы управлять входом UE в короткую/длинную DRX в течение «Активного времени».

Проблема существующего подхода состоит в том, что исполнение HARQ/DRX было оптимизировано для нескольких процессов HARQ и случаев использования, где важно малое время ожидания и минимизация потребления батареи UE не была основной целью. Если точно такое же исполнение применяется к UE, которое поддерживает только операции полудуплекса, планирование между субкадрами и только один процесс HARQ, оно приведет к тому, что UE находится в пробужденном состоянии более длительное время, чем необходимо для многих случаев использования трафика, которые, как правило, используются в приложениях MTC/IoT. Например, во многих из случаев использования трафика, отсутствует одновременный перенос данных UL и DL. Вместо этого, большая часть случаев использования основаны на шаблоне трафика типа запрос-ответ, где IP пакет, отправленный в одном направлении, сопровождается ответом в другом.

Кроме того, в соответствии с существующими подходами (как LTE, так и HSPA) операция HARQ в UL является синхронной. Если операция HARQ меняется на асинхронную, то неизвестно как долго UE должно ждать отклика HARQ после того, как была выполнена передача/повторная передача. Одним подходом будет копирование исполнения DL также для UL (т.е., введение сходных таймеров (например, HARQ-RTT-Timer/drx-RetransmissionTimer) также для UL). Несмотря на то, что такой подход может быть приемлемым для случаев использования унаследованного LTE, он не очень хорошо подходит для случаев использования в зоне MTC/IoT. Эти приложения предполагают использование новых, упрощенных UE с поддержкой только полудуплекса, одного процесса HARQ и планирования между субкадрами. Таким образом, желательно более оптимизированное решение. Причина этого состоит в том, что другие решения могут уменьшать потребление батареи/питания UE и, вследствие этого, работать лучше, если в исполнении используются свойства полудуплекса, одного процесса HARQ, только планирования между субкадрами и типичных шаблонов трафика.

Одна цель NB-IoT состоит в повторном использовании унаследованного LTE (включая изменения eMTC) насколько это возможно. Важным фактором является то, каким образом должны работать операции HARQ и DRX в режиме установленного соединения. Если унаследованное исполнение применяется к NB-IoT, это приведет к большему потреблению батареи/питания для UE. Кроме того, поскольку все связанные с DRX таймеры являются полу-статическими, имеется очень ограниченная гибкость для eNB чтобы планировать передачи/повторные передачи HARQ и отклики HARQ. Если требуется обслуживать много UE и/или UE с разными уровнями покрытия (и, следовательно, разными временами продолжительности передачи), предыдущие подходы с полу-статическими параметрами не являются достаточно гибкими для обеспечения короткого «активного времени» для UE. Применение точно такого же исполнения как в унаследованном LTE, потребует использования больших значений таймера, и, следовательно, время бодрствования UE будет длиннее, приводя к большему потреблению батареи/питания.

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

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

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

В некоторых вариантах осуществления, способ может содержать этап, на котором осуществляют вход в режим прерывистого приема, когда истекает третий таймер. Способ может содержать этап, на котором принимают сообщение, включающее в себя информацию о продолжительности, по меньшей мере, второго и третьего таймеров. В некоторых вариантах осуществления, первый таймер может быть onDurationTimer цикла прерывистого приема. В некоторых вариантах осуществления, по меньшей мере, один из первого таймера и третьего таймера может быть drx-InactivityTimer. В некоторых вариантах осуществления, по меньшей мере, один из первого таймера и третьего таймера может содержать таймер повторной передачи прерывистого приема. В некоторых вариантах осуществления, второй таймер может быть таймером Времени Кругового Обращения (RTT) Гибридного Автоматического Запроса Повторной Передачи (HARQ), который содержит период смещения.

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

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

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

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

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

В некоторых вариантах осуществления, продолжительность первого таймера содержит одно из: величины времени, которое UE ожидает после отправки передачи восходящей линии связи, ассоциированной с указанной передачей нисходящей линии связи или восходящей линии связи для UE, до того, как UE запускает второй таймер; и величины времени, которое UE ожидает после конца указания передачи нисходящей линии связи или восходящей линии связи для UE до того, как UE запускает второй таймер. В некоторых вариантах осуществления, первый таймер может быть таймером Времени Кругового Обращения (RTT) Гибридного Автоматического Запроса Повторной Передачи (HARQ). В некоторых вариантах осуществления, продолжительность второго таймера может содержать величину времени, которое UE осуществляет мониторинг канала управления нисходящей линии связи до того, как входит в режим прерывистого приема. В некоторых вариантах осуществления, второй таймер может быть drx-InactivityTimer.

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

Некоторые варианты осуществления настоящего раскрытия могут предоставлять одно или более технические преимущества. Например, некоторые варианты осуществления могут преимущественно уменьшать потребление батареи и/или питания UE в сравнении с существующими подходами. В качестве другого примера, некоторые варианты осуществления могут преимущественно уменьшать время, которое требуется UE, чтобы оставаться пробужденным, чтобы осуществлять мониторинг канала управления нисходящей линии связи. В качестве еще одного другого примера, величина времени, которое требуется UE, чтобы оставаться пробужденным, чтобы осуществлять мониторинг канала управления нисходящей линии связи, может быть адаптирована к настоящей ситуации планирования в сетевом узле (например, eNB). В качестве еще одного другого примера, так как в NB-IoT требуется, чтобы канал управления нисходящей линии связи был мультиплексирован по времени как между UE, так и с передачами по совместно используемому каналу нисходящей линии связи, некоторые варианты осуществления могут преимущественно обеспечивать мультиплексирование по времени «активного времени» для UE, что может увеличить гибкость планирования в сетевом узле и позволить UE находиться пробужденным меньше (т.е., более короткие продолжительности времени). Другие преимущества могут быть легко очевидны специалисту в соответствующей области техники. Некоторые варианты осуществления могут не иметь, иметь некоторые, или все из перечисленных преимуществ.

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

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

Фигура 1 иллюстрирует пример операции UE в течение DRX в режиме установленного соединения;

Фигура 2 иллюстрирует пример унаследованной операции DRX;

Фигура 3 иллюстрирует пример унаследованной операции DRX, если присутствуют повторные передачи DL;

Фигура 4 иллюстрирует пример унаследованной операции DRX, если присутствует повторная передача UL;

Фигура 5 является структурной схемой, иллюстрирующей вариант осуществления сети 500, в соответствии с некоторыми вариантами осуществления;

Фигура 6A иллюстрирует первый пример хронометража и передачи для управления операциями DRX, в соответствии с некоторыми вариантами осуществления;

Фигура 6B иллюстрирует вариацию первого примера хронометража и передачи для управления операциями DRX на Фигуре 6A, в соответствии с некоторыми вариантами осуществления;

Фигура 7A иллюстрирует второй пример хронометража и передачи для управления операциями DRX, в соответствии с некоторыми вариантами осуществления;

Фигура 7B иллюстрирует вариацию второго примера хронометража и передачи для управления операциями DRX на Фигуре 7A, в соответствии с некоторыми вариантами осуществления;

Фигура 8A иллюстрирует третий пример хронометража и передачи для управления операциями DRX, в соответствии с некоторыми вариантами осуществления;

Фигура 8B иллюстрирует вариацию третьего примера хронометража и передачи для управления операциями DRX на Фигуре 8A, в соответствии с некоторыми вариантами осуществления;

Фигура 9A иллюстрирует четвертый пример хронометража и передачи для управления операциями DRX, в соответствии с некоторыми вариантами осуществления;

Фигура 9B иллюстрирует вариацию четвертого примера хронометража и передачи для управления операциями DRX на Фигуре 9A, в соответствии с некоторыми вариантами осуществления;

Фигура 10 является блок-схемой примера операций DRX, в соответствии с некоторыми вариантами осуществления;

Фигура 11 является блок-схемой способа в UE, в соответствии с некоторыми вариантами осуществления;

Фигура 12 является блок-схемой способа в сетевом узле, в соответствии с некоторыми вариантами осуществления;

Фигура 13 является структурной схемой примерного UE, в соответствии с некоторыми вариантами осуществления;

Фигура 14 является структурной схемой примерного сетевого узла, в соответствии с некоторыми вариантами осуществления;

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

Фигура 16 является структурной схемой примерного UE, в соответствии с некоторыми вариантами осуществления; и

Фигура 17 является структурной схемой примерного сетевого узла, в соответствии с некоторыми вариантами осуществления.

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

Как описано выше, одним важным фактором является то, каким образом операции HARQ и DRX в режиме установленного соединения должны работать в NB-IoT. Существующие подходы, такие как те, что используются в унаследованном LTE, являются неприемлемыми для случаев использования, ассоциированных с операциями NB-IoT. Например, если унаследованное исполнение применяется к NB-IoT, это может привести к большему потреблению батареи и/или питания для UE. Вследствие этого, поскольку все связанные с DRX таймеры являются полу-статическими, присутствует очень ограниченная гибкость для eNB, чтобы планировать передачи/повторные передачи HARQ и отклики HARQ. Если требуется обслуживать много UE и/или UE с разными уровнями покрытия (и, следовательно, разными временами продолжительности передачи), существующие подходы с полу-статическими параметрами не являются достаточно гибкими, чтобы обеспечивать короткое «Активное время» для UE. Применение существующих подходов, используемых в унаследованном LTE, к случаям использования NB-IoT, вследствие этого, потребует использования больших значений таймера, что будет иметь нежелательное последствие в виде увеличения величины времени, которое требуется, чтобы UE было пробуждено и, в свою очередь, приведет к большему потреблению батареи и/или питания UE.

Настоящее раскрытие предусматривает разнообразные варианты осуществления, которые могут быть направлены на эти и прочие недостатки, ассоциированные с существующими подходами. В некоторых вариантах осуществления, недостатки, ассоциированные с существующими подходами, могут быть преодолены используя новый, гибкий путь обработки/управления «активным временем» (т.е., временем, которое UE требуется находиться пробужденным, чтобы осуществлять мониторинг канала управления DL) в режиме установленного соединения для NB-IoT. В целом, два параметра могут быть использованы для этого: «активное время», которое определяет насколько долго UE должно находиться пробужденным, чтобы осуществлять мониторинг канала управления DL до входа в DRX; и «время смещения», которое определяет, когда запускать «активное время». В некоторых случаях, «время смещения» устанавливается относительно передачи UL, которая была инициирована приемом сообщения управления по каналу управления DL (например, NB-PDCCH). В одном не ограничивающем примере, передача UL может быть либо сообщением отклика HARQ, ассоциированным с назначением DL для приема данных DL, либо предоставлением UL, приведшим к передачи UL данных UL. Если новое сообщение управления принимается по каналу управления DL во время «активного времени», «активное время» останавливается (т.е., UE не требуется находиться пробужденным, чтобы осуществлять мониторинг канала управления DL). Затем, активность, указанная сообщением управления (DL-назначение или UL-предоставление) выполняется, и используются новые параметры «активного времени» и «времени смещения». Информация о значениях двух параметров («активного времени» и «времени смещения») может быть предоставлена любым подходящим образом. В некоторых вариантах осуществления, информация о значениях двух параметров может быть предоставлена из расчета на передачу как часть сообщения DL-назначения/UL-предоставления, отправленного по каналу управления DL, и может варьироваться в промежутках между разными DL-назначениями/UL-предоставлениями.

Аспекты вариантов осуществления, описываемых в данном документе, направлены на способы, выполняемые UE в системе связи (например, NB-IoT), которые управляют операцией DRX в режиме установленного соединения и поведением для UE и сетевого узла (например, базовой станции радиосвязи/eNB). В некоторых вариантах осуществления, способ использует свойства возможностей связи устройств NB-IoT, описанные выше (например, полудуплекс, один процесс HARQ, планирование между субкадрами) и типичные шаблоны трафика, используемые для оптимизации «активного времени» для устройства (UE) для того, чтобы минимизировать потребление батареи и/или питания. Некоторые варианты осуществления также могут преимущественно вводить гибкий способ управления операциями DRX в режиме установленного соединения посредством динамической сигнализации задействованных параметров.

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

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

Фигура 5 является структурной схемой, иллюстрирующей вариант осуществления сети 500, в соответствии с некоторыми вариантами осуществления. Сеть 500 включает в себя одно или более UE 510 (которые могут взаимозаменяемым образом именоваться беспроводными устройствами 510) и один или более сетевой узел(ы) 515 (которые могут взаимозаменяемым образом именоваться eNB 515). UE 510 могут осуществлять связь с сетевыми узлами 515 через беспроводной интерфейс.Например, UE 510 может передавать беспроводные сигналы одному или более сетевым узлам 515, и/или принимать беспроводные сигналы от одного или более сетевых узлов 515. Беспроводные сигналы могут содержать голосовой трафик, трафик данных, сигналы управления, и/или могут быть другой подходящей информацией. В некоторых вариантах осуществления, зона покрытия беспроводного сигнала, ассоциированная с сетевым узлом 515, может именоваться сотой 525. В некоторых вариантах осуществления, UE 510 может иметь возможность связи устройство-с-устройством (D2D). Таким образом, UE 510 может быть способно принимать сигналы от и/или передавать сигналы непосредственно другому UE.

В некоторых вариантах осуществления, сетевые узлы 515 могут взаимодействовать с контроллером радиосети. Контроллер радиосети может управлять сетевыми узлами 515 и может обеспечивать некоторые функции администрирования ресурса радиосвязи, функции администрирования мобильности, и/или другие подходящие функции. В некоторых вариантах осуществления, функции контроллера радиосети могут быть включены в сетевой узел 515. Контроллер радиосети может взаимодействовать с узлом базовой сети. В некоторых вариантах осуществления, контроллер радиосети может взаимодействовать с узлом базовой сети через сеть 520 межсоединения. Сеть 520 межсоединения может относиться к любой системе межсоединения, выполненной с возможностью передачи аудио, видео, сигналов, данных, сообщений, или любого сочетания предшествующего. Сеть 520 межсоединения может включать в себя все или часть из телефонной коммутируемой сети общего пользования (PSTN), открытой или закрытой сети передачи данных, локальной сети (LAN), городской сети (MAN), глобальной сети (WAN), локальной, региональной, или глобальной сети связи или компьютерной сети, такой как Интернет, проводной или беспроводной сети, интрасети предприятия, или любой другой подходящей линии связи, включая из сочетания.

В некоторых вариантах осуществления, узел базовой сети может осуществлять администрирование создания сеансов связи и разнообразной другой функциональности для UE 510. UE 510 может осуществлять обмен некоторыми сигналами с узлом базовой сети, используя слой без доступа. В сигнализации слоя без доступа, сигналы между UE 510 и узлом базовой сети могут прозрачным образом проходить через сеть радиодоступа. В некоторых вариантах осуществления, сетевые узлы 515 могут взаимодействовать с одним или более сетевыми узлами через меж-узловой интерфейс, такой как, например, интерфейс X2.

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

В некоторых вариантах осуществления, используется неограничивающее понятие UE. UE 510, описываемое в данном документе, может быть беспроводным устройством любого типа, выполненным с возможностью осуществления связи с сетевыми узлами 515 или другим UE через радиосигналы. UE 510 также может быть устройством радиосвязи, целевым устройством, D2D UE, UE машинного типа или UE с возможностью связи типа машина с машиной (M2M), UE низкой стоимости и/или низкой сложности, датчиком оснащенным UE, Планшетом, мобильными терминалами, интеллектуальным телефоном, оборудованием со встраиваемым лэптопом (LEE), оборудованием с монтируемым лэптопом (LME), USB-ключом, Оборудованием, Установленным у Пользователя (CPE), и т.д. UE 510 может работать либо при нормальном покрытии, либо улучшенном покрытии по отношению к его обслуживающей соте. Улучшенное покрытие может взаимозаменяемым образом именоваться расширенным покрытием. UE 510 также может работать на множестве уровней покрытия (например, нормальное покрытие, уровень 1 улучшенного покрытия, уровень 2 улучшенного покрытия, уровень 3 улучшенного покрытия, и т.д.). В некоторых случаях, UE 510 также может работать в сценариях вне покрытия.

Также, в некоторых вариантах осуществления используется общая терминология, «узел радиосети» (или просто «сетевой узел»). Он может быть любым видом сетевого узла, который может содержать базовую станцию (BS), базовую станцию радиосвязи, Узел-B, узел радиосвязи многостандартного радио (MSR), такой как MSR BS, развитый Узел-B (eNB), сетевой контроллер, контроллер радиосети (RNC), контроллер базовых станций (BSC), узел-ретранслятор, донорский узел управляющий ретрансляцией, базовую станцию приемопередатчика (BTS), точку доступа (AP), точку радиодоступа, точку передачи, узлы передачи, Выносной Радиочастотный Блок (RRU), Выносную Головку Радиосвязи (RRH), узлы в распределенной антенной системе (DAS), Много-сотовый/многоадресный Объект Координации (MCE), узел базовой сети (например, MSC, MME, и т.д.), O&M, OSS, SON, узел позиционирования (например, E-SMLC), MDT, или любой другой подходящий сетевой узел.

Терминология, такая как сетевой узел и UE, должна рассматриваться как неограничивающая и, в частности, не подразумевает некоторого иерархического отношения между двумя; в целом «eNodeB» может рассматриваться в качестве устройства 1, а «UE» - устройство 2, и эти два устройства осуществляют связь друг с другом по некоторому каналу радиосвязи.

Примерные варианты осуществления UE 510, сетевых узлов 515, и других сетевых узлов (таких как контроллер радиосети или узел базовой сети) описываются более подробно ниже в отношении Фигур 13-17.

Несмотря на то, что Фигура 5 иллюстрирует конкретную организацию сети 500, настоящее раскрытие предполагает, что разнообразные варианты осуществления, описываемые в данном документе, могут быть применены к разнообразным сетям с любой подходящей конфигурацией. Например, сеть 500 может включать в себя любое подходящее число UE 510 и сетевых узлов 515, как впрочем и любые дополнительные элементы, подходящие для обеспечения связи между UE или между UE и другим устройством связи (таким как городской телефон). Кроме того, несмотря на то, что некоторые варианты осуществления могут быть описаны как реализованные в сети Долгосрочного Развития (LTE), варианты осуществления могут быть реализованы в любом подходящем типе телекоммуникационной системы, поддерживающей любые подходящие стандарты связи (включая стандарты 5G) и используя любые подходящие компоненты, и применимы к любой технологии радиодоступа (RAT) или системам множества RAT, в которой UE принимает и/или передает сигналы (например, данные). Например, разнообразные варианты осуществления, описанные в данном документе, могут быть применены к LTE, Усовершенствованному LTE, NB-IoT, 5G, UMTS, HSPA, GSM, cdma2000, WCDMA, WiMax, UMB, WiFi, другой подходящей технологии радиодоступа, или любому подходящему сочетанию из одной или более технологий радиодоступа. Несмотря на то, что некоторые варианты осуществления могут быть описаны в контексте беспроводных передач в DL, настоящее раскрытие подразумевает, что разнообразные варианты осуществления в равной степени применимы в UL.

Как описано выше, некоторые варианты осуществления предоставляют новые способы для управления операциями DRX в режиме установленного соединения. В нижеследующем описании разнообразных неограничивающих примерных вариантов осуществления, некоторые допущения могут быть сделаны в отношении операций планирования и HARQ применительно к NB-IoT. Во-первых, предполагается, что данные DL/UL планируются посредством сообщения по каналу управления DL (например, NB-PDCCH). Во-вторых, предполагается, что данные DL/UL передаются по совместно используемым каналам (например, NB-PDSCH и NB-PUSCH, соответственно). В-третьих, предполагается, что отклик HARQ передается по каналам NB-PDCCH/NB-PUSCH (предполагается, что ресурс UL для отклика HARQ должен быть отправлен как часть назначения DL по NB-PDCCH). В заключение, предполагается, что асинхронный HARQ используется как в DL, так и UL. Отметим, что объем настоящего раскрытия не ограничивается разнообразными примерными вариантами осуществления, описанными в данном документе. В некоторых случаях, могут применяться ни одно, некоторые, или все вышеизложенные допущения.

Как описано выше, UE 510 может осуществлять мониторинг канала управления DL (например, NB-PDCCH). Здесь, время, когда UE 510 осуществляет мониторинг канала управления DL именуется «активным временем». Поведение UE 510 в отношении запуска «активного времени», остановки «активного времени», истечения «активного времени» и того, каким образом извлекать информацию длины и запуска «активного времени», описывается, главным образом, ниже в контексте Фигуры 5, и более подробно в отношении Фигур 6A-9B ниже. В некоторых вариантах осуществления, запуск «активного времени» происходит через «время смещения» после передачи UL от UE 510.

В некоторых вариантах осуществления, поведение UE 510 описывается в контексте NB-IoT, и когда «активное время» истекает, UE 510, говорят, переходит к операции DRX, образом сходным с унаследованным LTE (т.е., мониторинг NB-PDCCH осуществляется только в течение «времени Продолжительности Включенного состояния» каждый цикл DRX). Тем не менее, отметим, что разнообразные варианты осуществления, описанные в данном документе, не ограничиваются контекстом NB-IoT. Наоборот, настоящее раскрытие предполагает, что разнообразные варианты осуществления, описываемые в данном документе, применимы к любым подходящим RAT.

В целом, используются два главных параметра: «активное время», которое определяет насколько долго UE должно оставаться пробужденным, чтобы осуществлять мониторинг канала управления DL до перехода в DRX; и «время смещения», которое определяет, когда запускать «активное время». Как описано выше, «время смещения» (которое может именоваться в данном документе взаимозаменяемым образом «периодом смещения») запускается относительно передачи UL, выполняемой UE 510, которая была инициирована приемом указания передачи DL или UL для UE 510 (например, сообщение управления по каналу управления DL (например, NB-PDCCH, такое как: назначение DL для приема данных DL, которое приводит к тому, что передача UL является сообщением отклика HARQ; или предоставление UL, которое приводит к тому, что упомянутая передача UL является данными UL).

Если принимается новое сообщение управления по каналу управления DL в течение «активного времени», «активное время» останавливается (т.е., UE не требуется быть пробужденным, чтобы осуществлять мониторинг канала управления DL (например, NB-PDCCH). Вместо этого, сначала выполняется активность, как указывается упомянутым сообщением управления (например, DL-назначением или UL-предоставлением) и используются новое «активное время» и «время смещения».

В некоторых вариантах осуществления, информация о значениях двух параметров («активное время» и «время смещения») предоставляется из расчета на передачу как часть сообщения DL-назначения/UL-предоставления, отправленного по каналу управления DL, и может варьироваться между каждым DL-назначением/UL-предоставлением. Например, в некоторых вариантах осуществления сетевой узел (например, сетевой узел 515) может определять продолжительность «активного времени» и «время смещения» для использования UE 510, чтобы управлять операцией DRX. Сетевой узел 515 может отправлять информацию о продолжительностях «активного времени» и «времени смещения» UE 510. Сетевой узел 515 может отправлять информацию UE 510 любым подходящим образом. В качестве одного примера, сетевой узел 515 может отправлять сообщение UE 510, включающее информацию о продолжительности «активного времени» и «времени смещения». В качестве другого примера, информация о продолжительности «активного времени» и «времени смещения» может быть включена в указание передачи DL или UL для UE 510 (например, сообщение управления по каналу управления DL (например, NB-PDCCH), такое как: назначение DL для приема данных DL, которое приводит к тому, что передача UL является сообщением отклика HARQ; или предоставление UL, которое приводит к тому, что упомянутая передача UL является данными UL).

Несмотря на то, что некоторые примерные варианты осуществления могут быть описаны исходя из параметров, описанных как продолжительности времени, это лишь в качестве примера. Разнообразные варианты осуществления, описываемые в данном документе, не ограничиваются такими примерами. Наоборот, настоящее раскрытие предполагает, что вместо этого могут быть использованы таймеры, при реализации, указании, описании, и/или моделировании этих признаков разнообразных вариантов осуществления. Специалисты в соответствующей области техники понимают, что описания, использующие продолжительность времени или таймер могут быть эквивалентами. В некоторых случаях, при реализации разнообразных вариантов осуществления, описываемых в данном документе, в устройстве, предпочтительно может быть использован таймер. В таком сценарии, UE 510 может запускать таймер (с продолжительностью «времени смещения») после того, как оканчивается передача UL, и по истечению упомянутого таймера может быть запущен новый таймер (с продолжительностью «времени смещения»), и в то время пока работает UE 510 осуществляет мониторинг канала управления DL (например, NB-PDCCH). Несмотря на то, что в данном документе обсуждается использование нескольких таймеров, в соответствии с альтернативными вариантами осуществления, может быть использовано меньшее число таймеров (или даже отсутствие таймеров), при условии, что по-прежнему осуществляется мониторинг и определение продолжительности времени.

Например, в некоторых вариантах осуществления UE 510 осуществляет мониторинг канала управления DL (например, NB-PDCCH) в течение продолжительности, по меньшей мере, первого таймера. В некоторых вариантах осуществления, один или более таймеры могут быть работающими в это время. В некоторых вариантах осуществления, первый таймер из одного или более таймеров может быть одним из onDurationTimer цикла DRX, drx-InactivityTimer, и таймером повторной передачи DRX. UE 510 может принимать, по находящемуся под мониторингом каналу управления DL, указание передачи DL или UL для UE 510 (например, назначение планирования DL или предоставление UL, соответственно). После приема указания передачи DL или UL для UE 510, UE 510 может останавливать мониторинг первого таймера, и выполнять передачу UL, ассоциированную с указанной передачей DL или UL для UE 510 (например, отправлять сообщение ACK или передачу данных в UL). В соответствии с некоторыми вариантами осуществления, после приема указания передачи DL или UL для UE 510, UE 510 также может останавливать мониторинг канала управления DL. В соответствии с альтернативными вариантами осуществления, UE более не требуется осуществлять мониторинг канала управления DL в данной точке, но оно может продолжать это делать. После приема указания передачи DL или UL, UE 510 запускает второй таймер, причем продолжительность второго таймера содержит период смещения (например, таймер HARQ-RTT, который содержит период смещения). В соответствии с некоторыми вариантами осуществления, UE может запускать второй таймер после выполнения ассоциированной передачи UL. Когда второй таймер истекает, UE 510 может запускать третий таймер (например, drx-InactivityTimer или таймер повторной передачи прерывистого приема). В некоторых вариантах осуществления, UE 510 может осуществлять мониторинг канала управления DL в течение продолжительности третьего таймера, и входить в режим DRX, когда третий таймер истекает.

Разнообразные варианты осуществления теперь будут описаны более подробно ниже в отношении Фигур 6-9. Отметим, что продолжительности времени передач и смещений между передачами, показанными на Фигурах 6-9, представлены не в масштабе и не обязательно в единицах времени, таких как один кадр/субкадр (например, 1 мс). Наоборот, Фигуры 6-9 используются, чтобы проиллюстрировать, что передается (например, управление/данные) по разным физическим каналам NB-IoT, в какой очередности, разные смещения канала/передачи, и какие существуют продолжительности таймера. Отметим, что описание ниже включает в себя примеры использования как продолжительностей времени, так и таймеров. Чтобы отразить, что возможна любая реализация, Фигуры 6-9 иллюстрируют «* время(таймер)», «время(таймер) смещения», и «активное время(таймер)».

Фигура 6A иллюстрирует первый пример хронометража и передачи для управления операциями DRX, в соответствии с некоторыми вариантами осуществления. В частности, Фигура 6A показывает указание 605 передачи DL для UE, принятое по каналу 610 управления нисходящей линии связи (NB-PDCCH в примере Фигуры 6A), а именно назначение планирования DL (обозначенное DCI-1 в примере Фигуры 6A) с результирующей передачей 615 данных. Другими словами, сообщение 605 (обозначенное DCI-1) принимается UE по каналу 610 управления DL, которое планирует блок 615 данных DL (обозначенный SRB/DRB в примере Фигуры 6A), который должен быть принят UE по NB-PDSCH 620 (либо по Радио Носителю Сигнализации (SRB), либо Радио Носителю Данных (DRB)). Как описано выше, предполагается, что ресурс отклика HARQ для NB-PUSCH 635 должен быть включен в сообщение 605 NB-PDCCH (т.е., DCI-1).

В примере Фигуры 6A, по приему указания передачи 605 DL для UE (т.е., когда принимается DCI-1), «* время» 630 останавливается и UE останавливает мониторинг канала 610 управления DL. Это происходит потому, что более не требуется осуществлять мониторинг канала 610 управления DL из-за успешного приема в UE. В соответствии с альтернативными вариантами осуществления, может по-прежнему осуществляться мониторинг канала 610 управления, даже несмотря на то, что UE более не требуется это делать. «*» указывает, что это может быть либо «Продолжительностью Включенного Состояния» («On Duration»), либо «активным» временем. Например, в вариантах осуществления, в которых используется один или более таймеры, «* время» 630, показанное в примере Фигуры 6A может быть первым таймером в течение продолжительности которого UE осуществляет мониторинг канала 610 управления DL. Например, первый таймер 630 может быть одним из onDurationTimer цикла DRX, drx-InactivityTimer, и таймером повторной передачи DRX. Сообщение 605 инициирует активность 635 передачи UL позже по времени. В случае назначения DL, показанного в примере Фигуры 6A, сначала данные 615 SRB/DRB принимаются по NB-PDSCH 620 и, на основании результата декодирования, отправляется отклик HARQ (ACK 635 в примере Фигуры 6A) по NB-PUSCH 625. Другими словами, сообщение 605 DCI-1 является указанием передачи DL для UE, и UE выполняет передачу 635 UL, ассоциированную с указанной передачей DL (а именно, отправку сообщения квитирования).

После выполнения ассоциированной передачи 635 UL, «активное время» 640 запускается через «время смещения» 645 после того, как заканчивается передача 635 UL. В вариантах осуществления, в которых используются таймеры, например, после выполнения ассоциированной передачи 635 UL (сообщение ACK в примере Фигуры 6A), UE запускает второй таймер 645. Продолжительность второго таймера 645 может быть или содержать период смещения. Например, второй таймер 645 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 645 истекает, UE запускает третий таймер 640, соответствующий «активному времени», описанному выше. В некоторых вариантах осуществления, третий таймер 640 может быть одним из drx-InactivityTimer или таймером повторной передачи DRX. В течение «активного времени» (например, в течение продолжительности третьего таймера 640), UE осуществляет мониторинг канала 610 управления DL (NB-PDCCH в примере Фигуры 6A). Если сообщение NB-PDCCH не принимается до того, как заканчивается «активное время» 640 (например, до того, как истекает третий таймер 640), UE входит в режим 660 DRX, как показано в примере Фигуры 6A. В течение DRX, применяются ранее описанные концепции (т.е., UE пробуждается на период времени 650 («Продолжительность Включенного Состояния»), чтобы осуществлять мониторинг канала 610 управления DL (например, NB-PDCCH).

В примере Фигуры 6A, стрелки 655a-d, идущие от сообщения 695 DCI-1, предназначены, чтобы проиллюстрировать, что размер (например, продолжительность) «времени смещения» 645 и «активного времени» 640 (или продолжительность второго таймера 645 и третьего таймера 640, описанных выше, соответственно) включены в сообщение 605 DCI-1 (или релевантная информация, чтобы обеспечить определение продолжительности таймера). В некоторых вариантах осуществления, эти параметры могут меняться между каждой запланированной передачей (например, назначением DL или предоставлением UL), обеспечивая динамическое изменение параметров для каждой передачи. Например, сетевой узел (например, eNB 515, описанный выше в отношении Фигуры 5) может определять продолжительность второго таймера 645, содержащего период смещения, и третьего таймера 640, описанного выше, для использования UE, чтобы управлять операцией DRX. Продолжительность второго таймера 645 может быть величиной времени, которое UE ожидает после отправки передачи 635 UL, ассоциированной с указанной передачей DL для UE перед тем, как UE запускает третий таймер 640. Продолжительность третьего таймера 640 может содержать величину времени, которое UE осуществляет мониторинг канала 610 управления DL до входа в режим DRX. Сетевой узел может отправлять, UE, информацию о продолжительности второго таймера 645 и третьего таймера 640 для UE.

Настоящее раскрытие предполагает, что информация о разнообразных параметрах (например, длина «времени смещения» 645 и «активного времени» 640 или продолжительность второго таймера 645 и третьего таймера 640, описанных выше) может быть просигнализирована любым подходящим образом. Например, они могут быть частью сообщения L3 или передаваться посредством широковещательной передачи в информации системы. В таком сценарии, параметры будут полу-статическими как в предыдущих подходах и не настолько гибкими, как отправка их как части сообщения 605 NB-PDCCH (например, DCI-1 в примере Фигуры 6A). Отметим также, что не обязательно требуется сигнализировать точное значение. Вместо этого, может осуществляться широковещательная передача таблицы и/или она может быть предварительно определена, и может быть просигнализирован и/или включен индекс в той таблице.

В примере Фигуры 6A, включающем назначение DL, типичные примеры разных продолжительностей времени приводятся ниже. Отметим, тем не менее, что любые значения могут применяться в зависимости от, например, используемых ресурсов частоты UL/DL, скорости кодирования и числа повторений (т.е., избыточности), размера сообщения/данных, типа модуляции, стратегии планирования сетевого узла (например, eNB), и любых других подходящих критериев. В некоторых вариантах осуществления, продолжительностью NB-PDCCH (DCI-1) могут быть 2 мс. Смещением между NB-PDCCH и NB-PDSCH могут быть 4 мс.Продолжительностью NB-PDSCH (SRB/DRB) могут быть 20 мс.Смещением между NB-PDSCH и NB-PUSCH могут быть 2 мс. Продолжительностью NB-PUSCH (ACK) могут быть 4 мс.Продолжительностью «времени смещения» 645 могут быть 10 мс.Продолжительностью «активного времени» 640 могут быть 20 мс.

Фигура 6B иллюстрирует вариацию первого примера хронометража и передачи для управления операциями DRX на Фигуре 6A, в соответствии с некоторыми вариантами осуществления. Фигура 6B является сходной с Фигурой 6A, так что будут описаны только отличия. В примерном варианте осуществления Фигуры 6B, «активное время» 640 запускается через «время смещения» 645 после конца принятого указания передачи 605 DL для UE, принятого по каналу 610 управления DL (NB-PDCCH в примере на Фигуре 6B), а именно назначения планирования DL (обозначенного DCI-1 в примере Фигуры 6B). В вариантах осуществления, в которых используются таймеры, например, после конца принятого указания передачи 605 DL для UE, UE запускает второй таймер 645. Продолжительность второго таймера 645 может быть или содержать период смещения. Например, второй таймер 645 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 645 истекает, UE запускает третий таймер 640, соответствующий «активному времени».

Фигура 7A иллюстрирует второй пример хронометража и передачи для управления операциями DRX, в соответствии с некоторыми вариантами осуществления. В частности, Фигура 7A показывает указание передачи UL для UE, а именно предоставление 705 UL (обозначенное DCI-0 в примере Фигуры 7A) с результирующей передачей 710 UL. Другими словами, сообщение 705 (обозначенное DCI-0) принимается UE по каналу 715 управления DL (NB-PDCCH в примере Фигуры 7A), которое планирует блок 710 данных UL, который должен быть отправлен UE по NB-PUSCH 720 (либо по SRB, либо DRB).

В примере Фигуры 7A, после приема указания передачи UL для UE (т.е., когда принимается DCI-0 705), «* время» 725 останавливается и UE останавливает мониторинг канала 715 управления DL. Это потому, что более не требуется осуществлять мониторинг канала 715 управления DL (NB-PDCCH в примере Фигуры 7) из-за успешного приема в UE. В соответствии с альтернативными вариантами осуществления, может по-прежнему осуществляться мониторинг канала 715 управления, даже несмотря на то, что UE более не требуется это делать. Сходно с Фигурой 6A, описанной выше, «* время» 725 указывает, что это может быть либо «Продолжительностью Включенного Состояния», либо «активным» временем. Например, в вариантах осуществления, в которых используется один или более таймеры, «* время» 725 может быть первым таймером 725 в течение продолжительности которого UE осуществляет мониторинг канала 715 управления DL. Например, первый таймер 725 может быть одним из onDurationTimer цикла DRX, drx-InactivityTimer, и таймером повторной передачи DRX. Сообщение 705 инициирует активность 710 передачи UL позже по времени. В случае предоставления UL, показанного в примере Фигуры 7A, UE выполняет передачу данных 710 SRB/DRB по NB-PUSCH 720. Другими словами, сообщение 705 DCI-0 является указанием передачи 710 UL для UE, и UE выполняет передачу UL, ассоциированную с указанием (а именно, передачу данных 710 SRB/DRB по NB-PUSCH 720).

После выполнения ассоциированной передачи 710 UL, «активное время» 730 запускается через «время смещения» 735 после того, как заканчивается передача 710 UL. В вариантах осуществления, которые используют таймеры, например, после выполнения ассоциированной передачи 710 UL, UE запускает второй таймер 735, соответствующий «времени смещения», описанному выше. Продолжительность второго таймера 735 может быть или содержать период смещения. Например, второй таймер 735 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 735 истекает, UE запускает третий таймер 730, соответствующий «активному времени», описанному выше. В некоторых вариантах осуществления, третий таймер 730 может быть одним из drx-InactivityTimer и таймера повторной передачи DRX. В течение «активного времени» 730 (например, в течение продолжительности третьего таймера 730), UE осуществляет мониторинг канала 715 управления DL (NB-PDCCH в примере Фигуры 7A). Если сообщение NB-PDCCH не принимается до того, как заканчивается «активное время» 730 (т.е., до того, как истекает третий таймер 730), UE входит в режим 750 DRX, как показано в примере Фигуры 7A. В течение DRX, применяются ранее применяемые концепции (т.е., UE пробуждается на период времени 740 («Продолжительность Включенного Состояния»), чтобы осуществлять мониторинг канал 715 управления DL (например, NB-PDCCH).

В примере Фигуры 7A, стрелки 745a-c, идущие от сообщения 705 DCI-0, предназначены для того, чтобы проиллюстрировать размер (например, продолжительность) «времени смещения» 735 и «активного времени» 730 (или продолжительность второго таймера 735 и третьего таймера 730, описанных выше, соответственно), включенных в сообщение 705 DCI-0 (или релевантной информации чтобы обеспечить определение продолжительности таймера). В некоторых вариантах осуществления, эти параметра могут меняться между каждой запланированной передачей (например, назначением DL или предоставлением UL), обеспечивая динамическое изменение параметров для каждой передачи. Например, сетевой узел (например, eNB 515, описанный выше в отношении Фигуры 5) может определять продолжительность второго таймера 735 и третьего таймера 730, описанных выше, для использования UE, чтобы управлять операцией DRX. Продолжительность второго таймера 735 может быть величиной времени, которое UE ожидает после отправки передачи 710 UL, ассоциированной с указанной передачей DL или UL для UE перед тем, как UE запускает третий таймер 730. Продолжительность третьего таймера 730 может содержать величину времени, которое UE осуществляет мониторинг канала 715 управления DL до входа в режим DRX. Сетевой узел может отправлять, UE, информацию о продолжительности второго таймера 735 и третьего таймера 730 для UE.

Настоящее раскрытие предполагает, что информация о разнообразных параметрах (например, длина «времени смещения» 735 и «активного времени» 730 или продолжительность второго таймера 735 и третьего таймера 730, описанных выше) может быть просигнализирована любым подходящим образом. Например, они могут быть частью сообщения L3 или передаваться посредством широковещательной передачи в информации системы. В таком сценарии, параметры будут полу-статическими и не настолько гибкими, как отправка их как части сообщения NB-PDCCH (например, DCI-0 705 в примере Фигуры 7A). Отметим также, что не обязательно требуется сигнализировать точное значение. Вместо этого, может осуществляться широковещательная передача таблицы и/или она может быть предварительно определена, и может быть просигнализирован и/или включен индекс в той таблице.

Настоящее раскрытие предполагает, что значения разнообразных параметров могут быть любыми подходящими значениями. В некоторых вариантах осуществления, значения могут варьироваться на основании любых подходящих критериев. Например, значения разнообразных параметров могут зависеть от используемых ресурсов частоты UL/DL, скорости кодирования и числа повторений (т.е., избыточности), размера сообщения/данных, типа модуляции, стратегии планирования сетевого узла (например, eNB), и любых других подходящих критериев.

Фигура 7B иллюстрирует вариацию второго примера хронометража и передачи для управления операциями DRX на Фигуре 7A, в соответствии с некоторыми вариантами осуществления. Фигура 7B является сходной с Фигурой 7A так, что будут описаны только отличия. В примерном варианте осуществления Фигуры 7B, «активное время» 730 запускается через «время смещения» 735 после конца принятого указания передачи 705 UL для UE, принятого по каналу 715 управления DL (NB-PDCCH в примере Фигуры 7B), а именно предоставления UL (обозначенного DCI-0 в примере Фигуры 7B). В вариантах осуществления, в которых используются таймеры, например, после конца принятого указания передачи 705 UL для UE, UE запускает второй таймер 735. Продолжительность второго таймера 735 может быть или содержать период смещения. Например, второй таймер 735 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 735 истекает, UE запускает третий таймер 730, соответствующий «активному времени».

Фигура 8A иллюстрирует третий пример хронометража и передачи для управления операциями DRX, в соответствии с некоторыми вариантами осуществления. В частности, Фигура 8A иллюстрирует сценарий, в котором повторная передача HARQ инициируется для DL. Сходно с примером хронометража и передачи для управления операциями DRX, иллюстрируемым на Фигуре 6A, Фигура 8A показывает указание передачи 805 DL для UE, а именно назначение планирования DL (обозначенное DCI-1 в примере Фигуры 8A) по каналу 810 управления нисходящей линии связи с результирующей передачей 815 данных. Другими словами, сообщение 805 (обозначенное DCI-1), принятое UE по каналу 810 управления DL (NB-PDCCH в примере Фигуры 8A), планирует блок 815 данных DL (обозначенный SRB/DRB в примере Фигуры 8A), который должен быть принят UE по NB-PDSCH 810 (либо по SRB, либо DRB).

В примере Фигуры 8A, по приему указания передачи 805 DL для UE (т.е., когда принимается DCI-1 805), «* время» 825 останавливается и UE останавливает мониторинг канала 810 управления DL. Это происходит потому, что более не требуется осуществлять мониторинг канала 810 управления DL из-за успешного приема в UE. В соответствии с альтернативными вариантами осуществления, может по-прежнему осуществляться мониторинг канала 810 управления, даже несмотря на то, что UE более не требуется это делать. «* время» 825 указывает, что это может быть либо «Продолжительностью Включенного Состояния», либо «активным» временем. Например, в вариантах осуществления, в которых используется один или более таймеры, «* время» 825, показанное в примере Фигуры 8A может быть первым таймером 825 в течение продолжительности которого UE осуществляет мониторинг канала 810 управления DL. Например, первый таймер 825 может быть одним из onDurationTimer цикла DRX, drx-InactivityTimer, и таймером повторной передачи DRX. Сообщение 805 инициирует активность 830 передачи UL позже по времени.

В случае назначения DL, показанного в примере Фигуры 8A, сначала данные 815 SRB/DRB принимаются по NB-PDSCH 820 и, на основании результата декодирования, отправляется отклик 830 HARQ (NACK в примере Фигуры 8A). Другими словами, сообщение 805 DCI-1 является указанием передачи DL для UE, и UE выполняет передачу 830 UL, ассоциированную с указанной передачей DL. В примере Фигуры 8A, ассоциированной передачей 830 UL является отклик HARQ в форме «NACK», который инициирует повторную передачу HARQ.

После выполнения ассоциированной передачи 830 UL, «активное время» 835 запускается через «время смещения» 840 после того, как заканчивается передача 830 UL. В вариантах осуществления, в которых используются таймеры, например, после выполнения ассоциированной передачи 830 UL (сообщения NACK в примере Фигуры 8A), UE запускает второй таймер 840. Продолжительность второго таймера 840 может быть или содержать период смещения. Например, второй таймер 840 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 840 истекает, UE запускает третий таймер 835, соответствующий «активному времени», описанному выше. В некоторых вариантах осуществления, третий таймер 835 может быть одним из drx-InactivityTimer и таймером повторной передачи DRX. В течение «активного времени» 835 (например, в течение продолжительности третьего таймера 835), UE осуществляет мониторинг канала 810 управления DL (NB-PDCCH в примере Фигуры 8A). Если сообщение NB-PDCCH не принимается до того, как заканчивается «активное время» 835 (т.е., до того как истекает третий таймер 835), UE входит в режим DRX. В течение DRX, применяются ранее применяемые концепции (т.е., UE пробуждается на период времени («Продолжительность Включенного Состояния»), чтобы осуществлять мониторинг канала 810 управления DL (например, NB-PDCCH).

В примере Фигуры 8A, тем не менее, UE принимает указание второй передачи 845 DL для UE (т.е., когда принимается второе DCI-1 845), «активное время» 835 останавливается и UE останавливает мониторинг канала 810 управления DL. Это происходит потому, что более не требуется осуществлять мониторинг канала 810 управления DL (NB-PDCCH в примере Фигуры 8A) из-за успешного приема в UE второго сообщения 845 DCI-1. Второе сообщение 845 инициирует активность 850 передачи UL позже по времени. В случае назначения DL, показанного в примере Фигуры 8A, сначала второй экземпляр данных 855 SRB/DRB принимается по NB-PDSCH 820 и, на основании результата декодирования, отправляется отклик HARQ (ACK 850 в примере Фигуры 8A). Другими словами, второе сообщение 845 DCI-1 является вторым указанием передачи 855 DL для UE (т.е., повторной передачей HARQ передачи 835 DL), и UE выполняет передачу 850 UL, ассоциированную с указанной повторной передачей HARQ DL (а именно, отправку сообщения 850 ACK).

После выполнения ассоциированной передачи 850 UL, «активное время» 860 запускается через «время смещения» 865 после того, как заканчивается передача 850 UL. В вариантах осуществления, в которых используются таймеры, например, после выполнения ассоциированной передачи 850 UL (сообщение NACK в примере Фигуры 8A), UE запускает второй таймер 865. Продолжительность второго таймера 865 может быть или содержать период смещения. Например, второй таймер 865 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 865 истекает, UE запускает третий таймер 860, соответствующий «активному времени», описанному выше. В некоторых вариантах осуществления, третий таймер 860 может быть одним из drx-InactivityTimer и таймером повторной передачи DRX. В течение «активного времени 860» (например, в течение продолжительности третьего таймера 860), UE осуществляет мониторинг канала 810 управления DL (NB-PDCCH в примере Фигуры 8A). Если сообщение NB-PDCCH не принимается до того, как заканчивается «активное время» 860 (т.е., до того, как истекает третий таймер 860), UE входит в режим 880 DRX, как показано в примере Фигуры 8A. В течение DRX, применяются ранее применяемые концепции (т.е., UE пробуждается на период времени («Продолжительность Включенного Состояния»), чтобы осуществлять мониторинг канала 810 управления DL (например, NB-PDCCH).

В примере Фигуры 8A, стрелки 870a-d, идущие из первого сообщения 805 DCI-1, и стрелки 875a-d, идущие из второго сообщения 845 DCI-1, предназначены чтобы проиллюстрировать, что размер (например, продолжительность) «времени смещения» 840, «активного времени» 835, «времени смещения» 865 и «активного времени» 860 (или, в некоторых вариантах осуществления, продолжительность второго и третьего таймеров, описанных выше, соответственно) могут быть включены в первое сообщение 805 DCI-1 и второе сообщение 845 DCI-1, соответственно (или релевантную информацию, чтобы обеспечить определение продолжительности таймера). В некоторых вариантах осуществления, эти параметры могут меняться между каждой запланированной передачей (например, между первым сообщением DCI-1 и вторым сообщением DCI-1), обеспечивая динамическое изменение параметров для каждой передачи. Таким образом, продолжительность «времени смещения» 840 может быть точно такой же или отличной от «времени смещения» 865. Сходным образом, продолжительность «активного времени» 835 может быть точно такой же или отличной от «активного времени» 860. Сетевой узел (например, eNB 515, описанный выше в отношении Фигуры 5) может определять продолжительность вторых таймеров 840, 865 и третьих таймеров 835, 860, описанных выше для использования UE, чтобы управлять операцией DRX. Продолжительности вторых таймеров 840, 865 могут быть величиной времени, которое UE ожидает после отправки передач 830, 850 UL, ассоциированных с указанными передачами DL или UL для UE, соответственно, до того, как UE запускает третьи таймеры 835, 860. Продолжительность третьих таймеров 835, 860 может содержать величину времени, которое UE осуществляет мониторинг канала управления DL до того, как входит в режим DRX. Сетевой узел может отправлять, UE, информацию о продолжительности вторых таймеров 840, 865 и третьих таймеров 835, 860 для UE. В некоторых случаях, продолжительности могут быть разными для первой передачи DL, ассоциированной с первым сообщением 805 DCI-1 и вторым сообщением 845 DCI-1. В некоторых вариантах осуществления, продолжительности могут быть одинаковыми. Разнообразные параметры (например, длина «времени смещения» 840, 865 и «активного времени» 835, 860 или продолжительность вторых таймеров 840, 865 и третьих таймеров 835, 860, описанных выше) могут быть просигнализированы любым подходящим образом. Разнообразные примеры сигнализации, описанные выше в отношении Фигуры 6, в равной степени применимы к примерному варианту осуществления Фигуры 8A.

Фигура 8B иллюстрирует вариацию третьего примера хронометража и передачи для управления операциями DRX на Фигуре 8A, в соответствии с некоторыми вариантами осуществления. Фигура 8B является сходной с Фигурой 8A, так что будут описаны только отличия. В примерном варианте осуществления Фигуры 8B, «активное время» 835 запускается через «время смещения» 840 после конца принятого указания передачи 805 DL для UE, принятого по каналу 810 управления DL (NB-PDCCH в примере Фигуры 8B), а именно назначения планирования DL (обозначенного DCI-1 в примере Фигуры 8B). В вариантах осуществления, в которых используются таймеры, например, после конца принятого указания передачи 805 DL для UE, UE запускает второй таймер 840. Продолжительность второго таймера 840 может быть или содержит период смещения. Например, второй таймер 840 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 840 истекает, UE запускает третий таймер 835, соответствующий «активному времени».

Сходно с Фигурой 8A, описанной выше, в примере Фигуры 8B UE принимает указание второй передачи 845 DL для UE (т.е., когда принимается вторая DCI-1 845). В таком сценарии, «активное время» 835 останавливается и UE останавливает мониторинг канала 810 управления DL. В примере Фигуры 8B, тем не менее, «активное время» 860 запускается через «время смещения» 865 в конце второго принятого указания передачи 845 DL для UE, принятого по каналу 810 управления DL (NB-PDCCH в примере Фигуры 8B), а именно назначения планирования DL (обозначенного DCI-1 в примере Фигуры 8B). В вариантах осуществления, в которых используются таймеры, например, после конца второго принятого указания передачи 845 DL для UE, UE запускает второй таймер 865. Продолжительность второго таймера 865 может быть или содержать период смещения. Например, второй таймер 865 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 865 истекает, UE запускает третий таймер 860, соответствующий «активному времени».

Фигура 9A иллюстрирует четвертый пример хронометража и передачи для управления операциями DRX, в соответствии с некоторыми вариантами осуществления. В частности, Фигура 9 иллюстрирует сценарий, в котором повторная передача HARQ инициируется для UL. Сходно с Фигурой 7A, описанной выше, пример Фигуры 9A иллюстрирует первое указание передачи 905 UL для UE, а именно предоставление UL (обозначенное DCI-0 в примере Фигуры 9A) с результирующей передачей 910 UL. Другими словами, первое сообщение 905 (обозначенное DCI-0) принимается UE по каналу 915 управления DL (NB-PDCCH в примере Фигуры 9A), которое планирует блок 910 данных UL, который должен быть отправлен UE по NB-PUSCH 920 (либо по SRB, либо DRB).

В примере Фигуры 9A, по приему указания передачи 905 UL для UE (т.е., когда принимается DCI-0) «* время» 925 останавливается и UE останавливает мониторинг канала 915 управления DL. Это происходит потому, что более не требуется осуществлять мониторинг канала 915 управления DL (TNB-PDCCH в примере Фигуры 9A) из-за успешного приема в UE. В соответствии с альтернативными вариантами осуществления, по-прежнему может осуществляться мониторинг канала 915 управления, даже несмотря на то, что UE более не требуется это делать. Сходно с Фигурой 7A, описанной выше, «* время» 925 указывает, что это может быть либо «Продолжительностью Включенного Состояния», либо «активным» временем. Например, в вариантах осуществления, в которых используется один или более таймеры, «* время» 925, показанное в примере Фигуры 9A, может быть первым таймером 925, в течение продолжительности которого UE осуществляет мониторинг канала 915 управления DL. Например, первый таймер 925 может быть одним из onDurationTimer цикла DRX, drx-InactivityTimer, и таймером повторной передачи DRX. Сообщение 905 инициирует активность 910 передачи UL позже по времени. В случае предоставления UL, показанного в примере Фигуры 9A, UE выполняет передачу данных 910 SRB/DRB по NB-PUSCH 920. Другими словами, сообщение 905 DCI-0 является указанием передачи UL для UE, и UE выполняет передачу 910 UL, ассоциированную с указанной передачей UL (а именно, передачу данных SRB/DRB по NB-PUSCH 920).

После выполнения ассоциированной передачи UL, «активное время» 930 запускается через «время смещения» 935 после того, как заканчивается передача 910 UL. В вариантах осуществления, в которых используются таймеры, например, после выполнения ассоциированной передачи 910 UL (передачи UL по любому из SRB/DRB в примере Фигуры 9A), UE запускает второй таймер 935. Продолжительность второго таймера 935 может быть или содержать период смещения. Например, второй таймер 935 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 935 истекает, UE запускает третий таймер 930, соответствующий «активному времени», описанному выше. В некоторых вариантах осуществления, третий таймер 930 может быть одним из drx-InactivityTimer и таймера повторной передачи DRX. В течение «активного времени» 930 (например, в течение продолжительности третьего таймера 930), UE осуществляет мониторинг канала 915 управления DL (NB-PDCCH в примере Фигуры 9A). Если сообщение NB-PDCCH не принимается до того, как заканчивается «активное время» 930 (например, до того, как истекает третий таймер 930), UE входит в режим DRX.

В случае предоставления UL, показанного в примере Фигуры 9A, тем не менее, UE принимает второе сообщение 940, которое является либо вторым сообщением DCI-0, либо сообщением NACK по каналу 915 управления DL до истечения «активного времени» 930 (например, до истечения третьего таймера 930). В сценариях, в которых второе сообщение 940 является сообщением NACK, это может быть предоставлением UL с индикатором новых данных (NDI), не переключенным в случае использования адаптивной повторной передачи HARQ (т.е., используется неявная NACK). Второе сообщение 940 предоставляет указание повторной передачи 945 HARQ UL для UE. По приему второго сообщения 940, «активное время» 930 (или, в некоторых случаях, третий таймер 930) останавливается и UE останавливает мониторинг канала 915 управления DL. Это происходит потому, что более не требуется осуществлять мониторинг канала 915 управления DL (NB-PDCCH в примере Фигуры 9A) из-за успешного приема в UE второго сообщения 940 (либо второго сообщения DCI-0, либо NACK). Второе сообщение 940 инициирует активность 945 передачи UL позже по времени (т.е., повторную передачу HARQ передачи 910 UL). В случае предоставления UL, показанного в примере Фигуры 9A, UE выполняет вторую передачу 945 UL (а именно, передачу вторых данных SRB/DRB по NB-PUSCH 920).

После выполнения второй ассоциированной передачи 945 UL, «активное время» 950 запускается чрез «время смещения» 955 после того, как заканчивается передача 945 UL. В вариантах осуществления, в которых используются таймеры, например, после выполнения второй ассоциированной передачи 945 UL (передача вторых данных SRB/DRB по NB-PUSCH 920 в примере Фигуры 9A), UE запускает второй таймер 955. Продолжительность второго таймера 955 может быть или содержит период смещения. Например, второй таймер 955 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер 955 истекает, UE запускает третий таймер 950, соответствующий «активному времени», описанному выше. В некоторых вариантах осуществления, третий таймер 950 может быть одним из drx-InactivityTimer и таймера повторной передачи DRX. В течение «активного времени» 950 (например, в течение продолжительности третьего таймера 950), UE осуществляет мониторинг канала 915 управления DL (NB-PDCCH в примере Фигуры 9A). Если сообщение NB-PDCCH не принимается до того, как заканчивается «активное время» 950 (например, до того, как истекает третий таймер 950), UE входит в режим 970 DRX, как показано в примере Фигуры 9A. В течение DRX, применяются ранее применяемые концепции (т.е., UE пробуждается на период времени («Продолжительность Включенного Состояния»), чтобы осуществлять мониторинг канала 915 управления DL (например, NB-PDCCH).

В примере Фигуры 9A, стрелки 960a-c, идущие из первого сообщения 905 DCI-0, и стрелки 965a-c, идущие из второго сообщения 905 DCI-0, предназначены для того, чтобы проиллюстрировать, что размер (например, продолжительность) «времени смещения» 935, «активного времени» 930, «времени смещения» 955 и «активного времени» 950 (или, в некоторых вариантах осуществления, продолжительность вторых таймеров 935, 955 и третьих таймеров 930, 950, описанных выше, соответственно) может быть включен в первое сообщение 905 DCI-0 и второе сообщение 940 DCI-0, соответственно (или релевантную информацию, чтобы обеспечить определение продолжительности таймера). В некоторых вариантах осуществления, эти параметры могут меняться между каждой запланированной передачей (например, между первым сообщением 905 DCI-0 и вторым сообщением 940 DCI-0), обеспечивая динамическое изменение параметров для каждой передачи. Таким образом, продолжительность «времени смещения» 935 может быть точно такой же или отличной от «времени смещения» 955. Сходным образом, продолжительность «активного времени» 930 может быть точно такой же или отличной от «активного времени» 950. Сетевой узел (например, eNB 515, описанный выше в отношении Фигуры 5) может определять продолжительность вторых таймеров 935, 955 и третьих таймеров 930, 950, описанных выше, для использования UE, чтобы управлять операцией DRX. Продолжительности вторых таймеров 935, 955 могут быть величиной времени, которое UE ожидает после отправки передач 910, 945 UL, ассоциированных с указанными передачами UL для UE, соответственно, до того, как UE запускает третьи таймеры 930, 950. Продолжительность третьих таймеров 930, 950 может содержать величину времени, которое UE осуществляет мониторинг канала 915 управления DL до входя в режим DRX. Сетевой узел может отправлять, UE, информацию о продолжительности вторых таймеров 935, 955 и третьих таймеров 930, 950 для UE. В некоторых случаях, продолжительности могут быть разными для первой передачи UL, ассоциированной с первым сообщением 905 DCI-0 и вторым сообщением 940 DCI-0. В некоторых вариантах осуществления, продолжительности могут быть одинаковыми. Разнообразные параметры (например, длина «времени смещения» 935, 955 и «активного времени» 930, 950 или продолжительность вторых таймеров 935, 955 и третьих таймеров 930, 950, описанных выше) могут быть просигнализированы любым подходящим образом. Разнообразные примеры сигнализации, описанные выше в отношении Фигуры 6A, в равной степени применимы к примерному варианту осуществления Фигуры 9A.

Настоящее раскрытие предполагает, что значения разнообразных параметров могут быть любыми подходящими значениями. В некоторых вариантах осуществления, значения могут варьироваться на основании любых подходящих критериев. Например, значения разнообразных параметров могут зависеть от используемых ресурсов частоты UL/DL, скорости кодирования и числа повторений (т.е., избыточности), размера сообщения/данных, типа модуляции, стратегии планирования сетевого узла (например, eNB), и любых других подходящих критериев.

Фигура 9B иллюстрирует вариацию четвертого примера хронометража и передачи для управления операциями DRX на Фигуре 9A, в соответствии с некоторыми вариантами осуществления. Фигура 9B является сходной с Фигурой 9A так, что будут описаны только отличия. В примерном варианте осуществления Фигуры 9B, «активное время» 930 запускается через «время смещения» 935 после конца принятого указания передачи 905 UL для UE, принятого по каналу 915 управления DL (NB-PDCCH в примере Фигуры 9B), а именно предоставления UL (обозначенного DCI-0 в примере Фигуры 9B). В вариантах осуществления, в которых используются таймеры, например, после конца принятого указания передачи 905 UL для UE, UE запускает второй таймер 935. Продолжительность второго таймера 935 может быть или содержит период смещения. Например, второй таймер 935 может быть таймером HARQ-RTT, который содержит период смещения. Когда истекает второй таймер 935, UE запускает третий таймер 930, соответствующий «активному времени».

Сходно с Фигурой 9A, описанной выше, в примере Фигуры 9B UE принимает второе сообщение 940, которое является либо вторым сообщением DCI-0, либо сообщением NACK по каналу 915 управления DL до истечения «активного времени» 930 (например, до истечения третьего таймера 930). Второе сообщение 940 предоставляет указание второй передачи 945 UL для UE. По приему второго сообщения 940, «активное время» 930 (или, в некоторых случаях, третий таймер 930) останавливается и UE останавливает мониторинг канала 915 управления DL. В примере Фигуры 9B, тем не менее, «активное время» 950 запускается через «время смещения» 955 после конца второго принятого указания передачи 940 UL для UE, принятого по каналу 915 управления DL (NB-PDCCH в примере Фигуры 9B). В вариантах осуществления, в которых используются таймеры, например, в конце второго принятого указания передачи 940 UL для UE, UE запускает второй таймер 955. Продолжительность второго таймера 955 может быть или содержит период смещения. Например, второй таймер 955 может быть таймером HARQ-RTT, который содержит период смещения. Когда второй таймер истекает, UE запускает третий таймер 950, соответствующий «активному времени».

Несмотря на то, что примерные варианты осуществления Фигур 6A-9B описывают назначения DL и предоставления UL в качестве примера критериев остановки, настоящее раскрытие не ограничивается этими примерами. Наоборот, настоящее раскрытие предполагает использование альтернативных критериев остановки для «активного времени», например, посредством отправки других сообщений, определенных по NB-PDCCH, которые не являются назначением DL или предоставлением UL. Такое сообщение может, например, быть «приказом» для непосредственного входа в DRX (применяя OnDuration/DRX-цикл). Другим примером может быть отправка новых параметров «времени смещения»/«активного времени», чтобы откладывать «активное время» через «время смещения» по отношению к принятому сообщению NB-PDCCH. Это может быть выполнено, чтобы указать UE, что оно временно не может быть обслужено (например, из-за слишком большого числа UE, обслуживаемых в настоящее время).

Фигура 10 является блок-схемой примерных операций DRX, в соответствии с некоторыми вариантами осуществления. На этапе 1005, UE осуществляет мониторинг канала управления DL (например, NB-PDCCH) в течение Времени OnDuration или Активного Времени. Если на этапе 1010 истекает либо Время OnDuration либо Активное Время, поток переходит к этапу 1015 и UE входит в режим DRX и ожидает наступления следующего OnDuration. В течение времени, которое UE ожидает наступления следующего OnDuration, UE не осуществляет мониторинг канала управления DL. На этапе 1020, происходит наступление следующего OnDuration. На этапе 1025, UE запускает таймер OnDuration. Как только таймер OnDuration запущен, поток возвращается к этапу 1005 и UE осуществляет мониторинг канала управления нисходящей линии связи (например, NB-PDCCH) в течение Времени OnDuration или Активного Времени.

В качестве альтернативы, в течение мониторинга NB-PDCCH на этапе 1005 поток может переходить к этапу 1030, если UE принимает сообщение по каналу управления нисходящей линии связи (например, назначение планирования DL или предоставление UL).

В некоторых случаях, на этапе 1035, сообщение NB-PDCCH, принятое на этапе 1030, может быть приказом DRX. В таком сценарии, поток переходит к этапу 1015, где UE входит в DRX и ожидает следующего наступления OnDuration. С того момента, операции DRX проходят как описано выше.

В некоторых случаях, на этапе 1040 UE определяет содержимое сообщения, принятого по каналу управления нисходящей линии связи. Если на этапе 1040 UE определяет, что принятое сообщение является предоставлением UL, поток переходит к этапу 1045, где UE передает данные SRB и/или DRB UL по совместно используемому каналу UL (NB-PUSCH в примере Фигуры 10). В качестве альтернативы, на этапе 1040 UE может определять, что принятое сообщение является назначением планирования DL. В таком сценарии, поток переходит к этапу 1050, где UE принимает и декодирует данные SRB и/или DRB по совместно используемому каналу DL (NB-PDSCH в примере Фигуры 10). На этапе 1055, UE передает отклик HARQ по совместно используемому каналу UL (например, NB-PUSCH). В некоторых вариантах осуществления, например, отклик HARQ может быть сообщением ACK или сообщением NACK.

Поток затем переходит к этапу 1060, где UE ожидает в течение «времени смещения». В некоторых вариантах осуществления, UE может запускать таймер. В некоторых вариантах осуществления, таймер может быть запущен либо после выполнения ассоциированной передачи UL (например, когда UE определяет, что принятое сообщение является предоставлением UL), либо в конце принятого указания передачи DL или UL для UE (например, когда UE определяет, что принятое сообщение является назначением планирования DL). Таким образом, продолжительность таймера может содержать величину времени, которое UE ожидает после отправки передачи UL на этапе 1045 до того, как UE запускает «активное время», или величину времени, которое UE ожидает после конца указания передачи DL или UL на этапе 1030 до того, как UE запускает «активное время». После ожидания в течение «времени смещения» на этапе 1060 (или, в некоторых вариантах осуществления, истечения таймера с продолжительностью времени смещения), поток переходит к этапу 1065. На этапе 1065, UE запускает активное время. В некоторых вариантах осуществления, UE может запускать другой таймер с продолжительностью, которая является величиной времени, которое UE осуществляет мониторинг канала управления DL (например, NB-PDCCH) до того, как UE входит в режим DRX. После запуска активного времени на этапе 1065, поток возвращается к этапу 1005, где UE осуществляет мониторинг NB-PDCCH в течение продолжительности «активного времени».

Фигура 11 является блок-схемой способа 1100 в UE, в соответствии с некоторыми вариантами осуществления. Способ начинается на этапе 1104, где UE осуществляет мониторинг канала управления DL в течение продолжительности, по меньшей мере, первого таймера. В некоторых вариантах осуществления, первый таймер может быть onDurationTimer цикла прерывистого приема. В некоторых вариантах осуществления, первый таймер может быть drx-InactivityTimer. В некоторых вариантах осуществления, первый таймер может быть таймером повторной передачи прерывистого приема.

На этапе 1108, UE принимает, по находящемуся под мониторингом каналу управления DL, указание передачи DL или UL для UE. В некоторых вариантах осуществления, указание передачи DL или UL для UE может содержать информацию о продолжительности, по меньшей мере, второго и третьего таймеров. На этапе 1112, после приема указания передачи DL или UL для UE, UE останавливает мониторинг первого таймера. После того, как первый таймер остановлен, UE не требуется осуществлять мониторинг канала управления нисходящей линии связи.

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

На этапе 1120, UE запускает второй таймер после приема указания для передачи нисходящей линии связи или восходящей линии связи для UE, причем продолжительность второго таймера содержит период смещения. В некоторых вариантах осуществления, второй таймер может быть запущен либо: после выполнения ассоциированной передачи UL; либо в конце принятого указания передачи DL или UL для UE. В некоторых вариантах осуществления, второй таймер может быть таймером Времени Кругового Обращения (RTT) Гибридного Автоматического Запроса Повторной Передачи (HARQ), который содержит период смещения. В качестве альтернативы, на этапе 1120, UE запускает второй таймер после приема указания для передачи нисходящей линии связи или восходящей линии связи для UE.

На этапе 1124, когда второй таймер истекает, UE запускает третий таймер. В некоторых вариантах осуществления, способ может содержать мониторинг канала управления DL в течение продолжительности третьего таймера. В некоторых вариантах осуществления, по меньшей мере, один из первого таймера и третьего таймера может быть drx-InactivityTimer. В некоторых вариантах осуществления, по меньшей мере, один из первого таймера и третьего таймера может быть таймером повторной передачи прерывистого приема.

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

Фигура 12 является блок-схемой способа 1200 в сетевом узле, в соответствии с некоторыми вариантами осуществления. Способ начинается на этапе 1204, где сетевой узел определяет продолжительность первого таймера и продолжительность второго таймера, причем первый и второй таймеры предназначены для использования UE, чтобы управлять операцией прерывистого приема, при этом продолжительность первого таймера содержит период смещений. В некоторых вариантах осуществления, продолжительность первого таймера может содержать одно из: величину времени, которое UE ожидает после отправки передачи UL, ассоциированной с указанной передачей DL или UL для UE до того, как UE запускает второй таймер; и величину времени, которое UE ожидает после конца указания передачи DL или UL для UE до того, как UE запускает второй таймер. В некоторых вариантах осуществления, первый таймер может быть таймером Времени Кругового Обращения (RTT) Гибридного Автоматического Запроса Повторной Передачи (HARQ). В некоторых вариантах осуществления, продолжительность второго таймера может содержать величину времени, которое UE осуществляет мониторинг канала управления DL до входа в режим прерывистой передачи. А некоторых вариантах осуществления, второй таймер может быть drx-InactivityTimer. В некоторых вариантах осуществления, второй таймер может быть таймером повторной передачи прерывистого приема.

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

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

Фигура 13 является структурной схемой примерного UE, в соответствии с некоторыми вариантами осуществления. UE 510 может относиться к любому типу беспроводного устройства, осуществляющего связь с узлом и/или другим беспроводным устройством в системе сотовой или мобильной связи. Примеры UE 510 включают в себя мобильный телефон, интеллектуальный телефон, PDA (Персональный Цифровой Помощник), портативный компьютер (например, лэптоп, планшет), датчик, модем, устройство связи машинного типа (MTC), устройство связи типа машина-с-машиной (M2M), оборудование со встраиваемым лэптопом (LEE), оборудование с монтируемым лэптопом (LME), USB-ключи, устройство с возможностью D2D, или другое устройство, которое может обеспечивать беспроводную связь. UE 510 также может именоваться беспроводным устройством, станцией (STA), устройством, или терминалом в некоторых вариантах осуществления. UE 510 включает в себя приемопередатчик 1310, схему 1320 обработки, и память 1330. В некоторых вариантах осуществления, приемопередатчик 1310 способствует передаче беспроводных сигналов к и приему беспроводных сигналов от сетевого узла 515 (например, через антенну 1340), схема 1320 обработки исполняет инструкции, чтобы предоставлять некоторые или всю из функциональности, описанной выше как предоставляемой UE 510, и память 1330 хранит инструкции, исполняемые схемой 1320 обработки.

Схема 1320 обработки может включать в себя любое подходящее сочетание аппаратного обеспечения и программного обеспечения, реализованное в одном или более модулях, чтобы исполнять инструкции и манипулировать данными, чтобы выполнять некоторые или все из описанных функций UE 510, такие как функции UE 510, описанные выше в отношении Фигур 1-12. В некоторых вариантах осуществления, схема 1320 обработки может включать в себя, например, один или более компьютеры, один или более центральные блоки обработки (CPU), один или боле микропроцессоры, одно или более приложения, одну или более проблемно-ориентированные интегральные микросхемы (ASIC), одну или более программируемые вентильные матрицы (FPGA) и/или другую логику.

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

Друге варианты осуществления UE 510 могут включать в себя дополнительные компоненты за пределами тех, что показаны на Фигуре 13, которые могут отвечать за обеспечение определенных аспектов функциональности UE, включая любую функциональность, описанную выше, и/или любую дополнительную функциональность (включая любую функциональность, необходимую, чтобы поддерживать решение, описанное выше). В качестве лишь одного примера, UE 510 может включать в себя устройства ввода и цепи, устройства вывода, и один или более блоки или цепи синхронизации, которые могут быть частью схемы 1320 обработки. Устройства ввода включают в себя механизмы для ввода данных в UE 510. Например, устройства ввода могут включать в себя механизмы ввода, такие как микрофон, элементы ввода, дисплей, и т.д. Устройства вывода могут включать в себя механизмы для вывода данных в аудио, видео и/или бумажном формате. Например, устройства вывода могут включать в себя громкоговоритель, дисплей, и т.д.

Фигура 14 является структурной схемой примерного сетевого узла, в соответствии с некоторыми вариантами осуществления. Сетевой узел 515 может быть узлом радиосети любого типа или любым сетевым узлом, который осуществляет связь с UE и/или с другим сетевым узлом. Примеры сетевого узла 515 включают в себя eNodeB, Узел-B, базовую станцию, беспроводную точку доступа (например, точку доступа Wi-Fi), узел низкой мощности, базовую станцию приемопередатчика (BTS), ретранслятор, донорский узел управляющий ретрансляцией, точки передачи, узлы передачи, выносные радиочастотные блоки (RRU), выносные головки радиосвязи (RRH), узел радиосвязи многостандартного радио (MSR) такой как MSR BS, узлы в распределенной антенной системе (DAS), O&M, OSS, SON, узел позиционирования (например, E-SMLC), MDT, или любой другой подходящий сетевой узел. Сетевые узлы 515 могут быть развернуты по всей сети 500 в качестве однородного развертывания, неоднородного развертывания, или смешанного развертывания. Однородное развертывание может, главным образом, описывать развертывание состоящее из сетевых узлов 515 одинакового (или сходного) типа и/или сходного покрытия и размеров соты и расстояний между местами. Неоднородное развертывание может, главным образом, описывать развертывания, использующие сетевые узлы 515 разнообразных типов с разными размерами соты, мощностями передачи, емкостями, и расстояниями между местами. Например, неоднородное развертывание может включать в себя множество узлов низкой мощности помещенных во всем размещении макро-соты. Смешанные развертывания могут включать в себя смесь однородных участков и неоднородных участков.

Сетевой узел 515 может включать в себя одно или более из приемопередатчика 1410, схемы 1420 обработки, памяти 1430, и сетевого интерфейса 1440. В некоторых вариантах осуществления, приемопередатчик 1410 способствует передаче беспроводных сигналов к и приему беспроводных сигналов от UE 510 (например, через антенну 1450), схема 1420 обработки исполняет инструкции, чтобы обеспечивать некоторую или всю функциональность, описанную выше как обеспечиваемую сетевым узлом 515, память 1430 хранит инструкции, исполняемые схемой 1420 обработки, и сетевой интерфейс 1440 сообщает сигналы сетевым компонентам внутреннего интерфейса, таким как шлюз, коммутатор, маршрутизатор, Интернет, Телефонная Коммутируемая Сеть Общего Пользования (PSTN), узлы базовой сети или контролеры 130 радиосети, и т.д.

Схема обработки 1420 может включать в себя любое подходящее сочетание аппаратного обеспечения и программного обеспечения, реализованного в одном или более модулях, чтобы исполнять инструкции и манипулировать данными, чтобы выполнять некоторые или все из описанных функций сетевого узла 515, такие как те, что описаны выше в отношении Фигуры 1-12 выше. В некоторых вариантах осуществления, схема 1420 обработки может включать в себя, например, один или более компьютеры, один или более центральные блоки обработки (CPU), один или более микропроцессоры, одно или более приложения, и/или другую логику.

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

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

Другие варианты осуществления сетевого узла 515 могут включать в себя дополнительные компоненты за пределами тех, что показаны на Фигуре 14, которые могут отвечать за обеспечение определенных аспектов функциональности узла радиосети, включая любую функциональность, описанную выше, и/или любую дополнительную функциональность (включая любую функциональность, необходимую, чтобы поддерживать решения, описанные выше). Сетевые узлы разнообразных других типов могут включать в себя компоненты с точно таким же физическим аппаратным обеспечением, но сконфигурированные (например, через программирование) для обеспечения других технологий радиодоступа, или могут представлять частично или целиком другие физические компоненты.

Фигура 15 является структурной схемой примерного контроллера радиосети или узла 130 базовой сети, в соответствии с некоторыми вариантами осуществления. Примеры сетевых узлов могут включать в себя центр коммутации подвижной связи (MSC), обслуживающий узел поддержки GPRS (SGSN), объект управления мобильностью (MME), контроллер радиосети (RNC), контроллер базовых станций (BSC), и т.д. Контроллер радиосети или узел 130 базовой сети включает в себя схему 1520 обработки, память 1530, и сетевой интерфейс 1540. В некоторых вариантах осуществления, схема 1520 обработки исполняет инструкции, чтобы обеспечивать некоторую или всю функциональность, описанную выше как обеспечиваемую сетевым узлом, память 1530 хранит инструкции, исполняемые схемой 1520 обработки, и сетевой интерфейс 1540 сообщает сигналы любому подходящему узлу, такому как шлюз, коммутатор, маршрутизатор, Интернет, Телефонная Коммутируемая Сеть Общего Пользования (PSTN), сетевые узлы 515, контроллеры радиосети или узлы 130 базовой сети, и т.д.

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

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

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

Другие варианты осуществления сетевого узла могут включать в себя дополнительные компоненты за пределами тех, что показаны на Фигуре 15, которые могут отвечать за обеспечение определенных аспектов функциональности сетевого узла, включая любую функциональность, описанную выше, и/или любую дополнительную функциональность (включая любую функциональность, необходимую, чтобы поддерживать решения, описанные выше).

Фигура 16 является структурной схемой примерного UE, в соответствии с некоторыми вариантами осуществления. UE 510 может включать в себя один или более модули. Например, UE 510 может включать в себя модуль 1610 определения, модуль 1320 связи, модуль 1630 приема, модуль 1640 ввода, модуль 1650 отображения, и любые другие подходящие модули. В некоторых вариантах осуществления, один или более из модуля 1610 определения, модуля 1620 связи, модуля 1630 приема, модуля 1640 ввода, модуля 1650 отображения, или любого другого подходящего модуля может быть реализован, используя схему обработки, такую как схема 1420 обработки, описанная выше в отношении Фигуры 14. В некоторых вариантах осуществления, функции двух или более разнообразных модулей могут быть объединены в едином модуле. UE 510 может выполнять способы для управления операциями DRX в режиме установленного соединения, описанные выше в отношении Фигур 1-12.

Модуль 1610 определения может выполнять функции обработки UE 510. Например, модуль 1610 определения может осуществлять мониторинг канала управления DL в течение продолжительности, по меньшей мере, первого таймера. В качестве другого примера, модуль 1610 определения может, после приема указания передачи DL или UL для UE, останавливать мониторинг первого таймера. После того как первый таймер остановлен, UE не требуется осуществлять мониторинг канала управления нисходящей линии связи. В еще одном другом примере, модуль 1610 определения может запускать второй таймер после приема указания для передачи нисходящей линии связи или восходящей линии связи для UE, причем продолжительность второго таймера содержит период смещения. В еще одном другом примере, модуль 1610 определения может, когда второй таймер истекает, запускать третий таймер. В качестве другого примера, модуль 1610 определения может осуществлять мониторинг канала управления DL в течение продолжительности третьего таймера. В качестве другого примера, модуль 1610 определения может входить в режим прерывистого приема, когда истекает третий таймер.

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

Модуль 1620 связи может выполнять функции передачи UE 510. Например, модуль 1620 связи может выполнять передачу UL, ассоциированную с указанной передачей DL или UL для UE. Модуль 1620 связи может передавать сообщения одному или более сетевым узлам 515 сети 500. Модуль 1620 связи может включать в себя передатчик и/или приемопередатчик, такой как приемопередатчик 1310, описанный выше в отношении Фигуры 13. Модуль 1620 связи может включать в себя схему, выполненную с возможностью беспроводным образом передачи сообщений и/или сигналов. В конкретных вариантах осуществления, модуль 1620 связи может принимать сообщения и/или сигналы для передачи от модуль 1610 определения. В некоторых вариантах осуществления, функции модуля 1620 связи, описанные выше, могут быть выполнены в одном или более особых модулях.

Модуль 1630 приема может выполнять функции приема UE 510. В качестве одного примера, модуль 1630 приема может принимать, по находящемуся под мониторингом каналу управления DL, указание передачи DL или UL для UE. В качестве другого примера, модуль приема 1630 может принимать сообщение, включающее в себя информацию о продолжительности, по меньшей мере, одного из второго и третьего таймеров. Модуль 1630 приема может включать в себя приемник и/или приемопередатчик, такой как приемопередатчик 1310, описанный выше в отношении Фигуры 13. Модуль 1630 приема может включать в себя схему, выполненную с возможностью беспроводным образом приема сообщений и/или сигналов. В конкретных вариантах осуществления, модуль 1630 приема может сообщать принятые сообщения и/или сигналы модулю 1610 определения. Функции модуль 1630 приема, описанные выше, могут, в некоторых вариантах осуществления, быть выполнены одним или более особыми модулями.

Модуль 1640 ввода может принимать ввод пользователя, предназначенный для UE 510. Например, модуль ввода может принимать нажатия клавиши, нажатие кнопки, касания, проводки, аудиосигналы, видеосигналы, и/или любые другие подходящие сигналы. Модуль ввода может включать в себя одну или более клавиши, кнопки, рычаги, переключатели, сенсорные экраны, микрофоны, и/или камеры. Модуль ввода может сообщать принятые сигналы модулю 1610 определения. Функции модуля 1640 ввода, описанные выше, могут, в некоторых вариантах осуществления, быть выполнены в одном или более особых модулях.

Модуль 1650 отображения может представлять сигналы на дисплее UE 510. Модуль 1650 отображения может включать в себя дисплей и/или любую надлежащую схему и аппаратное обеспечение, выполненные с возможностью представления сигналов на дисплее. Модуль 1650 отображения может принимать сигналы для представления на дисплее от модуля 1610 определения. Функции модуля 1650 отображения, описанные выше, могут, в некоторых вариантах осуществления, быть выполнены в одном или более особых модулях.

Модуль 1610 определения, модуль 1620 связи, модуль 1630 приема, модуль 1640 ввода, и модуль 1650 отображения могут включать в себя любую подходящую конфигурацию аппаратного обеспечения и/или программного обеспечения. UE 510 может включать в себя дополнительные модули за пределами тех, что показаны на Фигуре 16, которые могут отвечать за обеспечение любой подходящей функциональности, включая любую функциональность, описанную выше, и/или любую дополнительную функциональность (включая любую функциональность, необходимую, чтобы поддерживать разнообразные решения, описанные в данном документе).

Фигура 17 является структурной схемой примерного сетевого узла 515, в соответствии с некоторыми вариантами осуществления. Сетевой узел 515 может включать в себя один или более модули. Например, сетевой узел 515 может включать в себя модуль 1710 определения, модуль 1720 связи, модуль 1730 приема, и любые другие подходящие модули. В некоторых вариантах осуществления, один или более из модуля 1710 определения, модуля 1720 связи, модуля 1730 приема, или любого другого подходящего модуля может быть реализован, используя один или более процессоры, такие как схема 1420 обработки, описанная выше в отношении Фигуры 15. В некоторых вариантах осуществления, функции двух или более из разнообразных модулей могут быть объединены в едином модуле. Сетевой узел 515 может выполнять способы для управления операциями DRX в режиме установленного соединения, описанные выше в отношении Фигур 1-12.

Модуль 1710 определения может выполнять функции обработки сетевого узла 515. Например, модуль 1710 определения может определять продолжительность первого таймера и продолжительность второго таймера, причем первый и второй таймеры предназначены для использования UE для управления операцией прерывистого приема, при этом продолжительность первого таймера содержит период смещения. Модуль 1710 определения может включать в себя или быть включен в один или более процессоры, такие как схема 1420 обработки, описанная выше в отношении Фигуры 14. Модуль 1710 определения может включать в себя аналоговую и/или цифровую схему, выполненную с возможностью выполнения любой из функций модуля 1710 определения и/или схемы 1420 обработки, описанных выше. Функции модуля 1710 определения могут, в некоторых вариантах осуществления, быть выполнены в одном или более особых модулях.

Модуль 1720 связи может выполнять функции передачи сетевого узла 515. В качестве одного примера, модуль 1720 связи может отправлять, UE, информацию о продолжительности первого таймера и продолжительности второго таймера. В качестве другого примера, модуль 1720 связи может отправлять сообщение UE, включающее в себя информацию о продолжительности первого таймера и продолжительности второго таймера. В качестве еще одного другого примера, модуль 1720 связи может отправлять, UE, указание передачи DL или UL для UE. Модуль 1720 связи может передавать сообщения одному или более UE 510. Модуль 1720 связи может включать в себя передатчик или приемопередатчик, такой как приемопередатчик 1410, описанный выше в отношении Фигуры 14. Модуль 1720 связи может включать в себя схему, выполненную с возможностью беспроводным образом передачи сообщений и/или сигналов. В конкретных вариантах осуществления, модуль 1720 связи может принимать сообщения и/или сигналы для передачи от модуля 1710 определения или любого другого модуля. Функции модуля 1720 связи могут, в некоторых вариантах осуществления, быть выполнены в одном или более особых модулях.

Модуль 1730 приема может выполнять функции приема сетевого узла 515. Например, модуль 1730 приема может принимать, от UE, передачу UL, ассоциированную с указанной передачей DL или UL для UE. Модуль 1730 приема может принимать любую подходящую информацию от UE. Модуль 1730 приема может включать в себя приемник и/или приемопередатчик, такой как приемопередатчик 1420, описанный выше в отношении Фигуры 14. Модуль 1730 приема может включать в себя схему, выполненную с возможностью беспроводным образом приема сообщений и/или сигналов. В конкретных вариантах осуществления, модуль 1730 приема может сообщать принятые сообщения и/или сигналы модулю 1710 определения или любому другому подходящему модулю. Функции модуля 1730 приема могут, в некоторых вариантах осуществления, быть выполнены в одном или более особых модулях.

Модуль 1710 определения, модуль 1720 связи, и модуль 1730 приема могут включать в себя любую подходящую конфигурацию аппаратного обеспечения и/или программного обеспечения. Сетевой узел 515 может включать в себя дополнительные модули за пределами тех, что показаны на Фигуре 17, которые могут отвечать за обеспечение любой подходящей функциональности, включая любую функциональность, описанную выше, и/или любую дополнительную функциональность (включая любую функциональность, необходимую, чтобы поддерживать разнообразные решения, описанные в данном документе).

Нижеследующий текст предоставляет дополнительное пояснение, касательно некоторых вариантов осуществления и предложений, описываемых в данном документе, и не должен рассматриваться как ограничивающий объем изобретения. Функциональность для DRX в режиме установленного соединения в унаследованном LTE и eMTC основана на следующих параметрах (исключая параметры короткой DRX):

- onDurationTimer

- drxStartOffset (сигнализируется как longDRX-CycleStartOffset в 36.331)

- longDRX-Cycle (сигнализируется как longDRX-CycleStartOffset в 36.331)

- drx-InactivityTimer

- HARQ-RTT-Timer

- drx-RetransmissionTimer

Первые три параметра могут быть повторно использованы как есть для NB-IoT за исключением диапазонов значения, которые необходимо изучить дополнительно. Два последних параметра относятся к тому, каким образом работает операция HARQ. Параметр drx-InactivityTimer используется, чтобы управлять тем, когда UE входит в DRX после неактивности (при условии, что не сигнализируется MAC CE), так что главным образом будет обсуждаться обработка данного параметра. Поскольку уже принято решение поддерживать только один процесс HARQ из расчета на направление и если предполагается операция полудуплекса для UE, то изменения/упрощения этих трех последних трех параметров могут обсуждаться и выполняться, даже если еще полностью не принято решение в отношении подробностей операций HARQ.

Из-за того, что возможности передачи/приема UE NB-IoT являются полудуплексом и имеют только один процесс HARQ из расчета на направление, может быть изменена/упрощена обработка таймера неактивности DRX и таймеров повторной передачи HARQ для DRX в режиме установленного соединения. Вследствие этого, в соответствии с некоторыми вариантами осуществления, унаследованные параметры drxStartOffset, longDRX-Cycle и QnDurationTimer могут быть повторно использованы как есть для DRX в режиме установленного соединения с диапазонами значения, подходящими для NB-IoT.

В нижеследующих примерах предполагается, что высокоуровневая концепция для операций HARQ применительно к NB-IoT является сходной с eMTC. Подводя итог, предполагается следующее:

- Данные нисходящей линии связи/восходящей линии связи планируются посредством сообщения по каналу управления нисходящей линии связи NB-PDCCH.

- Данные нисходящей линии связи/восходящей линии связи передаются по совместно используемым каналам NB-PDSCH и NB-PUSCH соответственно.

- Отклик HARQ передается по каналам NB-PDCCH/NB-PUSCH.

- Асинхронный HARQ используется как в нисходящей линии связи, так и восходящей линии связи.

В предстоящих вариантах осуществления операции DRX объясняются посредством применения этих допущений HARQ. Отметим, что продолжительности времени передач и смещений между передачами могут варьироваться по длине. В соответствии с одним вариантом осуществления, мы использовали унаследованное поведение для операции DRX с drx-InactivityTimer и применили его к NB-IoT. Таймер запускается каждый раз, когда присутствует новая передача, запланированная либо в UL, либо DL по NB-PDCCH. В данном случае передача нисходящей линии связи является успешной и отсутствуют запланированные дополнительные данные, так что UE переходит в сон DRX по истечению таймера.

В соответствии с другим вариантом осуществления, присутствует одна повторная передача HARQ в нисходящей линии связи, при использовании унаследованных таймеров DRX в NB-IoT. Для этого используются таймеры HARQ-RTT-Timer/drx-RetransmmissionTimer и последний отменяется, когда принимается повторная передача.

В сравнении с унаследованным LTE HARQ восходящей линии связи для eMTC (и LAA) был изменен с синхронного на асинхронный. Здесь предполагается, что вероятно существует потребность в введении нечто подобного HARQ-RTT-Timer/drx-RetransmmissionTimer также для восходящей линии связи из-за асинхронного HARQ. Применительно к NB-IoT предполагается, что такие таймеры потребуются при обсуждении унаследованной базы для DRX. Таким образом, в соответствии с другим вариантом осуществления, присутствует повторная передача HARQ в восходящей линии связи с предполагаемым новым таймером. Сходно со случаем нисходящей линии связи таймер отменяется, когда UE обнаруживает, что повторная передача запланирована. Отметим, что мы называем его drx-RetransmmissionTimer даже если он фактически не является «Таймером Повторной Передачи», поскольку UE не знает результата передачи. Он также может именоваться HARQ-FeedbackWindowTimer.

Как обсуждалось, унаследованные таймеры DRX могут быть использованы также для NB-IoT. Данная унаследованная схема была разработана с учетом случаев использования Мобильного Широкополосного канала, которые включают в себя несколько процессов HARQ в обоих направлениях и операции полного дуплекса (за исключением конечно TDD). Для этих случаев использования (за исключением VoLTE) потребление питания UE в связи с пробуждением на несколько дополнительных субкадров здесь не является проблемой. Тем не менее, применительно к NB-IoT, очень важно, чтобы активное время UE (т.е., при мониторинге NB-PDCCH) было настолько мало, насколько это возможно также в течение режима установленного соединения для многих его случаев использования с тем, чтобы иметь хорошее время работы UE от батареи.

Одна проблема с унаследованным подходом состоит в том, каким образом установить значение drx-InactivityTimer.

- короткое значение: Это хорошо для потребления питания UE, но будет вводить дополнительное время ожидания в случае, когда присутствуют повторные передачи HARQ DL, поскольку таймер (вероятно) истечет в момент когда закончится повторная передача и, тогда новые данные должны ждать нового наступления OnDuration. Недостаток в связи с введением данного дополнительного времени ожидания состоит в том, что UE требуется находиться в режиме установленного соединения в течение более длительного времени. Дополнительно, длительное время, проведенное в режиме установленное соединения (в частности, если также используются длинные циклы DRX), может привести к риску больших вариаций канала и потере синхронизации.

- длинное значение: Это не хорошо для потребления питания UE, но не вводит дополнительного времени ожидания так, что будет существовать возможность планирования UE быстрее для того, чтобы оно быстрее входило в режим ожидания.

В соответствии с конкретными вариантами осуществления, решение вышеизложенной проблемы будет в изменении drx-InactivityTimer таким образом, что он повторно запускается в каждый прием NB-PDCCH, т.е., независимо от того, является ли это новой передачей или повторной передачей (как восходящей линии связи, так и нисходящей линии связи). Тогда в то же самое время может использовано короткое значение drx-InactivityTimer поскольку не вводится дополнительного времени ожидания. Если это делается, тогда отсутствует потребность в каком-либо HARQ-RTT-Timer/drx-RetransmissionTimer, поскольку только один таймер может быть использован, чтобы контролировать как повторные передачи UL/DL, так и неактивность. Это также уменьшает сложность UE, поскольку требуется только один таймер. В соответствии с данным вариантом осуществления, drx-InactivityTimer повторно запускается по приему любой DCI по NB-PDCCH.

В соответствии с дополнительными вариантами осуществления, отсутствует потребность в таймерах HARQ-RTT-Timer и drx-RetransmissionTimer как для нисходящей линии связи, так и восходящей линии связи, если изменен критерий для запуска таймера drx-InactivityTimer. Успешный прием NB-PDCCH в UE будет сопровождаться передачей восходящей линии связи, которая содержит либо данные SRB/DRB (в случае предоставления UL), либо отклик HARQ (в случае назначения DL). Если предполагается, что UE не требуется осуществлять мониторинг NB-PDCCH после того, как оно запланировано, не раньше чем после передачи, тогда могут быть сделаны дополнительные изменения в отношении запуска/перезапуска drx-InactivityTimer. Тогда таймер должен быть остановлен в каждый успешный прием NB-PDCCH и запущен после конца передачи восходящей линии связи, которая была инициирована сообщением NB-PDCCH. Это позволит UE иметь возможность выключения своего приемника (и потенциально входа в спящий режим) в течении больших наступлений времени в режиме установленного соединения в особенности, если промежутки времени между NB-PDCCH/NB-PDSCH/NB-PUSCH длинные.

В соответствии с дополнительными вариантами осуществления, остановка drx-InactivityTimer в успешный прием чего угодно по NB-PDCCH и запуск его после результирующей передачи восходящей линии связи (DRB/SRB или отклика HARQ) позволяют UE уменьшать время мониторинга NB-PDCCH и, следовательно, потребление питания. Таким образом, в соответствии с некоторыми вариантами осуществления, критерий запуска и остановки для drx-InactivityTimer меняется для UE NB-IoT, чтобы управлять DRX в режиме установленного соединения. В соответствии с некоторыми вариантами осуществления, критерий запуска drx-InactivityTimer должен быть изменен на после передачи NB-PUSCH HARQ ACK или данных DRB/SRB для назначения нисходящей линии связи и предоставления восходящей линии связи, соответственно. В соответствии с некоторыми вариантами осуществления, критерий остановки drx-InactivityTimer должен быть изменен на когда принимается назначение нисходящей линии связи или предоставление восходящей линии связи. В соответствии с некоторыми вариантами осуществления, HARQ-RTT-Tmier и drx-RetransmissionTimer могут не использоваться в NB-IoT. В соответствии с некоторыми вариантами осуществления, если drx-InactivityTimer истекает, то UE не требуется осуществлять мониторинг NB-PDCCH до следующего наступления OnDuration.

Большая часть случаев использования NB-IoT не включает в себя одновременный трафик восходящей линии связи/нисходящей линии связи, а вместо этого большинство случаев использования основываются на шаблоне трафика типа запрос-ответ, где IP-пакет, отправленный в одном направлении, сопровождается ответом в другом (потенциально повторенный в соответствии с некоторым шаблоном несколько раз применительно к некоторым случаям использования). Данный шаблон трафика также является истинным для процедур сигнализации L3 (NAS/RRC). Как следствие, после того, как отклик HARQ или данные SRB/DRB были переданы в восходящей линии связи посредством UE, не будет какой-либо активности NB-PDCCH в течение, по меньшей мере, одного времени кругового обращения HARQ. В течение данного времени UE NB-IoT может быть разрешено не осуществлять мониторинг NB-PDCCH. Таким образом, в соответствии с некоторыми вариантами осуществления, изменением в обработке drx-InactivityTimer будет не запуск его до значения смещения после передачи восходящей линии связи.

В большинстве случаев использования отсутствует необходимость в том, чтобы UE осуществляло мониторинг NB-PDCCH до, по меньшей мере, одного времени кругового обращения после конца передачи восходящей линии связи. Таким образом, в соответствии с некоторыми вариантами осуществления, запуск drx-InactivityTimer должен быть выполнен через значение смещения после передачи восходящей линии связи (DRB/SRB или отклика HARQ), чтобы позволить UE уменьшить время мониторинга NB-PDCCH. Значение данного смещения зависит, как описано выше, от времени кругового обращения, но также от исполнения физического слоя NB-PDCCH, например, выравниваний времени и того, каким образом мультиплексируются NB-PDCCH и NB-PDSCH. Значение даже может быть переменным в зависимости от исполнения физического слоя и класса покрытия UE. В соответствии с некоторыми вариантами осуществления, критерий запуска drx-InactivityTimer может быть установлен в, по меньшей мере, время кругового обращения после передачи восходящей линии связи, но подробности оставлены для FFS до тех пор, пока от RAN1 не станут доступны подробности в отношении исполнения NB-PDCCH/PDSCH нисходящей линии связи. В соответствии с некоторыми вариантами осуществления, полу-статичные параметры DRX в режиме установленного соединения для NB-IoT включаются как часть RrcCannectionReestablish, RrcConnectionSetup, RrcConnectionResume, т.е. как часть Msg3. В соответствии с некоторыми вариантами осуществления, полу-статичные параметры DRX в режиме установленного соединения должны быть применены непосредственно, когда принимаются в UE.

Модификации, дополнения, или пропуски могут быть выполнены в отношении систем и устройств, описываемых в данном документе, не отступая от объема раскрытия. Компоненты систем и устройств могут быть интегрированы или разделены. Более того, операции систем и устройств могут быть выполнены большим числом, меньшим числом, или другими компонентами. Дополнительно, операции систем и устройств могут быть выполнены, используя любую подходящую логику, содержащую программное обеспечение, аппаратное обеспечение, и/или другую логику. Используемое в данном документе «каждый» относится к каждому члену набора или каждому члену подмножества набора.

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

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

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

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

ACK Квитирование

AP Точка Доступа

BS Базовая Станция

BSC Контроллер Базовых Станций

BTS Базовая Станция Приемопередатчика

CPE Оборудование Установленное у Пользователя

D2D Устройство-с-устройством

DAS Распределенная Антенная Система

DCI Информация Управления Нисходящей Линии Связи

DL Нисходящая Линия Связи

DRB Радио Носитель Данных

DRX Прерывистый Прием

DTX Прерывистая Передача

eNB развитый Узел-B

EPDCCH Улучшенный Физический Канал Управления Нисходящей Линии Связи

FDD Дуплексная Связь с Частотным Разделением

HARQ Гибридный Автоматический Запрос Повторной Передачи

HSPA Высокоскоростной Пакетный Доступ

IoT Интернет-Вещей

LAN Локальная Сеть

LEE Оборудование со Встраиваемым Лэптопом

LME Оборудование с Монтируемым Лэптопом

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

M2M Машина-с-Машиной

MAN Городская Сеть

MCE Много-сотовый/многоадресный Объект Координации

MCS Схема уровня модуляции и кодирования

MIMO Множественный Ввод Множественный Вывод

MR Отграничение Измерения

MSR Многостандартное Радио

NACK Отрицательное Квитирование

NAS Слой без Доступа

NB Узкополосный

NB-IoT Узкополосный Интернет-Вещей

NB-PDCCH Узкополосный Физический Канал Управления Нисходящей Линии Связи

NB-PDSCH Узкополосный Физический Совместно Используемый Канал Нисходящей Линии Связи

NB-PUSCH Узкополосный Физический Совместно Используемый Канал Восходящей Линии Связи

NPDCCH Узкополосный Физический Канал Управления Нисходящей Линии Связи

NPDSCH Узкополосный Физический Совместно Используемый Канал Нисходящей Линии Связи

NPUSCH Узкополосный Физический Совместно Используемый Канал Восходящей Линии Связи

OFDM Мультиплексирование с Ортогональным Частотным Разделением

PDCCH Физический Канал Управления Нисходящей Линии Связи

PDSCH Физический Совместно Используемый Канал Нисходящей Линии Связи

PMI Индекс Матрицы Предварительного Кодирования

PRB Физический Блок Ресурсов

PSTN Телефонная Коммутируемая Сеть Общего Пользования

PHICH Физический Канал Индикатора Гибридного ARQ

PUSCH Физический Совместно Используемый Канал Восходящей Линии Связи

PUCCH Физический Канал Управления Восходящей Линии Связи

RB Блок Ресурсов

RI Индикатор Ранга

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

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

RRH Выносная Головка Радиосвязи

RRU Выносной Радиочастотный Блок

RTT Время Кругового Обращения

SAW Пауза-и-Ожидание

SRB Радио Носитель Сигнализации

TDD Дуплексная Связь с Временным Разделением

TFRE Частотно-Временной Элемент Ресурса

UCI Информация управления Восходящей Линии Связи

UE Оборудование Пользователя

UL Восходящая Линия Связи

WAN Глобальная Сеть

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

1. Способ в оборудовании пользователя (UE) (510), содержащий этапы, на которых:

осуществляют (1104) мониторинг канала (610, 715, 810, 915) управления нисходящей линии связи в течение продолжительности, по меньшей мере, первого таймера (630, 725, 825, 925);

принимают (1108) по находящемуся под мониторингом каналу управления нисходящей линии связи указание (605, 705, 805, 905) передачи нисходящей линии связи или восходящей линии связи для UE;

после этапа, на котором принимают указание передачи нисходящей линии связи или восходящей линии связи для UE, останавливают (1112) первый таймер, при этом после того, как первый таймер остановлен UE не требуется осуществлять мониторинг канала управления нисходящей линии связи;

выполняют (1116) передачу (635, 710, 830, 910) восходящей линии связи, ассоциированную с указанной передачей нисходящей линии связи или восходящей линии связи для UE;

запускают (1120) второй таймер (645, 735, 840, 935) после того, как принимают указание передачи нисходящей линии связи или восходящей линии связи для UE, причем продолжительность второго таймера содержит период смещения;

когда второй таймер истекает, запускают (1124) третий таймер (640, 730, 835, 930), при этом UE осуществляет мониторинг канала управления нисходящей линии связи в течение продолжительности третьего таймера,

при этом первый таймер содержит один из onDurationTimer цикла прерывистого приема, DRX, drx-InactivityTimer, и таймера повторной передачи DRX, и при этом третий таймер содержит drx-InactivityTimer.

2. Способ по п. 1, содержащий этап, на котором:

осуществляют вход в режим прерывистого приема, когда истекает третий таймер.

3. Способ по п. 1, в котором первый таймер является onDurationTimer цикла прерывистого приема.

4. Способ по п. 1, в котором первый таймер содержит таймер повторной передачи прерывистого приема.

5. Способ по п. 1, в котором второй таймер является таймером Времени Кругового Обращения (RTT) Гибридного Автоматического Запроса Повторной Передачи (HARQ), который содержит период смещения.

6. Способ по п. 1, в котором:

указание передачи нисходящей линии связи или восходящей линии связи для UE содержит назначение (605, 805) планирования нисходящей линии связи; и

передача восходящей линии связи, ассоциированная с указанной передачей нисходящей линии связи, содержит сообщение (635, 830) квитирования.

7. Способ по п. 1, в котором:

указание передачи нисходящей линии связи или восходящей линии связи для UE содержит предоставление (705, 905) восходящей линии связи; и

передача восходящей линии связи, ассоциированная с указанной передачей восходящей линии связи, содержит передачу (710, 910) данных в восходящей линии связи.

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

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

10. Способ по любому из пп. 1-9, в котором второй таймер запускается либо:

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

в конце принятого указания передачи нисходящей линии связи или восходящей линии связи для UE.

11. Способ в сетевом узле (515), содержащий этапы, на которых:

определяют (1204) продолжительность первого таймера (645, 735, 840, 935) и продолжительность второго таймера (640, 730, 835, 930), причем первый и второй таймеры предназначены для использования оборудованием пользователя (UE) (510), чтобы управлять операцией прерывистого приема, при этом продолжительность первого таймера содержит период смещения;

отправляют (1208), UE, информацию о продолжительности первого таймера и продолжительности второго таймера;

отправляют, UE, указание передачи нисходящей линии связи или восходящей линии связи для UE; и

принимают, от UE, передачу (635, 710, 830, 910) восходящей линии связи, ассоциированную с указанной передачей нисходящей линии связи или восходящей линии связи для UE,

при этом продолжительность первого таймера содержит одно из:

величины времени, которое UE ожидает после отправки передачи восходящей линии связи, ассоциированной с указанной передачей нисходящей линии связи или восходящей линии связи для UE, до того, как UE запускает второй таймер; и

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

при этом второй таймер является drx-InactivityTimer.

12. Способ по п. 11, в котором информация о продолжительности первого таймера и продолжительности второго таймера включена в указание (605, 705, 805, 905) передачи нисходящей линии связи или восходящей линии связи для UE.

13. Способ по п. 11, в котором этап, на котором отправляют, UE, информацию о продолжительности первого таймера и продолжительности второго таймера, содержит этап, на котором:

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

14. Способ по п. 11, в котором:

указание передачи нисходящей линии связи или восходящей линии связи для UE содержит назначение (605, 805) планирования нисходящей линии связи; и

передача восходящей линии связи, ассоциированная с указанной передачей нисходящей линии связи, содержит сообщение (635, 830) квитирования.

15. Способ по п. 11, в котором:

указание передачи нисходящей линии связи или восходящей линии связи для UE содержит предоставление (705, 905) восходящей линии связи; и

передача восходящей линии связи, ассоциированная с указанной передачей восходящей линии связи, содержит передачу (710, 910) данных в восходящей линии связи.

16. Способ по п. 11, в котором продолжительность второго таймера содержит величину времени, которое UE осуществляет мониторинг канала (610, 715, 810, 915) управления нисходящей линии связи до того, как входит в режим прерывистого приема.

17. Способ по п. 11, в котором первый таймер является таймером Времени Кругового Обращения (RTT) Гибридного Автоматического Запроса Повторной Передачи (HARQ).

18. Оборудование пользователя (UE) (510), содержащее:

схему (1320) обработки, причем схема обработки выполнена с возможностью:

мониторинга (1104) канала (610, 715, 810, 915) управления нисходящей линии связи в течение продолжительности, по меньшей мере, первого таймера (630, 725, 825, 925);

приема (1108) по находящемуся под мониторингом каналу управления нисходящей линии связи указания (605, 705, 805, 905) передачи нисходящей линии связи или восходящей линии связи для UE;

после приема указания передачи нисходящей линии связи или восходящей линии связи для UE, остановки (1112) мониторинга первого таймера, при этом после того, как первый таймер остановлен, UE не требуется осуществлять мониторинг канала управления нисходящей линии связи;

выполнения (1116) передачи (635, 710, 830, 910) восходящей линии связи, ассоциированной с указанной передачей нисходящей линии связи или восходящей линии связи для UE;

запуска (1120) второго таймера (645, 735, 840, 935), после приема указания передачи нисходящей линии связи или восходящей линии связи для UE, причем продолжительность второго таймера содержит период смещения;

когда второй таймер истекает, запуска (1124) третьего таймера (640, 730, 835, 930), при этом UE осуществляет мониторинг канала управления нисходящей линии связи в течение продолжительности третьего таймера,

при этом первый таймер содержит один из onDurationTimer цикла DRX, drx-InactivityTimer, и таймера повторной передачи DRX, и при этом третий таймер содержит drx-InactivityTimer.

19. UE по п. 18, в котором схема обработки выполнена с возможностью:

входа в режим прерывистого приема, когда истекает третий таймер.

20. UE по п. 18, в котором первый таймер является onDurationTimer цикла прерывистого приема.

21. UE по п. 18, в котором первый таймер является drx-InactivityTimer.

22. UE по п. 18, в котором первый таймер содержит таймер повторной передачи прерывистого приема.

23. UE по п. 18, в котором второй таймер является таймером Времени Кругового Обращения (RTT) Гибридного Автоматического Запроса Повторной Передачи (HARQ), который содержит период смещения.

24. UE по п. 18, в котором:

указание передачи нисходящей линии связи или восходящей линии связи для UE содержит назначение (605, 805) планирования нисходящей линии связи; и

передача восходящей линии связи, ассоциированная с указанной передачей нисходящей линии связи, содержит сообщение (635, 830) квитирования.

25. UE по п. 18, в котором:

указание передачи нисходящей линии связи или восходящей линии связи для UE содержит предоставление (705, 905) восходящей линии связи; и

передача восходящей линии связи, ассоциированная с указанной передачей восходящей линии связи, содержит передачу (710, 910) данных в восходящей линии связи.

26. UE по п. 18, в котором указание передачи нисходящей линии связи или восходящей линии связи для UE содержит информацию о продолжительности, по меньшей мере, одного из второго и третьего таймеров.

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

28. UE по любому из пп. 18-27, в котором схема обработки выполнена с возможностью запуска второго таймера либо:

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

в конце принятого указания передачи нисходящей линии связи или восходящей линии связи для UE.

29. Сетевой узел (515), содержащий:

схему (1420) обработки, причем схема обработки выполнена с возможностью:

определения (1204) продолжительности первого таймера (645, 735, 840, 935) и продолжительности второго таймера (640, 730, 835, 930), причем первый и второй таймеры предназначены для использования оборудованием пользователя (UE) (510), чтобы управлять операцией прерывистого приема, при этом продолжительность первого таймера содержит период смещения;

отправки (1208), UE, информации о продолжительности первого таймера и продолжительности второго таймера;

отправки, UE, указания передачи нисходящей линии связи или восходящей линии связи для UE; и

приема, от UE, передачи (635, 710, 830, 910) восходящей линии связи, ассоциированной с указанной передачей нисходящей линии связи или восходящей линии связи для UE,

при этом продолжительность первого таймера содержит одно из:

величины времени, которое UE ожидает после отправки передачи восходящей линии связи, ассоциированной с указанной передачей нисходящей линии связи или восходящей линии связи для UE, до того, как UE запускает второй таймер; и

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

при этом второй таймер является drx-InactivityTimer.

30. Сетевой узел по п. 29, в котором информация о продолжительности первого таймера и продолжительности второго таймера включена в указание (605, 705, 805, 905) передачи нисходящей линии связи или восходящей линии связи для UE.

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

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

32. Сетевой узел по п. 29, в котором:

указание передачи нисходящей линии связи или восходящей линии связи для UE содержит назначение (605, 805) планирования нисходящей линии связи; и

передача восходящей линии связи, ассоциированная с указанной передачей нисходящей линии связи, содержит сообщение (635, 830) квитирования.

33. Сетевой узел по п. 29, в котором:

указание передачи нисходящей линии связи или восходящей линии связи для UE содержит предоставление (705, 905) восходящей линии связи; и

передача восходящей линии связи, ассоциированная с указанной передачей восходящей линии связи, содержит передачу (710, 910) данных в восходящей линии связи.

34. Сетевой узел по п. 29, в котором продолжительность второго таймера содержит величину времени, которое UE осуществляет мониторинг канала (610, 715, 810, 915) управления нисходящей линии связи до того, как входит в режим прерывистого приема.

35. Сетевой узел по п. 29, в котором первый таймер является таймером Времени Кругового Обращения (RTT) Гибридного Автоматического Запроса Повторной Передачи (HARQ).