ОБЛАСТЬ ТЕХНИКИ
Конкретные варианты осуществления ориентированы на беспроводную связь, а конкретнее, на отображение потока качества обслуживания (QoS) пятого поколения (5G) Проекта партнерства третьего поколения (3GPP) в несущий радиоканал данных (DRB).
ВВЕДЕНИЕ
Проект партнерства третьего поколения (3GPP) задает стандартизацию беспроводной сети пятого поколения (5G), которая включает в себя отображение потока качества обслуживания (QoS) в несущий радиоканал данных (DRB). Также в этом документе описан уровень техники, связанный с развитой пакетной системой (EPS) (то есть системой долгосрочного развития (LTE)/развитой универсальной наземной сетью доступа (E-UTRAN)) и развитым пакетным ядром (EPC), потому что некоторые понятия 5G могут основываться на понятиях EPC, связанных с EPS аспектах архитектуры, передаче обслуживания между eNB и двойном подключении (DC) LTE.
TS 23.799 v14.0.0 3GPP включает в себя спецификации для нового радиоинтерфейса, называемого NR (или 5G, или G-UTRA), и пакетной базовой сети следующего поколения (NG-CN или NGC). Пример иллюстрируется на фиг. 1.
Фиг. 1 - блок-схема, иллюстрирующая высокоуровневую архитектуру сети следующего поколения. Фиг. 1 скопирована из фиг. 4.2.1-1 в TS 23.799 3GPP. Проиллюстрированные примеры включают в себя пользовательское оборудование (UE) следующего поколения (10), сеть радиодоступа (RAN) следующего поколения (20), ядро (30) следующего поколения, сеть (40) передачи данных и их опорные точки (то есть NG1, NG2, NG3 и NG6).
Опорная точка NG2 предназначена для плоскости управления между RAN (20) следующего поколения и ядром (30) следующего поколения. Опорная точка NG3 предназначена для плоскости пользователя между RAN (20) следующего поколения и ядром (30) следующего поколения. Опорная точка NG1 (см. фиг. 4) предназначена для плоскости управления между UE (10) следующего поколения и ядром (30) следующего поколения. Опорная точка NG6 предназначена для связи между ядром (30) следующего поколения и сетью (40) передачи данных. Сеть (40) передачи данных может быть выполнена в виде внешней общедоступной или частной сети передачи данных оператора либо внутренней сети передачи данных оператора (например, для предоставления услуг мультимедийной подсистемы на основе IP (IMS)). N6 соответствует SGi для доступов 3GPP.
RAN следующего поколения включает в себя базовые станции, которые поддерживают радиодоступ развитой LTE и/или NR. Пример иллюстрируется на фиг. 2.
Фиг. 2 - блок-схема, иллюстрирующая архитектуру новой RAN из TR 38.801 V1.0.0 3GPP. Новая RAN включает в себя два следующих логических узла. gNB предоставляет выходы протоколов U-плоскости и C-плоскости NR к UE. eNB eLTE предоставляет выходы протоколов U-плоскости и C-плоскости E-UTRA к UE.
Логические узлы в новой RAN взаимосвязаны друг с другом интерфейсом Xn (который может задаваться как развитие интерфейса X2). Логические узлы в новой RAN подключаются к NGC по интерфейсу NG (также называемому NG2 для интерфейса плоскости управления между новой RAN и NGC и NG3 для плоскости пользователя между новой RAN и NGC). Интерфейс NG поддерживает отношение "многие ко многим" между NG-CP/UPGW и логическими узлами в новой RAN.
Фиг. 3 - блок-схема, иллюстрирующая архитектуру протокола новой RAN. Уровни протокола включают в себя протокол конвергенции пакетных данных (PDCP), протокол управления радиосвязью (RLC) и протокол управления доступом к среде передачи (MAC).
Фиг. 4 - блок-схема, иллюстрирующая общую архитектуру системы 5G. Фиг. 4 скопирована из фиг. 8.12.2-2 в TS 23.799 v14.0.0 3GPP, и там дополнительно описываются различные функции проиллюстрированных узлов.
Варианты использования расширенной подключаемости, предусмотренные сетями 5G, например улучшенная мобильная широкополосная связь (eMBB), массовая связь машинного типа (MTC) и надежная связь со сверхмалой задержкой (ULLRC), включают в себя требования дифференцирования обслуживания к инфраструктуре качества обслуживания (QoS), чтобы обеспечить приоритетное и предсказуемое поведение для услуги подключаемости. Инфраструктура QoS 5G включает в себя ограничения, связанные с ограниченным числом одновременно активных несущих радиоканалов и улучшенным описанием обработки данных по сети подключения. Кроме того, 5G включает в себя более четкое разделение вопросов между классификацией услуг и описанием обработки в базовой сети и принуждение обработки выполнять цели QoS в RAN. Требования включают в себя инфраструктуру QoS на основе модели QoS потока протокольных блоков данных (PDU) и отказ от взаимно-однозначного соответствия между несущими радиоканалами развитой пакетной системы (EPS) и несущими радиоканалами данных (DRB).
Сеанс PDU задается в виде ассоциации между UE и сетью передачи данных, которая предоставляет услугу подключаемости PDU. Тип ассоциации включает в себя IP-тип, Ethernet-тип и тип без IP. Каждый сеанс PDU ассоциируется с одним интерфейсом NG3. Когда один и тот же сеанс PDU подключается к нескольким локальным сетям/сетям передачи данных, которые также требуют подключения к интерфейсу NG9, будет по одному экземпляру NG3 и NG9 на сеанс PDU.
Модель QoS 5G поддерживает инфраструктуру на основе потока QoS. Модель QoS 5G поддерживает как потоки QoS, которые требуют гарантированной скорости передачи битов потока, так и потоки QoS, которые не требуют гарантированной скорости передачи битов потока. Поток QoS 5G является самой мелкой степенью разбиения потока PDU, которую можно различить для обработки по перенаправлению QoS в системе. Трафик плоскости пользователя с одинаковым значением маркировки плоскости пользователя (NG3) в рамках сеанса PDU соответствует потоку QoS 5G. Маркировка плоскости пользователя для QoS переносится в инкапсулирующем заголовке в NG3 (то есть без каких-либо изменений в сквозном (e2e) заголовке пакета). Инкапсулирующий заголовок может применяться к блокам PDU с разными типами полезной нагрузки (то есть IP-пакеты, блоки PDU без IP и кадры Ethernet).
Два типа маркировки QoS включают в себя маркировку QoS типа A и маркировку QoS типа B. Маркировка QoS типа A является маркировкой плоскости пользователя, отправленной по NG3 (ID потока QoS 5G (5QI)) со стандартизованными характеристиками QoS 5G. Маркировка QoS типа B является маркировкой плоскости пользователя, отправленной по NG3 (5QI) с характеристиками QoS 5G, сигнализируемыми динамически по NG2 от CN NG к RAN NG.
Профиль QoS состоит из маркировки плоскости пользователя (5QI) и соответствующих характеристик QoS 5G. Правило QoS состоит из профиля QoS, фильтров пакетов и порядка предшествования. Профиль QoS в правилах QoS (включая предварительно санкционированные) предоставляется (R)AN по NG2, предоставленному при установлении сеанса PDU, и каждый раз, когда UE переключается из свободного в подключенный режим, для сеансов PDU, которые возобновляются выборочно.
Сеть может предоставить UE правило QoS по умолчанию при установлении сеанса PDU. К тому же UE можно предоставить предварительно санкционированные правила QoS. Сеть также может указывать, применяется ли отражающее QoS к потоку QoS 5G, в 5QI с диапазоном значений типа B.
Нижеследующие характеристики применяются для обработки трафика нисходящей линии связи. Основная функция плоскости пользователя (UPF) отображает поток данных услуги (SDF) в потоки QoS. Основная UPF выполняет принудительное применение групповой максимальной скорости передачи битов (AMBR) на каждый сеанс PDU, а также выполняет подсчет для поддержки тарификации. Основная UPF передает блоки PDU из сеанса PDU в одном туннеле и включает маркировку плоскости пользователя (5QI) в инкапсулирующий заголовок. К тому же основная UPF может включить указание для активации отражающего QoS в инкапсулирующий заголовок. (R)AN отображает блоки PDU из потоков QoS 5G в характерные для доступа ресурсы на основе 5QI и соответствующих характеристик QoS, также учитывая туннель NG3, ассоциированный с пакетом нисходящей линии связи. Фильтры пакетов не используются для привязки потоков QoS 5G к характерным для доступа ресурсам в (R)AN. Если применяется отражающее QoS, то UE создает новое выведенное правило QoS. Фильтр пакетов в выведенном правиле QoS выводится из пакета нисходящей линии связи (то есть заголовка пакета нисходящей линии связи).
Нижеследующие характеристики применяются для обработки трафика восходящей линии связи. UE использует сохраненные правила QoS для определения отображения между SDF и потоком QoS 5G и между потоком QoS 5G и характерным для доступа ресурсом. UE передает блоки PDU восходящей линии связи с использованием соответствующего характерного для доступа ресурса, определенного по правилу QoS. (R)AN передает блоки PDU по туннелю N3 к основной UPF. При передаче пакета восходящей линии связи от (R)AN к CN (R)AN определяет 5QI и выбирает туннель N3 на основе информации, принятой с уровня, связанного с предоставлением доступа (AS). UPF выполняет принудительное применение AMBR на каждый сеанс PDU и подсчет пакетов для тарификации.
AMBR на каждый сеанс PDU может принудительно применяться в основной UPF. Для сеансов PDU более чем с одним интерфейсом NG6 (сеанс PDU CL восходящей линии связи, групповой сеанс PDU) AMBR принудительно применяется в основной UPF, которая поддерживает CL восходящей линии связи или функциональные возможности точки ветвления. (R)AN может навязать ограничение максимальной скорости передачи битов (MBR) на восходящей линии связи и нисходящей линии связи по каждому UE для потоков, которые не требуют гарантированной скорости передачи битов потока. UE выполняет ограничение скорости восходящей линии связи на основе сеанса PDU для трафика без гарантированной скорости передачи битов (без GBR) и на основе потока QoS 5G для трафика с гарантированной скоростью передачи битов (GBR).
Принудительное применение ограничения скорости на каждый сеанс PDU применяется для потоков, которые не требуют GBR. MBR на каждый SDF обязательна для потоков GBR, но необязательна для потоков без GBR. Она принудительно применяется в UPF.
Развитая пакетная система (EPS) является развитой областью 3GPP с коммутацией пакетов и состоит из развитого пакетного ядра (EPC) и развитой универсальной наземной сети радиодоступа (E-UTRAN). Пример иллюстрируется на фиг. 5.
Фиг. 5 - блок-схема, иллюстрирующая общее представление архитектуры развитого пакетного ядра (EPC). Точнее говоря, проиллюстрированный пример является архитектурой без роуминга для доступов 3GPP. В TS 23.401 3GPP можно найти подробное описание PGW (шлюз PDN), SGW (обслуживающий шлюз), PCRF (функция политики и правил тарификации), MME (объект управления мобильностью) и мобильного устройства (UE). Радиодоступ LTE, E-UTRAN, состоит из одного или нескольких eNB.
Фиг. 6 - блок-схема, иллюстрирующая примерную архитектуру E-UTRAN. Компоненты фиг. 6 подробно описываются в TS 36.300 3GPP. E-UTRAN состоит из eNB, который предоставляет выходы протоколов плоскости пользователя E-UTRA (PDCP/RLC/MAC/PHY) и плоскости управления (RRC в дополнение к протоколам плоскости пользователя) к UE. eNB взаимосвязаны друг с другом посредством интерфейса X2. eNB также подключаются посредством интерфейса S1 к EPC (развитое пакетное ядро), точнее говоря, к MME (объект управления мобильностью) посредством интерфейса S1-MME, и к обслуживающему шлюзу (S-GW) посредством интерфейса S1-U. Основные части архитектур плоскости управления (CP) и плоскости пользователя (UP) EPC показаны на фиг. 7 и 8.
Фиг. 7 - блок-схема, иллюстрирующая архитектуру протокола плоскости управления EPC. Проиллюстрированный пример включает в себя стеки протоколов плоскости управления в UE, eNB, MME, S-GW и PDN-GW.
Фиг. 8 - блок-схема, иллюстрирующая архитектуру протокола плоскости пользователя EPC. Проиллюстрированный пример включает в себя стеки протоколов плоскости пользователя в UE, eNB, S-GW и PDN-GW.
Фиг. 9 - блок-схема, иллюстрирующая структуру протокола интерфейса X2. Структура интерфейса X2 подробно описывается в TS 36.420 V13.0.0 3GPP.
Фиг. 10A и 10B - логическая блок-схема, иллюстрирующая поток сигнализации для передачи обслуживания между eNB. В проиллюстрированном примере MME и обслуживающий шлюз не меняются во время передачи обслуживания. Поток сигнализации подробнее описывается в TS 36.300 v14.1.0 3GPP.
Этапы 4-8 особенно релевантны для вариантов осуществления, описанных ниже в ПОДРОБНОМ ОПИСАНИИ. Передача обслуживания инициируется исходным eNB, отправляющим в целевой eNB сообщение с запросом передачи обслуживания, передающее необходимую информацию для подготовки к передаче обслуживания (HO) на целевой стороне (этап 4). Передаваемая информация включает в себя профили QoS у E-RAB на стороне исходного eNB (и дополнительную информацию). Целевой eNB конфигурирует необходимые ресурсы в соответствии с принятой информацией QoS E-RAB (этап 5).
На этапе 6 целевой eNB готовит HO с L1/L2 и отправляет исходному eNB подтверждение приема запроса передачи обслуживания. Сообщение с подтверждением приема запроса передачи обслуживания включает в себя прозрачный контейнер для его отправки к UE в виде сообщения RRC, чтобы выполнить передачу обслуживания. Сообщение с подтверждением приема запроса передачи обслуживания также может включать в себя информацию RNL/TNL для туннелей перенаправления данных плоскости пользователя.
После того, как сообщение с подтверждением приема запроса передачи обслуживания принимается на стороне исходного eNB, можно инициировать перенаправление данных плоскости пользователя к целевому eNB. Целевой eNB формирует сообщение RRC для выполнения передачи обслуживания (то есть сообщение RRCConnectionReconfiguration, включающее mobilityControlInformation), которое исходному eNB нужно отправить к UE (этап 7). UE принимает сообщение RRCConnectionReconfiguration с необходимыми параметрами и управляется исходным eNB для выполнения HO.
На этапе 8 исходный eNB отправляет сообщение переноса состояния SN целевому eNB для передачи состояния приемника порядкового номера (SN) PDCP восходящей линии связи и состояния передатчика SN PDCP нисходящей линии связи у E-RAB, для которых применяется сохранение состояния PDCP (то есть для AM RLC). Состояние приемника SN PDCP восходящей линии связи включает в себя по меньшей мере SN PDCP у первого отсутствующего сервисного блока данных (SDU) восходящей линии связи и может включать в себя битовый массив состояния приема непоследовательных блоков SDU восходящей линии связи, которые UE нужно повторно передать в целевой соте, если есть какие-нибудь такие блоки SDU. Состояние передатчика SN PDCP нисходящей линии связи указывает следующий SN PDCP, который целевой eNB назначит новым блокам SDU, у которых еще нет SN PDCP.
Перенаправление данных между исходным eNB и целевым eNB основывается на следующих принципах. Туннели U-плоскости можно устанавливать между исходным eNB и целевым eNB во время подготовки к передаче обслуживания, как описано выше. Один туннель можно установить для перенаправления данных восходящей линии связи, а другой - для перенаправления данных нисходящей линии связи для каждого E-RAB, для которого применяется перенаправление данных. Пользовательские данные могут перенаправляться от исходного eNB к целевому eNB во время исполнения передачи обслуживания. Перенаправление пользовательских данных нисходящей линии связи от исходного к целевому eNB происходит в течение всего времени, пока пакеты принимаются на исходном eNB от EPC, или пока не опустошен буфер исходного eNB.
После того, как завершается передача обслуживания, целевой eNB отправляет в MME сообщение переключения тракта для информирования MME, что UE получило доступ, и MME отправляет обслуживающему шлюзу сообщение с запросом изменения несущего радиоканала. Тракт U-плоскости переключается обслуживающим шлюзом с исходного eNB на целевой eNB. Исходный eNB продолжает перенаправление данных U-плоскости при условии, что пакеты принимаются на исходном eNB от обслуживающего шлюза, или не опустошен буфер исходного eNB. Обслуживающий шлюз также может отправить исходному eNB "маркер окончания" для указания о том, что данные U-плоскости нисходящей линии связи больше не будут отправляться исходному eNB. "Маркер окончания" также можно перенаправить от исходного eNB к целевому eNB, чтобы инициировать освобождение туннелей плоскости пользователя для перенаправления данных.
Перенаправление данных плоскости пользователя используется для несущих радиоканалов RLC-AM (подтвержденный режим). В случае, когда не выполняется полная (AS) конфигурация на стороне целевого eNB, применяются следующие принципы.
Для последовательной доставки и избегания дублирования SN PDCP сохраняется на основе несущего радиоканала, и исходный eNB информирует целевой eNB о следующем SN PDCP нисходящей линии связи, который нужно выделить пакету, у которого еще нет порядкового номера PDCP (либо от исходного eNB, либо от обслуживающего шлюза).
Для синхронизации безопасности также сохраняется номер гиперкадра (HFN), и исходный eNB предоставляет целевому эталонный HFN для восходящей линии связи и для нисходящей линии связи (то есть HFN и соответствующий SN).
На UE и целевом eNB необходим механизм на основе окон для обнаружения дублирования.
Возникновение дубликатов по радиоинтерфейсу в целевом eNB минимизируется посредством отчетности на основе SN PDCP в целевом eNB посредством UE. На восходящей линии связи отчетность при необходимости конфигурируется посредством eNB на основе несущего радиоканала, и UE начинает путем передачи тех отчетов, когда выделены ресурсы в целевом eNB. На нисходящей линии связи eNB вправе решать, когда и для каких несущих радиоканалов отправляется отчет, и UE не ждет отчета для возобновления передачи по восходящей линии связи.
Целевой eNB повторно передает и назначает приоритет всем блокам SDU PDCP нисходящей линии связи, перенаправленным исходным eNB (то есть целевой eNB отправляет данные с SN PDCP из X2 до отправки данных из S1), за исключением блоков SDU PDCP, прием которых был подтвержден UE посредством отчетности на основе SN PDCP.
UE повторно передает в целевом eNB все блоки SDU PDCP восходящей линии связи, начиная с первого SDU PDCP после последнего последовательно подтвержденного SDU PDCP (то есть самого старого SDU PDCP, который не подтвержден в RLC на источнике), за исключением блоков SDU PDCP, прием которых был подтвержден целевым eNB посредством отчетности на основе SN PDCP.
При передаче обслуживания исходный eNB перенаправляет обслуживающему шлюзу блоки SDU PDCP восходящей линии связи, успешно принятые последовательно до отправки целевому eNB сообщения переноса состояния. В тот момент исходный eNB прекращает доставку блоков SDU PDCP восходящей линии связи к S-GW и отбрасывает любые оставшиеся блоки PDU RLC восходящей линии связи. Затем исходный eNB может либо отбросить блоки SDU PDCP восходящей линии связи, принятые непоследовательно, если не было активировано перенаправление данных восходящей линии связи, либо перенаправить блоки SDU PDCP восходящей линии связи целевому eNB, если перенаправление данных восходящей линии связи было активировано.
LTE включает в себя признак, называемый двойным подключением (DC). DC LTE является решением, стандартизованным выпуском 12 3GPP, которое поддерживает UE, подключающиеся к нескольким несущим для отправки и/или приема данных одновременно по нескольким несущим. Больше подробностей можно найти в TS 36.300 3GPP.
E-UTRAN поддерживает работу DC, при помощи чего несколько Rx/Tx UE в RRC_CONNECTED конфигурируются для использования радиоресурсов, предоставленных двумя отдельными планировщиками, расположенными в двух eNB, подключенных по неидеальному транзитному соединению по интерфейсу X2 (см. TR 36.842 и TR 36.932). Общая архитектура E-UTRAN, описанная по отношению к фиг. 6, также применяется для DC. eNB, участвующие в DC для некоторого UE, могут брать на себя две разные роли. eNB может действовать либо в виде главного eNB (MeNB), либо в виде второстепенного eNB (SeNB). В DC UE подключается к одному MeNB и одному SeNB.
Архитектура радиопротокола, которую использует конкретный несущий радиоканал, зависит от того, как настраивается несущий радиоканал. Существует три типа несущих радиоканалов: несущий радиоканал MCG, несущий радиоканал SCG и раздельный несущий радиоканал. Пример иллюстрируется на фиг. 11.
Фиг. 11 иллюстрирует архитектуру радиопротокола для двойного подключения (DC). Проиллюстрированный пример включает в себя три типа несущих радиоканалов (то есть несущий радиоканал MCG, несущий радиоканал SCG и раздельный несущий радиоканал). RRC располагается в MeNB. SRB конфигурируются как тип несущего радиоканала MCG и поэтому используют только радиоресурсы MeNB. DC также можно описать как содержащий по меньшей мере один несущий радиоканал, сконфигурированный для использования радиоресурсов, предоставленных SeNB.
Сигнализация плоскости управления между eNB для DC выполняется с помощью сигнализации интерфейса X2. Сигнализация плоскости управления к MME выполняется с помощью сигнализации интерфейса S1.
Только одно соединение S1-MME существует для каждого UE DC между MeNB и MME. Каждый eNB управляет UE независимо (то есть предоставляет PCell некоторым UE, тогда как предоставляет другим SCell(ы) для SCG). Каждый eNB, участвующий в DC для некоторого UE, управляет его радиоресурсами и отвечает главным образом за распределение радиоресурсов его сот. Соответствующая координация между MeNB и SeNB выполняется с помощью сигнализации интерфейса X2.
Фиг. 12 иллюстрирует подключаемость плоскости управления у eNB, участвующих в DC для конкретного UE. S1-MME заканчивается в MeNB. MeNB и SeNB взаимосвязаны посредством X2-C.
Двойное подключение включает в себя две разные архитектуры плоскости пользователя. В одной архитектуре только S1-U заканчивается в MeNB, а данные плоскости пользователя передаются от MeNB к SeNB с использованием X2-U. Во второй архитектуре S1-U заканчивается в SeNB.
Фиг. 13 иллюстрирует варианты подключаемости плоскости пользователя у eNB, участвующих в DC для конкретного UE. Разные варианты несущих радиоканалов могут конфигурироваться с разными архитектурами плоскости пользователя. Подключаемость U-плоскости зависит от сконфигурированного варианта несущего радиоканала.
Для несущих радиоканалов MCG соединение S1-U для соответствующего несущего радиоканала (радиоканалов) с S-GW заканчивается в MeNB. SeNB не участвует в транспортировке данных плоскости пользователя для этого типа несущего радиоканала (радиоканалов) по Uu.
Для раздельных несущих радиоканалов соединение S1-U с S-GW заканчивается в MeNB. Данные PDCP передаются между MeNB и SeNB посредством X2-U. SeNB и MeNB участвуют в передаче данных этого типа несущего радиоканала по Uu.
Для несущих радиоканалов SCG SeNB подключается напрямую к S-GW посредством S1-U. MeNB не участвует в транспортировке данных плоскости пользователя для этого типа несущего радиоканала (радиоканалов) по Uu.
Если конфигурируются только MCG и раздельные несущие радиоканалы, то у SeNB нет выхода S1-U.
Процедура добавления SeNB инициируется MeNB и устанавливает контекст UE в SeNB, чтобы предоставить UE радиоресурсы от SeNB. Процедура используется для добавления по меньшей мере первой соты (PSCell) у SCG.
Фиг. 14 - логическая блок-схема, иллюстрирующая процедуру добавления SeNB. Этапы 7 и 8 (то есть перенос состояния SN и перенаправление данных) такие же, как описаны в отношении потока сигнализации передачи обслуживания между eNB на фиг. 10A.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Конкретные варианты осуществления включают в себя механизм для повторного отображения потока QoS 5G в DRB в отношении, например, передачи обслуживания между gNB. Описанные в этом документе варианты осуществления упрощают целевому узлу RAN в процедуре мобильности прием пользовательских данных от исходного узла RAN и доставку таких данных таким образом, что можно восстановить потерянные пакеты. Варианты осуществления также упрощают целевому узлу повторное использование той же конфигурации, что исходный узел использовал для отображения потоков данных в DRB.
В соответствии с некоторыми вариантами осуществления способ выполнения передачи обслуживания беспроводного устройства для использования в сетевом узле содержит: прием запроса передачи обслуживания от исходного сетевого узла; прием от исходного сетевого узла отображения потока качества обслуживания (QoS) в несущий радиоканал данных (DRB), которое использовалось исходным сетевым узлом перед передачей обслуживания; прием буферизованных протокольных блоков данных (PDU) протокола конвергенции пакетных данных (PDCP) от исходного сетевого узла; передачу принятых блоков PDU PDCP с использованием принятого отображения потока QoS в DRB; получение указания о том, что передача обслуживания завершена; определение нового отображения потока QoS в DRB; и активацию нового отображения потока QoS в DRB для передачи блоков PDU PDCP.
В конкретных вариантах осуществления прием отображения потока QoS в DRB от исходного сетевого узла содержит прием сигнализации передачи обслуживания по интерфейсу Xn или прием сигнализации передачи обслуживания через элемент базовой сети по интерфейсу S1 или NG.
В конкретных вариантах осуществления способ дополнительно содержит отправку исходному сетевому узлу нового отображения потока QoS в DRB. Способ может включать в себя прием отчетности о состоянии PDCP от беспроводного устройства. Новое отображение потока QoS в DRB для передачи блоков PDU PDCP можно активировать после завершения синхронизации принятых буферизованных блоков PDU PDCP.
В конкретных вариантах осуществления принятое отображение потока QoS в DRB содержит поднабор DRB, используемый на сетевом узле или на исходном сетевом узле.
В соответствии с некоторыми вариантами осуществления сетевой узел выполнен с возможностью осуществлять передачу обслуживания беспроводного устройства. Сетевой узел содержит схемы обработки, выполненные с возможностью: приема запроса передачи обслуживания от исходного сетевого узла; приема от исходного сетевого узла отображения потока QoS в DRB, которое использовалось исходным сетевым узлом перед передачей обслуживания; приема буферизованных блоков PDU PDCP от исходного сетевого узла; передачи принятых блоков PDU PDCP с использованием принятого отображения потока QoS в DRB; получения указания о том, что передача обслуживания завершена; определения нового отображения потока QoS в DRB; и активации нового отображения потока QoS в DRB для передачи блоков PDU PDCP.
В конкретных вариантах осуществления схемы обработки выполнены с возможностью приема отображения потока QoS в DRB от исходного сетевого узла путем приема сигнализации передачи обслуживания по интерфейсу Xn или приема сигнализации передачи обслуживания через элемент базовой сети по интерфейсу S1 или NG.
В конкретных вариантах осуществления схемы обработки дополнительно выполнены с возможностью отправки исходному сетевому узлу нового отображения потока QoS в DRB. Схемы обработки могут быть выполнены с возможностью приема отчетности о состоянии PDCP от беспроводного устройства. Новое отображение потока QoS в DRB для передачи блоков PDU PDCP можно активировать после завершения синхронизации принятых буферизованных блоков PDU PDCP.
В конкретных вариантах осуществления принятое отображение потока QoS в DRB содержит поднабор DRB, используемый на сетевом узле или на исходном сетевом узле.
В соответствии с некоторыми вариантами осуществления сетевой узел выполнен с возможностью осуществлять передачу обслуживания беспроводного устройства. Сетевой узел содержит модуль приема, модуль передачи и модуль определения. Модуль приема выполнен с возможностью: приема запроса передачи обслуживания от исходного сетевого узла; приема от исходного сетевого узла отображения потока QoS в DRB, которое использовалось исходным сетевым узлом перед передачей обслуживания; и приема буферизованных блоков PDU PDCP от исходного сетевого узла. Модуль передачи выполнен с возможностью передачи принятых блоков PDU PDCP с использованием принятого отображения потока QoS в DRB. Модуль приема дополнительно выполнен с возможностью получения указания о том, что передача обслуживания завершена. Модуль определения выполнен с возможностью определения нового отображения потока QoS в DRB и активации нового отображения потока QoS в DRB для передачи блоков PDU PDCP.
Также раскрывается компьютерный программный продукт. Компьютерный программный продукт содержит команды, сохраненные на постоянных машиночитаемых носителях, которые при исполнении процессором выполняют этапы: приема запроса передачи обслуживания от исходного сетевого узла; приема от исходного сетевого узла отображения потока качества обслуживания (QoS) в несущий радиоканал данных (DRB), которое использовалось исходным сетевым узлом перед передачей обслуживания; приема буферизованных протокольных блоков данных (PDU) протокола конвергенции пакетных данных (PDCP) от исходного сетевого узла; передачи принятых блоков PDU PDCP с использованием принятого отображения потока QoS в DRB; получения указания о том, что передача обслуживания завершена; определения нового отображения потока QoS в DRB; и активации нового отображения потока QoS в DRB для передачи блоков PDU PDCP.
Некоторые варианты осуществления из настоящего раскрытия изобретения могут обеспечивать одно или несколько технических преимуществ. Конкретные варианты осуществления гарантируют, по меньшей мере на периоды после процедуры передачи обслуживания, что потоки, обслуживание которых передается от исходного узла, будут обрабатываться в целевом узле с таким же QoS, как и в исходном узле. Конкретные варианты осуществления преодолевают проблему пакетов, перенаправленных исходным узлом, которые уже пронумерованы исходным узлом на уровне PDCP. Без конкретных вариантов осуществления такие пакеты могут ошибочно интерпретироваться целевым узлом, потому что целевой узел может рассматривать исходную нумерацию PDCP как применяемую к своему процессу нумерации.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Теперь для более полного понимания вариантов осуществления и их признаков и преимуществ обратимся к нижеследующему описанию в сочетании с прилагаемыми чертежами, на которых:
Фиг. 1 - блок-схема, иллюстрирующая высокоуровневую архитектуру сети следующего поколения;
Фиг. 2 - блок-схема, иллюстрирующая архитектуру новой RAN из TR 38.801 V1.0.0 3GPP;
Фиг. 3 - блок-схема, иллюстрирующая архитектуру протокола новой RAN;
Фиг. 4 - блок-схема, иллюстрирующая общую архитектуру системы 5G;
Фиг. 5 - блок-схема, иллюстрирующая общее представление архитектуры развитого пакетного ядра (EPC);
Фиг. 6 - блок-схема, иллюстрирующая примерную архитектуру E-UTRAN;
Фиг. 7 - блок-схема, иллюстрирующая архитектуру протокола плоскости управления EPC;
Фиг. 8 - блок-схема, иллюстрирующая архитектуру протокола плоскости пользователя EPC;
Фиг. 9 - блок-схема, иллюстрирующая структуру протокола интерфейса X2;
Фиг. 10A и 10B - логическая блок-схема, иллюстрирующая поток сигнализации для передачи обслуживания между eNB;
Фиг. 11 иллюстрирует архитектуру радиопротокола для двойного подключения (DC);
Фиг. 12 иллюстрирует подключаемость плоскости управления у eNB, участвующих в DC для конкретного UE;
Фиг. 13 иллюстрирует варианты подключаемости плоскости пользователя у eNB, участвующих в DC для конкретного UE;
Фиг. 14 - логическая блок-схема, иллюстрирующая процедуру добавления SeNB;
Фиг. 15 иллюстрирует примерную беспроводную сеть в соответствии с конкретным вариантом осуществления;
Фиг. 16 - блок-схема, иллюстрирующая конкретную архитектуру сети в соответствии с некоторыми вариантами осуществления;
Фиг. 17 - логическая блок-схема, иллюстрирующая примерную сигнализацию передачи обслуживания в соответствии с некоторыми вариантами осуществления;
Фиг. 18 - логическая блок-схема, иллюстрирующая другой пример сигнализации передачи обслуживания в соответствии с некоторыми вариантами осуществления;
Фиг. 19 - логическая блок-схема примерного способа в сетевом узле в соответствии с некоторыми вариантами осуществления;
Фиг. 20 - блок-схема, иллюстрирующая примерный вариант осуществления беспроводного устройства;
Фиг. 21A - блок-схема, иллюстрирующая примерный вариант осуществления сетевого узла; и
Фиг. 21B - блок-схема, иллюстрирующая примерные компоненты сетевого узла.
ПОДРОБНОЕ ОПИСАНИЕ
Как описано во ВВЕДЕНИИ, Проект партнерства третьего поколения (3GPP) задает стандартизацию беспроводной сети пятого поколения (5G), которая включает в себя отображение потока качества обслуживания (QoS) в несущий радиоканал данных (DRB). Новая модель QoS 5G основывается на логике сети радиодоступа (RAN) для отображения потоков QoS 5G в DRB. Логика RAN может называться конфигурацией отображения потока QoS 5G в DRB. Для каждого DRB существует объект протокола конвергенции пакетных данных (PDCP), который выполняет отображение потока QoS 5G в DRB. К тому же уровень PDCP выполняет (в дополнение к другим функциональным возможностям) последовательную нумерацию для последовательной доставки и избегания дублирования в отношении передачи обслуживания между gNB или eNB (подключенных базовой сети (CN) 5G или CN следующего поколения (CN NG), или когда двойное подключение (DC) активируется (или деактивируется)).
Варианты осуществления и примеры ниже описываются в отношении передачи обслуживания между gNB, но также применяются к передаче обслуживания между eNB, подключенными к CN NG, и когда активируется (или деактивируется) двойное подключение, когда используется новая модель QoS 5G.
Конкретная проблема с передачей обслуживания имеет отношение к возможности изменения конфигурации отображения потока QoS 5G в DRB, когда обслуживание UE передается от исходного gNB к целевому gNB. Изменение конфигурации отображения потока QoS 5G в DRB может быть необходимо, потому что использование одной и той же конфигурации отображения потока QoS 5G в DRB не всегда может быть осуществимо или возможно в исходном и целевом gNB.
Например, у UE сначала может быть три потока QoS 5G {поток 1, поток 2, поток 3}, отображенных в два DRB {DRB1, DRB2} в исходном gNB на основе конфигурации отображения потока QoS 5G в DRB в исходном gNB (s-gNB). UE может обладать следующей конфигурацией отображения: поток 1 отображен в DRB1; и поток 2 и поток 3 отображены в DRB2. Целевой gNB (t-gNB) может обладать следующей конфигурацией отображения потока QoS 5G в DRB: поток 1 и поток 2 отображены в DRB1; и поток 3 отображен в DRB2.
В примере потоку 2 понадобилось бы перейти из DRB2 в s-gNB в DRB1 в t-gNB, когда обслуживание UE передается от s-gNB к t-gNB. Повторное отображение потока 2 в DRB, поддерживающий другой набор потоков в целевом узле, может привести к некоторому количеству проблем. Одна из проблем состоит в том, что пакеты, которые уже получили порядковый номер в исходном узле, не обязательно будут последовательными с другими пакетами в DRB целевого узла.
Конкретные варианты осуществления устраняют описанные выше проблемы. Конкретные варианты осуществления включают в себя механизм для повторного отображения потока QoS 5G в DRB в отношении, например, передачи обслуживания между gNB. Описанные в этом документе варианты осуществления упрощают целевому узлу RAN в процедуре мобильности прием пользовательских данных от исходного узла RAN и доставку таких данных таким образом, что можно восстановить потерянные пакеты. Варианты осуществления также упрощают целевому узлу повторное использование той же конфигурации, что исходный узел использовал для отображения потоков данных в DRB. Конкретные варианты осуществления гарантируют, по меньшей мере на периоды после процедуры передачи обслуживания, что потоки, обслуживание которых передается от исходного узла, будут обрабатываться в целевом узле с таким же QoS, как и в исходном узле. Конкретные варианты осуществления преодолевают проблему пакетов, перенаправленных исходным узлом, которые уже пронумерованы исходным узлом на уровне PDCP. Без конкретных вариантов осуществления такие пакеты могут ошибочно интерпретироваться целевым узлом, потому что целевой узел может рассматривать исходную нумерацию PDCP как применяемую к своему процессу нумерации.
Признаки любого из вариантов осуществления, раскрытых в этом документе, могут применяться к любому другому варианту осуществления, где это уместно. Также любое преимущество любого из вариантов осуществления может применяться к другим вариантам осуществления, и наоборот. Другие цели, признаки и преимущества включенных вариантов осуществления будут очевидны из нижеследующего описания.
В целом все термины, используемые в этом документе, нужно интерпретировать в соответствии с их обычным значением в данной области техники, пока иное не задано явно в этом документе. Все ссылки на "элемент, устройство, компонент, средство, этап и т. п." нужно интерпретировать прямо как ссылающиеся на по меньшей мере один экземпляр элемента, устройства, компонента, средства, этапа и т. п., пока явно не установлено иное. Этапы любого способа, раскрытого в этом документе, не должны выполняться в точном раскрытом порядке, пока не определено явно.
В некоторых вариантах осуществления используется неограничивающий термин "UE". Описанное в этом документе UE может быть любым типом беспроводного устройства, выполненного с возможностью осуществлять связь с сетевым узлом или другим UE посредством радиосигналов. UE также может быть устройством радиосвязи, целевым устройством, UE связи между устройствами (D2D), UE машинного типа или UE, выполненным с возможностью осуществлять связь (M2M), датчиком с UE, iPAD, планшетом, мобильными терминалами, смартфоном, встраиваемым в переносной компьютер оборудованием (LEE), устанавливаемым на переносной компьютер оборудованием (LME), адаптерами USB, оборудованием в помещении абонента (CPE) и т. п. UE также может называться беспроводным устройством.
В некоторых вариантах осуществления используется универсальная терминология "сетевой узел". Это может быть любой вид сетевого узла, который может составлять узел радиосети, например базовую станцию, базовую радиостанцию, базовую приемопередающую станцию, контроллер базовой станции, сетевой контроллер, развитый Узел Б (eNB), Узел Б, gNB, мультисотовый/многоадресный координационный объект (MCE), транзитный узел, точку доступа, точку радиодоступа, выносной радиоблок (RRU), выносную радиоголовку (RRH), узел базовой сети (например, MME, узел SON, координирующий узел, узел определения местоположения (например, SMLC, E-SMLC и т. п.), узел MDT и т. п.), или даже внешний узел (например, узел сторонних производителей, узел, внешний по отношению к текущей сети) и т. п.
Конкретные варианты осуществления описываются со ссылкой на фиг. 15-21B чертежей, при этом одинаковые цифры используются для одинаковых и соответствующих частей различных чертежей. LTE и NR используются по всему данному раскрытию изобретения в качестве примерной сотовой системы, но представленные в этом документе идеи могут с тем же успехом применяться к другим системам беспроводной связи.
Фиг. 15 - блок-схема, иллюстрирующая примерную беспроводную сеть в соответствии с конкретным вариантом осуществления. Беспроводная сеть 100 включает в себя одно или несколько беспроводных устройств 110 (например, мобильные телефоны, смартфоны, переносные компьютеры, планшетные компьютеры, устройства MTC или любые другие устройства, которые могут обеспечивать беспроводную связь) и множество сетевых узлов 120 (например, базовые станции, eNodeB, gNB и т. п.). Сетевой узел 120 обслуживает зону 115 обслуживания (также называемую сотой 115).
Вообще, беспроводные устройства 110, которые входят в покрытие узла 120 радиосети (например, в соту 115, обслуживаемую сетевым узлом 120), осуществляют связь с узлом 120 радиосети путем передачи и приема радиосигналов 130. Например, беспроводные устройства 110 и сетевой узел 120 могут передавать радиосигналы 130, содержащие голосовой трафик, трафик данных и/или управляющие сигналы. Сетевой узел 120, передающий голосовой трафик, трафик данных и/или управляющие сигналы беспроводному устройству 110, может называться обслуживающим сетевым узлом 120 для беспроводного устройства 110. Радиосигналы 130 могут включать в себя передачи по нисходящей линии связи (от узла 120 радиосети к беспроводным устройствам 110) и передачи по восходящей линии связи (от беспроводных устройств 110 к узлу 120 радиосети).
Радиосигналы 130 могут включать в себя данные, инкапсулированные по одному или нескольким протоколам. Например, радиосигналы 130 могут включать в себя данные, инкапсулированные с использованием PDCP 135. Каждый элемент радиосети (например, беспроводное устройство 110, сетевой узел 120 и т. п.) может включать в себя передатчик PDCP и приемник PDCP. Когда сетевой узел 120a передает обслуживание беспроводного устройства 110 сетевому узлу 120b, могут измениться конкретные параметры PDCP, например SN PDCP.
Радиосигналы 130 могут включать в себя один или несколько несущих радиоканалов данных (DRB), как описано во ВВЕДЕНИИ. Данные могут передаваться в соответствии с одним или несколькими потоками QoS. Поток QoS может отображаться в один из одного или нескольких DRB. Когда сетевой узел 120a передает обслуживание беспроводного устройства 110 сетевому узлу 120b, может измениться отображение потока QoS в DRB.
Например, сетевой узел 120b может принять запрос передачи обслуживания от сетевого узла 120a для беспроводного устройства 110. Сетевой узел 120b может принять от сетевого узла 120a отображение потока QoS в DRB, которое использовалось сетевым узлом 120a перед передачей обслуживания. В конкретных вариантах осуществления отображение потока QoS в DRB может содержать часть сигнализации передачи обслуживания. Сетевой узел 120b может принимать буферизованные протокольные блоки данных (PDU) PDCP от сетевого узла 120a. Сетевой узел 120b может передавать принятые блоки PDU PDCP с использованием принятого отображения потока QoS в DRB. В конкретных вариантах осуществления после получения указания о том, что передача обслуживания завершена, сетевой узел 120b определяет новое отображение потока QoS в DRB. Сетевой узел 120b активирует новое отображение потока QoS в DRB для передачи новых блоков PDU PDCP.
В конкретных вариантах осуществления сетевой узел 120b может определить новое отображение потока QoS в DRB до завершения передачи обслуживания. Сетевой узел 120b может отправить сетевому узлу 120a новое отображение потока QoS в DRB. Сетевой узел 120a может отправить беспроводному устройству 110 новое отображение потока QoS в DRB. Беспроводное устройство 110 может определить, использовать ли старое, новое или сочетание обоих отображений потока QoS в DRB при отправке сетевому узлу 120b блоков PDU PDCP и/или отчетов о состоянии PDCP. Более подробные примеры описываются по отношению к фиг. 16-19.
В некоторых вариантах осуществления беспроводное устройство 110 может называться неограничивающим термином "UE". UE может включать в себя любой тип беспроводного устройства, выполненного с возможностью осуществлять связь с сетевым узлом или другим UE посредством радиосигналов. UE может быть выполнено в виде устройства радиосвязи, целевого устройства, UE связи между устройствами (D2D), UE машинного типа или UE, выполненного с возможностью осуществлять межмашинную связь (M2M), датчика с UE, iPAD, планшета, мобильных терминалов, смартфона, встраиваемого в переносной компьютер оборудования (LEE), устанавливаемого на переносной компьютер оборудования (LME), адаптеров USB, оборудования в помещении абонента (CPE) и т. п.
В некоторых вариантах осуществления сетевой узел 120 может включать в себя любой тип сетевого узла, например базовую станцию, базовую радиостанцию, базовую приемопередающую станцию, контроллер базовой станции, сетевой контроллер, развитый Узел Б (eNB), Узел Б, gNB, базовую станцию с несколькими RAT, мультисотовый/многоадресный координационный объект (MCE), транзитный узел, точку доступа, точку радиодоступа, выносной радиоблок (RRU), выносную радиоголовку (RRH), узел базовой сети (например, MME, узел SON, координирующий узел и т. п.) или даже внешний узел (например, узел сторонних производителей, узел, внешний по отношению к текущей сети), и т. п.
Каждый сетевой узел 120 может содержать одиночный передатчик или несколько передатчиков для передачи радиосигналов 130 беспроводным устройствам 110. В некоторых вариантах осуществления сетевой узел 120 может содержать систему со многими входами и выходами (MIMO). Аналогичным образом каждое беспроводное устройство 110 может содержать одиночный приемник или несколько приемников для приема сигналов 130 от сетевых узлов 120.
В беспроводной сети 100 каждый сетевой узел 120 может использовать любую подходящую технологию радиодоступа, например систему долгосрочного развития (LTE), LTE-Advanced, NR, UMTS, HSPA, GSM, cdma2000, WiMax, WiFi и/или другую подходящую технологию радиодоступа. Беспроводная сеть 100 может включать в себя любое подходящее сочетание одной или нескольких технологий радиодоступа. Для примера различные варианты осуществления можно описывать в контексте некоторых технологий радиодоступа. Однако объем раскрытия изобретения не ограничивается теми примерами, и другие варианты осуществления могли бы использовать другие технологии радиодоступа.
Как описано выше, варианты осуществления беспроводной сети могут включать в себя одно или несколько беспроводных устройств и один или несколько разных типов сетевых узлов, выполненных с возможностью осуществлять связь с беспроводными устройствами. Сеть также может включать в себя любые дополнительные элементы, подходящие для поддержания связи между беспроводными устройствами или между беспроводным устройством и другим устройством связи (например, телефоном проводной связи). Беспроводное устройство может включать в себя любое подходящее сочетание аппаратных средств и/или программного обеспечения. Например, в конкретных вариантах осуществления беспроводное устройство, например беспроводное устройство 110, может включать в себя компоненты, описанные ниже по отношению к фиг. 20. Аналогичным образом сетевой узел может включать в себя любое подходящее сочетание аппаратных средств и/или программного обеспечения. Например, в конкретных вариантах осуществления сетевой узел, например сетевой узел 120, может включать в себя компоненты, описанные ниже по отношению к фиг. 21A.
Фиг. 16 - блок-схема, иллюстрирующая конкретную архитектуру сети в соответствии с некоторыми вариантами осуществления. Функция 132 аутентификации и управления (AMF) иллюстрируется в виде функции CN плоскости управления, видимой RAN и подключенной к RAN по интерфейсу NG2 (также называемому интерфейсом NG-C). Функция 134 плоскости пользователя (UPF) иллюстрируется в виде функции CN плоскости пользователя, видимой RAN и подключенной к RAN по интерфейсу NG3 (также называемому интерфейсом NG-U). Два gNB 120 показаны в качестве исходного gNB 120a и целевого gNB 120b, указывая, что UE 110 собирается выполнить передачу обслуживания от исходного gNB 120a к целевому gNB 120b. К тому же исходный и целевой gNB 120 соединяются по интерфейсу Xn. На фиг. 16 иллюстрируются только узлы CN, подключенные к RAN напрямую.
В первой группе вариантов осуществления t-gNB принимает от s-gNB отображение потока QoS в DRB (то есть отображение потока QoS 5G в DRB), которое применялось s-gNB. t-gNB использует принятое отображение потока QoS в DRB и может обновить конфигурацию после завершения передачи обслуживания. В конкретных вариантах осуществления, пока длится процедура передачи обслуживания, t-gNB применяет отображение потока QoS в DRB, используемое ранее s-gNB. Когда завершается процедура передачи обслуживания, t-gNB вправе отображать потоки в DRB наилучшим для такого узла образом. Пример иллюстрируется на фиг. 17.
Фиг. 17 - логическая блок-схема, иллюстрирующая примерную сигнализацию передачи обслуживания в соответствии с некоторыми вариантами осуществления. У UE 110 есть соединение плоскости управления с AMF 132 и соединение плоскости пользователя с UPF 134 через исходный gNB 120a (этапы 1a и 1b). На этапе 2 UE 110 выполняет измерения и сообщает измерения исходному gNB 120a. На этапе 3 на основе измерений принимается решение о передаче обслуживания к целевому gNB 120b. Передача обслуживания инициируется на этапе 4. На этапе 5 целевой gNB 120b принимает и сохраняет отображение потока QoS в DRB, используемое ранее исходным gNB 120a. Передача обслуживания продолжается, и на этапах 6-9 обмениваются буферизованными блоками PDU PDCP, SN PDCP и другим состоянием.
На этапе 10 любые блоки PDU PDCP нисходящей линии связи, принятые от исходного gNB 120a, сохраняются с использованием принятого отображения потока QoS в DRB. Если передаются блоки PDU PDCP, то они передаются с использованием принятого отображения потока QoS в DRB. Передача обслуживания завершается на этапах 11-13. На этапе 14 целевой gNB 120b активирует новое отображение потока QoS в DRB. Новое отображение будет использоваться для любых новых пакетов, принятых с верхних или нижних уровней.
Механизмами для отправки отображения потока QoS в DRB, используемого в s-gNB, от s-gNB к t-gNB могла бы быть сигнализация передачи обслуживания. Для передач обслуживания на основе интерфейса gNB-gNB, например интерфейса Xn в 5G, информацию можно отправлять напрямую от s-gNB к t-gNB, тогда как для передач обслуживания, которые привлекают CN, информация может отправляться по интерфейсу RAN-CN, например в прозрачных контейнерах. В 5G таким интерфейсом RAN-CN мог бы быть интерфейс S1 или интерфейс NG, так как в настоящее время он называется в 3GPP RAN3.
События, которые могут побудить t-gNB свободно использовать любую конфигурацию отображения потока QoS в DRB (то есть не придерживаться отображения потока QoS в DRB у s-gNB), могут состоять из прекращения приема перенаправленных данных или прекращения приема пронумерованных пакетов PDCP, или сконфигурированных таймеров, начинающихся в любой заданный момент процедуры передачи обслуживания (например, во время, когда t-gNB отправляет сообщение с подтверждением запроса перемещения).
Во второй группе вариантов осуществления старое отображение s-gNB и новое отображение t-gNB используются одновременно до завершения перенаправления данных. В конкретных вариантах осуществления t-gNB активирует новое отображение потока QoS в DRB как часть подготовки к передаче обслуживания. Старое отображение потока QoS в DRB (управляемое s-gNB) и новое отображение потока QoS в DRB используются параллельно UE и t-gNB (или, при необходимости, только одним из этих объектов). Старое отображение потока QoS в DRB используется для блоков PDU PDCP, обрабатываемых уровнем PDCP (обрабатываемых означает, например, что выделялся SN PDCP) либо в s-gNB, либо в UE в отношении соединения с s-gNB. Пример иллюстрируется на фиг. 18.
Фиг. 18 - логическая блок-схема, иллюстрирующая другой пример сигнализации передачи обслуживания в соответствии с некоторыми вариантами осуществления. Обычно активация нового отображения потока QoS в DRB на t-gNB может, например, основываться на любом сочетании старого отображения потока QoS в DRB, принятого от s-gNB, обнаруженных потоков QoS 5G, сообщенных от s-gNB, и локальной конфигурации в t-gNB.
t-gNB принимает от s-gNB старое отображение потока QoS в DRB, которое применялось s-gNB (этап 4 из фиг. 18). t-gNB сохраняет старое отображение потока QoS в DRB, принятое от s-gNB, и создает новое отображение потока QoS в DRB (этап 5). Новое отображение потока QoS в DRB возвращается s-gNB для дальнейшей передачи к UE (этапы 6 и 7). UE сохраняет как новое отображение потока QoS в DRB, так и старое отображение потока QoS в DRB (этап 8). Для обеспечения передачи обслуживания без потерь целевой узел и UE обмениваются информацией (то есть отчетностью о состоянии) о том, какие блоки PDU PDCP успешно приняты UE, а какие отсутствуют (этап 13). Обмен информацией основывается на отображении потока QoS в DRB на стороне s-gNB. Соответствующие порядковые номера PDCP нельзя отобразить в новую конфигурацию целевой стороны (то есть в новое отображение потока QoS в DRB).
В дополнение к порядковому номеру PDCP 5G может включать в себя идентификацию потока QoS, указанную в заголовке PDCP. Поэтому можно различать потоки QoS по идентификатору потока QoS, даже если они отображаются в DRB по-разному на исходном и целевом gNB.
Нижеследующее является двумя примерами того, как выполнять (повторную) передачу блоков PDU PDCP, для которых выделены SN в s-gNB на этапе 14, и показано для UE и t-gNB. В некоторых вариантах осуществления этот этап может выполняться только одним из объектов, например, только t-gNB.
В одном примере блоки PDU PDCP, для которых были выделены SN PDCP в s-gNB (то есть на основе старого отображения потока QoS в DRB), отправляются с SN исходной стороны посредством новой конфигурации DRB. В заголовок PDCP включается поле для включения SN PDCP для старых и новых отображений потока QoS в DRB. Другой вариант включает в себя два заголовка PDCP. Например, старый заголовок PDCP с выделенными s-gNB SN может вкладываться в новый заголовок PDCP, созданный t-gNB, что облегчает для t-gNB применение последовательной нумерации PDCP t-gNB, тогда как синхронизация состояния передачи может сколько необходимо применять последовательную нумерацию s-gNB и соответствующую (повторную) передачу блоков PDU.
В другом примере UE и t-gNB применяют старое отображение потока QoS в DRB и последовательную нумерацию PDCP до окончания синхронизации состояния передачи и соответствующей (повторной) передачи блоков PDU PDCP. После этого применяется конфигурация t-gNB (то есть используется новое отображение потока QoS в DRB).
Общим для обоих примеров является то, что перенаправление данных по интерфейсу Xn и соответствующий обмен информацией о состоянии SN (этап 9) могут применяться, как задано для LTE в интерфейсе X2. Отличие состоит в возможности использовать новые диапазоны порядковых номеров.
Чтобы t-gNB определил, нужно ли применять особую обработку в соответствии с описанными выше возможностями, t-gNB принимает от s-gNB старое отображение потока QoS в DRB.
В некоторых вариантах осуществления описанные выше функции t-gNB и UE применяются только для поднабора DRB. Например, если не изменилось отображение потока QoS в DRB для поднабора DRB, то применение функциональных возможностей может не понадобиться.
Другим примером, который не попадает в категорию обеспечения мобильности без потерь, является только перенаправление простых IP-пакетов как принятых от UPF, а не синхронизация состояния приема PDCP. Это могло бы привести к потере пакетов и/или дублированию пакетов, но это упрощает процедуры в RAN.
Конфигурацию отображения потока QoS в DRB можно представить по-разному. В простом виде представление указывает отношение между разными потоками QoS 5G и DRB. К тому же соответствующая внутренняя информация SN PDCP восходящей линии связи и нисходящей линии связи, HFN или любого другого объекта PDCP, связанная с определенным DRB, также может быть частью конфигурации отображения потока QoS в DRB.
Хотя конкретные варианты осуществления и примеры описываются по отношению к передаче обслуживания между gNB, конкретные варианты осуществления также применяются к передаче обслуживания между eNB, подключенными к CN NG, и когда активируется (или деактивируется) двойное подключение в случаях, когда используется новая модель QoS 5G.
К тому же, хотя описываются конкретные варианты осуществления и примеры, где интерфейс Xn используется для передачи обслуживания между двумя gNB, конкретные варианты осуществления могут использовать передачу обслуживания на основе интерфейса NG/NG2. Также, хотя конкретные варианты осуществления используют прямое перенаправление данных между gNB, конкретные варианты осуществления могут использовать косвенное перенаправление данных между gNB через UPF.
Тогда как фиг. 17 и 18 иллюстрируют сигнализацию между несколькими компонентами сети, фиг. 19 иллюстрирует этапы, выполняемые конкретным компонентом сети, например сетевым узлом.
Фиг. 19 - логическая блок-схема примерного способа в сетевом узле в соответствии с некоторыми вариантами осуществления. В конкретных вариантах осуществления один или несколько этапов могут выполняться сетевым узлом 120, описанным со ссылкой на фиг. 15.
Способ начинается на этапе 1912, где сетевой узел принимает запрос передачи обслуживания от исходного сетевого узла. Например, сетевой узел 120b может принимать запрос передачи обслуживания от сетевого узла 120a для беспроводного устройства 110 (например, этап 4 из фиг. 17 или 18).
На этапе 1914 сетевой узел принимает от исходного сетевого узла отображение потока QoS в DRB, которое использовалось исходным сетевым узлом перед передачей обслуживания. Например, сетевой узел 120b может принимать отображение потока QoS в DRB, которое использовалось сетевым узлом 120a перед передачей обслуживания (например, этап 4 из фиг. 17 или 18).
Прежнее отображение потока QoS в DRB может включать в себя поток 1, отображенный в DRB1, и поток 2 и поток 3, отображенные в DRB2. Отображение потока QoS в DRB может включаться в сигнализацию передачи обслуживания. В конкретных вариантах осуществления прием отображения потока QoS в DRB от исходного сетевого узла содержит прием сигнализации передачи обслуживания по интерфейсу Xn или через элемент базовой сети по интерфейсу S1 или NG.
На этапе 1916 сетевой узел принимает буферизованные блоки PDU PDCP от исходного сетевого узла. Например, у сетевого узла 120a могут быть буферизованные блоки PDU PDCP, которые еще не подтверждены беспроводным устройством 110. Сетевой узел 120a может отправить буферизованные блоки PDU PDCP сетевому узлу 120b (например, этапы 8 и 9 из фиг. 17 или этапы 9 и 10 из фиг. 18).
На этапе 1918 сетевой узел передает принятые блоки PDU PDCP с использованием принятого отображения потока QoS в DRB. Например, сетевой узел 120b может передать любые блоки PDU PDCP плоскости пользователя нисходящей линии связи беспроводному устройству 110 с использованием отображения потока QoS в DRB, принятого от сетевого узла 120a (например, этап 10 из фиг. 17 или этап 14 из фиг. 18).
На этапе 1920 сетевой узел получает указание о том, что завершена передача обслуживания. Например, сетевой узел 120b может принять подтверждение приема переключения тракта от базовой сети (например, AMF 132). Пример иллюстрируется на этапе 13 из фиг. 17 или этапе 16 из фиг. 18.
На этапе 1922 сетевой узел определяет новое отображение потока QoS в DRB. Например, конкретные требования и ресурсы сетевого узла 120b могут привести к определению сетевым узлом 120b нового отображения потока QoS в DRB, нежели отображение, используемое сетевым узлом 120a (например, этап 14 из фиг. 17 или этап 5 из фиг. 18). Новое отображение потока QoS в DRB может включать в себя поток 1 и поток 2, отображенные в DRB1, и поток 3, отображенный в DRB2.
На этапе 1924 сетевой узел активирует новое отображение потока QoS в DRB для передачи блоков PDU PDCP. Например, сетевой узел 120b будет использовать новое отображение потока QoS в DRB для блоков PDU PDCP, принятых с верхних или нижних уровней протокола.
В некоторых вариантах осуществления конкретные этапы могут выполняться в другом порядке, нежели описанный выше нумерационный порядок. Например, в некоторых вариантах осуществления сетевой узел может определять новое отображение потока QoS в DRB из этапа 1922 после или приблизительно в то же время, что и этап 1914 (например, этап 5 из фиг. 18).
В некоторых вариантах осуществления сетевой узел может использовать новое отображение потока QoS в DRB в соответствии с этапами 1926-1928. На этапе 1926 сетевой узел отправляет исходному сетевому узлу новое отображение потока QoS в DRB. Например, сетевой узел 120b может отправить сетевому узлу 120a новое отображение потока QoS в DRB (например, этап 6 из фиг. 18). Сетевой узел 120a может отправить беспроводному устройству 110 новое отображение потока QoS в DRB (например, этап 7 из фиг. 18). Беспроводное устройство 110 может использовать сочетание старого и нового отображения потока QoS в DRB для отправки сетевому узлу 120a и/или сетевому узлу 120b отчетов о состоянии или подтверждений приема.
На этапе 1928 сетевой узел принимает от беспроводного устройства отчетность о состоянии PDCP. Например, сетевой узел 120b может принимать отчеты о состоянии PDCP от беспроводного устройства 110 (например, этап 13 из фиг. 18). Новое отображение потока QoS в DRB для передачи блоков PDU PDCP можно активировать (то есть этап 1924) после завершения синхронизации принятых буферизованных блоков PDU PDCP.
В способ, проиллюстрированный на фиг. 19, можно вносить модификации, добавления или пропуски. Более того, один или несколько этапов в способе могут выполняться параллельно или в любом подходящем порядке.
Фиг. 20 - блок-схема, иллюстрирующая примерный вариант осуществления беспроводного устройства. Беспроводное устройство является примером беспроводных устройств 110, проиллюстрированных на фиг. 15. Беспроводное устройство выполнено с возможностью осуществлять передачу обслуживания из первой соты во вторую соту, где отображение потока QoS в DRB для второй соты может отличаться от отображения потока QoS в DRB для первой соты.
Конкретные примеры включают в себя мобильный телефон, смартфон, PDA (персональный цифровой помощник), портативный компьютер (например, переносной компьютер, планшет), датчик, модем, устройство машинного типа (MTC)/межмашинное устройство (M2M), встраиваемое в переносной компьютер оборудование (LEE), устанавливаемое на переносной компьютер оборудование (LME), адаптеры USB, устройство с возможностью связи между устройствами, устройство NB-IoT или любое другое устройство, которое может обеспечивать беспроводную связь. Беспроводное устройство включает в себя приемопередатчик 810, схемы 820 обработки, запоминающее устройство 830 и источник 840 питания. В некоторых вариантах осуществления приемопередатчик 810 облегчает передачу радиосигналов и прием радиосигналов от узла 120 беспроводной сети (например, через антенну), схемы 820 обработки исполняют команды для предоставления некоторых или всех функциональных возможностей, описанных в этом документе как предусмотренных беспроводным устройством, и запоминающее устройство 830 хранит команды, исполняемые схемами 820 обработки. Источник 840 питания подает электроэнергию одному или нескольким компонентам беспроводного устройства 110, например приемопередатчику 810, схемам 820 обработки и/или запоминающему устройству 830.
Схемы 820 обработки включают в себя любое подходящее сочетание аппаратных средств и программного обеспечения, реализованное в одной или нескольких интегральных схемах или модулях для исполнения команд и оперирования данными, чтобы выполнить некоторые или все описанные функции беспроводного устройства. В некоторых вариантах осуществления схемы 820 обработки могут включать в себя, например, один или несколько компьютеров, одно или несколько программируемых логических устройств, один или несколько центральных процессоров (CPU), один или несколько микропроцессоров, одно или несколько приложений и/или другой логики, и/или любое подходящее сочетание вышесказанного. Схемы 820 обработки могут включать в себя аналоговые и/или цифровые схемы, сконфигурированные для выполнения некоторых или всех описанных функций беспроводного устройства 110. Например, схемы 820 обработки могут включать в себя резисторы, конденсаторы, индукторы, транзисторы, диоды и/или любые другие подходящие компоненты схем.
Запоминающее устройство 830, в общем случае, выполнен с возможностью хранения исполняемого компьютером кода и данных. Примеры запоминающего устройства 830 включают в себя компьютерное запоминающее устройство (например, оперативное запоминающее устройство (RAM) или постоянное запоминающее устройство (ROM)), носители информации большой емкости (например, жесткий диск), съемные носители информации (например, компакт-диск (CD) или универсальный цифровой диск (DVD)) и/или любые другие энергозависимые или энергонезависимые, постоянные машиночитаемые и/или исполняемые компьютером запоминающие устройства, которые хранят информацию.
Источник 840 питания, в общем случае, выполнен с возможностью подачи электроэнергии компонентам беспроводного устройства 110. Источник 840 питания может включать в себя любой подходящий тип батареи, например литиево-ионный, литий-воздушный, литий-полимерный, никель-кадмиевый, никель-металгидридный или любой другой подходящий тип батареи для подачи энергии беспроводному устройству.
В конкретных вариантах осуществления схемы 820 обработки в связи с приемопередатчиком 810 обмениваются инкапсулированными PDCP данными с сетевым узлом 120. Другие варианты осуществления беспроводного устройства могут включать в себя дополнительные компоненты (помимо показанных на фиг. 20), отвечающие за предоставление некоторых аспектов функциональных возможностей беспроводного устройства, включая любые из описанных выше функциональных возможностей и/или любые дополнительные функциональные возможности (включая любые функциональные возможности, необходимые для поддержки описанного выше решения).
Фиг. 21A - блок-схема, иллюстрирующая примерный вариант осуществления сетевого узла. Сетевой узел выполнен с возможностью осуществлять передачу обслуживания из первой соты во вторую соту, где отображение потока QoS в DRB для второй соты может отличаться от отображения потока QoS в DRB для первой соты. Сетевой узел выполненный с возможностью: приема запроса передачи обслуживания от исходного сетевого узла; приема от исходного сетевого узла отображения потока QoS в DRB, которое использовалось исходным сетевым узлом перед передачей обслуживания; приема буферизованных блоков PDU PDCP от исходного сетевого узла; передачи принятых блоков PDU PDCP с использованием принятого отображения потока QoS в DRB; получения указания о том, что передача обслуживания завершена; определения нового отображения потока QoS в DRB; и активации нового отображения потока QoS в DRB для передачи блоков PDU PDCP.
Сетевой узел 120 может быть eNodeB, Узлом Б, базовой станцией, точкой беспроводного доступа (например, точкой доступа Wi-Fi), маломощным узлом, базовой приемопередающей станцией (BTS), точкой или узлом передачи, выносным РЧ-блоком (RRU), выносной радиоголовкой (RRH) или другим узлом радиодоступа. Сетевой узел 120 включает в себя схемы 920 обработки (например, CPU, ASIC, FPGA и т. п.), по меньшей мере одно запоминающее устройство 930, по меньшей мере один сетевой интерфейс 940 и один или несколько радиоблоков, каждый из которых включает в себя один или несколько приемопередатчиков 910, соединенных с одной или несколькими антеннами. Приемопередатчик 910 облегчает передачу радиосигналов и прием радиосигналов от беспроводного устройства, например беспроводных устройств 110 (например, через антенну); схемы 920 обработки исполняют команды для предоставления некоторых или всех описанных выше функциональных возможностей как предоставляемых сетевым узлом 120; запоминающее устройство 930 хранит команды, исполняемые схемами 920 обработки; и сетевой интерфейс 940 передает сигналы внутренним компонентам сети, например шлюзу, коммутатору, маршрутизатору, Интернет, коммутируемой телефонной сети общего пользования (PSTN), контроллеру и/или другим сетевым узлам 120. Схемы 920 обработки и запоминающее устройство 930 могут быть таких же типов, как описаны выше относительно схем 820 обработки и запоминающего устройства 830 из фиг. 20.
В некоторых вариантах осуществления сетевой интерфейс 940 коммуникационно соединен со схемами 920 обработки и относится к любому подходящему устройству, выполненному с возможностью приема ввода для сетевого узла 120, отправки вывода из сетевого узла 120, выполнения подходящей обработки ввода или вывода, или того и другого, осуществления связи с другими устройствами или любого сочетания предшествующего. Сетевой интерфейс 940 включает в себя подходящие аппаратные средства (например, порт, модем, сетевую интерфейсную плату и т. п.) и программное обеспечение, включающее в себя возможности преобразования протоколов и обработки данных, для осуществления связи по сети. В конкретных вариантах осуществления схемы 920 обработки в связи с приемопередатчиком 910 обмениваются инкапсулированными PDCP данными с беспроводным устройством 110.
В некоторых вариантах осуществления часть сетевого узла 120 можно реализовать в виде виртуального компонента (компонентов) (например, посредством виртуальной машины (машин), исполняющейся на физическом узле (узлах) обработки в сети (сетях)). Например, некоторые или все функции, исполняемые схемами 920 обработки сетевого узла 120, реализуются в виде виртуальных компонентов, исполняемых одной или несколькими виртуальными машинами, реализованными в виртуальной среде (средах), размещенной схемами 920 обработки.
Другие варианты осуществления сетевого узла 120 включают в себя дополнительные компоненты (помимо показанных на фиг. 21A), отвечающие за предоставление некоторых аспектов функциональных возможностей сетевого узла, включая любые из описанных выше функциональных возможностей и/или любые дополнительные функциональные возможности (включая любые функциональные возможности, необходимые для поддержки описанного выше решения). Различные типы сетевых узлов могут включать в себя компоненты, содержащие одинаковые физические аппаратные средства, но сконфигурированные (например, посредством программирования) для поддержки разных технологий радиодоступа, либо могут представлять собой частично или полностью разные физические компоненты.
Фиг. 21B - блок-схема, иллюстрирующая примерные компоненты сетевого узла 120. Компоненты могут включать в себя модуль 950 приема, модуль 952 передачи и модуль 954 определения.
Модуль 950 приема может выполнять функции приема в сетевом узле 120. Например, модуль 950 приема может выполнять этапы 1912-1916, 1920 и 1928 из фиг. 19. В некоторых вариантах осуществления модуль 950 приема может включать в себя схемы 920 обработки либо сам в них включаться. Модуль 950 приема может осуществлять связь с модулем 952 передачи и модулем 954 определения.
Модуль 952 передачи может выполнять функции передачи в сетевом узле 120. Например, модуль 952 передачи может выполнять этапы 1918 и 1926 из фиг. 19. В некоторых вариантах осуществления модуль 952 передачи может включать в себя схемы 920 обработки либо сам в них включаться. Модуль 952 передачи может осуществлять связь с модулем 950 приема и модулем 954 определения.
Модуль 954 определения может выполнять функции определения в сетевом узле 120. Например, модуль 954 определения может выполнять этапы 1922 и 1924 из фиг. 19. В некоторых вариантах осуществления модуль 954 определения может включать в себя схемы 920 обработки либо сам в них включаться. Модуль 954 определения может осуществлять связь с модулем 950 приема и модулем 952 передачи.
Некоторые варианты осуществления из раскрытия изобретения могут обеспечивать одно или несколько технических преимуществ. Некоторые варианты осуществления могут извлечь пользу из некоторых, никаких или всех этих преимуществ. Другие технические преимущества могут быть без труда выявлены средним специалистом в данной области техники.
Хотя данное раскрытие изобретения описано в виде некоторых вариантов осуществления, специалистам в данной области техники станут очевидны изменения и перестановки вариантов осуществления. Хотя некоторые варианты осуществления описаны со ссылкой на некоторые технологии радиодоступа, может использоваться любая подходящая технология радиодоступа (RAT) или сочетание технологий радиодоступа, например система долгосрочного развития (LTE), LTE-Advanced, NR, UMTS, HSPA, GSM, cdma2000, WiMax, WiFi и т. п. Соответственно, вышеприведенное описание вариантов осуществления не ограничивает данное раскрытие изобретения. Возможны другие изменения и замены без отклонения от сущности и объема данного раскрытия изобретения.
Сокращения:
3GPP Проект партнерства 3-го поколения
5GC Система пятого поколения
5GC Ядро пятого поколения
AMBR Групповая максимальная скорость передачи битов
AMF Функция аутентификации и управления
AS Уровень, связанный с предоставлением доступа
CA Агрегирование несущих
CC Компонентная несущая
CN Базовая сеть
DRB Несущий радиоканал данных
eMBB Улучшенная мобильная широкополосная (связь)
eMTC Улучшенная связь машинного типа
eMTC-U Улучшенная связь машинного типа для нелицензируемой полосы
eNB Развитый Узел Б
eNodeB Развитый Узел Б
EPC Развитое пакетное ядро
EPS Развитая пакетная система
FeMTC Дополнительно улучшенная MTC
FDD Частотный дуплексный разнос
FMS Первый отсутствующий SN PDCP
GBR Гарантированная скорость передачи битов
gNB Узел Б пятого поколения
HFN Номер гиперкадра
ID Идентификатор
IoT Интернет вещей
LTE Долгосрочное развитие
MBR Максимальная скорость передачи битов
MME Объект управления мобильностью
MSC Центр коммутации мобильной связи
MTC Связь машинного типа
NAS Уровень, не связанный с предоставлением доступа
NB-IoT Узкополосный IoT
NB-IoT-U Узкополосный Интернет вещей для нелицензируемой полосы
NGS Система следующего поколения
NR New Radio
NW Сеть
OFDM Мультиплексирование с ортогональным частотным разделением радиоканалов
PBCH Физический широковещательный радиоканал
PCC Основная компонентная несущая
PCell Основная сота
PCRF Функция политики и правил тарификации
PDCP Протокол конвергенции пакетных данных
PDN Сеть с коммутацией пакетов
PDU Протокольный блок данных
PGW Шлюз сети с коммутацией пакетов
QoS Качество обслуживания
RAB Несущий радиоканал радиодоступа
RAT Технология радиодоступа
RAN Сеть радиодоступа
RF Радиочастота
RLF Сбой линии радиосвязи
RRC Управление радиоресурсами
RSRP Мощность принимаемого опорного сигнала
RSRQ Качество принимаемого опорного сигнала
RSTD Разность времени опорного сигнала
SCC Дополнительная компонентная несущая
SCell Дополнительная сота
SDF Поток данных услуги
SDU Сервисный блок данных
SFN Системный номер кадра
SGW Обслуживающий шлюз
SLA Соглашение об уровне услуг
TDD Дуплекс с временным разделением
TDOA Разность времени прибытия
TOA Время прибытия
UE Пользовательское оборудование
UMTS Универсальная система мобильных телекоммуникаций
UTDOA Разность времени прибытия на восходящей линии связи
UTRA Наземный радиодоступ UMTS
Изобретение относится к мобильной связи. При выполнении передачи обслуживания беспроводного устройства принимают запрос передачи обслуживания от исходного сетевого узла, принимают от исходного сетевого узла отображения потока качества обслуживания (QoS) в несущий радиоканал данных (DRB), которое использовалось исходным сетевым узлом перед передачей обслуживания, принимают буферизованные протокольные блоки данных (PDU) протокола конвергенции пакетных данных (PDCP) от исходного сетевого узла, передают принятые блоки PDU PDCP с использованием принятого отображения потока QoS в DRB, получают указания о том, что передача обслуживания завершена, определяют новое отображение потока QoS в DRB и активируют новое отображение потока QoS в DRB для передачи блоков PDU PDCP. Технический результат заключается в упрощении приема пользовательских данных целевым узлом от исходного узла. 3 н. и 12 з.п. ф-лы, 23 ил.
1. Способ выполнения передачи обслуживания беспроводного устройства для использования в сетевом узле, содержащий этапы, на которых:
принимают (1912) запрос передачи обслуживания от исходного сетевого узла;
принимают (1914) от исходного сетевого узла отображение потока качества обслуживания (QoS) в несущий радиоканал данных (DRB), которое использовалось исходным сетевым узлом перед передачей обслуживания;
принимают (1916) буферизованные протокольные блоки данных (PDU) протокола конвергенции пакетных данных (PDCP) от исходного сетевого узла;
передают (1918) принятые блоки PDU PDCP с использованием принятого отображения потока QoS в DRB;
получают (1920) указание о том, что передача обслуживания завершена;
определяют (1922) новое отображение потока QoS в DRB; и
активируют (1924) это новое отображение потока QoS в DRB для передачи блоков PDU PDCP.
2. Способ по п. 1, в котором этап, на котором принимают отображение потока QoS в DRB от исходного сетевого узла, содержит этап, на котором принимают сигнализацию передачи обслуживания по интерфейсу Xn.
3. Способ по п. 1, в котором этап, на котором принимают отображение потока QoS в DRB от исходного сетевого узла, содержит этап, на котором принимают сигнализацию передачи обслуживания через элемент базовой сети по интерфейсу S1 или NG.
4. Способ по любому из пп. 1-3, дополнительно содержащий этап, на котором отправляют (1926) в исходный сетевой узел упомянутое новое отображение потока QoS в DRB.
5. Способ по п. 4, дополнительно содержащий этап, на котором принимают (1928) от беспроводного устройства отчетность о состоянии PDCP.
6. Способ по п. 5, в котором упомянутое новое отображение потока QoS в DRB для передачи блоков PDU PDCP активируется после завершения синхронизации принятых буферизованных блоков PDU PDCP.
7. Способ по п. 1, в котором принятое отображение потока QoS в DRB содержит поднабор DRB, используемый на сетевом узле или на исходном сетевом узле.
8. Сетевой узел (120), выполненный с возможностью осуществлять передачу обслуживания беспроводного устройства (110), при этом сетевой узел содержит схемы (920) обработки, выполненные с возможностью
принимать запрос передачи обслуживания от исходного сетевого узла (120);
принимать от исходного сетевого узла отображение потока качества обслуживания (QoS) в несущий радиоканал данных (DRB), которое использовалось исходным сетевым узлом перед передачей обслуживания;
принимать буферизованные протокольные блоки данных (PDU) протокола конвергенции пакетных данных (PDCP) от исходного сетевого узла;
передавать принятые блоки PDU PDCP с использованием принятого отображения потока QoS в DRB;
получать указание о том, что передача обслуживания завершена;
определять новое отображение потока QoS в DRB; и
активировать это новое отображение потока QoS в DRB для передачи блоков PDU PDCP.
9. Сетевой узел по п. 8, в котором схемы обработки выполнены с возможностью принимать отображение потока QoS в DRB от исходного сетевого узла путем приема сигнализации передачи обслуживания по интерфейсу Xn.
10. Сетевой узел по п. 8, в котором схемы обработки выполнены с возможностью принимать отображение потока QoS в DRB от исходного сетевого узла путем приема сигнализации передачи обслуживания через элемент базовой сети по интерфейсу S1 или NG.
11. Сетевой узел по любому из пп. 8-10, в котором схемы обработки дополнительно выполнены с возможностью отправлять в исходный сетевой узел упомянутое новое отображение потока QoS в DRB.
12. Сетевой узел по п. 11, в котором схемы обработки дополнительно выполнены с возможностью принимать отчетность о состоянии PDCP от беспроводного устройства.
13. Сетевой узел по п. 11, в котором схемы обработки выполнены с возможностью активировать упомянутое новое отображение потока QoS в DRB для передачи блоков PDU PDCP после завершения синхронизации принятых буферизованных блоков PDU PDCP.
14. Сетевой узел по п. 8, в котором принятое отображение потока QoS в DRB содержит поднабор DRB, используемый на сетевом узле или на исходном сетевом узле.
15. Сетевой узел (120), выполненный с возможностью осуществлять передачу обслуживания беспроводного устройства (110), при этом сетевой узел содержит модуль (950) приема, модуль (952) передачи и модуль (954) определения;
модуль приема выполнен с возможностью
принимать запрос передачи обслуживания от исходного сетевого узла (120),
принимать от исходного сетевого узла отображение потока качества обслуживания (QoS) в несущий радиоканал данных (DRB), которое использовалось исходным сетевым узлом перед передачей обслуживания,
принимать буферизованные протокольные блоки данных (PDU) протокола конвергенции пакетных данных (PDCP) от исходного сетевого узла;
модуль передачи выполнен с возможностью передавать принятые блоки PDU PDCP с использованием принятого отображения потока QoS в DRB;
модуль приема дополнительно выполнен с возможностью получать указание о том, что передача обслуживания завершена;
модуль определения выполнен с возможностью
определять новое отображение потока QoS в DRB и
активировать это новое отображение потока QoS в DRB для передачи блоков PDU PDCP.
HUAWEI, QoS considerations in Handover procedure, 3GPP TSG-RAN3 Meeting #94 (R3-162958) Reno, Nevada, USA, 04.11.2016, (найден 20.04.2020), найден в Интернет https://www.3gpp.org/DynaReport/TDocExMtg--R3-94--31677.htm | |||
Переносная печь для варки пищи и отопления в окопах, походных помещениях и т.п. | 1921 |
|
SU3A1 |
Авторы
Даты
2020-05-19—Публикация
2018-01-11—Подача