СПОСОБЫ, СЕТЕВЫЕ УЗЛЫ, БЕСПРОВОДНОЕ УСТРОЙСТВО И КОМПЬЮТЕРНЫЙ ПРОГРАММНЫЙ ПРОДУКТ ДЛЯ ВОЗОБНОВЛЕНИЯ СОЕДИНЕНИЯ С ПОЛНОЙ КОНФИГУРАЦИЕЙ Российский патент 2021 года по МПК H04W76/19 H04W76/27 

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

Настоящее описание в целом относится к беспроводной связи и, в частности, для возобновления соединения для беспроводного устройства.

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

Протокол управления радиоресурсами (RRC)

Как и в стандарте «Долгосрочное развитие» (LTE), протокол управления радиоресурсами (RRC) используется для конфигурирования/установки и поддержания соединения радиосвязи между устройством пользователя (UE) и сетевым узлом (например, eNB). Когда UE принимает RRC сообщение от eNB, то будет применена конфигурация (термин «компилировать» также может использоваться для обозначения применения конфигурации). И, если это успешно, UE генерирует RRC сообщение завершения, которое указывает идентификатор транзакции (ID) сообщения, которое инициировало этот ответ.

Начиная с LTE релиза (rel) 8, три сигнальных радиоканала (SRB), а именно, SRB0, SRB1 и SRB2, были доступны для доставки RRC и уровня без доступа (NAS) сообщений между устройством пользователя (UE) и eNB. Новый SRB, известный как SRB1bis, также был представлен в rel-13 для поддержки DoNAS (Data Over NAS) в узкополосном интернете вещей (NB-IoT).

SRB0 используется для RRC сообщений, использующих логический канал общего канала управления (CCCH), и используется для обработки установления RRC соединения, возобновления RRC соединения и повторного установления RRC соединения. После того как UE подключено к eNB (т.е. установка RRC соединения или восстановление/возобновление RRC соединения успешно завершены), SRB1 используется для обработки RRC сообщений (которые могут включать в себя вложенное NAS сообщение), а также для NAS сообщений до установления SRB2, все используют логический канал выделенного канала управления (DCCH).

SRB2 используется для RRC сообщений, которые включают в себя зарегистрированную информацию измерений, и для NAS сообщений, причем все используют логический канал DCCH. SRB2 имеет более низкий приоритет, чем SRB1, поскольку зарегистрированная информация измерений и NAS сообщений могут быть длинными и могут привести к блокировке более срочных и меньших сообщений SRB1. SRB2 всегда конфигурируется наземной сетью радиодоступа (E-UTRAN) усовершенствованной универсальной системы мобильной связи (UMTS) после активации безопасности.

Двойное подключение (DC) в LTE

Наземная сеть радиодоступа Evolved-UMTS (E-UTRAN) поддерживает операцию двойного подключения (DC), посредством которой сконфигурирован UE множественный прием/передача (Rx/Tx) в RRC_CONNECTED для использования радиоресурсов, предоставляемых двумя различными планировщиками, расположенными в двух eNB, соединенных через неидеальное транзитное соединение через интерфейс X2 (см. 3GPP 36.300). eNB, используемые в DC для конкретного UE, могут выполнять две разные роли: eNB может действовать как главный узел (MN) или как вторичный узел (SN). В DC UE подключено к одному MN и одному SN.

В LTE DC архитектура протокола радиосвязи, которую использует конкретный канал, зависит от того, как установлен канал. Существуют три типа каналов: канал основной группы сот (MCG), канал вторичной группы сот (SCG) и раздельные каналы. RRC расположен в MN, и SRB всегда конфигурируются как тип MCG канала и поэтому используют только радиоресурсы MN. Фиг. 1 иллюстрирует LTE DC (UP) плоскость пользователя с 3 типами каналов в UE.

LTE-NR Двойное подключение

LTE-NR (LTE-New Radio) DC (также называемый LTE-NR плотным взаимодействием) в настоящее время обсуждается для rel-15. В этом контексте основные изменения от LTE DC являются:

введение разделенного канала из SN (известного как SCG-разделенный канал);

введение разделенного канала для RRC;

введение прямого RRC от SN (также упоминаемого как SCG SRB).

Фиг. 2 и фиг. 3 показывают архитектуры UP и плоскости управления (CP) соответственно для LTE-NR плотного взаимодействия.

SN иногда упоминается как SgNB (где gNB является базовой станцией NR), и MN как MeNB в случае, если LTE является главным узлом, и NR является вторичным узлом. В другом случае, когда NR является главным, и LTE является вторичным узлом, соответствующими терминами являются SeNB и MgNB.

Разделенные RRC сообщения, в основном, используются для разнесения, и отправитель может принять решение либо выбрать одну из линий связи для планирования RRC сообщений, либо он может продублировать сообщение по обеим линиям связи. В нисходящей линии связи переключение тракта между MCG или SCG ответвлениями или дублирование на обоих оставлено для реализации сети. С другой стороны, для UL сеть настраивает UE на использование MCG, SCG или обеих ответвлений. Термины «ответвление» и «тракт» используются в данном документе взаимозаменяемо.

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

DC: LTE DC (то есть, и MN, и SN используют LTE);

EN-DC: двойное подключение LTE-NR, где LTE является главным и NR является вторичным;

NE-DC: двойное подключение LTE-NR, где NR является главным и LTE является вторичным;

NR-DC (или NR-NR DC): и MN, и SN используют NR;

MR-DC (DC с несколькими RAT): общий термин для описания того, где MN и SN используют разные технологии радиодоступа (RAT), EN-DC и NE-DC представляют собой два разных примерных случая MR-DC.

Гармонизация канала в EN-DC

В сети 2 радиодоступа (RAN2) было согласовано гармонизировать так называемые каналы MCG, разделенные каналы MCG, каналы SCG и раздельные каналы SCG следующим образом:

a) Можно сконфигурировать UE для использования протокола конвергенции пакетных данных NR (PDCP) для всех каналов (даже когда UE работает в автономном режиме LTE, и EN-DC не установлен);

b) для всех каналов, сконфигурированных с NR PDCP, можно сконфигурировать UE для использования либо KeNB, либо S-KeNB в качестве ключа безопасности;

c) Конфигурация PDCP уровней отделена от конфигурации нижних уровней MCG и SCG ответвления.

С точки зрения UE это означает, что существует только 3 разных канала (как видно на фиг. 4), а именно:

d) канал MCG, который использует радиолинию только к узлу MN;

e) канал SCG, который использует радиосвязь только узла SN;

f) и разделенный канал, который использует радиосвязь как MN, так и SN.

Когда эти каналы завершаются в сети, больше не важно с точки зрения UE, то есть, UE будет просто использовать ключ, который сконфигурирован из каждого однонаправленного канала. С точки зрения RAN2 полностью поддерживается установка каналов MCG, которые завершаются в узле SN с использованием каналов S-KeNB и SCG, которые заканчиваются в узле MN. Точно так же можно поддерживать как заканчивающиеся каналы MN, так и SN, то есть, как заканчивающиеся разделенные каналы SN, так и MN.

Процедура повторного установления LTE

