Предоставление отчетов, характерных для sftd и anr

Изобретение относится к средствам предоставления отчетов о разнице (SFTD) во времени кадров с номером системного кадра (SFN). Технический результат заключается в обеспечении UE предоставлять отчет об измерениях SSTD для списка сот. Принимают из сетевого узла в беспроводной сети список сот, для которых UE может предоставить отчет об измерениях SFTD. Выполняют измерения SFTD между PCell UE и второй сотой, причем вторая сота является сотой в списке сот, для которых UE может предоставить отчет об измерениях SFTD. Предоставляют, в сетевой узел, отчет об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD. 3 н. и 11 з.п. ф-лы, 11 ил.

 

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

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

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

Конфигурация отчетности в новом радио (NR)

Основные конфигурации отчетности при двойной связности в рамках развитой универсальной наземной сети радиодоступа (E-UTRAN) (EN-DC) для NR уже согласованы на форуме RAN2 проекта партнерства третьего поколения (3GPP), а также включены в спецификации управления радиоресурсами (RRC) (смотри техническую спецификацию 3GPP (TS) 38.331 v15.0.1). На основе этих конфигураций отчетности сеть может конфигурировать пользовательское оборудование (UE) на предоставление отчетов периодическим образом или на основе определенных триггеров событий. В настоящее время стандартизированные триггеры событий основаны на таких событиях, как в долгосрочном развитии (LTE), то есть на событиях A1-A6. В дополнение к инициируемым событиям и периодическому инициированию отчетов предусмотрен также заполнитель для "reportCGI", который используется для специальных целей автоматического взаимодействия между соседними сотами (ANR). Конфигурации отчетности представлены в информационном элементе ReportConfigNR, который описан в следующем фрагменте из 3GPP TS 38.311 v15.0.1:

**********************************************************************

ReportConfigNR

IE ReportConfigNR точно определяет критерии для инициирования события предоставления отчета о результатах измерений NR. События предоставления отчетов о результатах измерений основаны на результатах измерений соты, которые могут быть получены на основе блока SS/PBCH или CSI-RS. Эти события помечаются AN с N, равным 1, 2 и т.д.

Событие A1: уровень сигнала обслуживающей соты становится выше абсолютного порога;

Событие A2: уровень сигнала обслуживающей соты становится ниже абсолютного порога;

Событие A3: величина смещения соседней соты становится выше, чем у PCell/PSCell;

Событие A4: уровень сигнала соседней соты становится выше порога;

Событие A5: уровень сигнала сPCell/PSCell становится ниже порога 1 (threshold1), и уровень сигнала соседней соты становится выше порога 2 (threshold2);

Событие A6: смещение частоты соседней соты становится выше, чем у вторичной соты (SCell).

Информационный элемент ReportConfigNR

-- ASN1STOP

**************************************************************************

Механизм ANR в LTE и NR

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

Эта процедура проиллюстрирована на фиг. 1. На этапе 1 UE отправляет отчет об измерении в обслуживающий усовершенствованный или развитой узел B (Node B, eNB). Отчет об измерении содержит идентификатор физической соты (PCI) соты В. Затем eNB инструктирует UE считать ECGI, код зоны отслеживания (TAC), и все имеющиеся идентификаторы (ID) наземной сети мобильной связи общего пользования (PLMN) соты B. Соседняя сота широковещательно передает свои ID PLMN, TAC и т.д. в сообщении блока 1 системной информации (SIB1). После измерения этих значений UE предоставляет отчет об обнаруженном ECGI в обслуживающий eNB, и eNB принимает решение относительно того, чтобы добавить это взаимодействие между соседними сотами. eNB может использовать PCI и ECGI для поиска адреса транспортного уровня в новом eNB, обновить список взаимодействия между соседними сотами и при необходимости установить новый интерфейс X2 для этого eNB.

Первая версия стандарта для мобильных сетей 5-го поколения (то есть первая версия стандарта для NR) будет предназначена для неавтономных (NSA) сетей NR, использующих существующую сеть радиосвязи LTE и сеть развитого пакетного ядра (EPC) с добавлением несущей NR. Узлы NR NSA всегда будут иметь узел LTE в качестве главного узла, и системная информация не должна передаваться в NR, так как UE не будет базироваться в NR. Чтобы помочь UE с выполнением процедуры ANR, конфигурация отчетности NR уже имеет заполнитель для предоставления отчетов CGI неизвестной соседней соты. Заполнитель называется "reportCGI". Однако детали того, как сконфигурировать такую конфигурацию отчетов, еще не определены.

Предоставление отчета о разнице во времени в одночастотной сети (SFN) (SFTD)

В LTE конфигурация измерений SFN и разницы во времени между подкадрами (SSTD) используется для того, чтобы получить разницу во времени между первичной сотой (PCell) и первичной вторичной сотой (PSCell). В версии 15 для целей EN-DC было решено, что измерения SFTD могут быть сконфигурированы главным eNB (MeNB), и отчет, принятый MeNB, будет перенаправлен во вторичную gNB (SgNB) (где "gNB" обозначает базовую станцию NR), так что оба узла знают о разнице во времени между собой. Кроме того, было решено, что отчетность измерений SSTD распространяется на соты, которые не сконфигурированы в случае, если не сконфигурирована PSCell. Это полезно для помощи сети при конфигурировании релевантных окон конфигурации временной синхронизации измерений сигнала синхронизации (SMTC).

Соглашения из RAN2 #99bis:
1. Измерения SSTD для EN-DC поддерживаются со следующими принципами (как в LTE):
а) MeNB может конфигурировать отчеты о смещении SFN/подкадра для PSCell только в том случае, когда сконфигурирован EN-DC;
b) UE нужно только считать MIB для измерения/предоставления отчета относительно SFN/смещения подкадра;
c) MeNB пересылает смещение SFN/подкадра из MeNB в SgNB, используя "SCG-ConfigInfo" (требуется определить название IE).
d) покадровый отчет (то есть eNB конфигурирует измерение, и UE отправляет в eNB один отчет, а не периодические отчеты).
Соглашения из RAN2 #100:
1. Сеть может конфигурировать измерение SSTD NR всякий раз, когда сконфигурирована PSCell NR
2. Отчетность измерений SSTD NR распространяется на соты, которые еще не сконфигурированы в том случае, если PSCell NR не сконфигурирована

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

Раскрытие сущности изобретения

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

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

В некоторых вариантах осуществления список сот содержит одну или более сот нового радио (NR). Кроме того, в некоторых вариантах осуществления PCell является сотой долгосрочного развития (LTE). В некоторых вариантах осуществления предоставление отчета об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD, содержит предоставление отчета об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD, когда ни одна сота NR не сконфигурирована как первичная вторичная сота (PSCell) UE. В некоторых вариантах осуществления способ дополнительно содержит, когда сота NR сконфигурирована как PSCell для UE, выполнение измерения SFTD между PCell UE и PSCell NR и предоставление отчета об измерении SFTD между PCell UE и PSCell NR.

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

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

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

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

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

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

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

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

Фиг. 1 - процедура автоматического взаимодействия между соседними сотами (ANR);

фиг. 2 - процесс, в котором пользовательское оборудование (UE) сконфигурировано, сетевым узлом, со списком сот, для которых UE может предоставить отчет об измерениях одночастотной сети (SFN) - разницы во времени кадра (SFTD) в соответствии с некоторыми вариантами осуществления настоящего раскрытия;

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

фиг. 4 - один вариант осуществления UE в соответствии с различными аспектами, описанными в данном документе;

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

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

фиг. 7 - дополнительные подробности, касающиеся хост-компьютера, базовой станции и UE в системе связи (фиг. 6) в соответствии с некоторыми вариантами осуществления настоящего раскрытия; и

фиг. 8-11 - блок-схемы, иллюстрирующие способы, реализованные в системе связи, в соответствии с некоторыми вариантами осуществления настоящего раскрытия.

Осуществление изобретения

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

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

В настоящее время существуют определенные проблемы. В существующей конфигурации отчетности нового радио (NR) проекта партнерства третьего поколения (3GPP) в конфигурации отчетности имеется заполнитель "reportCGI". Этот заполнитель должен использоваться для глобального идентификатора соты (CGI) отчетности для конкретных целей автоматического взаимодействия между соседними сотами (ANR). Однако детали этой конфигурации еще не стандартизированы. Кроме того, в NR обсуждается конфигурация отчетности относительно одночастотной сети (SFN) и разницы во времени (SFTD), и детали этой конфигурации еще точно не определены.

Некоторые аспекты настоящего раскрытия и их вариантов осуществления позволяют обеспечить решения этих или других проблем. В настоящем раскрытии предложены варианты осуществления конфигурации отчетности SFTD и отчетности, связанной с ANR. С помощью этих предложений может осуществляться поддержка ANR для неавтономного (NSA) NR, не полагаясь на передачи системной информации из NR, с использованием существующего взаимодействия между соседними сотами LTE для того, чтобы найти адрес Интернет-протокола (IP) любых неизвестных узлов NR.

В данном документе предложены различные варианты осуществления, которые касаются одного или нескольких вопросов, раскрытых в данном документе. Некоторые варианты осуществления могут обеспечивать одно или несколько из следующих технических преимуществ. Например, предложенные варианты осуществления обеспечивают объединенный способ предоставления отчетов SFTD и отчетов ANR в компактной форме. Это позволит UE предоставлять отчет об измерениях SSTD для списка сот. Эти и другие технические преимущества можно легко увидеть в свете последующего описания. Конкретные варианты осуществления могут обеспечить некоторые, ни одного или все эти технические преимущества.

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

1. Конкретные конфигурации ANR

В LTE информационный элемент (IE) reportCGI был сконфигурирован как часть периодических отчетов об измерениях с периодичностью, равной бесконечности. В основном это покадровая отчетность. В NR этот параметр уже считается частью параметра reportType, но его конфигурация требует дальнейшего изучения и еще не согласована. Кроме того, ранее были предложены улучшения. Например, было предложено предоставлять список сот, для которых пользовательское оборудование (UE) должно предоставлять отчеты CGI. Кроме того, было также предложено сконфигурировать соту(ы), для которой(ых) нужно предоставлять отчет CGI в reportConfig, а не в measObject. Однако все вышеупомянутые конфигурации основаны на отчете, инициированном событием, или периодическом событии, полученном из UE, который содержит идентификатор физической соты (PCI), который не входит в число известных соседних сот для обслуживающей соты. Следует отметить, что как и в LTE, в вышеупомянутых механизмах UE не известно ни о каком списке соседних сот, и UE не может заранее обнаружить наличие неизвестной соседней соты в зоне.

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

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

1.1. Обнаружение дополнительной соседней соты

UE сконфигурировано с окнами конфигурации временной синхронизацией измерений сигнала синхронизации (SMTC), которые информируют UE о том, где найти блоки сигнала синхронизации (SS)/физического широковещательного канала (PBCH) (которые также упоминаются как блоки SS или SSB) на соответствующей частоте. Все передачи блоков SS/PBCH должны происходить в пределах этого окна. Окно может иметь длительность до 5 миллисекунд (мс), и его периодичность может быть сконфигурирована среди {5,10,20,40,80,160} мс. За пределами этого окна SMTC от UE не ожидается выполнения каких-либо измерений координации функций управления радиоресурсами (RRM).

Блоки SS/PBCH, передаваемые из соты, будут содержать первичный сигнал синхронизации (PSS), вторичный сигнал синхронизации (SSS) и PBCH. Содержание PBCH будет включать в себя, помимо прочего, индекс синхронизации, который информирует UE о том, является ли обнаруженный блок SS/PBCH первым блоком SS/PBCH из этой соты, или вторым блоком SS/PBCH из этой соты, или третьим блоком SS/PBCH из этой соты и т.д. На основе этой информации UE может обнаружить, существует ли какая-либо сота, чья передача блока SS/PBCH выходит за пределы сконфигурированного окна SMTC. Один способ, который может использоваться UE для этого, приведен ниже. Следует отметить, что это только примерный вариант осуществления, и для него могут быть выполнены дополнительные оптимизации. Например, вместо рассмотрения каждого обнаруженного блока SS/PBCH, UE может рассматривать только самый мощный блок SS/PBCH из данного PCI. Пример процесса выглядит следующим образом:

• Для каждого обнаруженного идентификатора блока SS/PBCH в UE

○ если обнаруженный идентификатор блока SS/PBCH (индекс луча) больше 1:

▪ на основе обнаруженного индекса временной синхронизации (идентификатор блока SS/PBCH → индекс луча), найти возможный экземпляр передачи идентификатора первого блока SS/PBCH из этой соты

▪ Проверить, происходит ли первая передача SS/PBCH блока перед началом окна SMTC.

• Если это так, то UE объявляет обнаружение кандидата неизвестной соседней соты

1.2. Обнаружение ошибки PCI

Оборудование UE выполняет измерения блока SS/PBCH в пределах окна SMTC. В течение этого времени UE ожидает, что индексы блоков SS/PBCH из одной и той же соты (например, индексы блоков SS/PBCH, которые имеют одинаковый PCI, закодированный в PSS + SSS) поступят в порядке возрастания, так как индекс блока SS/PBCH указывает информацию о временной синхронизации. Таким образом, если UE обнаруживает два разных блока SS/PBCK из одной и той же соты (например, имеющих одинаковый PCI) в одном и том же окне SMTC, и если эти обнаруженные блоки SS/PBCH не появляются в порядке постепенного возрастания, то UE может объявить, что существует более одной соты, которая покрывает зону и передает один и тот же PCI. Это обнаружение может быть основано на поступлении блоков SS/PBCH не в порядке возрастания, и/или, если обнаруженные индексы блоков SS/PBCH между последовательными местоположениями передачи SS/PBCH не находятся в порядке постепенного возрастания, согласно ожидаемой последовательности передачи. Эта ситуация может быть объявлена как обнаружение ошибки PCI.

1.3. Содержание ReportConfigNR

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

Если сети требуется получить отчет, связанный с "дополнительным обнаружением соседних сот", сеть может сконфигурировать UE для запуска отчета об измерениях, если такая сота обнаружена, путем установки флага reportTriggering на OneShotReportConfig и установки reportPurpose на cellOutsideSMTCWindowDetection или cellOutsideSMTCWindowDetectionORPCIConfusionDetection. В таком отчете UE включает в себя соту, которая была обнаружена в окне SMTC, но может иметь другие блоки SS/PBCH, переданные до запуска окна SMTC.

Если сети требуется получить отчет, связанный с "обнаружением ошибки PCI", сеть может сконфигурировать UE для запуска отчета об измерениях, если такая сота обнаружена, путем установки флага reportTriggering на OneShotReportConfig и установки reportPurpose на PCIConfusionDetection или cellOutsideSMTCWindowDetectionORPCIConfusionDetection. В таком отчете UE включает в себя PCI, который, как было обнаружено, имеет потенциальную проблему ошибки PCI, и, возможно, UE также может включать в себя GCID этих сот, используя автономные промежутки для считывания GCID этих сот.

Один пример модифицированного IE ReportConfigNR, включающего в себя вышеупомянутые аспекты для обеспечения дополнительной отчетности, связанной с обнаружением соседней соты, и отчетности, связанной с обнаружением путаницы PCI, представлен следующим образом:

Информационный элемент ReportConfigNR

Описание полей ReportConfigNR
cellsForWhichToReport
Если поле reportPurpose установлено в reportCGI, UE должно получить идентификатор CSG, код области отслеживания, список идентификаторов PLMN для каждой из сот, перечисленных в поле cellsForWhichToReport.
reportTriggering
Булев флаг, который указывает, может ли UE инициировать отчет об измерениях на основе критерия обнаружения, как указано для автономного обнаружения неизвестного критерия обнаружения соседней соты. Это поле может быть сконфигурировано только тогда, когда reportPurpose установлен в cellOutsideSMTCWindowDetection, или PCIConfusionDetection или cellOutsideSMTCWindowDetectionORPCIConfusionDetection.
includeMultiBandInfo
Если это поле присутствует, UE должно получить и включить информацию о многочисленных диапазонах в отчет об измерениях.
reportSSTD-Meas
Если это поле установлено на true, то UE должно измерять SSTD между PCell и PSCell, как указано в TS 36.214 [48] и игнорировать поля triggerQuantity, reportQuantity и maxReportCells. E-UTRAN только устанавливает это поле в true, когда TriggerType установлен на periodical, и purpose установлен на reportStrongestCells.
si-RequestForHO
Поле применяется к функциональности reportCGI, и когда поле включено, UE разрешается использовать автономные промежутки при получении системной информации из соседней соты, применяет другое значение для T321 и включает разные поля в отчет об измерениях.
Условное присутствие Объяснение
reportCGI Поле является необязательным, необходимо ИЛИ, если purpose включен и установлен на reportCGI; в противном случае, поле отсутствует, и UE должно удалить любое существующее значение для этого поля.

2. Конфигурации отчетности SFTD

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

