Система и способ передачи и приема поисковых вызовов и системной информации

Изобретение относится к способу и оборудованию для предотвращения потерь данных, существующих в Msg3-буфере, и определения периодов поисковых вызовов в системе мобильной связи следующего поколения. Техническим результатом является обеспечение гибкости планирования связи за счет возможности определения периодов поискового вызова. Согласно заявленному способу из базовой станции через системную информацию получают первую информацию, ассоциированную с конфигурацией дуплекса с временным разделением каналов (TDD); вторую информацию, ассоциированную с конфигурацией пространства поиска для поисковых вызовов; третью информацию, ассоциированную с позицией для по меньшей мере одного блока сигналов синхронизации (SSB), а также параметр, который должен использоваться для того, чтобы определять число периодов отслеживания PDCCH. Число периодов отслеживания PDCCH определяют на основе числа переданных SSB, определенных на основе третьей информации, ассоциированной с позицией для по меньшей мере одного SSB, и упомянутого параметра. 4 н. и 24 з.п. ф-лы, 46 ил.

 

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

[1] Раскрытие сущности, в общем, относится к абонентскому устройству (UE) и базовой станции (BS), а более конкретно, к способу и оборудованию для предотвращения потерь данных, существующих в Msg3-буфере, и определения периодов поисковых вызовов в системе мобильной связи следующего поколения.

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

[2] Чтобы удовлетворять потребность в трафике беспроводных данных, растущую с момента развертывания 4G-систем связи, прикладываются усилия для того, чтобы разрабатывать улучшенную 5G- или пред-5G-систему связи, также называемую "выходящей за рамки 4G-сети" или "системой после LTE". Считается, что 5G-система связи реализуется в верхних полосах частот (mmWave), к примеру, в полосах частот в 60 ГГц, с тем чтобы добиваться более высоких скоростей передачи данных. Чтобы снижать потери при распространении радиоволн и увеличивать расстояние передачи, формирование диаграммы направленности, массовая технология cо многими входами и многими выходами (MIMO), полноразмерная MIMO-технология (FD-MIMO), решетчатая антенна, формирование аналоговой диаграммы направленности, крупномасштабные антенные технологии обсуждаются в 5G-системах связи.

[3] Помимо этого, в 5G-системах связи, осуществляются разработки для улучшения системной сети на основе усовершенствованных небольших сот, облачных сетей радиодоступа (RAN), сверхплотных сетей, связи между устройствами (D2D), беспроводного обратного транзитного соединения, перемещаемой сети, совместной связи, координированной многоточечной передачи (CoMP), подавления помех на приемном конце и т.п. В 5G-системе, разработаны гибридная частотная манипуляция (FSK) и частотно-квадратурная амплитудная модуляция (QAM) (FQAM), и кодирование с наложением окон переменной длительности (SWSC) в качестве усовершенствованной модуляции с кодированием (ACM), а также интерфейс беспроводного доступа на нескольких несущих с гребенками фильтров (FBMC), неортогональный множественный доступ (NOMA) и множественный доступ на основе разреженных кодов (SCMA) в качестве усовершенствованной технологии доступа.

[4] Интернет сегодня развивается в Интернет вещей (IoT), в котором распределенные объекты, такие как вещи, обмениваются и обрабатывают информацию без вмешательства оператора. Появляется Интернет всего (IoE), который представляет собой комбинацию IoT-технологии и технологии обработки больших данных через соединение с облачным сервером. Поскольку такие технологические элементы, как "технология распознавания", "проводная/беспроводная связь и сетевая инфраструктура", "интерфейсная технология предоставления услуг" и "технология обеспечения безопасности", требуются для IoT-реализации, в последнее время исследуются сенсорная сеть, межмашинная связь (M2M), машинная связь (MTC) и т.п. Такое IoT-окружение может предоставлять интеллектуальные услуги на основе Интернет-технологий, которые создают новую ценность в человеческой жизни посредством сбора и анализа данных, сформированных между соединенными вещами. IoT может применяться к множеству областей техники, включающих в себя интеллектуальный дом, интеллектуальное здание, интеллектуальный город, интеллектуальный автомобиль или соединенные автомобили, интеллектуальную энергосеть, здравоохранение, интеллектуальные приборы и усовершенствованные медицинские услуги, через сходимость и комбинацию между существующими информационными технологиями (IT) и различными промышленными вариантами применения.

[5] Соответственно, проведено исследование для того, чтобы применять 5G-системы связи к IoT-сетям. Например, такие технологии, как сенсорная сеть, MTC- и M2M-связь, могут реализовываться посредством формирования диаграммы направленности, MIMO-антенны и решетчатых антенн. Применение облачной сети радиодоступа (RAN) в качестве вышеописанной технологии обработки больших данных также может считаться примером сходимости между 5G- и IoT-технологиями.

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

Техническая задача

[6] Между тем, если UE использует конкурентный произвольный доступ, смешиваемый с неконкурентным произвольным доступом при условии восстановления после сбоя луча, данные, существующие в Msg3-буфере, могут быть потеряны вследствие удаления Msg3-буфера. Соответственно, требуется способ предотвращения потерь данных, существующих в Msg3-буфере.

[7] Помимо этого, если несущая, используемая для передачи по нисходящей линии связи, представляет собой нелицензированную несущую, gNB должен выполнять считывание канала, чтобы определять, является или нет канал свободным, перед передачей сообщения поисковых вызовов в нисходящей линии связи. Возможно то, что gNB имеет сообщение поисковых вызовов, которое следует передавать, но не имеет возможность передавать его в период поисковых вызовов, поскольку канал не является свободным. Это должно задерживать передачу поисковых вызовов до следующего DRX-цикла, если возможности передачи поисковых вызовов в DRX-цикле не увеличиваются для UE. Требуется усовершенствованный способ определения кадра поисковых вызовов и/или периода поисковых вызовов.

[8] В текущем проектном решении, периоды PDCCH-отслеживания для поисковых вызовов, определенные посредством бездействующих/неактивных UE, и периоды PDCCH-отслеживания, определенные посредством соединенных UE, могут отличаться, поскольку TDD-конфигурации, применяемые к бездействующим/неактивным UE и соединенным UE, отличаются. Как результат, возникает рассогласование между периодами поисковых вызовов, определенными посредством бездействующих/неактивных UE и посредством соединенных UE. Требуется усовершенствованный способ определения достоверных периодов PDCCH-отслеживания.

Решение задачи

[9] Аспекты раскрытия сущности заключаются в том, чтобы разрешать, по меньшей мере, вышеуказанные проблемы и/или недостатки и предоставлять, по меньшей мере, преимущества, описанные ниже.

[10] В соответствии с аспектом настоящего раскрытия сущности, предусмотрен способ для терминала в системе беспроводной связи. Способ включает в себя прием, из базовой станции, информации конфигурации дуплекса (дуплексной передачи) с временным разделением каналов (TDD), включенной в блок 1 системной информации (SIB1); прием, из базовой станции, информации конфигурации пространства поиска поисковых вызовов; идентификацию кадра поисковых вызовов и индекса периода поисковых вызовов для отслеживания поисковых вызовов; идентификацию периодов отслеживания физического канала управления нисходящей линии связи (PDCCH) для поисковых вызовов на основе информации TDD-конфигурации и информации конфигурации пространства поиска поисковых вызовов, причем идентифицированные периоды PDCCH-отслеживания представляют собой периоды PDCCH-отслеживания, сконфигурированные посредством информации конфигурации пространства поиска поисковых вызовов, которые не перекрываются с одним или более UL-символов, определенных посредством информации TDD-конфигурации; и отслеживание PDCCH, адресованного временному идентификатору радиосети для поисковых вызовов (P-RNTI), по меньшей мере, в одном периоде PDCCH-отслеживания для поисковых вызовов, в период поисковых вызовов, соответствующий идентифицированному индексу периода поисковых вызовов.

[11] В соответствии с другим аспектом настоящего раскрытия сущности, предусмотрен способ для базовой станции в системе беспроводной связи, способ включает в себя передачу информации конфигурации дуплекса с временным разделением каналов (TDD), включенной в блок 1 системной информации (SIB1); передачу информации конфигурации пространства поиска поисковых вызовов; идентификацию кадра поисковых вызовов и индекса периода поисковых вызовов для передачи поисковых вызовов; идентификацию периодов отслеживания физического канала управления нисходящей линии связи (PDCCH) на основе информации TDD-конфигурации и информации конфигурации пространства поиска поисковых вызовов, причем идентифицированные периоды PDCCH-отслеживания представляют собой периоды PDCCH-отслеживания, сконфигурированные посредством информации конфигурации пространства поиска поисковых вызовов, которые не перекрываются с одним или более UL-символов, определенных посредством информации TDD-конфигурации; и передачу PDCCH для поисковых вызовов с использованием временного идентификатора радиосети для поисковых вызовов (P-RNTI), по меньшей мере, в одном периоде PDCCH-отслеживания для поисковых вызовов в идентифицированные периоды PDCCH-отслеживания, соответствующие идентифицированному индексу периода поисковых вызовов.

[12] В соответствии с другим аспектом настоящего раскрытия сущности, предусмотрен терминал в системе беспроводной связи. Терминал включает в себя приемо-передающее устройство и контроллер, соединенный с приемо-передающим устройством и выполненный с возможностью принимать, из базовой станции, информацию конфигурации дуплекса с временным разделением каналов (TDD), включенную в блок 1 системной информации (SIB1), принимать, из базовой станции, информацию конфигурации пространства поиска поисковых вызовов, идентифицировать кадр поисковых вызовов и индекс периода поисковых вызовов для отслеживания поисковых вызовов, идентифицировать периоды отслеживания физического канала управления нисходящей линии связи (PDCCH) для поисковых вызовов на основе информации TDD-конфигурации и информации конфигурации пространства поиска поисковых вызовов, причем идентифицированные периоды PDCCH-отслеживания представляют собой периоды PDCCH-отслеживания, сконфигурированные посредством информации конфигурации пространства поиска поисковых вызовов, которые не перекрываются с одним или более UL-символов, определенных посредством информации TDD-конфигурации, и выполнять отслеживание PDCCH, адресованного временному идентификатору радиосети для поисковых вызовов (P-RNTI), по меньшей мере, в одном периоде PDCCH-отслеживания для поисковых вызовов в период поисковых вызовов, соответствующий идентифицированному индексу периода поисковых вызовов.

[13] В соответствии с другим аспектом настоящего раскрытия сущности, предусмотрена базовая станция в системе беспроводной связи. Базовая станция включает в себя приемо-передающее устройство и контроллер, соединенный с приемо-передающим устройством и выполненный с возможностью передавать информацию конфигурации дуплекса с временным разделением каналов (TDD), включенную в блок 1 системной информации (SIB1), передавать информацию конфигурации пространства поиска поисковых вызовов, идентифицировать кадр поисковых вызовов и индекс периода поисковых вызовов для передачи поисковых вызовов, идентифицирует периоды отслеживания физического канала управления нисходящей линии связи (PDCCH) на основе информации TDD-конфигурации и информации конфигурации пространства поиска поисковых вызовов, причем идентифицированные периоды PDCCH-отслеживания представляют собой периоды PDCCH-отслеживания, сконфигурированные посредством информации конфигурации пространства поиска поисковых вызовов, которые не перекрываются с одним или более UL-символов, определенных посредством информации TDD-конфигурации, и передавать PDCCH для поисковых вызовов с использованием временного идентификатора радиосети для поисковых вызовов (P-RNTI), по меньшей мере, в одном периоде PDCCH-отслеживания для поисковых вызовов в идентифицированные периоды PDCCH-отслеживания, соответствующие идентифицированному индексу периода поисковых вызовов.

Преимущества изобретения

[14] Согласно вариантам осуществления настоящего раскрытия сущности, при выполнении произвольного доступа для того, чтобы выполнять восстановление после сбоя луча в системе беспроводной связи, UE может передавать данные в Msg3-буфере после выполнения произвольного доступа и предотвращать потери данных. Согласно вариантам осуществления, базовая станция может передавать сообщение поисковых вызовов в DRX-цикле без задержки, и может разрешаться неопределенность периодов PDCCH-отслеживания между бездействующими/неактивными UE и соединенным UE.

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

[15] Вышеуказанные и другие примерные аспекты, признаки и преимущества конкретных вариантов осуществления раскрытия сущности должны становиться более понятными из нижеприведенного описания, рассматриваемого вместе с прилагаемыми чертежами, на которых:

[16] Фиг. 1 иллюстрирует структуру LTE-системы согласно некоторым вариантам осуществления раскрытия сущности;

[17] Фиг. 2 иллюстрирует структуры протоколов радиосвязи в LTE- и NR-системах согласно некоторым вариантам осуществления раскрытия сущности;

[18] Фиг. 3 иллюстрирует структуры кадра канала нисходящей и восходящей линии связи, когда связь выполняется на основе лучей в NR-системе согласно некоторым вариантам осуществления раскрытия сущности;

[19] Фиг. 4 иллюстрирует процедуры конкурентного и неконкурентного произвольного доступа, выполняемые посредством UE при таком условии, как восстановление после сбоя луча согласно некоторым вариантам осуществления раскрытия сущности;

[20] Фиг. 5 иллюстрирует передачу и прием данных между UE и gNB, когда способ предотвращения потерь данных применяется согласно некоторым вариантам осуществления раскрытия сущности;

[21] Фиг. 6 иллюстрирует процедуру, выполняемую в UE, когда способ предотвращения потерь данных применяется согласно некоторым вариантам осуществления раскрытия сущности;

[22] Фиг. 7 иллюстрирует структуры кадра канала нисходящей и восходящей линии связи, когда связь выполняется на основе лучей в NR-системе согласно некоторым вариантам осуществления раскрытия сущности;

[23] Фиг. 8 иллюстрирует процедуры конкурентного и неконкурентного произвольного доступа, выполняемые посредством UE при таком условии, как восстановление после сбоя луча согласно некоторым вариантам осуществления раскрытия сущности;

[24] Фиг. 9 иллюстрирует передачу и прием данных между UE и gNB, когда способ предотвращения потерь отчета о состоянии буфера и отчета о запасе мощности применяется согласно некоторым вариантам осуществления раскрытия сущности;

[25] Фиг. 10 иллюстрирует процедуру UE, когда способ предотвращения потерь отчета о состоянии буфера и отчета о запасе мощности применяется согласно некоторым вариантам осуществления раскрытия сущности;

[26] Фиг. 11 иллюстрирует конфигурацию UE в системе беспроводной связи согласно некоторым вариантам осуществления раскрытия сущности; и

[27] Фиг. 12 иллюстрирует конфигурацию ENB в системе беспроводной связи согласно некоторым вариантам осуществления раскрытия сущности.

[28] Фиг. 13 иллюстрирует вариант осуществления определения PO в DRX-цикле согласно варианту осуществления способа 1.

[29] Фиг. 14 иллюстрирует пример PF, отслеживаемых посредством UE, определенного посредством способа 1.

[30] Фиг. 15 иллюстрирует процедуру определения PO в DRX-цикле согласно варианту осуществления способа 2-1.

[31] Фиг. 16 иллюстрирует пример PF и PO, отслеживаемых посредством UE, определенного посредством этого способа 2-1.

[32] Фиг. 17 иллюстрирует процедуру определения PO в DRX-цикле согласно варианту осуществления способа 2-2.

[33] Фиг. 18 иллюстрирует пример PO, отслеживаемых посредством UE, определенного посредством способа 2-2.

[34] Фиг. 19 иллюстрирует процедуру определения PO в DRX-цикле согласно варианту осуществления способа 3-1.

[35] Фиг. 20 иллюстрирует пример PO, отслеживаемых посредством UE, определенного посредством способа 3-1.

[36] Фиг. 21 иллюстрирует процедуру определения PO в DRX-цикле согласно способу 3-2.

[37] Фиг. 22 иллюстрирует пример PO, отслеживаемых посредством UE, определенного посредством способа 3-2.

[38] Фиг. 23 иллюстрирует процедуру определения PO в DRX-цикле согласно варианту осуществления способа 4-1.

[39] Фиг. 24 иллюстрирует пример периодов PDCCH-отслеживания в PO, соответствующих передаваемым SSB согласно варианту осуществления способа 4-1.

[40] Фиг. 25 иллюстрирует другие примерные периоды PDCCH-отслеживания в PO, соответствующие передаваемым SSB согласно варианту осуществления способа 4-1.

[41] Фиг. 26 иллюстрирует пример преобразования между PO и базовыми наборами для случая Ns=4 и C=2 согласно варианту 2-2-1 осуществления.

[42] Фиг. 27 иллюстрирует пример начальной BWP для SI-приема согласно варианту осуществления настоящего раскрытия сущности.

[43] Фиг. 28 иллюстрирует пример SI-окон для SI-сообщения с учетом нескольких базовых наборов согласно варианту осуществления настоящего раскрытия сущности.

[44] Фиг. 29 иллюстрирует пример SI-окон, в которых gNB передает SI-сообщение.

[45] Фиг. 30 иллюстрирует пример периодов PDCCH-отслеживания для поисковых вызовов, сконфигурированных посредством paging-SearchSpace.

[46] Фиг. 31 иллюстрирует пример TDD-конфигурации посредством tdd-UL-DL-ConfigurationCommon.

[47] Фиг. 32a иллюстрирует пример периодов PDCCH-отслеживания для поисковых вызовов и TDD-конфигураций.

[48] Фиг. 32b иллюстрирует пример PO согласно TDD-конфигурациям на фиг. 32a.

[49] Фиг. 33 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно варианту осуществления способа 1.

[50] Фиг. 34 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно варианту осуществления способа 1.

[51] Фиг. 35a иллюстрирует пример периодов PDCCH-отслеживания для поисковых вызовов и TDD-конфигурации на основе tdd-UL-DLConfigurationCommon.

[52] Фиг. 35b иллюстрирует пример достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно способу 1.

[53] Фиг. 36 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно варианту осуществления способа 2.

[54] Фиг. 37 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно варианту осуществления способа 3.

[55] Фиг. 38 иллюстрирует способ конфигурирования TDD-конфигурации посредством gNB согласно варианту осуществления способа 4.

[56] Фиг. 39 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для SI-сообщения согласно варианту осуществления способа 1.

[57] Фиг. 40 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для SI-сообщения согласно варианту осуществления способа 2.

[58] Фиг. 41 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для SI-сообщения согласно варианту осуществления способа 3.

[59] Фиг. 42 иллюстрирует способ конфигурирования TDD-конфигурации посредством gNB согласно варианту осуществления способа 4.

[60] Фиг. 43 иллюстрирует конфигурацию UE согласно вариантам 2 и 3 осуществления.

[61] Фиг. 44 иллюстрирует конфигурацию базовой станции согласно вариантам 2 и 3 осуществления.

Оптимальный режим осуществления изобретения

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

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

[64] Для удобства пояснения, варианты осуществления в данном документе используют термины и слова, заданные в стандарте долгосрочного развития Партнерского проекта третьего поколения (3GPP LTE). Тем не менее, раскрытие сущности не ограничено посредством этих терминов и слов и может в равной степени применяться к системам в соответствии с другими стандартами. В вариантах осуществления, для удобства пояснения термин "усовершенствованный узел B (eNB)" может использоваться взаимозаменяемо с "gNB" ("базовая 5G-станция" или "узел B следующего поколения"). Таким образом, eNB, проиллюстрированный в качестве базовой станции, может означать gNB. Термин "терминал" или "UE" может означать мобильный телефон, устройства с поддержкой стандарта узкополосного Интернета вещей (NB-IoT), датчики и другие устройства беспроводной связи.

[65] Вариант 1 осуществления

[66] Фиг. 1 иллюстрирует структуру LTE-системы согласно некоторым вариантам осуществления раскрытия сущности. NR-система также имеет практически одинаковую структуру.

[67] Ссылаясь на фиг. 1, LTE-система беспроводной связи может включать в себя множество ENB 105, 110, 115 и 120, объект 120 управления мобильностью (MME) и обслуживающий шлюз 130 (S-GW). Абонентское устройство (135) (в дальнейшем в этом документе, называемое "UE" или "терминалом") может осуществлять доступ к внешней сети через ENB 105, 110, 115 и 120 и S-GW 130.

[68] ENB 105, 110, 115 и 120 могут предоставлять беспроводной доступ для UE 135, осуществляющего доступ к сети, которое представляет собой узел доступа сотовой сети. Таким образом, чтобы обслуживать трафик пользователей, ENB 105, 110, 115 и 120 выполняют диспетчеризацию на основе собранной информации состояния, такой как состояния буфера, доступные состояния мощности передачи и состояния канала UE, и поддерживают соединение между UE 135 и базовой сетью (CN).

[69] MME 125 может представлять собой устройство, выполняющее функцию управления мобильностью UE 135 и различные функции управления, и соединяется с множеством ENB, и S-GW (130) может представлять собой устройство, предоставляющее однонаправленный канал передачи данных. MME 125 и S-GW 130 дополнительно выполняют аутентификацию для UE 135, осуществляющего доступ к сети, и управление однонаправленными каналами и обрабатывают пакеты, принимаемые из ENB 105, 110, 115 и 120, либо пакеты, которые должны передаваться в ENB 105, 110, 115 и 120.

[70] Фиг. 2 иллюстрирует структуры беспроводных протоколов в LTE- и NR-системах согласно некоторым вариантам осуществления раскрытия сущности.

[71] Ссылаясь на фиг. 2, UE и ENB могут включать в себя уровни 205 и 240 протокола конвергенции пакетных данных (PDCP), уровни 210 и 235 управления радиосвязью (RLC) и уровни 215 и 230 управления доступом к среде (MAC), соответственно, в беспроводном протоколе LTE-системы.

[72] Уровни 205 и 240 протокола конвергенции пакетных данных (PDCP) выполняют операцию сжатия/восстановления IP-заголовка, и уровни 210 и 235 управления радиосвязью (RLC) переконфигурируют пакетную PDCP-единицу данных (PDU) таким образом, что она имеет надлежащий размер. MAC 215 and 230 соединяются с различными устройствами RLC-уровня, включенными в одно UE, и выполняют операцию мультиплексирования RLC PDU в MAC PDU и демультиплексирования RLC PDU из MAC PDU. PHY-уровни 220 и 225 выполняют операцию канального кодирования и модуляции данных верхнего уровня, чтобы формировать OFDM-символ, и передачи OFDM-символа через радиоканал либо демодуляции и канального декодирования OFDM-символа, принимаемого через радиоканал, и передачи демодулированного и канально декодированного OFDM-символа на верхний уровень.

[73] Дополнительно, физический уровень может использовать гибридный ARQ (HARQ) для того, чтобы корректировать дополнительную ошибку, и приемная сторона может передавать 1-битовую информацию, чтобы указывать то, принимается или нет пакет, передаваемый посредством передающей стороны. 1-битовая информация, указывающая то, принимается или нет пакет, передаваемый посредством передающей стороны, представляет собой HARQ ACK/NACK-информацию.

[74] HARQ ACK/NACK-информация нисходящей линии связи для передачи данных по восходящей линии связи может передаваться через физический канал, такой как физический канал индикатора гибридного ARQ (PHICH) в LTE. Поскольку асинхронный HARQ применяется в NR, может определяться то, требуется повторная передача или требуется новая передача, через информацию диспетчеризации соответствующего UE в физическом выделенном канале управления (PDCCH), который представляет собой канал, в котором выделение ресурсов нисходящей/восходящей линии связи выполняется в NR.

[75] HARQ ACK/HARQ-информация восходящей линии связи для передачи по нисходящей линии связи может передаваться через физический канал, такой как физический канал управления восходящей линии связи (PUCCH) или физический совместно используемый канал восходящей линии связи (PUSCH). PUCCH, в общем, передается в восходящей линии связи первичной соты (PCell), описанной ниже, но иногда дополнительно передается во вторичной соте (SCell). В это время, PUCCH, передаваемый в SCell, упоминается как PUCCH SCell.

[76] Хотя не проиллюстрировано, может быть предусмотрен уровень управления радиоресурсами (RRC) выше PDCP-уровня каждого из UE и ENB, и RRC-уровень может обмениваться сообщением управления связанной с доступом и измерением конфигурацией с тем, чтобы управлять радиоресурсами.

[77] Между тем, PHY-уровень может включать в себя одну или множество частот/поднесущих, и технология для одновременного конфигурирования и использования множества частот упоминается как агрегирование несущих (CA). CA может значительно увеличивать объем передачи посредством числа поднесущих дополнительно с использованием первичной несущей и одной или множества поднесущих, что находится за рамками традиционной технологии, в которой только одна поднесущая используется для связи между UE и ENB (E-UTRAN-узлом B, eNB). Между тем, в LTE, сота в ENB с использованием первичной несущей упоминается как первичная сота (PCell), и сота в ENB с использованием вторичной несущей упоминается как вторичная сота (SCell).

[78] Фиг. 3 иллюстрирует структуры кадра канала нисходящей и восходящей линии связи, когда связь выполняется на основе лучей в NR-системе согласно некоторым вариантам осуществления раскрытия сущности.