Цель процедуры повторного установления LTE состоит в том, чтобы повторно устанавливать RRC соединение после обнаружения сбоя радиолинии, сбоя передачи обслуживания, мобильности из-за сбоя E-UTRA, сбоя проверки целостности на SRB или сбоя реконфигурации RRC соединения. Повторное установление включает в себя возобновление SRB1, повторную активацию защиты и настройку только первичной соты (PCell), то есть, операции агрегации несущих (CA) или DC повторно не установленной.

Когда целевой eNB получает запрос на повторное установление, он идентифицирует исходный eNB/соту из ReestabUE-Identity, включенного в запрос, и может отправлять сообщение X2 с индикацией отказа линии радиосвязи (RLF) в исходный eNB. Исходный eNB может ответить сообщением запроса передачи обслуживания, которое включает в себя контекст UE (контекст RRC и контекст S1). Если целевой eNB способен понять контекст UE, повторное установление завершается успешно, и целевой eNB отправляет сообщение RRCConnectionReestablishment в UE. Если целевой eNB не принимает контекст UE или не понимает контекст, он может отклонить повторное установление, и UE должен перейти к RRC_IDLE для повторного подключения. Если целевой eNB не понимает контекст RRC, но может понять контекст S1, он не обязательно отклоняет повторное установление и все равно может ответить с помощью RRCConnectionReestablishment и позже использовать полную реконфигурацию для переконфигурации каналов на основе контекста S1.

В случае успеха повторного установления операция SRB1 возобновляется, в то время как работа других радиоканалов (SRB2 и DRB) остается приостановленной. Если защита уровня доступа (AS) не была активирована, UE не инициирует процедуру, а вместо этого непосредственно переходит к RRC_IDLE.

E-UTRAN применяет процедуру повторного установления следующим образом:

Когда защита AS была активирована:

- переконфигурировать SRB1 и возобновить передачу данных только для этого радиоканала;

- повторно активировать безопасность AS без изменения алгоритмов.

После этого UE отправляет сообщение RRCConnectionReestablishmentComplete, и целевой eNB отвечает, отправляя сообщение RRCConnectionReconfiguration для переконфигурирования SRB2 и DRB.

Процедура повторного установления RRC соединения показана на фиг. 5 (случай успеха) и фиг. 6 (случай сбоя). SRB0 используется для отправки сообщений RRCConnectionReestablishmentRequest, RRCConnectionReestablishment и RRCConnectionReestablishementReject, в то время как RRCConnectionReestablishmentComplete использует SRB1.

LTE процедура приостановки/возобновления

Функциональность RRC приостановки/возобновления была введена в LTE rel-13. Приостановленное UE может рассматриваться как находящееся в промежуточном состоянии между IDLE и CONNECTED, где контекст AS UE сохраняется как в UE, так и в RAN, и UE можно рассматривать так, как будто оно находится в режиме соединения, но приостановлено из базовой сети (CN) и в режиме IDLE с точки зрения RAN. Преимущество работы в этом режиме заключается в уменьшении сигнализации и более быстром переходе в режим CONNECTED по сравнению с традиционными переходами в режим IDLE-CONNECTED при сохранении преимуществ энергосбережения UE в режиме IDLE.

Когда сеть принимает решение перевести UE в состояние ожидания, eNB отправляет UE сообщение RRCConnectionRelease со значением причины освобождения rrc-suspend. Сообщение RRCConnectionRelease также содержит Resume ID. UE хранит Resume ID и контекст AS UE (включающий в себя текущую RRC конфигурацию, текущий контекст безопасности, состояние PDCP, включающее в себя состояние надежного сжатия заголовка (ROHC), временный идентификатор сотовой радиосети (C-RNTI), используемый в исходной PCell, идентификатор соты (cellID) и физический идентификатор соты исходной PCell); повторно устанавливает все объекты управления радиоканалом (RLC) (как для SRB, так и для DRB); и приостанавливает все DRB и SRB, кроме SRB0.

Когда UE позже хочет возобновить соединение (в ответ на данные UL, которые должны быть отправлены, или на запрос поискового вызова для данных DL), оно отправляет сообщение RRCConnectionResumeRequest с сохраненным Resume ID. Если операция возобновления выполняется в eNB, отличном от eNB, который обслуживал UE, когда UE было приостановлено, новый eNB может выполнить выборку контекста с использованием процедуры Retrieve UE Context X2 из ранее использованного eNB (поскольку Resume ID включает в себя информация ранее использованного eNB/соты). После получения контекста (если возобновление в новом eNB) или, если возобновление было в том же eNB, целевой eNB отвечает сообщением RRCConnectionResume, и UE, и eNB восстанавливают сохраненный контекст UE и передачу/прием данных из/в UE может быть возобновлено.

Процедура возобновления RRC соединения показана на фиг. 7 (случай успеха) и на фиг. 8 (возврат к установлению RRC соединения). На фиг. 9 (отклонение или освобождение сети) показана процедура возобновления в LTE. SRB0 используется для отправки сообщений RRCConnectionResumeRequest, RRCConnectionSetup и RRCConnectionReestablishementReject, и сообщения RRCConnectionResume и RRCConnectionResume Complete используют SRB1.

Основное различие между возобновлением и повторным установлением состоит (с процедурной точки зрения): SRB1 используется для сообщения RRCConnectionResume, тогда как SRB0 используется для сообщения RRCConnectionReestablishment.

Сообщение RRCConnectionResume, в отличие от сообщения RRCConnectionReestablishement, может содержать SRB2/DRB конфигурацию и, таким образом, RRCConnectionReconfiguration не требуется после возобновления (хотя это необходимо в случае повторного установления для реконфигурации SRB2/DRB).

На фиг. 10 показана подробная процедура 1000 приостановки RRC соединения.

Более конкретно, на этапе 1010 на фиг. 10 из-за некоторых триггеров, например, по истечении таймера неактивности UE, eNB решает приостановить RRC соединение.

На этапе 1020 eNB инициирует процедуру приостановки контекста UE протокола S1-Application Protocol (AP), чтобы сообщить объекту управления мобильностью (MME), что RRC соединение приостановлено. Для этого eNB отправляет запрос приостановки контекста UE. Как примечание, S1 относится к интерфейсу между eNB и базовой сетью.

На этапе 1030 MME запрашивает обслуживающий шлюз (S-GW) освободить все каналы S1-U для UE. S1-U относится к плоскости пользователя S1, и каналы S1-U являются каналами, которые передают пользовательские данные между eNB и базовой сетью.

На этапе 1040 MME подтверждает этап 1020. Например, MME отправляет ответ на запрос этапа 1020.

На этапе 1050 eNB приостанавливает RRC соединение, отправляя сообщение RRCConnectionRelease с releaseCause, установленным в rrc-Suspend, в UE. Сообщение включает в себя идентификатор возобновления, который сохраняется UE.

На этапе 1060 UE сохраняет контекст AS, приостанавливает все SRB и DRB. UE входит в состояние RRC_IDLE соединение.

Когда UE позже хочет возобновить соединение (в ответ на данные UL, которые должны быть отправлены, или на пейджинговый запрос для данных DL), оно отправляет сообщение RRCConnectionResumeRequest с сохраненным resumeIdentity. eNB отвечает сообщением RRCConnectionResume, и как UE, так и eNB восстанавливают сохраненный контекст UE, и передача/прием данных от/к UE может быть возобновлена. Следует отметить, что операция возобновления может выполняться в eNB, отличном от eNB, который обслуживал UE, когда UE было приостановлено. В этом случае новый eNB может выполнять выборку контекста, например, с помощью процедуры извлечения контекста UE из ранее использованного eNB (так как resumeIdentity включает в себя информацию о ранее использованном eNB/соте).

