СПОСОБ И УСТРОЙСТВО ДЛЯ ОТПРАВКИ И ПРИЕМА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ НИСХОДЯЩЕЙ ЛИНИИ СВЯЗИ
METHOD AND DEVICE FOR SENDING AND RECEIVING DOWNLINK CONTROL INFORMATION

РОДСТВЕННЫЕ ЗАЯВКИ
По настоящей заявке испрашивается приоритет по предварительной заявке США № 61/753,086, поданной 16 января 2013 года, содержание которой является включенным в настоящую заявку во всей своей полноте посредством ссылки.
ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Настоящая заявка, в целом, относится к управляющей информации нисходящей линии связи в беспроводной системе связи и, в частности, относится к базовой станции и пользовательскому оборудованию, выполненным с возможностью, соответственно, отправлять и принимать подобную управляющую информацию нисходящей линии связи.
УРОВЕНЬ ТЕХНИКИ
Агрегирование несущих представляет собой функциональную возможность, при помощи которой множество, так называемых, компонентных несущих (также называемых «сотами») передаются параллельным образом к и от одного и того же пользовательского оборудования (UE). Осуществление агрегирования несущих в более крупную одну общую несущую для конкретного UE задействует больше диапазонов частот для UE и, вследствие этого, обеспечивает возможность UE достигать более высокой пиковой скорости по сравнению со скоростью, обеспеченной при помощи любой отдельной компонентной несущей. В системах долгосрочного развития (LTE), например, отдельные компонентные несущие, каждая из них, содержат обратно-совместимую несущую LTE (в пределах от 1,4 МГц до 20 МГц по диапазону частот), что подразумевает то, что осуществление агрегирования этих очень больших частей диапазона частот позволяет UE использовать диапазон частот отдельной несущей LTE больший, чем 20 МГц. Конечно, не требуется, чтобы агрегированные компонентные несущие являлись смежными в частотной области. Это обеспечивает возможность системным операторам, которые имеют небольшие (т.е. фрагментарные) распределения диапазона частот (обычно от 10 МГц и ниже), объединять эти небольшие распределения диапазона частот для конкретного UE.
UE, имеющее возможность агрегирования несущих, имеет одну первичную компонентную несущую (т.е. одну первичную соту) в каждом из нисходящего (DL) и восходящего (UL) направлений. Будучи агрегированными с первичными компонентными несущими, UE может иметь одну или более вторичных компонентных несущих (т.е. одну или более вторичных сот) в каждом из DL и UL. Однако не требуется, чтобы количество вторичных сот являлось одинаковым в каждом направлении так, чтобы являться симметричными. В некоторых версиях LTE, например, UE имеет одну первичную соту в каждом направлении, но ассиметричным образом имеет вторичную соту только в DL, но не в UL. В терминах компонентных несущих это означает, что UE имеет 2 несущих DL и одну несущую UL.
Как правило, сеть передает управляющую информацию нисходящей линии связи (DCI) на UE при помощи осуществления передачи сообщения DCI по нисходящему управляющему каналу на каждой из сот нисходящей линии связи UE, где DCI, переданная на соте нисходящей линии связи, относится к этой соте нисходящей линии связи и к связанной соте восходящей линии связи. В системах LTE, например, сеть передает DCI на UE при помощи осуществления передачи сообщения DCI по физическому нисходящему управляющему каналу (PDCCH) на каждой соте нисходящей линии связи (где один PDCCH переносит одно сообщение DCI и является специальным для конкретного UE). Принимая во внимание вышесказанное, если используется планирование для нескольких несущих, сеть может передавать на UE, на одной соте нисходящей линии связи, DCI, которая относится к множеству сот.
UE должно контролировать, передала ли сеть нисходящий управляющий канал, предназначенный специально для UE. Для того чтобы уменьшить сложность подобного контролирования, сеть подчиняет назначение нисходящих управляющих каналов ресурсам передачи конкретной структуре, основанной на, так называемых, элементах управляющего канала (множестве CCE). CCE представляет собой набор определенного количества ресурсов передачи, пригодных для передачи управляющих каналов (например, набор из 36 элементов ресурсов в LTE). Количество CCE, которым сеть назначает нисходящий управляющий канал (называемое «уровнем агрегирования») является переменным. Принимая во внимание вышесказанное, возможные уровни агрегирования являются ограниченными. В системе LTE, например, возможные уровни агрегирования являются ограниченными 1, 2, 4 или 8, соответствуя агрегированию 1, 2, 4 или 8 CCE для данного PDCCH. Возможные пути для того, чтобы агрегировать смежные CCE на любом данном уровне агрегирования, также являются ограниченными. Например, со множеством CCE, последовательно проиндексированных (например, как множество CCE 0-39), агрегирования смежных CCE могут начинаться только на конкретных индексах CCE; говоря другими словами, первый индекс CCE для агрегирования смежных CCE является ограниченным. Эти ограничения означают то, что существуют только конкретные CCE или агрегирования CCE (называемые в настоящем описании кандидатами управляющего канала), которым сеть имеет возможность назначать нисходящие управляющие каналы.
Для того чтобы не допустить необходимости для любого данного UE контролировать всех кандидатов управляющего канала для канала, предназначенного для UE, дополнительные ограничения устанавливают то, что UE требуется контролировать только определенный набор кандидатов управляющего канала. Набор кандидатов управляющего канала, который конкретное UE должно контролировать, определяется на уровне агрегирования при помощи основы уровня агрегирования в терминах, так называемых, пространств поиска. Пространство поиска представляет собой группу кандидатов управляющего канала на данном уровне агрегирования. Каждое UE имеет, так называемое, характерное для UE пространство поиска (USS) для каждого уровня агрегирования, где USS, как используется в настоящем описании, представляет собой пространство поиска, определяющее часть кандидатов управляющего канала на конкретном уровне агрегирования, которую конкретное UE должно контролировать. Все множество UE также контролируют одно или более общих пространств поиска (множество CSS) в дополнение к их характерным для UE пространствам поиска. CSS, как используется в настоящем описании, представляет собой пространство поиска, определяющее часть кандидатов управляющего канала на конкретном уровне агрегирования, которую все множество UE должны контролировать. Причем CSS может перекрываться с USS, означая то, что кандидаты в пределах набора кандидатов, который конкретное UE должно контролировать, не должны являться уникальными.
UE контролирует кандидата управляющего канала на предмет того, назначен ли нисходящий управляющий канал, предназначенный для UE, этому кандидату, при помощи осуществления попытки декодировать этого кандидата управляющего канала. Если попытка декодирования является успешной, то UE объявляет то, что управляющий канал, предназначенный для UE, назначен декодированному кандидату, и что допустимое сообщение DCI было передано по управляющему каналу. В этом случае UE продолжает обрабатывать допустимое сообщение DCI, переданное по каналу, при помощи интерпретирования битовых полей сообщения DCI. Однако этот процесс контролирования осложняется тем фактом, что сообщение DCI может являться отформатированным в соответствии с различными возможными, так называемыми, форматами DCI. Формат DCI соответствует определенному размеру полезной нагрузки и использованию номинального сообщения DCI. Системы LTE, например, определяют различные форматы DCI в соответствии с разделом 5.3.3.1.1 в TS 36.212 V10.4.0 совместно с разделом 7.2.1 в TS 36.213 V11.1.0. Поскольку конкретный формат DCI, использующийся нисходящим управляющим каналом в любое данное время, является неизвестным для UE априори, то UE должно вслепую обнаруживать формат DCI. Это означает то, что UE должно попытаться декодировать кандидата управляющего канала в соответствии с различными возможными форматами DCI. Как правило, UE идентифицирует формат сообщения DCI, переданного по управляющему каналу, по размеру полезной нагрузки этого сообщения DCI на основе предположения о том, что различные форматы DCI диктуют различные размеры полезной нагрузки сообщения DCI. Документ US 2012/327917 A1 раскрывает способ и устройство, которые предоставляют возможность оконечному устройству принимать управляющий канал в беспроводной системе связи, которая использует несколько несущих.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Проблемы возникают, если первичная сота передает пользовательскому оборудованию (UE) сообщение с управляющей информацией нисходящей линии связи (DCI), которое имеет размер полезной нагрузки, который обычно определяется как допустимый, в обоих общем пространстве поиска (CSS) и характерном для UE пространстве поиска (USS). Если сообщение DCI также имеет одинаковый первый индекс элемента управляющего канала (CCE), как это определено в CSS и USS (т.е. CSS и USS перекрываются), то UE будет воспринимать сообщение DCI как допустимое, вне зависимости от того, в которое из CSS или USS было в действительности передано сообщение DCI. Поскольку битовые поля сообщения DCI определяются различным образом, в зависимости от того, в которое из CSS или USS было передано сообщение, существует неопределенность относительно того, каким образом правильно интерпретировать битовые поля сообщения, после того как сообщение объявлено допустимым.
Известные подходы к тому, чтобы разрешать вопросы, связанные с этой неопределенностью, заключаются в том, чтобы сконфигурировать UE таким образом, чтобы оно всегда предполагало, что подобное сообщение DCI передавалось первичной сотой в CSS. Эти подходы, однако, оказываются несовершенными при определенных обстоятельствах. Например, подходы существенно уменьшают покрытие вторичной соты по сравнению с имеющимся у первичной соты. Один или более вариантов осуществления настоящего описания доказывают преимущества перед известными подходами в том, что они используют управление радио ресурсами (RRC) для того, чтобы конфигурировать предположение со стороны UE о том, в которое из CSS или USS подобное сообщение DCI передается первичной сотой.
В частности, варианты осуществления настоящего описания включают в себя UE, выполненное с возможностью принимать DCI, переданную на UE первичной сотой в беспроводной системе связи. UE характеризуется тем, что содержит одну или более обрабатывающих схем, которые выполнены с возможностью предполагать, что сообщение DCI, которое имеет общий размер полезной нагрузки и одинаковый первый индекс элемента управляющего канала, но различные битовые поля, в общем пространстве поиска и в характерном для UE пространстве поиска, передается первичной сотой в общее пространство поиска или характерное для UE пространство поиска на основе конфигурирования UE при помощи RRC. В одном или более вариантах осуществления это означает то, что обрабатывающие схемы выполнены с возможностью предполагать, что сообщение DCI передается первичной сотой в общее пространство поиска или характерное для UE пространство поиска на основе того, имеет ли параметр в принятом сообщении RRC первое значение или второе значение, соответственно.
Кроме того, по меньшей мере, в некоторых вариантах осуществления, одна или более обрабатывающих схем выполнены с возможностью предполагать по умолчанию, что сообщение DCI передается первичной сотой в общее пространство поиска.
В одном варианте, сообщение DCI в некоторых вариантах осуществления имеет одинаковый формат DCI в пространствах поиска. Альтернативным образом, в других вариантах осуществления сообщение DCI имеет различные форматы DCI в пространствах поиска.
Другие варианты осуществления настоящего описания включают в себя базовую станцию, выполненную с возможностью обеспечивать первичную соту в беспроводной системе связи, которая отправляет DCI на UE. Базовая станция характеризуется тем, что содержит одну или более обрабатывающих схем, которые конфигурируют UE при помощи RRC таким образом, чтобы оно предполагало то, что сообщение DCI, которое имеет общий размер полезной нагрузки и одинаковый первый индекс элемента управляющего канала, но различные битовые поля, в общем пространстве поиска и характерном для UE пространстве поиска, передается первичной сотой в общее пространство поиска или характерное для UE пространство поиска. В одном или более вариантах осуществления, одна или более обрабатывающих схем являются выполненными с возможностью отправлять сообщение RRC на UE с первым значением или вторым значением для параметра в сообщении RRC для того, чтобы сконфигурировать UE таким образом, чтобы оно предполагало то, что сообщение DCI передается первичной сотой в общее пространство поиска или характерное для UE пространство поиска, соответственно.
В некоторых вариантах осуществления одна или более обрабатывающих схем базовой станции конфигурирует UE при помощи RRC таким образом, чтобы оно предполагало то, что сообщение DCI передается первичной сотой в характерное для UE пространство поиска, вместо предположения по умолчанию того, что сообщение DCI передается первичной сотой в общее пространство поиска.
В свою очередь, сообщение DCI в некоторых вариантах осуществления имеет одинаковый формат DCI в пространствах поиска. Альтернативным образом, в других вариантах осуществления, сообщение DCI имеет различные форматы DCI в пространствах поиска.
В одном или более вариантах осуществления одна или более обрабатывающих схем базовой станции являются выполненными с возможностью идентифицировать сообщение DCI, которое должно отправляться UE, как имеющее общий размер полезной нагрузки в пространствах поиска, несмотря на то, что определение битовых полей в сообщении DCI является различным в пространствах поиска. В ответ на эту идентификацию, одна или более обрабатывающих схем конфигурируют UE при помощи RRC таким образом, чтобы оно предполагало то, что сообщение DCI передается в характерное для UE пространство поиска. В ответ на это конфигурирование, одна или более обрабатывающих схем планируют то, что сообщение DCI должно отправляться на UE.
Другие варианты осуществления настоящего описания включают в себя соответствующие способы, выполняющиеся UE и базовой станцией.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Фигура 1 представляет собой функциональную схему беспроводной системы связи, которая включает в себя пользовательское оборудование (UE) и базовую станцию в соответствии с одним или более вариантами осуществления.
Фигура 2 представляет собой логическую блок-схему способа, реализованного пользовательским оборудованием в соответствии с одним или более вариантами осуществления.
Фигура 3 представляет собой логическую блок-схему способа, реализованного базовой станцией в соответствии с одним или более вариантами осуществления.
Фигура 4 представляет собой логическую блок-схему обработки, выполненной базовой станцией для того, чтобы выполнить способ на Фигуре 3.
Фигура 5 представляет собой логическую блок-схему способа в соответствии с одним или более вариантами осуществления.
Фигура 6 представляет собой логическую блок-схему способа, реализованного базовой станцией в соответствии с еще другими вариантами осуществления.
Фигура 7 представляет собой логическую блок-схему способа, реализованного базовой станцией в соответствии с еще другими вариантами осуществления.
Фигура 8 представляет собой логическую блок-схему способа, реализованного базовой станцией в соответствии с другим вариантом осуществления.
Фигура 9 представляет собой функциональную схему пользовательского оборудования в соответствии с одним или более вариантами осуществления.
Фигура 10 представляет собой функциональную схему базовой станции в соответствии с одним или более вариантами осуществления.
ПОДРОБНОЕ ОПИСАНИЕ
Фигура 1 иллюстрирует беспроводную систему 10 связи в соответствии с одним или более вариантами осуществления. Как это показано, опорная сеть (CN) 12 коммуникационным образом соединяет сеть (RAN) 14 радио доступа с одной или более внешними сетями, такими как коммутируемая телефонная сеть общего доступа (PSTN) 16, сеть пакетной передачи данных (PDN) 18, такая как Интернет, или подобные им. RAN 14 в некоторых вариантах осуществления включает в себя различные размещения сети радиодоступа, такие как размещения макро точек доступа, размещения пико точек доступа и т.д. В одном варианте RAN 14 включает в себя одну или более базовых станций (также называемых в настоящем описании как eNodeB или eNB) для беспроводного взаимодействия с одним или более устройствами беспроводной связи (также называемыми в настоящем описании как пользовательское устройство, UE).
В частности, базовая станция 20 в настоящем описании передает компонентную несущую 22 нисходящей линии связи и связанную компонентную несущую восходящей линии связи (не показана), которая обеспечивает первичную соту одному или более обслуживаемых UE, включая сюда UE 24. Первичная сота 26 (через посредство базовой станции 20) передает управляющую информацию нисходящей линии связи (DCI) обслуживаемым UE при помощи осуществления передачи сообщений DCI по нисходящим управляющим каналам на первичной соте 26. Конкретный UE 24 контролирует, передала ли первичная сота 26 нисходящий управляющий канал, предназначенный специально для UE 24, при помощи контролирования одного или более общих пространств поиска (множество CSS) и характерных для UE пространств поиска (множество USS).
При некоторых обстоятельствах первичная сота 26 передает на UE 24 сообщение DCI, которое имеет размер полезной нагрузки, который обычно определяется как допустимый в обоих CSS и USS. Это означает то, что в том случае, когда сообщение DCI передается в USS, размер полезной нагрузки сообщения DCI также является допустимым сообщением DCI в CSS. Верно и обратное - в том случае, когда сообщение DCI передается в CSS, размер полезной нагрузки сообщения DCI также является допустимым сообщением DCI в USS. Этот размер полезной нагрузки соответственно называется в настоящем описании как общий размер полезной нагрузки, поскольку размер полезной нагрузки является общим в обоих CSS и USS. Сообщение DCI также имеет одинаковый первый индекс элемента управляющего канала (CCE), как определенного в CSS и USS (т.е. CSS и USS перекрываются). UE 24 является выполненным с возможностью воспринимать подобное сообщение DCI как допустимое, вне зависимости от того, в которое из CSS или USS сообщение DCI в действительности передавалось. UE 24 так делает, несмотря на то, что битовые поля сообщения DCI определяются различным образом в зависимости от того, в которое из CSS или USS передавалось сообщение. Для того чтобы разрешить вопрос неопределенности, которая в противном случае будет существовать по поводу того, как правильно интерпретировать битовые поля сообщения, один или более вариантов осуществления настоящего описания преимущественно используют управление радио ресурсами (RRC) для того, чтобы конфигурировать UE 24 таким образом, чтобы оно делало предположение о том, в которое из CSS или USS передается сообщение DCI, при помощи первичной соты 26. Говоря другими словами, UE 24 может конфигурироваться при помощи RRC таким образом, чтобы оно предполагало то, что принятое сообщение DCI передавалось или в общее, или в характерное для UE пространство поиска.
Фигура 2 иллюстрирует способ 100, выполненный UE 24 в этом отношении. Способ 100 реализуется UE 24 для осуществления приема DCI, переданной на UE 24 первичной сотой 26 в беспроводной системе 10 связи. Способ содержит UE 24, предполагающее то, что сообщение DCI, которое имеет общий размер полезной нагрузки и одинаковый первый индекс CCE, но различные битовые поля в общем пространстве поиска и характерном для UE пространстве поиска, передается первичной сотой 26 в общее пространство поиска или характерное для UE пространство поиска на основе конфигурирования UE 24 при помощи RRC (Блок 110). Говоря другими словами, UE 24 будет предполагать, что сообщение DCI, которое оно принимает, является связанным со характерным для UE пространством поиска или общим пространством поиска на основе конфигурирования RRC.
Это косвенным образом означает, конечно, что UE 24 принимает сообщение RRC (Блок 105), и что UE 24 основывает вышеупомянутое предположение на значении параметра в этом сообщении RRC. Говоря другими словами, UE предполагает, что сообщение DCI передается первичной сотой в общее пространство поиска или характерное для UE пространство поиска на основе того, имеет ли параметр в принятом сообщении RRC первое значение или второе значение, соответственно.
По меньшей мере, в некоторых вариантах осуществления UE 24 предполагает по умолчанию то, что сообщение DCI передается первичной сотой 26 в общее пространство поиска. Говоря другими словами, значение по умолчанию для конфигурирования RRC представляет собой то, что UE 24 предполагает то, что сообщения DCI, которые оно принимает, относятся к общему пространству поиска.
Следует отметить, что, по меньшей мере, в некоторых вариантах осуществления описанное сообщение DCI имеет одинаковый тип формата DCI в общем пространстве поиска и характерном для UE пространстве поиска. Говоря другими словами, сообщение DCI имеет размер полезной нагрузки, который обычно определяется в общем пространстве поиска и в характерном для UE пространстве поиска, как являющийся допустимым для одинакового типа форматов DCI. Несмотря на то, что сообщение DCI имеет одинаковый тип форматов DCI, оно, однако, содержит различные битовые поля в зависимости от того, располагается ли оно в характерном для UE пространстве поиска или общем пространстве поиска. Это означает то, что в ответ на осуществление приема сообщения DCI, которое имеет размер полезной нагрузки, который обычно определяется в общем пространстве поиска и характерном для UE пространстве поиска, как являющимся допустимым для конкретного типа форматов DCI, UE 24 предполагает то, что сообщение DCI передавалось в одно из этих пространств поиска на основе конфигурирования UE при помощи RRC. Вследствие этого, UE 24 интерпретирует битовые поля сообщения DCI так же, как эти поля определяются в предполагаемом пространстве поиска.
В других вариантах осуществления описанное сообщение DCI имеет различные типы форматов DCI в общем пространстве поиска и характерном для UE пространстве поиска. Говоря другими словами, сообщение DCI имеет размер полезной нагрузки, который обычно определяется в общем пространстве поиска, как являющийся допустимым для одного типа форматов DCI, и определяется в характерном для UE пространстве поиска, как являющийся допустимым для другого типа форматов DCI. Вследствие этого, сообщение DCI в обязательном порядке содержит различные битовые поля в зависимости от того, располагается ли оно в характерном для UE пространстве поиска или общем пространстве поиска. Это означает то, что в ответ на осуществление приема сообщения DCI, которое имеет размер полезной нагрузки, который обычно определяется в общем пространстве поиска, как являющийся допустимым для одного типа формата DCI, и определяется в характерном для UE пространстве поиска, как являющийся допустимым для другого типа формата DCI, UE 24 предполагает то, что сообщение DCI передавалось в одно из этих пространств поиска на основе конфигурирования UE при помощи RRC. Вследствие этого, UE 24 интерпретирует битовые поля сообщения DCI так же, как эти поля определяются в предполагаемом пространстве поиска.
Фигура 3 иллюстрирует соответствующий способ 200, реализованный при помощи базовой станции 20, обеспечивающей первичную соту 26, которая отправляет DCI на UE 24. Как показано на Фигуре 3, способ 200 влечет за собой конфигурирование UE 24 при помощи RRC таким образом, чтобы оно предполагало то, что сообщение DCI, которое имеет общий размер полезной нагрузки и одинаковый первый индекс элемента управляющего канала, но различные битовые поля, в общем пространстве поиска и характерном для UE пространстве поиска, передается первичной сотой 26 в общее пространство поиска или характерное для UE пространство поиска (Блок 210). По меньшей мере, в некоторых вариантах осуществления, в ответ на осуществление конфигурирования UE 24 таким образом, чтобы оно делало вышеупомянутое предположение для сообщения DCI, базовая станция 20 планирует сообщение DCI для передачи на UE 24.
Осуществление конфигурирования UE 24 при помощи RRC таким путем, по существу, означает осуществление отправки сообщения RRC на UE 24. В одном или более вариантах осуществления базовая станция отправляет сообщение RRC с первым значением или вторым значением для параметра в сообщении RRC, для того чтобы сконфигурировать UE 24 таким образом, чтобы оно предполагало то, что сообщение DCI передается первичной сотой 26 в общее пространство поиска или характерное для UE пространство поиска, соответственно.
Конечно, как упоминалось выше с точки зрения UE 24, UE 24 может выполняться с возможностью предполагать по умолчанию то, что сообщение DCI передается первичной сотой 26 в общее пространство поиска. В этом случае, при обстоятельствах, когда базовая станция 20 воспринимает это предположение по умолчанию неправильным, то базовая станция 20 конфигурирует UE при помощи RRC таким образом, чтобы вместо этого оно воспринимало то, что сообщение DCI передается первичной сотой 26 в характерное для UE пространство поиска. Параметр в сообщении RRC может, например, иметь первое значение, указывающее то, что должно делаться предположение по умолчанию (например, CSS), и второе значение, указывающее то, что должно делаться предположение не по умолчанию (например, USS).
В одном варианте, базовая станция в некоторых вариантах осуществления является выполненной с возможностью выполнять вышеупомянутое на постоянной основе или на основе «сообщение-за-сообщением», как часть планирования DCI. Фигура 4 иллюстрирует способ, выполняемый базовой станцией 20 в этом отношении с использованием примера, где базовая станция 20 конфигурирует UE таким образом, чтобы оно не принимало во внимание предположение CSS по умолчанию. Как это показано, способ включает в себя осуществление идентификации того, что размер полезной нагрузки между сообщением DCI в общем и характерном для UE пространствах поиска является одинаковым, хотя определение битов является различным (т.е. конфликтным) в этих пространствах (Блок 310). Для того чтобы предотвратить неопределенность, которая в противном случае приведет к интерпретированию определения битов, вследствие этого, способ дополнительно включает в себя, в ответ на эту идентификацию, осуществление конфигурирования UE 24 при помощи RRC для того, чтобы установить приоритет характерного для UE пространства поиска перед общим пространством поиска (Блок 320). Это, по существу, означает то, что базовая станция 20 конфигурирует UE 24 при помощи RRC таким образом, чтобы оно предполагало то, что сообщение DCI передается в характерное для UE пространство поиска. В ответ на подобное конфигурирование RRC, способ, в конце концов, влечет за собой осуществление планирования сообщения DCI таким образом, чтобы оно отправлялось на UE 24, теперь, когда ранее конфликтные определения битов сообщения являются решенными (Блок 330).
В то время как варианты осуществления настоящего описания являются применимыми к любому типу беспроводной системы 10 связи, которая применяет общее пространство поиска и характерное для UE пространство поиска для передачи управляющей информации нисходящей линии связи, один или более вариантов осуществления оказываются, в частности, применимыми к системе 10, основанной на системе долгосрочного развития (LTE). Эти или более вариантов осуществления будут описываться ниже в контексте модификаций версий LTE, определенных TS 36.212 V10.4.0 и TS 36.213 V11.1.0. В подобных вариантах осуществления нисходящий управляющий канал, описанный выше, соответствует физическому нисходящему управляющему каналу (PDCCH). Помимо всего прочего, циклическая проверка избыточности (CRC) для каждого сообщения DCI скремблируется при помощи временного идентификатора радиосети (RNTI), назначенного предполагаемому UE-получателю, так что не требуется передавать явный адрес назначения.
В этом контексте способ на Фигуре 2 может эквивалентным образом заявляться в качестве способа, реализованного UE 24 для контролирования кандидатов PDCCH. Как это используется в настоящем описании, кандидаты PDCCH содержат конкретные элементы управляющего канала (множество CCE) или агрегирований множества CCE, которым PDCCH имеет возможность назначаться. UE 24 контролирует набор кандидатов PDCCH на предмет того, является ли PDCCH, предназначенный для UE 24, назначенным одному из этих кандидатов. Этот набор определяется на уровне агрегирования на основании уровня агрегирования в терминах общих пространств поиска и характерных для UE пространств поиска. В одном варианте, UE 24 в настоящем описании является выполненным с возможностью контролировать кандидатов PDCCH с CRC, скремблированной при помощи RNTI на UE, с общим размером полезной нагрузки и одинаковым первым индексом CCE, но с различными наборами информационных полей DCI, как определяется в общем пространстве поиска и характерном для UE пространстве поиска на первичной соте 26. Поступая таким образом, UE 24 будет предполагать то, что для кандидатов PDCCH с CRC, скремблированной при помощи RNTI на UE, или только PDCCH в общее пространство поиска, или только PDCCH в характерное для UE пространство поиска передается первичной сотой 26 в зависимости от конфигурирования UE 24 при помощи RRC.
В одном или более вариантах осуществления, например, UE 24 будет предполагать то, что для PDCCH с CRC, скремблированной при помощи RNTI на UE, если параметр в сообщении RRC, принятом UE 24, имеет первое значение, только PDCCH в общее пространство поиска передается первичной сотой 26. В противном случае, UE 24 будет предполагать, что только PDCCH в характерное для UE пространство передается первичной сотой.
Контролирование кандидата PDCCH, как это используется в настоящем описании, влечет за собой осуществление попытки декодировать кандидата PDCCH. В ответ на успешное декодирование кандидата PDCCH с общим размером полезной нагрузки и с одинаковым первым индексом CCE, но различными наборами информационных полей DCI, как определено в общем пространстве поиска и характерном для UE пространстве поиска, UE 24 интерпретирует битовые поля декодированного кандидата в соответствии с вышеупомянутым предположением. Говоря другими словами, UE 24 интерпретирует битовые поля декодированного кандидата так, как эти битовые поля определяются или в общем пространстве поиска, или характерном для UE пространстве поиска, в зависимости от конфигурирования UE при помощи RRC.
В частности, однако же, контролирование кандидата PDCCH влечет за собой осуществление попытки декодировать кандидата PDCCH в соответствии с одним или более форматами DCI. В ответ на успешное декодирование кандидата PDCCH в соответствии с форматом DCI (например, форматом DCI 0 или 1A), который имеет одинаковый размер полезной нагрузки в обоих общем пространстве поиска (CSS) и характерном для UE пространстве поиска (USS), UE 24 в настоящем описании интерпретирует информационные поля DCI декодированного кандидата так, как эти поля определены в CSS или USS, в зависимости от конфигурирования UE при помощи RRC. Например, в случае, когда формат DCI 0/1A имеет общую полезную нагрузку и одинаковый первый индекс CCE между общим и характерным для UE пространством поиска, UE 24 будет предполагать то, что сообщение DCI, которое оно принимает, является связанным с характерным для UE пространством поиска или общим пространством поиска на основе конфигурирования UE при помощи RRC. Дополнительным или альтернативным образом, в ответ на успешное декодирование кандидата PDCCH в соответствии с форматом DCI (например, форматом DCI 1), определенным первым из CSS или USS, как имеющим одинаковый размер полезной нагрузки, как и другой формат DCI (например, формат DCI 1A), определенный вторым из CSS и USS, UE 24 интерпретирует информационные поля DCI декодированного кандидата так, как эти поля определены в CSS или USS, в зависимости от конфигурирования UE при помощи RRC.
Безотносительно к использованной конкретной терминологии, варианты осуществления настоящего описания оказываются преимущественным способом для того, чтобы справиться со значительными проблемами, которые в противном случае вносятся при определенных обстоятельствах неопределенностью относительно того, как правильно интерпретировать битовые поля сообщения DCI. Как принимается в настоящем описании, проблемы в системах на основе LTE касаются того факта, что подобная неопределенность в противном случае будет существенно ухудшать покрытие и/или планирование вторичной соты по сравнению с тем, что имеется у первичной соты 26.
Более конкретно в отношении этого, один из важных инструментов для того, чтобы сделать возможным хорошую производительность на агрегированной вторичной соте, – это иметь хорошую информацию о качестве канала, т.е. отчеты по информации о состоянии канала (CSI). На практике это означает, что сети требуется получать непериодические отчеты CSI. Непериодические отчеты CSI являются важными для того, чтобы делать возможным адаптацию каналов и осуществление планирования данных с достаточной производительностью на обеих вторичной соте и первичной соте. Базовая станция (т.е. eNB) запрашивает непериодическую CSI от UE при помощи включения подобного запроса в состав сообщения DCI, переданного на UE по PDCCH на первичной соте. Точнее говоря, сеть включает запрос на непериодическую CSI в состав разрешающего сигнала UL, переданного на UE по PDCCH на первичной соте. Точнее говоря, сеть включает в состав разрешающего сигнала UL, переданного на UE по PDCCH на первичной соте, запрос на непериодическую CSI.
Осуществление запуска непериодической CSI определяется различным образом в зависимости от того, принимается ли UE разрешающий сигнал UL в общем пространстве поиска (CSS) или характерном для UE пространстве поиска. В общем пространстве поиска непериодическая CSI может запрашиваться только для первичной соты в DL с форматом DCI 0. Если UE принимает разрешающий сигнал UL в характерном для UE пространстве поиска, то используется двух-битовый идентификатор для осуществления запуска непериодической CSI, причем определенная комбинация битов является конфигурируемой для того, чтобы непериодическая CSI могла запрашиваться для обеих вторичной соты и/или первичной соты.
Этот вышеупомянутый режим работы осуществления запуска в общем случае обеспечивает возможность eNB запрашивать непериодическую CSI для обеих первичной соты и вторичной соты. В том случае, когда формат DCI 0/1А имеет одинаковый размер полезной нагрузки в USS и CSS и одинаковый первый индекс CCE между USS и CSS, UE (в соответствии с известными подходами, специфицированными в разделе 9.1.1 в TS 36.213 V11.1.0) будет предполагать то, что сообщение DCI, которое оно принимает, является связанным с CSS. То, насколько часто это происходит или нет, в основном зависит от диапазона частот системы.
В Таблице 1 показаны различные размеры полезной нагрузки формата DCI 0/1a в USS и CSS, когда UE является выполненным с одной вторичной нисходящей несущей. Можно заметить на основе таблицы то, что формат DCI 0/1a имеет одинаковый размер в общем и характерном для UE пространстве поиска для диапазонов частот системы в 1.4, 5 и 10 МГц. Результаты изменяются в зависимости от диапазона частот системы из-за того, что количество битов заполнения, представленных в формате DCI 0, является различным для различным диапазонов частот системы.
Таблица 1Длина формата DCI в CSS и USS для формата DCI 0/1a
BW системы
Характерное для UESS (длина в битах)
Общее SS(длина в битах)
<b>1,4 МГц</b>
<b>37</b>
<b>37</b>
3 МГц
39
38
<b>5 МГц</b>
<b>41</b>
<b>41</b>
<b>10 МГц</b>
<b>43</b>
<b>43</b>
15 МГц
44
43
20 МГц
45
44
Кроме того, здесь является важным отметить то, что общее пространство поиска имеет уровни агрегирования 4 и 8, в то время как характерное для UE пространство поиска имеет уровни агрегирования 1, 2, 4 и 8. Воздействие перекрывания уровней агрегирования 4 и 8 между характерным для UE пространством поиска и общим пространством поиска состоит в том, что eNB не может запрашивать непериодическую CSI для вторичной соты, предполагая этот уровень агрегирования. Вероятность блокировки между общим и характерным для UE пространством поиска, если имеются проблематичные диапазоны частот в Таблице 1, представлена в Таблице 2. Результаты в Таблице 2 предполагают конфигурирование физического канала (PHICH) с идентификатором гибридного автоматического запроса на повторную передачу данных (HARQ) величиной Ng=1. Результаты имеют место, если рассматривать доступность характерного для UE пространства поиска на уровне агрегирования 4 и 8 для каждого соответствующего диапазона частот системы вместе с количеством символов мультиплексирования с ортогональным разделением частот (OFDM), выделенных физическим нисходящим управляющим каналом (PDCCH).
Таблица 2Вероятность блока USS и CSS на уровне агрегирования 4 и 8
Уровеньагрегирования
4 CCE
8 CCE
Диапазон частот/CFI
1*
2*
3*
1
2
3
1,4 МГц
100%
100%
100%
нет
нет
нет
5 МГЦ
100%
100%
80%
100%
100%
100%
10 МГц
100%
67%
40%
100%
67%
40%
*Значения CFI для 1,4 МГц соответствуют 2, 3 и 4 символам для PDCCH, соответственно
Один или более вариантов осуществления настоящего описания устанавливают из Таблицы 2 то, что количество возможных мест для планирования сообщения DCI в характерном для UE пространстве поиска с уровнем агрегирования 4 и 8 является очень ограниченным для известных подходов, и является вообще невозможным в большинстве случаев, рассматривая 5 и 1,4 МГц в качестве диапазона частот системы. Вышеупомянутое ограничение приводит к тому, что покрытие вторичной соты существенно уменьшается для известных подходов по сравнению с первичной сотой из-за того, что отсутствуют доступные для нее непериодические отчеты CSI. Это происходит потому, что уровень агрегирования сообщения DCI, использующегося для осуществления запроса на непериодическую CSI, является ограниченным 1 и 2. Говоря другими словами, для eNB является невозможным запросить отчеты по непериодической CSI для вторичной соты в том случае, когда первичная сота имеет небольшой размер диапазона частот.
Вышеупомянутое описано с точки зрения отправки отчетов по непериодической CSI вместе с CA. В том случае, когда UE является выполненным с возможностью осуществления планирования для нескольких несущих, проблематичные случаи представляют собой другую, но связанную проблему. В случае осуществления планирования для нескольких несущих эта проблема будет влиять на возможность планирования вторичной несущей UL. Предположением является то, что вторичная несущая UL может планироваться только при помощи формата DCI 0. Таблица 3 представляет размер полезной нагрузки формата DCI 0 в характерном для UE пространстве поиска, при условии, что UE является выполненным с возможностью осуществления планирования для нескольких несущих и агрегированием несущих (CA).
Таблица 3Размер формата DCI 0/1а, когда сконфигурирован с CA и осуществлением планирования для нескольких несущих
Диапазон частот системы
Формат DCI 0/1a с CIF
1,4 МГц
41
3 МГц
43
5 МГц
44
10 МГц
46
15 МГц
47
20 МГц
49
Изучая воздействие осуществления планирования для нескольких несущих при помощи комбинирования результатов в Таблице 3 с Таблицей 2, можно увидеть, что формат DCI 0 для вторичной соты имеет равную длину с форматом DCI 0/1а в общем пространстве поиска для следующий конфигураций CA: (А) 5 МГц Первичная сота и 1.4 МГц Вторичная сота; (В) 10 МГц Первичная сота и 3 МГц Вторичная сота; и (С) 20 МГц Первичная сота и 5 МГц Вторичная сота. В том случае, когда диапазон частот системы представляет собой величину 20 МГц, проблема с противоречием между общим и специальным для UE не является слишком существенной. Вместо этого, фокусируясь на случае с 5 и 10 МГц, воздействие вышеупомянутого ограничения заключается в том, что планирование вторичной соты в UL будет иметь меньшее покрытие, чем планирование первичной соты в UL, из-за того, что планирование вторичной соты UL будет ограничиваться 1 и 2 CCE.
Таким образом, варианты осуществления настоящего описания выявляют то, что способ для запрашивания eNB непериодической CSI для вторичной соты не является надежным в текущей версии release 10 3GPP, которая применяет известные подходы. В большинстве размещений eNB может только запрашивать CSI для множества UE в хорошем SINR. Помимо всего прочего, такое же ограничение (по той же причине) применяется к планированию для нескольких несущих в определенных комбинациях диапазонов частот, и потенциально будет применяться к любой будущей функциональной возможности 3GPP, где дополнительные биты добавляются в управляющую информацию нисходящей линии связи (DCI), когда функциональная возможность активируется. Это существенно уменьшает покрытие вторичной соты по сравнению с имеющимся у первичной соты.
Варианты осуществления настоящего описания, которые конфигурируют предположение со стороны UE USS или CCS через посредство RRC, преимущественно улучшают покрытие вторичной соты. Более того, варианты осуществления предоставляют возможность eNB планировать UE с более высокими уровнями агрегирования (т.е. 4 и 8). Это обеспечивает возможность eNB запрашивать непериодическую CSI и планировать вторичную соту UL с использованием подобных более высоких уровней агрегирования, когда качество приема в UE не является хорошим. К тому же это приводит к дополнительным возможностям взаимодействия с пользователем, поскольку UE, например, может функционировать с агрегированием несущих для большей части соты. Говоря другими словами, покрытие вторичной соты улучшается по сравнению с известными подходами.
Один или более других вариантов осуществления настоящего описания включают в себя еще другие пути обеспечения того, что UE может запрашивать непериодическую CSI для множества сот или процессов, или планирования всех соответствующих сот UL. В соответствии с некоторыми вариантами осуществления, например, обработка для осуществления этого влечет за собой то, что размер полезной нагрузки DCI делается различным между общим и характерным для UE пространством поиска. Дополнительным или альтернативным образом, другие варианты осуществления настоящего описания делают это при помощи изменения определения битовых полей в сообщении DCI в общем пространстве поиска.
В соответствии с одним вариантом осуществления, запускающий бит для непериодической CSI в формате DCI 0, которая передается при помощи любого из PDCCH/EPDCCH на UE при помощи eNB в общее пространство поиска, обозначает набор процессов CSI или отчетов CSI, связанных с различными сотами. Набор отчетов по непериодической CSI, которые направляются, основываются на предварительно сконфигурированном сообщении оконечному устройству, которое обозначало, каким процессам CSI или сотам принадлежат отчеты по непериодической CSI. В дальнейшем пояснении примером варианта осуществления конфигурирование осуществляется при помощи RRC или MAC.
В другом пояснении примером варианта осуществления набор, для которого UE отправляет отчет с непериодической CSI, соответствует или набору 1, или набору 2 из конфигурации запускающего бита для запросов на непериодическую CSI в характерном для UE пространстве поиска. Эти наборы задаются или таблицей 7.2.1-1А, или 7.2.1-1В в TS 36.213 V11.1.0, причем 7.2.1-1А соответствует тем обслуживающим сотам, для которых выполняется отправка отчета по CSI, и 7.2.1-1В соответствует тем процессам CSI, для которых делается отправка отчета:
Таблица 7.2.1-1АПоле запроса CSI для PDCCH с форматом DCI восходящей линии связи в USS
Значение поля запроса CSI
Описание
«00»
Непериодический отчет CSI не запускается
«01»
Непериодический отчет CSI запускается для обслуживающей cоты с
«10»
Непериодический отчет CSI запускается для 1-го набора обслуживающих сот, сконфигурированных более высокими уровнями
«11»
Непериодический отчет CSI запускается для 2-го набора обслуживающих сот, сконфигурированных более высокими уровнями
Таблица 7.2.1-1BПоле запроса CSI для PDCCH/EPDCCH с восходящим форматом DCI в USS
Значение поля запроса CSI
Описание
«00»
Непериодический отчет CSI не запускается
«01»
Непериодический отчет CSI запускается для наборапроцесса(ов) CSI, сконфигурированных более высокими уровнями для обслуживающей соты с
«10»
Непериодический отчет CSI запускается для 1-го набора процесса(ов) CSI, сконфигурированных более высокими уровнями
«11»
Непериодический отчет CSI запускается для 2-го набора процесса(ов) CSI, сконфигурированных более высокими уровнями
Как показано на Фигуре 5, например, способ 400 включает в себя формат DCI 0, который передается в CSS с осуществлением запуска непериодической CSI (Блок 410). Способ 400 также включает в себя передачу со стороны UE непериодической CSI в соответствии с набором 1 (Блок 420).
В другом варианте осуществления дополнительный(е) бит(ы) заполнения добавляется(ются) к сообщению DCI для того случая, когда сообщение DCI передается в характерное для UE пространство поиска, и упомянутый размер полезной нагрузки сообщения DCI также представляет собой допустимое сообщение DCI в общем пространстве поиска, но с другой интерпретацией битовых полей в пределах сообщения DCI.
В другом варианте осуществления дополнительный(е) бит(ы) заполнения добавляется(ются) к сообщению DCI для того случая, когда сообщение DCI передается в общее пространство поиска, и упомянутый размер полезной нагрузки сообщения DCI также представляет собой допустимое сообщение DCI в характерном для UE пространстве поиска, но с другой интерпретацией битовых полей в пределах сообщения DCI.
Фигура 6 иллюстрирует этот вариант осуществления. Как показано, способ 500 включает в себя определение того, является ли одинаковым размер полезной нагрузки сообщения DCI между CSS и USS, но определение битов сообщения DCI является различным (Блок 510). Если это тот случай (ДА в Блоке 510), то сообщение DCI заполняется дополнительным битом (Блок 520). В противном случае (НЕТ в Блоке 510) сообщение DCI не заполняется дополнительным битом. И в том, и в другом случае сообщение DCI в дальнейшем передается (Блок 530).
В дополнительном пояснении примером варианта осуществления описанное сообщение DCI может иметь различные типы форматов DCI или может иметь одинаковый тип формата DCI, но причем сообщение DCI содержит различные битовые поля в зависимости от того, располагается ли оно в характерном для UE или общем пространстве поиска. Например, дополнительный бит заполнения добавляется к формату DCI 0/1A в том случае, если формат DCI имеет различное понимание в характерном для UE и общем пространстве поиска, и формат DCI 1/1A имеет одинаковый размер в общем пространстве поиска и характерном для UE пространстве поиска. Поскольку этот вариант осуществления представляет функциональную возможность, которая вызывает изменение длины форматов DCI для того, чтобы она отличалась от той, которая устанавливалась в предыдущих версиях LTE Rel-1, может требоваться, чтобы функциональная возможность являлась конфигурируемой или как активная, или как неактивная, для того чтобы отвечать за изменение в длине формата DCI между двумя специальными версиями Rel-10.
В дополнительном примере дополнительный(е) бит(ы) заполнения всегда добавляется(ются), если применяемый размер полезной нагрузки DCI может иметь различную интерпретацию в общем или характерном для UE пространстве поиска, вне зависимости от того, передается ли сообщение DCI на начальном CCE и с длиной CCE сообщения PDCCH, которые всегда являются допустимыми в общем пространстве поиска, в соответствии с вышеупомянутыми определениями.
В дополнительном примере дополнительный(е) бит(ы) заполнения добавляется(ются), если применяемый размер полезной нагрузки DCI может иметь различную интерпретацию в общем или характерном для UE пространстве поиска, и начальный CCE и/или длина CCE сообщения PDCCH являются допустимыми в обоих общем и характерном для UE пространстве поиска.
Дополнительный(е) бит(ы) заполнения добавляется(ются) eNB как часть полезной нагрузки формата DCI. Принимающее UE будет предполагать, что заполнение присутствует или отсутствует, принимая во внимание вышеупомянутые примеры.
В дополнительном примере UE будет предполагать то, что бит(ы) заполнения присутствует(ют) в вышеупомянутых заданных сценариях, если оно является сконфигурированным таким образом, чтобы предполагать это. Конфигурирование, например, может осуществляться через RRC или MAC.
Биты заполнения, описанные в варианте осуществления, например, могут представлять собой биты, определенные в виде «значение бита 0» или «значение бита 1», добавленные в конец сообщения DCI.
Еще в другом варианте осуществления UE может планироваться со специальным RNTI только или в общем, или характерном для UE пространстве поиска. Описанный RNTI скремблирует CRC, которая является связанной с форматом DCI, который передается по одному из PDCCH/EPDCCH.
Фигура 7 иллюстрирует способ 600 в соответствии с этим вариантом осуществления. Как показано, способ включает в себя определение eNB того, чтобы передать DCI на UE (Блок 610). Способ дополнительно включает в себя определение eNB того, направлять ли UE или нет в общее пространство поиска (Блок 620). Если это так, то eNB определяет то, чтобы использовать RNTI характерного для UE пространства поиска (Блок 640). Если это не так, то eNB определяет то, чтобы использовать RNTI общего пространства поиска (Блок 630). В одном варианте eNB в дальнейшем планирует для UE сообщение DCI, которое ранее было противоречивым (Блок 650).
В одном примере варианта осуществления eNB конфигурирует UE с индивидуальными RNTI для того, чтобы использовать в общем и характерном для UE пространстве поиска, соответственно.
В дополнительном примере варианта осуществления eNB только отправляет сконфигурированные индивидуальные RNTI в случае, когда сообщение DCI передается в характерное для UE пространство поиска и имеет такой же размер полезной нагрузки, как и сообщение DCI в общем пространстве поиска, но другую интерпретацию битовых полей в пределах сообщения DCI.
В другом примере RNTI, который должен использоваться в общем пространстве поиска, представляет собой функцию от RNTI, который должен использоваться для характерного для UE пространства поиска.
В дополнительном примере RNTI является различным между общим и характерным для UE пространством поиска только в том случае, когда сообщение DCI передается в характерное для UE пространство поиска и имеет такой же размер полезной нагрузки, как и сообщение DCI в общем пространстве поиска, но другую интерпретацию битовых полей в пределах сообщения DCI.
Фигура 8 иллюстрирует еще другой вариант осуществления. Как показано, способ 700 включает в себя eNB, идентифицирующую сообщение DCI с одинаковым размером полезной нагрузки, но различной интерпретацией битов между общим и характерным для UE пространством поиска (Блок 710). Способ 700 дополнительно включает в себя eNB, конфигурирующую UE дополнительными функциональными возможностями, которые увеличивают размер полезной нагрузки DCI (т.е. расширяют сообщение DCI) в характерном для UE пространстве поиска, для того чтобы предотвратить вышеупомянутую проблему. Примером подобного конфигурирования является то, если eNB сконфигурировала UE таким образом, чтобы оно работало с агрегированием несущих, и первичная сота имеет величину 5МГц. Для того чтобы предотвратить эту проблему, в дальнейшем eNB дополнительно конфигурирует UE с дополнительной функциональной возможностью. Пример подобной функциональной возможности представляет собой то, если UE дополнительно является сконфигурированным с непериодическими звуковыми опорными сигналами (SRS).
В то время как вышеупомянутые варианты осуществления были описаны по отдельности, два или более из вариантов осуществления настоящего описания в некоторых случаях используются вместе.
Принимая во внимание модификации и вариации, описанные выше, для способов настоящего описания, средним специалистам в данной области техники следует принять во внимание то, что Фигура 9 иллюстрирует устройство беспроводной связи (т.е. пользовательское оборудование, UE) 24, выполненное с возможностью выполнять описанный выше технологический процесс. В связи с этим, устройство включает в себя один или более коммуникационных интерфейсов, выполненных с возможностью коммуникационным образом подключать устройство 24 к одной или более базовым станциям 20 в беспроводной системе 10 связи. Как показано, эти один или более коммуникационных интерфейсов содержат приемник (RX) 28 и передатчик (TX) 30, соединенные с одной или более антеннами 32. Устройство 24 также включает в себя одну или более обрабатывающих схем 34, выполненных с возможностью, например, в сочетании с памятью 36, реализовывать технологический процесс, описанный выше.
Средним специалистам в данной области техники следует принимать во внимание то, что Фигура 10 иллюстрирует базовую станцию 20, выполненную с возможностью выполнять технологический процесс, описанный выше. Базовая станция 20 аналогичным образом включает в себя один или более коммуникационных интерфейсов, выполненных с возможностью коммуникационным образом подключать базовую станцию 20 к одному или более устройствам 24 беспроводной связи. Как показано, эти один или более коммуникационных интерфейсов содержат приемник (RX) 38 и передатчик (TX) 40, соединенные с одной или более антеннами 42. Базовая станция 20, однако, также включает в себя один или более коммуникационных интерфейсов, выполненных с возможностью коммуникационным образом подключать базовую станцию 20 к одной или более другим базовым станциям и/или другим сетевым узлам. Как показано, эти интерфейсы включают в себя интерфейс S1 44 и интерфейс X2 46 в соответствии со стандартами LTE. В одном варианте, базовая станция дополнительно включает в себя одну или более обрабатывающих схем 48, выполненных с возможностью, например, в сочетании с памятью 50, реализовывать технологический процесс, описанный выше.
Средним специалистам в данной области техники, конечно, будут принимать во внимание то, что вышеупомянутый чертеж представляет собой просто пример, и что отображенные схемы могут реализовываться, воплощаться или конфигурироваться другим образом в пределах узла на основе исполнения команд компьютерной программы, сохраненных в памяти или в пределах другого машиночитаемого носителя в объекте. Таким образом, схемы, обсужденные выше, могут содержать процессорную схему (состоящую, например, из одного или более микропроцессоров, микроконтроллеров, цифровых сигнальных процессоров или подобных им), выполненную с надлежащими программными средствами и/или программно-аппаратными средствами в памяти, для того чтобы выполнять один или более технологических приемов, обсужденных выше. Схемы могут альтернативным образом реализовываться (полностью или частично) при помощи одной или более выделенных интегральных схем, таких как одна или более программируемых пользователем вентильных матриц (множество FPGA) или интегральных схем прикладной ориентации (множество ASIC).
Настоящее изобретение может, конечно, выполняться другими путями, отличающимися от тех, которые, в частности, изложены в настоящем описании, без отступления от существенных характеристик изобретения. Настоящие варианты осуществления должны рассматриваться во всех отношениях, как иллюстративные и не ограничивающие, и предполагается, что все изменения, происходящие в пределах смысла и эквивалентности прилагающейся формулы изобретения, должны охватывать таковую.