На основе этих соглашений сеть может конфигурировать список сот, для которых UE может предоставить отчет об измерениях SFTD. Один из примеров этого показан на фиг. 2. Необязательные этапы представлены пунктирными линиями на фиг. 2. В частности, на фиг. 2 показан процесс, в котором сетевой узел конфигурирует UE со списком сот, для которых UE может предоставить отчет об измерениях SFTD в соответствии с некоторыми вариантами осуществления настоящего раскрытия. Как показано, сетевой узел конфигурирует UE со списком сот, для которых UE может предоставить отчет об измерениях SFTD (этап 200). Как описано в данном документе, в некоторых вариантах осуществления список сот предоставляется в информационном элементе (например, в информационном элементе ReportConfigNR), который передается в RRC-сообщении, таком как сообщение о реконфигурировании RRC-соединения или сообщение о возобновлении RRC-соединения, как будет понятно специалисту в данной области техники после прочтения настоящего раскрытия. UE принимает этот список и при необходимости выполняет измерения SFTD в соответствии со списком (этап 202). Другими словами, UE выполняет измерения SFTD для сот в списке. UE предоставляет отчет об измерениях SFTD по меньшей мере для некоторых из этих сот в сетевой узел (этап 204).

В настоящем раскрытии предложено использовать аналогичный механизм для конфигурирования конфигураций отчетности, связанных с измерениями SFTD, для измерений, связанных с ANR. В случае конфигураций, связанных с ANR, ранее предлагалось предоставлять список сот, для которых UE должно предоставлять отчет об измерениях CGI. Ранее было также предложено конфигурировать этот список в конфигурации отчетности, а не в measObject. Аналогичный механизм может быть принят для конфигурации отчетности, связанной с измерением SFTD. Исходя из этого, один пример конфигурации отчетности SFTD приведен ниже.

Путем конфигурирования UE с oneShotReport, имеющим reportPurpose, установленный на reportSFTD, UE будет выполнять измерения SFTD. Конфигурация отчетности может дополнительно включать в себя "cellsForWhichToReport", который указывает UE то, для каких сот UE должно выполнить измерения SFTD и включить их в отчет об измерениях.

Информационный элемент ReportConfigNR

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

В еще одном варианте осуществления измерения SFTD, сконфигурированные в LTE, могут быть получены, как указано ниже. Эти различные варианты осуществления показаны в качестве изменений в 3GPP TS 36.331, причем измененный текст выделен жирным шрифтом с подчеркиванием. Хотя в этих предложениях используются конкретные названия и термины для IE, следует понимать, что эти названия и термины используются в иллюстративных целях. Различные названия и термины могут быть приняты в стандарте без отклонения от функциональности, раскрытой в данном документе.

1-е изменение

5.5. Измерения

5.5.1 Введение

UE предоставляет отчет с информацией об измерениях в соответствии с конфигурацией измерений, предоставленной E-UTRAN. E-UTRAN предоставляет конфигурацию измерения, применяемую для UE в RRC_CONNECTED посредством выделенной сигнализации, то есть с использованием сообщения RRCConnectionReconfiguration или RRCConnectionResume.

UE может отправлен запрос на выполнение измерений следующих типов:

- внутричастотные измерения: измерения на несущей(их) частоте(ах) нисходящей линии связи обслуживающей(их) соты (сот);

- межчастотные измерения: измерения на частотах, которые отличаются от любой из несущей(их) частоты (частот) нисходящей линии связи обслуживающей(их) соты (сот)

- измерения с использованием интер-RAT частот NR;

- измерения с использованием интер-RAT частот UTRA;

- измерения с использованием интер-RAT частот GERAN.

- измерения с использованием интер-RAT частот HRPD CDMA2000, или 1xRTT CDMA2000 или WLAN.

- измерения CBR.

Конфигурация измерений включает в себя следующие параметры:

1. Объекты измерения: объекты, в отношении которых UE должно выполнить измерения.

- Для внутричастотных и межчастотных измерений объектом измерения является одна несущая частота E-UTRA. Ассоциированная с этой несущей частотой E-UTRAN может конфигурировать список смещений, характерных для соты, список сот, занесенных в "черный список", и список сот, внесенных в "белый список". Соты, занесенные в черный список, не учитываются при оценке событий или предоставлении отчетов об измерениях.

- Для измерений NR интер-RAT объектом измерений является одна несущая частота NR. Ассоциированная с этой несущей частотой E-UTRAN может конфигурировать список сот, занесенных в "черный список". Соты, занесенные в черный список, не учитываются при оценке событий или предоставлении отчетов об измерениях.

- Для измерений UTRA интер-RAT объектом измерения является набор сот на одной несущей частоте UTRA.

- Для измерений интер-RAT GERAN объектом измерения является набор несущих частот GERAN.

- Для измерений CDMA2000 интер-RAT объектом измерения является набор сот на одной несущей частоте (HRPD или 1xRTT).

- Для измерений WLAN интер-RAT объектом измерения является набор идентификаторов WLAN и при необходимости набор частот WLAN.

- Для измерений CBR объектом измерения является набор пулов ресурсов передачи для связи по боковой линии связи V2X.

Примечание 1. Некоторые измерения, использующие вышеупомянутые объекты измерений, касаются только одной соты, например, измерений, используемых для передачи системной информации соседних сот, разнице во времени Rx-Tx UE PCell или пары сот, например измерения SSTD между PCell и PSCell или измерения SFTD между PCell и сотой NR.

2. Конфигурации отчетности: список конфигураций отчетности, где каждая конфигурация отчетности состоит из следующего:

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

- Формат отчетности: величины, которые UE включает в отчет об измерениях и ассоциированную информацию (например, количество сот для отчета).

2-е изменение

5.5.3 Выполнение измерений

5.5.3.1. Общие положения

Для всех измерений, кроме измерений разницы во времени Rx-Tx UE, RSSI, задержки из-за передачи пакета PDCP UL в расчете на одно измерение QCI, измерений канала занятости, измерения CBR, и кроме измерений WLAN полосы частот, информации о несущей, имеющейся допустимой пропускной способности, полосы пропускания транспортной сети, использования каналов и количества станций, UE применяет фильтрацию на уровне 3, как указано в 5.5.3.2, перед использованием результатов измерений для оценки критериев отчетности или для предоставления отчетов об измерениях. При выполнении измерений несущих NR UE получает качество соты, как указано в 5.5.3.3, и качество луча, как указано в 5.5.3.3a.

Оборудование UE должно:

1> всякий раз, когда UE имеет measConfig, выполнить измерения RSRP и RSRQ для каждой обслуживающей соты следующим образом:

2> для PCell, применить ограничение ресурса измерения во временной области в соответствии с measSubframePatternPCell, если он сконфигурирован;

2> если UE поддерживает измерение сигналов обнаружения на основе CRS:

3> для каждой соты SCell в деактивированном состоянии применить конфигурацию синхронизации измерения сигналов обнаружения в соответствии с MeasDS-Config, если он сконфигурирован в measObject, соответствующем частоте SCell;

1> если UE имеет measConfig со сконфигурированным rs-sinr-Config, выполнить измерения RS-SINR (как указано в ассоциированном reportConfig) следующим образом:

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

1> для каждого measId, включенного в список измерений в VarMeasConfig:

2> если purpose для ассоциированного reportConfig установлен на reportCGI:

3> если si-RequestForHO сконфигурирован для ассоциированного reportConfig:

4> выполнить соответствующие измерения на частоте и с использованием RAT, которые указаны в ассоциированном measObject, используя при необходимости автономные промежутки;

3> иначе:

4> выполнить соответствующие измерения на частоте и с использованием RAT, которые указаны в ассоциированном measObject, используя при необходимости доступные периоды ожидания или используя автономные промежутки;

Примечание 1. Если для выполнения измерений используются автономные промежутки, то UE разрешается временно прервать связь с одной или всеми обслуживающими сотами, то есть создать автономные промежутки для выполнения соответствующих измерений в рамках, заданных в TS 36.133[16]. В противном случае, UE поддерживает измерения только с целью, установленной в reportCGI, только если E-UTRAN предоставил достаточные периоды ожидания.

3> попытаться получить глобальный идентификатор соты, указанный в cellsForWhichToReportCGI в ассоциированном measObject, путем получения релевантной системной информации из рассматриваемой соты;

3> если запись в cellAccessRelatedInfoList включает в себя выбранную PLMN, получить релевантную системную информацию из рассматриваемой соты;

3> если сота, указанная cellsForWhichToReportCGI, включенный в ассоциированный measObject, является сотой E-UTRAN:

4> попытаться получить идентификатор CSG, если в рассматриваемой соте широковещательно передается идентификатор CSG;

4> попытаться получить trackingAreaCode в рассматриваемой соте;

4> попытаться получить список дополнительных идентификаторов PLMN, включенных в plmn-IdentityList, если в рассматриваемой соте широковещательно передается несколько идентификаторов PLMN;

4> если включен cellAccessRelatedInfoList, использовать trackingAreaCode и plmn-IdentityList из записи cellAccessRelatedInfoList, содержащей выбранную PLMN;

4> если includeMultiBandInfo сконфигурирован:

5> попытаться получить freqBandIndicator в SystemInformationBlockType1 рассматриваемой соты;

5> попытаться получить список дополнительных индикаторов частотных диапазонов, которые включены в multiBandInfoList, если в SystemInformationBlockType1 рассматриваемой соты включено несколько индикаторов частотных диапазонов;

5> попытаться получить freqBandIndicatorPriority, если freqBandIndicatorPriority включен в SystemInformationBlockType1 рассматриваемой соты;

Примечание 2: "Первичная" PLMN является частью глобального идентификатора соты.

3> если сота, указанная cellsForWhichToReportCGI, включенным в ассоциированный measObject, является сотой UTRAN:

4> попытаться получить LAC, RAC и список дополнительных идентификаторов PLMN, если в рассматриваемой соте широковещательно передается множество идентификаторов PLMN;

4> попытаться получить идентификатор CSG, если в рассматриваемой соте широковещательно передается идентификатор CSG;

3> если сота, указанная параметром cellsForWhichToReportCGI, включенным в ассоциированный measObject, является сотой GERAN:

4> попытаться получить RAC в рассматриваемой соте;

3> если сота, указанная параметром cellsForWhichToReportCGI, включенным в ассоциированный measObject, является сотой CDMA2000, и cdma2000-Type, включенный в measObject, является typeHRPD:

4> попытаться получить идентификатор сектора в рассматриваемой соте;

3> если сота, указанная параметром cellsForWhichToReportCGI, включенным в ассоциированный measObject, является сотой CDMA2000, и cdma2000-Type, включенный в measObject, представляет собой type1XRTT:

4> попытаться получить ID BASE, SID и NID в рассматриваемой соте;

2> если ul-DelayConfig сконфигурирован для ассоциированного reportConfig:

3> игнорировать measObject;

3> сконфигурировать уровень PDCP для выполнения задержки пакетов PDCP UL в расчете на одно измерение QCI;

2> иначе:

3> если конфигурация промежутка измерений сконфигурирована; или

3> если UE не требует промежутков измерений для выполнения рассматриваемых измерений:

4> если s-Measure не сконфигурирован; или

4> если сконфигурирован s-Measure, и RSeP PCell после фильтрации на уровне 3 ниже этого значения; или

4> если ассоциированный measObject относится к NR; или

4> если measDS-Config сконфигурирован в ассоциированном measObject:

5> если UE поддерживает измерение сигналов обнаружения на основе CS I-RS; и

5> если eventId в ассоциированном reportConfig установлен на eventC1 или eventC2, или если reportStrongestCSI-RS включены в ассоциированный reportConfig:

6> выполнить соответствующие измерения ресурсов CSI-RS на частоте, указанной в рассматриваемом measObject, применяя конфигурацию временной синхронизации измерения сигналов обнаружения в соответствии с measDS-Config в ассоциированном measObject;

6> если reportCRS-Meas включен в ассоциированный reportConfig, выполнить соответствующие измерения соседних сот на частотах, указанных в рассматриваемом measObject следующим образом:

7> для соседних сот на первичной частоте, применить ограничение ресурса измерения во временной области в соответствии с measSubframePatternConfigNeigh, если он сконфигурирован в рассматриваемом measObject;

7> применить временную конфигурацию временной синхронизации измерения сигналов обнаружения в соответствии с MeasDS-Config в рассматриваемом measObject;

5> иначе:

6> выполнить соответствующие измерения соседних сот на частотах и с использованием RAT, указанных в рассматриваемом measObject, следующим образом:

7> для соседних сот на первичной частоте, применить ограничение ресурса измерения во временной области в соответствии с measSubframePatternConfigNeigh, если он сконфигурирован в рассматриваемом measObject;

7> если UE поддерживает измерение сигналов обнаружения на основе CRS, применить конфигурацию временной синхронизации измерения сигналов обнаружения в соответствии с measDS-Config, если он сконфигурирован в рассматриваемом measObject;

4> если ue-RxTxTimeDiffPeriodical сконфигурирован в ассоциированном reportConfig:

5> выполнить измерения разницы во времени Rx-Tx UE в PCell;

4> если reportSSTD-Meas установлен на true или pSCell в ассоциированном reportConfig:

5> выполнить измерения SSTD между PCell и PSCell;

4> если measRSSI-ReportConfig сконфигурирован в ассоциированном reportConfig:

5> выполнить RSSI и измерения занятости канала на частоте, указанной в ассоциированном measObject;

2> выполнить оценку критериев отчетности, как указано в 5.5.4;

UE, способное измерить CBR тогда, когда оно сконфигурировано для передачи сообщения по боковой линии связи V2x, связанной с не-P2X, должно:

1> если в зоне покрытия на частоте, используемой для передачи по боковой линии связи V2x, как определено в TS 36.304[4, 11.4]; или

1> если рассматриваемая частота включена в v2x-InterFreqInfoList в RRCConnectionReconfiguration или в v2x-InterFreqInfoList в SystemInformationBlockType21:

2> если UE находится в RRC_IDLE:

3> если рассматриваемая частота является частотой в режиме ожидания:

4> выполнить измерение CBR для пулов в v2x-CommTxPoolNormalCommon и v2x-CommTxPoolExceptional, если они включены в SystemInformationBlockType21;

3> иначе, если v2x-CommTxPoolNormal или v2x-CommTxPoolExceptional включены в v2x-InterFreqInfoList для рассматриваемой частоты в SystemInformationBlockType21:

4> выполнить измерение CBR для пулов в v2x-CommTxPoolNormal и v2x-CommTxPoolExceptional в v2x-InterFreqInfoList для рассматриваемой частоты в SystemInformationBlockType21;

3> иначе, если соответствующая частота передает SystemInformationBlockType21:

4> выполнить измерение CBR для пулов в v2x-CommTxPoolNormalCommon и v2x-CommTxPoolExceptional, если они включены в широковещательную передачу SystemInformationBlockType21 на рассматриваемой частоте;

2> если UE находится в режиме RRC_CONNECTED:

3> если tx-ResourcePoolToAddList включен в VarMeasConfig:

4> выполнить измерения CBR для каждого пула ресурсов, указанного в tx-ResourcePoolToAddList;

3> если рассматриваемая частота является частотой PCell:

4> выполнить измерение CBR для пулов в v2x-CommTxPoolNormalDedicated или V2x-SchedulingPool, если они включены в RRCConnectionReconfiguration, v2x-CommTxPoolExceptional, если они включены в SystemInformationBlockType21 для рассматриваемой частоты и v2x-CommTxPoolExceptional, если они включены в mobilityControlInfoV2X;

3> иначе, если v2x-CommTxPoolNormal, v2x-SchedulingPool или v2x-CommTxPoolExceptional включены в v2x-InterFreqInfoList для рассматриваемой частоты в RRCConnectionReconfiguration:

4> выполнить измерение CBR для пулов в v2x-CommTxPoolNormal, v2x-SchedulingPool и v2x-CommTxPoolExceptional, если они включены в v2x-InterFreqInfoList для рассматриваемой частоты в RRCConnectionReconfiguration;

3> иначе, если SystemInformationBlockType21i широковещательно передается на рассматриваемой частоте:

4> выполнить измерение CBR для пулов в v2x-CommTxPoolNormalCommon и v2x-CommTxPoolExceptional, если они включены в SystemInformationBlockType21 для рассматриваемой частоты;

1> иначе:

2> выполнить измерение CBR для пулов в v2x-CommTxPoolList в SL-V2X-Preconfiguration для рассматриваемой частоты;

Примечание 3: В S-Measure определяет то, когда UE требуется выполнить измерения. Однако UE разрешено выполнять измерения также в том случае, когда RSRP PCell превышает s-Measure, например, для измерения сот, широковещательно передающих идентификатор CSG, после использования функции автономного поиска, как определено в TS 36.304[4].

Примечание 4: UE может не выполнить измерения WLAN, на которые оно сконфигурировано, например, из-за подключения к другой WLAN на основе предпочтений пользователя, как указано в TS 23.402[75], или из-за отключения WLAN.

3-е изменение

Инициирование отчета об измерениях

5.5.4.1. Общие положения

Если защита была успешно активирована, UE должно:

1> для каждого measId, включенного в список измерений в VarMeasConfig:

2> если соответствующий reportConfig включает в себя purpose, установленный в reportStrongestCellsForSON:

3> считать применимой любую соседнюю соту, обнаруженную на ассоциированной частоте;

2> иначе, если соответствующий reportConfig включает в себя purpose, установленный в reportCGI:

3> считать применимой любую соседнюю соту, обнаруженную на/в ассоциированной частоте/наборе частот (GERAN), которая/который имеет физический идентификатор соты, совпадающий со значением cellsForWhichToReportCGI, включенным в соответствующий measObject в VarMeasConfig;

