ПЕРВЫЙ БЛОК, ВТОРОЙ БЛОК И СПОСОБЫ, ВЫПОЛНЯЕМЫЕ В СЕТИ БЕСПРОВОДНОЙ СВЯЗИ
FIRST BLOCK, SECOND BLOCK AND METHODS IMPLEMENTED IN A WIRELESS COMMUNICATION NETWORK

Область техники, к которой относится изобретение
Варианты осуществления, представленные в данном документе, относятся к первому блоку, второму блоку и способам, выполняемым в них. В некоторых аспектах они относятся к обработке соединения между первым блоком и многочисленными вторыми блоками в сети беспроводной связи.
Уровень техники
В типичной сети беспроводной связи беспроводные устройства, также известные как устройства беспроводной связи, мобильные станции, станции (STA) и/или пользовательское оборудование (UE), обмениваются данными через локальную сеть, такую как сеть Wi-Fi или сеть радиодоступа (RAN), с одной или несколькими базовыми сетями (CN). RAN охватывает географическую зону, которая разделена на зоны обслуживания или зоны сот, которые могут также упоминаться как луч или группа лучей, при этом каждая зона обслуживания или зона сот обслуживается узлом радиосети, таким как узел радиодоступа, например, точка доступа Wi-Fi или базовая радиостанция (RBS), которая в некоторых сетях также может обозначаться, например, как NodeB, eNodeB (eNB) или gNB в 5G. Зона обслуживания или зона соты – это географическая зона, где радиопокрытие обеспечивается узлом радиосети. Узел радиосети обменивается данными по радиоинтерфейсу, работающему на радиочастотах, с беспроводным устройством в пределах диапазона радиосети.
Спецификации для развитой пакетной системы (EPS), также называемой сетью четвертого поколения (4G), были выполнены в рамках проекта партнерства 3-го поколения (3GPP), и эта работа продолжается в следующих версиях 3GPP, например, для специфицирования сети пятого поколения (5G), которая также упоминается как новое радио (NR) 5G. EPS содержит развитую универсальную наземную сеть радиодоступа (E-UTRAN), также известную как сеть радиодоступа долгосрочного развития (LTE), и развитое пакетное ядро (EPC), также известное как базовая сеть эволюции системной архитектуры (SAE). E-UTRAN/LTE – это вариант сети радиодоступа 3GPP, в которой узлы радиосети напрямую подключены к базовой сети EPC, а не к RNC, используемым в сетях 3G. В общем, в E-UTRAN/LTE функции RNC 3G распределены между узлами радиосети, например, eNodeB в LTE, и базовой сетью. Таким образом, RAN EPS имеет по существу "плоскую" архитектуру, содержащую узлы радиосети, подключенные непосредственно к одной или нескольким базовым сетям, то есть они не подключены к RNC. Чтобы компенсировать это, спецификация E-UTRAN определяет прямой интерфейс между узлами радиосети, который обозначается как интерфейс X2.
Многоантенные технологии позволяют значительно повысить скорости передачи данных и надежность системы беспроводной связи. В частности, производительность повышается в том случае, когда передатчик и приемник одновременно оснащены несколькими антеннами, что приводит к образованию канала связи с множеством входов и множеством выходов (MIMO). Такие системы и/или связанные с ними технологии обычно упоминаются как MIMO.
Современная общая архитектура RAN 5G описана в 3GPP TS38.401 и показана на фиг.1. Архитектура нового поколения (NG) может быть дополнительно описана следующим образом:
- NG-RAN содержит набор gNB, подключенных к 5GC через NG.
- gNB поддерживает работу в режиме FDD, режиме TDD или сдвоенном режиме.
- gNB могут подключаться друг к другу через Xn.
- gNB может содержать gNB-блок управления (CU) и gNB-DU.
- gNB-CU и gNB-распределенный блок (DU) подключаются через логический интерфейс F1.
- Один gNB-DU может быть подключен только к одному gNB-CU.
NG, Xn и F1 являются логическими интерфейсами.
NG – это аббревиатура интерфейса между CN 5G и NG-RAN.
F1 представляет собой интерфейс между gNB-CU и gNB-DU (или проще между CU и DU)
Xn – интерфейс между gNB (то есть многочисленными gNB).
Xn-C – интерфейс плоскости управления Xn между gNB.
Xn-U – интерфейс плоскости пользователя Xn между gNB.
Для NG-RAN интерфейсы NG и Xn-C для gNB, содержащего gNB-CU и gNB-DU, заканчиваются в gNB-CU.
S1-U – интерфейс плоскости пользователя между EPC и eNB или EPC и SgNB (вторичный gNB означает EN-DC).
X2-C – интерфейс плоскости управления между eNB и gNB.
X2-U – интерфейс плоскости пользователя между eNB и gNB.
gNB-CU может быть разделен на один gNB-CU-CP и один или несколько gNB-CU-UP.
F1-U – интерфейс плоскости пользователя между gNB-CU-UP и gNB-DU.
E1 – интерфейс плоскости управления между CU-CP и CU-UP в одном gNB.
Для нового радио E-UTRAN – двойная связность (EN-DC) интерфейсы S1-U и X2-C для gNB, содержащего gNB-CU и gNB-DU, заканчиваются в gNB-CU. gNB-CU и подключенные gNB-DU видны только другим gNB и 5GC как gNB.
NG-RAN разделен на уровень радиосети (RNL) и уровень транспортной сети (TNL). Архитектура NG-RAN, то есть логические узлы NG-RAN и интерфейсы между ними, определяется как часть RNL. Для каждого интерфейса NG-RAN (NG, Xn, F1) указывается связанный с ним протокол TNL и его функциональные возможности. TNL предоставляет услуги для транспортировки в плоскости пользователя и транспортировки сигнализации. В конфигурации NG-Flex каждый gNB подключен ко всем AMF в области AMF. Область AMF определена в 3GPP TS 23.501.
На фиг.2 показана связность плоскости управления (C) (Control (C)-Plane) для EN-DC, и на фиг.3 показана связность плоскости пользователя (U) (User (U)-Plane) для EN-DC.
Для системы 5G специфицирована опция связности, которая предусматривает двойную связность между узлом, предоставляющим ресурсы E-UTRA (eNB LTE на фиг.2 и 3), и узлом, предоставляющим ресурсы NR (gNB на фиг.2 и 3). Эта опция связности называется "опцией 3" в соответствии с 3GPP TR 38.801 и предусматривает связность из узлов RAN в направлении базовой сети 4G посредством интерфейса S1. Она может также обозначаться как E-UTRAN-двойная связность NR (EN-DC). Интерфейс S1 в LTE используется между eNB и EPC. Интерфейс между eNB LTE и gNB является интерфейсом X2.
Ранние развертывания сетей NR и LTE будут характеризоваться тесной интеграцией. Одной из ключевых особенностей будут многочисленные технологии радиодоступа - двойная связность (MR-DC), обеспечивающие конечным пользователям повышенную скорость передачи данных. В MR-DC как LTE, так и NR одновременно предоставляют радиоресурсы для UE. В одной из возможных опций для MR-DC, которая упоминается как "опция 3" в обсуждениях 3GPP, eNB LTE действует как главный узел, который также упоминается как привязка CP, и GNB NR действует как вторичный узел, предоставляющий дополнительные ресурсы UP.
eNB LTE и gNB NR также могут быть подключены через так называемый интерфейс Xn. В этом случае базовая сеть, участвующая в обслуживании UE через eNB и/или gNB, называется базовой сетью 5G (5GC) или базовой сетью NG (NGC). В этой архитектуре также могут быть предусмотрены случаи двойной связности между eNB и gNB. Главный узел может быть eNB или gNB. На фиг.4a и 4b показан случай, где eNB является главным узлом в так называемой опции 7 согласно TR38.801.
Раскрытие сущности изобретения
Задача вариантов осуществления, представленных в данном документе, состоит в повышении производительности сети беспроводной связи.
Согласно аспекту вариантов осуществления, представленных в данном документе, задача решена способом, выполняемым первым блоком для обработки соединения между первым блоком и многочисленными вторыми блоками в сети беспроводной связи. Первый блок получает 601, из каждого из многочисленных вторых блоков, соответствующее указание того, какие одну или несколько версий протокола плоскости пользователя NR (NR-U) он поддерживает. Первый блок 602 принимает решение относительно того, какую версию NR-U можно использовать для соединения, на основе указаний, принятых из многочисленных вторых блоков.
Согласно другому аспекту вариантов осуществления, представленных в данном документе, задача решена способом, выполняемым вторым блоком для обработки взаимодействия между первым блоком и многочисленными вторыми блоками в сети беспроводной связи. Второй блок отправляет сообщение в первый блок. Указание указывает то, какие одну или несколько версий протокола плоскости пользователя NR (NR-U) поддерживает второй блок. Затем второй блок принимает, из первого блока, указание выбранной версии NR-U, которую можно использовать для соединения. Версия NR-U определяется на основе отправленного указания того, какие одну или несколько версий NR-U поддерживает второй блок вместе с какими одной или несколькими версиями NR-U, которые поддерживает один или более других вторых блоков.
Согласно дополнительному аспекту вариантов осуществления, представленных в данном документе, задача решена с помощью первого блока для обработки соединения между первым блоком и многочисленными вторыми блоками в сети беспроводной связи. Первый блок выполнен с возможностью:
- получения, из каждого из многочисленных вторых блоков, соответствующего указания того, какие одну или несколько версий протокола плоскости пользователя NR (NR-U) он поддерживает, и
- принятия решения относительно того, какую версию NR-U можно использовать для соединения, на основе указаний, принятых из нескольких вторых блоков.
В соответствии с еще одним дополнительным аспектом вариантов осуществления, представленных в данном документе, задача решена с помощью второго блока для обработки соединения между первым блоком, блоком принятия решения и многочисленными вторыми блоками в сети беспроводной связи. Второй блок выполнен с возможностью:
- отправки, в первый блок, указания того, какие одну или несколько версий протокола плоскости пользователя NR (NR-U) поддерживает второй блок, и
- приема, из первого блока, указания выбранной версии NR-U, которую можно использовать для соединения, причем версия NR-U выбирается на основе отправленного указания того, какие одна или несколько версий NR-U поддерживает второй блок вместе с какими одной или несколькими версиями NR-U, которые поддерживает один или более других вторых блоков.
Краткое описание чертежей
Фиг.1 – схематичная блок-схема, иллюстрирующая уровень техники.
Фиг.2 – блок-схема, иллюстрирующая уровень техники.
Фиг.3 – блок-схема, иллюстрирующая уровень техники.
Фиг.4 – схематичная блок-схема, иллюстрирующая уровень техники.
Фиг.5a – схематичная блок-схема, иллюстрирующая варианты осуществления сети беспроводной связи.
Фиг.5b – схематичная блок-схема, иллюстрирующая варианты осуществления сети беспроводной связи.
Фиг.6 - блок-схема последовательности операций, изображающая варианты осуществления способа в первом блоке.
Фиг.7 – блок-схема последовательности операций, изображающая варианты осуществления способа во втором блоке.
Фиг.8 – схематичная блок-схема, иллюстрирующая варианты осуществления сети беспроводной связи.
Фиг.9 – блок-схема последовательности операций, изображающая варианты осуществления способа.
Фиг.10 – схематичное представление, иллюстрирующее вариант осуществления.
Фиг.11 – схема, иллюстрирующая вариант осуществления.
Фиг.12 – схематичное представление, иллюстрирующее вариант осуществления.
Фиг.13 – схематичное представление, иллюстрирующее вариант осуществления.
Фиг.14 – схематичное представление, иллюстрирующее вариант осуществления.
Фиг.15a и b – схематичные блок-схемы, иллюстрирующие варианты осуществления первого блока.
Фиг.16a и b – схематичные блок-схемы, иллюстрирующие варианты осуществления второго блока.
Фиг.17 – схематично иллюстрирует телекоммуникационную сеть, подключенную через промежуточную сеть к хост-компьютеру.
Фиг.18 – обобщенная блок-схема хост-компьютера, обменивающегося данными через базовую станцию с пользовательским оборудованием через частично беспроводное соединение.
Фиг.19-22 – блок-схемы последовательностей операций, иллюстрирующие способы, реализованные в системе связи, включающей в себя хост-компьютер, базовую станцию и пользовательское оборудование.
Осуществление изобретения
В рамках разработки вариантов осуществления, представленных в данном документе, авторы изобретения выявили проблему, которая будет обсуждена первой.
В сценариях с двойной или мульти-связностью, которые в дальнейшем совместно упоминаются как DC, данные в UE могут быть отправлены по меньшей мере в два или более распределенных блоков (DU), подключенных к блоку управления (CU) или к DU и eNB, как показано на фиг.2, 3, 4a и 4b. Следует отметить, что узел, на котором размещается уровень протокола конвергенции пакетных данных (PDCP), например, CU, может представлять собой один блок или может быть логически и физически разделен на две отдельные функции, которые обрабатывают плоскость пользователя и данные управления по отдельности. Соединение в плоскости пользователя между узлом, на котором размещается PDCP, и узлом, на котором размещаются нижние уровни, например, DU, является протоколом плоскости пользователя NR, как определено в плоскости пользователя NR спецификации 3GPP TS 38.425 (ссылка 1) версии V15.0.0. Таким образом, протокол плоскости пользователя NR используется поверх интерфейса F1-U, интерфейса X2-U и интерфейса X2-C. 3GPP TS 38.425 представляет собой управляемую версию, и на момент написания текущей самой последней версией является версия 15.0.0.
3GPP версии 15.0.0 является первой версией спецификации 3GPP плоскости пользователя NR (TS 38.425, версия V15.0.0), и ожидается, что объем спецификации будет увеличен за счет добавления новых функциональных возможностей в каждой последующей версии спецификации. Некоторые из этих дополнений будут необязательными, а другие обязательными для поддержки. Следовательно, узел, поддерживающий более низкие уровни, например, DU, который поддерживает более раннюю версию, может неверно интерпретировать некоторые поля в структуре заголовка PDU UP, отформатированного в соответствии с более поздней версией, и это может вызвать проблемы, начиная от потери данных как отброшенных, ошибочной интерпретации данных и информации заголовка до тупиковых ситуаций. Это означает, что важно убедиться, что передающий узел использует версию протокола, совместимую с приемным узлом. Следует отметить, что это автоматически не означает, что оба узла должны использовать одну и ту же версию протокола, а данные, передаваемые между узлами, должны использовать структуры полей и заголовков, которые оба узла поддерживают и интерпретируют правильно.
Таким образом, задача вариантов осуществления, представленных в данном документе, состоит в том, чтобы повысить производительность сети беспроводной связи.
Примеры вариантов осуществления, представленных в данном документе, относятся к обработке версии протокола плоскости пользователя 5G NR, например, к обработке версии протокола интерфейса в новом радио 5G NR с особым акцентом на протокол плоскости пользователя.
Варианты осуществления, представленные в данном документе, позволяют добавить возможность передачи того, какие поддерживаются версии протокола, с использованием подходящих информационных элементов, и того, что эта информация может быть отправлена между CU и DU с использованием согласования более высокого уровня или внутриполосной сигнализации PDU, как определено в протоколе плоскости пользователя NR спецификации 3GPP TS 38.425 (ссылка 1). Это позволяет передающему узлу использовать версию протокола, совместимую с приемным узлом. Используемый в данном документе термин "ссылка 1" означает плоскость пользователя NR.
Варианты осуществления, представленные в данном документе, относятся, в общем, к сетям беспроводной связи. На фиг.5а схематично показана сеть 100 беспроводной связи. Сеть 100 беспроводной связи содержит одну или несколько RAN и одну или несколько CN. Сеть 100 беспроводной связи может использовать ряд различных технологий, таких как Wi-Fi, долгосрочное развитие (LTE), усовершенствованное LTE (LTE-Advanced), 5G, новое радио (New Radio, NR), широкополосный множественный доступ с кодовым разделением каналов (WCDMA), глобальная система мобильной связи/повышенная скорость передачи данных для развития GSM (GSM/EDGE), всемирная совместимость для микроволнового доступа (WiMax) или сверхмобильная широкополосная связь (UMB), и это лишь некоторые возможные реализации. Варианты осуществления, представленные в данном документе, относятся к последним тенденциям в технологии, которые представляют особый интерес в контексте 5G, однако варианты осуществления также применимы при дальнейшем развитии существующих систем беспроводной связи, таких, например, как WCDMA и LTE.
В сети 100 беспроводной связи функционируют UE, такие как UE 120. UE 120 может быть мобильной станцией, STA без точки доступа (без AP), STA и беспроводными терминалами и способно поддерживать связь через одну или несколько сетей доступа (AN), например, RAN, с одной или несколькими базовыми сетями (CN). Специалистам в данной области техники должно быть понятно, что термин "беспроводное устройство" является неограничивающим термином, который означает любой терминал, терминал беспроводной связи, пользовательское оборудование, устройство связи машинного типа (MTC), терминал для связи между устройствами (D2D) или узел, например, смартфон, ноутбук, мобильный телефон, датчик, ретранслятор, мобильные планшеты или даже небольшая базовая станция, обменивающаяся данными внутри соты.
Сеть 100 беспроводной связи содержит узел 109 радиосети, обеспечивающий радиопокрытие в географической зоне, такой как зона 11 обслуживания, которая также может упоминаться как луч или группа лучей первой технологии радиодоступа (RAT), такой как 5G, LTE, Wi-Fi или аналогичные. Узел 109 радиосети может быть узлом NG-RAN, приемопередающей точкой, например, базовой станцией, узлом сети радиодоступа, например, точкой доступа беспроводной локальной вычислительной сети (WLAN) или станцией точки доступа (STA с AP), контроллером доступа, базовой станцией, например, базовой радиостанцией, такой как узел B (NodeB), развитой NodeB (eNB, eNodeB), gNB, базовая приемопередающая станция, удаленное радиоустройство, базовая станция точки доступа, маршрутизатор базовой станции, передающее устройство базовой радиостанции, автономная точка доступа или любой другой сетевой блок, способный поддерживать связь с беспроводным устройством в пределах зоны обслуживания, обслуживаемой сетевым узлом 110, в зависимости, например, от первой используемой технологии радиодоступа и терминологии.
Многочисленные DU, из которых на фиг.5a показан только один DU 110, функционируют в сети 100 беспроводной связи. DU 110 может находиться в сетевом узле 109. DU 110 может представлять собой или содержать объект управления линией радиосвязи (RLC). RLC является одним из протоколов, обеспечивающих хорошую производительность поверх радиоинтерфейса.
Узел 109 радиосети может называться обслуживающим узлом радиосети и обменивается данными с UE 120 посредством DU 110 с передачами по нисходящей линии связи (DL) в UE 120 и передачами по восходящей линии связи (UL) из UE 120.
На фиг.5a и фиг.5b показан ряд блоков, таких, например, как первый блок 130, 501, и один или многочисленные вторые блоки 132, 502 функционируют в сети 100 беспроводной связи. Первый блок 130 в некоторых вариантах осуществления может находиться в сетевом узле 109. Первый блок 501, 130 и второй блок 502, 132 могут представлять собой или могут содержать объект PDCP. Объект PDCP в случае, когда он используется в данном документе, является функциональным объектом, который осуществляет шифрование и защиту целостности и завершает протокол PDCP.
В некоторых вариантах осуществления первый блок 130, 501 может быть любым из CU и DU, а также вторые блоки 132 могут представлять собой любой из CU и DU. Другие альтернативные варианты будут описаны ниже.
Первый и второй блоки 501, 130, 502, 132 и DU могут использоваться для функционального разделения. В некоторых вариантах осуществления CU, такие как первый блок 501, 130 и второй блок 502, 132, завершают PDCP, в то время как DU, такие как DU 110, реализуют уровни протокола ниже PDCP.
В некоторых вариантах осуществления первый блок 501, 130 и DU 110 разделены промежуточным интерфейсом, таким как интерфейс F1-U. Другие альтернативные варианты будут описаны ниже.
Способы, представленные в данном документе, могут выполняться первым блоком 501 и вторыми блоками 502. В качестве альтернативы, любой распределенный узел (DN) и функциональные возможности, например, содержащиеся на облаке 140, как показано на фиг.5a, могут использоваться для выполнения или частичного выполнения способов.
Варианты осуществления, представленные в данном документе, особенно полезны в облачной реализации, где сетевые узлы физически отделены друг от друга. Например, в виртуализированной среде DU, обслуживающий UE, может быть разделен как физически, так и в частотной области, что означает, что характеристики передачи для каждого отдельного DU могут значительно изменяться в зависимости от времени, и поэтому особенно важно, чтобы управление дублированием данных было столь же эффективным, насколько это возможно в таком сценарии.
Например, плоскость пользователя централизованного блока (CU-UP), работающая на объекте PDCP, таком как, например, первый блок 501, 130, может быть реализована как облачная сетевая функция. Используемый в данном документе термин CU-UP означает, например, облачную функцию или CU-UP, реализованный в радиоузле, возможно, совместно с одним или несколькими DU.
В настоящем раскрытии в некоторых примерных вариантах осуществления описаны в общих чертах подходящие способы оценки того, какие версии протокола плоскости пользователя NR, такие как версии согласно ссылке 1, поддерживают подключенные узлы, такие как первый блок 501 и многочисленные вторые блоки 502, а также способы передачи этой информации либо путем использования внутриполосной сигнализации плоскости пользователя, либо полагаясь на управление плоскостью управления более высокого уровня, чтобы гарантировать, что совместимые версии плоскости пользователя NR, такие как информационные поля версий согласно ссылке 1 и структуры заголовка, используются на протяжении всего соединения. Внутриполосная сигнализация плоскости пользователя при использовании в данном документе означает информационные элементы, переносимые, например, в протоколах GTP-U, X2-U, Xn-U или F1-U. Управление плоскостью управления более высокого уровня при использовании в данном документе означает информационные элементы, переносимые, например, в протоколах сигнализации F1-C, X2-AP, E1 или RRC.
В приведенных здесь примерах вариантов осуществления основное внимание уделяется чистому решению 5G, но все включенные варианты осуществления также применимы для EN-DC.
Варианты осуществления, представленные в данном документе, могут обеспечивать, например, следующие преимущества:
Преимуществом является обмен информацией о подходящей версии между задействованными узлами, такими как первый блок 501 и многочисленные вторые блоки 502, в качестве входных данных для принятия решения относительно того, какая версия NR-U, которая также упоминается как ссылка 1, должна использоваться для подключения DU к CU. Таким образом, варианты осуществления, представленные в данном документе, позволяют значительно снизить риск несоответствия протоколов, приводящего к неверно интерпретируемым полям заголовка или данным, которые отбрасываются и теряются, ошибочной интерпретации данных и/или информации заголовка и тупиковым ситуациям. Представленные в данном документе варианты осуществления, использующие внутриполосную сигнализацию плоскости пользователя NR, также гарантируют, что информация об обработке версии может быть передана незамедлительно и с минимальными издержками по сравнению с другими более трудоемкими процедурами, такими как процедуры сигнализации радиоресурсов (RRC).
Функциональные возможности, описанные в настоящем раскрытии, будут особенно полезны в сценариях DC 5G с участием нескольких DU от нескольких разных поставщиков, поскольку чем больше задействовано узлов и разных поставщиков, тем важнее то, что используемые структуры заголовков и информационные элементы (IE) правильно понимаются, и интерпретируется всеми узлами.
На фиг.6 показан пример способа, выполняемого первым блоком 501 для обработки соединения, такого как предстоящее соединение между первым блоком 501 и многочисленными вторыми блоками 502 в сети 100 беспроводной связи. Способ может содержать любой из этапов, описанных ниже. Смотри также фиг.5b, изображающий первый блок 501 и два вторых блока 502. В некоторых вариантах осуществления первый блок 501 представлен CU, и многочисленные вторые блоки 502 представлены одним или несколькими DU. В некоторых альтернативных вариантах осуществления первый блок 501 представлен CU-CP, и многочисленные вторые блоки 502 представлены CU-UP и одним или несколькими DU. В некоторых других альтернативных вариантах осуществления первый блок 501 представлен главным узлом, и многочисленные вторые блоки 502 представлены многочисленными вторичными узлами. В некоторых вариантах осуществления первый блок 501 представлен CU-UP.
На этапе 601 первый блок 501 получает из каждого из многочисленных вторых блоков 502 соответствующее указание того, какие одну или несколько версий NR-U он поддерживает. NR-U также упоминается в данном документе как ссылка 1. Таким образом, первый блок 501 собирает информацию о поддерживаемых версиях NR-U из многочисленных вторых блоков 502.
Этап 602. Первый блок 501 затем принимает решение относительно того, какую версию NR-U можно использовать для соединения, на основе указаний, принятых из многочисленных вторых блоков 502. Это может быть решено путем сравнения версий, поддерживаемых в подключенных блоках, и выбора самой последней версии, поддерживаемой обоими взаимодействующими блоками.
На необязательном этапе 603 первый блок 501 отправляет в каждый из соответствующих многочисленных вторых блоков 502 указание выбранной версии NR-U, которую можно использовать для соединения. Это необходимо для информирования соответствующего второго блока 502 о том, какую версию использовать.
Некоторые дополнительные альтернативные варианты осуществления описаны ниже.
На фиг.7 показан примерный способ, выполняемый одним из многочисленных вторых блоков 502, например, для обработки соединения, такого как предстоящее соединение между первым блоком 501 и многочисленными вторыми блоками 502 в сети 100 беспроводной связи. Способ может содержать любой из этапов, описанных ниже. Смотри также фиг.5b, на которой показаны первый блок 501 и два вторых блока 502.
Как упомянуто выше, в некоторых вариантах осуществления первый блок 501 представлен CU, и второй блок 502 представлен DU. В некоторых альтернативных вариантах осуществления первый блок 501 представлен CU-CP, и второй блок 502 представлен любым одним из CU-UP и DU. В некоторых других альтернативных вариантах осуществления первый блок 501 представлен главным узлом, и второй блок 502 представлен вторичным узлом. В некоторых вариантах осуществления первый блок 501 представлен CU-UP.
На этапе 701 второй блок 502 отправляет указание в первый блок 501. Указание указывает то, какие одну или несколько версий NR-U поддерживает второй блок 502.
На этапе 702 второй блок 502 принимает другое указание из первого блока 501. Другое указание указывает выбранную версию NR-U, которую можно использовать для соединения. Версия NR-U выбирается на основе отправленного указания того, какие одну или несколько версий NR-U второй блок 502 поддерживает вместе с какими одной или несколькими версиями NR-U, которые поддерживает один или более других вторых блоков 502.
Обзор
Как показано на фиг.8, первым этапом определения того, какой тип структуры заголовка протокола и IE, которые могут использоваться через интерфейс F1-U, может быть определение того, какие поддерживаются версии плоскости пользователя NR, такие как версии согласно ссылке 1 всех узлов и/или блоков, таких как первый блок 501 и вторые блоки 502, участвующие в подключении к UE 120. После того, как эта информация была собрана первым блоком 501 из вторых блоков 502 и обработана в соответствующем узле, первый узел 502 будет принимать решение относительно того, какие версии протокола согласно ссылке 1, то есть версии NR-U, должны использоваться при каждом подключении. Следует отметить, что это может означать, что разные DU подключены к CU с использованием одной и той же или разных версий плоскости пользователя NR, такой как ссылка 1.
Следует также отметить, что использование версий плоскости пользователя NR, таких как версии согласно ссылке 1, не должно быть статическим: даже если определенная версия или версии выбраны при установке соединения, UE 120 может во время вызова переместиться в другое место, где оно подключается к другим первым и вторым блокам, например, к другому DU или ряду DU, которые поддерживают другие версии плоскости пользователя NR, такие как версии согласно ссылке 1, что означает, что управление версиями и их обработка должны постоянно контролироваться во время вызова во избежание возможных проблем, связанных с неправильным прочтением или ошибочной интерпретацией PDU плоскости пользователя, как описано выше.
Способы, описанные в данном документе, можно распространить на все случаи, когда применяется протокол плоскости пользователя NR. А именно, это могут быть случаи, когда узел, на котором размещен протокол PDCP, является сетевым узлом 109, таким как eNB или gNB-CU, тогда как узел, на котором размещены нижние уровни, может быть сетевым узлом 109, таким как eNB или gNB-DU. Следует отметить, что сетевой узел 109, такой как eNB, также может быть разделен на узел, выполняющий функции плоскости пользователя, то есть eNB-CU-UP, и функции уровня управления узла, то есть eNB-CU-CP. Сетевой узел 109, такой как eNB, также может иметь eNB-DU, и в этом случае протокол плоскости пользователя NR может также использоваться между eNB-CU (eNB-CU-UP) и eNB-DU. Таким образом, описанные в данном документе способы также применимы к интерфейсам, соединяющим eNB-CU с eNB-DU. Для упрощения варианты осуществления описывают способы в отношении gNB-CU, размещающего PDCP, и gNB-DU, размещающего нижние уровни.
Как упомянуто выше, первый блок 501 может быть представлен CU-CP, и вторые блоки 502 могут быть представлены любым одним из CU-UP и DU.
При развертывании, где CU разделен на часть плоскости пользователя (CU-UP) и часть плоскости управления (CU-CP), подключенные через стандартный интерфейс, то есть интерфейс E1, как указано в TS 38.46x, версии, поддерживаемые CU-UP, могут быть отправлены в CU-CP. Между тем, версии плоскости пользователя NR, поддерживаемые DU, например, вторым блоком 502, могут передаваться из DU в CU-CP, например, в первый блок 501, например, через стандартный интерфейс F1, заданный в 3GPP TS 38.473. CU-CP, такая как первый блок 501, может затем принять решение относительно того, какую версию протокола использовать для каждого радиоканала передачи данных (DRB), и информировать CU-UP, такую как второй блок 502, и DU, такой как второй блок 502, во время процедур установления однонаправленного канала через интерфейсы E1 и F1.
Как упомянуто выше, первый блок 501 может быть представлен CU-CP, и вторые блоки 502 могут быть представлены любым одним из CU-UP и DU. В качестве альтернативы, первый блок 501 может быть представлен CU-UP, и второй блок 502 представлен любым одним из CU-CP и DU.
В качестве альтернативы, CU-CP, такая как второй блок 502, может передать информацию о версиях протокола, поддерживаемых в DU, таком как второй блок 502, в CU-UP, такую как первый блок 501. Основываясь на этой информации, CU-UP, такая как первый блок 501, может принять решение относительно того, какую использовать версию. CU-UP, такая как первый блок 501, или CU-CP, когда она является первым блоком 501, может объединять информацию о версиях для разных DU, таких как вторые блоки 502, для принятия решений. Обмен версиями протокола может также осуществляться через внешние интерфейсы (такие как X2 и/или Xn), так что CU-CP, такая как первый блок 501, или CU-UP, когда она является первым блоком 501, может принять решение относительно того, какую версию использовать в случае двойной связности между различными узлами (узлом eNB и/или NG-RAN) для принятия решений. В качестве примера, CU-UP, такая как второй блок 502, в сценарии мобильности может принимать обновленную информацию о версии и на ее основе добавлять новые версии и/или реконфигурировать ссылки 1 в новые версии.
Во внутриполосном варианте осуществления эта информация об управлении версиями передается через информационные элементы, содержащиеся в кадре данных плоскости пользователя NR, как описано в разделе 5 ниже.
Согласованное управление версиями более высокого уровня
В этом подпункте приведен подробный пример механизма обмена поддерживаемой версией NR-U с использованием сигнализации более высокого уровня (то есть плоскости управления). Как описано выше, по меньшей мере две возможные опции представляет собой то, что: (1) CU-CP принимает решение, таким образом, являясь первым блоком 501, относительно того, какую версию NR-U использовать во время установления DRB, или что (2) CU-UP принимает решение, таким образом, являясь первым блоком 501, относительно того, какую версию NR-U использовать во время установления DRB. Далее приведен пример для случая, когда CU-CP принимает решение, таким образом, являясь первым блоком 501, относительно версии NR-U. Однако аналогичный принцип и сигнализация также могут применяться в случае, когда CU-UP принимает решение, таким образом, являясь первым блоком 501, относительно версии NR-U.
Пример: CU-CP принимает решение относительно того, чтобы представлять собой первый блок 501 версии NR-U
Поток сигнализации, представленный на фиг.9, показывает, как обмениваться информацией о поддерживаемых версиях NR-U. Это можно выполнить с помощью процедур установления F1 и E1. Затем CU-CP, такая как первый блок 501, узнает о версиях NR-U, поддерживаемых подключенными DU и CU-UP, такими как вторые блоки 502. Например, эту информацию можно использовать при выборе того, какую CU-UP нужно использовать для обслуживания UE 120. CU-CP гарантирует, что одна и та же версия используется CU-UP и DU, такими как вторые блоки 502, путем включения выбранной версии NR-U в процедуру установления контекста UE через F1 по направлению к DU и в процедуре установления контекста носителя информации через E1.
На фиг.9 показан поток вызовов, иллюстрирующий: (1) обмен поддерживаемыми версиями NR-U во время установления интерфейса; (2) обмен выбранной версией NR-U для DRB во время установления однонаправленного канала информации.
Этапы 1-2. DU, такой как один из вторых блоков 502, обозначенный на фиг.9 как gNB-DU, отправляет сообщение запроса на установление F1, включающее в себя список поддерживаемых версий NR-U. CU-CP, такая как первый блок 501, обозначенный на фиг.9 как gNB-CU-CP, сохраняет эту информацию и отправляет ответ установления F1. После этого F1-C готов к работе. Используемое в данном документе обозначение F1-C представляет собой протокол плоскости управления, используемый для связи между CU и DU.
DU, такой как один из вторых блоков 502, может предоставлять информацию о поддерживаемых версиях NR-U путем включения IE списка версий NR-U в сообщение запроса на установление F1, как показано ниже в таблице 1.
Следует отметить, что три последние строки в таблице 1, последняя строка в таблице 2 и последняя строка в таблице 3 представляют собой то, что варианты осуществления, представленные в данном документе, обеспечивают добавление к существующей процедуре.
В качестве альтернативы, DU может также предоставить только самую последнюю поддерживаемую версию NR-U, что подразумевает, что все предыдущие версии также поддерживаются.
Этапы 3-4. CU-CP отправляет сообщение запроса на установление E1. CU-UP, такая как другой из вторых блоков 502, которая упоминается как gNB-CU-UP, показанная на фиг.9, отвечает с помощью ответных сообщений установления E1, включая список поддерживаемых версий NR-U. CU-CP хранит эту информацию. После этого E1-C готов к работе.
Точно так же, как DU через F1, CU-UP может предоставить список поддерживаемых версий NR-U или последних поддерживаемых версий через E1. Точно такая же сигнализация, как и сигнализация, выделенная красным цветом в таблице 1, может использоваться CU-UP через E1.
Следует отметить, что этапы 1-2 и 3-4 необязательно выполняются в порядке, показанном на фиг.9. Кроме того, следующие этапы могут быть выполнены в любой момент времени после завершения этапов 1-4.
Этапы 5-6. CU-CP, такая как первый блок 501, завершает сообщение запроса на установление контекста однонаправленного канала E1 для CU-UP, такой как один из вторых блоков 502, для установления однонаправленных каналов. Сообщение может включать в себя новый IE, а именно версию NR-U (смотри пример, приведенный в таблице 2), который используется для информирования CU-UP о версии NR-U, которая будет использоваться для однонаправленных каналов. Версии NR-U могут находиться среди версий, просигнализированных CU-UP во время процедуры установления E1. CU-UP отвечает, используя ответ установления контекста однонаправленного канала.
Этапы 7-8. CU-CP, такая как первый блок 501, завершает сообщение F1 запроса на установление контекста UE для DU, такого как один из вторых блоков 502, для установления однонаправленных каналов. Сообщение включает в себя новый IE, а именно версию NR-U (смотри пример, приведенный в таблице 2), который используется для информирования DU о версии NR-U, используемой для однонаправленных каналов. Версии NR-U могут находиться среди версий, просигнализированных DU во время процедуры установления F1. DU отвечает, используя ответ установления контекста UE.
Этапы 9-10. Выполняется процедура модификации контекста однонаправленного канала, в которой CU-CP, такая как первый блок 501, завершает TEID DL однонаправленных каналов для CU-UP, такой как один из вторых блоков 502.
В качестве альтернативы, на этапе 5 CU-CP, такая как первый блок 501, отправляет полный список версий NR-U, поддерживаемых DU, например, в одном из вторых блоков 502. CU-UP, такая как один из вторых блоков 502, выбирает версию NR-U для использования и предоставляет отчет о ней на этапе 6. Затем на этапе 7 CU-CP отправляет DU версию NR-U, выбранную CU-UP.
Таблица 1. Запрос на установление F1, включая список поддерживаемых версий NR-U.
Название IE/группы
Наличие
Диапазон
Тип IE и ссылка
Описание семан-тики
Критичность
Назначенная критичность
Тип сообщения
M
9.3.1.1
Да
отклонить
ID транзакции
M
93.1.23
Да
отклонить
ID gNB-DU
M
9.3.19
Да
отклонить
Название gNB-DU
0
Напечатанная строка (размер(1..150...))
Да
игнорировать
Список обслуживаемых сот gNB-DU
1
Список сот, сконфигури-рованных в gNB-DU
Да
отклонить
>Элемент обслуживаемых сот gNB-DU
1..<maxCellingNBDU >
Каждый
отклонить
>>Информация об обслуживаемых сотах
M
93.1.10
Информация о сотах, сконфигурированных в gNB-DU
>>Системная информация gNB-DU
0
9.3.1.18
RRC-контейнер с системной информацией, принадле-жащий gNB-DU
Поддерживае-мая версия NR-U NR-U
1
Список версий NR-U, поддерживаемых gNB-DU
Да
отклонить
>Элемент поддерживае-мой версииNR-U
1..<maxnoofRRCversions>
Каждый
отклонить
>>Версия NR-U
M
ПЕРЕЧИСЛЕННЫЕ (rel1500. ге11510....)
Версия NR-U
-
-
Таблица 2. IE версии NR-U, включенный в сообщение запроса на установление контекста UE и/или в сообщение запроса на установление контекста однонаправленного канала.
Название IE/группы
Наличие
Диапазон
Тип IE и ссылка
Описание семантики
Критичность
Назначенная критичность
Версия NR-U
M
9.3.1.1
Да
отклонить
В некоторых вариантах осуществления версия NR-U может быть закодирована как диапазон числовых значений или как указание, например, как представлено в таблице 3. Каждое из чисел соответствует версии спецификации протокола UP NR, начиная с первого числового значения, которое соответствует версии 15.0.0 или первой точке инициирования выбора. Преимущество этого типа кодирования состоит в том, что спецификации и, следовательно, код протокола не нужно обновлять каждый раз, когда доступна новая версия протокола. Как только новая версия протокола доступна и поддерживается, поддерживающий ее узел просто сигнализирует следующее числовое значение по отношению к значению, указанному при поддержке предыдущей версии. Пример кодирования информации о версии показан в таблице 3.
Таблица 3. IE версии NR-U, включенный в сообщение запроса на установление контекста UE и/или сообщение запроса на установление контекста однонаправленного канала, закодированное как числовое значение в диапазоне от 1 до 128.
Название IE/группы
Наличие
Диапазон
Тип IE и ссылка
Описание семантики
Критичность
Назначенная критичность
Верксия NR-U
M
Нумерованный (1…128,…)
Да
отклонить
Управление внутриполосными версиями
Как упомянуто выше, в некоторых вариантах осуществления первый блок 501 представлен CU, и второй блок 502 представлен DU.
В примере, основанном на внутриполосном использовании, функция управления версиями находится в CU, таким образом, представляя собой первый блок 501, и использует информацию обратной связи, поступающую из DU, таким образом, представляя собой многочисленные вторые блоки 502, для определения того, какую использовать версию согласно ссылке 1. В сценарии EN-DC функция управления версиями находится в узле, в котором находится PDCP, таким образом, представляя собой первый блок 501. Эта информация в CU может быть передана любым из протоколов, соединяющих CU и DU, но во внутриполосном варианте осуществления PDU плоскости пользователя NR, как определено в ссылке 1, что представляет собой способ передачи такой информации. Детали, которые относятся к сигнализации, более подробно описаны ниже. Информация о поддерживаемой версии, принятой из DU, затем используется первым блоком 501 для определения того, какие использовать версии плоскости пользователя NR, такие как версии протокола согласно ссылке 1. Информация о версии может затем либо присутствовать в каждом заголовке PDU UP, отправленном в DU, либо она может быть добавлена в зависимости от потребностей в конкретных заголовках DL PDU, которые могут быть либо управляющими, либо PDU данных.
В альтернативном примере функция управления версиями разделена между всеми задействованными узлами. Любой узел может отправлять свои самые последние версии плоскости пользователя NR, такие как поддерживаемая версия протокола согласно ссылке 1, таким образом, представляя собой один из вторых блоков 502, в другие подключенные узлы, таким образом, представляя собой первые блоки 501. Каждый узел, принимающий такую информацию, должен реагировать с учетом самых ранних обычно поддерживаемых версий плоскости пользователя NR, таких как версия протокола согласно ссылке 1, отличная от своей собственной самой последней поддерживаемой версии протокола, и только что принятой версии протокола. Это называется установленной версией NR-U, которую можно использовать для соединения на основе указаний, принятых из многочисленных вторых блоков 502. Эта процедура квитирования продолжается до тех пор, пока та же самая версия протокола, ранее отправленная в конкретный узел, снова не будет принята из того же узла, например, подтвержденная как самая последняя обычно поддерживаемая версия протокола согласно ссылке 1.
Когда не все узлы находятся в прямом соединении друг с другом, например, в случае двух DU, подключенных к общему CU, но не подключенных напрямую между собой, узлы с более чем одним подключенным узлом, например, в этом примере CU, должны сигнализировать всем подключенным узлам о самых последних обычно поддерживаемых версиях плоскости пользователя NR, таких как версия протокола согласно ссылке 1, совместно используемая непосредственно им самим и его подключенными узлами, и сходиться к одной версии протокола.
Эта процедура квитирования может быть повторно инициирована снова в любой момент времени, например, при добавлении или удалении узла.
Одно дополнительное усовершенствование состоит в том, что узел может хранить, как правило, самую последнюю поддерживаемую версию протокола согласно ссылке 1 для каждого подключенного узла и, таким образом, сокращать сигнализацию при установлении новых соединений.
Для передачи информации об управлении версиями, перечисленной ниже, предлагается либо использовать существующие типы PDU и добавленную информацию о версии, либо при необходимости добавить новый тип PDU в раздел 5.5.2 согласно ссылке 1. В текущем стандарте уже используются типы 0 и 1 PDU, и в новой информации об управлении версиями типа PDU может, например, использоваться следующий доступный тип PDU, равный 2.
Специалисту в данной области техники будет понятно, что фиг.10-14, представленные ниже, представляют собой только примерные варианты осуществления, основанные на текущих типах PDU, определенных в ссылке 1, и что другие комбинации полей данных, запасных или зарезервированных битов либо в определенных в настоящее время, либо в типах PDU, либо в добавленных в дальнейшем в ссылку 1 могут использоваться для передачи информации об управлении версиями. Еще одной альтернативой является использование в настоящее время неиспользуемых значений поля "Заголовок следующего расширения" GTP-U.
Кроме того, следует также отметить, что информация об управлении версиями может быть передана или отправлена из любого узла, способного извлекать информацию, касающуюся поддержки версии. В качестве примера, другой тип PDU, который должен использоваться, может быть общим типом PDU UL. В качестве неограничивающего примера информация об управлении версиями может быть отправлена из второго блока 502, когда он является gNB-DU, в первый блок 501, когда он является gNB-CU, или из второго блока 502, когда он является gNB-DU, в первый блок 501, когда он является eNB LTE, или из второго блока 502, когда он является eNB LTE, в первый блок 501, когда он является gNB-CU.
Обработка информации об управлении версиями нисходящей линии связи
Поле информации об управлении версиями в нижеприведенных примерах может использоваться передающим узлом, таким как второй блок 502, для указания версии согласно ссылке 1, такой как версия NR-U, используемая для компиляции переданного PDU.
Затем, это позволяет приемному узлу, такому как первый блок 501, узнать структуру заголовка и правила IE, используемые передающим узлом для структурирования PDU, чтобы можно было бы правильным способом декодировать содержащуюся информацию.
Примеры PDU пользовательских данных DL с полем управления версиями
Одним из примеров PDU пользовательских данных DL с полем управления версиями всегда будет включение поля версии. Оно может быть добавлено либо непосредственно под первым октетом, как на фиг.10, который упоминается как информация 1010 о версии, либо как последний октет перед запасным расширением.
Другой вариант осуществления состоит в использовании доступных запасных битов заголовка, которые упоминаются как запасные биты 1110 для указания наличия поля версии, так что, если этот бит установлен в 1, он указывает на наличие поля версии, и если он установлен в 0, то поле версии отсутствует, как показано на фиг.11.
В еще одном варианте осуществления определен новый тип PDU, такой как пример кадра для информации о версии нового типа 2 PDU, называемой информацией 1210 об управлении версиями. На фиг.12 показан вариант осуществления, где новый тип PDU определен выше в ссылке 1. В настоящее время определены значения PDU Type = 0 (пользовательские данные DL) и 1 (статус доставки данных DL), что означает, что PDU Type = 2 может использоваться для передачи поля информации об управлении версиями. На фиг.12 представлена информация об управлении версиями (тип PDU 2).
Обработка управляющей информации версии восходящей линии связи
Примеры PDU статуса доставки данных DL (DDDS) с полем управления версиями.
В некоторых примерах один октет резервного расширения 1310, как указано в разделе 5.5.3.24 в ссылке 1, используется для передачи поля информации об управлении версиями (смотри фиг.13).
В другом примере во втором октете вводится новый бит флага, чтобы указать наличие поля информации о версии, называемого информацией (info) 1410 версии.
Информации о версии с битом 1 во втором октете используется для указания присутствия октета информации об управлении версиями. Если информация о версии установлена в 1, то присутствует октет информации об управлении версиями. Если установлено значение 0, то октет информации об управлении версиями отсутствует (смотри фиг.14).
Обработка ошибочных конфигураций версии
Неверные конфигурации или ошибки, при которых один или несколько PDU отправляются в узел, который не поддерживает определенную версию согласно ссылке 1, такую как версия NR-U, могут обрабатываться многочисленными способами:
Простым примером является введение правила, согласно которому узел, который принимает поле информации об управлении версиями с неподдерживаемой версией, должен отбросить PDU и/или ответить с помощью PDU, содержащим самую последнюю поддерживаемую версию.
Другой пример состоит в том, чтобы ввести либо новый тип PDU, либо IE, который указывает информацию либо о самой последней поддерживаемой версии, либо о списке поддерживаемых версий, который затем может быть отправлен в передающий узел.
Оба эти примера могут быть проиллюстрированы приведенными выше примерами с той лишь разницей, что поле информации об управлении версиями заменено на одно или несколько полей информации о поддерживаемой версии.
Таким образом, вышеупомянутое поведение, когда узел отбрасывает PDU, содержащие поля информации об управлении версиями, которые он не поддерживает, и отвечает PDU, указывая самую последнюю поддерживаемую версию через поле информации поддерживаемой версии или т.п., может быть принято 3GPP как обязательное дополнение к стандарту согласно ссылке 1.
В другом примере, при приеме неподдерживаемой версии протокола или после того, как оба задействованных узла, такие как первый и второй блоки 501 и 502, обменялись версиями протокола, такими как версии NR-U, и не была достигнута конвергенция в отношении обычно поддерживаемой версии, процедура может быть запущена через интерфейсы плоскости управления, например, через F1-C между gNB-DU и gNB-CU или через интерфейс E1 между gNB-CU-UP и gNB-CU-CP. Эта процедура может сигнализировать о несовпадении с общей версией протокола UP. Процедура может представлять собой сбой, из-за которого был удален однонаправленный канал, в котором не была достигнута конвергенция версии UP, или процедура может просто отметить событие отсутствия конвергенции и предоставить его в узел, на котором размещены функции CP, для управления переносом, например, gNB-CU-CP, чтобы предпринять соответствующие действия.
На фиг.15b показан пример механизмов в первом блоке 501. Первый блок 501 может содержать блок 1510 получения, блок 1520 принятия решения и блок 1530 отправки, которые показаны на фиг.15b.
На фиг.16а и b показан пример компоновки во втором блоке 502. Второй блок 502 может содержать блок 1610 отправки и блок 1620 приема, которые показаны на фиг.16b.
- Соответствующие первый блок 501 и второй блок 502 могут содержать интерфейс 1500, 1600 ввода и вывода, выполненный с возможностью поддержания связи друг с другом (смотри фиг.15а и фиг.16а). Интерфейс ввода и вывода может содержать беспроводной приемник (не показан) и беспроводной передатчик (не показан).
Варианты осуществления в данном документе могут быть реализованы с помощью соответствующего процессора или одного или нескольких процессоров, таких как соответствующий процессор 1540, 1630 схемы обработки в соответствующем первом блоке 501 и втором блоке 502, показанных на фиг.15a и 16a, вместе с соответствующим компьютерным программным кодом для выполнения функций и действий вариантов осуществления, представленных в данном документе. Программный код, упомянутый выше, может быть также предоставлен как компьютерный программный продукт, например, в виде носителя информации, несущего компьютерный программный код для выполнения приведенных в данном документе вариантов осуществления при загрузке в соответствующие первый блок 501 и второй блок 502. Один такой носитель информации может быть выполнен в виде CD-ROM. Однако это можно выполнить с помощью других носителей информации, таких как карта памяти. Кроме того, компьютерный программный код может быть предоставлен как чистый программный код на сервере и загружен в соответствующие первый блок 501 и второй блок 502.
Соответствующие первый блок 501 и второй блок 502 могут дополнительно содержать соответствующую память 1550, 1640, содержащую один или несколько блоков памяти. Память содержит инструкции, исполняемые процессором в соответствующем первом блоке 501 и втором блоке 502.
Память выполнена с возможностью использования для хранения, например, версий NR-U, данных, конфигураций и приложений для выполнения описанных в данном документе способов при их исполнении в соответствующих первом блоке 501 и втором блоке 502.
В некоторых вариантах осуществления соответствующая компьютерная программа 1560, 1650 содержит инструкции, которые при их исполнении по меньшей мере одним процессором 1540, 1630 предписывают по меньшей мере один процессору соответствующего первого блока 501 и второго блока 502 выполнять вышеупомянутые действия.
В некоторых вариантах осуществления соответствующий носитель 1570, 1660 информации содержит соответствующую компьютерную программу, причем носитель информации является одним из электронного сигнала, оптического сигнала, электромагнитного сигнала, магнитного сигнала, электрического сигнала, радиосигнала, микроволнового сигнала или машиночитаемого носителя информации.
Специалистам в данной области техники будет также понятно, что функциональные блоки в соответствующем первом блоке 501 и втором блоке 502, описанном ниже, могут относиться к комбинации аналоговых и цифровых схем и/или к одному или нескольким процессорам, сконфигурированным с программным обеспечением и/или аппаратно-программным обеспечением, которое хранится, например, в соответствующем первом блоке 501 и втором блоке 502, которое при его исполнении соответствующим одним или несколькими процессорами, такими как процессоры, описанные выше, предписывают по меньшей мере одному соответствующему процессору выполнять действия согласно любому из действий, описанных выше. Один или несколько из этих процессоров, а также другое цифровое оборудование могут быть включены в одну специализированную интегральную схему (ASIC), или несколько процессоров и различное цифровое оборудование могут быть распределены между несколькими отдельными компонентами, независимо от того, смонтированы ли они в отдельных корпусах или собраны в одну систему на кристалле (SoC).
Когда используется слово "содержать" или "содержащий", оно должно толковаться как неограничивающее, то есть означающее "состоять по меньшей мере из".
Варианты осуществления в данном документе не ограничиваются описанными выше предпочтительными вариантами осуществления. Можно использовать различные альтернативы, модификации и эквиваленты.
Ниже кратко описаны некоторые примерные варианты 1-22 осуществления. Смотри, например, фиг.5a и b, 6, 7, 15a и b и 16a и b.
Вариант 1 осуществления. Способ, выполняемый первым блоком 501, для обработки соединения, такого как предстоящее соединение между первым блоком 501 и многочисленными вторыми блоками 502 в сети 100 беспроводной связи, причем способ содержит:
получение 601, из каждого из многочисленных вторых блоков соответствующего, указания того, какие одну или несколько версий протокола плоскости пользователя NR (NR-U) он поддерживает, и
принятие решения 602 относительно того, какую версию NR-U можно использовать для соединения на основе указаний, принятых из многочисленных вторых блоков 502.
Вариант 2 осуществления. Способ согласно варианту 1 осуществления, в котором первый блок 501 представлен центральным блоком (CU), и многочисленные вторые блоки 502 представлены одним или более распределенными блоками (DU).
Вариант 3 осуществления. Способ согласно варианту 1 осуществления, в котором первый блок 501 представлен частью плоскости управления централизованного блока (CU-CP), и многочисленные вторые блоки 502 представлены частью плоскости пользователя центрального блока (CU-UP) и одним или более распределенными блоками (DU).
Вариант 4 осуществления. Способ согласно варианту 1 осуществления, в котором первый блок 501 представлен главным узлом, и многочисленные вторые блоки 502 представлены многочисленными вторичными узлами.
Вариант 5 осуществления. Способ согласно любому из вариантов 1-5 осуществления, дополнительно содержащий:
отправку 603 в каждый из соответствующих многочисленных вторых блоков 502 указания относительно выбранной версии NR-U, которую можно использовать для соединения.
Вариант 6 осуществления. Компьютерная программа, содержащая инструкции, которые при их исполнении процессором предписывают процессору выполнять действия согласно любому из вариантов 1-5 осуществления.
Вариант 7 осуществления. Носитель информации, содержащий компьютерную программу согласно варианту 6 осуществления, в котором носитель информации является одним из электронного сигнала, оптического сигнала, электромагнитного сигнала, магнитного сигнала, электрического сигнала, радиосигнала, микроволнового сигнала, или машиночитаемого носителя информации.
Вариант 8 осуществления. Способ, выполняемый вторым блоком 502, для обработки соединения, такого как предстоящее соединение между первым блоком 501, блоком принятия решения и многочисленными вторыми блоками 502 в сети 100 беспроводной связи, причем способ содержит:
отправку 701, в первый блок 501, указания того, какие одну или несколько версий протокола плоскости пользователя NR (NR-U) поддерживает второй блок, и
прием 702, из первого блока 501, указания выбранной версии NR-U, которую можно использовать для соединения, причем версия NR-U выбрана на основе отправленного указания того, какие одну или несколько версий NR-U поддерживает второй блок 502 вместе с одной или несколькими версиями NR-U, которые поддерживает один или более других вторых блоков 502.
Вариант 9 осуществления. Способ согласно варианту осуществления 8, в котором первый блок 501 представлен центральным блоком (CU), и второй блок 502 представлен распределенным блоком (DU).
Вариант 10 осуществления. Способ согласно варианту осуществления 8, в котором первый блок 501 представлен частью плоскости управления центрального блока (CU-CP), и второй блок 502 представлен любым распределенным блоком (DU) части плоскости пользователя централизованного блока (CU-UP).
Вариант 11 осуществления. Способ согласно варианту 8 осуществления, в котором первый блок 501 представлен главным узлом, и второй блок 502 представлен вторичным узлом.
Вариант 12 осуществления. Компьютерная программа, содержащая инструкции, которые при их исполнении процессором предписывают процессору выполнять действия согласно любому из вариантов 8-11 осуществления.
Вариант 13 осуществления. Носитель информации, содержащий компьютерную программу согласно варианту 12 осуществления, в котором носитель информации является одним из электронного сигнала, оптического сигнала, электромагнитного сигнала, магнитного сигнала, электрического сигнала, радиосигнала, микроволнового сигнала, или машиночитаемого носителя информации.
Вариант 14 осуществления. Первый блок 501 для обработки соединения, такого как предстоящее соединение между первым блоком 501 и многочисленными вторыми блоками 502 в сети 100 беспроводной связи, причем первый блок 501 выполнен с возможностью:
получения, из каждого из многочисленных вторых блоков, соответствующего указания того, какую одну или несколько версий протокола плоскости пользователя NR (NR-U) он поддерживает, например, посредством блока 1510 получения в первом блоке 501, и
принятия решения относительно того, какую версию NR-U можно использовать для соединения на основе указаний, принятых из многочисленных вторых блоков 502, например, посредством блока 1520 принятия решения в первом блоке 501.
Вариант 15 осуществления. Первый блок 501 согласно варианту 14 осуществления, в котором первый блок 501 выполнен с возможностью представления центральным блоком (CU), и многочисленные вторые блоки 502 выполнены с возможностью представления одним или более распределенными блоками (DU).
Вариант 16 осуществления. Первый блок 501 согласно варианту 14 осуществления, в котором первый блок 501 выполнен с возможностью представления частью плоскости управления централизованного блока (CU-CP), и многочисленные вторые блоки 502 выполнены с возможностью представления частью плоскости пользователя центрального блока (CU-UP) и одним или более распределенными блоками (DU).
Вариант 17 осуществления. Первый блок 501 согласно варианту 14 осуществления, в котором первый блок 501 выполнен с возможностью представления главным узлом, и многочисленные вторые блоки 502 выполнены с возможностью представления многочисленными вторичными узлами.
Вариант 18 осуществления. Первый блок 501 согласно любому из вариантов 14-17 осуществления, в котором первый блок 501 дополнительно выполнен с возможностью:
отправки, в каждый из соответствующих многочисленных вторых блоков 502, указания выбранной версии NR-U, которую можно использовать для соединения, например, посредством блока 1530 отправки в первом блоке 501.
Вариант 19 осуществления. Второй блок 502 для обработки соединения, такого как предстоящее соединение между первым блоком 501, блоком принятия решения и многочисленными вторыми блоками 502 в сети 100 беспроводной связи, причем второй блок 502 выполнен с возможностью:
отправки, в первый блок 501, указания того, какие одну или несколько версий протокола плоскости пользователя NR (NR-U) поддерживает второй блок, например, посредством блока 1610 отправки во втором блоке 502, и
приема, из первого блока 501, указания выбранной версии NR-U, которую можно использовать для соединения, например, посредством блока 1620 приема во втором блоке 502, причем версия NR-U выбирается на основе отправленного указания того, какие одну или несколько версий NR-U поддерживает второй блок 502 вместе с какими одной или несколькими версиями NR-U, которые поддерживают один или более других вторых блоков 502.
Вариант 20 осуществления. Второй блок 502 согласно варианту 8 осуществления, в котором первый блок 501 выполнен с возможностью представления центральным блоком (CU), и второй блок 502 выполнен с возможностью представления распределенным блоком (DU).
Вариант 21 осуществления. Второй блок 502 согласно варианту 8 осуществления, в котором первый блок 501 выполнен с возможностью представления частью плоскости управления центрального блока (CU-CP), и второй блок 502 выполнен с возможностью представления любым из распределенного блока (DU) части плоскости пользователя централизованного блока (CU-UP).
Вариант 22 осуществления. Второй блок 502 согласно варианту 8 осуществления, в котором первый блок 501 выполнен с возможностью представления главным узлом, и второй блок 502 выполнен с возможностью представления вторичным узлом.
Вариант 23 осуществления. Первый блок 501, предназначенный для обработки соединения, такого как предстоящее соединение между первым блоком 501 и многочисленными вторыми блоками 502 в сети 100 беспроводной связи, причем первый блок 501 содержит процессор 1540 и память 1550, содержащую инструкции, исполняемые процессором, при этом первый блок 501 выполнен с возможностью:
получения, из каждого из многочисленных вторых блоков, соответствующего указания того, какие одну или несколько версий протокола плоскости пользователя NR (NR-U) он поддерживает, и
принятия решения относительно того, какую версию NR-U можно использовать для соединения на основе указаний, принятых из многочисленных вторых блоков 502.
Вариант 24 осуществления. Первый блок 501 согласно варианту 23 осуществления, в котором первый блок 501 выполнен с возможностью представления центральным блоком (CU), и многочисленные вторые блоки 502 выполнены с возможностью представления одним или более распределенными блоками (DU).
Вариант 25 осуществления. Первый блок 501 согласно варианту 23 осуществления, в котором первый блок 501 выполнен с возможностью представления частью плоскости управления централизованного блока (CU-CP), и многочисленные вторые блоки 502 выполнены с возможностью представления частью плоскости пользователя центрального блока (CU-UP) и одним или более распределенными блоками (DU).
Вариант 26 осуществления. Первый блок 501 согласно варианту 23, в котором первый блок 501 выполнен с возможностью представления главным узлом, и многочисленные вторые блоки 502 представлены многочисленными вторичными узлами.
Вариант 27 осуществления. Первый блок 501 согласно любому из вариантов 23-26 осуществления, в котором первый блок 501 дополнительно выполнен с возможностью:
отправки, в каждый из соответствующих многочисленных вторых блоков 502, указания выбранной версии NR-U, которую можно использовать для соединения.
Вариант 28 осуществления. Второй блок 502 для обработки соединения, такого как предстоящее соединение между первым блоком 501, блоком принятия решения и многочисленными вторыми блоками 502 в сети 100 беспроводной связи, причем второй блок 502 содержит процессор 1630 и память 1640, содержащую инструкции, исполняемые процессором, при этом второй блок 502 выполнен с возможностью:
отправки, в первый блок 501, указания того, какие одну или несколько версий протокола плоскости пользователя NR (NR-U) поддерживает второй блок, и
приема, из первого блока 501, указания выбранной версии NR-U, которую можно использовать для соединения, причем версия NR-U определяется на основе отправленного указания того, какие одна или несколько версий NR-U поддерживает второй блок 502 вместе с какими одной или несколькими версиями NR-U, которые поддерживает один или более других вторых блоков 502.
Вариант 29 осуществления. Второй блок 502 согласно варианту 28 осуществления, в котором первый блок 501 выполнен с возможностью представления центральным блоком (CU), и второй блок 502 выполнен с возможностью представления распределенным блоком (DU).
Вариант 30 осуществления. Второй блок 502 согласно варианту 28 осуществления, в котором первый блок 501 выполнен с возможностью представления частью плоскости управления центрального блока (CU-CP), и второй блок 502 выполнен с возможностью представления любым распределенным блоком (DU) части плоскости пользователя централизованного блока (CU-UP).
Вариант 31 осуществления. Второй блок 502 в соответствии с вариантом 28 осуществления, в котором первый блок 501 выполнен с возможностью представления главным узлом, и второй блок 502 выполнен с возможностью представления вторичным узлом.
Со ссылкой на фиг.17, в соответствии с вариантом осуществления, система связи включает в себя телекоммуникационную сеть 3210, такую как сотовая сеть типа 3GPP, которая содержит сеть 3211 доступа, такую как сеть радиодоступа, и базовую сеть 3214. Сеть 3211 доступа содержит множество базовых станций 3212a, 3212b, 3212c, таких как первый блок 501 и второй блок 502, NB STA с AP, eNB, gNB или другие типы точек беспроводного доступа, каждая из которых определяет соответствующую зону 3213a, 3213b, 3213c покрытия. Каждая базовая станция 3212a, 3212b, 3212c может подключаться к базовой сети 3214 через проводное или беспроводное соединение 3215. Первое пользовательское оборудование (UE), такое как STA 3291 без точки доступа, расположенное в зоне 3213c покрытия, выполнено с возможностью беспроводного подключения (или поискового вызова) к соответствующей базовой станции 3212c. Второе UE 3292, такое как STA без AP, в зоне 3213a обслуживания, может выполнить беспроводное подключение к соответствующей базовой станции 3212a. Хотя в этом примере проиллюстрировано множество UE 3291, 3292, раскрытые варианты осуществления в равной степени применимы к ситуации, когда одиночное UE находится в зоне покрытия, или когда одиночное UE подключается к соответствующей базовой станции 3212.
Телекоммуникационная сеть 3210 подключена непосредственно к хост-компьютеру 3230, который может быть реализован в виде аппаратных средств и/или программного обеспечения автономного сервера, сервера, реализованного в облаке, распределенного сервера или в виде ресурсов обработки в ферме серверов. Хост-компьютер 3230 может находиться в собственности или под управлением поставщика услуг или может управляться поставщиком услуг или от имени поставщика услуг. Соединения 3221 и 3222 между телекоммуникационной сетью 3210 и хост-компьютером 3230 могут продолжаться непосредственно от базовой сети 3214 до хост-компьютера 3230 или могут проходить через вспомогательную промежуточную сеть 3220. Промежуточная сеть 3220 может представлять собой одну или комбинацию из более чем одной: общедоступной, частной или развернутой сети; промежуточной сети 3220, если таковая имеется, может представлять собой магистральную сеть или Интернет; в частности, промежуточная сеть 3220 может содержать две или более подсетей (не показаны).
Система связи, показанная на фиг.17, в целом обеспечивает связность между подключенными UE 3291, 3292 и хост-компьютером 3230. Связность может быть описана как соединение 3250 поверх протокола IP (OTT). Хост-компьютер 3230 и подключенные UE 3291, 3292 выполнены с возможностью передачи данных и/или сигнализации через OTT-соединение 3250, используя сеть 3211 доступа, базовую сеть 3214, любую промежуточную сеть 3220 и возможную дополнительную инфраструктуру (не показана) в качестве посредников. OTT-соединение 3250 может быть прозрачным в том смысле, что участвующие устройства связи, через которые проходит OTT-соединение 3250, не знают о маршрутизации передач по восходящей и нисходящей линиям связи. Например, базовая станция 3212 может не знать или не нуждаться в информации о прошлой маршрутизации входящей передачи по нисходящей линии связи с данными, исходящими из хост-компьютера 3230, которые должны пересылаться (например, при передаче обслуживания) в подключенное UE 3291. Аналогичным образом, базовой станции 3212 не нужно знать о будущей маршрутизации исходящей передачи по восходящей линии связи, исходящей от UE 3291 в направлении хост-компьютера 3230.
Примерные реализации, в соответствии с вариантом осуществления, UE, базовой станции и хост-компьютера, обсужденные в предыдущих абзацах, будут теперь описаны со ссылкой на фиг.18. В системе 3300 связи хост-компьютер 3310 содержит аппаратные средства 3315, включая интерфейс 3316 связи, выполненный с возможностью установления и поддержания проводного или беспроводного соединения с интерфейсом другого устройства связи системы 3300 связи. Хост-компьютер 3310 дополнительно содержит схему 3318 обработки, которая может иметь возможности хранения и/или обработки. В частности, схема 3318 обработки может содержать один или более программируемых процессоров, специализированных интегральных схем, программируемых вентильных матриц или их комбинации (не показаны), которые предназначены для исполнения инструкций. Хост-компьютер 3310 дополнительно содержит программное обеспечение 3311, которое хранится в хост-компьютере 3310 или доступно для него и исполняется схемой 3318 обработки. Программное обеспечение 3311 включает в себя хост-приложение 3312. Хост-приложение 3312 может быть выполнено с возможностью предоставления услуги удаленному пользователю, такому как UE 3330, устанавливающему соединение через OTT-соединение 3350, которое заканчивается в UE 3330 и хост-компьютере 3310. При предоставлении услуги удаленному пользователю хост-приложение 3312 может предоставлять пользовательские данные, которые передаются с использованием OTT-соединения 3350.
Система 3300 связи дополнительно включает в себя базовую станцию 3320, предусмотренную в телекоммуникационной системе и содержащую аппаратные средства 3325, позволяющие ей обмениваться данными с хост-компьютером 3310 и с UE 3330. Аппаратные средства 3325 могут включать в себя интерфейс 3326 связи для установки и поддержания проводного или беспроводного соединения с интерфейсом другого устройства связи системы 3300 связи, а также радиоинтерфейс 3327 для установки и поддержания по меньшей мере беспроводного соединения 3370 с UE 3330, расположенным в зоне покрытия (не показана на фиг.18), обслуживаемой базовой станцией 3320. Интерфейс 3326 связи может быть выполнен с возможностью упрощения соединения 3360 с хост-компьютером 3310. Соединение 3360 может быть прямым, или оно может проходить через базовую сеть (не показана на фиг.18) телекоммуникационной системы и/или через одну или несколько промежуточных сетей вне телекоммуникационной системы. В показанном варианте осуществления аппаратные средства 3325 базовой станции 3320 дополнительно включают в себя схему 3328 обработки, которая может содержать один или несколько программируемых процессоров, специализированных интегральных схем, программируемых пользователем вентильных матриц или их комбинации (не показаны), выполненные с возможностью исполнения инструкций. Базовая станция 3320 дополнительно имеет программное обеспечение 3321, хранящееся внутри нее или доступное через внешнее соединение.
Система 3300 связи дополнительно включает в себя уже упомянутое UE 3330. Его аппаратные средства 3335 могут включать в себя радиоинтерфейс 3337, выполненный с возможностью установки и поддержания беспроводного соединения 3370 с базовой станцией, обслуживающей зону покрытия, в которой на данный момент находится UE 3330. Аппаратные средства 3335 UE 3330 дополнительно включают в себя схему 3338 обработки, которая может содержать один или несколько программируемых процессоров, специализированные интегральные схемы, программируемые пользователем вентильные матрицы или их комбинации (не показаны), выполненных с возможностью исполнения инструкций. UE 3330 дополнительно содержит программное обеспечение 3331, которое хранится в UE 3330 или доступно для него и может исполняться схемой 3338 обработки. Программное обеспечение 3331 включает в себя клиентское приложение 3332. Клиентское приложение 3332 может быть выполнено с возможностью предоставлять услугу пользователю-человеку или пользователю-не человеку через UE 3330, с поддержкой хост-компьютера 3310. В хост-компьютере 3310 исполняющее хост-приложение 3312 может поддерживать связь с исполняющимся клиентским приложением 3332 через OTT-соединение 3350, оканчивающееся в UE 3330 и хост-компьютере 3310. При предоставлении услуги пользователю, клиентское приложение 3332 может принимать данные запроса из хост-приложения 3312 и предоставлять пользовательские данные в ответ на данные запроса. OTT-соединение 3350 может передавать как данные запроса, так и данные пользователя. Клиентское приложение 3332 может взаимодействовать с пользователем для выработки пользовательских данных, которые оно предоставляет.
Следует отметить, что хост-компьютер 3310, базовая станция 3320 и UE 3330, показанные на фиг.18, могут быть аналогичны или идентичны хост-компьютеру 3230, одной из базовых станций 3212a, 3212b, 3212c и одному из UE 3291, 3292, которые показаны на фиг.17, соответственно. То есть внутренняя работа этих объектов может быть такой, как показано на фиг.18, и независимо от этого топология окружающей сети может быть такой же, как на фиг.17.
На фиг.18 ОТТ-соединение 3350 было изображено абстрактно для иллюстрации связи между хост-компьютером 3310 и UE 3330 через базовую станцию 3320 без явной ссылки на какие-либо промежуточные устройства и точной маршрутизации сообщений через эти устройства. Сетевая инфраструктура может определять маршрутизацию, которую она может конфигурировать, чтобы скрыть ее от UE 3330 или от поставщика услуг, управляющего хост-компьютером 3310, или от обоих. Когда OTT-соединение 3350 является активным, сетевая инфраструктура может дополнительно принимать решения, с помощью которых оно динамически изменяет маршрутизацию (например, на основе рассмотрения балансировки нагрузки или реконфигурирования сети).
Беспроводное соединение 3370 между UE 3330 и базовой станцией 3320 соответствует идеям вариантов осуществления, описанным в настоящем раскрытии. Один или несколько из различных вариантов осуществления позволяют повысить производительность OTT-услуг, предоставляемых UE 3330, используя OTT-соединение 3350, в котором беспроводное соединение 3370 образует последний сегмент. Более точно, идеи этих вариантов осуществления позволяют улучшить [выбрать применимый эффект RAN: скорость передачи данных, задержка, энергопотребление] и, таким образом, обеспечить такие преимущества, как сокращение времени ожидания пользователя, ослабление ограничений на размер файла, лучшее время отклика, увеличенный срок службы аккумуляторной батареи.
Процедура измерения может выполняться с целью контроля скорости передачи данных, задержки и других показателей, которые улучшают один или несколько вариантов осуществления. Кроме того, может существовать дополнительные сетевые функциональные возможности для реконфигурирования OTT-соединения 3350 между хост-компьютером 3310 и UE 3330 в ответ на изменения результатов измерений. Процедура измерения и/или сетевые функциональные возможности для реконфигурирования OTT-соединения 3350 могут быть реализованы в виде программного обеспечения 3311 и аппаратных средств 3315 хост-компьютера 3310, или в виде программного обеспечения 3331 и аппаратных средств 3335 UE 3330 или и того и другого. В вариантах осуществления датчики (не показаны) могут быть развернуты в или в связи с устройствами связи, через которые проходит OTT-соединение 3350; датчики могут участвовать в процедуре измерения, предоставляя значения контролируемых величин, приведенных в качестве примера выше, или предоставляя значения других физических величин, на основе которых программное обеспечение 3311, 3331 может вычислить или оценить контролируемые величины. Реконфигурирование OTT-соединения 3350 может включать в себя формат сообщения, настройки повторной передачи, предпочтительную маршрутизацию и т.д.; реконфигурирование не должно влиять на базовую станцию 3320, и оно может быть неизвестным или незаметным для базовой станции 3320. Такие процедуры и функциональные возможности известны и могут быть осуществлены в данной области техники. В некоторых вариантах осуществления измерения могут включать в себя собственную сигнализацию UE, облегчающую измерения, проводимые хост-компьютером 3310, пропускной способности, времени распространения, задержки и т.п. Измерения могут быть реализованы таким образом, чтобы программное обеспечение 3311 и 3331 заставляло передавать сообщения, в частности пустые или "фиктивные" сообщения с использованием OTT-соединения 3350, контролируя при этом время распространения, ошибки и т.д.
На фиг.19 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи, в соответствии с одним вариантом осуществления. Система связи включает в себя хост-компьютер, базовую станцию, такую как STA с AP, и UE, например STA без AP, которые могут быть такими, которые описаны со ссылкой на фиг.17 и фиг.18. Для упрощения настоящего раскрытия в этот раздел будут включены только ссылки на фиг.19. На первом этапе 3410 способа хост-компьютер предоставляет данные пользователя. На необязательном подэтапе 3411 первого этапа 3410 хост-компьютер предоставляет данные пользователя, исполняя хост-приложение. На втором этапе 3420 хост-компьютер инициирует передачу пользовательских данных в UE. На необязательном третьем этапе 3430 базовая станция передает в UE пользовательские данные, которые были переданы при передаче, инициированной хост-компьютером, в соответствии с идеями вариантов осуществления, описанными в настоящем раскрытии. На необязательном четвертом этапе 3440 UE исполняет клиентское приложение, ассоциированное с хост-приложением, исполняемым хост-компьютером.
На фиг.20 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи, в соответствии с одним вариантом осуществления. Система связи включает в себя хост-компьютер, базовую станцию, такую как STA с AP, и UE, например STA без AP, которые могут быть такими, которые описаны со ссылкой на фиг.17 и фиг.18. Для упрощения настоящего раскрытия в этот раздел будут включены только ссылки на фиг.20. На первом этапе 3510 способа хост-компьютер предоставляет данные пользователя. На необязательном подэтапе (не показан) хост-компьютер предоставляет данные пользователя, исполняя хост-приложение. На втором этапе 3520 хост-компьютер инициирует передачу пользовательских данных в UE. Передача может проходить через базовую станцию в соответствии с идеями вариантов осуществления, описанными в настоящем раскрытии. На необязательном третьем этапе 3530 UE принимает пользовательские данные, переносимые при передаче.
На фиг.21 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи, в соответствии с одним вариантом осуществления. Система связи включает в себя хост-компьютер, базовую станцию, такую как STA с AP, и UE, например STA без AP, которые могут быть такими, которые описаны со ссылкой на фиг.17 и фиг.18. Для упрощения настоящего раскрытия в этот раздел будут включены только ссылки на фиг.21. На необязательном первом этапе 3610 способа UE принимает входные данные, предоставленные хост-компьютером. Дополнительно или альтернативно, на необязательном втором этапе 3620 UE предоставляет данные пользователя. На необязательном подэтапе 3621 второго этапа 3620 UE предоставляет пользовательские данные, исполняя клиентское приложение. На дополнительном необязательном подэтапе 3611 первого этапа 3610 UE исполняет клиентское приложение, которое предоставляет данные пользователя в ответ на принятые входные данные, предоставленные хост-компьютером. При предоставлении пользовательских данных исполняемое клиентское приложение может дополнительно учитывать пользовательский ввод, полученный от пользователя. Независимо от конкретного способа предоставления пользовательских данных, UE инициирует на необязательном третьем подэтапе 3630 передачу пользовательских данных в хост-компьютер. На четвертом этапе 3640 способа хост-компьютер принимает данные пользователя, переданные из UE, в соответствии с идеями вариантов осуществления, описанными в настоящем раскрытии.
На фиг.21 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи, в соответствии с одним вариантом осуществления. Система связи включает в себя хост-компьютер, базовую станцию, такую как STA с AP, и UE, например STA без AP, которые могут быть такими, которые описаны со ссылкой на фиг.17 и фиг.18. Для упрощения настоящего раскрытия в этот раздел будут включены только ссылки на фиг.21. На необязательном первом этапе 3710 способа в соответствии с идеями вариантов осуществления, описанными в настоящем раскрытии, базовая станция принимает пользовательские данные из UE. На необязательном втором этапе 3720 базовая станция инициирует передачу принятых пользовательских данных в хост-компьютер. На третьем этапе 3730 хост-компьютер принимает пользовательские данные, переносимые при передаче, инициированной базовой станцией.
Перечень сокращений
CU – центральный блок
DC – двойная связность
DU – децентрализованный блок
GTP-U – протокол туннелирования GPRS в плоскости пользователя
MC – мультисвязность
NGC – ядро нового поколения
NR – новое радио
UE – пользовательское оборудование