На фиг. 11 и фиг. 12 проиллюстрирована процедура возобновления RRC соединения в том же eNB и новом eNB, соответственно.

Фиг. 11 иллюстрирует процедуру 1100 возобновления RRC соединения в том же eNB.

На этапе 1110 UE отправляет преамбулу произвольного доступа в eNB, чтобы получить доступ к сети.

На этапе 1120 eNB отвечает отправкой ответа произвольного доступа, чтобы подтвердить, что UE подключено к сетевому узлу (eNB).

На этапе 1130 по фиг. 11 в некоторый более поздний момент времени (например, когда UE выполняется поисковый вызов или, когда новые данные поступают в буфер восходящей линии связи), UE возобновляет соединение, отправляя запрос RRCConnectionResumeRequest в eNB. UE может включать в себя свой идентификатор возобновления, причину установления и токен аутентификации. Токен аутентификации вычисляется так же, как код целостности короткого сообщения аутентификации сообщения (MAC-I), используемый при повторном установлении RRC соединения, и позволяет eNB проверять идентичность UE.

На этапе 1140, при условии, что Resume ID существует и токен аутентификации успешно подтвержден, eNB отвечает RRCConnectionResume. Сообщение включает в себя значение количества последовательных переходов (NCC), которое требуется для восстановления безопасности AS.

На этапе 1150 UE возобновляет все SRB и DRB и повторно устанавливает безопасность AS. UE теперь находится в RRC_CONNECTED.

На этапе 1160 UE отвечает RRCConnectionResumeComplete, подтверждающим, что RRC соединение было успешно возобновлено.

На этапе 1170 eNB инициирует процедуру возобновления контекста S1-AP, чтобы уведомить MME об изменении состояния UE.

На этапе 1180 MME запрашивает S-GW активировать каналы S1-U для UE.

На этапе 1190 MME подтверждает этап 1170.

Фиг. 12 иллюстрирует процедуру 1200 возобновления RRC в eNB, отличном от исходного eNB, где UE было приостановлено.

Этапы с 1205 по 1215 такие же, как этапы с 1110 по 1130 на фиг. 11.

На этапе 1220 (X2-AP: запрос запроса контекста UE) новый eNB обнаруживает ранее использованный eNB, используя идентификатор возобновления, и извлекает контекст UE с помощью процедуры контекста восстановления UE X2-AP.

На этапе 1225 (X2-AP: получение ответа контекста UE) ранее использованный eNB отвечает на новый eNB контекстом UE, ассоциированным с Resume ID.

Этап 1230, который аналогичен этапу 1140 на фиг. 11 (при возобновлении соединения в eNB).

Этап 1235 аналогичен этапу 1150 на фиг. 11 (при возобновлении соединения в eNB).

Этап 1240 аналогичен этапу 1160 на фиг. 11 (при возобновлении соединения в eNB).

На этапе 1245 новый eNB инициирует процедуру переключения тракта S1-AP, чтобы установить ассоциированное с S1 UE сигнализацией соединение с обслуживающим MME и запросить MME возобновить контекст UE.

На этапе 1250 MME запрашивает S-GW активировать каналы S1-U для UE и обновить тракт нисходящей линии связи.

На этапе 1255 MME подтверждает этап 1245.

На этапе 1260 (X2-AP: освобождение контекста UE) после процедуры переключения тракта S1-AP новый eNB инициирует освобождение контекста UE в ранее использованном eNB посредством процедуры освобождения контекста UE X2-AP.

Процедура возобновления является оппортунистической процедурой в том, что могут быть случаи, когда RAN узел не имеет сохраненного контекста UE. В этом случае было определено решение, позволяющее RAN восстанавливать контекст UE с использованием процедуры установки RRC соединения, которая включает в себя UE сигнализацию в CN, и затем CN восстанавливает контекст UE в RAN. Процедура RRC для этого показана на фиг. 8. На фиг. 13 показана более подробная процедура для этого случая. Этот случай также может упоминаться как использование восстановления NAS или переход через IDLE (поскольку контекст UE AS удален). Фиг. 13 известна в данной области техники, как таковая, она не будет описываться дополнительно.

Полные конфигурации RRC в LTE

В LTE во время передачи обслуживания (HO) или повторного установления контекст UE передается от источника к целевому eNB. Если целевой eNB не понимает какую-либо части конфигурации UE, тогда он запускает полную конфигурацию. Полная процедура конфигурирования указана в технической спецификации Проекта партнерства третьего поколения (TS 3GPP) 36.331, раздел 5.3.5.8, как указано ниже.

UE должно:

1> освободить/сбросить все текущие выделенные конфигурации радиосвязи, за исключением MCG C-RNTI, конфигурации безопасности MCG и PDCP, RLC, конфигурации логических каналов для RB и зарегистрированной конфигурации измерений;

Примечание 1. Конфигурация радиосвязи представляет собой не только конфигурацию ресурса, но и другие конфигурации, такие как MeasConfig и OtherConfig.

1> если сообщение RRCConnectionReconfiguration включает в себя mobilityControlInfo:

2> освободить/сбросить все текущие общие конфигурации радиосвязи;

2> использовать значения по умолчанию, указанные в 9.2.5 для таймера T310, T311 и константы N310, N311;

1> еще:

2> использовать значения для таймеров T301, T310, T311 и константы N310, N311, которые включены в ue-TimersAndConstants, принятые в SystemInformationBlockType2 (или SystemInformationBlockType2-NB в NB-IoT);

1> применить конфигурацию физического канала по умолчанию, как указано в 9.2.4;

1> применить конфигурацию полупостоянного планирования по умолчанию, как указано в 9.2.3;

1> применить основную конфигурацию MAC по умолчанию, как указано в 9.2.2;

1> если UE является UE NB-IoT; или

1> для каждого значения srb-Identity, включенного в srb-ToAddModList (реконфигурация SRB):

2> применить указанную конфигурацию, определенную в 9.1.2 для соответствующего SRB;

2> применить соответствующую конфигурацию RLC по умолчанию для SRB, указанную в 9.2.1.1 для SRB1 или в 9.2.1.2 для SRB2;

2> применить соответствующую конфигурацию логического канала по умолчанию для SRB, как указано в 9.2.1.1 для SRB1 или в 9.2.1.2 для SRB2;

Примечание 2. Это делается для перевода SRB (SRB1 и SRB2 для передачи обслуживания и SRB2 для переконфигурирования после восстановления) в известное состояние, из которого сообщение переконфигурирования может выполнять дополнительную конфигурацию.

1> для каждого значения eps-BearerIdentity, включенного в drb-ToAddModList, который является частью текущей конфигурации UE:

2> освободить PDCP объект;

2> освободить RLC объект или объекты;

2> освободить DTCH логический канал;

2> освободить drb-identity;

Примечание 3: Сохранит eps-bearerIdentity, но переместит DRB, включающий в себя drb-identity этих каналов, из текущей конфигурации UE и инициирует установку DRB в AS в разделе 5.3.10.3 с использованием новой конфигурации. Eps-bearerIdentity действует как привязка для ассоциации освобожденного и переустановленного DRB. В AS переустановка DRB эквивалентна новой DRB установке (включающей в себя новые конфигурации PDCP и логического канала).