2> иначе, если соответствующий reportConfig включает в себя purpose, установленный для reportLocation:

3> считать применимым только PCell;

2> иначе:

3> если соответствующий measObject относится к E-UTRA:

4> если UE-RxTxTimeDiffPeriodical будет сконфигурирован в ассоциированном reportConfig:

5> считать применимым только PCell;

4> иначе, если reportSSTD-Meas установлен на true в ассоциированном reportConfig:

5> считать применимым PSCell;

4> иначе, если eventA1 или eventA2 будет сконфигурирован в ассоциированном reportConfig:

5> считать применимой только обслуживающую соту;

4> иначе, если eventC1 или eventC2 будет сконфигурирован в ассоциированном reportConfig; или если reportStrongestCSI-RSs включен в соответствующий reportConfig:

5> считать применимым ресурс CSI-RS на ассоциированной частоте, когда рассматриваемый ресурс CSI-RS включен в measCSI-RS-ToAddModList, определенный в VarMeasConfig для этого measId;

4> иначе, если measRSSI-ReportConfig будет сконфигурирован в ассоциированном reportConfig:

5> считать применимым ресурс, указанный rmtc-Config на ассоциированной частоте;

4> иначе, если tx-ResourcePoolToAddList сконфигурирован в measObject:

5> считать применимыми пулы ресурсов передачи, указанные в tx-ResourcePoolToAddList, определенные в VarMeasConfig для этого measId;

4> иначе:

5> если useWhiteCellList установлен на TRUE:

6> считать, что любая соседняя сота, обнаруженная на ассоциированной частоте, применима тогда, когда соответствующая сота включена в whiteCellsToAddModList, определенный в VarMeasConfig для этого measId;

5> иначе:

6> считать, что любая соседняя сота, обнаруженная на ассоциированной частоте, применима тогда, когда рассматриваемая сота не включена в blackCellsToAddModList, определенный в VarMeasConfig для этого measId;

5> для событий, связанных с обслуживающей сотой на одной частоте и соседними сотами на другой частоте, рассматривать обслуживающую соту на другой частоте как соседнюю соту;

4> если соответствующий reportConfig включает в себя alternativeTimeToTrigger, и если UE поддерживает alternativeTimeToTrigger:

5> использовать значение alternativeTimeToTrigger в качестве времени для инициирования вместо значения timeToTrigger в ассоциированном reportConfig для сот, включенных в altTTT-CellsToAddModList соответствующего measObject;

3> иначе, если соответствующий measObject относится к UTRA или CDMA2000:

4> считать соседнюю соту на ассоциированной частоте применимой тогда, когда рассматриваемая сота включена в cellToAddModList, определенный в VarMeasConfig для этого measId (то есть сота включена в белый список);

Примечание 0: UE также может считать соседнюю соту на ассоциированной частоте UTRA применимой тогда, когда соответствующая сота включена в csg-allowReportingCells в VarMeasConfig для этого measId, если он сконфигурирован в рассматриваемом measObjectUTRA (то есть сота включена в диапазон идентификаторов физических сот, для которых разрешена отчетность).

3> иначе, если соответствующий measObject относится к GERAN:

4> считать соседнюю соту в ассоциированном наборе частот применимой тогда, когда рассматриваемая сота соответствует ncc-Permitted, определенному в VarMeasConfig для этого measId;

3> иначе, если соответствующий measObject относится к WLAN:

4> считать применимым WLAN в ассоциированном наборе частот, как указанный в carrierFreq или на всех частотах WLAN, когда отсутствует carrierFreq, если WLAN совпадает со всеми идентификаторами WLAN по меньшей мере одной записи в wlan-Id-List для этого measId;

3> иначе, если соответствующий measObject относится к NR:

2> если triggerType установлен на event, и если начальное условие, применяемое для этого события, то есть события, соответствующего eventId соответствующего reportConfig в VarMeasConfig, выполнено для одной или нескольких применяемых сот для всех измерений после фильтрации на уровне 3, выполненной в течение timeToTrigger, определенного для этого события в VarMeasConfig, в то время как VarMeasReportList не включает в себя запись отчетности измерений для этого measId (первая сота инициирует событие):

3> включить запись отчетности измерений в VarMeasReportList для этого measId;

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого measId, равным 0;

3> включить соответствующие соты в cellTriggeredList, определенный в VarMeasReportList для этого measId;

3> если UE поддерживает T312, и если useT312 включено для этого события, и если работает T310:

4> если T312 не работает:

5> запустить таймер T312 со значением, сконфигурированным в ассоциированном measObject;

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

2> если triggerType установлен на event, и если начальное условие, применяемое для этого события, то есть события, соответствующего eventId соответствующего reportConfig в VarMeasConfig, выполнено для одной или нескольких применяемых сот, не включенных в cellTriggeredList для всех измерений после фильтрации на уровне 3, выполненной в течение timeToTrigger, определенного для этого события в VarMeasConfig (последующая сота инициирует событие):

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого measId, равным 0;

3> включить соответствующие соты в cellTriggeredList, определенный в VarMeasReportList для этого measId;

3> если UE поддерживает T312, и если useT312 включено для этого события, и если работает T310:

4> если T312 не работает:

5> запустить таймер T312 со значением, сконфигурированным в ассоциированном measObject;

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

2> если triggerType установлен на event, и если конечное условие, применяемое к этому событию, выполнено для одной или нескольких сот, включенных в cellTriggeredList, определенный в VarMeasReportList для этого measId, для всех измерений после фильтрации на уровне 3, выполненной в течение timeToTrigger, определенного в VarMeasConfig для этого события:

3> удалить соответствующие соты из элемента cellTriggeredList, определенного в VarMeasReportList для этого measId;

3> если UE поддерживает T312, и если useT312 включен для этого события, и если работает T310:

4> если T312 не работает:

5> запустить таймер T312 со значением, сконфигурированным в ассоциированном measObject;

3> если reportOnLeave установлен на TRUE для соответствующей конфигурации отчетности, или если a6-ReportOnLeave установлен на TRUE для соответствующей конфигурации отчетности:

4> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

3> если cellTriggeredList, определенный в VarMeasReportList для этого measId, пуст:

4> удалить запись отчета об измерении в VarMeasReportList для этого measId;

4> остановить таймер периодической отчетности для этого measId, если он работает;

2> если triggerType установлен на event, и если начальное условие, применяемое для этого события, то есть события, соответствующего eventId соответствующего reportConfig в VarMeasConfig, выполнено для одного или нескольких применимых ресурсов CSI-RS для всех измерений после фильтрации на уровне 3, выполненной в течение timeToTrigger, определенного для этого события в VarMeasConfig, в то время как VarMeasReportList не включает в себя запись отчетности измерений для этого measId (то есть первый ресурс CSI-RS инициирует событие):

3> включить запись отчетности измерений в VarMeasReportList для этого measId;

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого параметра, равным 0;

3> включить рассматриваемый(е) ресурс(ы) CSI-RS в Csi-RS-TriggeredList, определенный в VarMeasReportList для этого measId;

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

2> если triggerType установлен на event, и если начальное условие, применяемое для этого события, то есть события, соответствующего eventId соответствующего reportConfig в VarMeasConfig, выполнено для одного или нескольких применимых ресурсов CSI-RS, не включенных в csi-RS-TriggeredList для всех измерений после фильтрации на уровне 3, выполненной в течение timeToTrigger, определенного для этого события в VarMeasConfig (то есть последующий ресурс CSI-RS инициирует событие):

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого параметра, равным 0;

3> включить соответствующий(е) ресурс(ы) CSI-RS в csi-RS-TriggeredList, определенный в VarMeasReportList для этого measId;

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

2> если triggerType установлен на event, и если конечное условие, применяемое для этого события, выполнено для одного или нескольких ресурсов CSI-RS, включенных в csi-RS-TriggeredList, определенный в VarMeasReportList для этого measId для всех измерений после фильтрации на уровне 3, выполненной в течение timeToTrigger, определенного в VarMeasConfig для этого события:

3> удалить рассматриваемые ресурсы CSI-RS из csi-RS-TriggeredList, определенного в VarMeasReportList для этого measId;

3> если c1-ReportOnLeave установлен на TRUE для соответствующей конфигурации отчетности или если c2-ReportOnLeave установлен на TRUE для соответствующей конфигурации отчетности:

4> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

3> если csi-RS-TriggeredList, определенный в VarMeasReportList для этого measId, пуст:

4> удалить запись отчетности измерений в VarMeasReportList для этого measId;

4> остановить таймер периодической отчетности для этого measId, если он работает;

2> если triggerType установлен на event, и если начальное условие, применяемое для этого события, то есть события, соответствующего eventId соответствующего reportConfig в VarMeasConfig, выполнено для одного или нескольких применяемых пулов ресурсов передачи для всех измерений, выполненных в течение timeToTrigger для этого события в VarMeasConfig, тогда как VarMeasReportList не включает запись отчета об измерении для этого measId (первый пул ресурсов передачи инициирует событие):

3> включить запись отчетности измерений в VarMeasReportList для этого measId;

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого параметра, равным 0;

3> включить рассматриваемый(е) пул(ы) ресурсов передачи в poolTriggeredList, определенный в VarMeasReportList для этого measId;

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

2> если triggerType установлен на event и начальное условие, применяемое для этого события, то есть события, соответствующего eventId соответствующего reportConfig в VarMeasConfig, выполнено для одного или нескольких применяемых пулов ресурсов передачи, не включенных в poolTriggeredList для всех измерений, выполненных в течение timeToTrigger, определенного для этого события в VarMeasConfig (последующий пул ресурсов передачи инициирует событие):

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого параметра, равным 0;

3> включить рассматриваемый(е) пул(ы) ресурсов передачи в poolTriggeredList, определенный в VarMeasReportList для этого measId;

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

2> если triggerType установлен на event, и если конечное условие, применяемое для этого события, выполнено для одного или нескольких применяемых пулов ресурсов передачи, включенных в poolTriggeredList, определенный в VarMeasReportList для этого measId, для всех измерений, выполненных в течение timeToTrigger, определенного в VarMeasConfig для этого события:

3> удалить рассматриваемый(е) пул(ы) ресурсов передачи из poolTriggeredList, определенного в VarMeasReportList для этого measId;

3> если poolTriggeredList, определенный в VarMeasReportList для этого measId, пуст:

4> удалить запись отчетности измерений из VarMeasReportList для этого measId;

4> остановить таймер периодической отчетности для этого measId, если он работает;

2> если measRSSI-ReportConfig будет включен, и если (первый) результат измерений доступен:

3> включить запись отчетности измерений в VarMeasReportList для этого measId;

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого параметра, равным 0;

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5, сразу после предоставления отчета о значениях выборки RSSI физическим уровнем после первой продолжительности измерения L1;

2> иначе, если purpose включен и установлен в reportStrongestCells, reportStrongestCellsForSON, reportLocation или sidelink, и если доступен (первый) результат измерений:

3> включить запись отчетности измерений в VarMeasReportList для этого measId;

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого measId, равным 0;

3> если purpose установлен на reportStrongestCells, и reportStrongestCSI-RSs не включен:

4> если triggerType установлен на periodical, и соответствующий reportConfig включает в себя ul-DelayConfig:

5> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5, сразу после того, как нижние уровни предоставят первый результат измерений;

4> иначе, если соответствующий объект измерения относится к WLAN:

5> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5, сразу после того, как предоставленный отчет о количестве станет доступным для PCell и для соответствующих WLAN;

4> иначе, если reportAmount превышает 1:

5> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5, сразу после того, как предоставленный отчет о количестве станет доступным для PCell;

4> иначе (то есть reportAmount равен 1):

5> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5, сразу после того, как предоставленный отчет о количестве станет доступным для PCell и для самой мощной соты среди применяемых сот, или станет доступным для пары PCell и PSCell в случае измерений SSTD или станет доступным для каждой пары PCell и соты NR в случае измерений SFTD;

3> иначе, если purpose установлен на reportLocation:

4> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5, сразу после того, как предоставленный отчет о количестве станет доступным для PCell, и станет доступной информация о местоположении;

3> иначе, если purpose установлен на sidelink:

4> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5, сразу после того, как будет предоставлен отчет о количестве для PCell и станет доступным результат измерения CBR;

3> иначе:

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

2> по истечении таймера периодической отчетности для этого measId:

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

2> если purpose включен и установлен в reportCGI, и если UE получило информацию, необходимую для установки всех полей cgi-Info для запрошенной соты:

3> включить запись отчетности измерений в VarMeasReportList для этого measId;

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого measId, равным 0;

3> остановить таймер T321;

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

2> по истечении T321 для этого measId:

3> включить запись отчетности измерений в VarMeasReportList для этого measId;

3> установить numberOfReportsSent, определенный в VarMeasReportList для этого measId, равным 0;

3> инициировать процедуру предоставления отчета об измерениях, как указано в 5.5.5;

Примечание 2: UE не прекращает периодическую отчетность с triggerType, установленным на event или periodical, в то время как соответствующее измерение не выполняется из-за того, что RSRP PCell равен или выше, чем s-Measure, или из-за того, что не установлен промежуток измерения.

Примечание 3: Если UE сконфигурировано с DRX, UE может задержать предоставление отчета об измерениях для инициированного события и периодически инициируемых измерений, до активного времени (Active Time), которое определено в TS 36.321[6].

4-е изменение

5.5.5. Предоставление отчета об измерениях

Назначение этой процедуры состоит в том, чтобы передать результаты измерений из UE в E-UTRAN. UE должно инициировать эту процедуру только после успешной активации безопасности.

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

1> установить measId на идентификатор измерения, который инициировал предоставление отчета об измерениях;

1> установить в MeasResultPCell количество PCell;

1> установить MeasResultservFreqList с тем, чтобы он включал в себя для каждой SCell E-UTRA, которая сконфигурирована, если таковая имеется, в MeasResultsCell количество соответствующих SCell, если они доступны в соответствии с требованиями к производительности, приведенными в [16], за исключением случаев, когда purpose для reportConfig, связанного с measId, который инициировал предоставление отчета об измерениях, установлен на reportLocation;

1> если reportConfig, ассоциированный с measId, который инициировал предоставление отчета об измерениях, включает в себя reportAddNeighMeas:

2> для каждой служебной частоты E-UTRA, для которой measObjectId упоминается в measIdList, кроме частоты, соответствующей measId, который инициировал предоставление отчета об измерениях:

3> установить measResultServFreqList с тем, чтобы measResultBestNeighCel включал в себя physCellId и количество лучших неслужебных сот, исходя из RSRP, на рассматриваемой служебной частоте;

1> если triggerType установлен на event; и если соответствующий measObject относится к NR; и если eventId установлен на eventB1 или eventB2; или

1> если triggerType установлен на event; и если eventId установлен на eventA3, или eventA4 или eventA5:

2> если purpose для reportConfig, ассоциированного с measId, который инициировал предоставление отчета об измерениях устанавливается в значение, отличное от reportLocation:

3> установить measResultServFreqListNR с тем, чтобы он включал в себя для каждой служебной частоты NR, если таковая имеется, следующее:

4> установить measResultsCell с тем, чтобы он включал в себя имеющиеся результаты относительно обслуживающей соты NR, если они соответствуют требованиям по производительности, приведенным в [16];

4> если reportConfig, ассоциированный с measId, который инициировал отчет об измерениях, включает в себя reportAddNeighMeas:

5> установить measureResultBestNeighCell с тем, чтобы он включал в себя имеющиеся результаты лучшей необслуживающей соты на основе RSRP;

5> для каждой (обслуживающей или соседней) соты, для которой UE предоставляет отчет, результаты согласно предыдущему дополнительно включают в себя имеющиеся результаты для луча согласно следующему:

6> если maxRS-IndexReport сконфигурирован, установить measResultCellRS-Index с тем, чтобы он включал в себя результаты до maxRS-IndexReport лучей, количество которых превышает threshRS-Index, определенный в VarMeasConfig для соответствующего measObject и в порядке убывания количества, аналогично используемому для отчетности соты, и следующим образом:

7> выбрать и установить очередность для лучей на основе количества отчетов, определенного в соответствии с 5.5.5.2;

TBCOrdering для лучей основан на принципах NR, которые отражены в TPR2-1801646:

7> включить ssbIndex;

7> если reportQuantityRS-IndexNR и reportRS-IndexResultsNR сконфигурированы, для каждого указанного количества включить соответствующий результат измерения;

В TBCWhether ввести такой же бит, как в NR, например, добавить, если сконфигурированы reportQuantityRS-IndexNR и reportRS-IndexResults

TBCReporting имеющихся результатов, основанных на принципах NR, отраженных в TPR2-1800951:

1> если имеется по меньшей мере одна применяемая соседняя сота для отчетности:

2> установить measResultNeighCells с тем, чтобы он включал в себя лучшие соседние соты вплоть до maxReportCells в соответствии со следующим:

3> если triggerType установлен на event:

4> включить соты, включенные в cellTriggeredList, как определено в VarMeasReportList для этого measId;

3> иначе:

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

Примечание 1: достоверность отчета (то есть уверенность в том, что содержит самые мощные соты на рассматриваемой частоте) зависит от конфигурации измерения то есть reportInterval. Соответствующие требования к производительности определены в TS 36.133 [16].

