ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Изобретение относится к способам для указания конфигурации восходящей линии связи/ нисходящей линии связи для дуплексной связи с временным разделением для мобильной станции. Изобретение также представляет мобильную станцию и базовую станцию для участия в способах, описанных в документе.
УРОВЕНЬ ТЕХНИКИ
Долгосрочное развитие систем связи (LTE)
Системы мобильной связи третьего поколения (3G) на основе технологии радиодоступа WCDMA (широкополосный множественный доступ с кодовым разделением) являются развертываемыми в широком масштабе по всему миру. Первый шаг в расширении или развитии этой технологии предусматривает внедрение Высокоскоростного пакетного доступа в нисходящей линии связи (HSDPA) и усовершенствованной восходящей линии связи, также именуемой «Высокоскоростной пакетный доступ в восходящей линии связи» (HSUPA), обеспечивающий технологию радиодоступа, являющуюся весьма конкурентоспособной.
Чтобы подготовиться к дальнейшему росту запросов пользователей и выдержать конкуренцию с новыми технологиями радиодоступа, консорциум 3GPP предложил новую систему мобильной связи, которая получила название «Долгосрочное развитие систем связи» (LTE). LTE разработана для удовлетворения потребностей в несущих для транспортировки высокоскоростных данных и мультимедиа, а также поддержки высокопроизводительной передачи речи с ориентацией на следующее десятилетие. Способность обеспечивать высокие битовые скорости является ключевым показателем для LTE.
Технические требования рабочих элементов (WI) по Долгосрочному развитию систем связи 3GPP (LTE), именуемые «Усовершенствованный наземный радиодоступ UMTS» (UTRA) и «Универсальная наземная сеть радиодоступа UMTS» (UTRAN) завершены в виде Версии 8 (LTE Rel.8). Система LTE представляет эффективный пакетный радиодоступ и сети радиодоступа, которые обеспечивают полные функциональные возможности на основе IP-протокола с малой задержкой и низкой стоимости. В LTE масштабируемые множественные полосы передачи заданы такими как 1,4, 3,0, 5,0, 10,0, 15,0 и 20,0 МГц, для обеспечения гибкого развертывания системы с использованием данного спектра. На нисходящей линии связи был принят радиодоступ на основе мультиплексирования с ортогональным частотным разделением (OFDM) благодаря свойственной ему невосприимчивости к многолучевым помехам (MPI) вследствие низкой скорости передачи символов, использования циклического префикса (CP) и совместимости с различными компоновками полосы передачи. Радиодоступ на основе множественного доступа с частотным разделением с одной несущей (SC-FDMA) применялся на восходящей линии связи, поскольку предоставление услуг для большой зоны обслуживания имело приоритет над повышением пиковой скорости передачи битов с учетом ограниченной мощности передачи пользовательского оборудования (UE). В версии Rel. 8/9 LTE используются многие ключевые способы пакетного радиодоступа, включающие в себя способы канальной передачи по схеме с множественными входами и множественными выходами (MIMO), и осуществляется высокоэффективная структура сигнализации управления.
Архитектура LTE
Общая архитектура показана на Фиг.1, и более конкретное представление архитектуры E-UTRAN дается на Фиг.2. E-UTRAN состоит из Усовершенствованного узла B (eNodeB), обеспечивающего протокольные окончания плоскости пользователя (PDCP/RLC/MAC/PHY) E-UTRAN и плоскости управления (RRC) по направлению к пользовательскому оборудованию (UE). eNodeB (eNB) обеспечивает «хост» для уровней физического (PHY), доступа к среде передачи (MAC), управления радиоканалом (RLC) и протокола управления передачей пакетных данных (PDCP), которые включают в себя функциональность компрессии заголовков и шифрования в плоскости пользователя. Он также обеспечивает функциональность управления радиоресурсами (RRC), соответствующую плоскости управления. Он выполняет многие функции, включая управление радиоресурсами, управление допуском (в сеть), планирование, обеспечение соблюдения согласованного качества обслуживания (QoS) в восходящей линии связи, вещание информации о соте, шифрование/дешифрование данных плоскости пользователя и управления, и компрессию/декомпрессию заголовков пакетов нисходящей линии связи/восходящей линии связи в плоскости пользователя. Узлы eNodeB соединены друг с другом посредством интерфейса X2.
Узлы eNodeB также подключены посредством интерфейса S1 к Усовершенствованной базовой сети пакетной передачи (Evolved Packet Core, EPC), более конкретно к модулю управления мобильностью (MME) - посредством S1-MME и к обслуживающему шлюзу (SGW) - посредством S1-U. Интерфейс S1 поддерживает отношение "многие ко многим" между модулями MME/обслуживающими шлюзами и узлами eNodeB. SGW маршрутизует и пересылает пользовательские пакеты данных, также действуя в качестве якоря мобильности для плоскости пользователя в ходе хэндоверов между eNodeB и в качестве якоря мобильности между LTE и другими технологиями 3GPP (оконечными для интерфейса S4 и ретранслирующими трафик между системами 2G/3G и GW PDN). Для единиц пользовательского оборудования, находящихся в неактивном состоянии, SGW является концом тракта данных нисходящей линии связи и инициирует поисковый вызов, когда данные нисходящей линии связи поступают для пользовательского оборудования. Он администрирует и сохраняет контексты пользовательского оборудования, например, информацию параметров IP-службы передачи данных, внутрисетевой маршрутизации. Он также выполняет репликацию пользовательского трафика в случае правомерного перехвата.
MME является ключевым узлом управления для сети доступа LTE. Он отвечает за процедуру отслеживания и поискового вызова пользовательского оборудования в неактивном состоянии, включая в повторные передачи. Он принимает участие в процессе активации/деактивации канала передачи данных и также отвечает за выбор SGW для пользовательского оборудования при начальном подключении и во время хэндовера внутри LTE, подразумевающего изменение местоположения узла базовой сети (CN). Он отвечает за аутентификацию пользователя (путем взаимодействия с сервером собственных абонентов (HSS)). Сигнализация уровня без доступа (NAS) оканчивается на MME, и он также отвечает за генерацию и выделение временных идентификационных данных для единиц пользовательского оборудования. Он осуществляет проверку авторизации пользовательского оборудования для подключения в режиме ожидания (вызова) к Наземной сети мобильной связи общего пользования (PLMN) и обеспечивает соблюдение ограничений роуминга пользовательского оборудования. MME является оконечной точкой в сети для шифрования/защиты целостности для сигнализации NAS и ведет управление ключами (системы) защиты. MME также поддерживает правомерный перехват сигнализации. MME также обеспечивает в плоскости управления функцию для мобильности между сетями доступа LTE и 2G/3G с интерфейсом S3 с окончанием на MME от SGSN. MME также является окончанием интерфейса S6a в направлении к домашнему HSS для находящихся в роуминге единиц пользовательского оборудования.
Структура компонентной несущей в LTE (Версия 8)
Компонентная несущая нисходящей линии связи в LTE 3GPP (Версии 8 и последующих) в частотно-временной области подразделяется на так называемые подкадры. В LTE 3GPP (Версии 8 и последующих) каждый подкадр разделяется на два временных интервала (slot) нисходящей линии связи, как показано на Фиг.3, причем первый временной интервал нисходящей линии связи содержит область канала управления (область PDCCH) в первых символах OFDM. Каждый подкадр состоит из данного числа символов OFDM во временной области (12 или 14 символов OFDM в LTE 3GPP, Версии 8 и последующих), причем каждый символ OFDM распространяется по всей полосе частот компонентной несущей. Каждый из символов OFDM таким образом состоит из ряда символов модуляции, передаваемых на соответственных 
поднесущих, как также показано на Фиг.4.
При условии системы связи с несколькими несущими, например, применяющей OFDM, как например, используется в Долгосрочном развитии систем связи (LTE) по стандартам 3GPP, наименьший блок ресурсов, который может назначаться планировщиком, является единичным "ресурсным блоком". Блок физических ресурсов (PRB) определен в виде 
последовательных символов OFDM во временной области (например, 7 символов OFDM) и 
последовательных поднесущих в частотной области, как показано на Фиг.4 (например, 12 поднесущих для компонентной несущей). В LTE 3GPP (Версии 8), блок физических ресурсов, таким образом, состоит из 
ресурсных элементов, соответствующих одному временному интервалу во временной области и 180 кГц в частотной области (для получения дополнительной информации относительно ресурсной сетки нисходящей линии связи, см., например, документ TS 36.211 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)", раздел 6.2, доступный по адресу http://www.3gpp.org и включенный в документ путем ссылки).
Один подкадр состоит из двух временных интервалов, так что имеются 14 символов OFDM в подкадре, когда используется так называемый "обычный" CP (циклический префикс), и 12 символов OFDM в подкадре, когда используется так называемый "расширенный" CP. Для терминологии, в последующем частотно-временные ресурсы, эквивалентные таким 
последовательным поднесущим, распространяющихся по полному подкадру, именуются "парой ресурсных блоков", или эквивалентно "парой RB" или "парой PRB".
Термин "компонентная несущая" относится к комбинации нескольких ресурсных блоков в частотной области. В будущих версиях LTE термин "компонентная несущая" более не используется; вместо этого, термин заменяет "ячейка", которая относится к комбинации ресурсов нисходящей и необязательно восходящей линий связи. Связывание между частотой несущей для ресурсов нисходящей линии связи и частотой несущей для ресурсов восходящей линии связи указывается в системной информации, передаваемой на ресурсах нисходящей линии связи.
Подобные допущения для структуры компонентной несущей применяются к более поздним версиям также.
Логические и транспортные каналы
Уровень MAC обеспечивает услугу передачи данных для уровня RLC через логические каналы. Логические каналы являются либо логическими каналами управления, которые несут управляющие данные, такие как сигнализация RRC, либо логическими каналами трафика, которые несут данные плоскости пользователя. Вещательный канал управления (BCCH), канал управления поискового вызова (PCCH), общий канал управления (CCCH), групповой канал управления (MCCH) и выделенный канал управления (DCCH) являются логическими каналами управления. Выделенный канал передачи трафика (DTCH) и канал групповой (многоадресной) передачи трафика (MTCH) являются информационными логическими каналами.
Обмен данными от уровня MAC с физическим уровнем осуществляется через транспортные каналы. Данные мультиплексируются в транспортные каналы в зависимости от того, каким образом они передаются по эфиру. Транспортные каналы классифицируются как каналы нисходящей линии связи или восходящей линии связи, как изложено ниже. Вещательный канал (BCH), совместно-используемый канал нисходящей линии связи (DL-SCH), канал поискового вызова (PCH) и канал групповой (многоадресной) передачи (MCH) являются транспортными каналами нисходящей линии связи, тогда как совместно-используемый канал восходящей линии связи (UL-SCH) и канал произвольного доступа (RACH) являются транспортными каналами восходящей линии связи.
Мультиплексирование затем выполняется между логическими каналами и транспортными каналами в нисходящей и восходящей линиях связи соответственно.
Сигнализация управления Уровня 1/Уровня 2 (L1/L2)
Чтобы информировать спланированных пользователей об их состоянии распределения, транспортном формате и другой относящейся к данным информации (например, информации HARQ, командах управления мощностью передачи (TPC)), сигнализация управления L1/L2 передается по нисходящей линии связи вместе с данными. Сигнализация управления L1/L2 мультиплексируется с данными нисходящей линии связи в подкадре при допущении, что распределение для пользователя может меняться от подкадра к подкадру. Нужно отметить, что распределение для пользователя может также выполняться на основе TTI (интервала времени передачи), где длительность TTI может быть кратной числу подкадров. Длительность TTI может быть фиксированной в зоне обслуживания для всех пользователей, может быть различной для различных пользователей или даже может быть динамической для каждого пользователя. Обычно, сигнализация управления L1/2 должна только однажды передаваться на один TTI. Без потери общности последующее допускает, что TTI является эквивалентным одному подкадру.
Сигнализация управления L1/L2 передается на Физическом канале управления нисходящей линии связи (PDCCH). PDCCH несет сообщение в виде Управляющей информации нисходящей линии связи (DCI), которая в большинстве случаев включает в себя назначения ресурсов и другую управляющую информацию для мобильного терминала или группы UE. В общем, несколько PDCCH могут передаваться в одном подкадре.
Нужно отметить, что в LTE 3GPP назначения для передач данных в восходящем направлении, также именуемые планируемыми предоставлениями восходящей линии связи или назначениями ресурсов восходящей линии связи, также передаются на PDCCH.
Обычно, информацию, посылаемую с сигнализацией управления L1/L2, для назначения радиоресурсов восходящей или нисходящей линий связи (конкретно в LTE(-A) Версии 10), можно группировать по следующим группам единиц:
- Идентификационные данные (идентификатор) пользователя, указывающие пользователя, который является распределяемым. Они обычно включаются в контрольную сумму путем маскирования CRC идентификационными данными пользователя;
- Информация распределения ресурсов, указывающая ресурсы (ресурсные блоки, RB), на которых распределяют пользователя. Нужно отметить, что число RB, на которых распределяют пользователя, может быть динамическим;
- Индикатор несущей, который используется, если канал управления, передаваемый на первой несущей, назначает ресурсы, которые касаются второй несущей, то есть, ресурсов на второй несущей или ресурсов, относящихся ко второй несущей;
- Схема модуляции и кодирования, которая определяет применяемые схему модуляции и скорость кодирования;
- Информация HARQ, такая как индикатор новых данных (NDI) и/или версия избыточности (RV), которая является особенно полезной в повторных передачах пакетов данных или их частей;
- Команды управления мощностью для регулировки мощности передачи для назначенной передачи данных или управляющей информации в восходящей линии связи;
- Информация опорного сигнала, такая как примененный циклический сдвиг и/или индекс ортогонального кода покрытия, которые должны использоваться для передачи или приема опорных сигналов, относящихся к назначению;
- Индекс назначения восходящей или нисходящей линий связи, который используется, чтобы идентифицировать порядок назначений, каковое является особенно полезным в системах TDD;
- Информация о скачкообразном изменении частоты, например, применять ли и каким образом применять «перескоки» частоты ресурса для повышения частотного разнесения;
- Запрос CSI, который используется, чтобы инициировать передачу информации о состоянии канала в назначенном ресурсе; и
- Информация мультикластера, которая является флажком, используемым для указания и управления, происходит ли передача в одном кластере (непрерывном множестве RB) или в множественных кластерах (по меньшей мере, двух несмежных множеств непрерывных RB). Многокластерное распределение было введено согласно LTE-(A) 3GPP Версии 10.
Следует отметить, что перечисление выше является неисчерпывающим, и не вся упомянутые единицы информации должны присутствовать в каждой передаче PDCCH в зависимости от формата DCI, который используется.
Управляющая информация нисходящей линии связи имеет место в нескольких форматах, которые отличаются по общему размеру, а также информации, содержащейся в ее полях. Различными форматами DCI, которые в настоящий момент определены для LTE, являются изложенные ниже и описанные подробно в документе TS 36.212 3GPP, разделе 5.3.3.1 "Multiplexing and channel coding", (доступном по адресу http://www.3gpp.org и включенном в документ путем ссылки). Для дополнительной информации относительно форматов DCI и конкретной информации, которая передается в DCI, пожалуйста, обратитесь к техническому стандарту или к документу LTE - The UMTS Long Term Evolution - From Theory to Practice, под ред. Stefanie Sesia, Issam Toufik, Matthew Baker, Главе 9.3 включенной в документ путем ссылки.
Формат 0: Формат 0 DCI используется для передачи предоставлений ресурсов для PUSCH с использованием передач одно-антенного порта в режиме 1 или 2 передачи по восходящей линии связи.
Формат 1: Формат 1 DCI используется для передачи назначений ресурсов для передач PDSCH в одном кодовом слове (режимы 1, 2 и 7 передачи по нисходящей линии связи).
Формат 1A: Формат 1A DCI используется для компактной сигнализации назначений ресурсов для передач PDSCH в одном кодовом слове и для распределения специальной подписи преамбулы мобильному терминалу для произвольного доступа без конкуренции.
Формат 1B: Формат 1B DCI используется для компактной сигнализации назначений ресурсов для передач PDSCH с использованием предварительного кодирования с замкнутым контуром с передачей (матрицы кодирования) ранга-1 (режим 6 передачи по нисходящей линии связи). Передаваемая информация является такой же, как в Формате 1A, но с добавлением индикатора вектора предварительного кодирования, применяемого для передачи PDSCH.
Формат 1C: Формат 1C DCI используется для сверхкомпактной передачи назначений PDSCH. Когда используется формат 1C, передача PDSCH ограничивается использованием квадратурной фазовой модуляции (QPSK). Это используется, например, для сообщений сигнализации поискового вызова и широковещательных сообщений системной информации.
Формат 1D: Формат 1D DCI используется для компактной сигнализации назначений ресурсов для передачи PDSCH с использованием MIMO с многопользовательским режимом. Передаваемая информация является такой же, как в Формате 1B, но вместо одного из битов индикатора вектора предварительного кодирования имеется единственный бит для указания, применяется ли к символам данных смещение мощности. Эта функция требуется, чтобы показать, является или не является мощность передачи совместно используемой двумя UE. Будущие версии LTE могут расширить это до случая совместного использования мощности более большим количеством UE.
Формат 2: Формат 2 DCI используется для передачи назначений ресурсов для PDSCH для режима работы MIMO с обратной связью.
Формат 2A: Формат 2A DCI используется для передачи назначений ресурсов для PDSCH для режима работы MIMO без обратной связи. Передаваемая информация является такой же, как для Формата 2, за исключением того, что если eNodeB имеет два порта передающих антенн, то отсутствует информация предварительного кодирования, и для четырех антенных портов используются два бита для указания ранга передачи.
Формат 2B: Введен в Версии 9 и используется для передачи назначений ресурсов для PDSCH для двухуровневого формирования луча.
Формат 2C: Введен в Версии 10 и используется для передачи назначений ресурсов для PDSCH для однопользовательского или многопользовательского режима работы MIMO с обратной связью с использованием до 8 уровней.
Формат 2D: Веден в Версии 11 и используется для передач до 8 уровней; в основном используется для COMP (Скоординированная многоточечная связь)
Формат 3 и 3A: форматы 3 и 3A DCI используются для передачи команд управления мощностью для PUCCh и PUSCH с 2-битовыми или 1-битовыми регулировками мощности соответственно. Эти форматы DCI содержат отдельные команды управления мощностью для группы UE.
Формат 4: формат 4 DCI используется для планирования PUSCH с использованием передач с пространственным мультиплексированием с обратной связью в режиме 2 передачи по восходящей линии связи.
Следующая таблица дает общее представление некоторых доступных форматов DCI и типового числа битов, предполагая для целей иллюстрации ширину полосы пропускания системы в 50 RB и четыре антенны в eNodeB. Количество битов, указанных в правом столбце, включает биты для CRC для конкретного DCI.
Фиг.5 иллюстрирует структуру обработки для одной DCI, согласно Фиг.5.3.3.13 в TS 36.212 GPP, как изложено ниже:
- Мультиплексирование информационных элементов (относится к мультиплексированию конкретных информационных элементов, составляющих одну единицу DCI),
- Присоединение CRC
- Канальное кодирование
- Согласование скорости
Чтобы UE могло идентифицировать, приняло ли оно передачу PDCCH корректно, обнаружение ошибок обеспечивается посредством 16-битового CRC, присоединяемого к каждому PDCCH (то есть DCI). Кроме того, необходимо, чтобы UE могло идентифицировать, какой экземпляр(ы) PDCCH предназначен для этого. Теоретически это можно осуществить добавлением идентификатора к полезной нагрузке PDCCH; однако, оказывается, что будет более эффективным скремблировать CRC с "идентификационными данными UE", каковое сберегает дополнительные издержки. CRC можно вычислять и скремблировать, как определено подробно 3GPP в документе TS 36.212, разделе 5.3.3.2 "CRC attachment", включенном тем самым путем ссылки. Раздел описывает, каким образом обнаружение ошибок обеспечивается на передачах DCI посредством контроля циклическим избыточным кодом (CRC). Краткое описание дается ниже.
Вся полезная нагрузка используется для вычисления битов четности CRC. Биты четности вычисляют и присоединяют. В случае, где выбор передающей антенны UE не задан в конфигурации или неприменим, после присоединения биты четности CRC скремблируют с соответствующим временным идентификатором соты (ячейки) в радиосети (RNTI).
Скремблирование может дополнительно зависеть от выбора передающей антенны UE, как очевидно из 36.212. В случае, где выбор передающей антенны UE задан в конфигурации и применим, после присоединения биты четности CRC скремблируют с маской выбора антенны и соответствующим RNTI. Поскольку в обоих случаях RNTI включается в операцию скремблирования, для простоты и без потери общности последующее описание вариантов осуществления просто относится к CRC, являющемуся скремблируемым (и дескремблируемым, если применимо) с RNTI, который поэтому следует понимать безотносительным, например, последующего элемента в процессе скремблирования, такого как маска выбора антенны.
Соответственно, UE дескремблирует CRC путем применения "идентификационных данных UE" и, если ошибка CRC не обнаружена, UE определяет, что PDCCH несет его управляющую информацию, предназначенную для него. Терминология "маскирование" и "демаскирование" также используется для вышеописанного процесса скремблирования CRC с идентификационными данными.
"Идентификационные данные UE", упомянутые выше, с которыми может быть скремблирован CRC для DCI, также могут быть SI-RNTI (Временным идентификатором в радиосети для системной информации), который не является "идентификационными данными UE", как таковыми, а предпочтительнее идентификатором, связанным с типом информации, которая указывается и передается, в этом случае - системной информации. SI-RNTI обычно задается в техническом описании и таким образом является известным априорно всем UE.
Имеются различные типы RNTI, которые используются для различных назначений. Следующие таблицы, которые взяты из Главы 7.1 документа 36.321 3GPP, должны давать общее представление о различных 16-битовых RNTI и их применениях.
, 
полупостоянного планирования, временный , 
и 
(см. примечание)
, полупостоянного планирования, временный , и 
Физический канал управления нисходящей линии связи (PDCCH) и Физический совместно-используемый канал нисходящей линии связи (PDSCH)
Физический канал управления нисходящей линии связи (PDCCH) несет, например, планируемые предоставления на распределение ресурсов для передачи данных в нисходящей или восходящей линии связи.
Каждый PDCCH передается с использованием одного или нескольких так называемых Элементов канала управления (CCE). Каждый CCE соответствует набору Ресурсных элементов (RE). В LTE 3GPP, в настоящее время один CCE состоит из 9 Групп ресурсных элементов (REG, где одна REG состоит из четырех последовательных RE (последовательных в частотной области), кроме потенциальных RE для опорных сигналов. Ресурсные элементы, занятые опорными символами, не включаются в единицы REG, что означает, что общее количество REG в данном символе OFDM зависит от того, присутствуют ли опорные сигналы.
PDCCH для единиц пользовательского оборудования передается на первых 
OFDM символах (обычно либо 1, 2, либо 3 символах OFDM, как указано посредством PCFICH (физический канал управления индикатора формата), в исключительных случаях либо 2, 3, либо 4 символах OFDM, как указывается посредством PCFICH) в подкадре, распространяющегося по всей ширине полосы пропускания системы; полоса пропускания системы обычно является эквивалентной диапазону ячейки или компонентной несущей. Диапазон, занятый первыми 
OFDM символами во временной области и 
поднесущими в частотной области, также именуется диапазоном PDCCH или диапазоном канала управления. Оставшиеся 
символов OFDM во временной области на 
поднесущих в частотной области именуются диапазоном PDSCH или диапазоном совместно-используемого канала (см. ниже).
Для предоставления нисходящей линии связи на физическом совместно-используемом канале нисходящей линии связи (PDSCH) PDCCH назначает ресурс PDSCH для данных (пользователя) внутри того же подкадра. Область канала управления PDCCH в подкадре состоит из набора CCE, где общее количество CCE в управляющей области подкадра распределяются по всему временному и частотному ресурсу управления. Множественные CCE можно объединять, чтобы эффективно снижать скорость кодирования канала управления. Единицы CCE объединяют предварительно определенным образом с использованием древовидной структуры, чтобы добиться другой скорости кодирования.
В LTE 3GPP PDCCH может агрегировать 1, 2, 4 или 8 CCE. Количество CCE, доступных для назначения канала управления, является функцией нескольких факторов, включая полосу частот несущей, количество передающих антенн, количество символов OFDM, используемых для управления, и размер CCE, и т.д. Множественные PDCCH могут передаваться в подкадре.
На уровне транспортного канала информация, передаваемая через PDCCH, также именуется сигнализацией управления L1/L2. Сигнализация управления L1/L2 передается в нисходящей линии связи для каждой единицы пользовательского оборудования (UE). Сигнализация управления обычно мультиплексируется с (пользовательскими) данными нисходящей линии связи в подкадре (при условии, что распределение для пользователя может меняться от подкадра к подкадру).
Дуплексная связь с временным разделением - TDD
LTE может работать в режимах Дуплексной связи с частотным разделением (FDD) и Дуплексной связи с временным разделением (TDD) в согласованной инфраструктуре, спроектированной также для поддержки развития TD-SCDMA (множественного доступа с синхронным временным и частотным разделением). TDD разносит передачи восходящей и нисходящей линий связи во временной области, тогда как частота может оставаться той же.
Термин "дуплекс" относится к двунаправленной связи между двумя устройствами, отличной от однонаправленной связи. В двунаправленном случае передачи по каналу связи в каждом направлении могут иметь место одновременно ("полнодуплексная связь") или во взаимно исключающие периоды времени ("полудуплексная связь").
Для TDD в радиоспектре с непарными частотами базовая структура из RB и RE изображена на Фиг.4, но только подмножество подкадров радиокадра являются доступными для передач по нисходящей линии связи; оставшиеся подкадры используются для передач по восходящей линии связи, или для специальных подкадров, которые содержат защитный интервал, чтобы позволять переключение между передачей по нисходящей и восходящей линиям связи. Защитный интервал позволяет усовершенствовать временную диаграмму передачи по восходящей линии связи. Эта структура TDD является известной как "Тип 2 структуры кадра" в LTE 3GPP Версии 8 и более поздней, для которой дано определение семи различных конфигураций, допускающих множество соотношений «нисходящая линия связи/восходящая линия связи» и переключения периодичностей. Фиг.6 иллюстрирует Таблицу с 7 различными, проиндексированными от 0 до 6, конфигурациями восходящая линия связи/нисходящая линия связи для TDD. Как может быть видно из нее, семь доступных конфигураций «нисходящая линия связи/восходящая линия связи» для TDD могут обеспечивать между 40% и 90% подкадров нисходящей линии связи (если считать специальный подкадр подкадром нисходящей линии связи, поскольку часть такого подкадра является доступной для передачи по нисходящей линии связи).
Фиг.7 показывает тип 2 структуры кадра, конкретно для периодичности точки переключения в 5 мс, то есть, конфигураций 0, 1, 2 и 6 для TDD.
Фиг.7 иллюстрирует радиокадр, имеющий длительность 10 мс и соответствующий двум полукадрам по 5 мс каждый. Радиокадр состоит из 10 подкадров в 1 мс, где каждому из подкадров назначен тип «Восходящая линия связи», «Нисходящая линия связи» или «Специальный», как определено таблицей по Фиг.6, где "D" означает «Нисходящая линия связи», "U" означает «Восходящая линия связи», и "S" означает «Специальный».
Как можно оценить из Фиг.6, подкадр #1 всегда является подкадром Специальный, и подкадр #6 является подкадром Специальный для конфигураций 0, 1, 2 и 6 в TDD; для конфигураций 3, 4 и 5 в TDD, подкадр #6 предназначен для Нисходящей линии связи. Специальные подкадры включают в себя три поля: DwPTS (Временной интервал для пилот-сигнала нисходящей линии связи), GP (Защитный интервал) и UpPTS (Временной интервал для пилот-сигнала восходящей линии связи). Следующая Таблица показывает информацию о специальном подкадре и в конкретных перечнях - длительности DwPTS (Downlink Pilot Time Slot), GP (Guard Period) и UpPTS (Uplink Pilot Time Slot) в виде времени, кратного времени выборки Ts = (1/30720) мс, как задано для LTE 3GPP Версии 11.
Конфигурация TDD, примененная в системе, оказывает влияние на многие операции, выполняемые на мобильной станции и базовой станции, такие как измерения для управления радиоресурсами (RRM), измерения для информации о состоянии канала (CSI), оценки канала, временные диаграммы детектирования PDCCH и HARQ.
В частности UE считывает системную информацию, чтобы узнать конфигурацию TDD в своей текущей соте, то есть, мониторинг какого подкадра осуществлять для измерения, для замера и отчета о CSI, для фильтрации временной области для получения оценки канала, для детектирования PDCCH или для обратной связи по подтверждению/неподтверждению приема (ACK/NACK) в UL/DL.
Недостаток существующей схемы полустатического конфигурирования UL/DL в TDD
В настоящий момент TDD LTE позволяет асимметричные распределения UL-DL путем обеспечения семи различных полустатически конфигурируемых конфигураций восходящая линия связи/нисходящая линия связи. Существующий механизм для приспосабливания распределения UL-DL основывается на процедуре сбора системной информации или процедуре изменения системной информации, где конфигурация UL-DL в TDD указывается блоком системной информации (SIB), конкретно параметром конфигурации TDD-config в SIB1, (относительно подробностей широковещательной передачи системной информации, см. документ 3GPP TS 25.331, "Radio Resource Control(RRC)", версия 6.7.0, раздел 8.1.1, включенный в документ путем ссылки; доступный по адресу http://www.3gpp.org).
С помощью процедуры изменения системной информации в Версии 8 поддерживаемая временная шкала для реконфигурирования UL/DL TDD составляет каждые 640 мс или более. При повторном использовании ETWS (Система предупреждения о приближении землетрясений и цунами, Earthquake and Tsunami Warning System), поддерживаемая временная шкала для реконфигурирования UL-DL TDD составляет каждые 320 мс или более в зависимости от сконфигурированного «по умолчанию» цикла поискового вызова.
Полустатическое распределение конфигурации UL/DL TDD может или не может соответствовать мгновенной ситуации трафика. Однако будет полезным приспосабливать конфигурацию UL/DL TDD к текущим потребностям трафика; например, чтобы динамически создавать больше «пустых» подкадров восходящей линии связи для ослабления помех по отношению к передаче, например, в восходящей или нисходящей линии связи соседней соты. Соответственно, ожидается, что Версия 12 одобрит более динамическое изменение конфигурации UL/DL TDD.
Консорциум 3GPP объявил задачу исследования в документе TR 36.828 v1 1.0.0, чтобы исследовать временные шкалы для различных типов изменений конфигурации UL/DL TDD и их преимущества и недостатки. В общем, заключение задачи исследования показало, что более быстрые временные шкалы реконфигурирования UL/DL TDD предоставляет больше преимуществ, чем более медленные временные шкалы реконфигурирования UL/DL TDD. Кроме того, объем требуемых изменений в описании варьируется в зависимости от поддерживаемых временных шкал реконфигурирования.
Задача исследования однако также идентифицировала проблемы относительно действующих UE (экземпляры UE, совместимые только со стандартами, более ранними, чем Версия 12, которые не реализуют механизм динамического реконфигурирования TDD), возникающие из-за различных конфигураций TDD для различных UE. В частности считается, что если базовая станция желает динамически реконфигурировать конфигурацию TDD для единиц UE в соте, динамическое реконфигурирование TDD может правильно обрабатываться только новыми UE; в случае, если используется не существующий способ указания конфигурации TDD на основе SIB, а способ более динамического указания, действующие UE не будут применять реконфигурирование TDD. Следовательно, действующие UE все еще будут полагать присутствие опорных сигналов, например, CRS (Общий опорный символ) в подкадрах нисходящей линии связи в радиокадре согласно конфигурации TDD по умолчанию (то есть, указанной посредством SIB). В случае, если динамическая конфигурация TDD имеет подкадр восходящей линии связи вместо подкадра нисходящей линии связи, действующее UE таким образом будет ошибочно полагать, что CRS должен присутствовать, каковое может привести к некорректным измерениям и оценкам канала.
Задача исследования также рассмотрела сигнализацию RRC, MAC и PHY в качестве способов более динамического указания. Реконфигурирование UL/DL TDD путем сигнализации RRC имеет порядок 200 мс и требует сообщения реконфигурирования на одного соединенного по RRC пользователя, если только не указан способ вещательной или многоадресной передачи. Реконфигурирование UL/DL TDD посредством сигнализации Управляющего элемента (CE) под-уровня MAC в заголовке MAC имеет порядок нескольких десятков мс. Используя построение Физического уровня, такое как обеспеченное сигнализацией управления L1/L2 в DCI, можно добиться временной шкалы адаптации UL/DL TDD порядка в 10 мс.
Ввиду результатов вышеуказанной задачи исследования реконфигурирование UL/DL TDD следует выполнять насколько возможно быстро, таким образом, позволяя гибкую адаптацию конфигурации UL/DL TDD к ситуациям трафика.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Один объект изобретения состоит в обеспечении улучшенного указания конфигурации Дуплексной связи с временным разделением, который решает проблемы предшествующего уровня техники, как обсуждено выше. Динамическая адаптация конфигурации TDD одного или нескольких радиокадров будет предпочтительно возможной.
Задача решается согласно объекту по независимым пунктам формулы изобретения. Полезные варианты осуществления являются объектами зависимых пунктов формулы изобретения.
Согласно различным вариантам осуществления изобретения, конфигурация дуплексной связи с временным разделением (TDD), которая будет использоваться для передачи между мобильной станцией и базовой станцией, кодируется базовой станцией в передачу DCI на мобильную станцию. В этом контексте термин «передача DCI» нужно понимать как целостную передачу, которая в данном случае означает DCI и соответствующий код с поддержкой обнаружения ошибок (такой как CRC). Изобретение обеспечивает различные варианты осуществления того, как этого можно добиться.
Согласно первому аспекту изобретения, конфигурация TDD кодируется в код обнаружения ошибок, вычисляемый для DCI; более конкретно, специфическая конфигурация TDD неявно кодируется в код с обнаружением ошибок. Для каждой из назначаемых конфигураций TDD задается другое значение идентификатора, и мобильным станциям, и базовым станциям известны предварительно определенные значения идентификаторов и взаимосвязи с возможными конфигурациями TDD. Более конкретно, в системах связи LTE идентификатор может быть временным идентификатором в радиосети, имеющим длину 16 битов, который затем скремблируют с 16-битовым кодом с обнаружением ошибок (CRC).
Соответственно, когда базовая станция желает динамически изменить конфигурацию TDD по умолчанию на другую целевую конфигурацию TDD для конкретной соты, она будет формировать DCI, вычислять соответствующий код обнаружения ошибок для DCI и затем скремблировать вычисленный CRC с тем идентификатором, который связан с целевой конфигурацией TDD, которую мобильная станция(и) в этой соте должна использовать для следующего радиокадра(ов).
DCI как таковая (то есть, не CRC) может быть либо в формате DCI, уже определенном в стандартах LTE, либо эквивалентно имеющей такой же размер, как уже определенный формат DCI, например, Формат 1C, или может быть соответствующей "новому" формату DCI, который служит цели использоваться вместе с динамическим реконфигурированием TDD.
В случае, если используется DCI, уже определенная в LTE, (такая как формата 1C), тогда базовая станция может установить один или несколько параметров в DCI (в случае Формата 1C, назначение ресурсного блока, например) в недействительное значение, так что мобильная станция, обрабатывающая DCI и недействительный параметр, может легко определить, что принятая DCI не является DCI "традиционного" Формата 1C, назначающего ресурсы нисходящей линии связи, а предпочтительнее используется, чтобы передавать конфигурацию TDD для динамического реконфигурирования TDD.
Первый аспект может быть дополнительно улучшен в том, что вышеуказанный недействительный параметр заданного Формата DCI (например, Формата 1C DCI) может использоваться для кодирования дополнительного параметра, как будет пояснено. Допускается, что недействительный параметр может принимать не только одно недействительное значение, а различные недействительные значения. В упомянутом случае недействительный параметр может использоваться для кодирования указателя, что DCI (с упомянутым недействительным параметром) несет динамическое реконфигурирование TDD, а также для кодирования дополнительного параметра (значения). Конкретно, факт, что параметр установлен в какое-либо недействительное значение или группу таковых, позволяет мобильной станции определять, что DCI будет DCI, переносящей указатель конфигурации TDD, а не традиционной DCI. Затем, каждое (или группу) недействительных значений упомянутого параметра затем можно связывать с отличающимся значением другого конкретного параметра. Например, фактически доступные недействительные значения можно связать с другими конфигурациями TDD, так что недействительный параметр, и конкретно одно из значений недействительного параметра, также указывает индекс требуемой конфигурации TDD для динамического реконфигурирования UL/DL TDD.
Кроме того, Формат DCI, уже определенный в 3GPP, может повторно использоваться, а именно, полагая битовый размер таким же, как у уже определенной DCI, но задавая другое содержимое (информационные элементы) в рамках DCI для конкретных ситуаций. Например, Формат 1C DCI в документе TS 36.212 стандарта 3GGP может быть расширен, так что для одного набора случаев Формат 1C DCI используется как уже задано 3GPP (для назначений PDSCH), но для оставшихся (других) случаев Формат 1C DCI не является таким, как подразумевает 3GPP на настоящее время (как определено на момент подачи заявки, соответственно), а предназначен для динамического реконфигурирования TDD согласно изобретению.
В качестве третьей альтернативы, может задаваться новый Формат DCI, возможно другой длины по сравнению с существующими форматами DCI; длина зависит от дополнительного содержимого (параметров), которое подлежит включению в упомянутый новый формат DCI. Как будет пояснено с дополнительными подробностями ниже, в любом случае ("заданной", "заданной-расширенной" и "новой" DCI), DCI может включать в себя, по меньшей мере, один добавочный параметр, который может использоваться преимущественно вместе с динамическим реконфигурированием TDD.
В соответствии с вышеуказанным, мобильная станция, принимающая DCI и соответствующий код обнаружения ошибок, сделает попытку дескремблирования и выполнения проверки на наличие ошибок применительно к коду обнаружения ошибок, используя различные идентификаторы, предварительно определенные для различных конфигураций TDD. Когда мобильная станция успешно выполняет проверку на наличие ошибок с одним из различных идентификаторов-кандидатов, мобильная станция затем определит специфическую конфигурацию TDD, связанную с тем идентификатором, для которого проверка на наличие ошибок была успешной. Мобильной станции затем известна конфигурация TDD, которая должна применяться для следующего радиокадра(ов) в ее соте.
Кроме того, мобильная станция может определять вышеуказанный дополнительный параметр(ы), чтобы извлекать дополнительные преимущества; подробности представлены в разделе подробного описания.
Согласно второму аспекту изобретения, вместо неявного кодирования конфигурации TDD в код обнаружения ошибок, как в первом аспекте, конфигурация TDD непосредственно кодируется в виде параметра в DCI. Соответственно, DCI, сформированная базовой станцией, содержит поле (предпочтительно длиной до 3 битов), указывающее конфигурацию TDD, которая должна применяться вместо конфигурации TDD по умолчанию. Второй аспект изобретения дополнительно описывает, что код обнаружения ошибок, вычисляемый для DCI и передаваемый вместе с DCI от базовой станции на мобильную станцию, скремблируется с идентификатором соты, каковое позволяет мобильной станции идентифицировать целевую соту, к которой должна применяться конфигурация TDD.
Мобильная станция, при приеме DCI и скремблированного кода обнаружения ошибок от базовой станции, сначала выполняет проверку на наличие ошибок на коде с обнаружением ошибок и DCI, каковое включает в себя этап дескремблирования кода обнаружения ошибок. Мобильная станция выполняет проверку ошибок до тех пор, пока не определит идентификатор соты, фактически использованный для процесса скремблирования кода обнаружения ошибок в базовой станции.
Из определенного идентификатора соты мобильная станция во-первых узнает, что DCI является DCI, предназначенной для транспортировки конфигурации TDD (а не какого-либо другого вида DCI); во-вторых, мобильная станция узнает, для какой целевой соты (идентифицированной идентификатором соты) конфигурацию TDD (включенную в DCI) фактически предполагается применять. Из полезной нагрузки DCI мобильная станция узнает конфигурацию TDD.
Естественно, мобильная станция применяет определенную конфигурацию TDD только в случае, если она принадлежит определенной целевой соте, идентифицированной идентификатором соты, использованным для скремблирования кода обнаружения ошибок для DCI.
Второй аспект может использоваться преимущественно для сценария, в котором имеется одна макро-сота и различные малые соты; например, макро-сотой оперируют с дуплексной связью с частотным разделением, и малыми сотами оперируют с дуплексной связью с временным разделением. Мобильная станция находится в макро-соте так же как и малая сота. Полагают, что DCI (и код с коррекцией ошибок) передается от базовой станции макро-соты, но с целью динамического изменения конфигурации TDD одной (или большего числа) малых сот.
С этой целью идентификатор соты, использованный для скремблирования кода обнаружения ошибок DCI, может идентифицировать только одну из сот, для которой должна применяться новая конфигурация TDD. Альтернативно, различные малые соты можно сгруппировывать вместе и связывать с единым идентификатором соты (группы), так что по приему DCI и кода обнаружения ошибок, скремблированного с упомянутым единым идентификатором соты (группы), мобильные станции могут определить, для каких сот(ы) новая конфигурация TDD должна применяться и для каких не должна.
Хотя как пояснено выше, использование такого идентификатора соты для скремблирования кода обнаружения ошибок уже позволяет мобильной станции идентифицировать DCI, которая будет нести конфигурацию TDD, DCI может дополнительно содержать недействительный параметр, чтобы снижать риск ложного аварийного сигнала. Конкретно, когда базовая станция формирует DCI для динамического изменения конфигурации TDD одной (или более) соты, включается параметр конфигурации TDD, а также параметр DCI устанавливается в недействительное значение. Какие конкретные параметры должны быть установлены в недействительное значение, является менее важным, если только мобильная станция может идентифицировать упомянутый параметр, являющийся недействительным, и тем самым образом вывести из этого, что DCI является не "традиционной" DCI, а некоторой, переносящей конфигурацию TDD. Соответственно, мобильная станция может заключить из и идентификатора соты, использованного в связи с кодом с обнаружением ошибок, а также из недействительного параметра DCI, что DCI должна содержать дополнительно указание относительно новой конфигурации TDD, которая должна применяться.
Одним примером недействительного параметра является параметр назначения ресурсного блока в Формате 1C DCI, как определено 3GPP. Параметр назначения ресурсного блока установлен в недействительное значение, например, все "1".
Как уже пояснено в связи с первым аспектом изобретения, вышеуказанный недействительный параметр может также использоваться для кодирования дополнительной информации; например, дополнительного значения параметра. Если множество недействительных значений являются доступными для недействительного параметра, то все недействительные значения связываются с информацией, что DCI, переносящая упомянутый недействительный параметр, является DCI, переносящей одну из множества конфигураций TDD. С другой стороны, каждое (или группа) недействительных значений связано с отличающимся значением еще одного параметра. Таким образом, дополнительная информация может транспортироваться на мобильную станцию без использования дополнительных битов. Например, фактическая конфигурация TDD может быть закодирована в недействительный параметр; по меньшей мере, семь различных значений недействительного параметра должны быть доступными, чтобы различать семь конфигураций TDD. Затем, на основе конкретного значения недействительного параметра, использованного в DCI, мобильная станция может определить конкретную конфигурацию TDD.
Вместо принятия известного Формата DCI (такого как Формат 1C DCI, определенный 3GPP), также является возможным задать определение нового Формата DCI исключительно с целью транспортировки указания динамического реконфигурирования TDD, и возможно дополнительных добавочных параметров, как будет обсуждено далее более подробно.
Согласно третьему аспекту изобретения, конфигурация TDD кодируется напрямую в DCI, подобно второму аспекту изобретения. DCI дополнительно содержит недействительный параметр, который позволяет мобильной станции обнаруживать, что принятая DCI несет указатель конфигурации TDD. Соответственно, в случае, если мобильная станция определяет, что DCI содержит упомянутый конкретный недействительный параметр, она переходит к определению конкретной конфигурации TDD, содержащейся в DCI.
Относительно третьего аспекта изобретения считается, что может использоваться любой из различных известных Форматов DCI, определенных 3GPP, например, Формат 1C DCI, уже обсужденный для первого и второго аспектов изобретения. Однако вместо этого могут использоваться другие форматы.
Формат 1C DCI, как определено 3GPP, традиционно включает в себя параметр назначения ресурсного блока (RBA) для назначения PDSCH. В целях третьего аспекта, упомянутый параметр RBA может быть установлен в недействительное значение.
Как и в случае предшествующих аспектов, дополнительная информация может быть закодирована в упомянутый недействительный параметр, если существует ряд недействительных значений для недействительного параметра. Тогда как любое из недействительных значений указывает, что DCI (переносящая упомянутый недействительный параметр) используется для цели транспортировки конфигурации TDD, каждое (или группа) недействительных значений связано с дополнительной информацией. Например, фактическая конфигурация TDD может быть закодирована в недействительный параметр; по меньшей мере, семь различных значений недействительного параметра должны быть доступными, чтобы различать семь конфигураций TDD. Затем, на основе конкретного значения недействительного параметра, использованного в DCI, мобильная станция может определить конкретную конфигурацию TDD.
Дополнительное улучшение третьего аспекта допускает, что код обнаружения ошибок для DCI скремблируют с так называемым идентификатором системной информации (SI-RNTI в 3GPP). SI-RNTI обычно используется в системах 3GPP для транспортировки системной информации, и различные окна SI задаются так, что мобильная станция может определить, какое сообщение системной информации в каком окне SI можно указывать (сравните 3GPP TS 36.331, разделы 5.2.1.2 и 5.2.3). Согласно 3GPP, только одно сообщение SI может передаваться на одно окно SI, но многократно в этом окне SI (в случае необходимости). Поскольку различные сообщения SI могут быть сконфигурированы с различными периодичностями, является возможным, что некоторые окна SI не используются для какого-либо сообщения SI; другими словами, мобильная станция осведомлена, что в таких неиспользуемых окнах SI какая-либо передача сообщения SI не будет выполняться базовой станцией. Это знание мобильной станции используется в ее интересах либо путем передачи DCI, транспортирующей конфигурацию TDD в таком неиспользуемом окне SI, хотя CRC для DCI скремблирован с SI-RNTI. Прием в рамках неиспользуемого окна SI позволяет мобильной станции, в комбинации с недействительным параметром, с более высокой достоверностью определять, что DCI транспортирует конфигурацию TDD.
В виде модификации задается окно приема TDD-DCI, которое должно пониматься как ограничивающее, где мобильная станция ожидает сообщение TDD-DCI для точно конкретных подкадров и/или радиокадров. Другими словами, предпочтительно периодический характер подкадров и/или радиокадров определен в виде окна приема TDD-DCI, где сообщение конфигурации TDD может передаваться базовой станцией, и/или лишь требует подлежать приему и детектированию мобильной станцией.
Первый вариант осуществления настоящего изобретения обеспечивает способ для указания одной из множества конфигураций дуплексной связи с временным разделением, TDD, для мобильной станции в системе связи. Конфигурация TDD задает подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или большем количестве радиокадров. Мобильная станция принимает от базовой станции управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок управляющей информации нисходящей линии связи, причем код обнаружения ошибок скремблирован базовой станцией с идентификатором, связанным с конфигурацией TDD. Затем, мобильная станция определяет идентификатор, использованный для скремблирования кода обнаружения ошибок управляющей информации нисходящей линии связи. Мобильная станция определяет конфигурацию TDD из идентификатора, использованного для скремблирования кода обнаружения ошибок управляющей информации нисходящей линии связи.
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться, в дополнение или альтернативно к вышеуказанному, каждая конфигурация TDD связана с отличающимся значением идентификатора, и конкретная конфигурация TDD кодируется в код обнаружения ошибок путем скремблирования кода с обнаружением ошибок со связанным идентификатором. В одном варианте идентификатор является временным идентификатором в радиосети длиной в 16 битов.
Согласно полезной модификации первого варианта осуществления изобретения, каковая может использоваться в дополнение или альтернативно к вышеуказанному, взаимосвязь между множеством конфигураций TDD и идентификаторами является предварительно определенной в базовой станции, и мобильную станцию информируют о предварительно определенной связи сообщением конфигурации.
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, система связи является системой связи LTE, и управляющая информация нисходящей линии связи является управляющей информацией нисходящей линии связи в формате 1C. Для этого конкретного случая в дополнительном варианте управляющая информация нисходящей линии связи дополнительно содержит недействительный параметр, указывающий, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD. Недействительный параметр может быть параметром назначения ресурсного блока, имеющим длину 3-9 битов и недействительное значение, такое как все биты параметра назначения ресурсного блока, равные "1".
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, управляющая информация нисходящей линии связи содержит недействительный параметр с одним из множества недействительных значений. Все из множества недействительных значений указывают, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD. С другой стороны, каждое или группа недействительных значений недействительного параметра указывают, по меньшей мере, одно из следующего:
целевую соту, для которой конфигурация TDD должна применяться,
инструкцию HARQ, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи, для соты, к которой конфигурация TDD должна применяться,
параметр времени действия для указанной конфигурации TDD, такой что мобильная станция определяет величину времени, в течение которого указанная конфигурация TDD должна применяться, из параметра времени действия, предпочтительно при этом параметр времени действия указывает индекс, связанный с предварительно определенной величиной времени,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, управляющая информация нисходящей линии связи содержит, по меньшей мере, одно из следующего:
идентификатор целевой соты, идентифицирующий целевую соту, для которой конфигурация TDD должна применяться, предпочтительно при этом идентификатор целевой соты имеет длину 1-5 битов,
инструкцию HARQ, включающую в себя инструкцию, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться, предпочтительно при этом инструкция HARQ имеет длину 1 бит,
параметр времени действия для указанной конфигурации TDD такой, что мобильная станция определяет величину времени, в течение которого указанная конфигурация TDD должна применяться, из параметра времени действия, предпочтительно при этом параметр времени действия имеет длину 1-2 бита и указывает индекс, связанный с предварительно определенной величиной времени,
поле заполнения с битовым значением таким, что мобильная станция определяет, является ли битовое значение поля заполнения тождественным предварительно определенному битовому значению, предпочтительно при этом дополнительное поле имеет длину 1-32 бита,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, мобильная станция конфигурируется с конфигурацией TDD по умолчанию. Мобильная станция применяет определенную конфигурацию TDD для радиокадров n+m и применяет конфигурацию TDD по умолчанию для радиокадров n+m+1. m>=1, и n связано с радиокадром, в котором управляющая информация нисходящей линии связи и код обнаружения ошибок принимаются мобильной станцией.
Первый вариант осуществления настоящего изобретения обеспечивает мобильную станцию для обработки одной из множества конфигураций дуплексной связи с временным разделением, TDD, в системе связи. Конфигурация TDD задает подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или большем количестве радиокадров. Приемная секция мобильной станции принимает от базовой станции управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок для управляющей информации нисходящей линии связи. Код обнаружения ошибок скремблирован базовой станцией с идентификатором, связанным с конфигурацией TDD. Процессор мобильной станции определяет идентификатор, использованный для скремблирования кода обнаружения ошибок управляющей информации нисходящей линии связи. Процессор мобильной станции дополнительно определяет конфигурацию TDD из идентификатора, использованного для скремблирования кода обнаружения ошибок управляющей информации нисходящей линии связи.
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, приемник принимает от базовой станции информацию о взаимосвязи между множеством конфигураций TDD и идентификаторами.
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, система связи является системой связи LTE, и управляющая информация нисходящей линии связи является управляющей информацией нисходящей линии связи в формате 1C. В этом случае, процессор может определить, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD, из управляющей информации нисходящей линии связи, содержащей недействительный параметр. В одном варианте недействительный параметр является параметром назначения ресурсного блока, имеющим длину 3-9 битов и недействительное значение, такое как все биты параметра назначения ресурсного блока, равные "1".
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, управляющая информация нисходящей линии связи содержит недействительный параметр с одним из множества недействительных значений. Процессор мобильной станции определяет, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD, на основании любого из недействительных значений. Кроме того, процессор определяет, на основе конкретного недействительного значения недействительного параметра в управляющей информации нисходящей линии связи, по меньшей мере, одно из следующего:
целевую соту, для которой конфигурация TDD должна применяться;
инструкцию HARQ, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться,
параметр времени действия, указывающий величину времени, в течение которого указанная конфигурация TDD должна применяться, предпочтительно при этом параметр времени действия указывает индекс, связанный с предварительно определенной величиной времени,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, процессор мобильной станции определяет из управляющей информации нисходящей линии связи, по меньшей мере, одно из следующего:
идентификатор целевой соты, идентифицирующий целевую соту, для которой конфигурация TDD должна применяться, предпочтительно при этом идентификатор целевой соты имеет длину 1-5 битов,
инструкцию HARQ, включающую в себя инструкцию, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться, предпочтительно при этом инструкция HARQ имеет длину 1 бит,
параметр времени действия для указанной конфигурации TDD, из которого процессор приспособлен определять величину времени, в течение которого указанная конфигурация TDD должна применяться, предпочтительно при этом параметр времени действия имеет длину 1-2 бита и указывает индекс, связанный с предварительно определенной величиной времени,
битовое значение поля заполнения, такое что мобильная станция определяет, является ли битовое значение поля заполнения тождественным предварительно определенному битовому значению, предпочтительно при этом дополнительное поле имеет длину 1-32 бита,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации первого варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, мобильная станция конфигурируется с конфигурацией TDD по умолчанию. Процессор применяет определенную конфигурацию TDD для радиокадров n+m, и применяет конфигурацию TDD по умолчанию для радиокадров n+m+1, где m>=1, и n связано с радиокадром, в котором управляющая информация нисходящей линии связи и код обнаружения ошибок принимаются мобильной станцией.
Первый вариант осуществления настоящего изобретения обеспечивает базовую станцию для указания одной из множества конфигураций дуплексной связи с временным разделением, TDD, для мобильной станции в системе связи. Конфигурация TDD задает подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или большем количестве радиокадров. Процессор базовой станции принимает решение о конфигурации TDD и формирует управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок для управляющей информации нисходящей линии связи. Процессор дополнительно скремблирует сформированный код обнаружения ошибок с идентификатором, связанным с определенной конфигурацией TDD. Передатчик передает на мобильную станцию сформированную управляющую информацию нисходящей линии связи и скремблированный код обнаружения ошибок.
Второй вариант осуществления настоящего изобретения обеспечивает способ для указания одной из множества конфигураций дуплексной связи с временным разделением, TDD, для мобильной станции, по меньшей мере, для одной целевой соты в системе связи. Конфигурация TDD задает подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или большем количестве радиокадров. Мобильная станция принимает от базовой станции первой соты управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок для управляющей информации нисходящей линии связи. Код обнаружения ошибок управляющей информации нисходящей линии связи скремблирован базовой станцией с идентификатором целевой соты, связанным, по меньшей мере, с одной целевой сотой, к которой должна применяться конфигурация TDD. Мобильная станция определяет идентификатор, использованный для скремблирования кода обнаружения ошибок управляющей информации нисходящей линии связи. Мобильная станция также определяет конфигурацию TDD из управляющей информации нисходящей линии связи в случае, если определенный идентификатор является идентификатором целевой соты, и определяет, по меньшей мере, одну целевую соту, к которой должна применяться определенная конфигурация TDD, из идентификатора целевой соты, использованного для скремблирования кода обнаружения ошибок управляющей информации нисходящей линии связи.
Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, первой сотой оперируют в режиме дуплексной связи с частотным разделением, и, по меньшей мере, одной целевой сотой оперируют в режиме с TDD. Управляющая информация нисходящей линии связи и код обнаружения ошибок передаются базовой станцией от первой соты.
Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, идентификатор целевой соты либо идентифицирует одиночную целевую соту, либо группу целевых сот из всех сот. Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, система связи является системой связи LTE, и управляющая информация нисходящей линии связи является управляющей информацией нисходящей линии связи в формате 1C. В конкретном варианте управляющая информация нисходящей линии связи дополнительно содержит недействительный параметр, указывающий, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD. Недействительный параметр может быть параметром назначения ресурсного блока, имеющим длину 3-9 битов и недействительное значение, такое как все биты параметра назначения ресурсного блока, равные "1".
Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, управляющая информация нисходящей линии связи содержит недействительный параметр с одним из множества недействительных значений. Все из множества недействительных значений указывают, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD. С другой стороны, каждое или группа недействительных значений недействительного параметра указывает, по меньшей мере, одно из следующего:
конфигурацию TDD,
инструкцию HARQ, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться,
параметр времени действия для указанной конфигурации TDD, такой что мобильная станция определяет величину времени, в течение которого указанная конфигурация TDD должна применяться, из параметра времени действия, предпочтительно при этом параметр времени действия указывает индекс, связанный с предварительно определенной величиной времени,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, при этом управляющая информация нисходящей линии связи содержит, по меньшей мере, одно из следующего:
поле конфигурации TDD, указывающее конфигурацию TDD, предпочтительно при этом поле конфигурации TDD имеет длину 3 бита,
инструкцию HARQ, включающую в себя инструкцию, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться, предпочтительно при этом инструкция HARQ имеет длину 1 бит,
параметр времени действия для указанной конфигурации TDD, такой что мобильная станция определяет величину времени, в течение которого указанная конфигурация TDD должна применяться, из параметра времени действия, предпочтительно при этом параметр времени действия имеет длину 1-2 бита и указывает индекс, связанный с предварительно определенной величиной времени,
поле заполнения с битовым значением таким, что мобильная станция определяет, является ли битовое значение поля заполнения тождественным предварительно определенному битовому значению, предпочтительно при этом дополнительное поле имеет длину 1-32 бита,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, мобильная станция конфигурируется с конфигурацией TDD по умолчанию и применяет определенную конфигурацию TDD для радиокадров n+m, и применяет конфигурацию TDD по умолчанию для радиокадров n+m+1. m>=1, и n связано с радиокадром, в котором управляющая информация нисходящей линии связи и код обнаружения ошибок принимаются мобильной станцией.
Второй вариант осуществления настоящего изобретения обеспечивает мобильную станцию для обработки одной из множества конфигураций дуплексной связи с временным разделением, TDD, в системе связи. Конфигурация TDD задает подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или большем количестве радиокадров. Приемная секция мобильной станции принимает управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок для управляющей информации нисходящей линии связи. Код обнаружения ошибок управляющей информации нисходящей линии связи скремблирован базовой станцией с идентификатором целевой соты, связанным, по меньшей мере, с одной целевой сотой, к которой должна применяться конфигурация TDD. Процессор мобильной станции определяет идентификатор, использованный для скремблирования кода обнаружения ошибок управляющей информации нисходящей линии связи. Процессор определяет конфигурацию TDD из управляющей информации нисходящей линии связи в случае, если определенный идентификатор является идентификатором целевой соты. Процессор определяет, по меньшей мере, одну целевую соту, к которой должна применяться определенная конфигурация TDD, из идентификатора целевой соты, использованного для скремблирования кода обнаружения ошибок для управляющей информации нисходящей линии связи.
Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, система связи является системой связи LTE, и управляющая информация нисходящей линии связи является управляющей информацией нисходящей линии связи в формате 1C. Процессор определяет, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD из управляющей информации нисходящей линии связи, содержащей недействительный параметр. Недействительный параметр может быть параметром назначения ресурсного блока, имеющим длину 3-9 битов и недействительное значение, такое как все биты параметра назначения ресурсного блока, равные "1".
Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, управляющая информация нисходящей линии связи содержит недействительный параметр с одним из множества недействительных значений. Процессор определяет, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD, на основании любого из недействительных значений. Процессор определяет, на основе конкретного недействительного значения недействительного параметра в управляющей информации нисходящей линии связи, по меньшей мере, одно из следующего:
конфигурацию TDD,
инструкцию HARQ, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться,
параметр времени действия, указывающий величину времени, в течение которого указанная конфигурация TDD должна применяться, из параметра времени действия, предпочтительно при этом параметр времени действия указывает индекс, связанный с предварительно определенной величиной времени,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, процессор определяет из управляющей информации нисходящей линии связи, по меньшей мере, одно из следующего:
конфигурацию TDD из поля конфигурации TDD, предпочтительно при этом поле конфигурации TDD имеет длину 3 бита,
инструкцию HARQ, включающую в себя инструкцию, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться, предпочтительно при этом инструкция HARQ имеет длину 1 бит,
параметр времени действия для указанной конфигурации TDD, из которого процессор приспособлен определять величину времени, в течение которого указанная конфигурация TDD должна применяться, предпочтительно при этом параметр времени действия имеет длину 1-2 бита и указывает индекс, связанный с предварительно определенной величиной времени,
битовое значение поля заполнения, такое что мобильная станция определяет, является ли битовое значение поля заполнения тождественным предварительно определенному битовому значению, предпочтительно при этом дополнительное поле имеет длину 1-32 бита,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации второго варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, мобильная станция конфигурируется с конфигурацией TDD по умолчанию. Процессор применяет определенную конфигурацию TDD для радиокадров n+m, и применяет конфигурацию TDD по умолчанию для радиокадров n+m+1, где m>=1, и n связано с радиокадром, причем управляющая информация нисходящей линии связи и код обнаружения ошибок принимаются мобильной станцией.
Второй вариант осуществления настоящего изобретения обеспечивает базовую станцию для указания одной из множества конфигураций дуплексной связи с временным разделением, TDD, для мобильной станции в системе связи. Конфигурация TDD задает подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или большем количестве радиокадров. Процессор базовой станции принимает решение о конфигурации TDD. Процессор формирует управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок для управляющей информации нисходящей линии связи, управляющая информация нисходящей линии связи указывает конфигурацию TDD по принятому решению. Процессор скремблирует сформированный код обнаружения ошибок с идентификатором целевой соты, связанным, по меньшей мере, с одной целевой сотой, к которой должна применяться конфигурация TDD. Передатчик передает сформированную управляющую информацию нисходящей линии связи и скремблированный код обнаружения ошибок на мобильную станцию.
Третий вариант осуществления настоящего изобретения обеспечивает способ для указания одной из множества конфигураций дуплексной связи с временным разделением, TDD, для мобильной станции в системе связи. Конфигурация TDD задает подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или большем количестве радиокадров. Мобильная станция принимает от базовой станции управляющую информацию нисходящей линии связи, причем управляющая информация нисходящей линии связи указывает конфигурацию TDD и дополнительно содержит недействительный параметр, указывающий, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD. Мобильная станция определяет, содержит ли принятая управляющая информация нисходящей линии связи недействительный параметр. Мобильная станция определяет конфигурацию TDD из управляющей информации нисходящей линии связи в случае, если принятая управляющая информация нисходящей линии связи содержит недействительный параметр.
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, система связи является системой связи LTE, и управляющая информация нисходящей линии связи является управляющей информацией нисходящей линии связи в формате 1C, причем недействительный параметр является параметром назначения ресурсного блока, имеющим длину 3-9 битов и недействительное значение, такое как все биты параметра назначения ресурсного блока, равные "1".
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, недействительный параметр может принимать одно из множества недействительных значений. Все из множества недействительных значений указывают, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD, и каждое или группа недействительных значений указывают, по меньшей мере, одно из следующего:
конфигурацию TDD
идентификатор целевой соты, идентифицирующий целевую соту, к которой должна применяться конфигурация TDD
инструкцию HARQ, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой должна применяться конфигурация TDD
параметр времени действия для указанной конфигурации TDD, такой что мобильная станция определяет величину времени, в течение которого указанная конфигурация TDD должна применяться, из параметра времени действия, предпочтительно при этом параметр времени действия указывает индекс, связанный с предварительно определенной величиной времени,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, управляющая информация нисходящей линии связи содержит, по меньшей мере, одно из следующего:
поле конфигурации TDD, указывающее конфигурацию TDD, предпочтительно при этом поле конфигурации TDD имеет длину 3 бита,
идентификатор целевой соты, идентифицирующий целевую соту, для которой конфигурация TDD должна применяться, предпочтительно при этом идентификатор целевой соты имеет длину 1-5 битов,
инструкцию HARQ, включающую в себя инструкцию, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться, предпочтительно при этом инструкция HARQ имеет длину 1 бит,
параметр времени действия для указанной конфигурации TDD, такой что мобильная станция определяет величину времени, в течение которого указанная конфигурация TDD должна применяться, из параметра времени действия, предпочтительно при этом параметр времени действия имеет длину 1-2 бита и указывает индекс, связанный с предварительно определенной величиной времени,
поле заполнения битового значения, такое что мобильная станция определяет, является ли битовое значение поля заполнения тождественным предварительно определенному битовому значению, предпочтительно при этом дополнительное поле имеет длину 1-32 бита,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, мобильная станция принимает от базовой станции код обнаружения ошибок для принятой управляющей информации нисходящей линии связи, причем код обнаружения ошибок для управляющей информации нисходящей линии связи скремблирован базовой станцией с идентификатором системной информации. Предварительно определенные окна приема системной информации однозначно связаны с конкретными сообщениями системной информации. Мобильная станция принимает управляющую информацию нисходящей линии связи и соответствующий код с обнаружением ошибок, скремблированный с идентификатором системной информации, в рамках одного из упомянутых окон приема системной информации, которое не используется базовой станцией для передачи системной информации в результате сконфигурированных периодичностей для сообщений системной информации.
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, мобильная станция конфигурируется с конфигурацией TDD по умолчанию. Мобильная станция применяет определенную конфигурацию TDD для радиокадров n+m, и применяет конфигурацию TDD по умолчанию для радиокадров n+m+1, где m>=1, и n связано с радиокадром, в котором управляющая информация нисходящей линии связи и код обнаружения ошибок принимаются мобильной станцией.
Третий вариант осуществления настоящего изобретения обеспечивает мобильную станцию для обработки одной из множества конфигураций дуплексной связи с временным разделением, TDD, в системе связи. Конфигурация TDD задает подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или большем количестве радиокадров. Приемная секция мобильной станции принимает от базовой станции управляющую информацию нисходящей линии связи, причем управляющая информация нисходящей линии связи указывает конфигурацию TDD и дополнительно содержит недействительный параметр, указывающий, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD. Процессор мобильной станции определяет, содержит ли принятая управляющая информация нисходящей линии связи недействительный параметр. Процессор дополнительно определяет конфигурацию TDD из управляющей информации нисходящей линии связи в случае, если принятая управляющая информация нисходящей линии связи содержит недействительный параметр.
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, система связи является системой связи LTE, и управляющая информация нисходящей линии связи является управляющей информацией нисходящей линии связи в формате 1C. Недействительный параметр является параметром назначения ресурсного блока, имеющим длину 3-9 битов и недействительное значение, такое как все биты параметра назначения ресурсного блока, равные "1".
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, недействительный параметр может принимать одно из множества недействительных значений. Процессор определяет, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD, на основании любого из недействительных значений. Процессор на основе конкретного недействительного значения недействительного параметра управляющей информации нисходящей линии связи определяет, по меньшей мере, одно из следующего:
конфигурацию TDD,
идентификатор целевой соты, идентифицирующий целевую соту, для которой конфигурация TDD должна применяться,
инструкцию HARQ, включающую в себя инструкцию, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться,
параметр времени действия, указывающий величину времени, в течение которого указанная конфигурация TDD должна применяться, из параметра времени действия, предпочтительно при этом параметр времени действия указывает индекс, связанный с предварительно определенной величиной времени,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, процессор определяет из управляющей информации нисходящей линии связи, по меньшей мере, одно из следующего:
конфигурацию TDD из поля конфигурации TDD, предпочтительно при этом поле конфигурации TDD имеет длину 3 бита,
идентификатор целевой соты, идентифицирующий целевую соту, для которой конфигурация TDD должна применяться, предпочтительно при этом идентификатор целевой соты имеет длину 1-5 битов,
инструкцию HARQ, включающую в себя инструкцию, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для связи для соты, к которой конфигурация TDD должна применяться, предпочтительно при этом инструкция HARQ имеет длину 1 бит,
параметр времени действия для указанной конфигурации TDD, из которого процессор приспособлен определять величину времени, в течение которого указанная конфигурация TDD должна применяться, предпочтительно при этом параметр времени действия имеет длину 1-2 бита и указывает индекс, связанный с предварительно определенной величиной времени,
битовое значение поля заполнения, такое что мобильная станция определяет, является ли битовое значение поля заполнения тождественным предварительно определенному битовому значению, предпочтительно при этом дополнительное поле имеет длину 1-32 бита,
инструкцию процедуры отчета о состоянии буфера, предписывающую отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкцию процедуры запроса планирования, предписывающую отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкцию процедуры произвольного доступа к каналу, предписывающую отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD,
инструкцию формирования отчета о запасе мощности, предписывающую отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, приемная секция принимает от базовой станции код обнаружения ошибок для принятой управляющей информации нисходящей линии связи, причем код обнаружения ошибок для управляющей информации нисходящей линии связи скремблирован базовой станцией с идентификатором системной информации. Предварительно определенные окна приема системной информации однозначно связаны с конкретными сообщениями системной информации. Приемная секция принимает управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок, скремблированный с идентификатором системной информации, в рамках одного из упомянутых окон приема системной информации, которое не используется базовой станцией для передачи системной информации в результате сконфигурированных периодичностей для сообщений системной информации.
Согласно полезной модификации третьего варианта осуществления изобретения, каковое может использоваться в дополнение или альтернативно к вышеуказанному, мобильная станция конфигурируется с конфигурацией TDD по умолчанию. Процессор применяет определенную конфигурацию TDD для радиокадров n+m, и применяет конфигурацию TDD по умолчанию для радиокадров n+m+1, где m>=1, и n связано с радиокадром, причем управляющая информация нисходящей линии связи и код обнаружения ошибок принимаются мобильной станцией.
Третий вариант осуществления настоящего изобретения обеспечивает базовую станцию для указания одной из множества конфигураций дуплексной связи с временным разделением, TDD, для мобильной станции в системе связи, причем конфигурация TDD задает подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или нескольких радиокадрах. Процессор базовой станции принимает решение о конфигурации TDD. Процессор формирует управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок для управляющей информации нисходящей линии связи, управляющая информация нисходящей линии связи указывает конфигурацию TDD принятого решения и включает в себя недействительный параметр, указывающий, что управляющая информация нисходящей линии связи указывает одну из множества конфигураций TDD. Передатчик базовой станции передает сформированную управляющую информацию нисходящей линии связи на мобильную станцию.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
В последующем изобретение описывается более конкретно со ссылкой на сопроводительные фигуры и чертежи.
Фиг.1 - показ примерной архитектуры системы LTE 3GPP,
Фиг.2 - показ примерного общего представления общей архитектуры E-UTRAN в LTE 3GPP,
Фиг.3 - показ примерных границ подкадра в компонентной несущей нисходящей линии связи, как определено для LTE 3GPP (Версия 8/9),
Фиг.4 - показ примерной ресурсной сетки нисходящей линии связи для временного интервала нисходящей линии связи, как определено для LTE 3GPP (Версия 8/9),
Фиг.5 - иллюстрация структуры обработки для единичной управляющей информации нисходящей линии связи, как определено 3GPP,
Фиг.6 - показ семи стандартизированных в настоящий момент конфигураций 0-6 для UL/DL TDD, соответственных определений 10 подкадров и периодичности их точки переключения,
Фиг.7 – иллюстрация структуры радиокадра, составляемого из двух полукадров и 10 подкадров, для периодичности точки переключения в 5 мс,
Фиг.8 – показ семи стандартизированных в настоящий момент конфигураций 0-6 для UL/DL TDD по Фиг.6, и примерной связности с семью TDD-RNTI согласно первому варианту осуществления,
Фиг.9 – иллюстрация основной структурной схемы для функционирования мобильной станции согласно первому варианту осуществления изобретения,
Фиг.10 – показ семи стандартизированных в настоящий момент конфигураций 0-6 для UL/DL TDD по Фиг.6, и примерной связности с семью значениями указателя конфигурации TDD согласно второму и третьему варианту осуществления,
Фиг.11 – схематичная иллюстрация сценария со многими малыми сотами и одной макросотой, названного улучшенной Локальной зоной,
Фиг.12 – иллюстрация основной структурной схемы для функционирования мобильной станции согласно второму варианту осуществления,
Фиг.13 – иллюстрация основной структурной схемы для функционирования мобильной станции согласно третьему варианту осуществления, и
Фиг.14 – показ двух радиокадров с различными конфигурациями UL/DL TDD вместе с некоторыми временными соотношениями для передач данных и обратной связи.
ПОДРОБНОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
В последующих параграфах будут описаны различные варианты осуществления изобретения. Лишь с иллюстративными целями большинство вариантов осуществления в общих чертах представлены относительно схемы радиодоступа в соответствии с системами мобильной связи LTE (Версии 8/9) и LTE-A (Версии 10/11/12) 3GPP, частично обсужденными в разделе «Уровень техники» выше. Следует отметить, что изобретение может преимущественно использоваться, например, в системе мобильной связи, такой как системы связи LTE-A 3GPP (Версии 10/11/12), как описано в разделе «Уровень техники» выше, но изобретение не ограничивается его использованием в этих конкретных примерных сетях связи.
Термин "конфигурация TDD" относится к конфигурации «Восходящая линия связи/Нисходящая линия связи» в TDD, как определено в текущем стандарте, где конфигурация TDD задает для каждого подкадра радиокадра, является ли он подкадром нисходящей линии связи, восходящей линии связи или специальным подкадром. Термин "индекс конфигурации TDD" являет собой номер (в настоящий момент 0-6), соответственно связанный с одной из семи возможных конфигураций UL/DL TDD, и определенный в технических стандартах 3GPP (см. Фиг.6).
Термин "конфигурация TDD по умолчанию", используемый в формуле изобретения, а также по всему описанию, относится к конфигурации TDD, которая конфигурируется в системе «полустатически» с использованием SIB1, как пояснено в разделе уровня техники. В другой формулировке, конфигурация TDD по умолчанию является такой, что одна конфигурация TDD осуществляет вещание на все UE в зоне связи базовой станции, используя традиционный механизм процедуры сбора и изменения системной информации. Безусловно, "конфигурация TDD по умолчанию" также может быть изменена в течение связи, хотя не так динамически, как с помощью настоящего изобретения, а в продолжительный рабочий период.
Термин "скремблирование", используемый в формуле изобретения в связи с кодом с обнаружением ошибок и используемый в подробном описании изобретения в основном в связи с CRC (как примера кода обнаружения ошибок), относится к процессу неявного кодирования, например, идентификатора в код с обнаружением ошибок (CRC). Термин "маскирование" считается эквивалентом в этой заявке.
Термин "недействительный параметр", используемый в формуле изобретения и описании, следует понимать в широком смысле в качестве параметра, имеющего недействительное значение, таким образом, образующего недействительный параметр.
В последующем несколько вариантов осуществления изобретения будут пояснены подробно. Пояснения не следует понимать в качестве ограничивающих изобретение, а просто в качестве примеров вариантов осуществления изобретения для лучшего понимания изобретения. Специалист в данной области техники должен знать, что общие принципы изобретения, как изложено в формуле изобретения, могут применяться к различным сценариям и способами, которые явно в документе не описаны. Соответственно, следующие сценарии, предполагаемые для целями пояснения различных вариантов осуществления, не будут ограничивать изобретение как таковое.
Различные варианты осуществления, поясненные для изобретения, в общем относятся к конфигурациям TDD и в частности предлагают быстрый механизм для динамического изменения конфигурации TDD из конфигурации TDD по умолчанию (сконфигурированной посредством SIB) в целевую конфигурацию TDD.
Как пояснено в разделе уровня техники, полустатическое реконфигурирование конфигурации TDD по предшествующему уровню техники является медленным и громоздким и будет улучшено путем динамического процесса согласно одному из различных вариантов осуществления, поясненных ниже.
Три последующих варианта осуществления используют передачу DCI от базовой станции, чтобы указать изменение конфигурации TDD для одной или более сот. Конфигурация TDD может либо неявно кодироваться в упомянутую передачу (в CRC, как для первого варианта осуществления), либо более непосредственно в виде параметра части DCI (как для второго и третьего вариантов осуществления), либо кодируется в транспортном блоке, который указывается посредством DCI.
Первый вариант осуществления
Согласно первому набору вариантов осуществления изобретения, конфигурация TDD кодируется в CRC для DCI, и то, и другое передается (обычно широковещательно) от базовой станции для конкретной соты радиосвязи.
Для этой цели заданы определения семи различных RNTI, например, на базовой станции или другом объекте в сети, причем каждый из семи различных RNTI связан с одной из семи конфигураций TDD, так что каждая конфигурация 0-6 для TDD связана с одним отличающимся RNTI. Фиг.8 иллюстрирует возможную взаимосвязь, где значения TDD_0-6_RNTI являются связанными с конфигурациями TDD. Затрата на RNTI таким образом строго ограничивается числом конфигураций TDD, и, например, не связана с числом малых сот в сценарии eLA (см. далее второй вариант осуществления). RNTI для TDD предпочтительно имеют длину 16-24 бита и могут выбираться свободно, но предпочтительно выбираются из диапазона FFEO-FFFC в шестнадцатеричной нотации для 16-битового случая и могут указываться образом, подобным как в настоящий момент осуществляется для M-RNTI, P-RNTI, SI-RNTI, или определяться и конфигурироваться базовой станцией и передаваться на приемники мобильных устройств посредством передачи сообщений конфигурации RRC или системной информации.
В одной модификации первого варианта осуществления (каковое также применяется ко второму и третьему варианту осуществления) не все семь конфигураций TDD подлежат связыванию. В этом случае, нет необходимости семи различных RNTI, а например, четыре TDD-RNTI достаточны для различения необходимых конфигураций TDD, которые будут доступными для динамического реконфигурирования TDD согласно изобретению.
Взаимосвязи «TDD-RNTI - конфигурация TDD» могут указываться таким же образом, как в настоящий момент M-RNTI, P-RNTI, SI-RNTI, или определяться и конфигурироваться базовой станцией и передаваться на мобильную станцию(ии); и возможно на базовую станцию(ии), в случае, если решение принимает другой объект сети. Это может делаться различными другими путями, и конкретный используемый способ не является важным для функционирования изобретения. Например, взаимосвязь по таблице на Фиг.8 можно передавать, используя сообщения RRC, сообщения системной информации, или можно создавать в ходе установления соединения. Соответственно, и базовая станция, и мобильная станция имеют информацию, необходимую для реализации динамического реконфигурирования TDD согласно первому варианту осуществления.
Базовая станция в некоторый момент во времени может принять решение, что конфигурация TDD по умолчанию не является оптимальной, и что другая конфигурация TDD будет более выгодной. Это может быть, например, обусловлено другой ситуацией с трафиком или подобными обстоятельствами. Базовая станция, таким образом, принимает решение о целевой конфигурации TDD (из числа доступных оставшихся шести конфигураций TDD), отличной от конфигурации TDD по умолчанию, и выполняет динамическое реконфигурирование TDD, как изложено ниже.
Базовая станция после принятия решения о новой конфигурации TDD для конкретных сот(ы), формирует DCI (нового или известного формата, или известного формата, но в виде расширения к нему, см. ниже), и затем вычисляет код обнаружения ошибок (в 3GPP используется CRC в качестве кода с обнаружением ошибок) для сформированной DCI. В предшествующем уровне техники CRC был бы скремблирован с любым из различных RNTI, в зависимости от передаваемого вида DCI. В данном случае, CRC, вычисленный для DCI, скремблируют с TDD-RNTI, связанным с определенной целевой конфигурацией TDD, например, с TDD_1_RNTI для конфигурации 1 TDD (см. Фиг.8; и при условии, что конфигурация TDD по умолчанию не является конфигурацией 1 TDD). Фактическое скремблирование CRC и RNTI TDD может выполняться обычным образом, как общеизвестно в области техники и пояснено в разделе уровня техники в качестве примера для LTE 3GPP.
После того, как базовая станция сформировала DCI, вычислила CRC и скремблировала CRC с соответствующим RNTI TDD, DCI и скремблированный CRC передаются в соте. Сообщение DCI/CRC может передаваться в PDCCH или ePDCCH, и предпочтительно в общей области поиска таковых в случае, если многие или все мобильные станции должны быть проинформированы о реконфигурировании. В других случаях передача в специфической для UE области поиска может быть более эффективной, поскольку параметры передачи могут быть приспособлены к предполагаемому получателю и соответственным преобладающим условиям передачи.
Согласно одной модификации варианта осуществления, одно из уже доступных сообщений управляющей информации по нисходящей линии связи, как определено 3GPP и кратко обсуждено в разделе уровня техники, повторно используется для упомянутой цели. Другими словами, базовая станция повторно использует один из Форматов 0, 1, 1A, 1B, 1C, 1D, 2, 2A, 2B, 2C DCI, 2D, 3, 3A, 4 (как определено на момент подачи данной заявки; или любой другой формат, определенный 3GPP в будущем) для динамического реконфигурирования TDD вместо фактически намеченного предназначения конкретного сообщения формата DCI.
Например, может повторно использоваться сообщение DCI Формата 1C, который имеет наименьшее количество битов из всех доступных форматов DCI. Следует отметить, что хотя в последующем описании к тому же в основном для второго и третьего вариантов осуществления формат 1C для DCI используется для иллюстрации принципов изобретения, другие форматы DCI могут быть повторно используемыми в целях изобретения.
Формат 1C DCI в 3GPP определен для включения следующих полей:
- назначение ресурсного блока (RBA) 3-9 битов (в зависимости от полосы пропускания)
- схема модуляции и кодирования (MCS) 5 битов
- указатель значения защитного интервала 1 бит (только если полоса пропускания >= 50 PRB)
Более конкретное обсуждение содержимого Формата 1C DCI можно найти в Главе 5.3.3.1.4 документа TS 36.212 3GPP, включенной тем самым путем ссылки. Таким образом, сообщение формата 1C DCI может иметь длину между 8 и 15 битами.
Соответственно, вместо посылки вышеуказанных параметров для назначения PDSCH, как предназначено для Формата 1C DCI, базовая станция может включать в DCI другие параметры. Это частично зависит от полосы пропускания в соте, поскольку количество битов, доступных в Формате 1C DCI, зависит от полосы пропускания. Эти другие параметры, подлежащие включению в Формат 1C DCI, могут содержать, по меньшей мере, одно из следующего:
- идентификатор целевой соты, идентифицирующий целевую соту, для которой конфигурация TDD в виде неявно закодированной в CRC для DCI должна применяться,
- инструкцию HARQ для предписания мобильной станции(ям) перезапускать или не перезапускать протокол HARQ по применении новой конфигурации TDD,
- параметр времени действия для закодированной конфигурации TDD, указывающий мобильной станции(ям) величину времени, которая упомянутая конфигурация TDD должна применяться, до переключения обратно на конфигурацию TDD по умолчанию,
- поле заполнения с предварительно определенным битовым значением (виртуальным CRC), которое может использоваться, чтобы "заполнить" DCI так, что оставшиеся, иначе, неиспользуемые биты, находят полезное применение с тем, чтобы снизить риск ложного аварийного сигнала
- инструкцию процедуры отчета о состоянии буфера (BSR), предписывающую отменить ожидающую процедуру BSR или инициировать новую процедуру BSR, по применении указанной конфигурации TDD,
- инструкцию процедуры запроса планирования (SR), предписывающую отменить ожидающую процедуру SR или инициировать новую процедуру SR, по применении указанной конфигурации TDD,
- инструкцию процедуры канала произвольного доступа (RACH), предписывающую отменить ожидающую процедуру RACH или инициировать новую процедуру RACH, по применении указанной конфигурации TDD,
- инструкцию формирования отчета о запасе мощности (PHR), предписывающую отменить ожидающую PHR или инициировать новую PHR, по применении указанной конфигурации TDD.
Эти параметры только кратко обсуждаются выше с целями иллюстрации и будут поясняться более подробно далее.
При использовании такого известного формата DCI также является возможным установить для базовой станции один из параметров, задаваемых для упомянутого известного формата DCI, в недействительное значение и таким образом использовать недействительный параметр в качестве "кодовой точки переключения" для указания для мобильной станции, что DCI, переносящая недействительный параметр, не является обычной, а несет указатель конфигурации UL/DL TDD. Сообщение DCI таким образом включает в себя упомянутый особый (недействительный) параметр, в виде обычного сообщения DCI, однако с недействительным значением. Это недействительное значение является известным и базовой станции, и мобильной станции. Полагая в качестве примера уже стандартизированный формат 1C DCI, параметр назначения ресурсного блока может быть установлен в недействительное значение, такое как все значения битов являются "1".
Недействительное значение для параметра или комбинации параметров может обычно характеризоваться как представляющее состояние, которое является зарезервированным или противоречит требованиям к указанному параметру. Например, недействительное значение назначения ресурсного блока является таким, которое приведет к назначению, по меньшей мере, одного ресурсного блока с отрицательным индексом или, по меньшей мере, одного ресурсного блока вне доступных ресурсных блоков. Другой пример недействительного значения относится к параметру номера процесса HARQ в случае TDD с индексом HARQ, который указывает процесс HARQ вне заданного максимального числа процессов HARQ, как указано в Таблице 7-1 в документе TS 36.213 3GPP. Примером комбинации недействительных параметров, где значение представляет зарезервированное состояние, является 'информация предварительного кодирования' в виде доступной, например, в формате 2 DCI, где в зависимости от числа указанных транспортных блоков различные значения информации предварительного кодирования определены как 'зарезервированные', и где количество указанных транспортных блоков зависит от комбинации из указанной схемы модуляции и кодирования и версии избыточности, как указано в главе 7.1.7.2 в документе TS 36.213 3GPP.
Для типа 2 распределения ресурсов, по меньшей мере, одно состояние RBA является недействительным для всех полос частот 6-110 PRB нисходящей линии связи, а именно, когда все значения битов установлены в "1". Для 10 и 13 PRB имеется точно одно недействительное состояние, уже упомянутые все биты = 1. Для 6 PRB имеются 2 недействительных значения RBA. Для 15 PRB имеются 4 недействительных значения RBA. Для 25 PRB имеются 50 недействительных значений RBA. Для 50 PRB имеются 62 недействительных значения RBA для интервала 1 и 83 недействительных значения RBA для интервала 2. Для 75 PRB имеются 120 недействительных значений RBA, и для 100 и 110 PRB, имеются 212 недействительных значений RBA.
Конкретно, при наличии полосы частот, где имеются более одного недействительного значения (то есть, все кроме для 10 и 13 PRB, каковые, однако, являются менее важными на практике), дополнительная информация может быть закодирована в этот недействительный параметр DCI помимо указания, что DCI, переносящая недействительный параметр, несет указатель конфигурации UL/DL TDD. Дополнительная информация может быть одним из вышеуказанных других параметров, а именно, по меньшей мере, одним из идентификатора целевой соты, инструкции HARQ и параметра времени действия, инструкции BRS, инструкции SR, инструкции RACH и инструкции PHR. Безусловно, если один из этих параметров кодируется в недействительный параметр, то DCI не должна включать упомянутый конкретный параметр отдельно в свою полезную нагрузку.
Например, рассматривая полосу частот в 15 PRB с 4 недействительными значениями RBA, все из 4 недействительных значений RBA указывают мобильной станции, что DCI, переносящая упомянутое недействительное значение RBA, включает в себя указатель относительно динамической конфигурации TDD. Кроме того, каждое конкретное недействительное значение RBA может дополнительно связываться с одним отличающимся параметром времени действия (например, 10 мс, 40 мс, 100 мс и 200 мс), или устанавливать различие между различными целевыми сотами, для которых должна применяться конфигурация TDD (например, PCell, SCell1, SCell2 или SCell3).
Альтернативно, 2 из недействительных значений RBA связываются с инструкцией «перезапустить HARQ», и остальные 2 недействительных значения RBA связываются с инструкцией «не перезапускать HARQ». Подобные соображения применяют для других полос частот; например, когда доступны только 2 недействительных состояния для параметра RBA, то только два различных состояния для дополнительной информации могут быть закодированы, такие как инструкция HARQ, или параметр времени действия (например, с различением действительных периодов в 10 мс и 40 мс).
В качестве альтернативы повторному использованию известного формата DCI (такого как Формат 1C), является возможным также создать расширение известного формата DCI, так что известный формат DCI используется только для конкретных случаев, и другая "версия" известного формата DCI используется для других конкретных случаев. Например, будет возможным приспосабливать известный формат DCI (такой как Формат 1C), чтобы был применимым только для конкретных радиокадров или подкадров в рамках конкретных радиокадров, и включал в себя определение, которое задает известный формат DCI, который будет использоваться для динамического реконфигурирования UL/DL TDD, для других радиокадров или других подкадров в рамках конкретных радиокадров, где в зависимости от "версии" формат DCI может содержать различные информационные элементы.
Альтернативно вышеуказанному, также возможно использовать формат DCI, специально заданный для цели динамического реконфигурирования TDD; например, к тому же имеющий другой размер, чем уже определенные форматы DCI. В упомянутом случае количество битов DCI не зависит от полосы пропускания соты, но может задаваться свободно в зависимости от параметров, которые должны передаваться в этой новой DCI. Например, может быть определен Формат 1E DCI, который включает в себя, по меньшей мере, один из вышеперечисленных параметров (идентификатор целевой соты, инструкцию HARQ, параметр времени действия, поле заполнения, инструкцию BSR, инструкцию SR, инструкцию RACH, инструкцию PHR).
Итак, базовая станция передает DCI и скремблированный CRC в своей соте, и мобильная станция(и) в соте принимают DCI и скремблированный CRC. Обработка DCI и CRC согласно этому первому варианту осуществления поясняется в связи с Фиг.9, которая показывает структурную схему мобильной станции для основного первого варианта осуществления изобретения.
Мобильная станция прослушивает PDCCH и EPDCCH, чтобы детектировать сообщения DCI, предназначенные для мобильной станции. После приема DCI и CRC от базовой станции, мобильная станция переходит к определению RNTI, с которым был скремблирован CRC. Конкретная проверка на наличие ошибок и дескремблирование могут выполняться обычным образом, как обсуждено на примерах в разделе уровня техники для LTE 3GPP. Например, мобильная станция выполняет проверку на наличие ошибок для DCI на основании CRC, DCI и различных возможных идентификаторов-кандидатов, которые, возможно, использовались для скремблирования DCI, из числа этих семи RNTI TDD. Только для одного из RNTI проверка CRC, выполняемая мобильной станцией, является успешной. Таким образом, мобильная станция определяет, что один конкретный RNTI TDD использовался для скремблирования.
Мобильная станция затем переходит к определению, с какой конфигурацией TDD определенный RNTI TDD является связанным, например, путем обращения к таблице, как определено на Фиг.8. Таким образом, например, мобильная станция определяет, что должна переключиться на конфигурацию TDD 1, вместо продолжения использования конфигурации TDD по умолчанию.
Определенная таким образом конфигурация TDD затем применяется мобильной станцией в течение конкретного времени. Это может либо предварительно задаваться являющимся фиксированной величиной времени, такой как 1, 2 или 4 радиокадра. В качестве альтернативы время может указываться динамически, например, с использованием параметра времени действия, уже упомянутого ранее как (необязательно) являющегося частью полезной нагрузки DCI или закодированного в недействительный параметр (см. выше). При допущении, что мобильная станция принимает передачу DCI/CRC в радиокадре n, она затем соответственно обрабатывает DCI и CRC и применяет указанную конфигурацию TDD для конкретного числа радиокадров n+1, n+2, n+3 и т.д., в зависимости от параметра времени действия из DCI или предварительно определенной фиксированной величины времени. После того, как динамически указанная конфигурация TDD "истекает", то есть, более не будет применяться, мобильная станция переключается обратно в конфигурацию TDD по умолчанию до тех пор, например, пока не примет другую DCI TDD для динамического реконфигурирования UL/DL TDD.
Альтернативно, мобильная станция может также переходить к применению новой конфигурации TDD, пока она не примет другое реконфигурирование TDD; другими словами, новая конфигурация TDD указывается не на конкретную величину времени, а на неопределенную, пока не будет предписано иное.
Мобильная станция может также определять дополнительные параметры из DCI в зависимости от того, включает ли DCI таковые. Например, мобильная станция может определять целевую соту, инструкцию HARQ, параметр времени действия, значение поля дополнения, инструкцию BRS, инструкцию SR, инструкцию RACH и/или инструкцию PHR из нее.
Подробности относительно того, каким образом используется информация, извлеченная из этих дополнительных параметров, поясняются далее отдельно в связи с этими параметрами.
Согласно дополнительной модификации первого варианта осуществления, CRC из DCI скремблирован посредством TDD-RNTI, хотя потребуется задание только одного TDD-RNTI с этой целью вместо множественных TDD-RNTI, где DCI назначает физические ресурсы для передачи транспортного блока таким образом, как, например, в настоящий момент формат 1A DCI может использоваться для назначения физических ресурсов для транспортного блока. Упомянутый транспортный блок может затем представлять сообщение MAC или RRC, которое содержит информацию и параметры о (ре-) конфигурировании TDD, как в общих чертах представлено в последующих разделах настоящей заявки. Другими словами, вместо (или в дополнение) использования полезной нагрузки DCI для указания одного или нескольких параметров конфигурации TDD, RNTI используется для идентификации, что передается сообщение реконфигурирования, и полезная нагрузка DCI дает информацию о транспортном блоке, который несет параметр(ы) конфигурации TDD.
Второй вариант осуществления
Второй вариант осуществления изобретения в основном отличается от первого варианта осуществления, поясненного выше, в том, что конфигурация UL/DL TDD не кодируется в RNTI, используемый для скремблирования CRC DCI, а вместо этого указатель конфигурации UL/DL TDD включается в полезную нагрузку DCI. Большинство остальных подробностей, однако, остаются одинаковыми между первым и вторым вариантами осуществления.
Указатель конфигурации UL/DL TDD в DCI различает 7 различных конфигураций UL/DL TDD по Фиг.6; таким образом, 3-битовое поле достаточно для указания конкретной конфигурации UL/DL TDD, где каждое значение указателя связано с одной из конфигураций TDD. Снова, также является возможным различать между меньшим числом конфигураций UL/DL TDD, так что уже является достаточным 2-битовое (или даже 1-битовое) поле; однако, с тем недостатком, что динамическое реконфигурирование TDD не является таким гибким.
Взаимосвязь между 3-битовыми значениями и конфигурациями TDD может задаваться базовой станцией или другим объектом сети. Примерная взаимосвязь для всех семи конфигураций TDD с использованием 3-битового поля указателя TDD иллюстрируется на Фиг.10. Информация о взаимосвязи между значениями указателя конфигурации TDD и фактическими конфигурациями TDD сообщается на мобильную станцию; и возможно на базовую станцию(ии), в случае, если решение принимает другой объект сети. Как в случае первого варианта осуществления, процедуру информирования можно осуществлять всевозможными способами; например, используя сообщения RRC, сообщения системной информации, или можно осуществлять в ходе установления соединения. Соответственно, и базовая станция, и мобильная станция имеют необходимую информацию, чтобы реализовывать динамическое реконфигурирование TDD по изобретению.
Что касается первого варианта осуществления, базовая станция принимает решение изменить конфигурацию UL/DL TDD из конфигурации TDD по умолчанию в другую целевую конфигурацию TDD, например, по причине, что целевая конфигурация TDD лучше подходит для текущего трафика. Базовая станция, таким образом, желает выполнять динамическое реконфигурирование TDD и формирует DCI, включающую в себя вышеуказанный указатель конфигурации UL/DL TDD.
Базовая станция, таким образом, формирует DCI для динамического реконфигурирования TDD, причем DCI включает в себя указатель конфигурации TDD, указывающий конфигурацию TDD, по которой приняла решение базовая станция. К тому же, как уже подробно пояснено для первого варианта осуществления, DCI может включать в себя дополнительные параметры, такие как, по меньшей мере, одно из инструкции HARQ, параметра времени действия, дополнительного поля, инструкции BRS, инструкции SR, инструкции RACH и инструкции PHR.
Таким же образом, как для первого варианта осуществления, сформированная базовой станцией DCI может быть одним из уже имеющихся сообщений управляющей информации нисходящей линии связи, как определено 3GPP (например, Форматы DCI 0, 1, 1A, 1B, 1C, 1D, 2, 2A, 2B, 2C, 2D, 3, 3A, 4). В этом случае, вместо посылки обычных параметров заданного Формата DCI (таких как RBA, MCS, указатель значения интервала для Формата 1C), базовая станция включает другие параметры. Как пояснено выше, включается поле указателя конфигурации TDD.
При использовании известного формата DCI для базовой станции также является возможным установить в недействительное значение один из параметров, задаваемых для упомянутой известной DCI. Недействительный параметр указывает мобильной станции, что DCI, переносящая недействительный параметр, дополнительно несет указатель конфигурации UL/DL TDD. Это было пояснено подробно для первого варианта осуществления, и те же принципы применяются также к второму варианту осуществления и не повторяются ради краткости. Вместо этого читателю любезно указывают соответствующие выдержки из первого варианта осуществления.
Кроме того, недействительный параметр можно понимать не только как указывающий мобильной станции, что DCI несет указатель реконфигурирования UL/DL TDD, но этот недействительный параметр может закодировать дополнительный параметр, такой как конкретный указатель реконфигурирования UL/DL TDD, или любой из других параметров, упомянутых выше: инструкцию HARQ, параметр времени действия, инструкцию BRS, инструкцию SR, инструкцию RACH, инструкцию PHR. Это весьма похоже на использование недействительного параметра для первого варианта осуществления, за исключением того, что недействительный параметр для первого варианта осуществления может закодировать идентификатор целевой соты, но не указатель конфигурации TDD, тогда как это иначе для второго варианта осуществления.
Альтернативно повторному использованию известного формата DCI (такого как формат 1C), также является возможным создать расширение известного формата, как уже пояснено для первого варианта осуществления. Чтобы избежать повторения, читателя отсылают к соответствующим разделам первого варианта осуществления.
В качестве дополнительной альтернативы также является возможным использовать формат DCI, специально определенный с целью динамического реконфигурирования TDD, например, с другим размером. Снова, читателя отсылают к соответствующим разделам первого варианта осуществления.
Независимо от фактически используемого формата DCI и независимо от того, включает или не включает DCI дополнительные параметры, базовая станция вычисляет код обнаружения ошибок для подобным образом сформированной DCI. Согласно второму варианту осуществления, код обнаружения ошибок (CRC) затем скремблируют с идентификатором соты, идентифицирующим целевую соту(ы), для которой должно применяться динамическое реконфигурирование TDD. Идентификатор соты может также называться SC-RNTI, RNTI малой соты.
Поскольку считается, что идентификатор соты для скремблирования с CRC имеет такую же длину, как CRC, то есть, ожидается, что будет длиной 16-24 бита, он особенно подходит для различения многих различных сот и таким образом предпочтительно может использоваться в сценариях, где имеется много сот. 16-24-битовые значения идентификатора соты могут гибко связываться либо с одиночными сотами, либо с другой группой сот. Это имеет преимущество в том, что базовая станция может гибко выполнять реконфигурирование TDD либо для одиночных сот (например, SCell1), и/или группы сот (например, соседних сот SCell1-SCell10) путем использования конкретного значения идентификатора целевой соты, связанного с ней. Кроме того, один из доступных идентификаторов целевой соты может также идентифицировать все соты как целевые соты. Решение о взаимосвязи между значениями идентификатора целевой соты и целевой сотой (группой) может приниматься в базовой станции или другом объекте сети, и затем должно сообщаться на мобильную станцию (и базовую станцию), так что и базовая станция, и мобильная станция имеют одинаковую информацию, необходимую для динамического реконфигурирования TDD согласно второму варианту осуществления. Что касается первого варианта осуществления, не является возможным использовать все доступные значения RNTI (65536 различных значений являются доступными для случая 16-битового RNTI), поскольку некоторые из них уже зарезервированы для других целей. Альтернативно, взаимосвязи могут быть предварительно определенными и фиксированными согласно стандарту.
Существующие механизмы, такие как поля указателя несущей, поддерживают только самое большее 8 различных сот. LTE-Advanced однако будет поддерживать расширенную Локальную зону (eLA), где многие десятки малых сот могут находиться в зоне обслуживания макросоты. Это схематично иллюстрируется на Фиг.11, где макросота с большой зоной обслуживания работает приблизительно с 800 МГц, и в ней многие соты с малой зоной обслуживания работают приблизительно с 3,4 ГГц. В таком развертывании сот мобильной станции может потребоваться различать более чем 7 малых сот, особенно если мобильная станция перемещается через зону обслуживания макросоты и должна выполнять измерения радиосвязи на множестве малых сот, чтобы определить одну с наиболее благоприятными условиями радиосвязи.
Итак, базовая станция передает DCI и скремблированный CRC для DCI, и мобильные станции, расположенные в соте, принимают DCI и скремблированный CRC. Обработка DCI и CRC в мобильной станции согласно второму варианту осуществления поясняется со ссылкой на Фиг.12.
Мобильная станция прослушивает PDCCH и EPDCCH, чтобы детектировать сообщения DCI, предназначенные для мобильной станции. Таким образом, мобильная станция принимает DCI и CRC от базовой станции и определяет RNTI, с которым CRC был скремблирован. Конкретные проверка на наличие ошибок и дескремблирование могут выполняться обычным образом, как описано иллюстративно в разделе уровня техники относительно LTE 3GPP. Например, мобильная станция выполняет проверку на наличие ошибок для DCI на основе CRC, DCI и различных возможных идентификаторов-кандидатов, которые возможно использовались для скремблирования DCI, из числа этих идентификаторов целевых сот. Только для одного из RNTI проверка CRC, выполняемая мобильной станцией, является успешной. Таким образом, мобильная станция определяет, что один из конкретных идентификаторов целевой соты был использован для скремблирования.
Из факта, что идентификатор целевой соты использовался для скремблирования CRC, мобильная станция может уже вывести, что DCI дополнительно указывает конфигурацию TDD для выполнения динамического реконфигурирования TDD. Соответственно, мобильная станция затем переходит к определению конкретной конфигурации TDD, закодированной в DCI, одним из различных способов, как пояснено выше. Таким образом, мобильная станция может либо считывать фактическое значение поля указателя конфигурации TDD, как показано на Фиг.10, и связывать значение с соответствующей конфигурацией TDD; либо мобильная станция определяет значение недействительного параметра и из значения недействительного параметра определяет связанную конфигурацию TDD.
Кроме того, мобильная станция определяет из определенного идентификатора целевой соты конкретную целевую соту или группу сот, для которых закодированная конфигурация TDD предназначена и должна применяться. Реконфигурирование TDD должно применяться мобильной станцией, только если мобильная станция фактически принадлежит идентифицированной целевой соте. Иначе, реконфигурирование TDD может игнорироваться мобильной станцией.
Если включены в DCI, мобильная станция может определять дополнительные параметры из полезной нагрузки DCI, например, параметр времени действия, инструкцию HARQ, значение поля дополнения, инструкцию BRS, инструкцию SR, инструкцию RACH и/или инструкцию PHR. Подробности относительно того, каким образом используется информация, извлеченная из этих дополнительных параметров, поясняются далее отдельно в связи с этими параметрами.
Определенная таким образом конфигурация TDD затем применяется мобильной станцией в течение конкретного времени. Как в случае первого варианта осуществления, это может либо предварительно задаваться являющимся фиксированной величиной времени, такой как 1, 2 или 4 радиокадра. Альтернативно, время может указываться динамически, например, путем использования параметра времени действия, уже упомянутого ранее, как являющегося (необязательно) частью полезной нагрузки DCI или кодируемого в недействительный параметр (см. выше). При допущении, что мобильная станция принимает передачу DCI/CRC в радиокадре n, она затем соответственно обрабатывает DCI и CRC и применяет указанную конфигурацию TDD для конкретного числа радиокадров n+1, n+2, n+3 и т.д., в зависимости от параметра времени действия в DCI или предварительно определенной фиксированной величины времени. После того, как динамически указанная конфигурация TDD "истекает", то есть более не будет применяться, мобильная станция переключается обратно в конфигурацию TDD по умолчанию, пока, например, она не примет другую DCI TDD для динамического реконфигурирования UL/DL TDD.
Альтернативно, мобильная станция может также переходить к применению новой конфигурации TDD, пока она не примет другое реконфигурирование TDD; другими словами, новая конфигурация TDD указывается не на конкретную величину времени, а неопределенно, пока не будет проинструктировано иное.
Согласно модификации второго варианта осуществления, CRC для DCI скремблируется согласно SC-RNTI, и DCI назначает физические ресурсы для передачи транспортного блока сходным образом, каким, например, существующий формат 1A DCI может использоваться для назначения физических ресурсов для транспортного блока. Упомянутый транспортный блок затем может представлять сообщение MAC или RRC, которое содержит информацию и параметры о (ре)конфигурировании TDD, как например, требуемую конфигурация TDD, или индекс целевой соты, или другие параметры, представленные в общих чертах в последующих разделах настоящей заявки.
Третий вариант осуществления
Третий вариант осуществления изобретения является подобным первому и второму вариантам осуществления в том, что имеет дело с динамическим реконфигурированием UL/DL TDD с использованием передачи DCI/CRC. Кроме того, подобно второму варианту осуществления, конфигурация UL/DL TDD не кодируется неявно в RNTI, используемый для скремблирования CRC, а вместо этого включается в полезную нагрузку DCI. Однако, согласно третьему варианту осуществления идентификатор целевой соты (SC-RNTI) не используется для скремблирования CRC DCI. Однако, DCI включает в себя недействительный параметр для указания мобильной станции, что DCI дополнительно содержит указатель относительно конфигурации TDD. Другими словами, недействительный параметр, уже обсужденный в связи с первым и вторым вариантами осуществления как являющийся необязательным параметром DCI, предназначенный для третьего варианта осуществления, всегда включен в полезную нагрузку DCI.
Иначе, многие подробности, уже обсужденные для первого и второго вариантов осуществления, остаются такими же для третьего варианта осуществления. По упомянутой причине повторения избегаются по возможности, и читателя отсылают к соответствующим выдержкам первого и/или второго варианта осуществления.
Таким же образом, как и для второго варианта осуществления, указатель конфигурации UL/DL TDD в DCI различает все 7 различных конфигураций UL/DL TDD по Фиг.6; или альтернативно, может различать меньшее количество конфигураций UL/DL TDD. Соответственно, указатель конфигурации UL/DL TDD может быть определен в виде иллюстративно изображенного на Фиг.10. Чтобы избежать повторения, читателя отсылают к разделам второго варианта осуществления, поясняющего подробно указатель конфигурации UL/DL TDD; который может быть включен в виде отдельного параметра в полезную нагрузку DCI, или может быть закодирован в недействительный параметр, когда доступно достаточно недействительных значений, как пояснено ранее. В любом случае, и базовая станция, и мобильная станция должны иметь общее понимание того, каким образом различные конфигурации TDD можно указывать, используя DCI.
Как уже обсуждено для первого и второго вариантов осуществления, базовая станция в некоторый момент времени может принять решение изменить конфигурацию UL/DL TDD из конфигурации TDD по умолчанию в другую конфигурацию UL/DL TDD, например, по причине, что конфигурация TDD лучше подходит для текущего трафика. Базовая станция тем самым желает выполнить динамическое реконфигурирование TDD, как будет пояснено ниже в связи с третьим вариантом осуществления.
Базовая станция формирует DCI, причем DCI включает в себя указатель конфигурации TDD для указания конфигурации TDD, по которой приняла решение базовая станция. Как пояснено для первого и второго вариантов осуществления подробно, DCI может дополнительно включать в себя дополнительные параметры; для этого конкретного третьего варианта осуществления: идентификатор целевой соты, инструкцию HARQ, параметр времени действия, поле заполнения, инструкцию BRS, инструкцию SR, инструкцию RACH и/или инструкцию PHR.
Поскольку DCI согласно третьему варианту осуществления всегда включает в себя недействительный параметр, сформированная базовой станцией DCI должна быть одним из уже доступных сообщений управляющей информации нисходящей линии связи, как определено 3GPP (например, Форматы 0, 1, 1A, 1B, 1C, 1D, 2, 2A, 2B, 2C DCI, 2D, 3, 3A, 4). Это уже заданное сообщение DCI является затем повторно используемым с целью несения указателя конфигурации TDD.
Кроме того, для случая, где имеются несколько недействительных значений, доступных для недействительного параметра (особенно для более больших полос пропускания), то возможно закодировать, по меньшей мере, один из вышеуказанных дополнительных параметров в недействительный параметр таким же образом, как для первого и второго варианта осуществления.
Например, допуская случай, где используется Формат 1C DCI, имеющий наименьшее количество числа битов, параметр RBA в формате 1C DCI может использоваться в качестве недействительного параметра и может быть установлен в недействительное значение. Как подробно пояснено для первого варианта осуществления, параметр RBA может принимать различное количество недействительных значений в зависимости от полосы пропускания, используемой в соте. Одно недействительное значение является одинаковым для всей полосы пропускания, а именно, где все биты параметра RBA установлены в единицу. Для большинства полос пропускания однако, параметр RBA может принимать несколько недействительных значений; для 6 PRB имеются 2 недействительных значения RBA; для 15 PRB имеются 4 недействительных значения RBA; для 25 PRB имеются 50 недействительных значений RBA; для 50 PRB имеются 62 недействительных значения RBA для интервала 1, и 83 недействительных значения RBA для интервала 2; для 75 PRB имеются 120 недействительных значений RBA, и для 100 и 110 PRB имеются 212 недействительных значений RBA.
Дополнительная информация может быть закодирована в этот недействительный параметр DCI кроме указания, что DCI, переносящая недействительный параметр, несет указатель конфигурации UL/DL TDD. Дополнительная информация может быть одним из вышеуказанных других параметров, а именно, по меньшей мере, одним из конфигурации TDD, идентификатора целевой соты, инструкции HARQ, параметра времени действия, инструкции BRS, инструкции SR, инструкции RACH и инструкции PHR. Безусловно, если один из упомянутых параметров кодируется в недействительный параметр, то DCI не должна содержать упомянутый конкретный параметр отдельно в своей полезной нагрузке.
Следовательно, в одной модификации третьего варианта осуществления (и фактически также второго варианта осуществления), формат 1C DCI для динамического реконфигурирования TDD включает в себя параметр RBA, установленный в недействительное значение (но кодирующее конкретную конфигурацию TDD), и поле заполнения для остающихся битов, поле заполнения, устанавливаемое в предварительно определенное значение и использующееся в качестве виртуального CRC.
Базовая станция формирует DCI, как пояснено выше, и затем вычисляет код обнаружения ошибок (CRC) для сформированной таким образом DCI. CRC скремблируется базовой станцией с RNTI; какой RNTI используется - не является важным для функционирования третьего варианта осуществления, однако для мобильной станции является выгодным ограничить операцию только до одного или ограниченного значения(ий) RNTI, чтобы минимизировать риск ошибочного обнаружения успешной передачи DCI, обусловленного ошибками передачи. Полезная модификация третьего варианта осуществления, где SI-RNTI используется для скремблирования, будет подробно пояснена дополнительно ниже.
Базовая станция передает DCI и скремблированный CRC для DCI, и мобильная станция(и), расположенная в соте, принимает DCI и скремблированный CRC. Обработка DCI и CRC мобильной станцией согласно третьему варианту осуществления поясняется со ссылкой на Фиг.13.
Мобильная станция прослушивает PDCCH и EPDCCH, чтобы детектировать сообщения DCI, предназначенные для мобильной станции. Таким образом, мобильная станция принимает DCI и CRC от базовой станции. CRC дескремблируется и содержимое DCI обрабатывается.
Мобильная станция затем определяет, содержит ли DCI недействительный параметр, и в случае, если содержит, мобильная станция делает вывод, что DCI не является обычной DCI, а используется базовой станцией для динамического реконфигурирования TDD и таким образом указывает конкретную конфигурацию TDD. Мобильная станция затем переходит к определению конкретной конфигурации TDD, закодированной в DCI, одним из различных способов, как пояснено выше. А именно, мобильная станция может либо считывать фактическое значение поля конфигурации TDD, как показано на Фиг.10, и связывать значение с соответствующей конфигурацией; либо мобильная станция определяет значение недействительного параметра и связывает определенное значение недействительного параметра с соответствующей конфигурацией TDD.
Кроме того, в зависимости от того, включает ли DCI дополнительные параметры, мобильная станция может определять значение любого другого параметра в DCI, такого как целевая сота(ы), время действия, инструкция HARQ, инструкция BRS, инструкция SR, инструкция RACH и/или инструкция PHR; является ли другой параметром кодированным в недействительный параметр или присутствующим как отдельный параметр в полезной нагрузке DCI.
Например, мобильная станция определяет из определенного идентификатора целевой соты конкретную целевую соту или группу сот, для которых закодированная конфигурация TDD предназначается и должна применяться. Реконфигурирование TDD должно применяться мобильной станцией, только если мобильная станция фактически принадлежит идентифицированной целевой соте. Иначе, реконфигурирование TDD может быть проигнорировано мобильной станцией. Подробности относительно того, каким образом информация, извлеченная из этих дополнительных параметров, используется, пояснены далее отдельно в связи с этими параметрами.
Определенная таким образом конфигурация TDD затем применяется мобильной станцией в течение конкретного времени. Как в случае первого варианта осуществления, это может либо предварительно задаваться являющимся фиксированной величиной времени, такой как 1, 2 или 4 радиокадра. Альтернативно, время может указываться динамически, например, с использованием параметра времени действия, уже упомянутого ранее как являющегося (необязательно) частью полезной нагрузки DCI или закодированного в недействительный параметр (см. выше). При допущении, что мобильная станция принимает передачу DCI/CRC в радиокадре n, она затем соответственно обрабатывает DCI и CRC и применяет указанную конфигурацию TDD для определенного числа радиокадров n+1, n+2, n+3 и т.д., в зависимости от параметра времени действия в DCI или предварительно определенной фиксированной величины времени. После того, как динамически указанная конфигурация TDD "истекает", то есть более не будет применяться, мобильная станция переключается обратно в конфигурацию TDD по умолчанию, пока например, она не примет другую DCI TDD для динамического реконфигурирования UL/DL TDD.
Альтернативно, мобильная станция может также переходить к применению новой конфигурации TDD, пока она не примет другое реконфигурирование TDD; другими словами, новая конфигурация TDD указывается не для конкретной величины времени, а неопределенно, пока не будет предписано иное.
Одна улучшенная модификация третьего варианта осуществления относится к CRC для DCI, скремблируемого базовой станцией с системной информацией RNTI (SI-RNTI), и, кроме того, конфигурации TDD DCI, передаваемой в окне приема SI, которое обычно не должно использоваться базовой станцией для посылки системной информации. Это будет пояснено подробно ниже.
В предшествующем уровне техники планирование во временной области для сообщений MIB и SIB1 является фиксированным с периодичностями 40 мс и 80 мс соответственно. Каждое сообщение SI передается в заданном, происходящем периодически окне временной области, тогда как сигнализация управления физического уровня указывает, в каких подкадрах в этом окне SI фактически спланирована. Окна планирования различных сообщений SI (именуемые окнами SI или окнами приема SI) являются последовательными (то есть, не имеется ни перекрытий, ни промежутков между ними), и имеют общую длину, являющуюся конфигурируемой. Окна SI могут включать в себя подкадры, в которых невозможно передавать сообщения SI, такие как подкадры, используемые для SIB1, и подкадры, используемые для восходящей линии связи в TDD.
Сообщения SI могут иметь различные периодичности. Следовательно, в некоторых кластерах окон SI все сообщения SI являются спланированными, тогда как в других кластерах передаются только сообщения SI с более короткими периодами повторения. Для одного примера кластер окон SI, начинающийся с Системного номера кадра (SFN) 0, содержит все сообщения SI, и кластер, начинающийся с другого SFN, может содержать только первое сообщение SI в зависимости от предварительно заданных периодичностей. Для более конкретного обсуждения окон SI, пожалуйста, обратитесь к техническому стандарту или материалу The UMTS Long Term Evolution - From Theory to Practice под редакцией Stefanie Sesia, Issam Toufik, Matthew Baker, Главам 3.2.2 и 3.2.2.1, включенным в документ путем ссылки.
В результате в зависимости от конкретных периодичностей (особенно для длительных периодов/циклов повторения), будут иметься окна SI, в которых SI не передается, и таким образом эти окна SI не будут использоваться базовой станцией для передачи системной информации. Этим можно пользоваться.
В одной модификации третьего варианта осуществления DCI, CRC которой скремблирован с SI-RNTI, передается базовой станцией в одном из упомянутых неиспользуемых окон SI. Мобильной станции известно заранее, что это конкретное окно SI не будет использоваться для передачи системной информации, поскольку мобильная станция также осведомлена о периодичностях сообщений SI. Таким образом, когда мобильная станция принимает SI-сообщение (то есть DCI TDD, CRC которой скремблирован с SI-RNTI), мобильной станции известно, что оно не может быть обычным SI-сообщением. Соответственно, она осведомлена, что это SI-сообщение, принятое в рамках окна SI, которое обычно не должно использоваться базовой станцией для передачи SI-сообщения, должно быть сообщением конфигурации TDD. Кроме того, мобильная станция может подтвердить это путем определения, включает ли полезная нагрузка DCI недействительный параметр.
Чтобы освободить мобильную станцию от затрат на обнаружение возможных сообщений SI в окнах SI, которые обычно не будут использоваться базовой станцией для передачи сообщения SI, дополнительная модификация третьего варианта осуществления задает определение "окна приема TDD-DCI". Окно приема TDD-DCI должно пониматься как ограничительное, где мобильная станция должна ожидать сообщение TDD-DCI только для точно конкретных подкадров и/или радиокадров. Другими словами, предпочтительно периодическая структура - возможно, но не обязательно смежных - подкадров и/или радиокадров задается как окно приема TDD-DCI (или эквивалентно структура), где сообщение TDD-DCI может передаваться базовой станцией, и/или требует только подлежать приему и детектированию мобильной станцией.
Такое окно может использоваться вообще с любым из описанных вариантов осуществления и независимо от используемого SI-RNTI. С иллюстративными целями последующее описывает ситуацию, где используется окно приема TDD-DCI, и SI-RNTI используется для скремблирования CRC для DCI. Как упомянуто выше, UE может знать, что детектированной DCI является DCI TDD, если DCI детектируется в окне SI, являющимся неиспользуемым для передач сообщения SI, как функцию сконфигурированных периодичностей SI. Такие неиспользуемые окна SI могут, следовательно, являться более или менее часто происходящими. Следовательно, может быть выгодным - для того, чтобы создавать больше возможностей передачи DCI TDD - задавать окно приема TDD-DCI. В случае, если подкадр является частью используемого окна SI, а также частью окна приема TDD-DCI, предпочтительно мобильная станция связывает успешно детектированную DCI с CRC, скремблированным посредством SI-RNTI, как являющуюся TDD-DCI и не используемую с целями указания передачи SI. Альтернативно, в такой ситуации мобильная станция интерпретирует такую DCI как TDD-DCI, если в DCI обнаружен недействительный параметр, и как DCI для указания передачи SI в противном случае.
Согласно модификации третьего варианта осуществления, CRC DCI скремблируют посредством SI-RNTI. В случае, если мобильная станция это детектирует в неиспользуемом окне SI и/или в подкадре, определяемом как часть окна приема TDD-DCI, мобильная станция узнает, что DCI предназначена для сообщения конфигурации TDD. В этой модификации DCI назначает физические ресурсы для передачи транспортного блока таким же образом, как например, в настоящий момент формат 1A DCI может использоваться для назначения физических ресурсов для транспортного блока. Упомянутый транспортный блок затем может представить сообщение MAC или RRC, которое содержит информацию и параметры о (ре)конфигурировании TDD, как например, индекс конфигурации TDD или дополнительные параметры, представляемые в общих чертах в последующих разделах настоящей заявки. Следовательно, вместо (или в дополнение) указателя TDD в сообщении DCI, транспортный блок, указанный сообщением DCI, содержит указатель TDD.
Дополнительные параметры
Вышеописанные первый, второй и третий варианты осуществления упоминают, что дополнительные параметры могут включаться в управляющую информацию нисходящей линии связи, используемую для динамического реконфигурирования UL/DL TDD, либо в виде отдельных параметров DCI, либо закодированными в недействительный параметр. Эти параметры были только кратко описаны и будут пояснены более подробно ниже.
Идентификатор целевой соты
Как уже очевидно из термина, этот идентификатор должен идентифицировать конкретную соту, к которой должна применяться конфигурация UL/DL TDD, передаваемая с DCI/CRC. Однако этот параметр должен быть некоторым, используемым в DCI, и может отличаться от такового, используемого для скремблирования CRC в DCI, как пояснено для второго варианта осуществления. Например, тогда как SC-RNTI, используемый для скремблирования, составляет 16 битов, идентификатор целевой соты, подлежащий включению в полезную нагрузку DCI, может иметь любой подходящий размер.
Могут иметься сценарии, в которых одна сота передает сообщение динамического реконфигурирования UL/DL TDD, хотя реконфигурирование UL/DL TDD должно применяться в другой соте. Это может иметь место для вышеуказанного сценария расширенной локальной зоны (eLA). Конкретно, если конфигурация TDD предназначена для SCell, то предпочтительно динамическое реконфигурирование TDD может передаваться в PCell.
В зависимости от числа различных сот в системе только несколько битов являются необходимыми для идентификатора целевой соты, чтобы различать разные соты.
Идентификатор целевой соты можно реализовывать различными путями. Например, могут использоваться определенные 3GPP в Версии 8 идентификационные данные физической соты (PCID, в документе TS 36.211; PhysCellID в документе TS 36.331), PCID, непосредственно указывающие на индекс. Альтернативно, нумерация, в настоящий момент используемая для добавления и модификации SCell (параметры SCellIndex, sCellToAddModList, SCellToAddMod-r10, см., например, документ TS 36.331, раздел 5.3.10.3b и другие разделы в нем), может использоваться непосредственно, или может быть установлено новое отношение между идентификатором целевой соты и целевой сотой.
Другой способ реализации идентификатора целевой соты относится к использованию 3-битового поля индикатора (компонентной) несущей (CIF). Поле CIF обычно предназначается для планирования кросс-несущих и идентифицирует несущую, к которой относится планирование. CIF таким образом может идентифицировать другую несущую, и тем самым позволяет мобильной станции определять, для какой соты (несущей) должна применяться конфигурация TDD, принятая с DCI. Это предпочтительно повторно использует нумерацию и отношения, подобные процедуре дополнения и модификации SCell (документ TS 36.331, раздел 5.3.10.3b и параметры SCelllndex, sCellToAddModList, SCellToAddMod-r10, описанные в других разделах в нем)
Еще одна необязательная возможность для идентификатора целевой соты подобна способу Скоординированной многоточечной связи (COMP) по Версии 10 3GPP. Вместо указания на идентификатор физической соты идентификатор целевой соты указывает на один или несколько ресурсов или конфигураций опорных символов, таких как порт CRS или ресурс CSI-RS, ресурс как определен в документе TS 36.211, разделах 6.10.1 и 6.10.5, и как определен в информационном элементе CSI-RS-Config (конфигурация РТС CSI) в документе TS 36.311.
Еще одной необязательной возможностью для идентификатора целевой соты является установление нового отношения между идентификатором целевой соты и целевой сотой.
Соответственно, мобильная станция определяет целевую соту из этого идентификатора целевой соты, включенного в DCI.
Параметр времени действия
Как пояснено в разделе уровня техники, по сравнению с другими способами реконфигурирования TDD на основе, например, MAC или RRC, реконфигурирование TDD с помощью DCI/CRC по настоящему изобретению должно иметь порядок 10 мс. Безусловно, указатель динамического реконфигурирования TDD может быть действительным только для одного радиокадра; однако, это потребует больших издержек, поскольку такое же сообщение реконфигурирования TDD будет необходимо передавать каждые 10 мс.
Согласно другому решению, DCI может включать в себя параметр времени действия, указывающий величину времени, которое реконфигурирование TDD должно быть действительным. Параметр времени действия может быть реализован различным образом, и может иметь различную длину в битах.
Использование параметра времени действия только в 1 бит позволяет различать два периода, в течение которых конфигурация TDD должна быть действительной; например, 10 мс и 40 мс, то есть, 1 радиокадр и 4 радиокадра. По-видимому, один радиокадр будет кратчайшим приемлемым действительным временем для такого динамического реконфигурирования UL/DL TDD. 4 радиокадра эквивалентны по величине интервалу MBSFN (одно-частотная вещательная сеть с многоадресной передачей). Безусловно, могут задаваться любые временные значения, отличны от 10 и 40 мс, такие как 100 мс или 200 мс. 200 мс, то есть, 20 радиокадров, эквивалентны временной шкале RRC для реконфигурирования TDD. Таким образом, разрыв между временными шкалами реконфигурирования TT с использованием уровня PHY (то есть, DCI/CRC) и уровня MAC/RRC может быть ликвидирован без потери возможности для быстрого реконфигурирования.
Использование более 1 бита, то есть, 2 битов или более, для параметра времени действия естественно позволяет более гибкое реконфигурирование TDD.
Таким образом, мобильная станция определяет величину времени, которое должна применяться динамическая конфигурация TDD, указанная упомянутым DCI/CRC.
Инструкция HARQ
Инструкция HARQ для предписания мобильной станции(ям) перезапускать или не перезапускать протокол HARQ по применении новой конфигурации TDD, относится к проблеме, обусловленной изменением конфигурации TDD, как будет пояснено в связи с Фиг.14.
С целями иллюстрации на Фиг.14 полагают, что конфигурация #3 UL/DL TDD применяется к радиокадру n, и конфигурация #5 UL/DL TDD применяется к следующему радиокадру n+1. Как изображено, подкадры 3, 4 изменяются от передачи по восходящей линии связи к передаче по нисходящей линии связи. Соответственно, количество процессов HARQ или временное соотношение для HARQ UL может изменяться при реконфигурировании подкадров UL/DL TDD, как можно видеть в документе TS 36.213 разделе 7 (с Таблицей 7-1), разделе 8, разделе 8.3 (с Таблицей 8.3-1), и разделе 10, включая подразделы, конкретно подраздел 10.2. В случае если процессов HARQ меньше, UE не может знать, какой процесс продолжается и какой более ранний PDCCH является опорным для периодического переключения Индикатора новых данных (NDI). Некоторые из результирующих проблем будут описаны более подробно ниже.
Процедура HARQ для PDSCH, принимаемого в подкадрах 7, 8 и 9 радиокадра n, показывает неоднозначности. Обратная связь ACK/NACK для предполагаемой передачи PDSCH в этих подкадрах 7, 8 и 9 более не может выполняться корректно, поскольку подкадры 3 и 4 из радиокадра n+1 более не позволяют посылку PUCCH с обратной связью ACK/NACK.
Параметр HARQ может конфигурировать поведение HARQ в мобильной станции по применении реконфигурирования UL/DL TDD.
Первая необязательная возможность состоит в том, что инструкция HARQ предписывает полный перезапуск протокола HARQ, так что все последующие передачи являются инициирующими новый транспортный блок. Неявно, буферы HARQ сбрасываются, то есть, удаляются. Преимущество состоит в том, что разрушение буферов HARQ можно избежать.
Эта первая необязательная возможность может указываться посредством следующей процедуры. NDI для всех процессов HARQ восходящей линии связи устанавливается в значение 0. «Мягкие» (программные) буферы для всех процессов HARQ нисходящей линии связи сбрасываются. Для каждого процесса HARQ нисходящей линии связи следующая принимаемая передача для транспортного блока считается самой первой передачей.
Вторая необязательная возможность для параметра инструкции HARQ состоит в том, что протокол HARQ не имеет перезапуска. Таким образом, буферы HARQ сохраняются для предоставления возможности продолжения протокола HARQ по всему реконфигурированию UL/DL TDD с тем, чтобы оптимизацию осуществлять по всей полосе пропускания. Это выгодно, если большинство процессов HARQ по старой конфигурации TDD завершились успешно во время реконфигурирования TDD.
Следовательно, между первой и второй необязательной возможностью существует компромисс, и базовая станция может устанавливать инструкцию HARQ в одно из двух значений. Поле инструкции HARQ в 1-бит является достаточным в этом предпочтительном случае.
Следовательно, мобильная станция определяет из этого параметра, каково поведение относительно процессов HARQ.
Поле заполнения
Поле заполнения может вставляться в DCI с предварительно определенным значением, известным мобильной станции, а также базовой станции, и для того, чтобы мобильная станция могла определить, принимает ли поле заполнения значение предварительно определенного. Если DCI содержит поле заполнения с предварительно определенным значением, мобильная станция может определить, что принятая DCI действительно транспортирует реконфигурирование UL/DL TDD. Следовательно, поле заполнения позволяет мобильной станции вторично определять, что DCI транспортирует конфигурацию UL/DL TDD; не только посредством RNTI TDD (первый вариант осуществления), SC-RNTI (второй вариант осуществления), или недействительного параметра в DCI (третий вариант осуществления).
Поле заполнения включается предпочтительно в DCI в Формате 3GPP, таком как Формат 1C, чтобы использовать остающиеся биты DCI, которые могут не использоваться для какого-либо из остальных параметров. Поле заполнения может таким образом иметь длину 1-32 бита. При использовании DCI конкретного размера, и после принятия решения и установки конкретных добавочных параметров, подлежащих включению в DCI, часто будут иметься оставшиеся биты, которые не иначе будут использоваться. Следовательно, для использования этих битов также, используется поле заполнения.
Термин "виртуальный CRC" может также использоваться специалистом в данной области техники, чтобы описать такое поле заполнения с помощью определенных битовых значений.
Таким образом, мобильная станция может сравнивать значение поля заполнения с предварительно определенным значением, чтобы гарантировать, что DCI, переносящая упомянутое поле заполнения, действительно предназначена для переноса динамического реконфигурирования TDD.
Отчет о состоянии буфера (BSR)
Инструкции BSR от мобильной станции на базовую станцию используются, чтобы содействовать распределению ресурсов восходящей линии связи. Обычно, чем больше заполнен буфер на мобильной станции, тем больше ресурсов или более часто ресурсы должны назначаться этой мобильной станции для передачи по восходящей линии связи. Подробности можно найти в материале The UMTS Long Term Evolution - From Theory to Practice, под редакцией Stefanie Sesia, Issam Toufik, Matthew Baker, Главе 4.4.2.2.
Формирование отчетов BSR является функцией MAC, которая подразумевает, что соответствующие транспортные блоки на физическом уровне подвергаются процедуре HARQ с возможными повторными передачами. BSR может запускаться при нескольких обстоятельствах, среди которых истечение таймера 'periodicBSR'. Подробности можно найти в материале The UMTS Long Term Evolution - From Theory to Practice, под редакцией Stefanie Sesia, Issam Toufik, Matthew Baker, Главе 4.4.2.2, включенной путем ссылки.
Как упомянуто, по применении реконфигурирования TDD может быть некоторая неясность или путаница между мобильной станцией и базовой станцией относительно состояния протокола HARQ. В случае передачи BSR, следовательно, может быть неправильное понимание, если BSR является частью (повторной) передачи по восходящей линии связи после реконфигурирования TDD. Следовательно, мобильная станция может принимать параметр, чтобы узнать, должна ли процедура BSR перезапускаться, каковое может подразумевать одно или более из следующего:
- отмену или повторный запуск ожидающих (повторных) передач BSR
- сброс/повторный пуск таймера 'periodicBSR'
- сброс/повторный пуск таймера 'retxBSR'
Процедура запроса планирования (SR) и канала произвольного доступа (RACH)
В случае если мобильная станция намеревается передавать BSR, но отсутствуют или недостаточны ресурсы восходящей линии связи для передачи BSR, мобильная станция может передавать SR на базовую станцию на PUCCH или с использованием процедуры RACH. Подробности можно найти в материале The UMTS Long Term Evolution - From Theory to Practice, под редакцией Stefanie Sesia, Issam Toufik, Matthew Baker, Главе 4.4.2.2, включенной в документ путем ссылки. Поскольку на временную привязку, когда PUCCH может передаваться для принимаемой передачи PDSCH, обычно влияет реконфигурирование TDD, как показано на Фиг.14, и процедура RACH может выйти за радиокадр, то есть, находится под влиянием реконфигурирования TDD из-за изменения положения и количества доступных возможностей передачи DL и UL для завершения всей процедуры RACH, может быть более безопасным по отношению к ошибкам сообщать мобильной станции, что ей следует осуществить отмену или повторный пуск процедуры SR и/или RACH снова после применения новой конфигурации TDD.
Формирование отчета о запасе мощности (PHR)
Подобно BSR, PHR используется для управления мощностью передачи по восходящей линии связи для мобильной станции. Базовая станция может использовать PHR, чтобы определять, сколько еще полосы частот во восходящей линии связи на один подкадр способна использовать мобильная станция. Подробности можно найти в материале The UMTS Long Term Evolution - From Theory to Practice, под редакцией Stefanie Sesia, Issam Toufik, Matthew Baker, Главе 18.3.3, включенной в документ путем ссылки.
Поскольку имеющаяся мощность передачи по восходящей линии связи на один подкадр должно распределяться по всей назначенной полосе частот восходящей линии связи, это является эквивалентным отчету о запасе мощности. PHR инициируется, например, когда обнаружено значительное изменение расчетной потери в тракте передачи с момента последней PHR, или когда истекло заданное в конфигурации время с момента предыдущей PHR ('таймер запрета PHR'), или когда мобильной станцией было реализовано большее количество команд TPC, чем задано в конфигурации.
Подобно BSR, PHR передается в виде информации MAC в назначенных ресурсах восходящей линии связи, и, следовательно, на процедуру может влиять реконфигурирование TDD. Следовательно, добавочный параметр может сообщить мобильной станции, что по реконфигурировании TDD следует сделать одно или несколько из следующего:
- отменить ожидающий отчет PHR
- инициировать новый отчет PHR
- сбросить/повторно пустить таймер запрета PHR
- сбросить счетчик команд TPC или установить его в заданное значение
Аппаратная и программная реализация изобретения
Еще один вариант осуществления изобретения относится к реализации вышеописанных различных вариантов осуществления с использованием аппаратного и программного обеспечения. В этой связи изобретение обеспечивает пользовательское оборудование (мобильный терминал) и eNodeB (базовую станцию). Пользовательское оборудование приспособлено для выполнения способов, описанных в документе.
Дополнительно признано, что различные варианты осуществления изобретения могут реализовываться или выполняться с использованием вычислительных устройств (процессоров). Вычислительное устройство или процессор может, например, являться универсальными процессорами, цифровыми процессорами сигналов (DSP), специализированными интегральными схемами (ASIC), программируемыми вентильными матрицами (FPGA) или другими программируемыми логическими устройствами, и т.д. Различные исполнения изобретения также могут выполняться или осуществляться комбинацией этих устройств.
Кроме того, различные исполнения изобретения также могут бы реализованы посредством программных модулей, которые исполняются процессором, или непосредственно аппаратными средствами. К тому же является возможной комбинация программных модулей и аппаратной реализации. Программные модули могут сохраняться на читаемом компьютером носителе любого вида, например, оперативном запоминающем устройстве (RAM), стираемом программируемом ПЗУ (EPROM), электрически-стираемом программируемом ПЗУ (EEPROM), флэш-памяти, регистрах, накопителях на жестких дисках, ПЗУ на компакт-диске (CD-ROM), цифровом многофункциональном диске (DVD) и т.д.
Следует дополнительно отметить, что отдельные признаки различных вариантов осуществления изобретения могут индивидуально или в произвольной комбинации являться объектом другого изобретения.
Специалист в данной области техники должен понимать, что могут делаться многочисленные изменения и/или модификации по отношению к данному изобретению, как показано в конкретных вариантах осуществления, без выхода за рамки сущности и объема изобретения, как описано в общих чертах. Настоящие варианты осуществления, следовательно, должны рассматриваться во всех отношениях иллюстративными и неограничительными.
Изобретение относится к вычислительной технике. Технический результат заключается в обеспечении улучшенного указания конфигурации дуплексной связи с временным разделением. Мобильная станция для обработки одной из множества конфигураций дуплексной связи содержит приемник, который при функционировании принимает блок системной информации (SIB), который включает в себя конфигурацию дуплексной связи с временным разделением (TDD) по умолчанию, схему обработки, соединенную с приемником, которая при функционировании определяет конфигурацию TDD из множества конфигураций TDD, включающего в себя конфигурацию TDD по умолчанию, на основе управляющей информации нисходящей линии связи, определяет по меньшей мере одну обслуживающую соту, к которой должна применяться упомянутая определенная конфигурация TDD, применяет упомянутую определенную конфигурацию TDD. 2 н. и 7 з.п. ф-лы, 4 табл., 14 ил.
1. Мобильная станция для обработки одной из множества конфигураций дуплексной связи, функционирующая в одной из множества конфигураций дуплексной связи с временным разделением (TDD) в системе связи, причем мобильная станция содержит:
приемник, который при функционировании принимает блок системной информации (SIB), который включает в себя конфигурацию TDD по умолчанию, задающую подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или нескольких радиокадрах, причем каждый радиокадр включает в себя несколько подкадров, и принимает управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок для управляющей информации нисходящей линии связи, при этом код обнаружения ошибок скремблирован идентификатором, связанным с данной мобильной станцией,
схему обработки, соединенную с приемником, которая при функционировании:
в ответ на успешное декодирование управляющей информации нисходящей линии связи с кодом обнаружения ошибок, скремблированным упомянутым идентификатором, определяет конфигурацию TDD из множества конфигураций TDD, включающего в себя конфигурацию TDD по умолчанию, на основе управляющей информации нисходящей линии связи,
определяет по меньшей мере одну обслуживающую соту, к которой должна применяться упомянутая определенная конфигурация TDD,
применяет упомянутую определенную конфигурацию TDD к радиокадру n+1 в упомянутой по меньшей мере одной обслуживающей соте, где n соответствует радиокадру, в котором управляющая информация нисходящей линии связи и код обнаружения ошибок принимаются мобильной станцией, и
в ответ на истечение упомянутой определенной конфигурации TDD, применяет конфигурацию TDD по умолчанию к радиокадру n+1+x, где x – положительное целое число.
2. Мобильная станция по п.1, в которой x равно 1, 2 или 4.
3. Мобильная станция по п.1, в которой система связи является системой связи LTE, и управляющая информация нисходящей линии связи является управляющей информацией нисходящей линии связи в формате 1C.
4. Мобильная станция по п.1, в которой управляющая информация нисходящей линии связи указывает по меньшей мере одно из следующего:
конфигурации TDD, которая должна применяться к упомянутой по меньшей мере одной обслуживающей соте, в поле конфигурации TDD,
инструкции HARQ, включающей в себя инструкцию, чтобы по применении упомянутой определенной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для обслуживающей соты, к которой упомянутая определенная конфигурация TDD применяется,
параметра времени действия для упомянутой определенной конфигурации TDD, указывающего величину времени, в течение которого упомянутая определенная конфигурация TDD должна применяться,
битового значения поля заполнения, которое является или не является тождественным предварительно определенному битовому значению,
инструкции процедуры отчета о состоянии буфера, предписывающей отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении упомянутой определенной конфигурации TDD,
инструкции процедуры запроса планирования, предписывающей отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении упомянутой определенной конфигурации TDD,
инструкции процедуры произвольного доступа к каналу, предписывающей отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении упомянутой определенной конфигурации TDD, и
инструкции формирования отчета о запасе мощности, предписывающей отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении упомянутой определенной конфигурации TDD.
5. Способ для указания одной из множества конфигураций дуплексной связи, исполняемый мобильной станцией, функционирующей в одной из множества конфигураций дуплексной связи с временным разделением (TDD) в системе связи, причем способ содержит этапы, на которых:
принимают блок системной информации (SIB), который включает в себя конфигурацию TDD по умолчанию, задающую подкадры восходящей линии связи, нисходящей линии связи и специальные подкадры в одном или нескольких радиокадрах, причем каждый радиокадр включает в себя несколько подкадров,
принимают управляющую информацию нисходящей линии связи и соответствующий код обнаружения ошибок для управляющей информации нисходящей линии связи, при этом код обнаружения ошибок скремблирован идентификатором, связанным с данной мобильной станцией,
в ответ на успешное декодирование управляющей информации нисходящей линии связи с кодом обнаружения ошибок, скремблированным упомянутым идентификатором, определяют конфигурацию TDD из множества конфигураций TDD, включающего в себя конфигурацию TDD по умолчанию, на основе управляющей информации нисходящей линии связи,
определяют по меньшей мере одну обслуживающую соту, к которой должна применяться упомянутая определенная конфигурация TDD,
применяют упомянутую определенную конфигурацию TDD к радиокадру n+1 в упомянутой по меньшей мере одной обслуживающей соте, где n соответствует радиокадру, в котором управляющая информация нисходящей линии связи и код обнаружения ошибок принимаются мобильной станцией, и
в ответ на истечение упомянутой определенной конфигурации TDD, применяют конфигурацию TDD по умолчанию к радиокадру n+1+x, где x – положительное целое число.
6. Способ по п.5, в котором x равно 1, 2 или 4.
7. Способ по п.5, в котором система связи является системой связи LTE, и управляющая информация нисходящей линии связи является управляющей информацией нисходящей линии связи в формате 1C.
8. Способ по п.5, в котором управляющая информация нисходящей линии связи включает в себя недействительный параметр с одним из множества недействительных значений, и одна из множества конфигураций TDD указывается посредством одного или нескольких из недействительных значений, причем одно или несколько из недействительных значений указывают по меньшей мере одно из следующего:
указанной конфигурации TDD,
инструкции HARQ, чтобы по применении указанной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для обслуживающей соты, к которой указанная конфигурация TDD применяется,
параметра времени действия, указывающего величину времени, в течение которого указанная конфигурация TDD должна применяться,
инструкции процедуры отчета о состоянии буфера, предписывающей отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении указанной конфигурации TDD,
инструкции процедуры запроса планирования, предписывающей отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении указанной конфигурации TDD,
инструкции процедуры произвольного доступа к каналу, предписывающей отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении указанной конфигурации TDD, и
инструкции формирования отчета о запасе мощности, предписывающей отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении указанной конфигурации TDD.
9. Способ по п.5, в котором управляющая информация нисходящей линии связи указывает по меньшей мере одно из следующего:
конфигурации TDD, которая должна применяться к упомянутой по меньшей мере одной обслуживающей соте, в поле конфигурации TDD,
инструкции HARQ, включающей в себя инструкцию, чтобы по применении упомянутой определенной конфигурации TDD перезапускать или не перезапускать протокол HARQ мобильной станции для обслуживающей соты, к которой упомянутая определенная конфигурация TDD применяется,
параметра времени действия для упомянутой определенной конфигурации TDD, указывающего величину времени, в течение которого упомянутая определенная конфигурация TDD должна применяться,
битового значения поля заполнения, которое является или не является тождественным предварительно определенному битовому значению,
инструкции процедуры отчета о состоянии буфера, предписывающей отменить текущую процедуру отчета о состоянии буфера или инициировать новую процедуру отчета о состоянии буфера, по применении упомянутой определенной конфигурации TDD,
инструкции процедуры запроса планирования, предписывающей отменить текущую процедуру запроса планирования или инициировать новую процедуру запроса планирования, по применении упомянутой определенной конфигурации TDD,
инструкции процедуры произвольного доступа к каналу, предписывающей отменить текущую процедуру произвольного доступа к каналу или инициировать новую процедуру произвольного доступа к каналу, по применении упомянутой определенной конфигурации TDD, и
инструкции формирования отчета о запасе мощности, предписывающей отменить текущее формирование отчета о запасе мощности или инициировать новое формирование отчета о запасе мощности, по применении упомянутой определенной конфигурации TDD.
| Изложница с суживающимся книзу сечением и с вертикально перемещающимся днищем | 1924 |
|
SU2012A1 |
| Изложница с суживающимся книзу сечением и с вертикально перемещающимся днищем | 1924 |
|
SU2012A1 |
| Способ приготовления лака | 1924 |
|
SU2011A1 |
| Приспособление для суммирования отрезков прямых линий | 1923 |
|
SU2010A1 |
| СПОСОБ И СИСТЕМА ДЛЯ ОБЕСПЕЧЕНИЯ ИНФОРМАЦИИ УПРАВЛЕНИЯ ДЛЯ ПОДДЕРЖКИ ВЫСОКОСКОРОСТНОЙ НИСХОДЯЩЕЙ И ВОСХОДЯЩЕЙ ЛИНИЙ СВЯЗИ | 2006 |
|
RU2384983C2 |