1> для каждого значения eps-BearerIdentity, которое является частью текущей конфигурации UE, но не является частью drb-ToAddModList:

2> выполнить освобождение DRB, как указано в 5.3.10.2;

Как видно из вышесказанного, опция полной конфигурации включает в себя инициализацию конфигурации радиосвязи, что делает процедуру независимой от конфигурации, используемой в исходной соте (сотах), за исключением того, что алгоритмы безопасности продолжаются для RRC повторного установления. Если DRB не включен в список drb-ToAddModList, DRB будет освобожден и, следовательно, будет отправлено сообщение на верхние уровни, указывающее освобождение канала (т.е. для продолжения обслуживания данных требуется полная установка канала с нуля ассоциированный с выпущенным каналом (и)). Для тех каналов, которые включены в список drb-toAddModList, объекты PDCP/RLC/логический канал (LCH) освобождаются и устанавливаются снова.

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

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

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

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

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

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

В контексте rel-15 и EN-DC такие ситуации могут легко возникнуть. Например, UE может быть сконфигурировано для использования NR PDCP для некоторых однонаправленных радиоканалов (SRB или DRB), даже когда оно не находится в режиме EN-DC, оно может быть возобновлено в eNB, который не поддерживает NR PDCP.

Для решения технической задачи в некоторой степени, было предложено решение в предварительной патентной заявке № 62/565067, поданной в USPTO 28 сентября 2017 года (содержание которой включено в настоящий документ), и позднее указанное в соглашение, которое было достигнуто на собрании RAN2 №100 [ftp://ftp.3gpp.org/tsg_ran/WG2_RL2/TSGR2_100/Report/RAN2-100-Reno-Chair-Notes-2017-12-01-eom.docx].

Соглашения

1 о повторном установлении,

• UE возвращается к использованию LTE PDCP для SRB1

• если целевой eNB поддерживает NR-PDCP, он может использовать RRCConnectionReconfiguration для возврата версии PDCP SRB1 или любых других каналов в NR

• если целевой eNB не поддерживает NR-PDCP, он может выполнить полную конфигурации для возврата версии PDCP всех каналов в LTE PDCP.

2 о возобновлении,

• UE возвращается к использованию LTE PDCP для SRB1

3 сообщение RRCResume расширяется для предоставления конфигурации каналов с NR PDCP

Это решение гарантирует, что eNB сможет отправлять команду RRCConnectionResume в SRB1, которая использует LTE PDCP, и UE сможет ее понять. Однако решение все еще требует, чтобы eNB понимал контекст (или конфигурацию) UE в исходной соте, чтобы знать, как он должен иметь возможность конфигурировать UE в целевой соте. Если целевая сота (или сетевой узел) не понимает контекст UE, у него не будет выбора позволить UE выполнить восстановление NAS, отправив сообщение установки RRC соединения в UE (как проиллюстрировано на фиг. 8 и фиг. 12).

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

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

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

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

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

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

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

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

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

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

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

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

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

- будет возможно возобновить приостановленное UE в e/gNB, который использует более раннюю версию RAT (или ту же версию RAT, но с ограниченными функциональными возможностями), чем та, которая используется исходным eNB, где UE приостановлено (или отправлено в неактивный режим),

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

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

Некоторые варианты осуществления могут иметь некоторые или ни одно из указанных выше преимуществ. Другие преимущества будут очевидны для специалистов в данной области.

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

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

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

фиг. 1 иллюстрирует схематическую структурную схему LTE DC (UP) плоскости пользователя;

фиг. 2 является схематической блок-схемой LTE-NR тесного взаимодействия для UP;

фиг. 3 является схематической блок-схемой LTE-NR тесного взаимодействия для плоскости управления (CP);

фиг. 4 иллюстрирует схематическую блок-схему конфигурации 3 каналов в сети связи;

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

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

фиг. 7 иллюстрирует схему сигнализации успешной процедуры возобновления RRC соединения;

фиг. 8 иллюстрирует схему сигнализации успешного возврата возобновления RRC соединения к процедуре установления RRC соединения;

фиг. 9 иллюстрирует схему сигнализации процедуры возобновления RRC соединения с отклонением или высвобождением сети;

фиг. 10 иллюстрирует схему сигнализации приостановки RRC соединения;

фиг. 11 иллюстрирует другую схему сигнализации процедуры возобновления RRC соединения;

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

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

фиг. 14 иллюстрирует схематическую блок-схему сети связи;

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

фиг. 16 иллюстрирует блок-схему алгоритма другого способа в сетевом узле согласно варианту осуществления;

фиг. 17 иллюстрирует блок-схему последовательности операций способа в беспроводном устройстве согласно варианту осуществления;

фиг. 18 иллюстрирует блок-схему алгоритма еще одного способа в сетевом узле согласно варианту осуществления;

фиг. 19 и фиг. 20 иллюстрируют блок-схемы алгоритма сетевого узла в соответствии с некоторыми вариантами осуществления;

фиг. 21 и фиг. 22 иллюстрируют схематические блок-схемы беспроводного устройства в соответствии с некоторыми вариантами осуществления;

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

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

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

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

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

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

Фиг. 14 иллюстрирует сеть 200 беспроводной связи для беспроводной связи. Сеть 200 беспроводной связи включает в себя беспроводные устройства 210 (например, устройство пользователя, UE) и множество сетевых узлов 220 (например, eNB, gNBs, базовых станций и т.д.), подключенных к одному или нескольким узлам 240 базовой сети через соединительную сеть 230. Каждое беспроводное устройство 210 в области покрытия может быть способно обмениваться данными напрямую с сетевыми узлами 220 через беспроводной интерфейс. Например, UEs 210 являются массивными UEs, способными к MIMO (M-MIMO). Сетевым узлом может быть обслуживающим сетевым узлом M-MIMO UE или любой сетевой узел, с помощью которого M-MIMO UE может устанавливать или поддерживать линию связи и/или принимать информацию (например, через широковещательный канал). Как таковой, сетевой узел может содержать множество антенн, распределенных по множеству RRHs.

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

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

В некоторых вариантах осуществления беспроводное устройство 210 может взаимозаменяемо называться неограничивающим термином устройством пользователя (UE). Беспроводное устройство 210 может быть беспроводным устройством любого типа, способным, по меньшей мере, осуществлять связь M-MIMO с сетевым узлом или другим UE посредством радиосвязи. Примерами таких UE M-MIMO являются датчик, модем, смартфон, устройство типа «машина» (MTC) или устройство «машина к машине» (M2M), PDA, iPAD, планшет, смартфон, встроенный ноутбук (LEE), оборудование, установленное на ноутбуке. (LME), USB-ключи и т.д.

В некоторых вариантах осуществления «сетевой узел» может быть любым видом сетевых узлов. Примерами сетевых узлов являются eNodeB, узел B, базовая станция, точка беспроводного доступа (AP), контроллер базовой станции, контроллер радиосети, ретранслятор, реле управления донорским узлом, базовая приемопередающая станция (BTS), точки передачи, узлы передачи, удаленный радиоблок (RRU), удаленная радиостанция (RRH), узлы в распределенной антенной системе (DAS), узел базовой сети, объект управления мобильностью (MME) и т.д.

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

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

В некоторых вариантах осуществления узел 240 базовой сети может управлять установлением сеансов связи и различными другими функциями для беспроводных устройств 210. Примеры узла 340 базовой сети могут включать в себя MSC, MME, SGW, PGW, O & M, OSS, SON, узел позиционирования (например, E-SMLC), узел MDT и т.д. Беспроводные устройства 210 могут обмениваться определенными сигналами с узлом 240 базовой сети, используя уровень без доступа. При сигнализации уровня без доступа сигналы между беспроводными устройствами 310 и основным сетевым узлом 240 могут прозрачно передаваться через сеть радиодоступа. В определенных вариантах осуществления сетевые узлы 220 могут взаимодействовать с одним или несколькими другими сетевыми узлами через интерфейс междоузлия. Например, сетевые узлы 220 могут взаимодействовать друг с другом через интерфейс X2.

Хотя фиг. 14 иллюстрирует конкретную компоновку сети 200, настоящее раскрытие предполагает, что различные варианты осуществления, описанные в данном документе, могут применяться к множеству сетей, имеющих любую подходящую конфигурацию. Например, сеть 200 может включать в себя любое подходящее количество беспроводных устройств 210 и сетевых узлов 220, а также любые дополнительные элементы, подходящие для поддержки связи между беспроводными устройствами или между беспроводным устройством и другим устройством связи (таким как стационарный телефон). Варианты осуществления могут быть реализованы в любом подходящем типе телекоммуникационной системы, поддерживающей любые подходящие стандарты связи и использующей любые подходящие компоненты, и применимы к любой системе радиодоступа (RAT) или системам с несколькими RAT, в которых беспроводное устройство принимает и/или передает сигналы (например, данные).

Хотя терминология 3GPP LTE (или E-UTRAN) использовалась в настоящем изобретении для иллюстрации вариантов осуществления и описания как обслуживающего, так и обслуживаемого сетевых узлов, это не должно рассматриваться как ограничение объема изобретения только вышеупомянутой системой. Другие беспроводные системы, включающая в себя WCDMA, UTRA FDD, UTRA TDD и GSM/GERAN/EDGE, также могут извлечь выгоду из использования идей, раскрытых в настоящем изобретении. Кроме того, варианты осуществления настоящего изобретения могут применяться к сценариям, в которых обслуживающий и обслуживаемый узлы используют разные технологии радиодоступа (RAT).

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

Варианты осуществления настоящего изобретения могут устранять недостатки текущих процедур возобновления LTE и NR для случая, когда UE возобновляет работу в eNB/gNB, который не поддерживает все функциональные возможности исходного eNB. В таком случае целевой eNB/gNB может не иметь возможности считывать информацию, содержащуюся в контексте AS UE, что делает невозможным возобновление соединения UE без возврата в IDLE режим (также известный как восстановление NAS). Использование восстановления NAS может вызвать дополнительные задержки и сигнализацию. Некоторые варианты осуществления смягчают данный недостаток путем введения возможности, например, выполнять полную реконфигурацию во время процедуры возобновления.

Вариант А осуществления

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

Более конкретно, процедура возобновления улучшена для поддержки полной конфигурации (или реконфигурации). Когда целевой/новый eNB (gNB) получает запрос возобновления от UE (см., например, этап 1215 на фиг. 12), он извлекает контекст AS UE из исходного/старого eNB (см. этапы 1220 и 1225 на фиг. 12). В случае, когда целевой/новый eNB и исходный/старый eNB различаются (с использованием разных технологий радиодоступа или разных выпусков технологии), целевой eNB может быть не в состоянии полностью получить доступ или прочитать контекст AS UE.

Фиг. 15 иллюстрирует способ 300 для возобновления соединения в сетевом узле, таком как новый eNB. В таком случае целевой eNB (gNB) выполняет следующие этапы или операции:

Этап 305: прием из беспроводного устройства запроса возобновления соединения в сети связи.

Этап 310: на основе запроса извлечение информации конфигурации (например, контекст AS UE) для беспроводного устройства.

Этап 315: в ответ на определение того, что извлеченная информация конфигурации не может быть идентифицирована, генерирование новых параметров конфигурации.

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

На этапе 305 запрос возобновления может быть запросом возобновления RRC соединения.

На этапе 315: после определения того, что извлеченная информация конфигурации не может быть идентифицирована, новый eNB может просто игнорировать извлеченную информацию контекста AS UE. Затем может подготовить (или сгенерировать) новую контекстную информацию AS UE из контекстной информации S1 или NG, которая предоставляется во время поиска контекста AS UE. Контекст S1 и NG содержит информацию, которую базовая сеть отправила в RAN во время начальной установки контекста UE или при последующей сигнализации. Эта информация может содержать параметры радиосвязи для конфигурации и информацию, касающуюся разных каналов. Эта информация должна быть достаточной для целевого eNB, чтобы перестроить контекст AS UE.

На этапе 320: новый eNB подготавливает сообщение возобновления RRC, которое включает в себя новую контекстную информацию AS UE для отправки на беспроводное устройство. Для этого новый eNB устанавливает флаг полной конфигурации в сообщении возобновления RRC. Как только флаг установлен, он может упоминаться как флаг fullConfig. В современных системах такого флага нет в сообщении Resume. Затем новый eNB отправляет сообщение возобновления RRC в UE с флагом.

В ответ на прием сообщения возобновления RRC, которое содержит флаг fullConfig, UE, например, будет отбрасывать старую конфигурацию канала и другие старые параметры радиосвязи. Затем он будет применять только (новую) конфигурацию, принятую в сообщении возобновления RRC. Таким образом, UE может переключиться на новую конфигурацию с сетевого узла, который не может понять старую конфигурацию. Следует отметить, что некоторые параметры, такие как ключи безопасности, будут храниться в UE даже после приема флага fullConfig, поскольку защита шифрования и целостности уже запущена, когда сетевой узел (gNB) отправляет сообщение возобновления RRC.

Следует отметить, что модификации, дополнения или пропуски могут быть сделаны в способе 300 по фиг. 15. Дополнительно, один или несколько этапов в способе 300 могут выполняться параллельно или в любом подходящем порядке. По существу, фиг. 16 иллюстрирует другой способ 300 для возобновления соединения с сетевым узлом. Этот способ упоминается как способ 330 и может выполняться в сетевом узле 220 по фиг. 14. Этот сетевой узел может называться новым узлом сети или целевым eNB или gNB. Способ 330 включает в себя следующие этапы:

Этап 335: прием от беспроводного устройства запроса на возобновление соединения в сети связи.

Этап 340: в ответ на запрос, отправку ответного сообщения возобновления на беспроводное устройство, сообщение содержит указание выполнить полную конфигурацию.

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

В некоторых вариантах осуществления новый сетевой узел может определять, что извлеченная информация конфигурации является неидентифицируемой/нечитаемой, новый eNB может просто игнорировать извлеченную информацию о контексте AS UE. Затем он может подготовить (или сгенерировать) параметры конфигурации, например, новая контекстная информация AS UE из контекстной информации S1 или NG, которая предоставляется во время поиска контекста AS UE. Контексты S1 и NG содержат информацию, которую базовая сеть отправила в RAN во время начальной установки контекста UE или при последующей сигнализации. Эта информация может содержать параметры радиосвязи для конфигурации и информацию, касающуюся разных каналов. Эта информация должна быть достаточной для целевого eNB, чтобы перестроить контекст AS UE. Как примечание, S1 является интерфейсом между eNB и базовой сетью, когда базовой сетью является Enhanced Packet Core (EPC). NG является интерфейсом между eNB/gNB и базовой сетью, когда базовой сетью является 5GC.

В некоторых вариантах осуществления новый eNB подготавливает сообщение возобновления RRC, которое включает в себя новую контекстную информацию AS UE (или параметры конфигурации) для отправки на беспроводное устройство. Новый eNB устанавливает флаг для полной конфигурации в сообщении возобновления RRC. Как только флаг установлен, он может упоминаться как флаг fullConfig. Затем новый eNB отправляет сообщение возобновления RRC в UE с флагом.

В ответ на прием сообщения возобновления RRC, которое содержит флаг fullConfig, UE, например, откажется от старой конфигурации канала и других старых параметров радиосвязи. Затем он будет применять только (новую) конфигурацию, полученную в сообщении возобновления RRC. Таким образом, UE может переключиться на новую конфигурацию с сетевого узла, который не может понять старую конфигурацию. Следует отметить, что некоторые параметры, такие как ключи безопасности, будут храниться в UE даже после получения флага fullConfig, поскольку защита шифрования и целостности уже запущена, когда сетевой узел (gNB) отправляет сообщение возобновления RRC.

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

Теперь обратимся к фиг. 17, будет описан способ 350 в беспроводном устройстве/UE для возобновления соединения. Беспроводным устройством может быть UE 210 по фиг. 14.

Способ 350 содержит следующие этапы:

Этап 355. Отправка на сетевой узел запроса на возобновление соединения в сети связи.

Этап 360: прием ответного сообщения возобновления из сетевого узла, причем сообщение содержит указание для выполнения полной конфигурации.

Этап 365. Применение (или выполнение) полной конфигурации.

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

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

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

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

Вариант B осуществления

Вариант B осуществления обращается к несовместимости между целевыми и исходными сетевыми узлами (например, eNB), рассматривая несоответствие контекста UE с точки зрения сети.

Например, следующие улучшения сети могут рассматриваться для решения технической задачи несовместимости сетевых узлов:

1) Контекстная информация AS UE, которая передается от узла исходной сети, может быть закодирована таким образом, что целевой сетевой узел может понимать унаследованные информационные элементы (IEs) (например, конфигурации LTE PDCP), даже если некоторые новые IEs могли бы быть введены в более поздних релизах стандарта, чем версия ранее использованного eNB,