3> для каждой соты, которая включена в MeasureResultNeighCells, включить PhysCellId;

3> если triggerType установлен на event; или purpose установлен в reportStrongestCells или reportStrongestCellsForSON:

4> для каждой включенной соты, включить отфильтрованные результаты измерений на уровне 3 в соответствии с reportConfig для этого measId, упорядоченные следующим образом:

5> если measObject, ассоциированный с этим measId относится к E-UTRA:

6> установить measResult с тем, чтобы он включал в себя величину(ы), указанную(ые) в reportQuantity в рассматриваемом reportConfig в порядке убывания triggerQuantity, то есть лучшая сота включается в первую очередь;

5> если measObject, ассоциированный с этим measObject, относится к NR:

6> установить measResultCell с тем, чтобы он включал в себя величину(ы), указанную(ые) в reportQuantityCellNR в рассматриваемом reportConfig в порядке убывания количества в соответствии с Bn-ThresholdYNR, то есть лучшая сота включается в первую очередь;

6> если maxRS-IndexReport сконфигурирован, установить measResultCellRS-Index с тем, чтобы он включал в себя результаты вплоть до maxRS-IndexReport лучей, количество которых превышает threshRS-Index, определенный в VarMeasConfig для соответствующего measObject и в порядке убывания количества, аналогично используемому для отчетности соты, и следующим образом:

7> выбрать и определить очередность для лучей на основе количества отчетов, определенного в соответствии с 5.5.5.2;

TBCOrdering для лучей, основанных на принципах NR, как это отражено в TPR2-1801646:

7> включить ssbIndex;

7> если reportQuantityRS-IndexNR и reportRS-IndexResultsNR сконфигурированы, для каждого указанного количества включить соответствующий результат измерений;

В TBCWhether ввести такой же бит, как в NR, например, добавить его, если сконфигурированы reportQuantityRS-IndexNR и reportRS-IndexResults;

5> если measObject, ассоциированный с этим measId, относится к FDD UTRA, и если ReportConfigInterRAT включает в себя reportQuantityUTRA-FDD:

6> установить measResult с тем, чтобы он включал в себя величины, указанные в reportQuantityUTRA-FDD в порядке убывания measQuantityUTRA-FDD в quantityConfig, то есть лучшая сота включается в первую очередь;

5> если measObject, ассоциированный с этим measId, относится к FDD UTRA, и если ReportConfigInterRAT не включает в себя reportQuantityUTRA-FDD; или

5> если measObject, ассоциированный с этим измерением, относится к TDD UTRA, GERAN или CDMA2000:

6> установить measResult на количество, которое сконфигурировано для рассматриваемой RAT в quantityConfig либо в порядке убывания количества для UTRA и GERAN или либо в порядке возрастания количества для PilotStrength CDMA2000, то есть лучшая сота включается в первую очередь;

3> иначе, если purpose установлен на reportCGI:

4> если были получены обязательные присутствующие поля cgi-Info для соты, указанной в cellsForWhichToReportCGI в ассоциированном measObject:

5> если includeMultiBandInfo сконфигурирован:

6> включить freqBandIndicator;

6> если сота осуществляет широковещательную передачу в multiBandInfoList, включить multiBandInfoList;

6> если сота осуществляет широковещательную передачу в freqBandIndicatorPriority, включить freqBandIndicatorPriority;

5> если сота передает идентификатор CSG:

6> включить csg-Identity;

6> включить csg-MemberStatus и установить его на member, если сота является сотой-членом CSG;

5> если si-RequestForHO сконфигурирован в reportConfig, ассоциированном с этим measId:

6> включить cgi-Info, содержащий все поля, кроме plmn-IdentityList, которые были успешно получены;

6> включить, в CGI-info, поле PLMN-IdentityList в соответствии со следующим:

7> если сота является сотой-членом CSG, определить поднабор идентификаторов PLMN, начиная со второй записи идентификаторов PLMN в широковещательной информации, которые удовлетворяют следующим условиям:

а) они равны RPLMN или EPLMN; и

b) белый список CSG UE включает в себя запись, содержащую рассматриваемый идентификатор PLMN и идентификатор CSG, широковещательно передаваемый сотой;

7> если подмножество идентификаторов PLMN, определенных в соответствии с предыдущим, включает в себя по меньшей мере один идентификатор PLMN, включить plmn-IdentityList и установить его так, чтобы он включал в себя это подмножество идентификаторов PLMN;

7> если сота является сотой-членом CSG, включить primaryPLMN-Suitable, если первичная PLMN соответствует условиям a) и b), указанным выше;

5> иначе:

6> включить cgi-Info, содержащий все поля, которые были успешно получены и в соответствии со следующим:

7> включить в plmn-IdentityList список идентификаторов, начиная со второй записи идентификаторов PLMN в широковещательной информации;

1> для сот, включенных в соответствии с предыдущим (то есть охватывающих PCell, соты SCell, лучшие необслуживающие соты на служебных частотах, а также соседние соты EUTRA), включить результаты в соответствии с повышенным RSRQ, если соответствующие результаты доступны в соответствии с ассоциированными требованиями к производительности, определенные в 36.133[16];

1> если имеется по меньшей мере один применимый ресурс CSI-RS для отчета:

2> установить measResultCSI-RS-List с тем, чтобы он включал в себя лучшие ресурсы CSI-RS вплоть до maxReportCells в соответствии со следующим:

3> если triggerType установлен на event:

4> включить ресурсы CSI-RS, включенные в csi-RS-TriggeredList, как определено в VarMeasReportList для этого measId;

3> иначе:

4> включить применяемые ресурсы CSI-RS, для которых новые результаты измерений стали доступны с момента последнего периодического отчета или с момента инициирования или сброса измерения;

Примечание 2: достоверность отчета (то есть том, что он содержит самые мощные ресурсы CSI-RS на рассматриваемой частоте) зависит от конфигурации измерения то есть от reportInterval. Соответствующие требования к производительности определены в TS 36.133 [16].

3> для каждого ресурса CSI-RS, который включен в measResultCSI-RS-List:

4> включить measCSI-RS-Id;

4> включить отфильтрованные результаты измерений на уровне 3 в соответствии с reportConfig для этого measId, упорядоченные следующим образом:

5> установить csi-RSRP-Result с тем, чтобы он включал в себя количество, указанное в reportQuantity в рассматриваемом reportConfig, в порядке убывания triggerQuantity CSI-RS, то есть лучший ресурс CSI-RS включается в первую очередь;

4> если reportCRS-Meas включен в ассоциированный reportConfig, и сота, указанная в physCellId этого ресурса CSI-RS не является обслуживающей сотой:

5> установить measResultNeighCells с тем, чтобы он включал в себя соту, указанную в physCellId этого ресурса CSI-RS, и включал в себя physCellId;

5> установить rsrqResult с тем, чтобы он включал в себя RSRP рассматриваемой соты, если она имеется в соответствии с требованиями к производительности в [16];

5> установить rsrqResult с тем, чтобы он включал в себя RSRQ рассматриваемой соты, если оно имеется в соответствии с требованиями к производительности в [16];

1> если ue-RxTxTimeDiffPeriodical сконфигурирован в ассоциированном reportConfig для этого measId;

2> установить для ue-RxTxTimeDiffResult результат измерения, предоставленный нижними уровнями;

2> установить currentSFN;

1> если measRSSI-ReportConfig сконфигурирован в ассоциированном reportConfig для этого measId:

2> установить rssi-Result на среднее(ие) выборочное(ые) значение(я), предоставленное(ые) нижними уровнями в reportInterval;

2> установить channelOccupancy на округленные значения выборок в процентах, которые находятся вне channelOccupancyThreshold в пределах всех значений выборок в reportInterval;

1> если имеются результаты по задержке PDCP восходящей линии связи:

2> установить ul-PDCP-DelayResultList с тем, чтобы он включал в себя имеющиеся результаты по задержке PDCP восходящей линии связи;

1> если includeLocationInfo сконфигурирован в ассоциированном reportConfig для этого measId, или если purpose для reportConfig, ассоциированного с measId, который инициировал предоставление отчета об измерениях, установлен на reportLocation; и имеется подробная информация о местоположении, о которой не был предоставлен отчет, установить содержание locationInfo следующим образом:

2> включить координаты местоположения locationCoordinates;

2> если таковые имеются, включить gnss-TOD-msec, за исключением того, если purpose для reportConfig, ассоциированного с measId, который инициировал предоставление отчета об измерениях, установлен в reportLocation;

1> если reportSSTD-Meas установлен на true или pSCell в ассоциированном reportConfig для этого measId:

2> установить measResultSSTD в результаты измерений, предоставленные нижними уровнями;

5-е изменение

6.3.5. Информационные элементы измерений

<пропущенный текст>

MeasResults

IE MeasResults охватывает результаты измерений для внутричастотной и межчастотной мобильности и мобильности интер-RAT.

Информационный элемент MeasResults

Описание полей MeasResults
availableAdmissionCapacityWLAN
Указывает доступную допустимую пропускную способность WLAN, как определено в IEEE 802.11-2012[67].
backhaulDL-BandwidthWLAN
Указывает доступную полосу пропускания нисходящей линии связи WLAN, равную скорости передачи данных нисходящей линии связи, умноженной на нагрузку нисходящей линии связи, определенную в Wi-Fi Alliance Hotspot 2.0[76].
backhaulUL-BandwidthWLAN
Указывает доступную полосу пропускания восходящей линии связи транспортной сети WLAN, равную скорости передачи данных нисходящей линии связи, умноженной на нагрузку восходящей линии связи, определенной в Wi-Fi Alliance Hotspot 2.0[76].
bandWLAN
Указывает диапазон WLAN.
carrierInfoWLAN
Указывает информацию о канале WLAN.
cbr-PSSCH
Указывает результаты измерения CBR по PSSCH пула, указанного poolIdentity. Если adjacencyPSCCH-PSSCH установлен на true для пула, указанного в poolIdentity, это поле указывает измерение CBR как ресурсов PSSCH, так и ресурсов PSCCH, которые измеряются вместе.
cbr-PSCCH
Указывает результаты измерений CBR по PSCCH в пуле, указанном poolIdentity. Это поле включается только в том случае, если adjacencyPSCCH-PSSCH установлен на FALSE для пула, указанного параметром pooIIdentity.
channelOccupancy
Указывает процент выборок, когда RSSI был выше сконфигурированного channelOccupancyThreshold для ассоциированного reportConfig.
channelUtilizationWLAN
Указывает использование канала WLAN, как определено в IEEE 802.11-2012[67].
connectedWLAN
Указывает то, подключено ли UE к WLAN, для которой применимы результаты измерений.
csg-MemberStatus
Указывает то, является ли UE членом CSG соседней соты.
currentSFN
Указывает номер текущего системного кадра при приеме результатов измерения разницы во времени Rx-Тх UE с нижнего уровня.
excessDelay
Указывает избыточное отношение задержки очередности в UL, в соответствии с таблицей отображения отчета измерения избыточного отношения задержки, как определено в TS 36.314[71, таблица 4.2.1.1.1-1]
locationAreaCode
Код фиксированной длины, идентифицирующий область местоположения в PLMN, как определено в TS 23.003[27].
measId
Идентифицирует идентификационные данные измерения, для которого выполняется отчетность. Если measId-v1250 включен, то measId (то есть без суффикса) игнорируется eNB.
measResult
Результат измерений соты E-UTRA;
Результат измерений соты UTRA;
Результат измерений соты или частоты GERAN;
Результат измерений соты CDMA2000;
Результат измерений WLAN;
Результат измерений разницы во времени Rx-Tx UE;
Результат измерений SFN UE, разницы во времени синхронизации радиокадров и подкадров; или
Результат измерений RSSI и занятость канала.
measResultCSI-RS-List
Результаты измерений с ресурсами CSI-RS в сигналах обнаружения измерения.
measResultListCDMA2000
Список результатов измерений для максимального числа зарегистрированных лучших сот для идентификационных данных измерения CDMA2000.
measResultListEUTRA
Список результатов измерений для максимального числа зарегистрированных лучших сот для идентификационных данных измерения E-UTRA. Для UE BL или UE в CE, при работе в режиме CE Mode B, отчет о measureResult-v1360 предоставляется в том случае, если измеренное значение RSRP составляет менее -140 дБм.
measResultListGERAN
Список результатов измерений для максимального числа зарегистрированных лучших сот или частот для идентификационных данных измерения GERAN.
measResultListUTRA
Список результатов измерений для максимального числа зарегистрированных лучших сот для идентификационных данных измерения UTRA.
measResultListWLAN
Список результатов измерений для максимального количества предоставленных отчетов о лучших WLAN за пределами набора мобильности WLAN и подключенной WLAN, если таковые имеются, для идентификационных данных измерения WLAN.
measResultPCell
Результат измерений PCell. Для UE BL или UE в CE, при работе в режиме CE Mode B, отчет о measResultPCell-v1360 предоставляется в том случае, если измеренное значение RSRP составляет менее -140 дБм.
measResultsCDMA2000
Содержит состояние предварительной регистрации HRPD CDMA2000 и список измерений CDMA2000.
MeasResultServFreqList
Результаты измерений служебных частот: результат измерений каждой соты SCell, если таковые имеются, и наилучшей соседней соты на каждой служебной частоте. Для UE BL или UE в CE, при работе в режиме CE Mode B, отчет о measResultBestNeighCell-v1360 предоставляется в том случае, если измеренное значение RSRP меньше -140 дБм.
pilotPnPhase
Указывает время прибытия пилот-сигнала CDMA2000, измеренное относительно временной привязки UE в единицах PN-чипов, смотри C.S0005 [25]. Эта информация используется в любой передаче обслуживания SRVCC или усовершенствованной процедуре обратной связи CS 1xRTT для 1xRTT CDMA2000.
PilotStrength
Интенсивность пилот-сигнала CDMA2000, отношение мощности пилот-сигнала к общей мощности в полосе пропускания сигнала прямого канала CDMA2000. Смотри C.S0005[25] для 1xRTT CDMA2000 и C.S0024[26] для HRPD CDMA2000.
рoolIdentity
Идентификационные данные пула ресурсов передачи, который соответствует poolReportId, сконфигурированному в пуле ресурсов для связи по боковой линии связи V2X.
plmn-IdentityList
Список идентификационных данных PLMN, считанных из широковещательной информации при широковещательной передаче идентификационных данных PLMN.
preRegistrationStatusHRPD
Установить в true, если UE на данный момент предварительно зарегистрировано в CDMA2000 HRPD. В противном случае, установить на FALSE. Это может быть проигнорировано eNB для 1xRTT CDMA2000.
qci-Id
Указывает значение QCI, для которого предоставляется excessDelay, в соответствии с TS 36.314[71].
routingAreaCode
Идентификационные данные RAC считывается из широковещательной информации, как определено в TS 23.003[27].
rsrpResult
Результат измерений RSRP соты E-UTRA.
Отчет о rsrqResult предоставляется только в том случае, если он сконфигурирован eNB.
rsrpResult
Результат измерений RSRQ соты E-UTRA.
Отчет о rsrqResult предоставляется только в том случае, если сконфигурирован eNB.
rssi
RSSI несущей GERAN. RXLEV отображается в значение от 0 до 63, TS 45.008[28]. При отображении значения RXLEV в битовую строку RSSI первый/крайний левый бит битовой строки содержит старший значащий бит.
rssi-Result
Результат измерений RSSI в дБм.
Rs-sinr-Result
Результат измерений RS-SINR соты E-UTRA или NR. Отчет о результате rs-sinr-Result предоставляется только в том случае, если он сконфигурирован eNB.
rssiWLAN
Результат измерений RSSI WLAN в дБм.
stationCountWLAN
Указывает общее количество станций, ассоциированных на данный момент с этой WLAN, как определено в IEEE 802.11-2012[67].
ue-RxTxTimeDiffResult
Результат измерений разницы во времени Rx-Tx UE PCell, предоставленный нижними уровнями. Если ue-RxTxTimeDiffPeriodicalTDD-r13 установлен на TRUE, отображение измерения соответствует отображению отчета о разнице во времени Rx-Tx UE TDD EUTRAN в TS 36.133[16], и результат измерений включает в себя NTAoffset, иначе отображение измерения соответствует отображению отчета о разнице во времени Rx-Tx UE TDD EUTRAN в TS 36.133[16].
utra-EcN0
Согласно CPICH_Ec/No в TS 25.133[29] для FDD.
Четырнадцать запасных значений. Поле отсутствует для TDD.
utra-RSCP
Согласно CPICH_RSCP в TS 25.133[29] для FDD и P-CCPCH_RSCP в TS 25.123[30] для TDD. Тридцать одно запасное значение.
wlan-Identifiers
Указывает параметры WLAN, используемые для идентификации WLAN, для которой применимы результаты измерений.

MeasResultSSTD

IE MeasResultSSTD состоит из SFN, различия границ радиокадров и подкадров между PCell и PSCell, как указано в TS 36.214[48] и TS 36.133[16].

Информационный элемент MeasResultSSTD