[79] Ссылаясь на фиг. 3, ENB 301 может передавать сигналы в форме лучей, чтобы гарантировать более широкое покрытие или передавать более сильные сигналы, как указано посредством ссылок с номерами 311, 313, 315 и 317. Соответственно, UE 303 в соте должно передавать и принимать данные с использованием конкретного луча (луча #1 313 на фиг. 3), передаваемого посредством ENB.

[80] Между тем, состояние UE может разделяться на состояние в виде бездействующего режима (RRC-бездействующего режима) и состояние в виде соединенного режима (RRC-соединенного режима) согласно тому, соединяется или нет UE с ENB. Соответственно, ENB не может знать местоположение UE в состоянии в виде бездействующего режима.

[81] Когда UE в состоянии в виде бездействующего режима переключается на состояние в виде соединенного режима, UE может принимать блоки 321, 323, 325 и 327 сигналов синхронизации (SSB), передаваемые посредством ENB. SSB представляют собой SSB-сигналы, передаваемые периодически согласно периоду, сконфигурированному посредством eNB, и каждый SSB может разделяться на сигнал 341 первичной синхронизации (PSS), сигнал 343 вторичной синхронизации (SSS) и физический широковещательный канал 345 (PBCH).

[82] Фиг. 3 предполагает сценарий, в котором SSB передается для каждого луча. Например, предполагается, что SSB #0 321 передается с использованием луча #0 311, SSB #1 323 передается с использованием луча #1 313, SSB #2 325 передается с использованием луча #2 315, и SSB #3 327 передается с использованием луча #3 317. Хотя фиг. 3 предполагает то, что UE в бездействующем режиме расположено в луче #1, даже когда UE в соединенном режиме выполняет произвольный доступ, UE может выбирать SSB, принимаемый в момент времени, в который произвольный доступ.

[83] Согласно такому предположению, что UE расположено в луче #1, UE принимает SSB #1, передаваемый через луч #1 на фиг. 3. При приеме SSB #1, UE может получать физический идентификатор соты (PCI) ENB через PSS и SSS и принимать PBCH и в силу этого идентифицировать идентификатор (т.е. #1) текущего принимаемого SSB, местоположение, в котором текущий SSB принимается в пределах кадра в 10 мс, и номер системного кадра (SFN) SSB внутри SFN, имеющего период в 10,24 секунды.

[84] PBCH может включать в себя блок главной информации (MIB) и предоставлять информацию, указывающую местоположение, в котором блок системной информации тип 1 (SIB1) для широковещательной передачи более подробной конфигурационной информации сот принимается через MIB. При приеме SIB1, UE может знать общее число SSB, передаваемых посредством ENB, и обнаруживать местоположение периода физического канала с произвольным доступом (PRACH) для выполнения произвольного доступа (более конкретно, для передачи преамбулы, которая представляет собой физический сигнал, специально спроектированный с возможностью выполнять синхронизацию в восходящей линии связи), чтобы переключаться на состояние в виде соединенного режима (фиг. 3 предполагает сценарий выделения каждую 1 мс: 330-339).

[85] Дополнительно, UE может знать преобразованный PRACH-период из числа PRACH-периодов и SSB-индекс, в который PRACH-период преобразуется на основе информации. Например, фиг. 3 предполагает сценарий, в котором PRACH-период выделяется каждую 1 мс, и сценарий, в котором 1/2 SSB выделяются в расчете на PRACH-период (т.е. 2 PRACH-периода в расчете на SSB). Соответственно, фиг. 3 иллюстрирует сценарий, в котором 2 RPACH-периода выделяются в расчете на SSB с начала PRACH-периода начиная согласно SFN. Таким образом, в сценарии, PRACH-периоды выделяются для SSB #0, как указано посредством ссылок с номерами 330 и 331, и PRACH-периоды выделяются для SSB #1, как указано посредством ссылок с номерами 332 и 333. После того, как PRACH-периоды сконфигурированы для всех SSB, PRACH-период может выделяться для первого CCB снова, как указано посредством ссылок с номерами 338 и 339.

[86] Соответственно, UE может распознавать PRACH-периоды 332 и 333 для SSB #1 и передавать преамбулу произвольного доступа в текущий самый ранний PRACH-период из числа PRACH-периодов 332 и 333, соответствующих SSB #1 (например, 332). Поскольку ENB принимает преамбулу в PRACH-периоде 332, ENB может знать то, что соответствующее UE выбирает SSB #1, и передавать преамбулу и в силу этого передавать и принимать данные через соответствующий луч в следующем произвольном доступе.

[87] Между тем, даже когда UE в соединенном состоянии перемещается из текущего (исходного) ENB в назначенный (целевой) ENB по причине передачи обслуживания, UE может выполнять произвольный доступ для целевого ENB и выполнять операцию выбора SSB и передачи преамбулы произвольного доступа или данных, как описано со ссылкой на фиг. 3.

[88] Дополнительно, при передаче обслуживания, команда для передачи обслуживания от исходного ENB целевому ENB может передаваться в UE, и соответствующий идентификатор UE-выделенной преамбулы произвольного доступа может выделяться сообщению команды передачи обслуживания для каждого SSB целевого ENB, который должен использоваться, когда выполняется произвольный доступ к целевому ENB.

[89] В это время, ENB может не выделять идентификаторы выделенных преамбул произвольного доступа для всех лучей (согласно текущему местоположению UE), и, соответственно, выделенные преамбулы произвольного доступа могут не выделяться некоторым SSB (например, выделенные преамбулы произвольного доступа выделяются только лучам #2 и #3). Если выделенная преамбула произвольного доступа не выделяется SSB, который UE выбирает для передачи преамбулы, UE случайно выбирает преамбулу конкурентного произвольного доступа и выполняет произвольный доступ.

[90] Например, фиг. 3 может использовать сценарий, в котором UE первоначально находится в луче #1 и выполняет произвольный доступ, но сбоит при произвольном доступе, а затем UE расположено в луче #3 и передает выделенную преамбулу при передаче преамбулы произвольного доступа снова. Таким образом, когда повторная передача преамбулы выполняется, процедура конкурентного произвольного доступа и процедура неконкурентного произвольного доступа могут сосуществовать в одной процедуре произвольного доступа согласно тому, выделяется или нет выделенная преамбула произвольного доступа выбранному SSB в каждой передаче преамбулы.

[91] Фиг. 4 иллюстрирует процедуры конкурентного и неконкурентного произвольного доступа, выполняемые посредством UE при таком условии, как восстановление после сбоя луча согласно некоторым вариантам осуществления раскрытия сущности.

[92] Процедура произвольного доступа может включать в себя процедуру конкурентного произвольного доступа и процедуру неконкурентного произвольного доступа, и процедура неконкурентного произвольного доступа может иметь процедуру, в которой gNB выделяет выделенные ресурсы произвольного доступа для того, чтобы обеспечивать возможность UE выполнять неконкурентный произвольный доступ.

[93] Вышеуказанные выделенные ресурсы произвольного доступа могут представлять собой конкретный индекс преамбулы и/или PRACH-ресурсы в конкретное время/на конкретной частоте. Информация для выделения выделенных ресурсов произвольного доступа может выделяться через PDCCH или передаваться через сообщение на RRC-уровне. Сообщение на RRC-уровне может включать в себя такое сообщение, как RRCReconfiguration (например, в случае передачи обслуживания). Если предусмотрены выделенные ресурсы произвольного доступа, выделяемые посредством gNB в SSB/CSI-RS, выбранном для процедуры произвольного доступа, в данный момент выполняемой посредством UE, UE передает преамбулу произвольного доступа через выделяемые выделенные ресурсы произвольного доступа.

[94] В неконкурентном произвольном доступе, когда предусмотрена преамбула, передаваемая посредством UE в RAR-сообщении, описанном ниже, UE определяет то, что произвольный доступ успешно завершается, и завершает процедуру произвольного доступа.

[95] Между тем, как проиллюстрировано на фиг. 3, может рассматриваться сценарий, в котором UE передает и принимает сигнал в конкретном луче, но сбоит при использовании текущего используемого луча по причине перемещения UE, и в силу этого выполняет восстановление после сбоя при использовании луча в одном ENB, и он упоминается как процедура восстановления после сбоя луча. Процедура произвольного доступа может использоваться для процедуры восстановления после сбоя луча. В процедуре восстановления после сбоя луча, gNB может выделять выделенные ресурсы произвольного доступа, соответствующие восстановленному лучу, и UE, принимающее выделенные ресурсы произвольного доступа, соответствующие восстановленному лучу, может выполнять неконкурентный произвольный доступ. Если gNB не выделяет выделенные ресурсы, UE может выполнять конкурентный произвольный доступ.

[96] Фиг. 4 предполагает сценарий, в котором UE выполняет произвольный доступ для восстановления после сбоя луча.

[97] Таким образом, может предполагаться сценарий, в котором произвольный доступ инициируется, с тем чтобы выполнять восстановление после сбоя луча, поскольку интенсивность сигнала луча, в данный момент передаваемого и принимаемого посредством UE 401, понижается, на этапе 411. UE определяет то, какой луч используется для того, чтобы передавать и принимать данные, включающие в себя произвольный доступ, и выбирает SSB на этапе 413.

[98] Ниже описывается способ, посредством которого UE выбирает SSB. GNB 403 конфигурирует пороговое значение, которое должно использоваться для восстановления после сбоя луча, и конфигурирует выделенные ресурсы произвольного доступа для каждого SSB. Если SSB, для которого сконфигурированы выделенные ресурсы произвольного доступа, существует в SSB, интенсивность сигнала которых выше порогового значения из числа принимаемых SSB, UE выбирает SSB, для которого сконфигурированы выделенные ресурсы произвольного доступа.

[99] Например, если UE принимает все из SSB #0, SSB #1 и SSB #2, но gNB конфигурирует выделенные ресурсы произвольного доступа только для SSB #1 и SSB #2, и только интенсивности сигнала для SSB #0 и SSB #1 выше порогового значения, UE выбирает SSB #1 и выполняет неконкурентный произвольный доступ. Если только интенсивность сигнала для SSB #0 выше порогового значения в вышеприведенном примере, UE выбирает SSB #0 и выполняет конкурентный произвольный доступ. В сценарии, проиллюстрированном на фиг. 4, описывается процедура, в которой выбирается луч (например, SSB #0 в вышеприведенном примере), в котором не сконфигурированы выделенные ресурсы, и выполняется конкурентный произвольный доступ, поскольку луч, в котором сконфигурированы выделенные ресурсы, не может удовлетворять условию, на этапе 413.

[100] Как описано выше, если UE выбирает SSB, UE может знать PRACH-период, преобразованный в выбранный SSB, и, соответственно, передавать преамбулу произвольного доступа в gNB через соответствующий PRACH-период на этапе 415. Поскольку выделенная преамбула не выделяется выбранному SSB, UE выполняет конкурентный произвольный доступ, как описано выше. Таким образом, UE случайно выбирает и передает один из идентификаторов конкурентных преамбул.

[101] Дополнительно, одно или более UE могут одновременно передавать преамбулы произвольного доступа через PRACH-период (т.е. другое UE может случайно выбирать один из идентификаторов конкурентных преамбул и передавать его в соответствующие ресурсы, и множество UE могут выбирать такой же индекс преамбулы).

[102] PRACH-ресурсы могут существовать по одному субкадру, либо могут использоваться только некоторые символы в одном субкадре. Информация относительно PRACH-ресурсов может быть включена в системную информацию, широковещательно передаваемую посредством gNB, либо в конфигурационную информацию в команде передачи обслуживания, и UE может знать то, какие временные и частотные ресурсы используются для передачи преамбул, через информацию относительно PRACH-ресурсов. Преамбулы произвольного доступа представляют собой конкретные последовательности, специально спроектированные с возможностью приема, даже если они передаются до того, как UE и gNB полностью синхронизируются, и может быть предусмотрено множество идентификаторов (индексов) преамбул согласно стандартам. Если предусмотрено множество идентификаторов преамбул, преамбула, передаваемая посредством UE, может случайно выбираться посредством UE из множества преамбул либо может представлять собой конкретную преамбулу, обозначенную посредством gNB.

[103] Между тем, если gNB конфигурирует специальный сигнал, который должен измеряться, когда UE в состоянии в виде соединенного режима выполняет произвольный доступ, UE может выбирать PRACH-период на основе соответствующего специального сигнала, который должен измеряться. Соответствующий специальный сигнал, который должен измеряться, может представлять собой SSB или опорный сигнал информации состояния канала (CSI-RS). Например, если передача обслуживания выполняется вследствие перемещения UE, gNB может конфигурировать PRACH-период, преобразованный в SSB или CSI-RS целевого gNB в команде передачи обслуживания, и, соответственно, UE измеряет сконфигурированный сигнал, и определять то, какой PRACH-период используется для передачи преамбулы произвольного доступа.

[104] Если gNB принимает преамбулу (или преамбулу, передаваемую посредством другого UE), gNB передает ответ по произвольному доступу (в дальнейшем в этом документе, называемый RAR) на преамбулу в UE на этапе 417. RAR-сообщение включает в себя информацию идентификатора преамбулы, используемую на этапе 415, информацию коррекции временной синхронизации передачи по восходящей линии связи и информацию выделения ресурсов восходящей линии связи, а также информацию временного идентификатора UE, которая должна использоваться на следующем этапе (т.е. на этапе 421). Например, если множество UE передают различные преамбулы и выполняют попытку произвольного доступа на этапе 415, информация идентификатора преамбулы передается, чтобы информировать в отношении преамбулы, на которую отвечает RAR-сообщение. Информация выделения ресурсов восходящей линии связи представляет собой подробную информацию относительно ресурсов, которые должны использоваться посредством UE на этапе 421, и включает в себя физическое местоположение и размер ресурсов, схему декодирования и кодирования (схему модуляции и кодирования (MCS)) и информацию управления мощностью передачи. Если UE, передающее преамбулу, первоначально осуществляет доступ к gNB, UE не имеет идентификатора, выделенного посредством gNB для связи с gNB, так что информация временного идентификатора UE представляет собой значение, передаваемое для начального доступа UE.

[105] RAR-сообщение должно передаваться в пределах предварительно определенного периода после предварительно определенного времени от передачи преамбулы, и предварительно определенный период упоминается как "RAR-окно". RAR-окно начинается в момент времени после предварительно определенного времени от передачи первой преамбулы. Предварительно определенное время может иметь значение в единицах субкадров (4 мс) или меньшее значение. Длина RAR-окна сконфигурирована внутри системного информационного сообщения, широковещательно передаваемого посредством gNB, или внутри сообщения команды передачи обслуживания.

[106] Между тем, когда RAR-сообщение передается, gNB диспетчеризует соответствующее RAR-сообщение через PDCCH, и соответствующая информация диспетчеризации скремблируется с использованием временного идентификатора радиосети с произвольным доступом (RA-RNTI). RA-RNTI преобразуется в PRACH-ресурсы, используемые для того, чтобы передавать сообщение на этапе 415, и UE, передающее преамбулу в конкретные PRACH-ресурсы, может выполнять попытку PDCCH-приема на основе RA-RNTI и определять то, предусмотрено или нет RAR-сообщение, соответствующее преамбуле, передаваемой посредством UE. Таким образом, если RAR-сообщение представляет собой ответ на преамбулу, передаваемую посредством UE на этапе 415, как проиллюстрировано на чертеже (фиг. 14), RA-RANTI, используемый для диспетчеризации информации RAR-сообщения, включает в себя информацию относительно соответствующей передачи на этапе 415. С этой целью, RA-RANTI может вычисляться посредством следующего уравнения.

[107] уравнение 1

[108] RA-RNTI=1+s_id+14*t_id+14*80*f_id+14*80*8*ul_carrier_id

[109] В уравнении 1, s_id обозначает индекс, соответствующий первому OFDM-символу, в котором начинается передача преамбулы на этапе 415, и имеет значение 0≤s_id<14 (т.е. меньшее максимального числа OFDM в одном временном кванте); t_id обозначает индекс, соответствующий первому временному кванту, в котором начинается передача преамбулы на этапе 415, и имеет значение 0≤t_id<80 (т.е. максимальное число временных квантов в одном системном кадре (40 мс)); f_id обозначает PRACH-ресурсы на частоте, посредством которой передается преамбула, переданная на этапе 415, и имеет значение 0≤f_id<8 (т.е. меньшее максимального числа PRACH на частоте в течение одного и того же времени); ul_carrier_id обозначает фактор для идентификации того, передается преамбула в нормальной восходящей линии связи (NUL) (в этом случае, 0), либо преамбула передается в дополнительной восходящей линии связи (SUL) (в этом случае, 1), если две поднесущие используются для восходящей линии связи в одной соте.

[110] На фиг. 4, предполагается сценарий, в котором UE принимает RAR-сообщение с использованием RA-RANTI, соответствующего передаче преамбулы 415, и ответ на идентификатор преамбулы, передаваемый посредством UE, включается в RAR-сообщение. Соответственно, UE вставляет сообщение, которое должно передаваться, в Msg3-буфер в UE, так что оно соответствует размеру ресурсов восходящей линии связи для сообщения 3, выделяемого RAR-сообщению на этапе 419. В процедуре произвольного доступа, преамбула упоминается как Msg1, RAR упоминается как Msg2, сообщение, передаваемое посредством UE в восходящей линии связи, упоминается как Msg3, сообщение, принимаемое посредством UE в нисходящей линии связи, упоминается как Msg4, и буфер для сохранения данных, которые должны передаваться через Msg3, упоминается как Msg3.

[111] В сценарии фиг. 4 предполагается, что восстановление после сбоя луча выполняется в соединенном режиме UE. Соответственно, UE может формировать данные, которые должны передаваться посредством UE наряду с данными восходящей линии связи, согласно размеру выделенных ресурсов восходящей линии связи, принимаемых в RAR, причем сформированные данные включают в себя элемент C-RNTI MAC-управления (CE) (MAC CE представляет собой управляющее сообщение на MAC-уровне), включающий в себя C-RNTI-информацию, указывающую то, что UE, в данный момент выполняющее произвольный доступ, представляет собой UE, и передавать сформированные данные на этапе 421.

[112] Тем не менее, фиг. 4 предполагает сценарий, в котором UE сбоит при передаче Msg3 на этапах 421, 423 и 425. UE передает Msg3, запускает ra-ContentionResolutionTimer (таймер разрешения коллизий с произвольным доступом), когда ответ на Msg3 не поступает, до тех пор, пока соответствующий таймер не истекает на этапе 427, определяет то, что Msg3 не передано нормально, и начинает процедуру передачи снова преамбулы произвольного доступа.

[113] Если ra-ContentionResolutionTimer истекает, UE выбирает SSB снова в момент времени, в который таймер истекает, чтобы повторно передавать преамбулу. На этапах 429-437 по фиг. 4, сценарий, в котором SSB, который UE выбирает снова, представляет собой SSB, которому выделена область выделенных ресурсов произвольного доступа, такой как SSB #1 в вышеприведенном примере на этапе 429. UE передает выделенную преамбулу через PRACH-период, соответствующий выбранному SSB, на этапе 431. Если неконкурентный произвольный доступ выполняется при восстановлении после сбоя луча, как указано в сценарии этапа 429, UE принимает PDCCH для выделения ресурсов нисходящей или восходящей линии связи вместо RAR в качестве сообщения, соответствующего передаваемой преамбуле, на этапе 433. Более конкретно, когда UE принимает связанную с восстановлением после сбоя луча конфигурацию из gNB, UE отдельно принимает местоположение ресурсов (recoverySearchSpace), в котором принимается PDCCH для выделения ресурсов нисходящей или восходящей линии связи. При приеме PDCCH, скремблированного с C-RNTI, который представляет собой уникальный идентификатор в соте UE для выделения ресурсов нисходящей или восходящей линии связи в соответствующем местоположении ресурсов, на этапе 433, UE определяет то, что произвольный доступ завершается, на этапе 435.

[114] Между тем, когда UE выполняет конкурентный произвольный доступ (процедуру на этапах 411-427), не, только C-RNTI MAC CE, но также и данные восходящей линии связи включаются в Msg3-буфер. Если UE принимает PDCCH для нисходящей линии связи в качестве Msg2 в процедуре неконкурентного произвольного доступа (в процедуре на этапах 429-435), UE не имеет ресурсов, которые должны передаваться в восходящей линии связи, и завершает процедуру произвольного доступа и в силу этого удаляет Msg3-буфер. Как описано выше, если Msg3 удаляется, UE теряет данные восходящей линии связи, которые находятся в Msg3-буфере на этапе 437.

[115] Фиг. 5 иллюстрирует передачу и прием данных между UE и gNB, когда способ предотвращения потерь данных применяется согласно некоторым вариантам осуществления раскрытия сущности.

[116] На фиг. 5, описание, которое является таким же как описание на фиг. 4, опускается. Этапы 511-535 по фиг. 1E являются такими же как этапы 411-435 по фиг. 4. Таким образом, фиг. 5 предполагает сценарий, в котором UE 501 выполняет конкурентный произвольный доступ на этапах 511-527, выполняет неконкурентный произвольный доступ на этапах 529-535, принимает PDCCH для выделения ресурсов нисходящей линии связи и затем завершает процедуру произвольного доступа на этапе 535.

[117] UE согласно некоторым вариантам осуществления раскрытия сущности определяет то, имеются или нет данные в Msg3-буфере, когда произвольный доступ завершается, то, принимает UE PDCCH, указываемый посредством C-RNTI UE в recoverSearchSpace, и завершает произвольный доступ либо нет (либо то, начинает или нет произвольный доступ выполнять восстановление после сбоя луча, и произвольный доступ завершается на основе неконкурентного), и то, не выделяются либо выделяются ресурсы восходящей линии связи PDCCH, указываемому посредством C-RNTI (либо то, выделяются или нет ресурсы нисходящей линии связи).

[118] Если вышеуказанные условия удовлетворяются для каждой MAC SDU в MAC PDU в Msg3-буфере, UE информирует соответствующий RLC-уровень (объект) в отношении того, что передача сбоит и в силу этого не выполняется, чтобы предотвращать потери данных в Msg3-буфере, как описано выше на этапе 537.

[119] В это время, MAC-уровень может использовать идентификатор логического канала (LCID), чтобы идентифицировать RLC-уровень, из которого поступает каждая MAC SDU. Помимо этого, предусмотрены PDCP-объект и RLC-объект, соответствующие однонаправленному радиоканалу передачи данных (DRB) выше на MAC-уровне, и MAC принимает данные из каждого RLC-объекта, чтобы передавать данные восходящей линии связи.

[120] RLC-уровень, принимающий уведомление относительно сбоя при передаче из MAC-уровня, может повторно передавать RLC SDU, либо сегменты RLC SDU, включенной в RLC PDU через соответствующее уведомление относительно сбоя, предоставляются на 539. Более конкретно, RLC-уровень может включать в себя RLC AM и RLC UM согласно типу данных. RLC AM представляет собой RLC-уровень, допускающий передачу пакета снова, чтобы предотвращать потери данных, если подтверждение приема передачи не принимается из приемной стороны, и RLC UM представляет собой RLC-уровень, выполняющий только однонаправленную передачу без отдельного подтверждения приема передачи. Если MAC SUD в данных Msg3 представляет собой пакет, принадлежащий RLC AM, RLC AM может выполнять повторную передачу после приема уведомления относительно сбоя при передаче. Если MAC SDU в данных Msg3 представляет собой пакет, принадлежащий RLC UM, RLC UM может отбрасывать соответствующий пакет и не выполнять повторную передачу либо может сохранять соответствующий пакет и повторно передавать пакет даже в случае RLC UM после приема уведомления относительно сбоя при передаче. Если RLC-уровень повторно передает пакет, UE может передавать соответствующий пакет, когда UE принимает ресурсы восходящей линии связи из gNB 503 на этапе 541.

[121] Между тем, Msg3-буфер может включать не только общие данные, но также и релевантный MAC CE для отчета о состоянии буфера (BSR) и/или релевантный MAC CE для отчета о запасе мощности (PHR). Соответственно, если предусмотрен MAC CE, связанный с BSR или PHR, в Msg3, MAC CE может быть потерян вследствие удаления Msg3-буфера, и в силу этого состояние буфера UE и оставшаяся информация мощности восходящей линии связи могут не передаваться в gNB.

[122] Условия для инициирования BSR и PHR, соответственно, уже существуют. Например, если данные, имеющие высокий приоритет, формируются, BSR может инициироваться, и UE может передавать BSR в gNB, и в силу этого gNB может знать то, что поступают данные, имеющие высокий приоритет.

[123] В некоторых вариантах осуществления раскрытия сущности, в дополнение к традиционным инициирующим условиям, новое условие для инициирования BSR или PHR, даже когда MAC CE, связанный с BSR или PHR, существует в Msg3-буфере и в силу этого потерян. Например, если MAC CE, связанный с BSR, существует в Msg3-буфере и потерян вследствие удаления Msg3-буфера, BSR может заново инициироваться. Если MAC CE, связанный с PHR, существует в Msg3-буфере и потерян вследствие удаления Msg3-буфера, PHR может заново инициироваться.

[124] Через добавление условия для инициирования BSR или PHR, UE может предотвращать потери BSR- или PHR-данных.

[125] Фиг. 6 иллюстрирует процедуру, выполняемую в UE, когда способ предотвращения потерь данных применяется согласно некоторым вариантам осуществления раскрытия сущности.

[126] На фиг. 6, предполагается сценарий, в котором UE в соединенном состоянии выполняет произвольный доступ и завершает произвольный доступ, чтобы выполнять восстановление после сбоя луча, на этапе 603.

[127] Когда произвольный доступ завершается аналогично этапу 603, UE, соответственно, определяет то, имеются или нет данные в Msg3-буфере, то, принимает UE PDCCH, указываемый посредством C-RNTI UE в recoverSearchSpace, и завершает произвольный доступ либо нет (либо то, начинает или нет произвольный доступ выполнять восстановление после сбоя луча, и произвольный доступ завершается на основе неконкурентного), и то, не выделяются либо выделяются ресурсы восходящей линии связи PDCCH, указываемому посредством C-RNTI (либо то, выделяются или нет ресурсы нисходящей линии связи), на этапе 605.

[128] Если вышеуказанные условия удовлетворяются для каждой MAC SDU в MAC PDU в Msg3-буфере, UE информирует соответствующий RLC-уровень (объект) в отношении того, что передача сбоит и в силу этого не выполняется, чтобы предотвращать потери данных в Msg3-буфере, как описано выше на этапе 607.

[129] В это время, MAC-уровень может использовать идентификатор логического канала (LCID), чтобы идентифицировать RLC-уровень, из которого исходит каждая MAC SDU. Помимо этого, предусмотрены PDCP-объект и RLC-объект, соответствующие однонаправленному радиоканалу передачи данных (DRB) выше на MAC-уровне, и MAC принимает данные из каждого RLC, чтобы передавать данные восходящей линии связи.

[130] RLC-уровень, принимающий уведомление относительно сбоя при передаче из MAC-уровня, может повторно передавать RLC SDU, либо сегменты RLC SDU, включенной в RLC PDU через соответствующее уведомление относительно сбоя, предоставляются. Более конкретно, RLC-уровень может включать в себя RLC AM и RLC UM согласно типу данных. RLC AM представляет собой RLC-уровень, допускающий передачу пакета снова, чтобы предотвращать потери данных, если подтверждение приема передачи не принимается из приемной стороны, и RLC UM представляет собой RLC-уровень, выполняющий только однонаправленную передачу без отдельного подтверждения приема передачи. Если MAC SUD в данных Msg3 представляет собой пакет, принадлежащий RLC AM, RLC AM может выполнять повторную передачу после приема уведомления относительно сбоя при передаче. Если MAC SDU в данных Msg3 представляет собой пакет, принадлежащий RLC UM, RLC UM может отбрасывать соответствующий пакет и не выполнять повторную передачу либо может сохранять соответствующий пакет и повторно передавать пакет даже в случае RLC UM после приема уведомления относительно сбоя при передаче. Если RLC-уровень повторно передает пакет, UE может передавать соответствующий пакет, когда UE принимает ресурсы восходящей линии связи из gNB.

[131] Между тем, Msg3-буфер может включать не только общие данные, но также и релевантный MAC CE для отчета о состоянии буфера (BSR) и/или релевантный MAC CE для отчета о запасе мощности (PHR). Соответственно, если предусмотрен MAC CE, связанный с BSR или PHR, в Msg3, MAC CE может быть потерян вследствие удаления Msg3-буфера, и в силу этого состояние буфера UE и оставшаяся информация мощности восходящей линии связи могут не передаваться в gNB.

[132] Условия для инициирования BSR и PHR, соответственно, уже существуют. Например, если данные, имеющие высокий приоритет, формируются, BSR может инициироваться, и UE может передавать BSR в gNB, и в силу этого gNB может знать то, что поступают данные, имеющие высокий приоритет.

[133] В некоторых вариантах осуществления раскрытия сущности, в дополнение к традиционным инициирующим условиям, новое условие для инициирования BSR или PHR, даже когда MAC CE, связанный с BSR или PHR, в Msg3-буфере потерян. Например, если MAC CE, связанный с BSR, существует в Msg3-буфере и потерян вследствие удаления Msg3-буфера, BSR может заново инициироваться. Если MAC CE, связанный с PHR, существует в Msg3-буфере и потерян вследствие удаления Msg3-буфера, PHR может заново инициироваться в 607.

[134] Через добавление условия для инициирования BSR или PHR, UE может предотвращать потери BSR- или PHR-данных.

[135] В дальнейшем в этом документе, способ предотвращения BSR- и PHR-потерь описывается со ссылкой на фиг. 7-10.

[136] Фиг. 7 иллюстрирует структуры кадра канала нисходящей и восходящей линии связи, когда связь выполняется на основе лучей в NR-системе согласно некоторым вариантам осуществления раскрытия сущности.

[137] Ссылаясь на фиг. 7, ENB 701 может передавать сигналы в форме лучей, чтобы гарантировать более широкое покрытие или передавать более сильные сигналы, как указано посредством ссылок с номерами 711, 713, 715 и 717. Соответственно, UE 703 в соте должно передавать и принимать данные с использованием конкретного луча (луча #2 713 на фиг. 7), передаваемого посредством ENB.

[138] Между тем, состояние UE может разделяться на состояние в виде бездействующего режима (RRC-бездействующего режима) и состояние в виде соединенного режима (RRC-соединенного режима) согласно тому, соединяется или нет UE с ENB. Соответственно, ENB не может знать местоположение UE в состоянии в виде бездействующего режима.

[139] Если UE в состоянии в виде бездействующего режима переключается на состояние в виде соединенного режима, UE может принимать блоки 721, 723, 725 и 727 сигналов синхронизации (SSB), передаваемые посредством ENB. SSB периодически представляют собой SSB-сигналы, передаваемые согласно периоду, сконфигурированному посредством eNB, и каждый SSB может разделяться на сигнал 741 приоритетной синхронизации (PSS), сигнал 743 вторичной синхронизации (SSS) и физический широковещательный канал 745 (PBCH).

[140] Фиг. 7 предполагает сценарий, в котором SSB передается для каждого луча. Например, предполагается, что SSB #0 721 передается с использованием луча #0 711, SSB #1 723 передается с использованием луча #1 713, SSB #2 725 передается с использованием луча #2 715, и SSB #3 727 передается с использованием луча #3 717. Хотя фиг. 7 предполагает то, что UE в бездействующем режиме расположено в луче #1, даже когда UE в соединенном режиме выполняет произвольный доступ, UE может выбирать SSB, принимаемый в момент времени, в который произвольный доступ.

[141] Согласно такому предположению, что UE расположено в луче #1, UE принимает SSB #1, передаваемый через луч #1 на фиг. 7. При приеме SSB #1, UE может получать физический идентификатор соты (PCI) ENB через PSS и SSS и принимать PBCH и в силу этого идентифицировать идентификатор (т.е. #1) текущего принимаемого SSB, местоположение, в котором текущий SSB принимается в пределах кадра в 10 мс, и номер системного кадра (SFN) SSB внутри SFN, имеющего период в 10,24 секунды.

[142] PBCH может включать в себя блок главной информации (MIB) и предоставлять информацию, указывающую местоположение, в котором блок системной информации тип 1 (SIB1) для широковещательной передачи более подробной конфигурационной информации сот принимается через MIB. При приеме SIB1, UE может знать общее число SSB, передаваемых посредством ENB, и обнаруживать местоположение периода физического канала с произвольным доступом (PRACH) для выполнения произвольного доступа (более конкретно, для передачи преамбулы, которая представляет собой физический сигнал, специально спроектированный с возможностью выполнять синхронизацию в восходящей линии связи), чтобы переключаться на состояние в виде соединенного режима (фиг. 7 предполагает сценарий выделения каждые 2 мс: 730-739).

[143] Дополнительно, UE может знать преобразованный PRACH-период из числа PRACH-периодов и SSB-индекс, в который PRACH-период преобразуется на основе информации. Например, фиг. 7 предполагает сценарий, в котором PRACH-период выделяется каждую 1 мс, и сценарий, в котором 1/2 SSB выделяются в расчете на PRACH-период (т.е. 2 PRACH-периода в расчете на SSB). Соответственно, фиг. 7 иллюстрирует сценарий, в котором 2 RPACH-периода выделяются в расчете на SSB с начала PRACH-периода начиная согласно SFN. Таким образом, в сценарии, PRACH-периоды выделяются для SSB #0, как указано посредством ссылок с номерами 730 и 731, и PRACH-периоды выделяются для SSB #2, как указано посредством ссылок с номерами 732 и 733. После того, как PRACH-периоды сконфигурированы для всех SSB, PRACH-период может выделяться для первого CCB снова, как указано посредством ссылок с номерами 738 и 739.

[144] Соответственно, UE может распознавать PRACH-периоды 732 и 733 для SSB #1 и передавать преамбулу произвольного доступа в текущий самый ранний PRACH-период из числа PRACH-периодов 732 и 733, соответствующих SSB #1 (например, 732). Поскольку ENB принимает преамбулу в PRACH-периоде 332, ENB может знать то, что соответствующее UE выбирает SSB #1, и передавать преамбулу и, соответственно, передавать и принимать данные через соответствующий луч в следующем произвольном доступе.

[145] Между тем, при перемещении из текущего (исходного) ENB в назначенный (целевой) ENB по причине передачи обслуживания, UE в соединенном состоянии выполняет произвольный доступ к целевому ENB и может выполнять операцию выбора SSB и передачи преамбулы произвольного доступа или данных, как описано со ссылкой на фиг. 7.

[146] Если передача обслуживания выполняется, команда передачи обслуживания передается в UE, чтобы инструктировать UE перемещаться из исходного ENB в целевой ENB, и соответствующий идентификатор UE-выделенной преамбулы произвольного доступа может выделяться сообщению команды передачи обслуживания для каждого SSB целевого ENB, который должен использоваться, когда выполняется произвольный доступ к целевому ENB.

[147] В это время, ENB может не выделять идентификатор выделенной преамбулы произвольного доступа для всех лучей (согласно текущему местоположению UE), и, соответственно, выделенная преамбула произвольного доступа может не выделяться некоторым SSB (например, выделять выделенные преамбулы произвольного доступа только лучам #2 и #3). Если выделенная преамбула произвольного доступа не выделяется SSB, выбранному посредством UE для передачи преамбулы, UE случайно выбирает преамбулу конкурентного произвольного доступа и выполняет произвольный доступ.

[148] Например, фиг. 7 может использовать сценарий, в котором UE первоначально находится в луче #1 и выполняет произвольный доступ, но сбоит при произвольном доступе, а затем UE расположено в луче #3 и передает выделенную преамбулу при передаче преамбулы произвольного доступа снова. Таким образом, когда повторная передача преамбулы выполняется, процедура конкурентного произвольного доступа и процедура неконкурентного произвольного доступа могут сосуществовать в одной процедуре произвольного доступа согласно тому, выделяется или нет выделенная преамбула произвольного доступа выбранному SSB в каждой передаче преамбулы.

[149] Фиг. 8 иллюстрирует процедуры конкурентного и неконкурентного произвольного доступа, выполняемые посредством UE при таком условии, как восстановление после сбоя луча.

[150] На фиг. 8, описание, которое является таким же как описание на фиг. 1D, опускается. Например, этапы 811-835 по фиг. 8 могут соответствовать этапам 411-435 по фиг. 4. Таким образом, фиг. 8 предполагает сценарий, в котором UE выполняет конкурентный произвольный доступ на этапах 811-827, выполняет неконкурентный произвольный доступ на этапах 829-835, принимает PDCCH для выделения ресурсов нисходящей линии связи и затем завершает процедуру произвольного доступа на этапе 835.

[151] Процедура произвольного доступа может включать в себя процедуру конкурентного произвольного доступа и процедуру неконкурентного произвольного доступа, и процедура неконкурентного произвольного доступа может иметь процедуру, в которой gNB выделяет выделенные ресурсы произвольного доступа для того, чтобы обеспечивать возможность UE выполнять неконкурентный произвольный доступ перед произвольным доступом.

[152] Вышеуказанные выделенные ресурсы произвольного доступа могут представлять собой конкретный индекс преамбулы и/или PRACH-ресурсы в конкретное время/на конкретной частоте. Информация для выделения выделенных ресурсов произвольного доступа может выделяться через PDCCH или передаваться через сообщение на RRC-уровне. Сообщение на RRC-уровне может включать в себя такое сообщение, как RRCReconfiguration (например, в случае передачи обслуживания). Если предусмотрены выделенные ресурсы произвольного доступа, выделяемые посредством gNB в SSB/CSI-RS, выбранном для процедуры произвольного доступа, в данный момент выполняемой посредством UE, UE передает преамбулу произвольного доступа через выделяемые выделенные ресурсы произвольного доступа.

[153] В неконкурентном произвольном доступе, когда предусмотрена преамбула, передаваемая посредством UE в RAR-сообщении, описанном ниже, UE определяет то, что произвольный доступ успешно завершается, и завершает процедуру произвольного доступа.

[154] Как проиллюстрировано на фиг. 3, может рассматриваться сценарий, в котором UE передает и принимает сигнал в конкретном луче, но сбоит при использовании текущего используемого луча по причине перемещения UE, и в силу этого выполняет восстановление после сбоя при использовании луча в одном ENB, и он упоминается как процедура восстановления после сбоя луча. Процедура произвольного доступа может использоваться для процедуры восстановления после сбоя луча. В процедуре восстановления после сбоя луча, gNB может выделять выделенные ресурсы произвольного доступа, соответствующие восстановленному лучу, и UE, принимающее выделенные ресурсы произвольного доступа, соответствующие восстановленному лучу, может выполнять неконкурентный произвольный доступ. Если gNB не выделяет выделенные ресурсы, UE может выполнять конкурентный произвольный доступ.

[155] Фиг. 8 предполагает сценарий, в котором UE выполняет произвольный доступ при передаче обслуживания для восстановления после сбоя луча.

[156] Таким образом, может предполагаться сценарий, в котором произвольный доступ инициируется, с тем чтобы выполнять восстановление после сбоя луча, поскольку интенсивность сигнала луча, в данный момент передаваемого и принимаемого посредством UE, понижается, на этапе 811. UE определяет то, какой луч используется для того, чтобы передавать и принимать данные, включающие в себя произвольный доступ, и выбирает SSB на этапе 813.

[157] Ниже описывается способ, посредством которого UE 801 выбирает SSB. GNB 803 конфигурирует пороговое значение, которое должно использоваться для восстановления после сбоя луча, и конфигурирует выделенные ресурсы произвольного доступа для каждого SSB. Если SSB, в котором сконфигурированы выделенные ресурсы произвольного доступа, существует в SSB, интенсивность сигнала которых выше порогового значения из числа принимаемых SSB, UE выбирает SSB, в котором сконфигурированы выделенные ресурсы произвольного доступа.

[158] Например, если UE принимает все из SSB #0, SSB #1 и SSB #2, но gNB конфигурирует выделенные ресурсы произвольного доступа только для SSB #1 и SSB #2, и только интенсивности сигнала для SSB #0 и SSB #1 выше порогового значения на фиг. 3, UE выбирает SSB #1 и выполняет неконкурентный произвольный доступ. Если только интенсивность сигнала для SSB #0 выше порогового значения в вышеприведенном примере, UE выбирает SSB #0 и выполняет конкурентный произвольный доступ. В сценарии, проиллюстрированном на фиг. 8, описывается процедура, в которой выбирается луч (например, SSB #0 в вышеприведенном примере), в котором не сконфигурированы выделенные ресурсы, и выполняется конкурентный произвольный доступ, поскольку луч, в котором сконфигурированы выделенные ресурсы, не может удовлетворять условию, на этапе 813.

[159] Как описано выше, если UE выбирает SSB, UE может знать PRACH-период, преобразованный в выбранный SSB, и, соответственно, передавать преамбулу произвольного доступа в gNB через соответствующий PRACH-период на этапе 815. Поскольку выделенная преамбула не выделяется выбранному SSB, UE выполняет конкурентный произвольный доступ, как описано выше. Таким образом, UE случайно выбирает и передает один из идентификаторов конкурентных преамбул.

[160] В это время, gNB может конфигурировать группы преамбул, чтобы выделять ресурсы восходящей линии связи, имеющие различные размеры, на основе идентификатора преамбулы. Более конкретно, если gNB конфигурирует группы A и B преамбул, UE может выбирать группу B, когда следующее условие удовлетворяется, и может выбирать группу A и затем случайно выбирать преамбулу в выбранной группе, когда следующее условие не удовлетворяется. Если gNB не конфигурирует группу B, UE случайно выбирает преамбулу в группе A.

[161] Условие 1: случай, в котором размер данных, которые должны передаваться через Msg3, превышает пороговое значение ra-Msg3SizeGroupA, сконфигурированное посредством gNB, и в котором измеренное значение потерь в тракте передачи составляет {PCMAX (обслуживающей соты, выполняющей процедуру произвольного доступа) - preambleReceivedTargetPower - (msg3-DeltaPreamble) - messagePowerOffsetGroupB} (т.е. максимальная мощность передачи соты, выполняющей произвольный доступ - preambleReceivedTargetPower, сконфигурированный посредством gNB - константа, определенная согласно преамбуле (msg3-DeltaPreamble) - messagePowerOffsetGroupB, сконфигурированный посредством gNB), или

[162] Условие 2: случай, в котором произвольный доступ выполняется для того, чтобы передавать общий канал управления (CCCH), сформированный в бездействующем состоянии или неактивном состоянии UE, и соответствующее CCCH-сообщение превышает пороговое значение ra-Msg3SizeGroupA, сконфигурированное посредством gNB.

[163] Соответственно, при приеме преамбулы, принадлежащей группе A преамбул, gNB может выделять ресурсы восходящей линии связи в 56 битов. При приеме преамбулы, принадлежащей группе B, gNB может выделять ресурсы восходящей линии связи в 72 бита.

[164] Помимо этого, чтобы не формировать проблему, описанную ниже, UE может не применять условие 1, и gNB может выделять 56-битовые ресурсы не только в случае, в котором группа A преамбул принимается, но также и в случае, в котором выделенная преамбула (т.е. преамбула неконкурентного произвольного доступа) для восстановления после сбоя луча принимается. Альтернативно, UE может непосредственно применять условие 1 и условие 2, но применять условие 1 только к случаю, отличному от восстановления после сбоя луча, так что одни и те же ресурсы восходящей линии связи могут всегда приниматься, когда неконкурентный произвольный доступ и конкурентный произвольный доступ выполняются.

[165] Между тем, одно или более UE могут одновременно передавать преамбулы произвольного доступа через вышеописанный PRACH-период (т.е. другое UE также может случайно выбирать один из идентификатора конкурентной преамбулы через соответствующие ресурсы, и множество UE могут выбирать такой же индекс преамбулы).

[166] PRACH-ресурсы могут существовать по одному субкадру, либо могут использоваться только некоторые символы в одном субкадре. Информация относительно PRACH-ресурсов может быть включена в системную информацию, широковещательно передаваемую посредством gNB, либо в конфигурационную информацию в команде передачи обслуживания, и UE может знать то, какие временные и частотные ресурсы используются для передачи преамбул, через информацию относительно PRACH-ресурсов. Преамбулы произвольного доступа представляют собой конкретные последовательности, специально спроектированные с возможностью приема, даже если они передаются до того, как UE и gNB полностью синхронизируются, и может быть предусмотрено множество идентификаторов (индексов) преамбул согласно стандартам. Если предусмотрено множество идентификаторов преамбул, преамбула, передаваемая посредством UE, может случайно выбираться посредством UE из множества преамбул либо может представлять собой конкретную преамбулу, обозначенную посредством gNB.

[167] Между тем, если gNB конфигурирует специальный сигнал, который должен измеряться, когда UE в состоянии в виде соединенного режима выполняет произвольный доступ, UE может выбирать PRACH-период на основе соответствующего специального сигнала, который должен измеряться. Соответствующий специальный сигнал, который должен измеряться, может представлять собой SSB или опорный сигнал информации состояния канала (CSI-RS). Например, если передача обслуживания выполняется вследствие перемещения UE, gNB может конфигурировать PRACH-период, преобразованный в SSB или CSI-RS целевого gNB в команде передачи обслуживания, и, соответственно, UE измеряет сконфигурированный сигнал, и определять то, какой PRACH-период используется для передачи преамбулы произвольного доступа.

[168] Если gNB принимает преамбулу (или преамбулу, передаваемую посредством другого UE), gNB передает ответ по произвольному доступу (в дальнейшем в этом документе, называемый RAR) на преамбулу в UE на этапе 817. RAR-сообщение включает в себя информацию идентификатора преамбулы, используемую на этапе 815, информацию коррекции временной синхронизации передачи по восходящей линии связи и информацию выделения ресурсов восходящей линии связи, а также информацию временного идентификатора UE, которая должна использоваться на следующем этапе (т.е. на этапе 821). Например, если множество UE передают различные преамбулы и выполняют попытку произвольного доступа на этапе 815, информация идентификатора преамбулы передается, чтобы информировать в отношении преамбулы, на которую отвечает RAR-сообщение. Информация выделения ресурсов восходящей линии связи представляет собой подробную информацию относительно ресурсов, которые должны использоваться посредством UE на этапе 821, и включает в себя физическое местоположение и размер ресурсов, схему декодирования и кодирования (схему модуляции и кодирования (MCS)), используемую для передачи, и информацию управления мощностью передачи. Если UE, передающее преамбулу, первоначально осуществляет доступ к gNB, UE не имеет идентификатора, выделенного посредством gNB для связи с gNB, так что информация временного идентификатора UE представляет собой значение, передаваемое для начального доступа UE.

[169] RAR-сообщение должно передаваться в пределах предварительно определенного периода после предварительно определенного времени от передачи преамбулы, и предварительно определенный период упоминается как "RAR-окно". RAR-окно начинается в момент времени после предварительно определенного времени от передачи первой преамбулы. Предварительно определенное время может иметь значение в единицах субкадров (4 мс) или меньшее значение. Длина RAR-окна сконфигурирована внутри системного информационного сообщения, широковещательно передаваемого посредством gNB, или внутри сообщения команды передачи обслуживания.

[170] Между тем, когда RAR-сообщение передается, gNB диспетчеризует соответствующее RAR-сообщение через PDCCH, и соответствующая информация диспетчеризации скремблируется с использованием временного идентификатора радиосети с произвольным доступом (RA-RNTI). RA-RNTI преобразуется в PRACH-ресурсы, используемые для того, чтобы передавать сообщение на этапе 815, и UE, передающее преамбулу в конкретные PRACH-ресурсы, может выполнять попытку PDCCH-приема на основе RA-RNTI и определять то, предусмотрено или нет RAR-сообщение, соответствующее преамбуле, передаваемой посредством UE. Таким образом, если RAR-сообщение представляет собой ответ на преамбулу, передаваемую посредством UE на этапе 815, как проиллюстрировано на фиг. 8, RA-RANTI, используемый для диспетчеризации информации RAR-сообщения, включает в себя информацию относительно соответствующей передачи на этапе 815. С этой целью, RA-RANTI может получаться посредством следующего уравнения.

[171] уравнение 2

[172] RA-RNTI=1+s_id+14*t_id+14*80*f_id+14*80*8*ul_carrier_id

[173] В уравнении 2, s_id обозначает индекс, соответствующий первому OFDM-символу, в котором начинается передача преамбулы на этапе 815, и имеет значение 0≤s_id<14 (т.е. меньшее максимального числа OFDM в одном временном кванте); t_id обозначает индекс, соответствующий первому временному кванту, в котором начинается передача преамбулы на этапе 815, и имеет значение 0≤t_id<80 (т.е. максимальное число временных квантов в одном системном кадре (40 мс)); f_id обозначает PRACH-ресурсы на частоте, через которую передается преамбула, переданная на этапе 815, и имеет значение 0≤f_id<8 (т.е. меньшее максимального числа PRACH на частоте в течение такого же времени); ul_carrier_id обозначает фактор для идентификации того, передается преамбула в нормальной восходящей линии связи (NUL) (в этом случае, 0), либо преамбула передается в дополнительной восходящей линии связи (SUL) (в этом случае, 1), если две поднесущие используются для восходящей линии связи в одной соте.

[174] На фиг. 8, предполагается сценарий, в котором UE принимает RAR-сообщение с использованием RA-RANTI, соответствующего передаче преамбулы 815, и ответ на идентификатор преамбулы, передаваемый посредством UE, включается в RAR-сообщение. Соответственно, UE вставляет сообщение, которое должно передаваться, в Msg3-буфер в UE, так что оно соответствует размеру ресурсов восходящей линии связи для сообщения 3, выделяемого RAR-сообщению на этапе 819. В процедуре произвольного доступа, преамбула упоминается как Msg1, RAR упоминается как Msg2, сообщение, передаваемое посредством UE в восходящей линии связи, упоминается как Msg3, сообщение, принимаемое посредством UE в нисходящей линии связи, упоминается как Msg4, и буфер для сохранения данных, которые должны передаваться через Msg3, упоминается как Msg3.

[175] В сценарии фиг. 8 предполагается, что восстановление после сбоя луча выполняется в соединенном режиме UE. Соответственно, UE может вставлять элемент C-RNTI MAC-управления (CE) (MAC CE представляет собой управляющее сообщение на MAC-уровне), включающий в себя C-RNTI-информацию, указывающую то, что UE, в данный момент выполняющее произвольный доступ, представляет собой UE, в Msg3, формировать данные, которые должны передаваться посредством UE наряду с данными восходящей линии связи, согласно размеру выделенных ресурсов восходящей линии связи, принимаемых в RAR, и передавать сформированные данные на этапе 821.

[176] Тем не менее, фиг. 8 предполагает сценарий, в котором UE сбоит при передаче Msg3 на этапах 821, 823 и 825. UE передает Msg3, запускает ra-ContentionResolutionTimer (таймер разрешения коллизий с произвольным доступом), когда ответ на Msg3 не поступает, до тех пор, пока соответствующий таймер не истекает на этапе 827, определяет то, что Msg3 не передано нормально, и начинает процедуру передачи снова преамбулы произвольного доступа.

[177] Если ra-ContentionResolutionTimer истекает, UE выбирает SSB снова в момент времени, в который таймер истекает, чтобы повторно передавать преамбулу. На этапах 829-837 по фиг. 2D, сценарий, в котором SSB, который UE выбирает снова, представляет собой SSB, которому выделена область выделенных ресурсов произвольного доступа, такой как SSB #1 в вышеприведенном примере на этапе 829. UE передает выделенную преамбулу через PRACH-период, соответствующий выбранному SSB, на этапе 831. Если неконкурентный произвольный доступ выполняется при восстановлении после сбоя луча, как указано в сценарии этапа 829, UE принимает PDCCH для выделения ресурсов нисходящей или восходящей линии связи вместо RAR в качестве сообщения, соответствующего передаваемой преамбуле, на этапе 833. Более конкретно, когда UE принимает связанную с восстановлением после сбоя луча конфигурацию из gNB, UE отдельно принимает местоположение ресурсов (recoverySearchSpace), в котором принимается PDCCH для выделения ресурсов нисходящей или восходящей линии связи. При приеме PDCCH, скремблированного с C-RNTI, который представляет собой уникальный идентификатор в соте UE для выделения ресурсов нисходящей или восходящей линии связи в соответствующем местоположении ресурсов, на этапе 833, UE определяет то, что произвольный доступ завершается, на этапе 835. На фиг. 8 предполагается, что UE принимает PDCCH, скремблированный с C-RNTI для выделения ресурсов восходящей линии связи.

[178] Между тем, при выполнении конкурентного произвольного доступа (процедуры на этапах 811-827), UE сохраняет данные в Msg3-буфере согласно размеру выделенных ресурсов восходящей линии связи RAR, принимаемого из gNB. Данные, сохраненные в Msg3-буфере, могут включать в себя не только C-RNTI MAC CE для идентификации конкурентного произвольного доступа, но также и MAC CE для отчета о состоянии буфера (BSR), MAC CE для отчета о запасе мощности или данные восходящей линии связи.

[179] Тем не менее, если UE выполняет неконкурентный произвольный доступ на этапе 831, gNB не может знать то, что UE уже выполнило конкурентный произвольный доступ. Соответственно, когда gNB выделяет восходящую линию для UE позднее на этапе 833, размер выделенных ресурсов может отличаться от размера выделенных ресурсов в предыдущем RAR. Если размер выделенных ресурсов в RAR в конкурентном произвольном доступе отличается от размера выделенных ресурсов, когда gNB выделяет восходящую линию связи для UE в неконкурентном произвольном доступе, UE отбрасывает MAC CE для BSR и PHR и формирует MAC PDU снова только с MAC SDU (т.е. с данными из RLC-уровня), чтобы предотвращать потери важных данных (например, сообщения завершения передачи обслуживания) на этапе 837.

[180] Чтобы предотвращать отбрасывание MAC CE для BSR и PHR, при выделении ресурсов в неконкурентном произвольном доступе, gNB может рассматривать способ выделения одного и того же размера выделенных ресурсов восходящей линии связи (например, 56 битов), в общем, используемых в конкурентном произвольном доступе на этапе 837. Тем не менее, даже в конкурентном произвольном доступе, gNB может выделять ресурсы восходящей линии связи в 56 битов или в 72 бита согласно состоянию буфера UE, и размер других ресурсов, которые может выделять gNB, также не ограничивается. Соответственно, если размер выделенного ресурса в RAR в конкурентном произвольном доступе отличается от размера ресурсов, выделенных, когда gNB выделяет восходящую линию связи для UE в неконкурентном произвольном доступе, требуется способ передачи потерянных MAC CE снова.

[181] Фиг. 9 иллюстрирует передачу и прием данных между UE и gNB, когда способ предотвращения потерь отчета о состоянии буфера и отчета о запасе мощности применяется согласно варианту осуществления раскрытия сущности.

[182] На фиг. 9, описание, которое является таким же как описание на фиг. 8, опускается. Этапы 911-935 по фиг. 9 являются такими же как этапы 811-835 по фиг. 8. Таким образом, фиг. 9 предполагает сценарий, в котором UE 901 выполняет конкурентный произвольный доступ на этапах 911-927, выполняет неконкурентный произвольный доступ на этапах 929-935, принимает PDCCH для выделения ресурсов восходящей линии связи и затем завершает процедуру произвольного доступа на этапе 935.

[183] Когда произвольный доступ завершается, UE согласно некоторым вариантам осуществления раскрытия сущности идентифицирует то, является или нет Msg3-буфер пустым (т.е. имеются данные в Msg3-буфере), и то, прекращается или нет произвольный доступ, посредством передачи преамбулы неконкурентного произвольного доступа.

[184] Если Msg3-буфер не является пустым, и произвольный доступ прекращается посредством передачи преамбулы неконкурентного произвольного доступа, UE инициирует BSR, если BSR существует в Msg3-буфере. Если предусмотрен MAC CE, связанный с PHR, в Msg3-буфере, PHR инициируется на этапе 937. UE может передавать релевантный MAC CE согласно инициированному BSR и/или PHR в gNB 903 на этапе 939.

[185] Если BSR инициируется, UE может инициировать запрос на диспетчеризацию (SR) согласно типу BSR и передавать SR-информацию через PUCCH или может передавать BSR при приеме ресурсов восходящей линии связи из gNB, без инициирования отдельного SR.

[186] Тип BSR может разделяться следующим образом согласно инициированному условию.

[187] Первый тип: регулярный BSR

[188] - BSR, передаваемый в случае, в котором таймер повторной BSR-передачи (retxBSR-Timer) истекает, если имеются данные, которые могут передаваться для любого логического канала/однонаправленного радиоканала (RB), принадлежащего группе логических каналов (в дальнейшем в этом документе, называемой LCG),

[189] - BSR, передаваемый в случае, в котором данные, которые должны передаваться из верхнего уровня (RLC- или PDCP-уровня), формируются для логического канала/однонаправленного радиоканала, принадлежащего LCG, и сформированные данные имеют более высокий приоритет, чем логический канал/однонаправленный радиоканал, принадлежащий любой LCG,

[190] - BSR, передаваемый в случае, в котором данные, которые должны передаваться из верхнего уровня (RLC- или PDCP-уровня), формируются для логического канала/однонаправленного радиоканала, принадлежащего LCG, и отсутствуют данные во всех LCG, за исключением сформированных данных,

[191] Второй тип: периодический BSR

[192] - BSR, передаваемый в случае, в котором периодический BSR-таймер (periodicBSR-Timer), сконфигурированный в UE, истекает,

[193] Третий тип: дополняющий BSR

[194] - BSR, передаваемый в случае, в котором ресурсы восходящей линии связи выделяются, и дополняющие биты, заполняющие остающееся пространство после передача данных, равны или выше суммы размера BSR MAC CE и размера подзаголовка BSR MAC CE.

[195] - передавать усеченный BSR, если предусмотрены пакеты в буферах множества LCG.

[196] Если BSR включается в Msg3-буфер согласно вышеуказанному типу BSR, UE может инициировать соответствующий BSR-тип снова либо может всегда инициировать регулярный BSR или периодический BSR согласно условию, при котором BSR ранее инициирован. Если BSR, включенный в Msg3-буфер, представляет собой дополняющий BSR, UE может не инициировать отдельно BSR.

[197] Хотя не упомянуто, другой тип BSR может включать в себя BSR боковой линии связи для подачи запроса на ресурсы в gNB для прямой связи с UE. Другой вариант осуществления раскрытия сущности относится к сценарию, в котором UE получает ресурсы восходящей линии связи посредством передачи MAC CE BSR боковой линии связи в gNB и непосредственно передает данные в другое UE. UE может инициировать BSR только тогда, когда BSR боковой линии связи потерян. Альтернативно, UE может не инициировать BSR снова в случае BSR боковой линии связи, но может инициировать BSR только в случае BSR, инициированного в качестве вышеуказанного регулярного BSR. Например, в случае, в котором связь между UE имеет очень высокий приоритет, к примеру, связь между транспортным средствами, BSR может инициироваться снова. В противном случае, BSR может не инициироваться снова.

[198] Согласно другому варианту осуществления раскрытия сущности, если регулярный BSR или BSR боковой линии связи потерян, UE может инициировать BSR только тогда, когда приоритет логического канала, принадлежащего BSR, выше приоритета, сконфигурированного в качестве RRC-сообщения посредством BS или сконфигурированного в UE.

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

[200] Традиционные условия в отношении момента времени, в который UE передает PHR в gNB (т.е. UE инициирует PHR), заключаются в следующем.

[201] - случай, в котором изменение интенсивности приема в нисходящей линии связи превышает или равно dl-PathlossChange дБ, когда prohibitPHR-Timer истекает,

[202] - случай, в котором prohibitPHR-Timer истекает (периодический отчет),

[203] - случай, в котором информация связанной с PHR-сообщением конфигурации первоначально конфигурируется (или обновляется),

[204] - случай, в котором SCell, включающая в себя восходящую линию связи, добавляется,

[205] - случай, в котором первичная сота вторичного gNB (PSCell) добавляется, когда используется технология режима сдвоенного подключения.

[206] Согласно некоторым вариантам осуществления раскрытия сущности, если размер выделенных ресурсов восходящей линии связи в Msg3 отличается от размера выделенных ресурсов в RAR вследствие добавления условий, и в силу этого связанный с PHR MAC CE теряется, UE может инициировать PHR и передает связанный с PHR MAC CE в gNB. В связи с передаваемым связанным с PHR MAC CE, UE передает однократный PHR MAC CE, если число обслуживающих сот составляет одну, и передает многократные PHR MAC CE, если число обслуживающих сот составляет несколько.

[207] Согласно добавленным условиям инициирования BSR или PHR, UE может инициировать потерянный BSR и/или PHR снова и быстро сообщает соответствующую информацию gNB снова.

[208] Фиг. 10 иллюстрирует процедуру UE, когда способ предотвращения потерь отчета о состоянии буфера и отчета о запасе мощности применяется согласно варианту осуществления раскрытия сущности.

[209] На фиг. 10, предполагается сценарий, в котором UE в соединенном состоянии выполняет произвольный доступ и завершает произвольный доступ, чтобы выполнять восстановление после сбоя луча, на этапе 1003.

[210] Когда произвольный доступ завершается на этапе 1003, UE идентифицирует то, является или нет Msg3-буфер пустым (имеются или нет данные), и то, прекращается или нет произвольный доступ, посредством передачи преамбулы неконкурентного произвольного доступа на этапе 1005.

[211] Если Msg3-буфер не является пустым, и произвольный доступ прекращается посредством передачи преамбулы неконкурентного произвольного доступа, UE инициирует BSR, если BSR существует в Msg3-буфере. Если предусмотрен MAC CE, связанный с PHR, в Msg3-буфере, PHR инициируется на этапе 937. UE может передавать релевантный MAC CE согласно инициированному BSR и/или PHR в gNB на этапе 1007.

[212] Если BSR инициируется, UE может инициировать запрос на диспетчеризацию (SR) согласно типу BSR и передавать SR-информацию через PUCCH или может передавать BSR при приеме ресурсов восходящей линии связи из gNB, без инициирования отдельного SR.

[213] Тип BSR может разделяться следующим образом согласно инициированному условию.

[214] Первый тип: регулярный BSR

[215] - BSR, передаваемый в случае, в котором таймер повторной BSR-передачи (retxBSR-Timer) истекает, если имеются данные, которые могут передаваться для любого логического канала/однонаправленного радиоканала (RB), принадлежащего группе логических каналов (в дальнейшем в этом документе, называемой LCG),

[216] - BSR, передаваемый в случае, в котором данные, которые должны передаваться из верхнего уровня (RLC- или PDCP-уровня), формируются для логического канала/однонаправленного радиоканала, принадлежащего LCG, и сформированные данные имеют более высокий приоритет, чем логический канал/однонаправленный радиоканал, принадлежащий любой LCG,

[217] - BSR, передаваемый в случае, в котором данные, которые должны передаваться из верхнего уровня (RLC- или PDCP-уровня), формируются для логического канала/однонаправленного радиоканала, принадлежащего LCG, и отсутствуют данные во всех LCG, за исключением сформированных данных,

[218] Второй тип: периодический BSR

[219] - BSR, передаваемый в случае, в котором периодический BSR-таймер (periodicBSR-Timer), сконфигурированный в UE, истекает,

[220] Третий тип: дополняющий BSR

[221] - BSR, передаваемый в случае, в котором ресурсы восходящей линии связи выделяются, и дополняющие биты, заполняющие остающееся пространство после передача данных, равны или выше суммы размера BSR MAC CE и размера подзаголовка BSR MAC CE.

[222] - передавать усеченный BSR, если предусмотрены пакеты в буферах множества LCG.

[223] Если BSR включается в Msg3-буфер согласно вышеуказанному типу BSR, UE может инициировать соответствующий BSR-тип снова либо может всегда инициировать регулярный BSR или периодический BSR согласно условию, при котором BSR ранее инициирован. Если BSR, включенный в Msg3-буфер, представляет собой дополняющий BSR, UE может не инициировать отдельно BSR.

[224] Хотя не упомянуто, другой тип BSR может включать в себя BSR боковой линии связи для подачи запроса на ресурсы в gNB для прямой связи с UE. Другой вариант осуществления раскрытия сущности относится к сценарию, в котором UE получает ресурсы восходящей линии связи посредством передачи MAC CE BSR боковой линии связи в gNB и непосредственно передает данные в другое UE. UE может инициировать BSR только тогда, когда BSR боковой линии связи потерян. Альтернативно, UE может не инициировать BSR снова в случае BSR боковой линии связи, но может инициировать BSR только в случае BSR, инициированного в качестве вышеуказанного регулярного BSR. Например, в случае, в котором связь между UE имеет очень высокий приоритет, к примеру, связь между транспортным средствами, BSR может инициироваться снова. В противном случае, BSR может не инициироваться снова.

[225] Согласно другому варианту осуществления раскрытия сущности, если регулярный BSR или BSR боковой линии связи потерян, UE может инициировать BSR только тогда, когда приоритет логического канала, принадлежащего BSR, выше приоритета, сконфигурированного в качестве RRC-сообщения посредством BS или сконфигурированного в UE.

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

[227] Традиционные условия в отношении момента времени, в который UE передает PHR в gNB (т.е. UE инициирует PHR), заключаются в следующем.

[228] - случай, в котором изменение интенсивности приема в нисходящей линии связи превышает или равно dl-PathlossChange дБ, когда prohibitPHR-Timer истекает,

[229] - случай, в котором prohibitPHR-Timer истекает (периодический отчет),

[230] - случай, в котором информация связанной с PHR-сообщением конфигурации первоначально конфигурируется (или обновляется),

[231] - случай, в котором SCell, включающая в себя восходящую линию связи, добавляется,

[232] - случай, в котором первичная сота вторичного gNB (PSCell) добавляется, когда используется технология режима сдвоенного подключения.

[233] Согласно некоторым вариантам осуществления раскрытия сущности, если размер выделенных ресурсов восходящей линии связи в Msg3 отличается от размера выделенных ресурсов в RAR вследствие добавления условий, и в силу этого связанный с PHR MAC CE теряется, UE может инициировать PHR и передает связанный с PHR MAC CE в gNB. В связи с передаваемым связанным с PHR MAC CE, UE передает однократный PHR MAC CE, если число обслуживающих сот составляет одну, и передает многократные PHR MAC CE, если число обслуживающих сот составляет несколько.

[234] Согласно добавленным условиям инициирования BSR или PHR, UE может инициировать потерянный BSR и/или PHR снова и быстро сообщает соответствующую информацию gNB снова.

[235] Фиг. 11 иллюстрирует конфигурацию UE в системе беспроводной связи согласно некоторым вариантам осуществления раскрытия сущности.

[236] Ссылаясь на фиг. 11, UE включает в себя модуль 1110 радиочастотной (RF) обработки, модуль 1120 обработки в полосе модулирующих частот, запоминающее устройство 1130 и контроллер 1140. Конечно, элементы, включенные в UE, не ограничены этим, и UE может включать в себя меньшее число элементов или большее число элементов по сравнению с числом элементов, проиллюстрированных на фиг. 11.

[237] Модуль 1110 RF-обработки выполняет функцию для передачи и приема сигнала через беспроводной канал, такую как преобразование и усиление полосы частот сигнала. Таким образом, модуль 1110 RF-обработки преобразует с повышением частоты сигнал в полосе модулирующих частот, предоставленный из процессора 1120 полосы модулирующих частот, в сигнал в полосе RF-частот, а затем передает преобразованный сигнал через антенну и преобразует с понижением частоты сигнал в полосе RF-частот, принимаемый через антенну, в сигнал в полосе модулирующих частот. Например, модуль 1110 RF-обработки может включать в себя фильтр передачи, фильтр приема, усилитель, микшер, осциллятор, цифро-аналоговый преобразователь (DAC), аналого-цифровой преобразователь (ADC) и т.п.

[238] Хотя фиг. 11 иллюстрирует только одну антенну, UE может включать в себя множество антенн. Модуль 1110 RF-обработки может включать в себя множество RF-цепочек. Кроме того, модуль 1110 RF-обработки может выполнять формирование диаграммы направленности. Для формирования диаграммы направленности, модуль 1110 RF-обработки может управлять фазой и размером каждого из сигналов, передаваемых/принимаемых через множество антенн или антенных элементов. Дополнительно, модуль 1110 RF-обработки может выполнять работу в режиме cо многими входами и многими выходами (MIMO) и принимать множество уровней во время работы в MIMO-режиме.

[239] Модуль 1120 обработки в полосе модулирующих частот выполняет функцию для преобразования между сигналом в полосе модулирующих частот и потоком битов согласно стандарту физического уровня системы. Например, когда данные передаются, модуль 1120 обработки в полосе модулирующих частот формирует комплексные символы посредством кодирования и модуляции передаваемого потока битов. Дополнительно, когда данные принимаются, модуль 1120 обработки в полосе модулирующих частот восстанавливает принимаемый поток битов посредством демодуляции и декодирования сигнала в полосе модулирующих частот, предоставленного из модуля 1110 RF-обработки. Например, в схеме мультиплексирования с ортогональным частотным разделением каналов (OFDM), когда данные передаются, модуль 1120 обработки в полосе модулирующих частот формирует комплексные символы посредством кодирования и модуляции передаваемого потока битов, преобразования комплексных символов в поднесущие и затем конфигурирует OFDM-символы посредством операции обратного быстрого преобразования Фурье (IFFT) и вставки циклического префикса (CP). Дополнительно, когда данные принимаются, модуль 1120 обработки в полосе модулирующих частот разделяет сигнал в полосе модулирующих частот, предоставленный из RF-процессора 1110 в единицах OFDM-символов, восстанавливает сигналы, преобразованные в поднесущие посредством операции быстрого преобразования Фурье (FFT), и затем восстанавливает принимаемый поток битов через демодуляцию и декодирование.

[240] Модуль 1120 обработки в полосе модулирующих частот и модуль 1110 RF-обработки передают и принимают сигналы, как описано выше. Соответственно, модуль 1120 обработки в полосе модулирующих частот и модуль 1110 RF-обработки могут упоминаться как передающие устройства, приемные устройства, приемо-передающие устройства или модули связи. Дополнительно, по меньшей мере, один из модуля 1120 обработки в полосе модулирующих частот и модуля 1110 RF-обработки может включать в себя множество модулей связи, чтобы поддерживать множество различных технологий радиодоступа. По меньшей мере, один из модуля 1120 обработки в полосе модулирующих частот и модуля 1110 RF-обработки может включать в себя множество различных модулей связи, чтобы обрабатывать сигналы различных полос частот. Например, различные технологии радиодоступа могут включать в себя WLAN (например, IEEE 802.11) и сотовую сеть (например, LTE). Дополнительно, различные полосы частот могут включать в себя полосу сверхвысоких частот (SHF) (например, 2,5 ГГц и 5 ГГц) и полосу частот в диапазоне миллиметровых волн (mm) (например, 60 ГГц). UE может передавать и принимать сигнал в и из ENB через модуль 1120 обработки в полосе модулирующих частот и модуль 1110 RF-обработки, и сигнал может включать в себя управляющую информацию и данные.

[241] Запоминающее устройство 1130 может сохранять данные, такие как базовая программа для работы UE, прикладная программа, конфигурационная информация и т.п. В частности, запоминающее устройство 1130 может сохранять информацию, связанную с WLAN-узлом, для осуществления беспроводной связи с использованием технологии доступа к WLAN. Запоминающее устройство 1130 предоставляет сохраненные данные согласно запросу из контроллера 1140. Запоминающее устройство 1130 может быть сконфигурировано посредством носителей хранения данных, таких как ROM, RAM, жесткий диск, CD-ROM и DVD либо комбинация носителей хранения данных. Запоминающее устройство 1130 может быть сконфигурировано посредством множества запоминающих устройств. Согласно некоторым вариантам осуществления, запоминающее устройство 1130 может сохранять программу для осуществления способа передачи данных согласно раскрытию сущности.

[242] Контроллер 1140 полностью управляет работой UE. Например, контроллер 1140 передает и принимает сигнал через модуль 1120 обработки в полосе модулирующих частот и модуль 1110 RF-обработки. Дополнительно, контроллер 1140 записывает данные в запоминающее устройство 1140 и считывает данные. С этой целью, контроллер 1140 может включать в себя, по меньшей мере, один процессор. Например, контроллер 1140 может включать в себя процессор связи (CP), который осуществляет управление для связи, и процессор приложений (AP), который управляет верхним уровнем, к примеру, приложение. Дополнительно, по меньшей мере, один элемент в UE может реализовываться как одна микросхема. Согласно некоторым вариантам осуществления раскрытия сущности, контроллер 1140 включает в себя модуль 1142 обработки с поддержкой множественного соединения для обработки работы в режиме множественного соединения.

[243] Каждый элемент UE может работать с возможностью выполнять варианты осуществления раскрытия сущности.

[244] Например, контроллер 1140 может управлять UE, чтобы выполнять процедуру, связанную с операцией UE, проиллюстрированной на фиг. 1E. Таким образом, контроллер 1140 может выполнять запрос на повторную передачу на RLC-уровень, чтобы предотвращать потери данных в Msg3-буфере во время произвольного доступа.

[245] Контроллер 1140 может управлять UE, чтобы выполнять процедуру, связанную с операцией UE, проиллюстрированной на фиг. 2E. Таким образом, если BSR и PHR в Msg3-буфере потеряны во время произвольного доступа, контроллер 1140 может быстро сообщать соответствующую информацию в ENB снова посредством инициирования его снова.

[246] Фиг. 12 иллюстрирует конфигурацию базовой станции в системе беспроводной связи согласно некоторым вариантам осуществления раскрытия сущности.

[247] Ссылаясь на фиг. 12, базовая станция может включать в себя модуль 1210 RF-обработки, модуль 1220 обработки в полосе модулирующих частот, модуль 1230 связи, запоминающее устройство 1240 и контроллер 1250. Конечно, раскрытие сущности не ограничено этим, и базовая станция может включать в себя меньшее число элементов или большее число элементов по сравнению с числом элементов, проиллюстрированных на фиг. 12.

[248] Модуль 1210 RF-обработки может выполнять функцию для передачи и приема сигнала через беспроводной канал, такую как покрытие и усиление полосы частот сигнала. Модуль 1210 RF-обработки может преобразовывать с повышением частоты сигнал в полосе модулирующих частот, предоставленный из модуля 1220 обработки в полосе модулирующих частот в сигнал, в полосе RF-частот, передавать сигнал в полосе RF-частот через антенну и затем преобразовывать с понижением частоты сигнал в полосе RF-частот, принимаемый через антенну, в сигнал в полосе модулирующих частот. Например, модуль 1210 RF-обработки может включать в себя фильтр передачи, фильтр приема, усилитель, микшер, осциллятор, DAC и ADC. Хотя фиг. 12 иллюстрирует только одну антенну, модуль 1210 RF-обработки может включать в себя множество антенн. Модуль 1210 RF-обработки может включать в себя множество RF-цепочек. Модуль 1210 RF-обработки может выполнять формирование диаграммы направленности. Для формирования диаграммы направленности, модуль 1210 RF-обработки может управлять фазой и размером каждого из сигналов, передаваемых и принимаемых через множество антенн или антенных элементов. Модуль 1210 RF-обработки может выполнять работу в MIMO-режиме в нисходящей линии связи посредством передачи одного или более уровней.

[249] Модуль 1220 обработки в полосе модулирующих частот может выполнять функцию для преобразования между сигналом в полосе модулирующих частот и потоком битов согласно стандартам физического уровня предварительно определенной технологии радиодоступа. Например, когда данные передаются, модуль 1220 обработки в полосе модулирующих частот может формировать комплексные символы посредством кодирования и модулирования передаваемого потока битов. Когда данные принимаются, модуль 1220 обработки в полосе модулирующих частот может восстанавливать принимаемый поток битов посредством демодуляции и декодирования сигнала в полосе модулирующих частот, предоставленного из модуля 1210 RF-обработки. Например, в OFDM-схеме, когда данные передаются, модуль обработки в полосе модулирующих частот 1220 может формировать комплексные символы посредством кодирования и модуляции передаваемого потока битов, преобразовывать комплексные символы в поднесущие и затем конфигурировать OFDM-символы через IFFT-операцию и CP-вставку. Помимо этого, когда данные принимаются, модуль 1220 обработки в полосе модулирующих частот может разделять сигнал в полосе модулирующих частот, предоставленный из модуля 1210 RF-обработки в единицах OFDM-символов, восстанавливать сигналы, преобразованные в поднесущие через FFT-операцию, и затем восстанавливать принимаемый поток битов через демодуляцию и декодирование. Модуль 1220 обработки в полосе модулирующих частот и модуль 1210 RF-обработки могут передавать и принимать сигнал, как описано выше. Соответственно, модуль 1220 обработки в полосе модулирующих частот и модуль 1210 RF-обработки могут упоминаться как передающие устройства, приемные устройства, приемо-передающие устройства, модули связи или модули беспроводной связи. Базовая станция может передавать и принимать сигнал в и из UE через модуль 1220 обработки в полосе модулирующих частот и модуль 1210 RF-обработки, и сигнал может включать в себя управляющую информацию и данные.

[250] Модуль 1230 связи предоставляет интерфейс для обмена данными с другими узлами в сети. Таким образом, модуль 1230 связи преобразует поток битов, передаваемый из первичной базовой станции в другой узел, например, вторичную базовую станцию или базовую сеть, в физический сигнал, и преобразует физический сигнал, принимаемый из другого узла, в поток битов. Модуль 1230 связи может представлять собой модуль транзитной связи.

[251] Запоминающее устройство 1240 сохраняет данные, такие как базовая программа, приложение и конфигурационная информация для работы базовой станции. Запоминающее устройство 1240 может сохранять информацию относительно однонаправленного канала, выделенного UE для доступа, и результата измерений, сообщаемого посредством UE, к которому осуществляется доступ. Дополнительно, запоминающее устройство 1240 может сохранять информацию, которая представляет собой опорную информацию для определения того, следует предоставлять или прекращать несколько соединений с UE. Запоминающее устройство 1240 предоставляет сохраненные данные согласно запросу из контроллера 1250. Запоминающее устройство 1240 может быть сконфигурировано посредством носителей хранения данных, таких как ROM, RAM, жесткий диск, CD-ROM и DVD либо комбинация носителей хранения данных. Дополнительно, запоминающее устройство 1240 может быть сконфигурировано посредством множества запоминающих устройств. Согласно некоторым вариантам осуществления, запоминающее устройство 1240 может сохранять программу для осуществления способа передачи отчета о состоянии буфера согласно раскрытию сущности.

[252] Контроллер 1250 полностью управляет работой базовой станции. Например, контроллер 1250 передает и принимает сигнал через модуль 1220 обработки в полосе модулирующих частот и модуль 1210 RF-обработки или через модуль транзитной связи 1230. Дополнительно, контроллер 1250 записывает данные в запоминающее устройство 1240 и считывает данные. С этой целью, контроллер 1250 может включать в себя, по меньшей мере, один процессор. По меньшей мере, один элемент базовой станции может реализовываться как одна микросхема. Дополнительно, каждый элемент базовой станции может работать с возможностью выполнять варианты осуществления раскрытия сущности.

[253] Способы согласно вариантам осуществления, указанным в формуле изобретения и/или в подробном описании раскрытия сущности, могут реализовываться в аппаратных средствах, программном обеспечении либо в комбинации аппаратных средств и программного обеспечения.

[254] Когда способы реализуются посредством программного обеспечения, может предоставляться машиночитаемый носитель хранения данных для сохранения одной или более программ (программных модулей). Одна или более программ, сохраненных на машиночитаемом носителе хранения данных, могут быть выполнены с возможностью выполнения посредством одного или более процессоров в электронном устройстве. По меньшей мере, одна программа может включать в себя инструкции, которые инструктируют электронному устройству осуществлять способы согласно различным вариантам осуществления раскрытия сущности, заданным посредством прилагаемой формулы изобретения и/или раскрытым в данном документе.

[255] Программы (программные модули или программное обеспечение) могут сохраняться в энергонезависимых запоминающих устройствах, включающих в себя оперативное запоминающее устройство и флэш-память, постоянное запоминающее устройство (ROM), электрически стираемое программируемое постоянное запоминающее устройство (EEPROM), устройство хранения данных на магнитных дисках, ROM на компакт-дисках (CD-ROM), универсальные цифровые диски (DVD) либо оптические устройства хранения данных другого типа или магнитную кассету. Альтернативно, любая комбинация части или всех из них может формировать запоминающее устройство, в котором сохраняется программа. Дополнительно, множество таких запоминающих устройств могут быть включены в электронное устройство.

[256] Помимо этого, программы могут сохраняться в присоединяемом устройстве хранения данных, которое может осуществлять доступ к электронному устройству через сети связи, такие как Интернет, сеть intranet, локальная вычислительная сеть (LAN), глобальная вычислительная LAN (WLAN) и сеть хранения данных (SAN) либо комбинация вышеозначенного. Такое устройство хранения данных может осуществлять доступ к электронному устройству через внешний порт. Дополнительно, отдельное устройство хранения данных в сети связи может осуществлять доступ к портативному электронному устройству.

[257] [258] Вариант 2 осуществления

[259] В последние годы, разработаны несколько широкополосных беспроводных технологий для того, чтобы удовлетворять растущему числу широкополосных абонентов и предоставлять большее число и лучшие приложения и услуги. Система беспроводной связи второго поколения разработана для того, чтобы предоставлять голосовые услуги при обеспечении мобильности пользователей. Система беспроводной связи третьего поколения поддерживает не только голосовые услуги, но также и услуги передачи данных. В последние годы, четвертая система беспроводной связи разработана для того, чтобы предоставлять услуги высокоскоростной передачи данных. Тем не менее, в настоящее время, система беспроводной связи четвертого поколения страдает от отсутствия ресурсов, чтобы удовлетворять возрастающую потребность в предоставлении услуг высокоскоростной передачи данных. Таким образом, система беспроводной связи пятого поколения разрабатывается для того, чтобы удовлетворять возрастающую потребность в предоставлении услуг высокоскоростной передачи данных, поддерживать варианты применения сверхнадежной связи с низкой задержкой. Система беспроводной связи пятого поколения реализуется не только в полосах нижних частот, но также и в полосах верхних частот (mmWave), например, в полосах частот в 10-100 ГГц, с тем чтобы добиваться более высоких скоростей передачи данных. Чтобы уменьшать потери при распространении радиоволн и увеличивать расстояние передачи, формирование диаграммы направленности, массовая технология cо многими входами и многими выходами (MIMO), полноразмерная MIMO (FD-MIMO), решетчатая антенна, формирование аналоговой диаграммы направленности, крупномасштабные антенные технологии рассматриваются в проектном решении системы беспроводной связи пятого поколения. Помимо этого, система беспроводной связи пятого поколения предположительно нацелена на различные варианты использования, имеющие сильно отличающиеся требования с точки зрения скорости передачи данных, задержки, надежности, мобильности и т.д. Тем не менее, предполагается, что проектное решение по радиоинтерфейсу системы беспроводной связи пятого поколения должно быть достаточно гибким для того, чтобы обслуживать UE, имеющие сильно отличающиеся характеристики в зависимости от варианта использования и рыночного сегмента, в котором UE предоставляет услуги конечному потребителю. Некоторые примерные случаи использования, на которые предположительно нацелена беспроводная система системы беспроводной связи пятого поколения, представляют собой усовершенствованный стандарт широкополосной связи для мобильных устройств (eMBB), массовую машинную связь (mMTC), стандарт сверхнадежной связи с низкой задержкой (URLL) и т.д. EMBB-требования, такие как скорость передачи данных в десятки Гбит/с, низкая задержка, высокая мобильность и т.д., нацелены на рыночный сегмент, представляющий традиционных беспроводных широкополосных абонентов, которым требуется Интернет-подключение везде, в любой момент времени и "на ходу". MMTC-требования, такие как очень высокая плотность соединений, нечастая передача данных, очень продолжительное время работы от аккумулятора, решение проблемы низкой мобильности и т.д., нацелены на рыночный сегмент, представляющий Интернет вещей (IoT)/Интернет всего (IoE), предусматривающий подключение миллиардов устройств. URLL-требования, такие как очень низкая задержка, очень высокая надежность и переменная мобильность и т.д., нацелены на рыночный сегмент, представляющий вариант применения для промышленной автоматизации, связь между транспортными средствами/между транспортным средством и инфраструктурой, прогнозируемые в качестве одного из способствующих развитию факторов для автономных автомобилей.

[260] Текущее проектное решение 5G-системы беспроводной связи служит для работы на лицензированной несущей(их). Недавно инициировано исследование на предмет того, чтобы изучать улучшения в 5G-системе беспроводной связи для работы на нелицензированной несущей(их). Основной стимул использования нелицензированной несущей заключается в уменьшении CAPEX для операторов сотовой связи посредством использования свободного доступа к спектру для интеллектуальной разгрузки данных; в улучшенном и интеллектуальном доступе и управлении спектром, что нацелено на растущую потребность в беспроводном трафике при ограниченном доступном спектре, и в возможности сетевым операторам без лицензированного спектра использовать радиоэффективную технологию 3GPP-радиодоступа. Различные сценарии развертывания рассматриваются для работы на нелицензированных несущих, такие как:

[261] NR-U LAA: агрегирование несущих между лицензированной полосой частот на основе NR (PCell) и нелицензированной полосой частот на основе NR-U (SCell).

[262] NR-U SA: автономный NR-U.

[263] ENU-DC: режим сдвоенного подключения между лицензированной полосой частот на основе LTE (PCell) и нелицензированной полосой частот на основе NR-U (PSCell).

[264] NNU-DC: режим сдвоенного подключения между лицензированной полосой частот на основе NR (PCell) и нелицензированной полосой частот на основе NR-U (PSCell).

[265] Следует отметить, что вышеприведенные сценарии включают в себя NR-соту с DL в нелицензированной полосе частот и UL в лицензированной полосе частот.

[266] Одна из целей вышеуказанного исследования состоит в том, чтобы идентифицировать улучшения, требуемые для того, чтобы поддерживать процедуру поисковых вызовов в нелицензированной полосе частот. В системе беспроводной связи пятого поколения (также упоминаемого как "NR" или "новый стандарт радиосвязи"), поисковые вызовы передаются, чтобы осуществлять поисковые вызовы UE, которые присоединяются к сети беспроводной связи, но находятся в бездействующем/неактивном режиме. В бездействующем/неактивном режиме, UE пробуждается с регулярными интервалами (т.е. каждый цикл прерывистого приема (DRX) поисковых вызовов) в течение коротких периодов для того, чтобы принимать поисковые вызовы и другую широковещательную информацию. Сеть может конфигурировать несколько периодов поисковых вызовов (PO) в DRX-цикле. В PO, сообщение поисковых вызовов передается с использованием физического совместно используемого канала нисходящей линии связи (PDSCH). Физический общий канал управления нисходящей линии связи (PDCCH) адресуется в RNTI для поисковых вызовов (P-RNTI), если предусмотрено сообщение поисковых вызовов в PDSCH. P-RNTI является общим для всех UE. Таким образом, идентификационные данные UE (т.е. временный идентификатор абонента мобильной связи по стандарту SAE (S-TMSI)) включаются в сообщение поисковых вызовов, чтобы указывать поисковые вызовы для конкретного UE. Сообщение поисковых вызовов может включать в себя несколько идентификационных данных UE, чтобы осуществлять поисковые вызовы нескольких UE. Сообщение поисковых вызовов широковещательно передается (т.е. PDCCH маскируется с P-RNTI) по каналу передачи данных (т.е. PDSCH).

[267] UE отслеживает один PO каждый DRX-цикл. Каждый PO представляет собой набор из S периодов PDCCH-отслеживания, где S является числом передаваемых SSB в соте. UE определяет свой PO на основе UE_ID. UE сначала определяет кадр поисковых вызовов (PF), а затем определяет PO относительно определенного PF. Одно PF представляет собой радиокадр (10 мс). PF для UE представляет собой радиокадр с номером системного кадра (SFN), который удовлетворяет уравнению (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N); где PF_offset, T и N передаются в служебных сигналах посредством gNB в системной информации. UE отслеживает (i_s+1)-ый PO, где i_s=floor(UE_ID/N) mod Ns; где N и Ns передаются в служебных сигналах посредством gNB в системной информации.

[268] Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами, последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Периоды PDCCH-отслеживания определяются на основе конфигурации пространства поиска поисковых вызовов, передаваемой в служебных сигналах посредством gNB в системной информации. GNB может передавать в служебных сигналах параметр firstPDCCH-MonitoringOccasionOfPO для каждого PO, соответствующего PF. Когда firstPDCCH-MonitoringOccasionOfPO передается в служебных сигналах, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO). В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1 (SIB1).

[269] Если несущая, используемая для передачи по нисходящей линии связи, представляет собой нелицензированную несущую, gNB должен выполнять считывание канала, чтобы определять то, является или нет канал свободным, перед передачей сообщения поисковых вызовов в нисходящей линии связи. Возможно то, что gNB имеет сообщение поисковых вызовов, которое следует передавать, но не имеет возможность передавать его в PO, поскольку канал не является свободным. Это должно задерживать передачу поисковых вызовов до следующего DRX-цикла. Требуется усовершенствованный способ определения PF/PO.

[270] Вариант 2-1 осуществления: PF/PO-определение, чтобы поддерживать дополнительные возможности поисковых вызовов

[271] Способ 1

[272] Фиг. 13 иллюстрирует вариант осуществления определения PO в DRX-цикле согласно варианту осуществления способа 1.

[273] Ссылаясь на фиг. 13, UE 1300 получает/принимает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns, P) из системной информации, передаваемой в служебных сигналах посредством сети 1301 (может использоваться взаимозаменяемо с "gNB"), на этапе 1310. В RRC-бездействующем и RRC-неактивном состоянии, UE также получает/принимает конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети 1301 для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов. Таким образом, в RRC-соединенном состоянии, UE получает/принимает конфигурацию пространства поиска поисковых вызовов из выделенной передачи служебных RRC-сигналов. UE также получает/принимает параметр ssb-PositionsInBurst из системной информации, т.е. из SystemInformationBlock1. Он также может приниматься в выделенной передаче служебных RRC-сигналов в RRC-соединенном состоянии.

[274] На этапе 1320, UE 1300 сначала определяет кадр поисковых вызовов. PF представляет собой радиокадр с SFN, который удовлетворяет:

[275] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[276] где:

[277] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[278] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[279] UE_ID: S-TMSI mod 1024

[280] На этапе 1330, UE 1300 затем вычисляет индекс i_s, где i_s извлекается из следующего уравнения:

[281] i_s=floor(UE_ID/N) mod Ns, где:

[282] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

[283] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[284] UE_ID: S-TMSI mod 1024.

[285] Каждый DRX-цикл T (как определено выше), UE 1300 отслеживает (i_s+1)-ый PO во вплоть до P последовательных PF начиная с определенного PF на этапе 1320, на этапе 1340. Параметр P передается в служебных сигналах посредством gNB 1301 (например, в системной информации). Если PF, определенный на этапе 1320, представляет собой SFN X, UE отслеживает SFN X+k*T/N, где k=0, 1, 2, ..., P-1.

[286] Фиг. 14 иллюстрирует пример PF, отслеживаемых посредством UE, определенного посредством способа 1. SFN X 1400 представляет собой PF, определенный посредством UE, значение P, передаваемое в служебных сигналах посредством gNB, равно 2, и N равен T/2. Таким образом, UE отслеживает (i_s+1)-ый PO относительно SFN X и SFN X+1*T/N=SFN X+2. UE должно сначала отслеживать (i_s+1)-ый PO относительно SFN X 1400. Если оно не принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, оно отслеживает (i_s+1)-ый PO относительно следующего PF, т.е. SFN X+2 1410.

[287] В варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя (т.е. сообщение поисковых вызовов включает в себя идентификатор UE), UE может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя, UE может не отслеживать свои остальные PO в этом DRX-цикле. Индикатор SkipAdditionalPOMonitoring предоставляет гибкость для сети в том, чтобы сразу передавать поисковые вызовы, когда канал становится доступным, или откладывать их до последующих PO.

[288] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать свои остальные PO в этом DRX-цикле.

[289] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, UE может не отслеживать свои остальные PO в этом DRX-цикле.

[290] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и отсутствует индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, UE может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и отсутствует индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и предусмотрен индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, UE может отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и предусмотрен индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, оно отслеживает свои остальные PO в этом DRX-цикле. В варианте осуществления, UE может отслеживать все свои PO в DRX-цикле.

[291] Согласно варианту осуществления, периоды PDCCH-отслеживания, соответствующие (i_s+1)-ому PO, определяются следующим образом:

[292] Ассоциирование не по умолчанию (т.е. параметр pagingSearchSpace, принимаемый из gNB, задается равным не нулю):

[293] В этом случае, периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации поиска поисковых вызовов. GNB передает в служебных сигналах конфигурацию пространства поиска поисковых вызовов (содержащую параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность). UE определяет период PDCCH-отслеживания из периодичности PDCCH-отслеживания (Monitoring-periodicity-PDCCH-slot), смещения PDCCH-отслеживания (Monitoring-offset-PDCCH-slot) и шаблона PDCCH-отслеживания (Monitoring-symbols-PDCCH-within-slot) во временном кванте. Периоды PDCCH-отслеживания находятся во временных квантах x - x+duration, где временной квант с номером x в радиокадре с номером y удовлетворяет нижеприведенному уравнению:

[294] (y * (число временных квантов в радиокадре) + x - Monitoring-offset-PDCCH-slot) mod (Monitoring-periodicity-PDCCH-slot) = 0;

[295] Начальный символ периода PDCCH-отслеживания в каждом временном кванте, имеющем период PDCCH-отслеживания, задается посредством Monitoring-symbols-PDCCH-within-slot. Длина (в символах) периода PDCCH-отслеживания задается в базовом наборе, ассоциированном с пространством поиска.

[296] На основе конфигурации пространства поиска поисковых вызовов (содержащей параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность), UE может знать первый период PDCCH-отслеживания для поисковых вызовов в определенном PF, а также последующие периоды PDCCH-отслеживания.

[297] В TDD-соте, UE принимает TDD-конфигурацию с использованием, по меньшей мере, одного из IE tdd-UL-DL-ConfigurationCommon, IE tdd-UL-DL-ConfigurationDedicated и группового общего PDCCH. IE tdd-UL-DL-ConfigurationCommon передается в служебных сигналах в системной информации и указывает DL-символы, UL-символы и гибкие символы. IE tdd-UL-DL-ConfigurationDedicated передается в служебных сигналах в выделенной передаче служебных RRC-сигналов и указывает то, какие из гибких символов представляют собой UL-символы. Групповой общий PDCCH предоставляет TDD-конфигурацию для одного или более временных квантов.

[298] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символом(ами). UL-символ(ы) определяется согласно tdd-UL-DL-ConfigurationCommon. Периоды PDCCH-отслеживания для поисковых вызовов, которые остаются после исключения, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов и упоминаются как периоды PDCCH-отслеживания для поисковых вызовов в последующей процедуре. Следует отметить, что исключение периодов отслеживания для поисковых вызовов, которые перекрываются с UL-символами, определенными согласно параметру tdd-UL-DL-ConfigurationCommon, выполняется только в TDD-соте, поскольку в FDD-соте tdd-UL-DL-ConfigurationCommon не передается в служебных сигналах; tdd-UL-DL-ConfigurationCommon передается в служебных сигналах только в TDD-соте. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами, причем UL-символы определяются согласно параметру tdd-UL-DL-ConfigurationCommon, передаваемому в служебных сигналах в SIB1, последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Другими словами, достоверные периоды PDCCH-отслеживания с начала PF последовательно нумеруются от нуля. Эти пронумерованные периоды PDCCH-отслеживания для поисковых вызовов затем преобразуются в PO следующим образом:

[299] Когда firstPDCCH-MonitoringOccasionOfPO присутствует (firstPDCCH-MonitoringOccasionOfPO необязательно передается в служебных сигналах в конфигурации поисковых вызовов), (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO); firstPDCCH-MonitoringOccasionOfPO представляет собой список начальных номеров периодов PDCCH-отслеживания.

[300] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. Следует отметить, что периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации пространства поиска поисковых вызовов.

[301] Для ассоциирования по умолчанию, Ns равен 1 или 2. Для Ns=1, предусмотрен только один PO, который начинается в PF. Для Ns=2, PO находится либо в первом полукадре (i_s=0), либо во втором полукадре (i_s=1) PF. Для ассоциирования по умолчанию, периоды PDCCH-отслеживания для поисковых вызовов являются такими же как периоды PDCCH-отслеживания для оставшейся минимальной системной информации (RMSI).

[302] В альтернативном варианте осуществления, если поддерживаются несколько мультиплексированных с частотным разделением каналов (FDM-мультиплексированных) PO (все PO, включающие в себя FDM-мультиплексированные PO, идентифицируются посредством i_s) посредством конфигурирования нескольких базовых наборов поисковых вызовов, и firstPDCCH-MonitoringOccasionOfPO не передается в служебных сигналах, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с ((i_s/C)*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. C является числом наборов управляющих ресурсов поисковых вызовов (базовых наборов). В периоды PDCCH-отслеживания (i_s+1)-ого PO, UE отслеживает k-ый базовый набор поисковых вызовов, где k=i_s mod C.

[303] В варианте осуществления настоящего раскрытия сущности, параметр S может быть равен [число фактических передаваемых SSB, определенное согласно ssb-PositionsInBurst в SystemInformationBlock1]*X, где X передается в служебных сигналах посредством gNB, или X является числом раз, когда каждый SSB повторяется в SSB-окне.

[304] Следует отметить, что для поисковых вызовов UE, gNB также определяет PO для этого UE так же, как определяет это UE на основе процедуры, поясненной выше.

[305] Способ 2

[306] Способ 2-1

[307] Фиг. 15 иллюстрирует процедуру определения PO в DRX-цикле согласно варианту осуществления способа 2-1.

[308] Ссылаясь на фиг. 15, UE 1500 получает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns, P) из системной информации, передаваемой в служебных сигналах посредством сети 1501, на этапе 1510. В RRC-бездействующем и RRC-неактивном состоянии, UE также получает конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети 1501 для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов. Таким образом, в RRC-соединенном состоянии, UE получает конфигурацию пространства поиска поисковых вызовов из выделенной передачи служебных RRC-сигналов. UE также получает/принимает параметр ssb-PositionsInBurst из системной информации, т.е. из SystemInformationBlock1. Он также может приниматься в выделенной передаче служебных RRC-сигналов в RRC-соединенном состоянии.

[309] UE сначала определяет кадр поисковых вызовов на этапе 1520. PF представляет собой радиокадр с SFN, который удовлетворяет:

[310] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[311] где:

[312] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[313] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[314] UE_ID: S-TMSI mod 1024

[315] На этапе 1530, UE 1500 затем вычисляет индекс i_s, где i_s извлекается из следующего уравнения:

[316] i_s=floor(UE_ID/N), mod (Ns/P), где:

[317] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[318] P: Число PO в расчете на DRX-цикл, отслеживаемых посредством UE.

[319] UE_ID: S-TMSI mod 1024.

[320] Каждый DRX-цикл T (как определено выше), UE 1500 отслеживает вплоть до P PO начиная с (i_s*P+1)-ого PO, соответствующего определенному PF на этапе 1520, на этапе 1510. Параметр P передается в служебных сигналах посредством gNB 1501 (например, в системной информации).

[321] Фиг. 16 иллюстрирует пример PF и PO, отслеживаемых посредством UE, определенного посредством способа 2-1. SFN X 1600 представляет собой PF, определенный посредством UE, значение P, передаваемое в служебных сигналах посредством gNB, равно 2, N равен T/2, и i_s, определенный посредством UE, равен 0. Таким образом, UE отслеживает первый и второй PO 1610, 1620 относительно SFN X. UE должно сначала отслеживать первый PO 1610 относительно SFN X 1600. Если оно не принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, оно отслеживает второй PO 1620 относительно SFN X 1600.

[322] В варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя (т.е. сообщение поисковых вызовов включает в себя идентификатор UE), UE может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя, UE может не отслеживать свои остальные PO в этом DRX-цикле. Индикатор SkipAdditionalPOMonitoring предоставляет гибкость для сети в том, чтобы сразу передавать поисковые вызовы, когда канал становится доступным, или откладывать их до последующих PO.

[323] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать свои остальные PO в этом DRX-цикле.

[324] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, UE может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, UE может не отслеживать свои остальные PO в этом DRX-цикле.

[325] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и отсутствует индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и отсутствует индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, UE может не отслеживать свои остальные PO в этом DRX-цикле.

[326] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и предусмотрен индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, UE отслеживает свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и предусмотрен индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, UE отслеживает свои остальные PO в этом DRX-цикле. В варианте осуществления, UE может отслеживать все свои PO в DRX-цикле.

[327] Согласно варианту осуществления, периоды PDCCH-отслеживания, соответствующие (i_s*P+1)-ому PO, определяются следующим образом:

[328] GNB передает в служебных сигналах конфигурацию пространства поиска поисковых вызовов (содержащую параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность). UE определяет период PDCCH-отслеживания из периодичности PDCCH-отслеживания (Monitoring-periodicity-PDCCH-slot), смещения PDCCH-отслеживания (Monitoring-offset-PDCCH-slot) и шаблона PDCCH-отслеживания (Monitoring-symbols-PDCCH-within-slot) во временном кванте. Периоды PDCCH-отслеживания находятся во временных квантах x - x+duration, где временной квант с номером x в радиокадре с номером y удовлетворяет уравнению:

[329] (y * (число временных квантов в радиокадре) + x - Monitoring-offset-PDCCH-slot) mod (Monitoring-periodicity-PDCCH-slot) = 0;

[330] Начальный символ периода PDCCH-отслеживания в каждом временном кванте, имеющем период PDCCH-отслеживания, задается посредством Monitoring-symbols-PDCCH-within-slot. Длина (в символах) периода PDCCH-отслеживания задается в базовом наборе, ассоциированном с пространством поиска.

[331] На основе конфигурации пространства поиска поисковых вызовов (содержащей параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность), UE может знать периоды PDCCH-отслеживания для поисковых вызовов с начала PF.

[332] В TDD-соте, UE принимает TDD-конфигурацию с использованием, по меньшей мере, одного из IE tdd-UL-DL-ConfigurationCommon, IE tdd-UL-DL-ConfigurationDedicated и группового общего PDCCH. IE tdd-UL-DL-ConfigurationCommon передается в служебных сигналах в системной информации и указывает DL-символы, UL-символы и гибкие символы. IE tdd-UL-DL-ConfigurationDedicated передается в служебных сигналах в выделенной передаче служебных RRC-сигналов и указывает то, какие из гибких символов представляют собой UL-символы. Групповой общий PDCCH предоставляет TDD-конфигурацию для одного или более временных квантов.

[333] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символом(ами). UL-символ(ы) определяется согласно tdd-UL-DL-ConfigurationCommon. Периоды PDCCH-отслеживания для поисковых вызовов, которые остаются после исключения, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов и упоминаются как периоды PDCCH-отслеживания для поисковых вызовов в последующей процедуре. Следует отметить, что исключение периодов отслеживания для поисковых вызовов, которые перекрываются с UL-символами, определенными согласно параметру tdd-UL-DL-ConfigurationCommon, выполняется только в TDD-соте, поскольку в FDD-соте tdd-UL-DL-ConfigurationCommon не передается в служебных сигналах; tdd-UL-DL-ConfigurationCommon передается в служебных сигналах только в TDD-соте. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами (определенными согласно параметру tdd-UL-DL-ConfigurationCommon, передаваемому в служебных сигналах в SIB1), последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Другими словами, достоверные периоды PDCCH-отслеживания с начала PF последовательно нумеруются от нуля. Эти пронумерованные периоды PDCCH-отслеживания затем преобразуются в PO следующим образом: Когда firstPDCCH-MonitoringOccasionOfPO присутствует (firstPDCCH-MonitoringOccasionOfPO необязательно передается в служебных сигналах в конфигурации поисковых вызовов), (i_s*P+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s*P+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[334] В противном случае, (i_s*P+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*P*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. Следует отметить, что периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации пространства поиска поисковых вызовов.

[335] В альтернативном варианте осуществления, если несколько FDM-мультиплексированных PO поддерживаются (все PO, включающие в себя FDM-мультиплексированные PO, идентифицируются посредством i_s) посредством конфигурирования нескольких базовых наборов поисковых вызовов, и firstPDCCH-MonitoringOccasionOfPO не передается в служебных сигналах, (i_s*P+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с ((i_s*P/C)*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. C является числом базовых наборов поисковых вызовов. В периоды PDCCH-отслеживания (i_s*P+1)-ого PO, UE отслеживает k-ый базовый набор поисковых вызовов, где k=(i_s*P) mod C.

[336] В варианте осуществления настоящего раскрытия сущности, параметр S может быть равен [число фактических передаваемых SSB, определенное согласно ssb-PositionsInBurst в SystemInformationBlock1]*X, где X передается в служебных сигналах посредством gNB, или X является числом раз, когда каждый SSB повторяется в SSB-окне.

[337] Следует отметить, что для поисковых вызовов UE, gNB также определяет PO для этого UE так же, как определяет это UE на основе процедуры, поясненной выше.

[338] Способ 2-2

[339] Фиг. 17 иллюстрирует процедуру определения PO в DRX-цикле согласно варианту осуществления способа 2-2.

[340] Ссылаясь на фиг. 17, UE 1700 получает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns, P) из системной информации, передаваемой в служебных сигналах посредством сети 1701, на этапе 1710. В RRC-бездействующем и RRC-неактивном состоянии, UE также получает конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети 1701 для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов. Таким образом, в RRC-соединенном состоянии, UE получает конфигурацию пространства поиска поисковых вызовов из выделенной передачи служебных RRC-сигналов. UE также получает/принимает параметр ssb-PositionsInBurst из системной информации, т.е. из SystemInformationBlock1. Он также может приниматься в выделенной передаче служебных RRC-сигналов в RRC-соединенном состоянии.

[341] UE сначала определяет кадр поисковых вызовов на этапе 1720. PF представляет собой радиокадр с SFN, который удовлетворяет:

[342] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[343] где:

[344] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[345] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[346] UE_ID: S-TMSI mod 1024

[347] UE затем вычисляет индекс i_s на этапе 1730, где i_s извлекается из следующего уравнения:

[348] i_s=floor(UE_ID/N), mod (Ns/P), где:

[349] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

[350] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[351] P: Число PO в расчете на DRX-цикл, отслеживаемых посредством UE.

[352] UE_ID: S-TMSI mod 1024.

[353] Каждый DRX-цикл T (как определено выше), UE отслеживает вплоть до P PO, заданных посредством (i_s+P*n+1), где n=0, 1, 2, ..., P-1, на этапе 1740. Параметр P передается в служебных сигналах посредством gNB 1701 (например, в системной информации).

[354] Фиг. 18 иллюстрирует пример PO, отслеживаемых посредством UE, определенного посредством способа 2-2. SFN X 1800 представляет собой PF, определенный посредством UE, значение P, передаваемое в служебных сигналах посредством gNB, равно 2, N равен T/2, и i_s, определенный посредством UE, равен 0. Таким образом, UE отслеживает первый и третий PO 1810, 1820 относительно SFN X. UE должно сначала отслеживать первый PO 1810 относительно SFN X 1800. Если оно не принимает сообщение поисковых вызовов в отслеживаемом PO, оно отслеживает третий PO 1820 относительно SFN X 1800.

[355] В варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя (т.е. сообщение поисковых вызовов включает в себя идентификатор UE), оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя, UE может не отслеживать свои остальные PO в этом DRX-цикле. Индикатор SkipAdditionalPOMonitoring предоставляет гибкость для сети в том, чтобы сразу передавать поисковые вызовы, когда канал становится доступным, или откладывать их до последующих PO.

[356] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать свои остальные PO в этом DRX-цикле.

[357] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, UE может не отслеживать свои остальные PO в этом DRX-цикле.

[358] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и отсутствует индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и отсутствует индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, UE может не отслеживать свои остальные PO в этом DRX-цикле.

[359] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и предусмотрен индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, UE отслеживает свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и предусмотрен индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, UE отслеживает свои остальные PO в этом DRX-цикле. В варианте осуществления, UE может отслеживать все свои PO в DRX-цикле.

[360] Согласно варианту осуществления, периоды PDCCH-отслеживания, соответствующие (i_s+P*n+1)-ому PO, определяются следующим образом:

[361] GNB передает в служебных сигналах конфигурацию пространства поиска поисковых вызовов (содержащую параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность). UE определяет период PDCCH-отслеживания из периодичности PDCCH-отслеживания (Monitoring-periodicity-PDCCH-slot), смещения PDCCH-отслеживания (Monitoring-offset-PDCCH-slot) и шаблона PDCCH-отслеживания (Monitoring-symbols-PDCCH-within-slot) во временном кванте. Периоды PDCCH-отслеживания находятся во временных квантах x - x+duration, где временной квант с номером x в радиокадре с номером y удовлетворяет уравнению:

[362] (y * (число временных квантов в радиокадре) + x - Monitoring-offset-PDCCH-slot) mod (Monitoring-periodicity-PDCCH-slot) = 0;

[363] Начальный символ периода PDCCH-отслеживания в каждом временном кванте, имеющем период PDCCH-отслеживания, задается посредством Monitoring-symbols-PDCCH-within-slot. Длина (в символах) периода PDCCH-отслеживания задается в базовом наборе, ассоциированном с пространством поиска.

[364] На основе конфигурации пространства поиска поисковых вызовов (содержащей параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность), UE может знать первый период PDCCH-отслеживания для поисковых вызовов в определенном PF, а также последующие периоды PDCCH-отслеживания.

[365] В TDD-соте, UE принимает TDD-конфигурацию с использованием, по меньшей мере, одного из IE tdd-UL-DL-ConfigurationCommon, IE tdd-UL-DL-ConfigurationDedicated и группового общего PDCCH. IE tdd-UL-DL-ConfigurationCommon передается в служебных сигналах в системной информации и указывает DL-символы, UL-символы и гибкие символы. IE tdd-UL-DL-ConfigurationDedicated передается в служебных сигналах в выделенной передаче служебных RRC-сигналов и указывает то, какие из гибких символов представляют собой UL-символы. Групповой общий PDCCH предоставляет TDD-конфигурацию для одного или более временных квантов.

[366] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символом(ами). UL-символ(ы) определяется согласно tdd-UL-DL-ConfigurationCommon. Периоды PDCCH-отслеживания для поисковых вызовов, которые остаются после исключения, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов и упоминаются как периоды PDCCH-отслеживания для поисковых вызовов в последующей процедуре. Следует отметить, что исключение периодов отслеживания для поисковых вызовов, которые перекрываются с UL-символами, определенными согласно параметру tdd-UL-DL-ConfigurationCommon, выполняется только в TDD-соте, поскольку в FDD-соте tdd-UL-DL-ConfigurationCommon не передается в служебных сигналах; tdd-UL-DL-ConfigurationCommon передается в служебных сигналах только в TDD-соте. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами (определенными согласно параметру tdd-UL-DL-ConfigurationCommon, передаваемому в служебных сигналах в SIB1), последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Другими словами, достоверные периоды PDCCH-отслеживания с начала PF последовательно нумеруются от нуля. Эти пронумерованные периоды PDCCH-отслеживания затем преобразуются в PO следующим образом:

[367] Когда firstPDCCH-MonitoringOccasionOfPO присутствует (firstPDCCH-MonitoringOccasionOfPO необязательно передается в служебных сигналах в конфигурации поисковых вызовов), (i_s+P*n+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+P*n+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[368] В противном случае, (i_s+P*n+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с ((i_s+P*n)*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. Следует отметить, что периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации пространства поиска поисковых вызовов.

[369] В альтернативном варианте осуществления, если несколько FDM-мультиплексированных PO поддерживаются (все PO, включающие в себя FDM-мультиплексированные PO, идентифицируются посредством i_s) посредством конфигурирования нескольких базовых наборов поисковых вызовов, и firstPDCCH-MonitoringOccasionOfPO не передается в служебных сигналах, (i_s+P*n+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с ((i_s+P*n)/C)*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. C является числом базовых наборов поисковых вызовов. В периоды PDCCH-отслеживания (i_s+P*n+1)-ого PO, UE отслеживает k-ый базовый набор поисковых вызовов, где k=(i_s+P*n) mod C.

[370] В варианте осуществления настоящего раскрытия сущности, параметр S может быть равен [число фактических передаваемых SSB, определенное согласно ssb-PositionsInBurst в SystemInformationBlock1]*X, где X передается в служебных сигналах посредством gNB, или X является числом раз, когда каждый SSB повторяется в SSB-окне.

[371] Следует отметить, что для поисковых вызовов UE, gNB также определяет PO для этого UE так же, как определяет это UE на основе процедуры, поясненной выше.

[372] Способ 3

[373] Способ 3-1

[374] Фиг. 19 иллюстрирует процедуру определения PO в DRX-цикле согласно варианту осуществления способа 3-1.

[375] Ссылаясь на фиг. 19, UE 1900 получает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns, P, M) из системной информации, передаваемой в служебных сигналах посредством сети 1901, на этапе 1910. В RRC-бездействующем и RRC-неактивном состоянии, UE также получает конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети 1901 для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов. Таким образом, в RRC-соединенном состоянии, UE получает конфигурацию пространства поиска поисковых вызовов из выделенной передачи служебных RRC-сигналов. UE также получает/принимает параметр ssb-PositionsInBurst из системной информации, т.е. из SystemInformationBlock1. Он также может приниматься в выделенной передаче служебных RRC-сигналов в RRC-соединенном состоянии.

[376] UE сначала определяет кадр поисковых вызовов на этапе 1920. PF представляет собой радиокадр с SFN, который удовлетворяет:

[377] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[378] где:

[379] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[380] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[381] UE_ID: S-TMSI mod 1024

[382] UE затем вычисляет индекс i_s на этапе 1930, где i_s извлекается из следующего уравнения:

[383] i_s=floor(UE_ID/N), mod (Ns/X), где:

[384] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

[385] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[386] P: Число PO в расчете на DRX-цикл, отслеживаемых посредством UE.

[387] M: Число PF в расчете на DRX-цикл, отслеживаемых посредством UE.

[388] X: P/M; число PO в расчете на PF, отслеживаемых посредством UE.

[389] UE_ID: S-TMSI mod 1024.

[390] Каждый DRX-цикл T (как определено выше), UE отслеживает вплоть до x PO начиная с (i_s*X+1)-ого PO во вплоть до M PF начиная с определенного PF на этапе 1920, на этапе 1940. Параметр P и M передается в служебных сигналах посредством gNB 1901 (например, в системной информации). Если PF, определенный на этапе 1920, представляет собой SFN X, UE 1900 отслеживает SFN X+k*T/N, где k=0, 1, 2, ..., M-1.

[391] Фиг. 20 иллюстрирует пример PO, отслеживаемых посредством UE, определенного посредством способа 3-1. SFN X 2000 представляет собой PF, определенный посредством UE, значение P, передаваемое в служебных сигналах посредством gNB, равно 4, значение M, передаваемое в служебных сигналах посредством gNB, равно 2, N равен T/2, и i_s, определенный посредством UE, равен 0. Таким образом, UE отслеживает первый и второй PO 2020, 2030 относительно SFN X 2000 и SFN X+2 2010. UE должно сначала отслеживать первый PO 2020 относительно SFN X 2000. Если оно не принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, оно отслеживает второй PO 2030 относительно SFN X 2000 и т.д.

[392] В варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя (т.е. сообщение поисковых вызовов включает в себя идентификатор UE), оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя, UE может не отслеживать свои остальные PO в этом DRX-цикле. Индикатор SkipAdditionalPOMonitoring предоставляет гибкость для сети в том, чтобы сразу передавать поисковые вызовы, когда канал становится доступным, или откладывать их до последующих PO.

[393] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать свои остальные PO в этом DRX-цикле.

[394] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, UE может не отслеживать свои остальные PO в этом DRX-цикле.

[395] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и отсутствует индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и отсутствует индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, оно может не отслеживать свои остальные PO в этом DRX-цикле.

[396] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и предусмотрен индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, UE отслеживает свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и предусмотрен индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, UE отслеживает свои остальные PO в этом DRX-цикле. В варианте осуществления, UE может отслеживать все свои PO в DRX-цикле.

[397] Согласно варианту осуществления, периоды PDCCH-отслеживания, соответствующие (i_s*X+1)-ому PO, определяются следующим образом:

[398] GNB передает в служебных сигналах конфигурацию пространства поиска поисковых вызовов (содержащую параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность). UE определяет период PDCCH-отслеживания из периодичности PDCCH-отслеживания (Monitoring-periodicity-PDCCH-slot), смещения PDCCH-отслеживания (Monitoring-offset-PDCCH-slot) и шаблона PDCCH-отслеживания (Monitoring-symbols-PDCCH-within-slot) во временном кванте. Периоды PDCCH-отслеживания находятся во временных квантах x - x+duration, где временной квант с номером x в радиокадре с номером y удовлетворяет уравнению:

[399] (y * (число временных квантов в радиокадре) + x - Monitoring-offset-PDCCH-slot) mod (Monitoring-periodicity-PDCCH-slot) = 0;

[400] Начальный символ периода PDCCH-отслеживания в каждом временном кванте, имеющем период PDCCH-отслеживания, задается посредством Monitoring-symbols-PDCCH-within-slot. Длина (в символах) периода PDCCH-отслеживания задается в базовом наборе, ассоциированном с пространством поиска.

[401] На основе конфигурации пространства поиска поисковых вызовов (содержащей параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность), UE может знать первый период PDCCH-отслеживания для поисковых вызовов в определенном PF, а также последующие периоды PDCCH-отслеживания.

[402] В TDD-соте, UE принимает TDD-конфигурацию с использованием, по меньшей мере, одного из IE tdd-UL-DL-ConfigurationCommon, IE tdd-UL-DL-ConfigurationDedicated и группового общего PDCCH. IE tdd-UL-DL-ConfigurationCommon передается в служебных сигналах в системной информации и указывает DL-символы, UL-символы и гибкие символы. IE tdd-UL-DL-ConfigurationDedicated передается в служебных сигналах в выделенной передаче служебных RRC-сигналов и указывает то, какие из гибких символов представляют собой UL-символы. Групповой общий PDCCH предоставляет TDD-конфигурацию для одного или более временных квантов.

[403] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символом(ами). UL-символ(ы) определяется согласно tdd-UL-DL-ConfigurationCommon. Периоды PDCCH-отслеживания для поисковых вызовов, которые остаются после исключения, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов и упоминаются как периоды PDCCH-отслеживания для поисковых вызовов в последующей процедуре. Следует отметить, что исключение периодов отслеживания для поисковых вызовов, которые перекрываются с UL-символами, определенными согласно параметру tdd-UL-DL-ConfigurationCommon, выполняется только в TDD-соте, поскольку в FDD-соте tdd-UL-DL-ConfigurationCommon не передается в служебных сигналах; tdd-UL-DL-ConfigurationCommon передается в служебных сигналах только в TDD-соте. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами (UL-символы определяются согласно параметру tdd-UL-DL-ConfigurationCommon, передаваемому в служебных сигналах в SIB1), последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Другими словами, достоверные периоды PDCCH-отслеживания с начала PF последовательно нумеруются от нуля. Эти пронумерованные периоды PDCCH-отслеживания затем преобразуются в PO следующим образом:

[404] Когда firstPDCCH-MonitoringOccasionOfPO присутствует (firstPDCCH-MonitoringOccasionOfPO необязательно передается в служебных сигналах в конфигурации поисковых вызовов), (i_s*X+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s*X+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[405] В противном случае, (i_s*X+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*X*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. Следует отметить, что периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации пространства поиска поисковых вызовов.

[406] В альтернативном варианте осуществления, если несколько FDM-мультиплексированных PO поддерживаются (все PO, включающие в себя FDM-мультиплексированные PO, идентифицируются посредством i_s) посредством конфигурирования нескольких базовых наборов поисковых вызовов, и firstPDCCH-MonitoringOccasionOfPO не передается в служебных сигналах, (i_s*X+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с ((i_s*X/C)*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. C является числом базовых наборов поисковых вызовов. В периоды PDCCH-отслеживания (i_s*X+1)-ого PO, UE отслеживает k-ый базовый набор поисковых вызовов, где k=(i_s*X) mod C.

[407] В варианте осуществления настоящего раскрытия сущности, параметр S может быть равен [число фактических передаваемых SSB, определенное согласно ssb-PositionsInBurst в SystemInformationBlock1]*L, где L передается в служебных сигналах посредством gNB, или L является числом раз, когда каждый SSB повторяется в SSB-окне.

[408] Следует отметить, что для поисковых вызовов UE, gNB также определяет PO для этого UE так же, как определяет это UE на основе процедуры, поясненной выше.

[409] Способ 3-2

[410] Фиг. 21 иллюстрирует процедуру определения PO в DRX-цикле согласно варианту осуществления способа 3-2.

[411] UE 2100 получает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns, P, M) и конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети 2101, на этапе 2110. В RRC-бездействующем и RRC-неактивном состоянии, UE также получает конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети 2101 для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов. Таким образом, в RRC-соединенном состоянии, UE получает конфигурацию пространства поиска поисковых вызовов из выделенной передачи служебных RRC-сигналов. UE также получает параметр ssb-PositionsInBurst из системной информации, т.е. из SystemInformationBlock1. Он также может приниматься в выделенной передаче служебных RRC-сигналов в RRC-соединенном состоянии.

[412] UE 2100 сначала определяет кадр поисковых вызовов на этапе 2120. PF представляет собой радиокадр с SFN, который удовлетворяет:

[413] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[414] где:

[415] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[416] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[417] UE_ID: S-TMSI mod 1024

[418] UE 2100 затем вычисляет индекс i_s на этапе 2130, где i_s извлекается из следующего уравнения:

[419] i_s=floor(UE_ID/N), mod (Ns/X), где:

[420] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

[421] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[422] P: Число PO в расчете на DRX-цикл, отслеживаемых посредством UE.

[423] M: Число PF в расчете на DRX-цикл, отслеживаемых посредством UE.

[424] X: P/M; число PO в расчете на PF, отслеживаемых посредством UE.

[425] UE_ID: S-TMSI mod 1024.

[426] Каждый DRX-цикл T (как определено выше), UE 2100 отслеживает вплоть до x PO, заданных посредством (i_s+X*n+1), где n=0, 1, 2, ..., X-1 во вплоть до M PF начиная с определенного PF на этапе 2120. Параметр P и M передается в служебных сигналах посредством gNB 2101 (например, в системной информации). Если PF, определенный на этапе 2120, представляет собой SFN X, UE 2100 отслеживает SFN X+k*T/N, где k=0, 1, 2, ..., M-1.

[427] Фиг. 22 иллюстрирует пример PO, отслеживаемых посредством UE, определенного посредством способа 3-2. SFN X 2200 представляет собой PF, определенный посредством UE, значение P, передаваемое в служебных сигналах посредством gNB, равно 4, значение M, передаваемое в служебных сигналах посредством gNB, равно 2, N равен T/2, и i_s, определенный посредством UE, равен 0. Таким образом, UE отслеживает первый и третий PO 2220, 2230 относительно SFN X 2200 и SFN X+2 2210. UE должно сначала отслеживать первый PO 2220 относительно SFN X 2200. Если оно не принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, оно отслеживает третий PO 2230 относительно SFN X 2200 и т.д.

[428] В варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя (т.е. сообщение поисковых вызовов включает в себя идентификатор UE), UE может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя, UE может не отслеживать свои остальные PO в этом DRX-цикле. Индикатор SkipAdditionalPOMonitoring предоставляет гибкость для сети в том, чтобы сразу передавать поисковые вызовы, когда канал становится доступным, или откладывать их до последующих PO.

[429] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать свои остальные PO в этом DRX-цикле.

[430] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, UE может не отслеживать свои остальные PO в этом DRX-цикле.

[431] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и отсутствует индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, оно может не отслеживать свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и отсутствует индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, оно может не отслеживать свои остальные PO в этом DRX-цикле.

[432] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и предусмотрен индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие PO, UE отслеживает свои остальные PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в отслеживаемом PO, и предусмотрен индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие PO, оно отслеживает свои остальные PO в этом DRX-цикле. В варианте осуществления, UE может отслеживать все свои PO в DRX-цикле.

[433] Периоды PDCCH-отслеживания, соответствующие (i_s+X*+1)-ому PO, определяются следующим образом:

[434] GNB передает в служебных сигналах конфигурацию пространства поиска поисковых вызовов (содержащую параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность). UE определяет период PDCCH-отслеживания из периодичности PDCCH-отслеживания (Monitoring-periodicity-PDCCH-slot), смещения PDCCH-отслеживания (Monitoring-offset-PDCCH-slot) и шаблона PDCCH-отслеживания (Monitoring-symbols-PDCCH-within-slot) во временном кванте. Периоды PDCCH-отслеживания находятся во временных квантах x - x+duration, где временной квант с номером x в радиокадре с номером y удовлетворяет уравнению:

[435] (y * (число временных квантов в радиокадре) + x - Monitoring-offset-PDCCH-slot) mod (Monitoring-periodicity-PDCCH-slot) = 0;

[436] Начальный символ периода PDCCH-отслеживания в каждом временном кванте, имеющем период PDCCH-отслеживания, задается посредством Monitoring-symbols-PDCCH-within-slot. Длина (в символах) периода PDCCH-отслеживания задается в базовом наборе, ассоциированном с пространством поиска.

[437] На основе конфигурации пространства поиска поисковых вызовов (содержащей параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность), UE может знать первый период PDCCH-отслеживания для поисковых вызовов в определенном PF, а также последующие периоды PDCCH-отслеживания.

[438] В TDD-соте, UE принимает TDD-конфигурацию с использованием, по меньшей мере, одного из IE tdd-UL-DL-ConfigurationCommon, IE tdd-UL-DL-ConfigurationDedicated и группового общего PDCCH. IE tdd-UL-DL-ConfigurationCommon передается в служебных сигналах в системной информации и указывает DL-символы, UL-символы и гибкие символы. IE tdd-UL-DL-ConfigurationDedicated передается в служебных сигналах в выделенной передаче служебных RRC-сигналов и указывает то, какие из гибких символов представляют собой UL-символы. Групповой общий PDCCH предоставляет TDD-конфигурацию для одного или более временных квантов.

[439] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символом(ами). UL-символ(ы) определяется согласно tdd-UL-DL-ConfigurationCommon. Периоды PDCCH-отслеживания для поисковых вызовов, которые остаются после исключения, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов и упоминаются как периоды PDCCH-отслеживания для поисковых вызовов в последующей процедуре. Следует отметить, что исключение периодов отслеживания для поисковых вызовов, которые перекрываются с UL-символами, определенными согласно параметру tdd-UL-DL-ConfigurationCommon, выполняется только в TDD-соте, поскольку в FDD-соте tdd-UL-DL-ConfigurationCommon не передается в служебных сигналах; tdd-UL-DL-ConfigurationCommon передается в служебных сигналах только в TDD-соте. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами (UL-символы определяются согласно параметру tdd-UL-DL-ConfigurationCommon, передаваемому в служебных сигналах в SIB1), последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Другими словами, достоверные периоды PDCCH-отслеживания с начала PF последовательно нумеруются от нуля. Эти пронумерованные периоды PDCCH-отслеживания затем преобразуются в PO следующим образом:

[440] Когда firstPDCCH-MonitoringOccasionOfPO присутствует (firstPDCCH-MonitoringOccasionOfPO необязательно передается в служебных сигналах в конфигурации поисковых вызовов), (i_s+X*n+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+X*n+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[441] В противном случае, (i_s+X*n+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с ((i_s+X*n)*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. Следует отметить, что периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации пространства поиска поисковых вызовов.

[442] В альтернативном варианте осуществления, если несколько FDM-мультиплексированных PO поддерживаются (все PO, включающие в себя FDM-мультиплексированные PO, идентифицируются посредством i_s) посредством конфигурирования нескольких базовых наборов поисковых вызовов, и firstPDCCH-MonitoringOccasionOfPO не передается в служебных сигналах, (i_s+X*n+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (((i_s+X*n)/C)*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. C является числом базовых наборов поисковых вызовов. В периоды PDCCH-отслеживания (i_s+X*n+1)-ого PO, UE отслеживает k-ый базовый набор поисковых вызовов, где k=(i_s+X*n) mod C.

[443] В варианте осуществления настоящего раскрытия сущности, параметр S может быть равен [число фактических передаваемых SSB, определенное согласно ssb-PositionsInBurst в SystemInformationBlock1]*L, где L передается в служебных сигналах посредством gNB, или L является числом раз, когда каждый SSB повторяется в SSB-окне.

[444] В способе 3-3, P является числом PO в расчете на DRX-цикл, отслеживаемых посредством UE. M является числом PF в расчете на DRX-цикл, отслеживаемых посредством UE. X является числом PO в расчете на PF, отслеживаемых посредством UE, где X=P/M. В варианте 1 и 2 осуществления, поясненном выше, P и M передаются в служебных сигналах посредством gNB. В альтернативном варианте осуществления, любой из двух параметров из числа P, M и X может передаваться в служебных сигналах посредством gNB. Третий параметр может получаться на основе взаимосвязи X=P/M. Вариант 1 или 2 осуществления затем может использоваться для того, чтобы определять PF/PO, которые должны отслеживаться посредством UE в DRX-цикле.

[445] Следует отметить, что для поисковых вызовов UE, gNB также определяет PO для этого UE так же, как определяет это UE на основе процедуры, поясненной выше.

[446] Способ 4

[447] Способ 4-1

[448] Фиг. 23 иллюстрирует процедуру определения PO в DRX-цикле согласно варианту осуществления способа 4-1.

[449] UE 2300 получает/принимает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns, X) из системной информации (т.е. SystemInformationBlock1), передаваемой в служебных сигналах посредством сети 2301, на этапе 2310. В RRC-бездействующем и RRC-неактивном состоянии, UE также получает/принимает конфигурацию пространства поиска поисковых вызовов из системной информации (т.е. SystemInformationBlock1), передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов. Таким образом, в RRC-соединенном состоянии, UE получает/принимает конфигурацию пространства поиска поисковых вызовов из выделенной передачи служебных RRC-сигналов. UE также получает параметр ssb-PositionsInBurst из системной информации, т.е. из SystemInformationBlock1. Он также может приниматься в выделенной передаче служебных RRC-сигналов в RRC-соединенном состоянии.

[450] UE 2300 сначала определяет кадр поисковых вызовов на этапе 2320. PF представляет собой радиокадр с SFN, который удовлетворяет:

[451] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[452] где:

[453] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[454] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[455] UE_ID: S-TMSI mod 1024

[456] UE 2300 затем вычисляет индекс i_s на этапе 2330, где i_s извлекается из следующего уравнения:

[457] i_s=floor(UE_ID/N) mod Ns, где:

[458] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

[459] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[460] UE_ID: S-TMSI mod 1024.

[461] На этапе 2340, UE 2300 определяет достоверные периоды PDCCH-отслеживания для поисковых вызовов с начала определенного PF на этапе 2320.

[462] GNB передает в служебных сигналах конфигурацию пространства поиска поисковых вызовов (содержащую параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность). UE определяет период PDCCH-отслеживания из периодичности PDCCH-отслеживания (Monitoring-periodicity-PDCCH-slot), смещения PDCCH-отслеживания (Monitoring-offset-PDCCH-slot) и шаблона PDCCH-отслеживания (Monitoring-symbols-PDCCH-within-slot) во временном кванте. Периоды PDCCH-отслеживания находятся во временных квантах x - x+duration, где временной квант с номером x в радиокадре с номером y удовлетворяет уравнению:

[463] (y * (число временных квантов в радиокадре) + x - Monitoring-offset-PDCCH-slot) mod (Monitoring-periodicity-PDCCH-slot) = 0;

[464] Начальный символ периода PDCCH-отслеживания в каждом временном кванте, имеющем период PDCCH-отслеживания, задается посредством Monitoring-symbols-PDCCH-within-slot. Длина (в символах) периода PDCCH-отслеживания задается в базовом наборе, ассоциированном с пространством поиска.

[465] На основе конфигурации пространства поиска поисковых вызовов (содержащей параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность), UE может знать первый период PDCCH-отслеживания для поисковых вызовов в определенном PF, а также последующие периоды PDCCH-отслеживания.

[466] В TDD-соте, UE принимает TDD-конфигурацию с использованием, по меньшей мере, одного из IE tdd-UL-DL-ConfigurationCommon, IE tdd-UL-DL-ConfigurationDedicated и группового общего PDCCH. IE tdd-UL-DL-ConfigurationCommon передается в служебных сигналах в системной информации и указывает DL-символы, UL-символы и гибкие символы. IE tdd-UL-DL-ConfigurationDedicated передается в служебных сигналах в выделенной передаче служебных RRC-сигналов и указывает то, какие из гибких символов представляют собой UL-символы. Групповой общий PDCCH предоставляет TDD-конфигурацию для одного или более временных квантов.

[467] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символом(ами). UL-символ(ы) определяется согласно tdd-UL-DL-ConfigurationCommon. Следует отметить, что исключение периодов отслеживания для поисковых вызовов, которые перекрываются с UL-символами, определенными согласно параметру tdd-UL-DL-ConfigurationCommon, выполняется только в TDD-соте, поскольку в FDD-соте tdd-UL-DL-ConfigurationCommon не передается в служебных сигналах; tdd-UL-DL-ConfigurationCommon передается в служебных сигналах только в TDD-соте. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами (UL-символы определяются согласно параметру tdd-UL-DL-ConfigurationCommon, передаваемому в служебных сигналах в SIB1), последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Другими словами, достоверные периоды PDCCH-отслеживания с начала PF последовательно нумеруются от нуля. Эти пронумерованные периоды PDCCH-отслеживания затем преобразуются в PO.

[468] На этапе 2350, каждый DRX-цикл T (как определено выше), UE отслеживает (i_s+1)-ый PO в определенном PF на этапе 2320. Периоды PDCCH-отслеживания, соответствующие (i_s+1)-ому PO, определяются следующим образом:

[469] Когда firstPDCCH-MonitoringOccasionOfPO присутствует (firstPDCCH-MonitoringOccasionOfPO необязательно передается в служебных сигналах в конфигурации поисковых вызовов), (i_s+1)-ый PO представляет собой набор из S*X последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[470] В противном случае, (i_s+1)-ый PO представляет собой набор из S*X последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S*X)-ого периода PDCCH-отслеживания для поисковых вызовов.

[471] S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. Параметр ssb-PositionsInBurst в SystemInformationBlock1 указывает то, какие SSB передаются посредством gNB; ssb-PositionsInBurst представляет собой битовую карту. Первый/самый левый бит в ssb-PositionsInBurst соответствует индексу SS/PBCH-блока 0, второй бит соответствует индексу 1 SS/PBCH-блока и т.д. Значение 0 в битовой карте указывает то, что соответствующий SS/PBCH-блок не передается, в то время как значение 1 указывает то, что соответствующий SS/PBCH-блок передается. Например, скажем, что ssb-PositionsInBurst (посредством задания соответствующего бита битовой карты равным 1) указывает то, что SSB-индекс 4, SSB-индекс 8, SSB-индекс 14 и SSB-индекс 16 передаются посредством gNB. Поскольку передаются четыре SSB, S равен 4.

[472] x передается в служебных сигналах посредством gNB в конфигурации поисковых вызовов, или x является числом раз, когда каждый SSB повторяется в SSB-окне. x также может упоминаться как коэффициент расширения для расширения PO или для конфигурирования дополнительных периодов PDCCH-отслеживания в PO. X также может упоминаться как число периодов PDCCH-отслеживания в расчете на SSB в PO. Следует отметить, что периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации пространства поиска поисковых вызовов. Значение по умолчанию X может предполагаться в качестве 1, т.е. если x не передается в служебных сигналах, X задается равным 1 для определения периодов PDCCH-отслеживания PO. В варианте осуществления, x передается в служебных сигналах посредством gNB для поисковых вызовов на нелицензированной несущей или в соте, в которой DL-несущая находится в нелицензированной полосе частот.

[473] В альтернативном варианте осуществления, если несколько FDM-мультиплексированных PO поддерживаются (все PO, включающие в себя FDM-мультиплексированные PO, идентифицируются посредством i_s) посредством конфигурирования нескольких базовых наборов поисковых вызовов, и firstPDCCH-MonitoringOccasionOfPO не передается в служебных сигналах, (i_s+1)-ый PO представляет собой набор из S*X последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с ((i_s/C)*S*X)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. C является числом базовых наборов поисковых вызовов. В периоды PDCCH-отслеживания (i_s+1)-ого PO, UE отслеживает k-ый базовый набор поисковых вызовов, где k=i_s mod C.

[474] В другом варианте осуществления, вместо X, PO-длительность во временных квантах/символах может передаваться в служебных сигналах. PO содержит все периоды PDCCH-отслеживания в PO-длительности. В другом варианте осуществления, вместо x, параметр A, т.е. число периодов PDCCH-отслеживания в PO может передаваться в служебных сигналах. В этом случае, в вышеприведенном описании, S*X заменяется посредством A. В варианте осуществления, вместо передачи в служебных сигналах x сеть может передавать в служебных сигналах число периодов PDCCH-отслеживания в PO, при этом X=(число периодов PDCCH-отслеживания в PO)/(число фактических передаваемых SSB, определенное согласно ssb-PositionsInBurst в SystemInformationBlock1).

[475] Каждый период PDCCH-отслеживания для поисковых вызовов в PO ассоциирован с одним из передаваемых SSB (или SS/PBCH-блоков). На основе этого ассоциирования, UE может определять период PDCCH-отслеживания, соответствующий одному или более подходящих SSB (например, SSB с RSRP SS выше порогового значения), и отслеживать только эти периоды PDCCH-отслеживания в PO. В существующей системе, K-ый период PDCCH-отслеживания для поисковых вызовов в PO соответствует K-ому передаваемому SSB. Тем не менее, это правило преобразования между периодами PDCCH-отслеживания PO и передаваемыми SSB работает только в том случае, если число периодов PDCCH-отслеживания в PO равно числу передаваемых SSB. Как описано выше, каждый PO состоит из S*X периодов PDCCH-отслеживания, и для X>1, число периодов PDCCH-отслеживания в PO превышает число передаваемых SSB. Таким образом, требуется новое правило преобразования между периодами PDCCH-отслеживания в PO и передаваемыми SSB.

[476] Предусмотрено вплоть до 64 SSB, и каждый SSB уникально идентифицируется посредством SSB-идентификатора. Параметр ssb-PositionsInBurst в SystemInformationBlock1 указывает то, какие SSB передаются посредством gNB; ssb-PositionsInBurst представляет собой битовую карту. Первый/самый левый бит в ssb-PositionsInBurst соответствует индексу SS/PBCH-блока 0, второй бит соответствует индексу 1 SS/PBCH-блока и т.д. Значение 0 в битовой карте указывает то, что соответствующий SS/PBCH-блок не передается, в то время как значение 1 указывает то, что соответствующий SS/PBCH-блок передается.

[477] В варианте осуществления, [(K-1)*X+x)]-ый период PDCCH-отслеживания в PO соответствует K-ому передаваемому SSB, где x=0, 1, ..., X-1; и K=1, 2, ..., S. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SIB1, и x является числом периодов PDCCH-отслеживания в расчете на SSB. Следует отметить, что фактические передаваемые SSB последовательно нумеруются от 1 до S в порядке возрастания своих SSB-индексов. Например, скажем, что ssb-PositionsInBurst указывает то, что SSB-индекс 4, SSB-индекс 8, SSB-индекс 14 и SSB-индекс 16 передаются посредством gNB. Таким образом, S равен 4, и K равен 1 для SSB с SSB-индексом 4, K равен 2 для SSB с SSB-индексом 8, K равен 3 для SSB с SSB-индексом 14, и K равен 4 для SSB с SSB-индексом 16. Фиг. 24 иллюстрирует пример периодов PDCCH-отслеживания в PO, соответствующих передаваемым SSB согласно варианту осуществления способа 4-1. Ссылаясь на фиг. 24, один или более периодов PDCCH-отслеживания, соответствующих конкретному SSB 2400, выделяются в порядке индексов передаваемых SSB в PO. Каждый передаваемый SSB преобразуется в X последовательных периодов PDCCH-отслеживания, при этом SSB преобразуются в периоды PDCCH-отслеживания в PO в порядке возрастания своих SSB-индексов.

[478] В другом варианте осуществления, (x*S+K)-ый период PDCCH-отслеживания для поисковых вызовов в PO соответствует K-ому передаваемому SSB, где x=0, 1, ..., X-1; и K=1, 2, ..., S. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SIB1, и x является числом периодов PDCCH-отслеживания в расчете на SSB. Следует отметить, что фактические передаваемые SSB последовательно нумеруются от 1 до S в порядке возрастания своих SSB-индексов. Например, скажем, что ssb-PositionsInBurst указывает то, что SSB-индекс 4, SSB-индекс 8, SSB-индекс 14 и SSB-индекс 16 передаются посредством gNB. Таким образом, K равен 1 для SSB с SSB-индексом 4, K равен 2 для SSB с SSB-индексом 8, K равен 3 для SSB с SSB-индексом 14, и K равен 4 для SSB с SSB-индексом 16. Фиг. 25 иллюстрирует другие примерные периоды PDCCH-отслеживания в PO, соответствующие передаваемым SSB согласно варианту осуществления способа 4-1. Ссылаясь на фиг. 25, каждый период PDCCH-отслеживания, соответствующий каждому передаваемому SSB 2500, выделяется в порядке индексов передаваемых SSB. Несколько наборов периодов PDCCH-отслеживания, соответствующих передаваемым SSB, могут выделяться в PO. В этом способе, PO состоит из x наборов из S последовательных периодов PDCCH-отслеживания, причем каждый набор из S последовательных периодов PDCCH-отслеживания преобразуется в S передаваемых SSB последовательно в порядке увеличения SSB-индексов.

[479] В существующей системе, один PO состоит только из S периодов PDCCH-отслеживания. Тем не менее, в этом способе, PO расширяется, чтобы предоставлять дополнительные возможности (S*X, где X>1) передавать PDCCH, адресованный в P-RNTI, на нелицензированной несущей, поскольку канал не всегда может быть доступным на нелицензированной несущей. Тем не менее, это может увеличивать потребление мощности UE. Таким образом, требуются некоторые критерии для того, чтобы прекращать отслеживание периодов PDCCH-отслеживания в PO.

[480] В варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя (т.е. сообщение поисковых вызовов включает в себя идентификатор UE), UE может не отслеживать оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, при этом сообщение поисковых вызовов в DL TB, диспетчеризуемом посредством этого PDCCH, включает в себя поисковые вызовы для себя, UE может не отслеживать оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле. Индикатор SkipAdditionalPMOMonitoring предоставляет гибкость для сети в том, чтобы сразу передавать поисковые вызовы, когда канал становится доступным, или откладывать их до последующих периодов PDCCH-отслеживания PO.

[481] В варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов (может включать в себя или может не включать в себя поисковые вызовы для себя), UE может не отслеживать оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле.

[482] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, UE может не отслеживать оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле. В другом варианте осуществления, если сеть передает в служебных сигналах SkipAdditionalPOMonitoring в системной информации или выделенной передаче служебных RRC-сигналов, и если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, UE может не отслеживать оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле.

[483] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и отсутствует индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать другие периоды PDCCH-отслеживания PO, UE может не отслеживать оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, и отсутствует индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать другие периоды PDCCH-отслеживания PO, UE может не отслеживать оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле.

[484] В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, при этом DL TB, диспетчеризуемый посредством этого PDCCH, включает в себя сообщение поисковых вызовов, и предусмотрен индикатор в принимаемом сообщении поисковых вызовов на предмет того, чтобы отслеживать оставшиеся периоды PDCCH-отслеживания PO, UE отслеживает оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле. В другом варианте осуществления, если UE принимает PDCCH, адресованный в P-RNTI, в период PDCCH-отслеживания отслеживаемого PO, и предусмотрен индикатор в принимаемом PDCCH на предмет того, чтобы отслеживать оставшиеся периоды PDCCH-отслеживания PO, UE отслеживает оставшиеся периоды PDCCH-отслеживания отслеживаемого PO в этом DRX-цикле.

[485] Следует отметить, что для поисковых вызовов UE, gNB также определяет PO для этого UE так же, как определяет это UE на основе процедуры, поясненной выше.

[486] Способ 5

[487] В одном варианте осуществления способа 5 настоящего раскрытия сущности, UE определяет PO в DRX-цикле следующим образом:

[488] Этап 1: UE получает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns) из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-бездействующем и RRC-неактивном состоянии, UE также получает конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов. Таким образом, в RRC-соединенном состоянии, UE получает конфигурацию пространства поиска поисковых вызовов из выделенной передачи служебных RRC-сигналов.

[489] Этап 2: UE сначала определяет кадр поисковых вызовов. PF представляет собой радиокадр с SFN, который удовлетворяет:

[490] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[491] где:

[492] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[493] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[494] UE_ID: S-TMSI mod 1024

[495] Этап 3: UE затем вычисляет индекс i_s, где i_s извлекается из следующего уравнения:

[496] i_s=floor(UE_ID/N) mod Ns, где:

[497] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

[498] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[499] UE_ID: S-TMSI mod 1024.

[500] Этап 4: Каждый DRX-цикл, UE отслеживает (i_s+1)-ый PO в определенном PF на этапе 2.

[501] Периоды PDCCH-отслеживания, соответствующие (i_s+1)-ому PO, определяются следующим образом:

[502] GNB передает в служебных сигналах конфигурацию пространства поиска поисковых вызовов (содержащую параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность). UE определяет период PDCCH-отслеживания из периодичности PDCCH-отслеживания (Monitoring-periodicity-PDCCH-slot), смещения PDCCH-отслеживания (Monitoring-offset-PDCCH-slot) и шаблона PDCCH-отслеживания (Monitoring-symbols-PDCCH-within-slot) во временном кванте. Периоды PDCCH-отслеживания находятся во временных квантах x - x+duration, где временной квант с номером x в радиокадре с номером y удовлетворяет уравнению:

[503] (y * (число временных квантов в радиокадре) + x - Monitoring-offset-PDCCH-slot) mod (Monitoring-periodicity-PDCCH-slot) = 0;

[504] Начальный символ периода PDCCH-отслеживания в каждом временном кванте, имеющем период PDCCH-отслеживания, задается посредством Monitoring-symbols-PDCCH-within-slot. Длина (в символах) периода PDCCH-отслеживания задается в базовом наборе, ассоциированном с пространством поиска.

[505] На основе конфигурации пространства поиска поисковых вызовов (содержащей параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность), UE может знать первый период PDCCH-отслеживания для поисковых вызовов в определенном PF, а также последующие периоды PDCCH-отслеживания.

[506] В TDD-соте, UE принимает TDD-конфигурацию с использованием, по меньшей мере, одного из IE tdd-UL-DL-ConfigurationCommon, IE tdd-UL-DL-ConfigurationDedicated и группового общего PDCCH. IE tdd-UL-DL-ConfigurationCommon передается в служебных сигналах в системной информации и указывает DL-символы, UL-символы и гибкие символы. IE tdd-UL-DL-ConfigurationDedicated передается в служебных сигналах в выделенной передаче служебных RRC-сигналов и указывает то, какие из гибких символов представляют собой UL-символы. Групповой общий PDCCH предоставляет TDD-конфигурацию для одного или более временных квантов.

[507] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символом(ами). UL-символ(ы) определяется согласно tdd-UL-DL-ConfigurationCommon. Следует отметить, что исключение периодов отслеживания для поисковых вызовов, которые перекрываются с UL-символами, определенными согласно параметру tdd-UL-DL-ConfigurationCommon, выполняется только в TDD-соте, поскольку в FDD-соте tdd-UL-DL-ConfigurationCommon не передается в служебных сигналах. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами (UL-символы определяются согласно параметру tdd-UL-DL-ConfigurationCommon, передаваемому в служебных сигналах в SIB1), последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Другими словами, достоверные периоды PDCCH-отслеживания с начала PF последовательно нумеруются от нуля. Эти пронумерованные периоды PDCCH-отслеживания затем преобразуются в PO следующим образом:

[508] Когда firstPDCCH-MonitoringOccasionOfPO присутствует, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[509] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. Следует отметить, что периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации пространства поиска поисковых вызовов.

[510] В периоды PDCCH-отслеживания (i_s+1)-ого PO, UE отслеживает P базовых наборов поисковых вызовов (базовый набор указывает RB в частотной области и длительность в символах; длительность начинается с начала символа, указываемого посредством периода PDCCH-отслеживания). GNB передает в служебных сигналах C базовых наборов поисковых вызовов (например, в конфигурации поисковых вызовов). В варианте осуществления, UE отслеживает все базовые наборы поисковых вызовов (т.е. P равно C). В другом варианте осуществления, UE отслеживает P базовых наборов поисковых вызовов из числа C базовых наборов поисковых вызовов начиная с i-ого базового набора, где i=UE_ID mod P. UE может определять P на основе своих характеристик. Значение P также может информироваться посредством UE в сеть в сообщении с информацией характеристик UE (или в любом другом служебном сообщении).

[511] Способ 6

[512] В этом варианте осуществления настоящего раскрытия сущности, поисковые вызовы поддерживаются в нескольких BWP (скажем, C BWP), и UE может отслеживать сообщение поисковых вызовов в P BWP. Список BWP, в которых поддерживаются поисковые вызовы, передается в служебных сигналах посредством gNB. Конфигурация поисковых вызовов (например, длительность DRX-цикла, N, Ns, PF_Offset, конфигурация пространства поиска, базовые наборы и т.д.) может передаваться в служебных сигналах для каждой из этих BWP. Попеременно конфигурация поисковых вызовов является общей для всех этих BWP. В варианте осуществления, UE отслеживает поисковые вызовы во всех C BWP (т.е. P равно C). В другом варианте осуществления, UE отслеживает P BWP из числа C BWP начиная с i-ой BWP, где i=UE_ID mod P. UE также может определять P на основе своих характеристик. Значение P также может информироваться посредством UE в сеть в сообщении с информацией характеристик UE (или в любом другом служебном сообщении).

[513] В каждой отслеживаемой BWP, UE определяет PF/PO с использованием одного из способов (1-5), поясненных ранее, либо с использованием способа, описанного в технических требованиях 3GPP (TS 38.304).

[514] Вариант 2-2 осуществления: PF/PO-определение, когда поддерживаются несколько FDM-мультиплексированных PO

[515] В существующей системе, в DRX-цикле поддерживаются несколько мультиплексированных с временным разделением каналов (TDM-мультиплексированных) PO. Если PO FDM-мультиплексируются, а также TDM-мультиплексируются, то требуется способ для того, чтобы определять PO для UE.

[516] Вариант 2-2-1 осуществления

[517] Пространство поиска является общим для всех PO. Сконфигурированы несколько базовых наборов.

[518] В одном варианте осуществления способа 5 настоящего раскрытия сущности, UE определяет PO в DRX-цикле следующим образом:

[519] Этап 1: UE получает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns), список базовых наборов поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-бездействующем и RRC-неактивном состоянии, UE также получает конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов. Таким образом, в RRC-соединенном состоянии, UE получает конфигурацию пространства поиска поисковых вызовов из выделенной передачи служебных RRC-сигналов.

[520] Этап 2: UE сначала определяет кадр поисковых вызовов. PF представляет собой радиокадр с SFN, который удовлетворяет:

[521] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[522] где:

[523] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[524] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[525] UE_ID: S-TMSI mod 1024

[526] Этап 3: UE затем вычисляет индекс i_s, где i_s извлекается из следующего уравнения:

[527] i_s=floor(UE_ID/N) mod Ns, где:

[528] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

[529] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[530] UE_ID: S-TMSI mod 1024.

[531] Этап 4: Каждый DRX-цикл, UE отслеживает (i_s+1)-ый PO в определенном PF на этапе 2. Периоды PDCCH-отслеживания, соответствующие (i_s+1)-ому PO, определяются следующим образом:

[532] GNB передает в служебных сигналах конфигурацию пространства поиска поисковых вызовов (содержащую параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность). UE определяет период PDCCH-отслеживания из периодичности PDCCH-отслеживания (Monitoring-periodicity-PDCCH-slot), смещения PDCCH-отслеживания (Monitoring-offset-PDCCH-slot) и шаблона PDCCH-отслеживания (Monitoring-symbols-PDCCH-within-slot) во временном кванте. Периоды PDCCH-отслеживания находятся во временных квантах x - x+duration, где временной квант с номером x в радиокадре с номером y удовлетворяет уравнению:

[533] (y * (число временных квантов в радиокадре) + x - Monitoring-offset-PDCCH-slot) mod (Monitoring-periodicity-PDCCH-slot) = 0;

[534] Начальный символ периода PDCCH-отслеживания в каждом временном кванте, имеющем период PDCCH-отслеживания, задается посредством Monitoring-symbols-PDCCH-within-slot. Длина (в символах) периода PDCCH-отслеживания задается в базовом наборе, ассоциированном с пространством поиска.

[535] На основе конфигурации пространства поиска поисковых вызовов (содержащей параметры Monitoring-periodicity-PDCCH-slot, Monitoring-offset-PDCCH-slot, Monitoring-symbols-PDCCH-within-slot и длительность), UE может знать первый период PDCCH-отслеживания для поисковых вызовов в определенном PF, а также последующие периоды PDCCH-отслеживания.

[536] В TDD-соте, UE принимает TDD-конфигурацию с использованием, по меньшей мере, одного из IE tdd-UL-DL-ConfigurationCommon, IE tdd-UL-DL-ConfigurationDedicated и группового общего PDCCH. IE tdd-UL-DL-ConfigurationCommon передается в служебных сигналах в системной информации и указывает DL-символы, UL-символы и гибкие символы. IE tdd-UL-DL-ConfigurationDedicated передается в служебных сигналах в выделенной передаче служебных RRC-сигналов и указывает то, какие из гибких символов представляют собой UL-символы. Групповой общий PDCCH предоставляет TDD-конфигурацию для одного или более временных квантов.

[537] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символом(ами). UL-символ(ы) определяется согласно tdd-UL-DL-ConfigurationCommon. Следует отметить, что исключение периодов отслеживания для поисковых вызовов, которые перекрываются с UL-символами, определенными согласно параметру tdd-UL-DL-ConfigurationCommon, выполняется только в TDD-соте, поскольку в FDD-соте tdd-UL-DL-ConfigurationCommon не передается в служебных сигналах. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами (UL-символы определяются согласно параметру tdd-UL-DL-ConfigurationCommon, передаваемому в служебных сигналах в SIB1), последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Другими словами, достоверные периоды PDCCH-отслеживания с начала PF последовательно нумеруются от нуля. Эти пронумерованные периоды PDCCH-отслеживания затем преобразуются в PO следующим образом:

[538] Когда firstPDCCH-MonitoringOccasionOfPO присутствует, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[539] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с ((i_s/C)*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. C является числом базовых наборов поисковых вызовов. Следует отметить, что периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации пространства поиска поисковых вызовов.

[540] В варианте осуществления настоящего раскрытия сущности, параметр S может быть равен [число фактических передаваемых SSB, определенное согласно ssb-PositionsInBurst в SystemInformationBlock1]*L, где L передается в служебных сигналах посредством gNB, или L является числом раз, когда каждый SSB повторяется в SSB-окне.

[541] В периоды PDCCH-отслеживания (i_s+1)-ого PO, UE отслеживает k-ый базовый набор поисковых вызовов, где k=i_s mod C. Фиг. 26 иллюстрирует пример преобразования между PO и базовыми наборами для случая Ns=4 и C=2 согласно варианту 2-2-1 осуществления. Ссылаясь на фиг. 26, 4 PO 2600 выделяются в интервале PF, и PO, соответствующие базовым наборам, FDM-мультиплексируются.

[542] Вариант 2-2-2 осуществления: сконфигурированы несколько пространств поиска.

[543] В одном варианте осуществления способа 5 настоящего раскрытия сущности, UE определяет PO в DRX-цикле следующим образом:

[544] Этап 1: UE получает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns), список конфигурации пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов.

[545] Этап 2: UE сначала определяет кадр поисковых вызовов. PF представляет собой радиокадр с SFN, который удовлетворяет:

[546] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[547] где:

[548] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[549] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[550] UE_ID: S-TMSI mod 1024

[551] Этап 3: UE затем вычисляет индекс i_s, где i_s извлекается из следующего уравнения:

[552] i_s=floor(UE_ID/N) mod Ns, где:

[553] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

[554] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[555] UE_ID: S-TMSI mod 1024.

[556] Этап 4: Каждый DRX-цикл, UE отслеживает (i_s+1)-ый PO в определенном PF на этапе 2.

[557] Периоды PDCCH-отслеживания, соответствующие (i_s+1)-ому PO, определяются следующим образом:

[558] UE определяет периоды PDCCH-отслеживания на основе k-ого пространства поиска поисковых вызовов, где k=i_s mod C, C является числом пространств поиска поисковых вызовов. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами (UL-символы определяются согласно параметру tdd-UL-DL-ConfigurationCommon, передаваемому в служебных сигналах в SIB1), последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF.

[559] Когда firstPDCCH-MonitoringOccasionOfPO присутствует, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[560] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с ((i_s/C)*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно ssb-PositionsInBurst в SystemInformationBlock1. C является числом пространств поиска поисковых вызовов.

[561] В варианте осуществления настоящего раскрытия сущности, параметр S может быть равен [число фактических передаваемых SSB, определенное согласно ssb-PositionsInBurst в SystemInformationBlock1]*L, где L передается в служебных сигналах посредством gNB, или L является числом раз, когда каждый SSB повторяется в SSB-окне.

[562] В периоды PDCCH-отслеживания (i_s+1)-ого PO, UE отслеживает базовый набор поисковых вызовов, соответствующий определенному пространству поиска поисковых вызовов.

[563] Вариант 2-3 осуществления: PO-определение для ассоциирования по умолчанию

[564] Для ассоциирования по умолчанию (т.е. когда параметр paging-SearchSpace, передаваемый в служебных сигналах посредством gNB, задается равным 0), периоды PDCCH-отслеживания для поисковых вызовов являются такими же как периоды PDCCH-отслеживания для RMSI. Согласно текущему проектному решению, для ассоциирования по умолчанию, Ns равен 1 или 2. Ns передается в служебных сигналах посредством gNB. Для Ns=1, предусмотрен только один PO, который начинается в PF. Для Ns=2, PO находится либо в первом полукадре (i_s=0), либо во втором полукадре (i_s=1) PF.

[565] Для RMSI-шаблона 2/3 (т.е. периоды PDCCH-отслеживания для RMSI возникают в одни и те же моменты времени с SSB), может быть предусмотрено вплоть до двух PO в PF, если период набора SS-пакетов составляет 5 мс. Если Ns задается равным единице, то UE должно отслеживать PO в первом полукадре или втором полукадре. Следует отметить, что оба из них начинаются в PF. Если UE отслеживает в первом полукадре, но сеть передает во втором полукадре, UE должно пропускать поисковые вызовы. Если UE отслеживает во втором полукадре, но сеть передает в первом полукадре, UE должно пропускать поисковые вызовы.

[566] Вариант 2-3-1 осуществления

[567] Чтобы преодолевать проблему, предлагается, что для ассоциирования по умолчанию (т.е. когда параметр paging-SearchSpace, передаваемый в служебных сигналах посредством gNB, задается равным 0), если Ns=1, предусмотрен только один PO, который начинается с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Для ассоциирования по умолчанию, периоды PDCCH-отслеживания для поисковых вызовов являются такими же как периоды PDCCH-отслеживания для RMSI.

[568] PF/PO-определение для ассоциирования по умолчанию (т.е. когда параметр paging-SearchSpace, передаваемый в служебных сигналах посредством gNB, задается равным 0) согласно варианту 2-3-1 осуществления заключается в следующем:

[569] Этап 1: UE получает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns), конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов.

[570] [571] Этап 2: UE сначала определяет кадр поисковых вызовов. PF представляет собой радиокадр с SFN, который удовлетворяет:

[572] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[573] где:

[574] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[575] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[576] UE_ID: S-TMSI mod 1024

[577] Этап 3: UE затем вычисляет индекс i_s, где i_s извлекается из следующего уравнения:

[578] i_s=floor(UE_ID/N) mod Ns, где:

[579] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации). Следует отметить, что все PO, соответствующие PF, не должны обязательно быть расположены в этом PF. Они могут быть расположены в одном или более радиокадров начиная с PF.

[580] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[581] UE_ID: S-TMSI mod 1024.

[582] Для Ns=2 и i_s=0, UE отслеживает PO в первом полукадре PF. Для Ns=2 и i_s=1, UE отслеживает PO во втором полукадре PF. Для Ns=1, предусмотрен только один PO, который начинается с первого периода PDCCH-отслеживания для поисковых вызовов в PF. Для ассоциирования по умолчанию, периоды PDCCH-отслеживания для поисковых вызовов являются такими же как периоды PDCCH-отслеживания для RMSI.

[583] Вариант 2-3-2 осуществления

[584] В альтернативном варианте осуществления, если Ns=1, и RMSI-шаблон составляет 2/3, и период набора SS-пакетов составляет 5 мс, s gNB может указывать в конфигурации поисковых вызовов то, находится PO в первом полукадре или втором полукадре PF. UE должно отслеживать PO в первом полукадре или втором полукадре PF, соответственно.

[585] PF/PO-определение для ассоциирования по умолчанию (т.е. когда параметр paging-SearchSpace, передаваемый в служебных сигналах посредством gNB, задается равным 0) согласно варианту 2-3-2 осуществления заключается в следующем:

[586] Этап 1: UE получает конфигурацию поисковых вызовов (длительность DRX-цикла по умолчанию, PF_Offset, N, Ns), конфигурацию пространства поиска поисковых вызовов из системной информации, передаваемой в служебных сигналах посредством сети. В RRC-соединенном состоянии, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством сети для одной или более сконфигурированных BWP в выделенной передаче служебных сигналов.

[587] Этап 2: UE сначала определяет кадр поисковых вызовов. PF представляет собой радиокадр с SFN, который удовлетворяет:

[588] (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N)

[589] где:

[590] T: DRX-цикл UE. T определяется посредством кратчайшего из конкретного для UE DRX-значения, если выделяется посредством верхних уровней (например, NAS), и DRX-значения по умолчанию, передаваемого в служебных сигналах в системной информации. Если конкретный для UE DRX не сконфигурирован посредством верхних уровней, значение по умолчанию применяется.

[591] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации). Значения N могут составлять T, T/2, T/4, T/8, T/16, T/32 и т.д.

[592] UE_ID: S-TMSI mod 1024

[593] Этап 3: UE затем вычисляет индекс i_s, где i_s извлекается из следующего уравнения:

[594] i_s=floor(UE_ID/N) mod Ns, где:

[595] Ns: Число PO в расчете на PF. Параметр Ns передается в служебных сигналах посредством gNB (например, в системной информации).

[596] N: Число кадров поисковых вызовов в DRX-цикле. N передается в служебных сигналах посредством gNB (например, в системной информации).

[597] UE_ID: S-TMSI mod 1024.

[598] Для Ns=2 и i_s=0, UE отслеживает PO в первом полукадре PF. Для Ns=2 и i_s=1, UE отслеживает PO во втором полукадре PF. Если Ns=1, и RMSI-шаблон составляет 2/3, и период набора SS-пакетов составляет 5 мс, gNB указывает в конфигурации поисковых вызовов то, находится PO в первом полукадре или втором полукадре PF. UE должно отслеживать PO в первом полукадре или втором полукадре PF, соответственно. Если gNB не указывает то, находится PO в первом полукадре или втором полукадре, UE должно отслеживать PO, который начинается (т.е. с первого периода PDCCH-отслеживания) в PF.

[599] Для ассоциирования по умолчанию (т.е. пространство поиска поисковых вызовов задается равным нулю):

[600] Если RMSI-шаблон составляет 2/3:

[601] - Если период набора SS-пакетов составляет 5 мс:

[602] -- Если gNB задает Ns равным 1, он указывает PO-местоположение в PF (первый полукадр или второй полукадр)

[603] -- Иначе, если gNB задает Ns равным 2, он не указывает PO-местоположение в PF

[604] Иначе

[605] -- GNB задает Ns равным 1

[606] -- Он не указывает PO-местоположение в PF

[607] Иначе, если RMSI-шаблон равен 1

[608] - GNB задает Ns равным 1

[609] - Он не указывает PO-местоположение в PF

[610] Если пространство поиска поисковых вызовов задается равным нулю, и если RMSI-шаблон составляет 2/3, и период набора SS-пакетов составляет 5 мс, и Ns равен одному, UE отслеживает PO в первом полукадре или втором полукадре, как указано посредством gNB в конфигурации поисковых вызовов.

[611] Вариант 2-4 осуществления: прием SI-сообщений

[612] В системе беспроводной связи пятого поколения (также упоминаемого как "NR" или "новый стандарт радиосвязи"), системная информация разделяется на минимальную системную информацию (SI) (содержащую MIB и SIB1) и другую SI (SIB 2, SIB 3 и т.д.). SIB, отличные от SIB1, переносятся в сообщениях с системной информацией (SI), которые передаются по DL-SCH. Только SIB, имеющие такую же периодичность, могут преобразовываться в такое же SI-сообщение. Каждое SI-сообщение передается в периодически возникающих окнах во временной области (называемых "SI-окнами" с одинаковой длиной для всех SI-сообщений). Каждое SI-сообщение ассоциировано с SI-окном, и SI-окна различных SI-сообщений не перекрываются. Таким образом, в одном SI-окне передается только соответствующее SI-сообщение. Информация диспетчеризации в SIB1 включает в себя преобразование между SIB и SI-сообщениями, периодичность каждого SI-сообщения и длину SI-окна.

[613] В SI-окне SI-сообщения, UE отслеживает сконфигурированные периоды PDCCH-отслеживания (посредством параметра конфигурации пространства поиска из другой системной информации (OSI)) для SI-сообщения. K-ый период PDCCH-отслеживания в SI-окне соответствует K-ому передаваемому SSB. Это обеспечивает возможность UE отслеживать только период PDCCH-отслеживания, соответствующий подходящему (т.е. хорошему SSB или SSB с RSRP выше указанного порогового значения) SSB. В частотной области, полоса пропускания (или базовый набор) для приема SI-сообщений представляет собой начальную BWP (передаваемую в служебных сигналах в SIB1 или MIB).

[614] Фиг. 27 иллюстрирует пример начальной BWP для SI-приема согласно варианту осуществления настоящего раскрытия сущности. Ссылаясь на фиг. 27, ссылка с номером 2700 указывает SI-окно, которое отслеживает UE, и 2710 указывает начальную BWP.

[615] В нелицензированной полосе частот, gNB может передавать SI-сообщение только в том случае, если канал является свободным (на основе принципа "слушай перед тем, как сказать" (LBT)). Это может приводить к задержке при передаче SI-сообщения и в силу этого может задерживать получение SI-сообщения посредством UE. Чтобы уменьшать задержку, требуются дополнительные возможности передачи/приема SI-сообщений.

[616] Вариант 2-4-1 осуществления

[617] GNB передает в служебных сигналах список из N базовых наборов для приема SI-сообщений. GNB может передавать в служебных сигналах это в SIB1 или MIB либо в RRC-сообщении.

[618] GNB также передает в служебных сигналах SI-периодичность, длину SI-окна, конфигурацию пространства поиска. Конфигурация пространства поиска может быть общей для всех базовых наборов. Это означает то, что только одна конфигурация пространства поиска передается в служебных сигналах посредством gNB для SI-сообщений (или OSI). Конфигурация пространства поиска может быть выделенной для каждого базового набора. Это означает то, что N конфигураций пространства поиска передаются в служебных сигналах посредством gNB для SI-сообщений (или OSI).

[619] GNB может выполнять LBT для нескольких подполос частот (соответствующих различным базовым наборам). GNB широковещательно передает SI-сообщение в базовом наборе, в котором канал является доступным. UE отслеживает на предмет SI-сообщений в одном или более базовых наборов в зависимости от характеристик UE.

[620] Фиг. 28 иллюстрирует пример SI-окон для SI-сообщения с учетом нескольких базовых наборов согласно варианту осуществления настоящего раскрытия сущности. Ссылаясь на фиг. 28, SI-окна, соответствующие нескольким базовым наборам 2800, могут FDM-мультиплексироваться. Фиг. 29 иллюстрирует пример SI-окон, в которых gNB передает SI-сообщение. Ссылаясь на фиг. 29, в SI-период, в период SI-окна, gNB должен передавать SI-сообщение в базовом наборе, в котором канал является свободным, в качестве ссылки с номером 2900. В различные SI-периоды, канал может быть свободным в различных базовых наборах, и gNB передает SI-сообщение соответствующим образом.

[621] [622] Вариант 3 осуществления

[623] В системе беспроводной связи пятого поколения (также упоминаемого как "NR" или "новый стандарт радиосвязи"), поисковые вызовы передаются, чтобы осуществлять поисковые вызовы UE, которые присоединяются к сети беспроводной связи, но находятся в бездействующем/неактивном режиме. В бездействующем/неактивном режиме, UE пробуждается с регулярными интервалами (т.е. каждый DRX-цикл поисковых вызовов) в течение коротких периодов для того, чтобы принимать поисковые вызовы, принимать уведомление относительно SI-обновления и принимать экстренные уведомления. Сообщение поисковых вызовов передается с использованием физического совместно используемого канала нисходящей линии связи (PDSCH). Физический общий канал управления нисходящей линии связи (PDCCH) адресуется в P-RNTI, если предусмотрено сообщение поисковых вызовов в PDSCH. P-RNTI является общим для всех UE. Идентификационные данные UE (т.е. S-TMSI для бездействующего UE или I-RNTI для неактивного UE) включаются в сообщение поисковых вызовов, чтобы указывать поисковые вызовы для конкретного UE. Сообщение поисковых вызовов может включать в себя несколько идентификационных данных UE, чтобы осуществлять поисковые вызовы нескольких UE. Сообщение поисковых вызовов широковещательно передается (т.е. PDCCH маскируется с P-RNTI) по каналу передачи данных (т.е. PDSCH). Уведомления относительно SI-обновления и экстренные уведомления включаются в DCI, и PDCCH, переносящий эту DCI, адресуется в P-RNTI. В бездействующем/неактивном режиме, UE отслеживает один период поисковых вызовов (PO) каждый DRX-цикл. В RRC-соединенном состоянии, UE отслеживает один или более PO, чтобы принимать уведомление относительно SI-обновления и принимать экстренные уведомления. UE может отслеживать любой PO в DRX-цикле поисковых вызовов и отслеживает, по меньшей мере, один PO в период SI-модификации.

[624] PO представляет собой набор из S периодов PDCCH-отслеживания для поисковых вызовов, где S является числом передаваемых SSB (т.е. сигнал синхронизации и PBCH-блок (SSB) состоят из сигналов первичной и вторичной синхронизации (PSS, SSS) и PBCH) в соте. UE сначала определяет кадр поисковых вызовов (PF) и затем определяет PO относительно определенного PF. Одно PF представляет собой радиокадр (10 мс). PF для UE представляет собой радиокадр с номером системного кадра SFN, который удовлетворяет уравнению (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N); где PF_offset, T и N передаются в служебных сигналах посредством gNB в системной информации.

[625] UE отслеживает (i_s+1)-ый PO, где i_s=floor(UE_ID/N) mod Ns; где N и Ns передаются в служебных сигналах посредством gNB в системной информации. Периоды PDCCH-отслеживания для поисковых вызовов определяются на основе конфигурации пространства поиска поисковых вызовов (paging-SearchSpace), передаваемой в служебных сигналах посредством gNB. Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами, последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. GNB может передавать в служебных сигналах параметр firstPDCCH-MonitoringOccasionOfPO для каждого PO, соответствующего PF. Когда firstPDCCH-MonitoringOccasionOfPO передается в служебных сигналах, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с номера периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO). В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB.

[626] В NR, следующие параметры в paging-SearchSpace конфигурируют периоды PDCCH-отслеживания для поисковых вызовов: периодичность (p); смещение (o); длительность (d): число последовательных временных квантов, имеющих периоды PDCCH-отслеживания каждый период, заданный посредством периодичности; monitoringSymbolsWithinSlot (1 битовая карта размера 14, один бит, соответствующий OFDM-символу); длительность базового набора (c): число последовательных OFDM-символов в период PDCCH-отслеживания.

[627] Фиг. 30 иллюстрирует пример периодов PDCCH-отслеживания для поисковых вызовов, сконфигурированных посредством paging-SearchSpace. Ссылаясь на фиг. 30, ссылка с номером 3000 указывает временной квант, имеющий период PDCCH-отслеживания для поисковых вызовов, периодичность (p) 3010 составляет 5 временных квантов; смещение (o) 3020 составляет 5 временных квантов; длительность (d) 3030 составляет 2 временных кванта; monitoringSymbolsWithinSlot составляет 00100000100000, и длительность базового набора составляет 4 OFDM-символа.

[628] В TDD-соте, конкретная для соты TDD-конфигурация (указывающая временные DL-кванты/символы, временные UL-кванты/символы) передается в служебных сигналах посредством параметра tdd-UL-DL-ConfigurationCommon в SystemInformationBlock1; tdd-UL-DL-ConfigurationCommon включает в себя длительность/период TDD- или DL-UL-шаблона, dslots, dsymbols, uslots, usymbols. dslots указывает число последовательных полных временных DL-квантов в начале каждого DL-UL-шаблона. Первые dslots временных квантов в длительности TDD-шаблона представляют собой временные DL-кванты. Все OFDM-символы во временных DL-квантах представляют собой DL-символы. uslots указывает число последовательных полных временных UL-квантов в конце каждого DL-UL-шаблона. Последние uslots временных квантов в шаблоне представляют собой временные UL-кванты. Все OFDM-символы во временных UL-квантах представляют собой UL-символы. dsymbols указывает число последовательных DL-символов в начале временного кванта после последнего полного временного DL-кванта (извлеченного из dslots). Значение 0 указывает то, что отсутствует частичный временной квант нисходящей линии связи. Первые dsymbols OFDM-символов в (dslots+1)-ом временном кванте представляют собой DL-символы. usymbols указывает число последовательных UL-символов в конце временного кванта, предшествующего первому полному временному UL-кванту (извлеченному из uslots). Значение 0 указывает то, что отсутствует частичный временной квант восходящей линии связи. Последние usymbols OFDM-символов в (uslots+1)-ом временном кванте от конца длительности TDD-шаблона представляют собой UL-символы. Оставшиеся символы в длительности TDD-шаблона представляют собой гибкие символы. Этот шаблон повторяется начиная с SFN 0. Гибкие символы могут быть сконфигурированы как DL- или UL-символы посредством tdd-UL-DL-ConfigurationDedicated; tdd-UL-DL-ConfigurationDedicated передается в служебных сигналах в UE в выделенной передаче служебных RRC-сигналов.

[629] Фиг. 31 иллюстрирует пример TDD-конфигурации посредством tdd-UL-DL-ConfigurationCommon. Ссылаясь на фиг. 31, длительность TDD-шаблона 3100 составляет 10 временных квантов, dslots 3110 составляет 2 временных кванта, dsymbols 3130 составляет 4 OFDM-символа, uslots 3120 составляет 3 временных кванта, usymbols 3140 составляет 6 OFDM-символов.

[630] В дополнение к tdd-UL-DL-ConfigurationDedicated и tdd-UL-DL-ConfigurationCommon, групповой общий PDCCH также может указывать TDD-конфигурацию для UE для одного или более временных квантов. В TDD-соте, UE может принимать информацию относительно UL-символов с использованием одного или более из tdd-UL-DL-ConfigurationDedicated, tdd-UL-DL-ConfigurationCommon и группового общего PDCCH.

[631] В TDD-соте, один или более периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством paging-SearchSpace, могут перекрываться с UL-символами. В текущем проектном решении, периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством paging-SearchSpace, которые не перекрываются с UL-символами, считаются достоверными для поисковых вызовов. С начала PF, эти достоверные периоды PDCCH-отслеживания для поисковых вызовов последовательно нумеруются начиная с нуля.

[632] Бездействующее/неактивное UE определяет UL-символы на основе tdd-UL-DL-ConfigurationCommon, передаваемого в служебных сигналах в SystemInformationBlock1. RRC-соединенное UE определяет UL-символы на основе tdd-UL-DL-ConfigurationCommon, tdd-UL-DL-ConfigurationDedicated и TDD-конфигурации, принимаемой в групповом общем PDCCH. Как результат, возникает рассогласование между PO, определенным посредством бездействующих/неактивных UE и посредством соединенных UE.

[633] Фиг. 32a иллюстрирует пример периодов PDCCH-отслеживания для поисковых вызовов и TDD-конфигураций. Ссылаясь на фиг. 32a, PagingSeachSpace сконфигурирован каждый временной квант, и 4 символа с первого символа и седьмого символа представляют собой периоды PDCCH-отслеживания во временном кванте. TDD-конфигурация на основе tdd-UL-DL-ConfigurationCommon проиллюстрирована, и третий, четвертый, пятый, шестой и седьмой временной квант радиокадра указываются в качестве гибких временных квантов. Третий и четвертый временные кванты указываются в качестве временных UL-квантов посредством tdd-DL-UL-ConfigurationDedicated.

[634] Фиг. 32b иллюстрирует пример PO согласно TDD-конфигурациям на фиг. 32a. Ссылаясь на 32b, для S=8, первый PO, определенный посредством бездействующего/неактивного UE, состоит из периодов PDCCH-отслеживания во временном кванте 0, 1, 2 и 3. Эти UE не считают периоды PDCCH-отслеживания во временных квантах 8-10 достоверными, поскольку они представляют собой временные UL-кванты. Первый PO, определенный посредством соединенного UE, состоит из периодов PDCCH-отслеживания во временном кванте 0, 1, 4 и 5. Эти UE не считают периоды PDCCH-отслеживания во временных квантах 8-10 и временных квантах 3 и 4 достоверными, поскольку они представляют собой временные UL-кванты.

[635] Вариант 3-1 осуществления: достоверные периоды PDCCH-отслеживания для поисковых вызовов

[636] Способ 1

[637] Фиг. 33 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно варианту осуществления способа 1.

[638] UE принимает TDD-конфигурацию с использованием, по меньшей мере, одного из tdd-UL-DL-ConfigurationCommon, tdd-UL-DL-ConfigurationDedicated и группового общего (GC) PDCCH на этапе 3300.

[639] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon, на этапе 3310.

[640] На этапе 3320, UE затем определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством pagingSearchSpace, которые остаются после применения вышеуказанного исключения, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов.

[641] На этапе 3330, с начала PF, достоверные периоды PDCCH-отслеживания для поисковых вызовов последовательно нумеруются начиная с нуля и преобразуются в Ns PO, соответствующих PF.

[642] Если firstPDCCH-MonitoringOccasionOfPO сконфигурирован, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с номера периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[643] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB.

[644] Операция UE для того, чтобы определять PO, заключается в следующем:

[645] UE принимает tdd-UL-DL-ConfigurationCommon из gNB; tdd-UL-DL-ConfigurationCommon принимается в системной информации (например, SystemInformationBlock1).

[646] UE принимает конфигурацию канала поисковых вызовов (т.е. длительность DRX-цикла по умолчанию, N, Ns, PF_offset) и конфигурацию пространства поиска поисковых вызовов из gNB, при этом идентификатор пространства поиска поисковых вызовов не задается равным нулю. Конфигурация канала поисковых вызовов принимается в системной информации (например, SystemInformationBlock1) посредством UE. Конфигурация пространства поиска поисковых вызовов принимается в системной информации (например, SystemInformationBlock1) посредством бездействующего/неактивного UE. Конфигурация пространства поиска поисковых вызовов принимается в выделенной передаче служебных RRC-сигналов посредством RRC-соединенного UE. В выделенной передаче служебных RRC-сигналов, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством gNB в BWP-конфигурации каждой BWP, в которой могут приниматься поисковые вызовы.

[647] UE также получает параметр ssb-PositionsInBurst из системной информации, т.е. из SystemInformationBlock1. Он также может приниматься в выделенной передаче служебных RRC-сигналов в RRC-соединенном состоянии.

[648] UE определяет PF. PF для UE представляет собой радиокадр с номером системного кадра SFN, который удовлетворяет уравнению (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N).

[649] UE определяет индекс (i_s), где i_s=floor(UE_ID/N) mod Ns.

[650] Идентификатор пространства поиска поисковых вызовов не задается равным нулю, так что периоды PDCCH-отслеживания для поисковых вызовов определяются согласно конфигурации пространства поиска, указываемой посредством paging-SearchSpace.

[651] Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами, последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. UL-символы определяются согласно tdd-UL-DL-ConfigurationCommon.

[652] Если firstPDCCH-MonitoringOccasionOfPO принимается из gNB, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[653] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB; firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается в системной информации (например, SystemInformationBlock1) или выделенной передаче служебных RRC-сигналов.

[654] Способ 2

[655] Фиг. 34 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно варианту осуществления способа 2.

[656] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon, на этапе 3400.

[657] Из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с гибкими символами, определенными согласно tdd-UL-DL-ConfigurationCommon, на этапе 3410.

[658] На этапе 3420, UE затем определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством pagingSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов.

[659] На этапе 3430, с начала PF, достоверные периоды PDCCH-отслеживания для поисковых вызовов последовательно нумеруются начиная с нуля и преобразуются в Ns PO, соответствующих PF.

[660] Если firstPDCCH-MonitoringOccasionOfPO сконфигурирован, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с номера периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[661] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB.

[662] Операция UE для того, чтобы определять PO, заключается в следующем:

[663] Во-первых, UE принимает tdd-UL-DL-ConfigurationCommon из gNB; tdd-UL-DL-ConfigurationCommon принимается в системной информации (например, SystemInformationBlock1).

[664] UE затем принимает конфигурацию канала поисковых вызовов (т.е. длительность DRX-цикла по умолчанию, N, Ns, PF_offset) и конфигурацию пространства поиска поисковых вызовов из gNB, при этом идентификатор пространства поиска поисковых вызовов не задается равным нулю. Конфигурация канала поисковых вызовов принимается в системной информации (например, SystemInformationBlock1) посредством UE. Конфигурация пространства поиска поисковых вызовов принимается в системной информации (например, SystemInformationBlock1) посредством бездействующего/неактивного UE. Конфигурация пространства поиска поисковых вызовов принимается в выделенной передаче служебных RRC-сигналов посредством RRC-соединенного UE. В выделенной передаче служебных RRC-сигналов, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством gNB в BWP-конфигурации каждой BWP, в которой могут приниматься поисковые вызовы.

[665] UE определяет PF. PF для UE представляет собой радиокадр с номером системного кадра SFN, который удовлетворяет уравнению (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N).

[666] UE определяет индекс (i_s), где i_s=floor(UE_ID/N) mod Ns.

[667] Идентификатор пространства поиска поисковых вызовов не задается равным нулю, так что периоды PDCCH-отслеживания для поисковых вызовов определяются согласно конфигурации пространства поиска, указываемой посредством paging-SearchSpace.

[668] Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами или гибкими символами, последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. UL-символы и гибкие символы определяются согласно tdd-UL-DL-ConfigurationCommon.

[669] Если firstPDCCH-MonitoringOccasionOfPO принимается из gNB, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[670] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB; firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается в системной информации (например, SystemInformationBlock1) посредством бездействующего/неактивного UE; firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается в выделенной передаче служебных RRC-сигналов посредством RRC-соединенного UE для отслеживания поисковых вызовов в неначальной BWP. Для отслеживания поисковых вызовов в начальной BWP, firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается посредством RRC-соединенного UE в системной информации (например, SystemInformationBlock1).

[671] Фиг. 35a иллюстрирует пример периодов PDCCH-отслеживания для поисковых вызовов и TDD-конфигурации на основе tdd-UL-DLConfigurationCommon. Ссылаясь на фиг. 35a, ссылка с номером 3500 является иллюстрацией периодов PDCCH-отслеживания для поисковых вызовов, сконфигурированных посредством paging-SearchSpace. В 3500, периодичность (p) составляет 10 временных квантов; смещение (o) составляет 0 временных квантов; длительность (d) составляет 10 временных квантов; monitoringSymbolsWithinSlot составляет 10000010000000, и длительность базового набора составляет 4 OFDM-символа.

[672] Ссылка с номером 3510 является иллюстрацией TDD-конфигурации посредством tdd-UL-DL-ConfigurationCommon. В 3510, длительность TDD-шаблона составляет 10 временных квантов, dslots составляет 4 временных кванта, dsymbols составляет 0 OFDM-символов, uslots составляет 3 временных кванта, usymbols составляет 0 OFDM-символов. Первый, второй, третий и четвертый временные кванты представляют собой временные DL-кванты, пятый, шестой и седьмой временные кванты представляют собой гибкие временные кванты, и восьмой, девятый и десятый временные кванты представляют собой временные UL-кванты.

[673] Фиг. 35b иллюстрирует пример достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно способу 1. Ссылаясь на фиг. 35b, ссылка с номером 3520 иллюстрирует то, что периоды PDCCH-отслеживания для поисковых вызовов (сконфигурированные посредством paging-SearchSpace), которые перекрываются с UL-символами или гибкими символами, сконфигурированными посредством tdd-UL-DL-ConfigurationCommon, исключаются (т.е. не считаются достоверными для поисковых вызовов). Оставшиеся периоды PDCCH-отслеживания для поисковых вызовов с начала PF последовательно нумеруются и преобразуются в PO. Например, если Ns равен 2, число передаваемых SSB (S) равно 8, и firstPDCCH-MonitoringOccasionOfPO не сконфигурирован, PO1 задается из периода PDCCH-отслеживания, пронумерованного от 0 до 7. PO2 задается из периода PDCCH-отслеживания, пронумерованного от 8 до 15.

[674] Способ 3

[675] Фиг. 36 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно варианту осуществления способа 3.

[676] Ссылаясь на фиг. 36, на этапе 3600, UE определяет то, представляет или нет DL BWP, в которой UE отслеживает периоды поисковых вызовов, собой начальную BWP. Если DL BWP, в которой UE отслеживает периоды поисковых вызовов (для поисковых вызовов и/или уведомлений относительно SI-обновления и/или экстренных уведомлений), представляет собой начальную DL BWP,

[677] - UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, на этапе 3610. Затем UE исключает те периоды PDCCH-отслеживания, которые перекрываются с гибкими символами, определенными согласно tdd-UL-DL-ConfigurationCommon, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, на этапе 3620. На этапе 3630, UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством pagingSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов.

[678] Если DL BWP, в которой UE отслеживает период поисковых вызовов (для поисковых вызовов и/или уведомлений относительно SI-обновления и/или экстренных уведомлений), не представляет собой начальную DL BWP, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon и tdd-UL-DL-ConfigurationDedicated, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, на этапе 3650.

[679] UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством pagingSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов, на этапе 3660.

[680] С начала PF, достоверные периоды PDCCH-отслеживания для поисковых вызовов последовательно нумеруются начиная с нуля и преобразуются в Ns PO, соответствующих PF, на этапе 3640.

[681] Если firstPDCCH-MonitoringOccasionOfPO сконфигурирован, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с номера периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO). В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB.

[682] UE в RRC-бездействующем/неактивном состоянии отслеживает периоды поисковых вызовов в начальной DL BWP. UE в RRC-соединенном состоянии отслеживает период поисковых вызовов в активной DL BWP, если пространство поиска поисковых вызовов сконфигурировано в активной DL BWP. Активная DL BWP может представлять собой или может не представлять собой начальную DL BWP. Если пространство поиска поисковых вызовов не сконфигурировано в активной DL BWP, UE в RRC-соединенном состоянии не отслеживает период поисковых вызовов.

[683] Операция UE для того, чтобы определять PO, заключается в следующем:

[684] UE принимает tdd-UL-DL-ConfigurationCommon из gNB; tdd-UL-DL-ConfigurationCommon принимается в системной информации (например, SystemInformationBlock1).

[685] UE принимает конфигурацию канала поисковых вызовов (т.е. длительность DRX-цикла по умолчанию, N, Ns, PF_offset) и конфигурацию пространства поиска поисковых вызовов из gNB, при этом идентификатор пространства поиска поисковых вызовов не задается равным нулю. Конфигурация канала поисковых вызовов принимается в системной информации (например, SystemInformationBlock1) посредством UE. Конфигурация пространства поиска поисковых вызовов принимается в системной информации (например, SystemInformationBlock1) посредством бездействующего/неактивного UE. Конфигурация пространства поиска поисковых вызовов принимается в выделенной передаче служебных RRC-сигналов посредством RRC-соединенного UE. В выделенной передаче служебных RRC-сигналов, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством gNB в BWP-конфигурации каждой BWP, в которой могут приниматься поисковые вызовы.

[686] UE определяет PF. PF для UE представляет собой радиокадр с номером системного кадра SFN, который удовлетворяет уравнению (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N).

[687] Затем UE определяет индекс (i_s), где i_s=floor(UE_ID/N) mod Ns.

[688] Идентификатор пространства поиска поисковых вызовов не задается равным нулю, так что периоды PDCCH-отслеживания для поисковых вызовов определяются согласно конфигурации пространства поиска, указываемой посредством paging-SearchSpace.

[689] Если DL BWP, в которой UE отслеживает периоды поисковых вызовов (для поисковых вызовов и/или уведомлений относительно SI-обновления и/или экстренных уведомлений), представляет собой начальную DL BWP: Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами или гибкими символами, последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. UL-символы и гибкие символы определяются согласно tdd-UL-DL-ConfigurationCommon.

[690] Если DL BWP, в которой UE отслеживает период поисковых вызовов (для поисковых вызовов и/или уведомлений относительно SI-обновления и/или экстренных уведомлений), не представляет собой начальную DL BWP: Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами, последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. UL-символы определяются согласно tdd-UL-DL-ConfigurationCommon и tdd-UL-DL-ConfigurationDedicated.

[691] Если firstPDCCH-MonitoringOccasionOfPO принимается из gNB, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[692] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB; firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается в системной информации (например, SystemInformationBlock1) посредством бездействующего/неактивного UE; firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается в выделенной передаче служебных RRC-сигналов посредством RRC-соединенного UE для отслеживания поисковых вызовов в неначальной BWP. Для отслеживания поисковых вызовов в начальной BWP, firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается посредством RRC-соединенного UE в системной информации (например, SystemInformationBlock1).

[693] Способ 4

[694] Фиг. 37 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для поисковых вызовов согласно варианту осуществления способа 4.

[695] Ссылаясь на фиг. 37, на этапе 3700, UE определяет то, представляет или нет DL BWP, в которой UE отслеживает периоды поисковых вызовов, собой начальную BWP. Если DL BWP, в которой UE отслеживает период поисковых вызовов (для поисковых вызовов и/или уведомлений относительно SI-обновления и/или экстренных уведомлений), представляет собой начальную DL BWP,

[696] - UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, на этапе 3710.

[697] Затем UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством pagingSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов, на этапе 3720.

[698] Если DL BWP, в которой UE отслеживает период поисковых вызовов (для поисковых вызовов и/или уведомлений относительно SI-обновления и/или экстренных уведомлений), не представляет собой начальную DL BWP, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon и tdd-UL-DL-ConfigurationDedicated, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace, на этапе 3740.

[699] UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством pagingSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов, на этапе 3750.

[700] На этапе 3730, с начала PF, достоверные периоды PDCCH-отслеживания для поисковых вызовов последовательно нумеруются начиная с нуля и преобразуются в Ns PO, соответствующих PF.

[701] Если firstPDCCH-MonitoringOccasionOfPO сконфигурирован, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с номера периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO). В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB.

[702] UE в RRC-бездействующем/неактивном состоянии отслеживает периоды поисковых вызовов в начальной DL BWP. UE в RRC-соединенном состоянии отслеживает периоды поисковых вызовов в активной DL BWP, если пространство поиска поисковых вызовов сконфигурировано в активной DL BWP. Активная DL BWP может представлять собой или может не представлять собой начальную DL BWP. Если пространство поиска поисковых вызовов не сконфигурировано в активной DL BWP, UE в RRC-соединенном состоянии не отслеживает период поисковых вызовов.

[703] Операция UE для того, чтобы определять PO, заключается в следующем:

[704] UE принимает tdd-UL-DL-ConfigurationCommon из gNB; tdd-UL-DL-ConfigurationCommon принимается в системной информации (например, SystemInformationBlock1).

[705] UE принимает конфигурацию канала поисковых вызовов (т.е. длительность DRX-цикла по умолчанию, N, Ns, PF_offset) и конфигурацию пространства поиска поисковых вызовов из gNB, при этом идентификатор пространства поиска поисковых вызовов не задается равным нулю. Конфигурация канала поисковых вызовов принимается в системной информации (например, SystemInformationBlock1) посредством UE. Конфигурация пространства поиска поисковых вызовов принимается в системной информации (например, SystemInformationBlock1) посредством бездействующего/неактивного UE. Конфигурация пространства поиска поисковых вызовов принимается в выделенной передаче служебных RRC-сигналов посредством RRC-соединенного UE. В выделенной передаче служебных RRC-сигналов, конфигурация пространства поиска поисковых вызовов передается в служебных сигналах посредством gNB в BWP-конфигурации каждой BWP, в которой могут приниматься поисковые вызовы.

[706] UE определяет PF. PF для UE представляет собой радиокадр с номером системного кадра SFN, который удовлетворяет уравнению (SFN+PF_Offset) mod T=(T div N)*(UE_ID mod N).

[707] Затем UE определяет индекс (i_s), где i_s=floor(UE_ID/N) mod Ns.

[708] Идентификатор пространства поиска поисковых вызовов не задается равным нулю, так что периоды PDCCH-отслеживания для поисковых вызовов определяются согласно конфигурации пространства поиска, указываемой посредством paging-SearchSpace.

[709] Если DL BWP, в которой UE отслеживает периоды поисковых вызовов (для поисковых вызовов и/или уведомлений относительно SI-обновления и/или экстренных уведомлений), представляет собой начальную DL BWP: Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами, последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. UL-символы определяются согласно tdd-UL-DL-ConfigurationCommon.

[710] Если DL BWP, в которой UE отслеживает период поисковых вызовов (для поисковых вызовов и/или уведомлений относительно SI-обновления и/или экстренных уведомлений), не представляет собой начальную DL BWP: Периоды PDCCH-отслеживания для поисковых вызовов, которые не перекрываются с UL-символами, последовательно нумеруются от нуля начиная с первого периода PDCCH-отслеживания для поисковых вызовов в PF. UL-символы определяются согласно tdd-UL-DL-ConfigurationCommon и tdd-UL-DL-ConfigurationDedicated.

[711] Если firstPDCCH-MonitoringOccasionOfPO принимается из gNB, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO).

[712] В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB; firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается в системной информации (например, SystemInformationBlock1) посредством бездействующего/неактивного UE; firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается в выделенной передаче служебных RRC-сигналов посредством RRC-соединенного UE для отслеживания поисковых вызовов в неначальной BWP. Для отслеживания поисковых вызовов в начальной BWP, firstPDCCH-MonitoringOccasionOfPO (в случае конфигурирования посредством gNB) принимается посредством RRC-соединенного UE в системной информации (например, SystemInformationBlock1).

[713] Способ 5

[714] В способе 5 настоящего раскрытия сущности, достоверные периоды PDCCH-отслеживания для поисковых вызовов определяются следующим образом:

[715] UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace. UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством pagingSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для поисковых вызовов. С начала PF, достоверные периоды PDCCH-отслеживания для поисковых вызовов последовательно нумеруются начиная с нуля и преобразуются в Ns PO, соответствующих PF.

[716] Если firstPDCCH-MonitoringOccasionOfPO сконфигурирован, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с номера периода PDCCH-отслеживания, указываемого посредством firstPDCCH-MonitoringOccasionOfPO (т.е. (i_s+1)-ого значения параметра firstPDCCH-MonitoringOccasionOfPO). В противном случае, (i_s+1)-ый PO представляет собой набор из S последовательных периодов PDCCH-отслеживания для поисковых вызовов начиная с (i_s*S)-ого периода PDCCH-отслеживания для поисковых вызовов. S является числом фактических передаваемых SSB, определенным согласно параметру ssb-PositionsInBurst, передаваемому в служебных сигналах в SystemInformationBlock1, принимаемом из gNB.

[717] В этом способе, также предлагается способ, как показано на фиг. 38. Фиг. 38 иллюстрирует способ конфигурирования TDD-конфигурации посредством gNB согласно варианту осуществления способа 4. Ссылаясь на фиг. 38, gNB определяет то, перекрывается или нет гибкий символ, определенный согласно tdd-UL-DL-ConfigurationCommon, с каким-либо периодом PDCCH-отслеживания, передаваемым в служебных сигналах посредством pagingSearchSpace, на этапе 3800. Если гибкий символ, определенный согласно tdd-UL-DL-ConfigurationCommon, перекрывается с каким-либо периодом PDCCH-отслеживания, передаваемым в служебных сигналах посредством pagingSearchSpace, то gNB не конфигурирует этот гибкий символ в качестве UL-символа через выделенную передачу служебных сигналов (например, через tdd-UL-DL-ConfigurationDedicated или SFI) в UE на этапе 3810. Этот гибкий символ может быть сконфигурирован как DL-символ через выделенную передачу служебных сигналов (например, через tdd-UL-DL-ConfigurationDedicated или SFI) в UE. Если гибкий символ, определенный согласно tdd-UL-DL-ConfigurationCommon, не перекрывается ни с одним периодом PDCCH-отслеживания, передаваемым в служебных сигналах посредством pagingSearchSpace, этот гибкий символ может быть сконфигурирован как выделенная передача в служебных сигналах DL-символов или UL-символов (например, через tdd-UL-DL-ConfigurationDedicated или SFI) в UE на этапе 3820.

[718] Вариант 3-2 осуществления: достоверные периоды PDCCH-отслеживания для SI-сообщения

[719] Для приема SI-сообщений, периоды PDCCH-отслеживания передаются в служебных сигналах посредством osi-SearchSpace. В NR, следующие параметры в osi-SearchSpace конфигурируют периоды PDCCH-отслеживания для приема SI-сообщений: периодичность (p); смещение (o); длительность (d): число последовательных временных квантов, имеющих периоды PDCCH-отслеживания каждый период, заданный посредством периодичности; monitoringSymbolsWithinSlot (1 битовая карта размера 14, один бит, соответствующий OFDM-символу); длительность базового набора (c): число последовательных OFDM-символов в период PDCCH-отслеживания.

[720] В TDD-соте, один или более периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством osi-SearchSpace, могут перекрываться с UL-символами. В текущем проектном решении, периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством osi-SearchSpace, которые не перекрываются с UL-символами, считаются достоверными для приема SI-сообщений. SI-сообщение принимается в SI-окне. В SI-окне, периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством osi-SearchSpace, которые не перекрываются с UL-символами, нумеруются начиная с единицы. Бездействующее/неактивное UE определяет UL-символы на основе tdd-UL-DL-ConfigurationCommon, передаваемого в служебных сигналах в SystemInformationBlock1. RRC-соединенное UE определяет UL-символы на основе tdd-UL-DL-ConfigurationCommon, tdd-UL-DL-ConfigurationDedicated и динамического индикатора формата временного кванта. Как результат, возникает рассогласование между периодами PDCCH-отслеживания, определенными посредством бездействующих/неактивных UE и посредством соединенных UE для приема SI-сообщений в SI-окне.

[721] Способ 1

[722] Фиг. 39 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для SI-сообщения согласно варианту осуществления способа 1.

[723] Ссылаясь на фиг. 39, в SI-окне, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством osiSearchSpace, на этапе 3900.

[724] На этапе 3910, в SI-окне, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с гибкими символами, определенными согласно tdd-UL-DL-ConfigurationCommon, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством osiSearchSpace.

[725] Затем UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством osiSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для приема SI-сообщений в SI-окне, на этапе 3920.

[726] На этапе 3930, в SI-окне, достоверные периоды PDCCH-отслеживания для приема SI-сообщений последовательно нумеруются начиная с единицы и преобразуются в SSB. UE отслеживает один или более из этих достоверных периодов PDCCH-отслеживания для приема SI-сообщений в SI-окне.

[727] Способ 2

[728] Фиг. 40 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для SI-сообщения согласно варианту осуществления способа 2.

[729] Ссылаясь на фиг. 40, UE определяет то, представляет или нет DL BWP для приема SI-сообщения собой начальную BWP, на этапе 4000. Если DL BWP, в которой UE отслеживает SI-сообщение, представляет собой начальную DL BWP, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством osiSearchSpace в SI-окне, на этапе 4010. В SI-окне, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством osiSearchSpace, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с гибкими символами, определенными согласно tdd-UL-DL-ConfigurationCommon, на этапе 4020. Затем UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством osiSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для приема SI-сообщений в SI-окне, на этапе 4030.

[730] Если DL BWP, в которой UE отслеживает SI-сообщение, не представляет собой начальную DL BWP, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon и tdd-UL-DL-ConfigurationDedicated, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством osiSearchSpace в SI-окне, на этапе 4050. Затем UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством osiSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для приема SI-сообщений в SI-окне, на этапе 4060.

[731] На этапе 4040, в SI-окне, достоверные периоды PDCCH-отслеживания для приема SI-сообщений последовательно нумеруются начиная с единицы и преобразуются в SSB. UE отслеживает один или более из этих достоверных периодов PDCCH-отслеживания для приема SI-сообщений в SI-окне.

[732] UE в RRC-бездействующем/неактивном состоянии принимает SI-сообщение в начальной DL BWP. UE в RRC-соединенном состоянии принимает SI-сообщение в активной DL BWP, если пространство поиска OSI сконфигурировано в активной DL BWP. Активная DL BWP может представлять собой или может не представлять собой начальную DL BWP. Если пространство поиска OSI не сконфигурировано в активной DL BWP, UE в RRC-соединенном состоянии не принимает SI-сообщение.

[733] Способ 3

[734] Фиг. 41 иллюстрирует способ определения достоверных периодов PDCCH-отслеживания для SI-сообщения согласно варианту осуществления способа 3.

[735] Ссылаясь на фиг. 41, UE определяет то, представляет или нет DL BWP для приема SI-сообщения собой начальную BWP, на этапе 4100. Если DL BWP, в которой UE отслеживает SI-сообщение, представляет собой начальную DL BWP, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством osiSearchSpace в SI-окне, на этапе 4110. Затем UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством osiSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для приема SI-сообщений в SI-окне, на этапе 4120.

[736] Если DL BWP, в которой UE отслеживает SI-сообщение, не представляет собой начальную DL BWP, UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon и tdd-UL-DL-ConfigurationDedicated, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством osiSearchSpace в SI-окне, на этапе 4140. Затем UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством osiSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для приема SI-сообщений в SI-окне, на этапе 4150.

[737] На этапе 4130, в SI-окне, достоверные периоды PDCCH-отслеживания для приема SI-сообщений последовательно нумеруются начиная с единицы и преобразуются в SSB. UE отслеживает один или более из этих достоверных периодов PDCCH-отслеживания для приема SI-сообщений в SI-окне.

[738] UE в RRC-бездействующем/неактивном состоянии принимает SI-сообщение в начальной DL BWP. UE в RRC-соединенном состоянии принимает SI-сообщение в активной DL BWP, если пространство поиска OSI сконфигурировано в активной DL BWP. Активная DL BWP может представлять собой или может не представлять собой начальную DL BWP. Если пространство поиска OSI не сконфигурировано в активной DL BWP, UE в RRC-соединенном состоянии не принимает SI-сообщение.

[739] Способ 4

[740] В способе 4 настоящего раскрытия сущности, достоверные периоды PDCCH-отслеживания для SI-сообщения определяются следующим образом:

[741] UE исключает те периоды PDCCH-отслеживания, которые перекрываются с UL-символами, определенными согласно tdd-UL-DL-ConfigurationCommon, из числа периодов PDCCH-отслеживания, передаваемых в служебных сигналах посредством pagingSearchSpace в SI-окне.

[742] В SI-окне, UE определяет то, что периоды PDCCH-отслеживания, передаваемые в служебных сигналах посредством osiSearchSpace, которые остаются после применения вышеуказанных исключений, представляют собой достоверные периоды PDCCH-отслеживания для приема SI-сообщений.

[743] В SI-окне, достоверные периоды PDCCH-отслеживания для приема SI-сообщений последовательно нумеруются начиная с единицы и преобразуются в SSB. UE отслеживает один или более из этих достоверных периодов PDCCH-отслеживания для приема SI-сообщений в SI-окне.

[744] В этом способе, также предлагается способ, как показано на фиг. 42. Фиг. 42 иллюстрирует способ конфигурирования TDD-конфигурации посредством gNB согласно варианту осуществления способа 4.

[745] Ссылаясь на фиг. 42, gNB определяет то, перекрывается или нет гибкий символ, определенный согласно tdd-UL-DL-ConfigurationCommon, с каким-либо периодом PDCCH-отслеживания, передаваемым в служебных сигналах посредством osiSearchSpace, на этапе 4200. Если гибкий символ, определенный согласно tdd-UL-DL-ConfigurationCommon, перекрывается с каким-либо периодом PDCCH-отслеживания, передаваемым в служебных сигналах посредством osiSearchSpace, то gNB не конфигурирует этот гибкий символ в качестве UL-символа через выделенную передачу служебных сигналов (например, через tdd-UL-DL-ConfigurationDedicated или SFI) в UE на этапе 4210. Этот гибкий символ может быть сконфигурирован как DL-символ через выделенную передачу служебных сигналов (например, через tdd-UL-DL-ConfigurationDedicated или SFI) в UE.

[746] Если гибкий символ, определенный согласно tdd-UL-DL-ConfigurationCommon, не перекрывается ни с одним периодом PDCCH-отслеживания, передаваемым в служебных сигналах посредством osiSearchSpace, этот гибкий символ может быть сконфигурирован как выделенная передача в служебных сигналах DL-символов или UL-символов (например, через tdd-UL-DL-ConfigurationDedicated или SFI) в UE на этапе 4220.

[747] В альтернативном варианте осуществления, если гибкий символ, определенный согласно tdd-UL-DL-ConfigurationCommon, не перекрывается ни с одним периодом PDCCH-отслеживания, передаваемым в служебных сигналах посредством osiSearchSpace и pagingSearchSpace, этот гибкий символ может быть сконфигурирован как выделенная передача в служебных сигналах DL-символов или UL-символов (например, через tdd-UL-DL-ConfigurationDedicated или SFI) в UE.

[748] Фиг. 43 иллюстрирует конфигурацию UE согласно вариантам 2 и 3 осуществления.

[749] Ссылаясь на фиг. 43, UE включает в себя радиочастотный (RF) процессор 4310, процессор 4320 полосы модулирующих частот, запоминающее устройство 4330 и контроллер 4340. Контроллер 4340 может включать в себя процессор 4342 с поддержкой множественного соединения.

[750] RF-процессор 4310 передает или принимает сигнал через беспроводной канал, такой как преобразование полосы частот и усиление сигнала. Таким образом, RF-процессор 4310 преобразует с повышением частоты сигнал в полосе модулирующих частот, предоставленный из процессора 4320 полосы модулирующих частот, в сигнал в полосе RF-частот, чтобы передавать сигнал в полосе RF-частот через антенну, и преобразует с понижением частоты сигнал в полосе RF-частот, принимаемый через антенну, в сигнал в полосе модулирующих частот. RF-процессор 4310 может включать в себя фильтр передачи, фильтр приема, усилитель, микшер, осциллятор, цифро-аналоговый преобразователь (DAC) и аналого-цифровой преобразователь (ADC). Хотя фиг. 43 показывает только одну антенну, UE может включать в себя множество антенн. Помимо этого, RF-процессор 4310 может включать в себя множество RF-цепочек.

[751] RF-процессор 4310 может выполнять формирование диаграммы направленности посредством регулирования фазы и интенсивности каждого из сигналов, передаваемых и принимаемых через множество антенн или антенных элементов. RF-процессор может выполнять MIMO и может принимать множество уровней при выполнении MIMO, может выполнять развертку луча приема посредством надлежащего задания множества антенн или антенных элементов под управлением контроллера 4340 либо может регулировать ориентацию и ширину луча приема таким образом, что луч приема координируется с лучом передачи.

[752] Процессор 4320 полосы модулирующих частот преобразует сигнал в полосе модулирующих частот и поток битов согласно техническим требованиям физического уровня системы. Например, при передаче данных, процессор 4320 полосы модулирующих частот кодирует и модулирует передаваемый поток битов, за счет этого формируя комплексные символы. При приеме данных, процессор 4320 полосы модулирующих частот демодулирует и декодирует сигнал в полосе модулирующих частот, предоставленный из RF-процессора 4310, за счет этого восстанавливая принимаемый поток битов. Например, согласно OFDM, при передаче данных, процессор 4320 полосы модулирующих частот формирует комплексные символы посредством кодирования и модуляции передаваемого потока битов, преобразует комплексные символы в поднесущие и конструирует OFDM-символы через обратное быстрое преобразование Фурье (IFFT) и вставку циклического префикса (CP). При приеме данных, процессор 4320 полосы модулирующих частот разделяет сигнал в полосе модулирующих частот, предоставленный из RF-процессора 4310, на OFDM-символы, восстанавливает сигналы, преобразованные в поднесущие через быстрое преобразование Фурье (FFT), и восстанавливает принимаемый поток битов через демодуляцию и декодирование.

[753] Как описано выше, процессор 4320 полосы модулирующих частот и RF-процессор 4310 передают и принимают сигналы и в силу этого могут упоминаться как передающее устройство, приемное устройство, приемо-передающее устройство или модуль связи. По меньшей мере, один из процессора 4320 полосы модулирующих частот и RF-процессора 4310 может включать в себя множество модулей связи, чтобы поддерживать множество различных технологий радиодоступа, таких как LTE- и NR-сети, и может включать в себя различные модули связи для обработки сигналов в различных полосах частот. Различные полосы частот могут включать в себя полосу сверхвысоких частот (SHF) (например, 2,2 ГГц и 2 ГГц) и полосу частот в диапазоне миллиметровых волн (например, 60 ГГц).

[754] Запоминающее устройство 4330 сохраняет данные, такие как программа по умолчанию, приложение и конфигурационная информация для работы UE и предоставляет сохраненные данные по запросу из контроллера 4340.

[755] Контроллер 4340 полностью управляет операциями UE. Например, контроллер 4340 передает и принимает сигналы через процессор 4320 полосы модулирующих частот и RF-процессор 4310 и записывает и считывает данные в запоминающем устройстве 4330. С этой целью, контроллер 4340 может включать в себя, по меньшей мере, один процессор, такой как процессор связи, чтобы выполнять управление для связи, и процессор приложений (AP), чтобы управлять верхним уровнем, таким как приложение.

[756] Фиг. 44 иллюстрирует конфигурацию базовой станции согласно вариантам 2 и 3 осуществления.

[757] Ссылаясь на фиг. 44, базовая станция включает в себя RF-процессор 4410, процессор 4420 полосы модулирующих частот, модуль 4430 связи, запоминающее устройство 4440 и контроллер 4450. Контроллер 4450 может включать в себя процессор 4452 с поддержкой множественного соединения.

[758] RF-процессор 4410 передает или принимает сигнал через беспроводной канал, такой как преобразование полосы частот и усиление сигнала. Таким образом, RF-процессор 4410 преобразует с повышением частоты сигнал в полосе модулирующих частот, предоставленный из процессора 4420 полосы модулирующих частот, в сигнал в полосе RF-частот, чтобы передавать сигнал в полосе RF-частот через антенну, и преобразует с понижением частоты сигнал в полосе RF-частот, принимаемый через антенну, в сигнал в полосе модулирующих частот. RF-процессор 4410 может включать в себя фильтр передачи, фильтр приема, усилитель, микшер, осциллятор, DAC и ADC. Хотя фиг. 44 показывает только одну антенну, базовая станция может включать в себя множество антенн. Помимо этого, RF-процессор 4410 может включать в себя множество RF-цепочек и может выполнять формирование диаграммы направленности посредством регулирования фазы и интенсивности каждого из сигналов, передаваемых и принимаемых через множество антенн или антенных элементов. RF-процессор может передавать один или более уровней, за счет этого выполняя MIMO в нисходящей линии связи.

[759] Процессор 4420 полосы модулирующих частот преобразует сигнал в полосе модулирующих частот и поток битов согласно техническим требованиям физического уровня первой технологии радиодоступа. Например, при передаче данных, процессор 4420 полосы модулирующих частот кодирует и модулирует передаваемый поток битов, за счет этого формируя комплексные символы. При приеме данных, процессор 4420 полосы модулирующих частот демодулирует и декодирует сигнал в полосе модулирующих частот, предоставленный из RF-процессора 4410, за счет этого восстанавливая принимаемый поток битов. Например, согласно OFDM, при передаче данных, процессор 4420 полосы модулирующих частот формирует комплексные символы посредством кодирования и модуляции передаваемого потока битов, преобразует комплексные символы в поднесущие и конструирует OFDM-символы через IFFT и CP-вставку. При приеме данных, процессор 4420 полосы модулирующих частот разделяет сигнал в полосе модулирующих частот, предоставленный из RF-процессора 4410, на OFDM-символы, восстанавливает сигналы, преобразованные в поднесущие через FFT, и восстанавливает принимаемый поток битов через демодуляцию и декодирование. Процессор 4420 полосы модулирующих частот и RF-процессор 4410 передают и принимают сигналы и в силу этого могут упоминаться как передающее устройство, приемное устройство, приемо-передающее устройство, модуль связи или модуль беспроводной связи.

[760] Модуль 4430 связи предоставляет интерфейс для выполнения связи с другими узлами в сети.

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

[762] Контроллер 4450 полностью управляет операциями базовой станции. Например, контроллер 4450 передает и принимает сигналы через процессор 4420 полосы модулирующих частот и RF-процессор 4410 или через модуль 4430 связи и записывает и считывает данные в запоминающем устройстве 4440. С этой целью, контроллер 4450 может включать в себя, по меньшей мере, один процессор

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

[764] Хотя раскрытие сущности показано и описано со ссылкой на его конкретные варианты осуществления, специалисты в данной области техники должны понимать, что различные изменения по форме и подробностям могут вноситься в них без отступления от объема раскрытия сущности. Следовательно, объем раскрытия сущности не должен задаваться как ограниченный вариантами осуществления, а должен задаваться посредством прилагаемой формулы изобретения и ее эквивалентов. Таким образом, специалистам в области техники, которой принадлежит раскрытие сущности, должно быть очевидным, что различные модификации могут достигаться на основе технической сущности раскрытия сущности. Дополнительно, при необходимости, вышеприведенные соответствующие варианты осуществления могут использоваться в комбинации. Например, способы, предложенные в раскрытии сущности, могут частично комбинироваться таким образом, чтобы управлять базовой станцией и терминалом. Дополнительно, хотя вышеуказанные варианты осуществления описываются на основе 5G- и NR-систем, может быть возможным реализовывать другие варианты осуществления на основе технической идеи вариантов осуществления в других системах, таких как LTE-, LTE-A- и LTE-A Pro-система. Следует отметить, что улучшение, предложенное в этом настоящем раскрытии сущности, является применимым для лицензированных и нелицензированных несущих.

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

получают из базовой станции первую информацию, ассоциированную с конфигурацией дуплекса с временным разделением каналов (TDD), через системную информацию;

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

получают из базовой станции третью информацию, ассоциированную с позицией для по меньшей мере одного блока сигналов синхронизации (SSB), через системную информацию;

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

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

отслеживают PDCCH, адресованный временному идентификатору радиосети для поисковых вызовов (P-RNTI), в упомянутом периоде отслеживания PDCCH для поисковых вызовов,

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

2. Способ по п. 1,

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

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

Число периодов отслеживания PDCCH в периоде поисковых вызовов = S * X,

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

4. Способ по п. 1, в котором параметр представляет собой число периодов отслеживания PDCCH в расчете на SSB в периоде поисковых вызовов.

5. Способ по п. 3, в котором по меньшей мере один период отслеживания PDCCH, соответствующий K-му передаваемому SSB в периоде поисковых вызовов, включает в себя K-й период отслеживания PDCCH для каждых S периодов отслеживания PDCCH в упомянутом периоде поисковых вызовов.

6. Способ по п. 3, причем в случае, когда набор чисел периодов отслеживания PDCCH соответствует (i_s+1)-му периоду отслеживания, набор чисел периода отслеживания PDCCH начинается с (i_s * S * X)-го периода отслеживания PDCCH.

7. Способ по п. 1, причем набор чисел периода отслеживания PDCCH начинается с периода отслеживания PDCCH, указанного четвертой информацией,

причем четвертая информация получается от базовой станции.

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

идентифицируют первую информацию, ассоциированную с конфигурацией дуплекса с временным разделением каналов (TDD);

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

идентифицируют третью информацию, ассоциированную с позицией для по меньшей мере одного блока сигналов синхронизации (SSB), в системной информации;

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

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

передают PDCCH на основе временного идентификатора радиосети для поисковых вызовов (P-RNTI) в упомянутом периоде отслеживания PDCCH для поисковых вызовов,

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

9. Способ по п. 8,

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

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

Число периодов отслеживания PDCCH в период поисковых вызовов = S * X,

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

11. Способ по п. 8, в котором параметр представляет собой число периодов отслеживания PDCCH в расчете на SSB в период поисковых вызовов.

12. Способ по п. 10, в котором по меньшей мере один период отслеживания PDCCH, соответствующий K-му передаваемому SSB в периоде поисковых вызовов, включает в себя K-й период отслеживания PDCCH для каждых S периодов отслеживания PDCCH в периоде поисковых вызовов.

13. Способ по п. 10, причем в случае, когда набор чисел периодов отслеживания PDCCH соответствует (i_s+1)-му периоду отслеживания, набор чисел периодов отслеживания PDCCH начинается с (i_s * S * X)-го периода отслеживания PDCCH.

14. Способ по п. 8, причем набор чисел периодов отслеживания PDCCH начинается с периода отслеживания PDCCH, ассоциированного с четвертой информацией,

причем четвертая информация идентифицируется базовой станцией.

15. Терминал в системе связи, причем терминал содержит:

приемо-передающее устройство; и

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

получать, из базовой станции, первую информацию, ассоциированную с конфигурацией дуплекса с временным разделением каналов (TDD), через системную информацию,

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

получать из базовой станции третью информацию, ассоциированную с позицией для по меньшей мере одного блока сигналов синхронизации (SSB), через системную информацию,

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

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

выполнять отслеживание PDCCH, адресованного временному идентификатору радиосети для поисковых вызовов (P-RNTI), в упомянутом периоде отслеживания PDCCH для поисковых вызовов,

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

16. Терминал по п. 15,

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

17. Терминал по п. 15, в котором число периодов отслеживания PDCCH в периоде поисковых вызовов идентифицируется на основе следующего уравнения:

Число периодов отслеживания PDCCH в периоде поисковых вызовов = S * X,

где S является числом передаваемых SSB, определенных на основе третьей информации, ассоциированной с позицией для по меньшей мере одного SSB, и X является значением параметра, который должен использоваться для того, чтобы определять число периодов отслеживания PDCCH.

18. Терминал по п. 15, в котором параметр представляет собой число периодов отслеживания PDCCH в расчете на SSB в период поисковых вызовов.

19. Терминал по п. 17, в котором по меньшей мере один период отслеживания PDCCH, соответствующий K-му передаваемому SSB в периоде поисковых вызовов, включает в себя K-й период отслеживания PDCCH для каждых S периодов отслеживания PDCCH в периоде поисковых вызовов.

20. Терминал по п. 17, причем в случае, когда набор чисел периодов отслеживания PDCCH соответствует (i_s+1)-му периоду отслеживания, набор чисел периодов отслеживания PDCCH начинается с (i_s * S * X)-го периода отслеживания.

21. Терминал по п. 15, причем набор чисел периодов отслеживания PDCCH начинается с периода отслеживания PDCCH, идентифицированного четвертой информацией,

причем четвертая информация получается от базовой станции.

22. Базовая станция в системе связи, причем базовая станция содержит:

приемо-передающее устройство; и

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

идентифицировать первую информацию, ассоциированную с конфигурацией дуплекса с временным разделением каналов (TDD),

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

идентифицировать третью информацию, ассоциированную с позицией для по меньшей мере одного блока сигналов синхронизации (SSB), в системной информации,

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

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

передавать PDCCH на основе временного идентификатора радиосети для поисковых вызовов (P-RNTI) в упомянутом периоде отслеживания PDCCH для поисковых вызовов,

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

23. Базовая станция по п. 22, при этом число периодов отслеживания PDCCH равно числу передаваемых SSB на основе третьей информации, ассоциированной с позицией для упомянутого по меньшей мере одного SSB в случае, когда упомянутый параметр не идентифицирован.

24. Базовая станция по п. 22, в которой число периодов отслеживания PDCCH в периоде поисковых вызовов идентифицируется на основе следующего уравнения:

Число периодов отслеживания PDCCH в периоде поисковых вызовов = S * X,

где S является числом передаваемых SSB, определенных на основе третьей информации, ассоциированной с позицией для по меньшей мере одного SSB, и X является значением параметра, который должен использоваться для того, чтобы определять число периодов отслеживания PDCCH.

25. Базовая станция по п. 22, в которой параметр представляет собой число периодов отслеживания PDCCH в расчете на SSB в период поисковых вызовов.

26. Базовая станция по п. 24, в которой по меньшей мере один период отслеживания PDCCH, соответствующий K-му передаваемому SSB в периоде поисковых вызовов, включает в себя K-й период отслеживания PDCCH для каждых S периодов отслеживания PDCCH в упомянутом периоде поисковых вызовов.

27. Базовая станция по п. 24, причем в случае, когда набор чисел периодов отслеживания PDCCH соответствует (i_s+1)-му периоду отслеживания, набор чисел периодов отслеживания PDCCH начинается с (i_s * S * X)-го периода отслеживания.

28. Базовая станция по п. 22, причем набор чисел периодов отслеживания PDCCH начинается с периода отслеживания PDCCH, ассоциированного с четвертой информацией,

причем четвертая информация идентифицируется базовой станцией.



 

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

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

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

Изобретение относится к области беспроводной связи. Технический результат заключается в возможности получения посредством терминала конфигурации NR PDCP в сценарии LTE-NR-DC.

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

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

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

Группа изобретений относится к способу и устройству помощи при вождении. Устройство помощи при вождении содержит контроллер (3), выполненный с возможностью вычисления маршрута движения транспортного средства и выполнения управления помощью при вождении на основе маршрута движения.

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

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

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

Изобретение относится к пользовательскому оборудованию в системе радиосвязи. Технический результат заключается в обеспечении обработки запроса для межтерминальной прямой связи. Для этого пользовательское оборудование содержит: блок управления, передающий блок и приемный блок. Блок управления выполнен с возможностью определения конфигурации для передачи запроса планирования на основании того, предназначен ли запрос планирования для связи между аппаратом базовой станции и пользовательским оборудованием или запрос планирования предназначен для связи между указанным пользовательским оборудованием и другим пользовательским оборудованием. Передающий блок выполнен с возможностью передачи запроса планирования с использованием конфигурации для передачи определенного запроса планирования. Приемный блок выполнен с возможностью приема гранта планирования на основании запроса планирования. 5 з.п. ф-лы, 14 ил.
Наверх