2) Когда исходный сетевой узел знает, что целевой сетевой узел является унаследованным eNB, он может преобразовать контекстную информацию AS UE в формат, который унаследованный eNB способен распознать (например, преобразовывать конфигурацию NR PDCP в конфигурации LTE PDCP).

В первом случае целевой сетевой узел может получить релевантную информацию канала, которую он может понять (например, конфигурации DRB-id и RLC и нижнего уровня), посредством надлежащего кодирования. Он может получить остальную информацию для этого конкретного канала из контекста канала S1 (то есть, чтобы он мог переконфигурировать UE с правильной версией LTE PDCP). Проблема с этим решением состоит в том, что оно предполагает, что унаследованный eNB выполняет что-то новое (объединяет контекст S1 или NG с другим контекстом UE, полученным от исходного сетевого узла) для обработки этого случая (т.е. на самом деле это не унаследованный eNB), но, по меньшей мере, в будущем должна быть возможность добавлять новые параметры, которые не должны быть поняты существующими eNB, поскольку эти eNB будут получать всю соответствующую информацию из частей, которые они понимают, из контекста UE и контекста S1. Эти части являются частями, которые были должным образом закодированы, чтобы их понимали все сетевые узлы (унаследованные и новые поколения сетевых узлов).

Во втором случае целевой eNB будет понимать контекст UE из исходного eNB. Однако необходимо передать все DRB в UE, чтобы инициировать UE изменить эти DRB из старой конфигурации (не понятной целевым eNB). Обычно eNB не нужно сигнализировать конфигурацию DRB для DRB, которые не хочет изменять (поскольку используется дельта-сигнализация). Таким образом, дополнительным эффектом этого решения будет добавление функции к целевому eNB для запуска сигнализации DRB для всех DRB. Это потребует обновления целевого eNB, но, по меньшей мере, должна быть возможность добавлять новые параметры в будущем, которые не должны быть поняты существующими/унаследованными eNB, поскольку eNB будет понимать все параметры, переданные из исходного eNB и всегда отправлять конфигурацию DRB в UE.

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

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