Описание полей MeasResultSSTD
SFN-OffsetResult
Указывает различие SFN между PCell и PSCell в виде целочисленного значения в соответствии с TS 36.214[48].
frameBoundaryOffsetResult
Указывает различие границ кадров между PCell и PSCell в виде целочисленного значения в соответствии с TS 36.214[48].
subframeBoundaryOffsetResult
Указывает различие границ радиокадра между PCell и PSCell в виде целочисленного значения в соответствии с таблицей отображения в TS 36.133[16].

MeasResultSFTD

IE MeasResultSFTD состоит из SFN и различия границ радиокадров между PCell и PSCell NR или набором сот, как указано в TS 36.214[48] и TS 36.133[16].

Информационный элемент MeasResultSFTD

<пропущенный текст>

- ReportConfigInterRAT

IE ReportConfigInterRAT точно определяет критерии для инициирования события предоставления отчета о результатах измерений интер-RAT. События предоставления отчетов о результатах измерений интер-RAT для NR, UTRAN, GERAN и CDMA2000 помечаются как BN, где N равно 1, 2 и т.д. События предоставления отчетов о результатах измерений интер-RAT для WLAN помечаются как WN, где N равно 1, 2 и т.д.

Событие B1: Уровень сигнала соседней соты становится выше порога;

Событие B2: PCell становится хуже, чем абсолютный threshold1, и сосед становится лучше, чем другой абсолютный threshold2.

Событие W1: WLAN становится лучше, чем порог;

Событие W2: все WLAN внутри набора мобильности WLAN становятся хуже, чем threshold1, и WLAN вне набора мобильности WLAN становится лучше, чем threshold2;

Событие W3: все WLAN внутри набора мобильности WLAN становятся хуже порога.

Пороги событий b1 и b2 для CDMA2000 представляют собой пороги обнаружения пилот-сигналов CDMA2000, которые выражаются в виде двоичного числа без знака, равные [-2 x 10 log 10 Ec/Io] в единицах 0,5 дБ, для получения более подробной информации смотри C.S0005 [25].

Информационный элемент ReportConfigInterRAT

Описание полей ReportConfigInterRAT
availableAdmissionCapacityRequestWLAN
Значение true указывает, что UE должно включать, если она доступна, доступную пропускную способность WLAN в отчеты об измерениях.
backhaulDL-BandwidthRequestWLAN
Значение true указывает, что UE должно включать, если она доступна, полосу пропускания нисходящей линии связи WLAN в отчеты об измерениях.
backhaulUL-BandwidthRequestWLAN
Значение true указывает, что UE должно включать, если она доступна, полосу пропускания восходящей линии связи WLAN в отчеты об измерениях.
bandRequestWLAN
Значение true указывает, что UE должно включать полосу WLAN в отчеты об измерениях.
Bn-ThresholdM
Порог, который должен использоваться в условии запуска отчета об измерениях интер-RAT для номера bN события. Если для номера события bN определено несколько порогов, то пороги дифференцируются по M.
carrierInfoRequestWLAN
Значение true указывает, что UE должно включать, если она доступна, информацию о несущей WLAN в отчеты об измерениях.
channelUtilizationRequest-WLAN
Значение true указывает, что UE должно включать, если это доступно, использование канала WLAN в отчеты об измерениях.
eventId
Выбор критериев отчетности по событиям интер-RAT.
maxReportCells
Максимальное количество сот, исключая обслуживающую соту, для включения в отчет об измерениях. В случае, если purpose установлен на reportStrongestCellsForSON, применяется только значение 1. Для интер-RAT WLAN это максимальное количество WLAN предназначено для включения в отчет об измерениях.
Purpose
reportStrongestCellsForSON применяется только в том случае, если reportConfig связан с measObject, установленным на measObjectUTRA или measObjectCDMA2000.
reportAmount
Количество отчетов об измерениях, применяемых для triggerType event, а также для triggerType periodical. В случае, если purpose установлен на reportCGI или reportStrongestCellsForSON, то применяется только значение 1. Если reportSSTD-Meas сконфигурирован, то применяется только значение 1.
reportAnyWLAN
Указывает, что UE предоставляет отчет о любой AP WLAN, удовлетворяющей требованиям запуска, даже если она не включена в соответствующий MeasObjectWLAN.
reportOnLeave
Указывает, должно или нет UE инициировать процедуру предоставления отчета об измерениях, когда выполняется условие выхода для соты в cellTriggeredList, как указано в 5.5.4.1.
reportQuantityUTRA-FDD
Это величины, которые будут включены в отчет об измерениях UTRA. Значения both означают, что оба значения RSCP CPICH, и величины EcN0 CPICH должны быть включены в отчет об измерениях.
reportSFTD-Meas
Если это поле установлено на pSCell, то UE должно измерить SSTD между PCell и PSCell, как указано в TS 36.214[48]. Если поле установлено на neighborCells, UE должно измерить SFTD между сотами PCell и NR, как указано в TS 36.214[48]. E-UTRAN включает это поле только при установке triggerType на periodical, и purpose на reportStrongestCells. Если это включено, UE должно игнорировать поля triggerType и maxReportCells.
si-RequestForHO
Поле применяется к функциональности reportCGI, и когда поле включено, UE разрешается использовать автономные промежутки при получении системной информации из соседней соты, применяет другое значение для T321 и включает разные поля в отчет об измерениях.
stationCountRequestWLAN
Значение true указывает, что UE должно включать, если это доступно, количество станций WLAN в отчетах об измерениях.
b1-ThresholdGERAN, b2-Threshold2GERAN
Фактическим значением является значение поля -110 дБм.
b1-ThresholdUTRA, b2-Threshold2UTRA
utra-RSCP соответствует CPICH_RSCP в TS 25.133[29] для FDD и P-CCPCH_RSCP в TS 25.123[30] для TDD. utra-EcN0 соответствует CPICH_Ec/No в TS 25.133 [29] для FDD и не применяется для TDD.
Для utra-RSCP: фактическим значением является значение поля -115 дБм.
Для utra-EcN0: фактическое значение равно (значение поля -49)/2 дБ.
timeToTrigger
Время, в течение которого необходимо выполнить определенные критерии для события, чтобы инициировать отчет об измерениях.
TriggerType
E-UTRAN не конфигурирует значение periodical в случае, если reportConfig связан с measObject, установленным на measObjectWLAN.
Условное присутствие Объяснение
reportCGI Поле является необязательным, необходимо ИЛИ, если purpose включен и установлен на reportCGI; в противном случае поле отсутствует, и UE должно удалить любое существующее значение для этого поля.

Хотя предмет изобретения, описанный в данном документе, может быть реализован в любой системе подходящего типа с использованием любых подходящих компонентов, раскрытые в данном документе варианты осуществления описаны в отношении беспроводной сети, такой, например, как беспроводная сеть, показанная на фиг. 3. Для упрощения беспроводная сеть, показанная на фиг. 3, изображает только сеть 306, сетевые узлы 360 и 360b и WD 310, 310b и 310c. На практике беспроводная сеть может дополнительно включать в себя любые дополнительные элементы, подходящие для поддержания связи между беспроводными устройствами или между беспроводным устройством и другим устройством связи, таким как стационарный телефон, поставщик услуг или любой другой сетевой узел или терминальное устройство. Из проиллюстрированных компонентов сетевой узел 360 и беспроводное устройство (WD) 310 изображены с дополнительными подробностями. Беспроводная сеть может предоставлять связь и другие типы услуг одному или нескольким беспроводным устройствам для облегчения доступа беспроводных устройств к беспроводной сети и/или для использования услуг, предоставляемых беспроводной сетью или посредством нее.

Беспроводная сеть может содержать и/или взаимодействовать с любым типом сети связи, телекоммуникационной сети, сети передачи данных, сети сотовой и/или радиосвязи или с другим аналогичным типом системы. В некоторых вариантах осуществления беспроводная сеть может быть выполнена с возможностью функционирования в соответствии с конкретными стандартами или другими типами заданных правил или процедур. Таким образом, конкретные варианты осуществления беспроводной сети позволяют реализовать стандарты связи, такие как глобальная система мобильной связи (GSM), универсальная система мобильной связи (UMTS), LTE и/или другие подходящие стандарты 2G, 3G, 4G или 5G; стандарты беспроводной локальной вычислительной сети (WLAN), такие как стандарты IEEE 802.11; и/или любые другие соответствующие стандарты беспроводной связи, такие как стандарты всемирной совместимости для микроволнового доступа (WiMax), Bluetooth, Z-Wave и/или ZigBee. Однако в некоторых предпочтительных вариантах осуществления беспроводная сеть выполнена с возможностью функционирования в соответствии со стандартом 5G 3GPP, который упоминается как NR, как обсуждалось выше.

Сеть 306 может содержать одну или несколько транспортных сетей, базовых сетей, IP-сетей, коммутируемых телефонных сетей общего пользования (PSTN), сетей пакетной передачи данных, оптических сетей, глобальных вычислительных сетей (WAN), локальных вычислительных сетей (LAN), беспроводных локальных вычислительных сетей (WLAN), проводных сетей, беспроводных сетей, городских сетей и других сетей, обеспечивающих связь между устройствами.

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

Используемый в данном документе термин "сетевой узел" относится к оборудованию, способному, сконфигурированному, расположенному и/или выполненному с возможностью поддержания прямой или косвенной связи с беспроводным устройством и/или с другими сетевыми узлами или оборудованием в беспроводной сети, чтобы разрешить и/или обеспечить беспроводной доступ к беспроводному устройству и/или выполнять другие функции (например, администрирование) в беспроводной сети. Примеры сетевых узлов включают в себя, но не ограничиваются ими, точки доступа (AP) (например, точки радиодоступа), базовые станции (BS) (например, базовые радиостанции, узлы B, развитые узлы B (eNB) и gNB). Базовые станции можно классифицировать по размеру покрытия, которое они обеспечивают (или, иначе говоря, по их уровню мощности передачи), и в дальнейшем они могут также упоминаться как фемто-базовые станции, пико-базовые станции, микро-базовые станции или макро-базовые станции. Базовая станция может быть ретрансляционным узлом или донорским ретрансляционным узлом, управляющим ретранслятором. Сетевой узел может также включать в себя одну или несколько (или все) части распределенной базовой радиостанции, такие как централизованные цифровые блоки и/или удаленные радиоблоки (RRU), иногда называемые удаленными радиоголовками (RRH). Такие удаленные радиоблоки могут или не могут быть интегрированными с антенной в виде антенны с интегрированным радиомодулем. Части распределенной базовой радиостанции также могут называться узлами в распределенной антенной системе (DAS). Еще одни дополнительные примеры сетевых узлов включают в себя оборудование многостандартной радиосвязи (MSR), такое как BS MSR, сетевые контроллеры, такие как контроллеры радиосети (RNC) или контроллеры базовых станций (BSC), базовые приемопередающие станции (BTS), точки передачи, узлы передачи, объекты многосотовой/многоадресной координации (MCE), узлы базовой сети (например, MSC, MME), узлы O&M, узлы OSS, узлы (SON), узлы позиционирования (например, E-SMLC) и/или узлы MDT. В качестве другого примера, сетевой узел может быть узлом виртуальной сети, как описано более подробно ниже. Однако, в более общем случае, сетевые узлы могут представлять собой любое подходящее устройство (или группу устройств), способное, сконфигурированное, расположенное и/или выполненное с возможностью разрешения и/или предоставления беспроводному устройству доступа к беспроводной сети или предоставления некоторой услуги беспроводному устройству, которое получило доступ к беспроводной сети.

На фиг. 3 сетевой узел 360 включает в себя схему 370 обработки, машиночитаемый носитель 380 информации, интерфейс 390, вспомогательное оборудование 384, источник 386 электропитания, схему 387 электропитания и антенну 362. Хотя сетевой узел 360, проиллюстрированный в примере беспроводной сети, показанной на фиг. 3, может представлять собой устройство, которое включает в себя проиллюстрированную комбинацию аппаратных компонентов, другие варианты осуществления могут содержать сетевые узлы с различными комбинациями компонентов. Следует понимать, что сетевой узел содержит любую подходящую комбинацию аппаратных средств и/или программного обеспечения, необходимую для выполнения задач, особенностей, функций и способов, раскрытых в данном документе. Более того, хотя компоненты сетевого узла 360 изображены в виде отдельных блоков, расположенных в большем блоке или вложенных в несколько блоков, на практике сетевой узел может содержать несколько разных физических компонентов, которые образуют один проиллюстрированный компонент (например, машиночитаемый носитель 380 информации может содержать несколько отдельных жестких дисков, а также многочисленные модули RAM).

Аналогичным образом, сетевой узел 360 может состоять из нескольких физически отдельных компонентов (например, из компонента узла B (NodeB) и компонента RNC или компонента BTS и компонента BSC и т.д.), каждый из которых может иметь свои собственные соответствующие компоненты. В некоторых сценариях, в которых сетевой узел 360 содержит несколько отдельных компонентов (например, компоненты BTS и BSC), один или несколько отдельных компонентов могут совместно использоваться несколькими узлами сети. Например, один RNC может управлять несколькими NodeB. В таком сценарии каждая уникальная пара из NodeB и RNC в некоторых случаях может рассматриваться в качестве одного отдельного сетевого узла. В некоторых вариантах осуществления сетевой узел 360 может быть выполнен с возможностью поддержания множества технологий радиодоступа (RAT). В таких вариантах осуществления некоторые компоненты могут дублироваться (например, отдельный машиночитаемый носитель 380 информации для различных RAT), и некоторые компоненты могут использоваться повторно (например, одна и та же антенна 362 может совместно использоваться различными RAT). Сетевой узел 360 может также включать в себя множество наборов различных проиллюстрированных компонентов для различных беспроводных технологий, интегрированных в сетевой узел 360, таких, например, как технологии беспроводной связи GSM, WCDMA, LTE, NR, Wi-Fiили Bluetooth. Эти технологии беспроводной связи могут быть интегрированы в одну или разные микросхемы или набор микросхем и другие компоненты в сетевом узле 360.

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

Схема 370 обработки может содержать комбинацию одного или более из: микропроцессора, контроллера, микроконтроллера, центрального процессорного устройства, процессора цифровых сигналов, специализированной интегральной микросхемы, программируемой пользователем вентильной матрицы или любого другого подходящего вычислительного устройства, ресурса или комбинации аппаратных средств, программного обеспечения и/или кодированной логики, выполненной с возможностью обеспечения, по отдельности или в сочетании с другими компонентами сетевого узла 360, такими как машиночитаемый носитель 380 информации, функциональных возможностей сетевого узла 360. Например, схема 370 обработки может исполнять инструкции, хранящиеся на машиночитаемом носителе 380 информации или в памяти в схеме 370 обработки. Такие функциональные возможности могут включать в себя обеспечение любых из различных беспроводных особенностей, функций или преимуществ, обсужденных в данном документе. В некоторых вариантах осуществления схема 370 обработки может включать в себя систему на кристалле (SOC).

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

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

Машиночитаемый носитель 380 информации может содержать любую форму энергозависимой или энергонезависимой машиночитаемой памяти, включая, помимо прочего, постоянное хранилище, твердотельное запоминающее устройство, удаленно установленную память, магнитные носители информации, оптические носители информации, оперативное запоминающее устройство (RAM), постоянное запоминающее устройство (ROM), массовый носитель информации (например, жесткий диск), съемный носитель информации (например, флэш-диск, компакт-диск (CD) или цифровой видеодиск (DVD)) и/или любые другие энергозависимые или энергонезависимые невременные машиночитаемые и/или машиноисполняемые запоминающие устройства, которые хранят информацию, данные и/или инструкции, которые могут использоваться схемой 370 обработки. Машиночитаемый носитель 380 информации может хранить любые подходящие инструкции, данные или информацию, в том числе компьютерную программу, программное обеспечение, приложение, включающее в себя одну или несколько логических схем, правил, кодов, таблиц и т.д. и/или других инструкций, которые могут исполняться схемой 370 обработки и использоваться сетевым узлом 360. Машиночитаемый носитель 380 информации может использоваться для хранения любых вычислений, выполненных схемой 370 обработки, и/или любых данных, принятых через интерфейс 390. В некоторых вариантах осуществления схема 370 обработки и машиночитаемый носитель 380 информации могут рассматриваться как интегрированные.

Интерфейс 390 используется в проводной или беспроводной передаче сигнализации и/или данных между сетевым узлом 360, сетью 306 и/или WD 310. Как показано, интерфейс 390 содержит порт(ы)/терминал(ы) 394 для отправки и приема данных, например, в и из сети 306 по проводному соединению. Интерфейс 390 также включает в себя схему 392 радиочастотного тракта, которая может быть подключена к антенне 362 или, в некоторых вариантах, может быть частью антенны 362. Схема 392 радиочастотного тракта содержит фильтры 398 и усилители 396. Схема 392 радиочастотного тракта может быть подключена к антенне 362 и к схеме 370 обработки радиосигнала. Схема радиочастотного тракта может быть выполнена с возможностью обработки сигналов, передаваемых между антенной 362 и схемой 370 обработки. Схема 392 радиочастотного тракта может принимать цифровые данные, которые должны быть отправлены в другие узлы сети или WD через беспроводное соединение. Схема 392 радиочастотного тракта может преобразовывать цифровые данные в радиосигнал, имеющий соответствующие параметры канала и полосу пропускания, используя комбинацию фильтров 398 и/или усилителей 396. Затем радиосигнал может передаваться через антенну 362. Аналогичным образом, при приеме данных антенна 362 может принимать радиосигналы, которые затем преобразуются в цифровые данные с помощью схемы 392 радиочастотного тракта. Цифровые данные могут передаваться в схему 370 обработки. В других вариантах осуществления интерфейс может содержать различные компоненты и/или различные комбинации компонентов.