[Случай 1] Исходный узел должен пересылать контекст UE, закодированный таким образом, чтобы целевой узел мог понимать все необходимые унаследованные параметры и игнорировать новые параметры. Кодирование может, например, использовать некритические расширения, которые могут игнорироваться унаследованными целевыми eNB.

[Случай 1] Целевой узел должен перестраивать контекст UE, используя комбинацию информации контекста S1 или NG и параметров, которые он понимает из контекста UE, пересылаемого из исходного узла.

[Случай 2] Исходный узел должен получить информацию от целевого узла о том, какой выпуск спецификации стандарта он понимает или какие признаки он поддерживает. Это может быть передано в сообщении от целевого узла-источника во время установки X2 или Xn.

[Случай 2] Исходный узел должен кодировать информацию контекста UE способом, понятным целевому узлу. В случае, если целевой узел поддерживает более поздние релизы, чем исходный узел, предполагается, что код исходного узла в соответствии с его собственным выпуском должен быть понят целевым узлом. Затем контекст отправляется через X2, Xn или через базовую сеть на целевой узел.

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

Теперь обратимся к фиг. 18, будет описана блок-схема последовательности операций способа 370 для возобновления соединения для беспроводного устройства в сети связи. Сетевым узлом связи может быть сетью 200. Беспроводное устройство может быть UE 210.

Способ 370 может быть реализован в сетевом узле, таком как сеть 220 на фиг. 14.

Способ 370 включает в себя:

Этап 375: прием из беспроводного устройства запроса на возобновление соединения в сети связи;

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

Этап 385: отправку ответного сообщения возобновления на беспроводное устройство для возобновления соединения на основе адаптированной информации конфигурации.

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

В некоторых вариантах осуществления информация конфигурации адаптируется путем преобразования формата информации конфигурации из исходного сетевого узла в формат сетевого узла.

Фиг. 19 является блок-схемой примерного сетевого узла 220 радиосвязи в соответствии с некоторыми вариантами осуществления. Сетевой узел 220 радиосвязи может включать в себя один или приемопередатчики 420 с несколькими антеннами, процессор 440, память 450 и сетевой интерфейс 430. В некоторых вариантах осуществления приемопередатчик облегчает передачу беспроводных сигналов и прием беспроводных сигналов от беспроводного устройства 210 (например, через передатчик (Tx), приемник (Rx) и антенны). Процессор 440 выполняет инструкции для обеспечения некоторых или всех описанных выше функций, предоставляемых сетевым узлом 220 радиосвязи, в памяти хранятся инструкции, выполняемые процессором. В некоторых вариантах осуществления процессор 440 и память 450 формируют схему 410 обработки. Сетевой интерфейс передает сигналы на внутренние компоненты сети, такие как шлюз, коммутатор, маршрутизатор, Интернет, телефонная сеть общего пользования (PSTN), узлы базовой сети или сетевые контроллеры радиосвязи и др.