В некоторых альтернативных вариантах осуществления сетевой узел 360 может не включать в себя отдельные схемы 392 радиочастотного тракта; вместо этого схема 370 обработки может содержать схему радиочастотного тракта и может быть подключена к антенне 362 без отдельной схемы 392 радиочастотного тракта. Аналогичным образом, в некоторых вариантах осуществления все или некоторые из схем 372 РЧ приемопередатчика могут рассматриваться как часть интерфейса 390. В еще одних вариантах осуществления интерфейс 390 может включать в себя один или несколько портов или терминалов 394, схему 392 радиочастотного тракта и схему 372 РЧ приемопередатчика как часть радиоблока (не показан), и интерфейс 390 может поддерживать связь со схемой 374 обработки основополосных сигналов, которая является частью цифрового устройства (не показано).

Антенна 362 может включать в себя одну или несколько антенн или антенных решеток, выполненных с возможностью отправки и/или приема сигналов беспроводной связи. Антенна 362 может быть подключена к схеме 390 радиочастотного тракта и может быть антенной любого типа, способной передавать и принимать данные и/или сигналы беспроводным образом. В некоторых вариантах осуществления антенна 362 может содержать одну или несколько всенаправленных, секторных или панельных антенн, выполненных с возможностью передачи/приема радиосигналов, например, между 2 ГГц и 66 ГГц. Всенаправленная антенна может использоваться для передачи/приема радиосигналов в любом направлении, секторная антенна может использоваться для передачи/приема радиосигналов из устройств в конкретной области, и панельная антенна может быть антенной прямой видимости, используемой для передачи/приема радиосигналов по относительно прямой линии. В некоторых случаях использование более чем одной антенны может упоминаться как MIMO. В некоторых вариантах осуществления антенна 362 может быть расположена отдельно от сетевого узла 360 и может быть подключена к сетевому узлу 360 через интерфейс или порт.

Антенна 362, интерфейс 390 и/или схема 370 обработки могут быть выполнены с возможностью выполнения любых операций приема и/или некоторых операций получения, описанных в данном документе, которые выполняет сетевой узел. Любая информация, данные и/или сигналы могут быть приняты из беспроводного устройства, другого сетевого узла и/или любого другого сетевого оборудования. Аналогичным образом, антенна 362, интерфейс 390 и/или схема 370 обработки могут быть выполнены с возможностью выполнения любых операций передачи, описанных в данном документе, которые выполняет сетевой узел. Любая информация, данные и/или сигналы могут передаваться в беспроводное устройство, другой сетевой узел и/или любое другое сетевое оборудование.

Схема 387 электропитания может содержать или быть подключена к схеме управления электропитанием и выполнена с возможностью подачи питания на компоненты сетевого узла 360 для выполнения функций, описанных в данном документе. Схема 387 электропитания может принимать энергию из источника 386 электропитания. Источник 386 электропитания и/или схема 387 электропитания могут быть выполнены с возможностью подачи питания на различные компоненты сетевого узла 360 в виде, подходящем для соответствующих компонентов (например, на уровне напряжения и тока, необходимом для каждого соответствующего компонента). Источник 386 электропитания может быть включен в схему 387 и/или сетевой узел 360 или может быть внешним по отношению к ней. Например, сетевой узел 360 может быть подключен к внешнему источнику электропитания (например, к электрической розетке) через входную схему или интерфейс, такой как электрический кабель, посредством которого внешний источник электропитания подает питание на схему 387 электропитания. В качестве дополнительного примера источник 386 электропитания может содержать источник электропитания в виде аккумуляторной батареи или аккумуляторного блока, который подключен или встроен в схему 387 электропитания. Аккумуляторная батарея может обеспечивать резервное питание в случае отказа внешнего источника электропитания. Могут также использоваться и другие типы источников электропитания, такие как фотоэлектрические устройства.

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

Используемый в данном документе термин "беспроводное устройство (WD)" относится к устройству, способному, сконфигурированному, расположенному и/или выполненному с возможностью поддержания беспроводной связи с сетевыми узлами и/или другими беспроводными устройствами. Если не указано иное, термин "WD" может использоваться в данном документе взаимозаменяемо с пользовательским оборудованием (UE). Беспроводная связь может включать передачу и/или прием сигналов беспроводной связи с использованием электромагнитных волн, радиоволн, инфракрасных волн и/или других типов сигналов, подходящих для передачи информации в воздушной среде. В некоторых вариантах осуществления WD может быть выполнено с возможностью передачи и/или приема информации без прямого взаимодействия с человеком. Например, WD может быть предназначено для передачи информации в сеть по заранее определенному расписанию, когда оно запускается внутренним или внешним событием или в ответ на запросы из сети. Примеры WD включают в себя, но не ограничиваются ими, смартфон, мобильный телефон, сотовый телефон, телефон с передачей голоса по IP (VoIP), телефон беспроводного абонентского доступа, настольный компьютер, персональный цифровой помощник (PDA), беспроводные камеры, игровую приставку или устройство, устройство для хранения музыки, устройство воспроизведения, носимое терминальное устройство, беспроводную оконечную точку, мобильную станцию, планшетный компьютер, ноутбук, оборудование, встроенное в портативный компьютер (LEE), оборудование, монтируемое на портативном компьютере (LME), интеллектуальное устройство, беспроводное абонентское оборудование (CPE), беспроводное терминальное устройство, устанавливаемое в транспортном средстве и т.д. WD может поддерживать связь между устройствами (D2D), например, путем реализации стандарта 3GPP для поддержания связи по боковой линии связи и в этом случае может называться устройством связи D2D. В качестве еще одного конкретного примера в сценарии Интернета вещей (IoT) WD может представлять собой машину или другое устройство, которое выполняет мониторинг и/или измерения и передает результаты такого мониторинга и/или измерений в другое WD и/или сетевой узел. В этом случае WD может быть устройством межмашинной связи (M2M), которое в контексте 3GPP может упоминаться как устройство связи машинного типа (MTC). В качестве одного конкретного примера, WD может быть UE, реализующим стандарт узкополосного IoT (NB-IoT) 3GPP. Конкретными примерами таких машин или устройств являются датчики, измерительные устройства, такие как измерители мощности, промышленное оборудование или бытовые или персональные электроприборы (например, холодильники, телевизоры и т.д.), персональные носимые портативные электронные устройства (например, часы, фитнес-браслеты и т.д.). В других сценариях WD может представлять транспортное средство или другое оборудование, которое способно контролировать и/или сообщать о своем рабочем состоянии или других функциях, связанных с его работой. WD, как описано выше, может представлять оконечную точку беспроводного соединения, и в этом случае устройство может упоминаться как беспроводной терминал. Кроме того, WD, как описано выше, может быть мобильным, и в этом случае его можно также назвать мобильным устройством или мобильным терминалом.

Как показано, беспроводное устройство 310 включает в себя антенну 311, интерфейс 314, схему 320 обработки, машиночитаемый носитель 330 информации, оборудование 332 пользовательского интерфейса, вспомогательное оборудование 334, источник 336 электропитания и схему 337 электропитания. WD 310 может включать в себя множество наборов из одного или более из проиллюстрированных компонентов для различных технологий беспроводной связи, поддерживаемых WD 310, таких, например, как технологии беспроводной связи GSM, WCDMA, LTE, NR, WiFi, WiMAX или Bluetooth, и это всего лишь некоторые из них. Эти технологии беспроводной связи могут быть интегрированы в те же или другие микросхемы или набор микросхем, что и другие компоненты в WD 310.

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

Как показано, интерфейс 314 содержит схему 312 радиочастотного тракта и антенну 311. Схема 312 радиочастотного тракта содержит один или несколько фильтров 318 и усилителей 316. Схема 314 радиочастотного тракта подключена к антенне 311 и схеме 320 обработки и выполнена с возможностью выполнения кондиционирования сигналов, передаваемых между антенной 311 и схемой 320 обработки. Схема 312 радиочастотного тракта может быть подключена к антенне 311 или к ее части. В некоторых вариантах осуществления WD 310 может не включать в себя отдельную схему 312 радиочастотного тракта; скорее всего, схема 320 обработки может содержать схему радиосигнала и может быть подключена к антенне 311. Аналогичным образом, в некоторых вариантах осуществления некоторые или все схемы 322 РЧ приемопередатчика могут рассматриваться как часть интерфейса 314. Схема 312 радиочастотного тракта может принимать цифровые данные, подлежащие отправке в другие узлы сети или WD через беспроводное соединение. Схема 312 радиочастотного тракта может преобразовывать цифровые данные в радиосигнал, имеющий соответствующие параметры канала и полосу пропускания, используя комбинацию фильтров 318 и/или усилителей 316. Затем радиосигнал может передаваться через антенну 311. Аналогичным образом, при приеме данных антенна 311 может принимать радиосигналы, которые затем преобразуются в цифровые данные схемой 312 радиочастотного тракта. Цифровые данные могут передаваться в схему 320 обработки. В других вариантах осуществления интерфейс может содержать различные компоненты и/или различные комбинации компонентов.

Схема 320 обработки может содержать комбинацию из одного или более из: микропроцессора, контроллера, микроконтроллера, центрального процессора, процессора цифровых сигналов, специализированной интегральной схемы, программируемой пользователем вентильной матрицы или любого другого подходящего вычислительного устройства, ресурса или комбинации аппаратных средств, программного обеспечения и/или кодированной логики, предназначенной для обеспечения, по отдельно или в сочетании с другими компонентами WD 310, такими как машиночитаемый носитель 330 информации, функциональных возможностей WD 310. Такие функциональные возможности могут включать в себя предоставление любых различных функций беспроводной связи или преимуществ, обсужденных в данном документе. Например, схема 320 обработки может исполнять инструкции, хранящиеся на машиночитаемом носителе 330 информации или в памяти, расположенной в схеме 320 обработки с тем, чтобы обеспечить раскрытые в данном документе функциональные возможности.

Как показано, схема 320 обработки включает в себя одну или несколько из схемы 322 РЧ приемопередатчика, схемы 324 обработки основополосных сигналов и схемы 326 обработки приложения. В других вариантах осуществления схема обработки может содержать различные компоненты и/или различные комбинации компонентов. В некоторых вариантах осуществления схема 320 обработки WD 310 может содержать SOC. В некоторых вариантах осуществления схема 322 РЧ приемопередатчика, схема 324 обработки основополосных сигналов и схема 326 обработки приложения могут быть выполнены в виде отдельных микросхем или наборов микросхем. В альтернативных вариантах осуществления часть или вся схема 324 обработки основополосных сигналов и схема 326 обработки приложений могут быть объединены в одну микросхему или набор микросхем, и схема 322 РЧ приемопередатчика может быть выполнена в виде отдельной микросхемы или набора микросхем. В еще одних альтернативных вариантах осуществления часть или вся схема 322 РЧ приемопередатчика и схема 324 обработки основополосных сигналов могут быть выполнены на одной и той же микросхеме или на одном и том же наборе микросхем, и схема 326 обработки приложения может быть в виде отдельной микросхемы или набора микросхем. В еще одних альтернативных вариантах осуществления часть или вся схема 322 РЧ приемопередатчика, схема 324 обработки основополосных сигналов и схема 326 обработки приложения могут быть объединены в одной и той же микросхеме или наборе микросхем. В некоторых вариантах осуществления схема 322 РЧ приемопередатчика может быть частью интерфейса 314. Схема 322 РЧ приемопередатчика может формировать РЧ сигналы для схемы 320 обработки.

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

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

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