Процессор 440 может включать в себя любую подходящую комбинацию аппаратных средств для выполнения инструкций и манипулирования данными для выполнения некоторых или всех описанных функций сетевого узла 220 радиосвязи, таких как описанные выше, например, способы 300 на фиг. 15, 330 на фиг. 16 и 370 на фиг. 18 и связанные с ними варианты осуществления. В некоторых вариантах осуществления процессор может включать в себя, например, один или несколько компьютеров, один или несколько центральных процессоров (CPU), один или несколько микропроцессоров, одну или несколько специализированных интегральных схем (ASIC), один или несколько программируемых вентильных матриц (FPGA) и/или другую логику.

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

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

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

Процессоры, интерфейсы и память, аналогичные описанным в отношении фиг. 19, могут быть включены в другие сетевые узлы (такие как основной сетевой узел 230). Другие сетевые узлы могут дополнительно включать в себя или не включать в себя беспроводной интерфейс (такой как приемопередатчик, описанный на фиг. 19).

В некоторых вариантах осуществления сетевой узел 220 может содержать серию модулей 510 (см. фиг. 20), выполненные с возможностью реализации функциональных возможностей сетевого узла 220, описанного выше. Ссылаясь на фиг. 20, в некоторых вариантах осуществления сетевой узел 220 может содержать модуль приема, выполненный с возможностью принимать от беспроводного устройства запрос на возобновление соединения. Сеть 220 может содержать, например, модуль отправки, выполненный с возможностью отправлять ответное сообщение возобновления на беспроводное устройство, причем сообщение содержит указание для выполнения полной конфигурации. Сетевой узел 220 также может содержать модуль приема, выполненный с возможностью принимать запрос на возобновление соединения от беспроводного устройства. Сетевой узел может содержать другие модули, выполненные с возможностью выполнять функциональные возможности, например, способа 300 по фиг. 15 и способа 370 по фиг. 18.

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

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

Фиг. 21 иллюстрирует схематическую блок-схему беспроводного устройства 210 в соответствии с некоторыми вариантами осуществления настоящего изобретения. Как показано, беспроводное устройство 210 включает в себя схему/цепь 610, содержащую один или несколько процессоров 620 (например, центральные процессорные блоки (CPU), специализированные интегральные схемы (ASIC), программируемые пользователем вентильные матрицы (FPGA) и/или тому подобное) и память 630. Беспроводное устройство 210 также включает в себя один или несколько приемопередатчиков 640, каждый из которых включает в себя один или несколько передатчиков 650 и один или несколько приемников 660, подключенных к одной или нескольким антеннам 670. В некоторых вариантах осуществления функциональность беспроводного устройства 210, описанного выше, может быть полностью или частично реализованным в программном обеспечении, которое, например, хранится в памяти 630 и исполняется процессором(ами) 620. Например, процессор 620 выполнен с возможностью выполнять любые операции, связанные с UE, например, способ 350 на фиг. 17.

В некоторых вариантах осуществления компьютерная программа, включающая в себя инструкции, которые при выполнении, по меньшей мере, одним процессором 620, побуждают, по меньшей мере, один процессор 620 выполнять функциональные возможности беспроводного устройства 210 в соответствии с любым из вариантов осуществления, описанных в данном документе, (например, любые операции, связанные с UE, например, способ 350 на фиг. 17). В некоторых вариантах осуществления предоставляется носитель, содержащий вышеупомянутый компьютерный программный продукт. Носителем является один из электронных сигналов, оптических сигналов, радиосигналов или машиночитаемых носителей данных (например, постоянных машиночитаемых носителей, таких как память).

Фиг. 22 является схематической блок-схемой беспроводного устройства 210 в соответствии с некоторыми другими вариантами осуществления настоящего изобретения. Беспроводное устройство 210 включает в себя один или несколько модулей 700, каждый из которых реализован в программном обеспечении. Модуль (модули) 700 обеспечивают функциональные возможности беспроводного устройства 210, описанного в данном документе. Например, модули 700 могут содержать модуль отправки, выполненный с возможностью выполнять, по меньшей мере, этап 355 на фиг. 17, модуль приема, выполненный с возможностью выполнять, по меньшей мере, этап 360 на фиг. 17, и модуль выполнения, выполненный с возможностью выполнять, по меньшей мере, этап 365 на фиг. 17.

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

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

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

Функции могут быть реализованы одним или несколькими приложениями QQ320 (которые могут альтернативно называться экземплярами программного обеспечения, виртуальными устройствами, сетевыми функциями, виртуальными узлами, функциями виртуальной сети и т.д.), работающими для реализации некоторых функций, функций и/или преимущества некоторых из раскрытых здесь вариантов осуществления. Приложения QQ320 выполняются в среде 800 виртуализации, которая предоставляет аппаратное обеспечение QQ330, содержащее схему QQ360 обработки и память QQ390. Память QQ390 содержит инструкции QQ395, выполняемые схемой QQ360 обработки, посредством чего приложение QQ320 функционирует для обеспечения одной или нескольких функций, преимуществ и/или функций, раскрытых в данном документе.

Среда 800 виртуализации содержит сетевые аппаратные устройства QQ330 общего или специального назначения, содержащие набор из одного или нескольких процессоров или схем QQ360 обработки, которые могут представлять собой коммерческие готовые процессоры (COTS), выделенные специализированные интегрированные схемы (ASIC) или любые другие типы схем обработки, включающие в себя цифровые или аналоговые аппаратные компоненты или процессоры специального назначения. Каждое аппаратное устройство может содержать память QQ390-1, которая может быть непостоянной памятью для временного хранения инструкций QQ395 или программного обеспечения, выполняемого схемой QQ360 обработки. Каждое аппаратное устройство может содержать один или несколько контроллеров сетевого интерфейса (NIC) QQ370, также известных как карты сетевого интерфейса, которые включают в себя физический сетевой интерфейс QQ380. Каждое аппаратное устройство также может включать в себя непостоянные, постоянные, машиночитаемые носители данных QQ390-2, на которых хранится программное обеспечение QQ395 и/или инструкции, исполняемые схемой QQ360 обработки. Программное обеспечение QQ395 может включать в себя программное обеспечение любого типа, включающее в себя программное обеспечение для создания экземпляров одного или нескольких уровней виртуализации QQ350 (также называемое гипервизорами), программное обеспечение для выполнения виртуальных машин QQ340, а также программное обеспечение, позволяющее ему выполнять функции, признаки и/или преимущества, описанные в отношении с некоторыми вариантами осуществления, описанными в настоящем документе.

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

Во время работы схема QQ360 обработки выполняет программное обеспечение QQ395 для создания экземпляра гипервизора или уровня QQ350 виртуализации, который иногда может называться монитором виртуальной машины (VMM). Уровень QQ350 виртуализации может представлять виртуальную операционную платформу, которая выглядит как сетевое оборудование для виртуальной машины QQ340.

Как показано на фиг. QQ3, аппаратное обеспечение QQ330 может быть автономным сетевым узлом с общими или конкретными компонентами. Аппаратное обеспечение QQ330 может содержать антенну QQ3225 и может реализовывать некоторые функции посредством виртуализации. В качестве альтернативы, аппаратное обеспечение QQ330 может быть частью более крупного кластера аппаратного обеспечения (например, например, в центре обработки данных или оборудовании, расположенного в помещении клиентов (CPE)), где многие аппаратные узлы работают вместе и управляются посредством управления и оркестровки (MANO) QQ3100, который, среди другие курируют управление жизненным циклом приложений QQ320.

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

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

Тем не менее в контексте NFV функция виртуальной сети (VNF) отвечает за обработку определенных сетевых функций, которые выполняются в одной или нескольких виртуальных машинах QQ340 поверх аппаратной сетевой инфраструктуры QQ330 и соответствует приложению QQ320 на фиг. QQ3.

В некоторых вариантах осуществления один или несколько радиоблоков QQ3200, каждый из которых включает в себя один или несколько передатчиков QQ3220 и один или несколько приемников QQ3210, могут быть связаны с одной или несколькими антеннами QQ3225. Радиоблоки QQ3200 могут связываться напрямую с аппаратными узлами QQ330 через один или несколько соответствующих сетевых интерфейсов и могут использоваться в сочетании с виртуальными компонентами для обеспечения виртуального узла возможностями радиосвязи, такими как узел радиодоступа или базовая станция.

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

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

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

Изобретение относится к области возобновления соединения для беспроводного устройства. Техническим результатом является обеспечение возможности возобновить приостановленное UE в e/gNB, который использует более раннюю версию RAT (или ту же версию RAT, но с ограниченными функциональными возможностями), чем та, которая используется исходным eNB, где UE приостановлено (или отправлено в неактивный режим). Способ возобновления соединения с применением полной конфигурации, выполняемый в сетевом узле, причем способ содержит этапы, на которых: принимают от беспроводного устройства запрос на возобновление соединения в сети связи; в ответ на запрос отправляют сообщение возобновления в беспроводное устройство, причем сообщение содержит указание выполнить полную конфигурацию. 6 н. и 32 з.п. ф-лы, 23 ил.

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

принимают от беспроводного устройства запрос на возобновление соединения в сети связи;

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

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

3. Способ по п. 2, дополнительно содержащий этап, на котором устанавливают флаг на полную конфигурацию.

4. Способ по любому из пп. 1-3, в котором сетевой узел имеет технологию радиодоступа, отличную от технологии радиодоступа предшествующего сетевого узла, который приостановил предшествующее соединение для беспроводного устройства.

5. Способ по любому из пп. 1-4, дополнительно содержащий этап, на котором извлекают информацию конфигурации для беспроводного устройства.

6. Способ по п. 5, в котором извлеченная информация конфигурации содержит контекст устройства пользователя (UE) беспроводного устройства.

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

8. Способ по любому из пп. 1-7, в котором сообщение дополнительно содержит параметры конфигурации.

9. Способ по п. 7 или 8, в котором указание содержит указание выполнить полную конфигурацию с использованием указанных параметров конфигурации.

10. Способ по любому из пп. 1-9, в котором ответное сообщение возобновления является одним из RRCConnectionResume и RRCResume.

11. Способ по п. 7, в котором на этапе генерирования параметров конфигурации генерируют контекст уровня доступа (AS) устройства пользователя (UE).

12. Способ по любому из пп. 7-11, в котором генерирование параметров конфигурации основано на контексте S1 и NG, который содержит информацию канала, используемую во время начальной установки контекста.

13. Способ по п. 7 или 8, в котором параметры конфигурации содержат одну или более из конфигурации канала, конфигурации протокола конвергенции пакетных данных (PDCP), конфигурации управления радиоканалом (RLC).

14. Сетевой узел, характеризующийся тем, что выполнен с возможностью:

принимать от беспроводного устройства запрос на возобновление соединения в сети связи; и

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

15. Энергонезависимый машиночитаемый носитель данных, имеющий машиночитаемый программный код, воплощенный на носителе, причем машиночитаемый программный код содержит:

машиночитаемый программный код для приема от беспроводного устройства запроса на возобновление соединения в сети связи;

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

16. Сетевой узел, содержащий:

интерфейс связи; и

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

приема от беспроводного устройства запроса на возобновление соединения в сети связи;

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

17. Сетевой узел по п. 16, в котором указание содержит флаг.

18. Сетевой узел по п. 17, в котором указанный по меньшей мере один процессор выполнен с возможностью устанавливать флаг на полную конфигурацию.

19. Сетевой узел по любому из пп. 16-18, в котором сетевой узел имеет технологию радиодоступа, отличную от технологии радиодоступа предшествующего сетевого узла, который приостановил предшествующее соединение для беспроводного устройства.

20. Сетевой узел по любому из пп. 16-19, в котором указанный по меньшей мере один процессор выполнен с возможностью извлекать информацию конфигурации для беспроводного устройства.

21. Сетевой узел по п. 20, в котором извлеченная информация конфигурации содержит контекст устройства пользователя (UE) беспроводного устройства.

22. Сетевой узел по п. 20 или 21, в котором указанный по меньшей мере один процессор выполнен с возможностью в ответ на определение, что извлеченная информация конфигурации является нечитаемой, генерировать параметры конфигурации.

23. Сетевой узел по любому из пп. 16-22, в котором сообщение дополнительно содержит параметры конфигурации.

24. Сетевой узел по п. 22 или 23, в котором указание содержит указание выполнить полную конфигурацию с использованием указанных параметров конфигурации.

25. Сетевой узел по любому из пп. 16-24, в котором ответное сообщение возобновления является одним из RRCConnectionResume и RRCResume.

26. Сетевой узел по п. 22, в котором указанный по меньшей мере один процессор выполнен с возможностью генерировать параметры конфигурации посредством генерирования нового контекста уровня доступа (AS) устройства пользователя (UE).

27. Сетевой узел по любому из пп. 22-26, в котором указанный по меньшей мере один процессор выполнен с возможностью генерировать новые параметры конфигурации на основании контекста S1 и NG, который содержит информацию канала, используемую во время начальной установки контекста.

28. Сетевой узел по п. 22 или 23, в котором параметры конфигурации содержат одну или более из конфигурации канала, конфигурации протокола конвергенции пакетных данных (PDCP), конфигурации управления радиоканалом (RLC).

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

отправляют в сетевой узел запрос на возобновление соединения в сети связи;

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

применяют полную конфигурацию.

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

31. Способ по п. 29 или 30, дополнительно содержащий этап, на котором сохраняют ключи безопасности.

32. Способ по любому из пп. 29-31, дополнительно содержащий этап, на котором принимают конфигурацию.

33. Способ по п. 32, дополнительно содержащий этап, на котором применяют принятую конфигурацию.

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

отправки в сетевой узел запроса на возобновление соединения в сети связи;

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

применения полной конфигурации.

35. Беспроводное устройство по п. 34, в котором указанный по меньшей мере один процессор выполнен с возможностью отбрасывать ранее использованную конфигурацию канала и ранее использованные параметры радиосвязи.

36. Беспроводное устройство по п. 34 или 35, в котором указанный по меньшей мере один процессор выполнен с возможностью хранить ключи безопасности.

37. Беспроводное устройство по любому из пп. 34-36, в котором указанный по меньшей мере один процессор выполнен с возможностью принимать конфигурацию.

38. Беспроводное устройство по п. 37, в котором указанный по меньшей мере один процессор выполнен с возможностью применять принятую конфигурацию.