Оборудование 332 пользовательского интерфейса может предоставлять компоненты, которые позволяют пользователю-человеку взаимодействовать с WD 310. Такое взаимодействие может принимать различные формы, такие как визуальное, звуковое, тактильное и т.д. Оборудование 332 пользовательского интерфейса может быть выполнено с возможностью предоставлять пользователю возможность выводить и вводить данные из/в WD 310. Тип взаимодействия может варьироваться в зависимости от типа оборудования 332 пользовательского интерфейса, установленного в WD 310. Например, если WD 310 представляет собой смартфон, взаимодействие может осуществляться посредством касания экрана; если WD 310 представляет собой интеллектуальный измеритель, взаимодействие может осуществляться через экран, который представляет показания расхода (например, количество использованных галлонов (литров), или динамик, который обеспечивает звуковое оповещение (например, если обнаружен дым). Оборудование 332 пользовательского интерфейса может включать в себя интерфейсы, устройства и схемы ввода и интерфейсы, устройства и схемы вывода. Оборудование 332 пользовательского интерфейса выполнено с возможностью ввода информации в WD 310 и подключения к схеме 320 обработки с тем, чтобы схема 320 обработки могла обрабатывать вводимую информацию. Оборудование 332 пользовательского интерфейса может включать в себя, например, микрофон, датчик приближения или другой датчик, клавиши/кнопки, сенсорный дисплей, одну или несколько камер, порт универсальной последовательной шины (USB) или другую схему ввода. Оборудование 332 пользовательского интерфейса также выполнено с возможностью разрешать вывод информации из WD 310 и разрешать схемам 320 обработки выводить информацию из WD 310. Оборудование 332 пользовательского интерфейса может включать в себя, например, динамик, дисплей, вибрирующие схемы, USB-порт, интерфейс наушников или другие выходные схемы. Используя один или несколько интерфейсов ввода и вывода, устройств и схем оборудования 332 пользовательского интерфейса, WD 310 может поддерживать связь с конечными пользователями и/или беспроводной сетью и предоставлять им возможность пользоваться функциональными возможностями, описанными в данном документе.

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

В некоторых вариантах осуществления источник 336 электропитания может использоваться в виде аккумуляторной батареи или аккумуляторного блока. Кроме того, могут также использоваться другие типы источников электропитания, такие как внешний источник электропитания (например, электрическая розетка), фотоэлектрические устройства или элементы электропитания. WD 310 может дополнительно содержать схему 337 электропитания для подачи питания от источника 336 электропитания на различные части WD 310, которым требуется электропитание от источника 336 электропитания для выполнения любых функций, описанных или указанных в данном документе. В некоторых вариантах осуществления схема 337 электропитания может содержать схему управления электропитанием. Схема 337 электропитания может дополнительно или альтернативно выполнена с возможностью приема энергии от внешнего источника питания; в этом случае WD 310 может быть подключено к внешнему источнику электропитания (например, к электрической розетке) через входную схему или интерфейс, такой как кабель электропитания. В некоторых вариантах осуществления схема 337 электропитания может быть также выполнена с возможностью подачи питания от внешнего источника электропитания на источник 336 электропитания. Это может потребоваться, например, для зарядки источника 336 электропитания. Схема 337 электропитания может выполнять любое форматирование, преобразование или другое изменение электроэнергии, подаваемой из источника 336 электропитания, чтобы сделать электроэнергию подходящей для соответствующих компонентов WD 310, на которые подается питание.

На фиг. 4 показан один вариант осуществления UE в соответствии с различными аспектами, описанными в данном документе. Используемый в данном документе термин "пользовательское оборудование или UE" необязательно может иметь пользователя в смысле пользователя-человека, который владеет и/или управляет соответствующим устройством. Вместо этого UE может представлять устройство, которое предназначено для продажи или эксплуатации пользователем-человеком, но которое не может или не может изначально быть связано с конкретным пользователем-человеком. UE может также содержать любое UE, определенное в рамках проекта партнерства 3-го поколения (3GPP), включая UE NB-IoT, которое не предназначено для продажи или эксплуатации пользователем-человеком. UE 400, как показано на фиг. 4, является одним примером WD, выполненного с возможностью поддержания связи в соответствии с одним или несколькими стандартами связи, принятыми в рамках проекта партнерства 3-го поколения (3GPP), такими как стандарты GSM 3GPP, UMTS, LTE и/или стандарты 5G. Как упоминалось ранее, термины "WD" и "UE" могут использоваться взаимозаменяемо. Соответственно, хотя на фиг. 4 показано UE, компоненты, обсужденные в данном документе, в равной степени применимы к WD, и наоборот.

На фиг. 4 UE 400 включает в себя схему 401 обработки, которая функционально связана с интерфейсом 405 ввода-вывода, РЧ интерфейсом 409, интерфейсом 411 сетевого подключения, памятью 415, в том числе оперативное запоминающее устройство (RAM) 417, постоянное запоминающее устройство (ROM) 419 и носитель 421 информации или тому подобное, подсистему связи 431, источник 433 электропитания и/или любой другой компонент или любую их комбинацию. Носитель 421 информации включает в себя операционную систему 423, прикладную программу 425 и данные 427. В других вариантах осуществления носитель 421 информации может включать в себя другие подобные типы информации. Некоторые UE могут использовать все компоненты, показанные на фиг. 4, или только подмножество компонентов. Уровень интеграции между компонентами может варьироваться от одного UE до другого UE. Кроме того, некоторые UE могут содержать несколько экземпляров компонента, таких как несколько процессоров, запоминающих устройств, приемопередатчиков, передатчиков, приемников и т.д.

На фиг. 4 схема 401 обработки может быть выполнена с возможностью обработки компьютерных инструкций и данных. Схема 401 обработки может быть выполнена с возможностью реализации любой машины последовательных состояний, предназначенной для исполнения инструкций, хранящихся в виде машиночитаемых компьютерных программ в памяти, такой как одна или несколько аппаратных машин состояний (например, в дискретной логике, FPGA, ASIC и т.д.); программируемая логическая схема вместе с соответствующим программно-аппаратным обеспечением; одна или несколько процессоров общего назначения вместе с программами, хранящимися в памяти, таких как микропроцессор или процессор цифровых сигналов (DSP), вместе с соответствующим программным обеспечением; или любая комбинация из вышеперечисленного. Например, схема 401 обработки может включать в себя два центральных процессора (CPU). Данные могут быть представлены в форме информации, подходящей для использования в компьютере.

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

На фиг. 4 РЧ интерфейс 409 может быть выполнен с возможностью обеспечения интерфейса связи с РЧ компонентами, такими как передатчик, приемник и антенна. Интерфейс 411 сетевого соединения может быть выполнен с возможностью обеспечения интерфейса связи с сетью 443a. Сеть 443a может охватывать проводные и/или беспроводные сети, такие как локальная вычислительная сеть (LAN), глобальная вычислительная сеть (WAN), компьютерная сеть, беспроводная сеть, телекоммуникационная сеть, другая подобная сеть или любая их комбинация. Например, сеть 443a может содержать сеть Wi-Fi. Интерфейс 411 сетевого соединения может быть выполнен с возможностью включать в себя интерфейс приемника и передатчика, используемый для поддержания связи с одним или несколькими другими устройствами по сети связи в соответствии с одним или несколькими протоколами связи, такими как Ethernet, TCP/IP, SONET, ATM или т.п. Интерфейс 411 сетевого соединения может реализовывать функциональные возможности приемника и передатчика, соответствующие каналам сети связи (например, оптическим, электрическим и т.п.). Функции передатчика и приемника могут совместно использовать компоненты схемы, программное обеспечение или аппаратно-программное обеспечение или, альтернативно, могут быть реализованы по отдельности.

RAM 417 может быть выполнено с возможностью взаимодействия через шину 402 со схемой 401 обработки для обеспечения хранения или кэширования данных или компьютерных инструкций во время исполнения программ, таких как операционная система, прикладные программы и драйверы устройств. ROM 419 может быть выполнено с возможностью предоставления компьютерных инструкций или данных для схемы 401 обработки. Например, ROM 419 может быть выполнено с возможностью хранения инвариантного низкоуровневого системного кода или данных для основных системных функций, таких как базовый ввод и вывод (I/O), запуск или прием нажатий клавиш с клавиатуры, которые хранятся в энергонезависимой памяти. Носитель 421 информации может быть выполнен с возможностью включать в себя память, такую как RAM, ROM, программируемое постоянное запоминающее устройство (PROM), стираемое программируемое постоянное запоминающее устройство (EPROM), электрически стираемое программируемое постоянное запоминающее устройство (EEPROM), магнитные диски, оптические диски, дискеты, жесткие диски, съемные картриджи или флэш-память. В одном примере носитель 421 информации может быть выполнен с возможностью включать в себя операционную систему 423, прикладную программу 425, такую как приложение веб-браузера, механизм виджетов или гаджетов или другое приложение и файл 427 данных. Носитель 421 информации может хранить, при использовании UE 400, любое из множества различных операционных систем или комбинаций операционных систем.

Носитель 421 информации может быть выполнен с возможностью включать в себя несколько физических дисков, таких как резервный массив независимых дисков (RAID), дисковод для гибких дисков, карта флэш-памяти, флэш-память USB, внешний жесткий диск, флэш-накопитель, флэшка, оптический дисковод высокой плотности для цифровых универсальных дисков (HD-DVD), внутренний жесткий диск, дисковод для оптических дисков Blu-Ray, дисковод для оптических дисков с голографическим цифровым хранилищем данных (HDDS), внешний миниатюрный двойной встроенный модуль памяти (DIMM) синхронное динамическое оптическое запоминающее устройство (SDRAM), SDRAM на основе внешнего микро-DIMM, память на основе смарт-карты, такая как модуль идентификации абонента или сменный модуль идентификации пользователя (SIM/RUIM), другая память или любая их комбинация. Носитель 421 информации может предоставлять UE 400 доступ к исполняемым на компьютере инструкциям, прикладным программам и т.п., хранящимся на временном или постоянном носителе памяти, для выгрузки данных или для загрузки данных. Изделие производства, такое как изделие, использующее систему связи, может быть материально воплощено в виде носителя 421 информации, который может содержать машиночитаемый носитель.

На фиг. 4 показана схема 401 обработки, которая может быть выполнена с возможностью поддержания связи с сетью 443b, использующей подсистемы 431 связи. Сеть 443a и сеть 443b могут быть одной и той же сетью или сетями или другой сетью или сетями. Подсистема 431 связи может быть выполнена с возможностью включать в себя один или несколько приемопередатчиков, используемых для поддержания связи с сетью 443b. Например, подсистема 431 связи может быть выполнена с возможностью включать в себя один или несколько приемопередатчиков, используемых для поддержания связи с одним или несколькими удаленными приемопередатчиками другого устройства, способного поддерживать беспроводную связь, такого как другое WD, UE или базовая станция сети радиодоступа (RAN), в соответствии с одним или несколькими протоколами связи, такими как IEEE 802.3, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax или т.п. Каждый приемопередатчик может включать в себя передатчик 433 и/или приемник 435 для реализации функциональных возможностей передатчика или приемника, соответственно, свойственных линиям связи RAN (например, выделение частот и тому подобное). Кроме того, передатчик 433 и приемник 435 каждого приемопередатчика могут совместно использовать компоненты схемы, программное обеспечение или аппаратно-программное обеспечение или, альтернативно, могут быть реализованы отдельно.

В проиллюстрированном варианте осуществления функции связи подсистемы 431 связи могут включать в себя передачу данных, голосовую связь, мультимедийную связь, связь малого радиуса действия, такую как Bluetooth, связь ближнего радиуса действия, связь на основе определения местоположения, например, на основе использования системы глобального позиционирования (GPS) для определения местоположения, другую подобную функцию связи или любую их комбинацию. Например, подсистема 431 связи может включать в себя сотовую связь, связь Wi-Fi, связь Bluetooth и связь GPS. Сеть 443b может охватывать проводные и/или беспроводные сети, такие как локальная вычислительная сеть (LAN), глобальная вычислительная сеть (WAN), компьютерная сеть, беспроводная сеть, телекоммуникационная сеть, другая подобная сеть или любая их комбинация. Например, сеть 443b может быть сотовой сетью, сетью Wi-Fi и/или сетью ближнего радиуса действия. Источник 413 электропитания может быть выполнен с возможностью подачи переменного тока (AC) или постоянного тока (DC) на компоненты UE 400.

Особенности, преимущества и/или функции, описанные в данном документе, могут быть реализованы в одном из компонентов UE 400 или распределены по множеству компонентов UE 400. Кроме того, описанные в данном документе особенности, преимущества и/или функции могут быть реализованы в любой комбинации: аппаратные средства, программное обеспечение или программно-аппаратное обеспечение. В одном примере подсистема 431 связи может быть выполнена с возможностью включать в себя любой из компонентов, описанных в данном документе. Кроме того, схема 401 обработки может быть выполнена с возможностью поддержания связи с любым из таких компонентов по шине 402. В другом примере любой из таких компонентов может быть представлен программными инструкциями, хранящимися в памяти, которые при исполнении схемой 401 обработки выполняют соответствующие функции, описанные в данном документе. В другом примере функциональные возможности любого из таких компонентов могут быть разделены между схемой 401 обработки и подсистемой 431 связи. В другом примере, функции, не требующие большого объема вычислений, любого из таких компонентов могут быть реализованы в программном обеспечении или программно-аппаратном обеспечении, а также функции, требующие большого объема вычислений, могут быть реализованы аппаратным образом.

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

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

Функции могут быть реализованы одним или несколькими приложениями 520 (которые могут альтернативно называться экземплярами программного обеспечения, виртуальными устройствами, сетевыми функциями, виртуальными узлами, функциями виртуальной сети и т.д.), выполненными с возможностью реализации некоторых особенностей, функций и/или преимуществ некоторых из раскрытых в данном документе вариантов осуществления. Приложения 520 выполняются в среде 500 виртуализации, которая предоставляет аппаратные средства 530, содержащие схему 560 обработки и память 590. Память 590 содержит инструкции 595, исполняемые схемой 560 обработки, посредством чего приложение 520 способно обеспечить одну или несколько функций, преимуществ и/или функций, раскрытых в данном документе.

Среда 500 виртуализации содержит сетевые аппаратные устройства 530 общего или специального назначения, содержащие набор из одного или нескольких процессоров или схем 560 обработки, которые могут быть готовыми к применению коммерческими (COTS) процессорами, специализированными интегрированными схемами (ASIC) или схемами обработки любого другого типа, включая цифровые или аналоговые аппаратные компоненты или процессоры специального назначения. Каждое аппаратное устройство может содержать память 590-1, которая может быть невременной памятью для временного хранения инструкций 595 или программного обеспечения, исполняемого схемой 560 обработки. Каждое аппаратное устройство может содержать один или несколько контроллеров сетевого интерфейса (NIC) 570, также известных как сетевые интерфейсные карты, которые включают в себя физический сетевой интерфейс 580. Каждое аппаратное устройство может также включать в себя невременные, постоянные, машиночитаемые носители 590-2 информации, на которых хранится программное обеспечение 595 и/или инструкции, исполняемые схемой 560 обработки. Программное обеспечение 595 может включать в себя любой тип программного обеспечения, включая программное обеспечение для создания экземпляров одного или нескольких уровней 550 виртуализации (также называемых гипервизорами), программного обеспечения для исполнения виртуальных машин 540, а также программного обеспечения, позволяющего ему исполнять функции, особенности и/или преимущества, описанные в связи с некоторыми вариантами осуществления, описанными в данном документе.

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

Во время работы схема 560 обработки исполняет программное обеспечение 595 для создания экземпляра гипервизора или слоя 550 виртуализации, который иногда может упоминаться как монитор виртуальной машины (VMM). Слой 550 виртуализации может представлять собой виртуальную операционную платформу, которая выглядит как сетевое оборудование для виртуальной машины 540.

Как показано на фиг. 5, аппаратные средства 530 могут представлять собой автономный сетевой узел с общими или конкретными компонентами. Аппаратные средства 530 могут содержать антенну 5225 и могут реализовывать некоторые функции посредством виртуализации. В качестве альтернативы, аппаратные средства 530 могут быть частью более крупного кластера аппаратных средств (например, такого как в центре обработки данных или оборудовании для обслуживания клиентов (CPE)), где многие аппаратные узлы работают вместе и управляются через управление и оркестровку (MANO) 5100, которая, помимо прочего, контролирует управление жизненным циклом приложений 520.

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

В контексте NFV виртуальная машина 540 может быть программной реализацией физической машины, которая запускает программы, как если бы они исполнялись на физической, не виртуализированной машине. Каждая из виртуальных машин 540, в том числе та часть аппаратных средств 530, которая исполняет эту виртуальную машину, будь то аппаратные средства, выделенные для этой виртуальной машины, и/или аппаратные средства, совместно используемые этой виртуальной машиной с другими виртуальными машинами 540, образует отдельные элементы виртуальной сети (VNE).

Вместе с тем в контексте NFV функция виртуальной сети (VNF) отвечает за обработку определенных сетевых функций, которые выполняются в одной или нескольких виртуальных машинах 540 на верхнем уровне аппаратной сетевой инфраструктуры 530, и соответствует приложению 520, показанному на фиг. 5.

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

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

Как показано на фиг. 6, в соответствии с вариантом осуществления система связи включает в себя телекоммуникационную сеть 610, такую как сотовая сеть типа 3GPP, которая содержит сеть 611 доступа, такую как сеть радиодоступа, и базовую сеть 614. Сеть 611 доступа содержит множество базовых станций 612a, 612b, 612c, таких как NB, eNB, gNB или точки беспроводного доступа других типов, каждая из которых определяет соответствующую зону 613a, 613b, 613c покрытия. Каждая базовая станция 612a, 612b, 612c может быть подключена к базовой сети 614 через проводное или беспроводное соединение 615. Первое UE 691, расположенное в зоне 613c покрытия, выполнено с возможностью беспроводного подключения к или передачи сигналов поискового вызова с помощью соответствующей базовой станции 612c. Второе UE 692 в зоне 613a покрытия беспроводным образом подключается к соответствующей базовой станции 612a. Хотя в этом примере проиллюстрировано множество UE 691, 692, раскрытые варианты осуществления в равной степени применимы к ситуации, когда одиночное UE находится в зоне покрытия, или когда одиночное UE подключается к соответствующей базовой станции 612.

Телекоммуникационная сеть 610 сама подключена к хост-компьютеру 630, который может быть реализован в аппаратном и/или программном обеспечении автономного сервера, сервера, реализованного в облаке, распределенного сервера или в качестве ресурсов обработки в ферме серверов. Хост-компьютер 630 может находиться в собственности или под контролем поставщика услуг или может управляться поставщиком услуг или от имени поставщика услуг. Соединения 621 и 622 между телекоммуникационной сетью 610 и хост-компьютером 630 могут простираться непосредственно из базовой сети 614 на хост-компьютер 630 или могут проходить через дополнительную промежуточную сеть 620. Промежуточная сеть 620 может быть одной или несколькими сетями общего пользования, частной или размещенной; промежуточная сеть 620, если таковая имеется, может быть магистральной сетью или Интернетом; в частности, промежуточная сеть 620 может содержать две или более подсетей (не показаны).

Система связи, показанная на фиг. 6, в целом обеспечивает связность между подключенными UE 691, 692 и хост-компьютером 630. Связность может быть описана как соединение 650 поверх протокола IP (OTT). Хост-компьютер 630 и подключенные UE 691, 692 выполнены с возможностью передачи данных и/или сигнализации через OTT-соединение 650, используя сеть 611 доступа, базовую сеть 614, любую промежуточную сеть 620 и возможную дополнительную инфраструктуру (не показана) в качестве посредников. OTT-соединение 650 может быть прозрачным в том смысле, что участвующие устройства связи, через которые проходит OTT-соединение 650, не знают о маршрутизации передач по восходящей и нисходящей линиям связи. Например, базовая станция 612 может не знать или не нуждаться в информации о прошлой маршрутизации входящей передачи по нисходящей линии связи с данными, исходящими из хост-компьютера 630, которые должны пересылаться (например, при передаче обслуживания) в подключенное UE 691. Аналогичным образом, базовой станции 612 не нужно знать о будущей маршрутизации исходящей передачи по восходящей линии связи, исходящей от UE 691 в направлении хост-компьютера 630.

Примерные реализации, в соответствии с вариантом осуществления, UE, базовой станции и хост-компьютера, обсуждаемые в предыдущих абзацах, теперь будут описаны со ссылкой на фиг. 7. В системе связи 700 хост-компьютер 710 содержит аппаратное обеспечение 715, включающее в себя интерфейс связи 716, сконфигурированный для установки и поддержания проводного или беспроводного соединения с интерфейсом другого устройства связи системы связи 700. Хост-компьютер 710 дополнительно содержит схему обработки 718, которая может иметь возможности хранения и/или обработки. В частности, схема обработки 718 может содержать один или несколько программируемых процессоров, специализированных интегральных схем, программируемых пользователем вентильных матриц или их комбинации (не показаны), предназначенные для выполнения команд. Хост-компьютер 710 дополнительно содержит программное обеспечение 711, которое хранится в хост-компьютере 710 или доступно для него и исполняется схемой обработки 718. Программное обеспечение 711 включает в себя хост-приложение 712. Хост-приложение 712 может быть выполнено с возможностью предоставления услуги удаленному пользователю, такому как UE 730, соединяющееся через OTT-соединение 750, заканчивающееся на UE 730, и хост-компьютер 710. При предоставлении услуги удаленному пользователю хост-приложение 712 может предоставлять пользовательские данные, которые передаются с использованием OTT-соединения 750.

Система 700 связи дополнительно включает в себя базовую станцию 720, предусмотренную в телекоммуникационной системе и содержащую аппаратные средства 725, позволяющие ей обмениваться данными с хост-компьютером 710 и с UE 730. Аппаратные средства 725 могут включать в себя интерфейс 726 связи для установки и поддержания проводного или беспроводного соединения с интерфейсом другого устройства связи системы 700 связи, а также радиоинтерфейс 727 для установки и поддержания по меньшей мере беспроводного соединения 770 с UE 730, расположенным в зоне покрытия (не показана на фиг. 7), обслуживаемой базовой станцией 720. Интерфейс 726 связи может быть выполнен с возможностью упрощения соединения 760 с хост-компьютером 710. Соединение 760 может быть прямым, или оно может проходить через базовую сеть (не показана на фиг. 7) телекоммуникационной системы и/или через одну или несколько промежуточных сетей вне телекоммуникационной системы. В показанном варианте осуществления аппаратные средства 725 базовой станции 720 дополнительно включают в себя схему 728 обработки, которая может содержать один или несколько программируемых процессоров, специализированные интегральные схемы, программируемые пользователем вентильные матрицы или их комбинации (не показаны), выполненные с возможностью исполнения инструкций. Базовая станция 720 дополнительно имеет программное обеспечение 721, хранящееся внутри нее или доступное через внешнее соединение.

Система 700 связи дополнительно включает в себя уже упомянутое UE 730. Его аппаратные средства 735 могут включать в себя радиоинтерфейс 737, выполненный с возможностью установки и поддержания беспроводного соединения 770 с базовой станцией, обслуживающей зону покрытия, в которой на данный момент находится UE 730. Аппаратные средства 735 UE 730 дополнительно включают в себя схему 738 обработки, которая может содержать один или несколько программируемых процессоров, специализированных интегральных схем, программируемых пользователем вентильных матриц или их комбинации (не показаны), выполненных с возможностью исполнения инструкций. UE 730 дополнительно содержит программное обеспечение 731, которое хранится в UE 730 или доступно для него и может исполняться схемой 738 обработки. Программное обеспечение 731 включает в себя клиентское приложение 732. Клиентское приложение 732 может быть выполнено с возможностью предоставлять услугу пользователю- человеку или пользователю-не человеку через UE 730, с поддержкой хост-компьютера 710. В хост-компьютере 710 исполняющее хост-приложение 712 может поддерживать связь с исполняющимся клиентским приложением 732 через OTT-соединение 750, оканчивающееся в UE 730 и хост-компьютере 710. При предоставлении услуги пользователю, клиентское приложение 732 может принимать данные запроса из хост-приложения 712 и предоставлять пользовательские данные в ответ на данные запроса. OTT-соединение 750 может передавать как данные запроса, так и данные пользователя. Клиентское приложение 732 может взаимодействовать с пользователем для выработки пользовательских данных, которые оно предоставляет.

Следует отметить, что хост-компьютер 710, базовая станция 720 и UE 730, показанные на фиг. 7, могут быть аналогичны или идентичны хост-компьютеру 630, одной из базовых станций 612a, 612b, 612c и одному из UE 691, 692, которые показаны на фиг. 6, соответственно. То есть внутренняя работа этих объектов может быть такой, как показано на фиг. 7, и независимо от этого топология окружающей сети может быть такой же, как на фиг. 6.

На фиг. 7 ОТТ-соединение 750 было изображено абстрактно для иллюстрации связи между хост-компьютером 710 и UE 730 через базовую станцию 720 без явной ссылки на какие-либо промежуточные устройства и точной маршрутизации сообщений через эти устройства. Сетевая инфраструктура может определять маршрутизацию, которую она может конфигурировать, чтобы скрыть ее от UE 730 или от поставщика услуг, управляющего хост-компьютером 710, или от обоих. Когда OTT-соединение 750 является активным, сетевая инфраструктура может дополнительно принимать решения, с помощью которых оно динамически изменяет маршрутизацию (например, на основе рассмотрения балансировки нагрузки или реконфигурирования сети).

Беспроводное соединение 770 между UE 730 и базовой станцией 720 соответствует принципам вариантов осуществления, описанным в настоящем раскрытии. Один или более из различных вариантов осуществления позволяют повысить производительность OTT-услуг, предоставляемых UE 730, используя OTT-соединение 750, в котором беспроводное соединение 770 образует последний сегмент. Более точно, идеи этих вариантов осуществления позволяют повысить скорость передачи данных, уменьшить задержку и потребление энергии и, таким образом, обеспечить такие преимущества, как, например, уменьшенное время ожидания пользователя, более высокая скорость отклика и увеличенный срок службы аккумуляторной батареи.

Процедура измерения может выполняться с целью контроля скорости передачи данных, задержки и других показателей, которые улучшают один или несколько вариантов осуществления. Кроме того, может существовать дополнительные сетевые функциональные возможности для реконфигурирования OTT-соединения 750 между хост-компьютером 710 и UE 730 в ответ на изменения результатов измерений. Процедура измерения и/или сетевые функциональные возможности для реконфигурирования OTT-соединения 750 могут быть реализованы в виде программного обеспечения 711 и аппаратных средств 715 хост-компьютера 710, или в виде программного обеспечения 731 и аппаратных средств 735 UE 730 или и того и другого. В вариантах осуществления датчики (не показаны) могут быть развернуты в или в связи с устройствами связи, через которые проходит OTT-соединение 750; датчики могут участвовать в процедуре измерения, предоставляя значения контролируемых величин, приведенных в качестве примера выше, или предоставляя значения других физических величин, на основе которых программное обеспечение 711, 731 может вычислить или оценить контролируемые величины. Реконфигурирование OTT-соединения 750 может включать в себя формат сообщения, настройки повторной передачи, предпочтительную маршрутизацию и т.д.; реконфигурирование не должно влиять на базовую станцию 720, и оно может быть неизвестным или незаметным для базовой станции 720. Такие процедуры и функциональные возможности известны и могут быть осуществлены в данной области техники. В некоторых вариантах осуществления измерения могут включать в себя собственную сигнализацию UE, облегчающую измерения, проводимые хост-компьютером 710, пропускной способности, времени распространения, задержки и т.п. Измерения могут быть реализованы таким образом, чтобы программное обеспечение 711 и 731 заставляло передавать сообщения, в частности пустые или «фиктивные» сообщения с использованием OTT-соединения 750, контролируя при этом время распространения, ошибки и т.д.

На фиг. 8 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи, в соответствии с одним вариантом осуществления. Система связи включает в себя хост-компьютер, базовую станцию и UE, которые могут быть такими, которые описаны со ссылкой на фиг. 6 и 7. Для упрощения настоящего раскрытия в этом разделе будут включены только ссылки на чертежи, показанные на фиг. 8. На этапе 810 хост-компьютер предоставляет пользовательские данные. На подэтапе 811 (который может быть необязательным) этапа 810 хост-компьютер предоставляет пользовательские данные путем исполнения хост-приложения. На этапе 820 хост-компьютер инициирует передачу, переносящую пользовательские данные в UE. На этапе 830 (который может быть необязательным) базовая станция передает в UE пользовательские данные, которые были перенесены при передаче, инициированной хост-компьютером, в соответствии с идеями вариантов осуществления, описанных в настоящем раскрытии. На этапе 840 (который также может быть необязательным) UE исполняет клиентское приложение, связанное с хост-приложением, исполняемым хост-компьютером.

На фиг. 9 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи, в соответствии с одним вариантом осуществления. Система связи включает в себя хост-компьютер, базовую станцию и UE, которые могут быть такими, которые описаны со ссылкой на фиг. 6 и 7. Для упрощения настоящего раскрытия в этом разделе будут включены только ссылки на чертежи, показанные на фиг. 9. На этапе 910 способа хост-компьютер предоставляет пользовательские данные. На необязательном подэтапе (не показан) хост-компьютер предоставляет пользовательские данные, исполняя хост-приложение. На этапе 920 хост-компьютер инициирует передачу, переносящую пользовательские данные в UE. Передача может проходить через базовую станцию в соответствии с идеями вариантов осуществления, описанных в настоящем раскрытии. На этапе 930 (который может быть необязательным) UE принимает пользовательские данные, переносимые в передаче.

На фиг. 10 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи, в соответствии с одним вариантом осуществления. Система связи включает в себя хост-компьютер, базовую станцию и UE, которые могут быть такими, которые описаны со ссылкой на фиг. 6 и 7. Для упрощения настоящего раскрытия в этом разделе будут включены только ссылки на чертежи, показанные на фиг. 10. На этапе 1010 (который может быть необязательным) UE принимает данные ввода, предоставленные хост-компьютером. Дополнительно или альтернативно, на этапе 1020 UE предоставляет пользовательские данные. На подэтапе 1021 (который может быть необязательным) этапа 1020 UE предоставляет пользовательские данные путем исполнения клиентского приложения. На подэтапе 1011 (который может быть необязательным) этапа 1010 UE исполняет клиентское приложение, которое предоставляет пользовательские данные в ответ на принятые данные ввода, предоставленные хост-компьютером. При предоставлении пользовательских данных исполняемое клиентское приложение может дополнительно учитывать пользовательский ввод, полученный от пользователя. Независимо от конкретного способа предоставления пользовательских данных, UE на подэтапе 1030 (который может быть необязательным) инициирует передачу пользовательских данных в хост-компьютер. На этапе 1040 способа хост-компьютер принимает пользовательские данные, переданные из UE, в соответствии с идеями вариантов осуществления, описанных в настоящем раскрытии.

На фиг. 11 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи, в соответствии с одним вариантом осуществления. Система связи включает в себя хост-компьютер, базовую станцию и UE, которые могут быть такими, которые описаны со ссылкой на фиг. 6 и 7. Для упрощения настоящего раскрытия в этом разделе будут включены только ссылки на чертежи, показанные на фиг. 11. На этапе 1110 (который может быть необязательным), в соответствии с идеями вариантов осуществления, описанных в настоящем раскрытии, базовая станция принимает пользовательские данные из UE. На этапе 1120 (который может быть необязательным) базовая станция инициирует передачу принятых пользовательских данных в хост-компьютер. На этапе 1130 (который может быть необязательным) хост-компьютер принимает пользовательские данные, переносимые при передаче, инициированной базовой станцией.

Любые подходящие этапы, способы, признаки, функции или преимущества, раскрытые в данном документе, могут быть выполнены с помощью одного или нескольких функциональных блоков или модулей одного или нескольких виртуальных устройств. Каждое виртуальное устройство может содержать ряд этих функциональных блоков. Эти функциональные блоки могут быть реализованы посредством схемы обработки, которая может включать в себя один или несколько микропроцессоров или микроконтроллеров, а также другое цифровое аппаратное обеспечение, которое может включать в себя процессоры цифровых сигналов (DSP), специализированную цифровую логику и т.п. Схема обработки может быть выполнена с возможностью исполнения программного кода, хранящегося в памяти, который может включать в себя один или несколько типов памяти, таких как постоянное запоминающее устройство (ROM), оперативное запоминающее устройство (RAM), кэш-память, устройства флэш-памяти, оптические запоминающие устройства и т.д. Программный код, хранящийся в памяти, включает в себя программные инструкции для исполнения одного или нескольких телекоммуникационных протоколов и/или протоколов передачи данных, а также инструкций для исполнения одного или нескольких технологий, описанных в данном документе. В некоторых реализациях схема обработки может использоваться для того, чтобы заставить соответствующий функциональный блок выполнять соответствующие функции согласно одному или нескольким вариантам осуществления настоящего раскрытия.

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

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

5G - пятое поколение

AP - точка доступа

ASIC - специализированная интегральная схема

BSC - контроллер базовой станции

BTS - базовая приемопередающая станция

CD - компакт-диск

COTS - готовый коммерческий продукт

CPE - клиентское оборудование

CPU - центральное процессорное устройство

D2D - связь между устройствами

DAS - распределенная антенная система

DSP - процессор цифровых сигналов

DVD - цифровой видеодиск

eNB - усовершенствованный или развитой узел B

E-SMLC - развитой центр определения местоположения мобильных устройств

FPGA - программируемая вентильная матрица

GHz - гигагерц

gNB - базовая станция нового радио

GSM - глобальная система мобильной связи

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

IP - Интернет-протокол

LEE - оборудование, встроенное в переносной компьютер

LME - оборудование, установленное в переносном компьютере

LTE - долгосрочное развитие

М2М - межмашинная связь

MANO - управление и оркестрация

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

MDT - минимизация выездного тестирования

MIMO - многоканальный вход - многоканальный выход

MME - управление мобильностью

MSC - центр коммутации мобильной связи

MSR - мультистандартное радио

MTC - связь машинного типа

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

NFV - виртуализация сетевых функций

NIC - контроллер сетевого интерфейса

NR - новое радио

O&M - эксплуатация и техническое обслуживание

OSS - система поддержки операций

OTT - поверх сети

PDA - персональный цифровой помощник

PGW - шлюз сети пакетной передачи данных

RAM - оперативное запоминающее устройство

RAN - сеть радиодоступа

RAT - технология радиодоступа

RF - радиочастота

RNC - контроллер радиосети

ROM - постоянное запоминающее устройство

RRH - удаленная радиоголовка

RRU - удаленный радиоблок

SCEF - функция представления возможностей обслуживания

SOC - система на кристалле

SON - самоорганизующаяся сеть

UE - пользовательское оборудование

USB - универсальная последовательная шина

V2I - придорожная инфраструктура - транспортное средство

V2V - связь между транспортными средствами

V2X - подключение автомобиля к любому объекту в сети

VMM - монитор виртуальной машины

VNE - элемент виртуальной сети

VNF - функция виртуальной сети

VoIP - передача голосового сообщения по Интернет-протоколу

WCDMA - широкополосный множественный доступ с кодовым разделением каналов

WiMax - всемирная совместимость для микроволнового доступа

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

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

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

выполняют (202) измерения SFTD между PCell UE и второй сотой, причем вторая сота является сотой в списке сот, для которых UE может предоставить отчет об измерениях SFTD; и

предоставляют, в сетевой узел, отчет (204) об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD.

2. Способ по п. 1, в котором список сот содержит одну или более сот нового радио (NR).

3. Способ по п. 2, в котором PCell является сотой долгосрочного развития (LTE).

4. Способ по п. 2 или 3, в котором на этапе предоставления отчета об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD:

предоставляют отчет об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD, когда ни одна сота NR не сконфигурирована как первичная вторичная сота (PSCell) UE.

5. Способ по п. 4, дополнительно содержащий, когда сота NR сконфигурирована как PSCell для UE, этап, на котором:

выполняют измерение SFTD между PCell UE и PSCell NR; и

предоставляют отчет об измерении SFTD между PCell UE и PSCell NR.

6. Способ по любому из пп. 1-5, в котором на этапе приема списка сот, для которых UE может предоставить отчет об измерениях SFTD, принимают сообщение о реконфигурировании соединения управления радиоресурсами (RRC), содержащее список сот, для которых UE может предоставить отчет об измерениях SFTD, или принимают сообщение о возобновлении RRC-соединения, содержащее список сот, для которых UE может предоставить отчет об измерениях SFTD.

7. Пользовательское оборудование (UE) для выполнения измерений (SFTD) разницы во времени для кадров с номером системного кадра (SFN) между первичной сотой (PCell) UE и одной или более другими сотами в беспроводной сети, характеризующееся тем, что выполнено с возможностью:

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

выполнения измерений SFTD между PCell UE и второй сотой, причем вторая сота является сотой в списке сот, для которых UE может предоставить отчет об измерениях SFTD; и

предоставления, в сетевой узел, отчета об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD.

8. UE по п. 7, характеризующееся тем, что дополнительно выполнено с возможностью выполнения способа по любому из пп. 2-6.

9. Пользовательское оборудование (UE) для выполнения измерений разницы (SFTD) во времени для кадров с номером системного кадра (SFN) между первичной сотой (PCell) UE и одной или более другими сотами в беспроводной сети, причем UE содержит:

интерфейс, содержащий схему радиочастотного тракта; и

схему обработки, ассоциированную с интерфейсом, причем схема обработки выполнена с возможностью вызывать выполнение UE:

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

измерений SFTD между PCell UE и второй сотой, причем вторая сота является сотой в списке сот, для которых UE может предоставить отчет об измерениях SFTD; и

предоставления, в сетевой узел, отчета об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD.

10. UE по п. 9, в котором список сот содержит одну или более сот нового радио (NR).

11. UE по п. 10, в котором PCell является сотой долгосрочного развития (LTE).

12. UE по п. 10 или 11, в котором для того, чтобы предоставить отчет об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD, схема обработки дополнительно выполнена с возможностью вызывать выполнение UE:

предоставления отчетов об измерениях SFTD в соответствии со списком сот, для которых UE может предоставить отчет об измерениях SFTD, когда ни одна сота NR не сконфигурирована как первичная вторичная сота (PSCell) UE.

13. UE по п. 12, в котором схема обработки дополнительно выполнена с возможностью вызывать выполнение UE, когда сота NR сконфигурирована как PSCell для UE:

измерения SFTD между PCell UE и PSCell NR; и

предоставления отчета об измерении SFTD между PCell UE и PSCell NR.

14. UE по любому из пп. 9-13, в котором для того, чтобы принять список сот, для которых UE может предоставить отчет об измерениях SFTD, схема обработки дополнительно выполнена с возможностью вызывать выполнение UE приема сообщения о реконфигурировании соединения управления радиоресурсами (RRC), содержащего список сот, для которых UE может предоставить отчет об измерениях SFTD, или приема сообщения о возобновлении RRC-соединения, содержащего список сот, для которых UE может предоставить отчет об измерениях SFTD.



 

Похожие патенты:

Изобретение относится к беспроводной связи. Способ содержит: получение терминальным устройством параметра управления мобильностью для выполнения выбора и повторного выбора соты в неактивном состоянии RRC.

Изобретение относится к способу связи. Технический результат заключается в улучшении гибкости передачи физического восходящего управляющего канала (PUCCH).

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

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

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

Группа изобретений относится к технологии Интернета вещей (IoT). Технический результат заключается в повышении безопасности устройств в IoT-окружении.

Изобретение относится к области систем спутниковой связи. Техническим результатом является генерирование укороченных суперкадров.

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

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

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

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