ОБНОВЛЕНИЕ TA В RRC_INACTIVE Российский патент 2021 года по МПК H04W76/27 H04W60/00 

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

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

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

Проект партнерства 3-го поколения (3GPP) продолжает прилагать свои усилия по разработке спецификаций для технологии беспроводной связи 5-го поколения, обычно называемой 5G. В новом стандарте 5GS, в стандарте системы и архитектуры для 5G, представлены различные машины состояний для того, чтобы обеспечить доступность пользовательского оборудования (UE).

Одной из таких машин состояний является модель состояний управления соединением или модель состояний CM, описанная в 3GPP TS 23.501. В общем, управление соединением (CM) содержит функции для установления и разъединения соединения сигнализации между UE и функцией управления доступом и мобильностью (AMF).

На фиг. 1 показан пример архитектуры системы 5G, включающей в себя такие узлы, как AMF, UE, сеть радиодоступа (RAN) и названия интерфейсов. Управление подключением связано с сигнализацией подключения через интерфейс N1, показанный на фиг. 1.

Это соединение сигнализации через N1 используется для обеспечения возможности обмена сигнализацией в слое без доступа (NAS) между UE и базовой сетью. Он содержит как соединение сигнализации узел доступа (AN) между UE и AN, так и соединение N2 между AN и AMF.

Определены два состояния CM: CM-IDLE и CM-CONNECTED. UE в CM-IDLE не имеет соединения сигнализации NAS, установленного через N1 с AMF, и в этом CM-состоянии UE выполняет выбор/повторный выбор соты и выбор наземной сети мобильной связи общего пользования (PLMN). Кроме того, в состоянии ожидания отсутствует соединение сигнализации AN или соединения N2/N3 для UE. Если UE зарегистрировано в сети и в CM-IDLE, оно обычно должно прослушивать сообщения поискового вызова из сети и отвечать на них. Это означает, что в состоянии CM-IDLE UE все еще доступно. Если оно инициировано пользователем/UE, UE также должно иметь возможность выполнять процедуру запроса услуги.

UE в CM-CONNECTED представляет собой UE, которое установило соединение сигнализации AN между UE и AN. UE перешло в состояние RRC_CONNECTED через доступ к 3GPP. По этому соединению UE может передать начальное сообщение NAS (например, запрос на обслуживание), и это сообщение инициирует переход из CM-IDLE в CM-CONNECTED в AMF. Из фиг. 1 также видно, что для перехода в CM-CONNECTED необходимо также установить соединение N2 между AN и AMF. Прием начального сообщения N2 (например, сообщения UE "N2 Initial") инициирует переход для AMF из состояния CM-IDLE в состояние CM-CONNECTED.

В состоянии CM-CONNECTED UE может передавать данные и должно быть готово к переходу в CM-IDLE всякий раз, когда разъединяется соединение сигнализации AN. AMF переходит в CM-IDLE всякий раз, когда разъединяются логическое соединение сигнализации N1 и соединение плоскости пользователя N3. Соединение сигнализации AN и разъединение для CM показаны на фиг. 2. Установление и разъединение контекста N2 для CM показаны на фиг. 3.

Аналогичным образом, как и в AMF, существует также модель состояний в сети доступа (AN). В связи с этим мы будем использовать термин "gNB" для узла сети доступа, но он может быть также узлом другого типа, например, ng-eNB, eNB. Таким образом, термин "gNB" следует рассматривать в качестве примера, а не ограничения применимости настоящего изобретения. Одна модель состояния в gNB является машиной состояний RRC.

UE может находиться в состояниях RRC_CONNECTED, RRC_INACTIVE и RRC_IDLE. Отображение между различными машинами состояний, отображение в AN и отображение в AMF является таким, что CM-CONNECTED может отображаться либо в RRC_CONNECTED, либо в RRC_INACTIVE, тогда как CM-IDLE всегда отображается в RRC_IDLE.

UE находится либо в состоянии RRC_CONNECTED, либо в состоянии RRC_INACTIVE, когда было установлено RRC-соединение. Если это не так, то есть RRC-соединение не установлено, UE находится в состоянии RRC_IDLE. Эти различные состояния дополнительно описаны в 3GPP TS 38.331.

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

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

Когда UE находится в состояниях CM-CONNECTED и RRC_INACTIVE, применяется следующее: управление доступностью UE осуществляется RAN с помощью вспомогательной информации из базовой сети; управление поисковым вызовом UE осуществляется RAN; и UE отслеживает поисковый вызов с помощью CN UE (5G S-TMSI) и идентификатора RAN (I-RNTI).

AMF на основе конфигурации сети может предоставлять вспомогательную информацию в NG-RAN, чтобы помочь NG-RAN принять решение относительно того, можно ли перевести UE в неактивное состояние RRC. "Вспомогательная информация RRC неактивно" может, например, включать в себя: значения DRX, специфичные для UE; зону регистрации, предоставленную UE, которая иногда упоминается ниже как TAI-список (TrackingAreaIdentifier List); таймер периодических обновлений регистрации; если AMF активировал состояние MICO для UE, индикацию того, что UE находится в состоянии MICO; и/или информацию из постоянного идентификатора UE, как определено в TS 38.304 [50], которая позволяет RAN вычислять случаи поискового вызова RAN UE.

Вспомогательная информация "RRC неактивно", упомянутая выше, предоставляется AMF во время активации N2 (новым) обслуживающим узлом NG-RAN (то есть во время регистрации, запроса услуги, передачи обслуживания), чтобы помочь RAN NG принять решение относительно того, можно ли перевести UE в неактивное состояние RRC. Состояние "RRC неактивно" является частью машины состояний RRC, и именно RAN определяет условия перехода в неактивное состояние RRC. Если какой-либо из параметров, включенных во вспомогательную информацию "RRC неактивно", изменяется в результате процедуры NAS, AMF должна обновить вспомогательную информацию "RRC неактивно" для узла NG-RAN.

Состояние контрольных точек N2 и N3 не изменяется при переходе UE в CM-CONNECTED при неактивном состоянии RRC. UE в неактивном состоянии RRC знает о зоне уведомлений RAN (RNA). UE в состоянии RRC_INACTIVE может быть сконфигурировано с RNA, где: RNA может охватывать одну или несколько сот и может быть меньше, чем зона регистрации CN; обновление зоны уведомления на основе RAN (RNAU) периодически отправляется UE, а также отправляется, когда процедура повторного выбора соты UE выбирает соту, которая не принадлежит к сконфигурированной RNA.

Существует несколько различных альтернатив того, как можно сконфигурировать RNA: список сот; список зон RAN; и/или список идентификаторов зоны отслеживания (TAI). Что касается списка сот: UE предоставляется явный список сот (один или несколько), которые образуют RNA. Что касается списка зон RAN: UE предоставляется (по меньшей мере один) идентификатор (ID) зоны RAN, где зона RAN является поднабором зоны отслеживания CN; и/или сота передает (по меньшей мере один) ID зоны RAN в системной информации, так что UE знает то, к какой зоне принадлежит сота.

В CM-IDLE именно базовая сеть отвечает за достижимость UE, и базовая сеть делает это путем конфигурирования зоны регистрации CN, которая определяется набором зон отслеживания (TA). UE конфигурируется с зоной регистрации CN через список идентификаторов зон отслеживания (TAI), и эта зона регистрации CN далее упоминается как "TAI-список".

При переходе в CM-CONNECTED с неактивным состоянием RRC NG-RAN конфигурирует UE с таймером периодических обновлений зоны уведомлений RAN с учетом значения таймера периодических обновлений регистрации, указанного в информации о неактивной помощи RRC, и использует защитный таймер со значением, превышающим значение таймера обновления зоны уведомления RAN, предоставленное UE. Если защитный таймер периодических обновлений зоны уведомлений RAN истекает в RAN, RAN должна инициировать процедуру разъединения AN, как указано в TS 23.502.

Когда UE находится в CM-CONNECTED при неактивном состоянии RRC, UE выполняет процедуры выбора PLMN, как определено в TS 23.122 для CM-IDLE. Когда UE находится в состоянии CM-CONNECTED при неактивном состоянии RRC, UE может возобновить RRC-соединение из-за: ожидаемых данных восходящей линии связи; процедуры сигнализации NAS инициированной мобильным устройством; в ответ на поисковый вызов RAN; уведомления сети о том, что она покинула зону уведомлений RAN; и/или по истечении таймера периодических обновлений RAN.

В LTE UE выполняет TAU, инициируемое мобильностью, например, когда UE после выполнения повторного выбора соты обнаруживает зону отслеживания, которая не входит в список зон отслеживания, которые UE ранее зарегистрировало в объекте управления мобильностью (MME).

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

Затем процедура TAU инициируется уровнем NAS в UE и начинается с передачи сообщения "запроса TAU" с уровня NAS в UE в MME. В RRC_IDLE UE должно сначала подключиться к RAN, прежде чем оно сможет передать сообщение NAS в MME, что выполняется с помощью сообщения RRRConnectionRequest с параметром causeValue, равным "mo-signaling". Это инициирует установку временного RRC-соединения. В большинстве случаев UE или сеть не имеет данных для отправки, что означает, что сеть переведет UE в состояние RRC_IDLE как можно скорее. Когда CN завершает работу с TAU, она разъединяет соединение CN/RAN, которое инициирует eNB для отправки сообщения RRRConnectionRelease после того, как сообщение NAS "TAU Accept" было отправлено в UE. В случае, если UE имеет данные UL для отправки вместе с TAU, сообщение NAS "запрос TAU" будет иметь флаг, указывающий на это. Аналогичным образом, если в сети имеются данные DL или управляющая сигнализация, ожидающая UE, CN может инициировать настройку контекста UE в RAN, чтобы RAN могла устанавливать безопасность и однонаправленные радиоканалы передачи данных в направлении UE.

На фиг. 4 показана временная диаграмма возможной процедуры обновления зоны отслеживания в RRC_IDLE для UE в NR на основе процедуры TAU из LTE. Для UE в RRC_INACTIVE в системе 5G и для радиодоступа, известного как NG-RAN (RAN следующего поколения), было согласовано, что UE также будет выполнять TAU при переходе в новую TA (то есть в TA, которая не является частью зарегистрированного списка ТА UE), и это должно выполняться с использованием сигнализации RRC. Следовательно, чтобы отправить TAU в 5G-CN, UE должно отправить сообщение на свой уровень AS. Когда уровень RRC в UE в RRC_INACTIVE принимает сообщение NAS "запрос TAU", ему нужно будет подключиться к сети, и это должно быть сделано с помощью сообщения RRRConnectionResumeRequest.

Как и в случае с LTE, в большинстве случаев передача/прием данных не осуществляется, и сеть не должна поддерживать UE в состоянии RRC_CONNECTED. Следовательно, чтобы разрешить это, RRCConnectionResumeRequest должен указать RAN, что это сообщение было инициировано из-за запроса NAS. Чтобы указать, что возобновление предназначено только для сигнализации NAS, в сообщении RRRConnectionResumeRequest должно быть установлено значение причины, соответствующее "mo-signaling".

Если сеть может извлечь контекст AS UE, она может ответить сообщением RRRConnectionResume, и UE отправит "запрос TAU", совмещенный в сообщении RRRConnectionResumeComplete. Так как соединение CN/RAN поддерживается в RRC_INACTIVE, его сначала необходимо переместить, прежде чем сообщение NAS может быть переадресовано в CN. И после того, как CN завершит работу с TAU, оно отправит сообщение NAS "получение TAU" ("TAU Accept") в UE, как показано на фиг. 5A.

Так как UE выполняет TAU в RRC_INACTIVE, когда оно обнаруживает, что оно входит в новую (незарегистрированную) зону отслеживания, поиск контекста UE может иногда терпеть неудачу. Например, если UE с длинными циклами DRX перемещается далеко от исходного gNB, может прерваться Xn-соединение между целевым и исходным gNB. В любом случае процедура TAU из RRC_INACTIVE должна иметь возможность обрабатывать случай, когда сохраненный контекст UE не может быть извлечен.

Если контекст не может быть успешно извлечен, gNB ответит на RRRConnectionResumeRequest, указывающий mo-signaling, с помощью RRRConnectionSetup для создания нового контекста UE. На фиг. 5B показано обновление зоны отслеживания UE в RRC_INACTIVE с неудачным извлечением контекста UE.

Как можно заметить из фиг. 5A и 5B, после того как CN завершила работу с TAU и передала сообщение NAS "получение TAU" в UE, gNB должен дождаться истечения таймера неактивности, прежде чем он сможет снова приостановить UE. Это связано с тем, что сообщения NAS прозрачны для RAN, и так как соединение CN/RAN сохраняется, ни AS в gNB, ни в UE не будут знать, что CN завершила работу с TAU.

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

Когда UE находится в RRC_INACTIVE, следовательно, в CM-CONNECTED, оно все еще выполняет обновления зоны регистрации CN из-за мобильности и, в частности, это необходимо в случае, если UE перемещается в соту, которая не принадлежит ни к одной из зон отслеживания в списке TAI.

В то же время, когда UE перемещается/повторно выбирает такую соту, оно может также выйти за пределы какой-либо RNA, так как разрешенная RNA может включать только те соты, которые являются частью TA в списке TAI.

Таким образом, в данном документе признается, что может быть ситуация для UE в RRC_INACTVE, когда как AS, так и NAS инициируют необходимость обновления.

NAS инициирует потребность в обновлении зоны отслеживания. AS инициирует необходимость обновления RNA из-за мобильности, так как UE оставило свою сконфигурированную RNA. Таким образом, проблема состоит в том, что UE может инициировать их друг за другом.

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

Варианты осуществления настоящего изобретения позволяют сети избежать ненужного перехода UE в состояние RRC_CONNECTED и предоставляют решение, которое позволяет избежать любых "дублированных процедур", когда UE инициирует как RNAU, так и TAU.

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

В одном аспекте настоящего изобретения, с точки зрения UE, UE выполнено с возможностью выполнения обновлений RNA и обновлений зоны отслеживания при пересечении границы списка зон отслеживания (и в то же время при пересечении границы списка RNA, так как эти границы перекрываются). UE сначала инициирует обновление RNA. Например, UE отправляет запрос на возобновление RRC со значением причины, связанным с обновлением RNA (например, "rna-update"), и ожидает сообщения о возобновлении RRC. И после приема сообщения о возобновлении RRC UE переходит к RRC_CONNECTED и отправляет сообщение о завершении возобновления RRC, мультиплексированное с сообщением NAS об обновлении зоны отслеживания.

Следует отметить, что возможны случаи, когда UE пересекает только RNA и остается в одной и той же TA или в одном и том же списке TA. В этих случаях UE отправляет запрос на возобновление и просто ожидает сообщения о приостановке. Принимая во внимание приведенное ниже обсуждение, будет понятно, что это позволяет сети использовать оптимизированную процедуру, при которой UE немедленно переводится в неактивное состояние RRC, например, когда сеть определила для себя, что необходимо обновление зоны отслеживания (TAU), или когда сеть просто хочет вызвать отдельную процедуру TAU, если необходимо TAU. В сообщении о приостановке UE может быть назначен новый I-RNTI (ID возобновления) и в некоторых вариантах осуществления новая RNA.

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

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

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

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

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

С точки зрения сети, когда gNB принимает сообщение с запросом на возобновление RRC из UE, включая указание на обновление зоны уведомлений RAN (RNAU), сеть извлекает контекст этого UE, и если выборка контекста является успешной, gNB проверяет, принадлежит ли сота, через которую UE в данный момент времени осуществляет доступ, к TA, которая представлена в списке TAI, который принимается во вспомогательной информации "RRC неактивно" и сохраняется в контексте UE. Если имеется несоответствие и текущие обслуживающие соты не принадлежат ни к одной из перечисленных TA, gNB отвечает на запрос на возобновление RNAU сообщением о возобновлении и переводит UE в RRC_CONNECTED, чтобы согласно способу, выполняемому в UE и описанному в первой части описания, UE отправляет запрос на обновление зоны отслеживания (TAU), мультиплексированный с сообщением о завершении RRC-возобновления. С другой стороны, если нет несоответствия, gNB может вместо этого немедленно ответить сообщением о приостановке RRC, например, если нет данных нисходящей линии связи, буферизованных для UE, тем самым избегая перехода UE в подключенное состояние RRC.

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

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

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

В другом аспекте настоящего изобретения, когда UE принимает сообщение о возобновлении RRC в ответ на запрос на возобновление RRC со значением причины, указывающим обновление зоны RAN, оно всегда должно выполнять процедуру обновления зоны отслеживания. Эту процедуру можно инициировать путем включения указания TAU NAS в сообщение 5. Сообщение 5 обычно является полным сообщением, отправляемым UE в сеть, например, завершено возобновление RRC. В случае, если UE приостановлено в MSG4 (сеть не отправляет возобновление "Resume"), UE, скорее всего, не нужно отправлять MSG5. Но если UE возобновляется, оно отправляет сообщение 5. Сообщение 5 может совмещать сообщения NAS, такие как обновление регистрации UE. В этом аспекте обновление зоны отслеживания должно выполняться независимо от того, идентифицировал ли NAS в UE необходимость процедуры обновления зоны отслеживания.

В первом варианте предыдущего способа, с точки зрения UE, UE отправляет запрос на возобновление RRC со значением причины, связанным с обновлением RNA (например, 'rna-update'), но при этом ожидает либо сообщения о возобновлении RRC, либо сообщения RRC, приостанавливающего работу UE (например, сообщение о разъединении с указанием приостановки). Если UE принимает сообщение о возобновлении RRC, оно действует, как описано в первом параграфе, иначе, если оно принимает сообщение RRC, приостанавливающее UE (например, разъединение с указанием о приостановке), UE затем переходит к RRC_INACTIVE. До сих пор этот вариант является таким же, с точки зрения UE, как и первый вышеописанный способ.

Однако в этом варианте, если UE AS позже принимает указание из UE NAS о том, что обновление зоны отслеживания должно быть инициировано, оно отправляет запрос на возобновление RRC со значением причины "mo-signaling", чтобы затем принять и возобновить RRC и отправить запрос TAU, мультиплексированный с сообщением о завершении возобновления "Resume Complete".

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

В этом варианте, с точки зрения сети, когда gNB принимает сообщение с запросом на возобновление RRC из UE, включая указание на обновление зоны уведомлений RAN (RNAU), сеть может принять решение относительно того, извлечь ли контекст этого UE, выполнить ли действия, описанные во втором абзаце, или просто перевести UE непосредственно в RRC_INACTIVE, чтобы иметь возможность упростить реализацию сети с тем, чтобы UE в случае необходимости выполняло TAU, снова инициировало процедуру и отправляло запрос на возобновление RRC со значением причины 'mo-signaling'.

В еще одном варианте способа (во втором варианте), с точки зрения UE, UE, выполненное с возможностью выполнения обновлений RNA и обновлений зон отслеживания, при пересечении границы списка зон отслеживания (и в то же время при пересечении границы списка RNA, так как эти границы перекрываются), и определения необходимости выполнения обеих процедур обновления RNA и TAU, всегда сначала инициирует обновление зоны отслеживания (TAU), то есть отправляет запрос на возобновление RRC со значением причины, связанным с обновлением (например, 'mo-signaling '), и ожидает сообщения о возобновлении RRC. И после приема сообщения о возобновлении RRC UE переходит в RRC_CONNECTED, и UE отправляет сообщение о завершении возобновления RRC, мультиплексированное с сообщением NAS обновления зоны отслеживания, и продолжает процедуру TAU. В этом варианте UE выполняет только TAU, даже если активированы как и TAU, так и RNA. Таким образом, с внешней точки зрения поведение UE похоже на описанное выше в связи с нормальным TAU. В данном случае различие состоит в том, что объект NAS UE инициировал RNAU, но UE приняло решение выполнять только TAU, так как необходимы как TAU, так и RNAU. Следует отметить, что этот подход эффективен, потому что если UE переходит в RRC_CONNECTED, в этом случае для выполнения TAU менее актуально обновлять RNA, и новая RNA будет сконфигурирована для UE, когда оно позже снова будет приостановлено при переходе в состояние RRC_INACTIVE. Чтобы поддержать этот вариант, уровень RRC UE (или объект, реализующий уровень RRC) будет перенаправлять идентификатор зоны отслеживания (TAI), который он принимает из целевой соты (например, по широковещательному каналу системной информации), на уровень NAS (или объект, реализующий уровень NAS) внутри UE. В этом случае уровень RRC будет ждать ответа с уровня NAS относительно того, требуется или нет TAU, прежде чем определять, следует ли инициировать обновление RNA. Если требуется TAU, то обновление RNA не выполняется.

В этом варианте, с точки зрения сети, когда gNB принимает сообщение с запросом на возобновление RRC из UE, включая указание TAU (например, ‘mo-signalling’), как это выполняется через запрос на возобновление RRC, сеть может извлечь контекст этого UE, который предоставляет ответ в виде сообщения о возобновлении RRC-соединения, и переводит UE в состояние RRC_CONNECTED, подождать сообщение о завершении возобновления RRC, мультиплексированное с сообщением запроса TAU, продолжить список TAU с CN, пока оно также параллельно принимает решение относительно того, изменит ли оно параметры контекста UE, например, I-RNTI, NCC, конфигурацию RNA и т.д., или даже принимает решение относительно того, будет ли это UE переведено в RRC_INACTIVE или RRC_IDLE. Следует отметить, что даже несмотря на то, что мы описали изобретение как применимое в случае одновременного инициирования процедур TAU и RNAU в UE, это может также происходить в других комбинациях процедур NAS/data и AS, таких как: одновременные TAU с NAS, пока UE идентифицирует, что у него в буфере имеются данные UL; одновременные TAU с NAS, пока UE отвечает на поисковый вызов; в этом смысле способ можно было бы интерпретировать как общую обработку одновременных запросов AS и NAS.

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

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

В ситуации, когда сеть получила причину данных UL в сообщении запроса на возобновление (msg3), она в любом случае извлечет контекст UE и ответит сообщением о возобновлении RRC, чтобы перевести UE в RRC_CONNECTED. В этой ситуации RNAU не понадобится, так как UE в любом случае будет сконфигурировано с новой RNA в RRC_Suspend, что может или не может произойти или может произойти намного позже.

Аналогичным образом, если имеются данные DL, ожидающие в узле RAN, который содержит контекст UE, для целевого узла RAN возможно приказать UE перейти в RRC_CONNECTED, даже в том случае, если UE указывает, что оно просто хочет выполнить обновление RNA. Целевой узел RAN может узнать во время выборки контекста UE, имеются ли данные в узле-источнике. Из источника можно сигнализировать в целевой узел через интерфейс X2 или Xn.

Таким образом, в одном аспекте настоящего изобретения причина RNAU должна использоваться только в том случае, если нет другой релевантной причины для отправки запроса на возобновление RRC. Если имеется какая-либо другая причина для отправки возобновления, причину этой другой причины следует указать в сообщении с запросом на возобновление.

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

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

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

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

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

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

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

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

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

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

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

На фиг. 1 показан пример архитектуры системы 5G.

Фиг. 2 иллюстрирует переход состояния CM в UE.

Фиг. 3 иллюстрирует переход состояния CM в AMF.

Фиг. 4 иллюстрирует временную диаграмму обновления зоны отслеживания UE в RRC_IDLE.

Фиг. 5A иллюстрирует временную диаграмму обновления зоны отслеживания UE в RRC_INACTIVE.

Фиг. 5B иллюстрирует временную диаграмму обновления зоны отслеживания UE в RRC_INACTIVE с неудачным поиском контекста UE.

Фиг. 6 - блок-схема, иллюстрирующая примерный сетевой узел доступа согласно некоторым вариантам осуществления.

Фиг. 7A-7C - блок-схема последовательности операций, иллюстрирующая примерные способы, выполняемые в узле сети доступа, согласно некоторым вариантам осуществления.

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

Фиг. 9A-9C - блок-схемы последовательностей операций, иллюстрирующие примерные способы, выполняемые в беспроводном устройстве, согласно некоторым вариантам осуществления.

Фиг. 10 - блок-схема последовательности операций, иллюстрирующая другой примерный способ, выполняемый в беспроводном устройстве, согласно некоторым вариантам осуществления.

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

Фиг. 12 иллюстрирует возобновление RRC-соединения для обновления RNA согласно некоторым вариантам осуществления.

Фиг. 13 иллюстрирует возобновление RRC-соединения для объединенного обновления RNA и TAU согласно некоторым вариантам осуществления.

На фиг. 14 показано возобновление RRC-соединения для обновления RNA согласно некоторым вариантам осуществления.

Фиг. 15 - вариант возобновления RRC-соединения для объединенного обновления RNA и TAU согласно некоторым вариантам осуществления.

Фиг. 16 - примерная система связи согласно некоторым вариантам осуществления.

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

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

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

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

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

Раскрытые в настоящее время способы описаны в контексте стандартов беспроводной связи 5GS. Однако следует понимать, что эти способы могут быть, в общем, применимы к другим сетям беспроводной связи, таким как сеть долгосрочного развития (LTE). Для понимания объема раскрытых в настоящее время технологий и устройств беспроводным устройством может быть UE. Однако эти термины следует понимать в более общем смысле, как относящиеся к беспроводным устройствам, выполненным с возможностью функционирования в качестве терминалов доступа в сети беспроводной связи, независимо от того, являются ли эти беспроводные устройства ориентированными на потребителя устройствами, такими как сотовые телефоны, смартфоны, ноутбуки, планшетные компьютеры с беспроводной связью или т.п., или устройствам межмашинного взаимодействия (M2M) для использования в промышленных приложениях или для обеспечения Интернета вещей (IoT). Аналогичным образом, следует понимать, что термины gNB в целом относятся к базовым станциям или узлам сети доступа в системе беспроводной связи.

Как обсуждалось выше, сеть может избегать ненужного перехода UE в RRC_CONNECTED и инициирования как RLAU, так и TAU. Возможно, RLAU и TAU будут синхронизированы таким образом, чтобы они объединились в передаче сообщений по беспроводной связи. В противном случае, возможно, сеть примет разумное решение на этапе 6, показанном на фиг. 5A и 5B, чтобы не возвращать UE в неактивное состояние, а перевести его в RRC_CONNECTED, чтобы обеспечить ожидаемое TAU.

Один подход состоит в том, что если gNB находится на границе TA, он предполагает, что любое RLAU может быть связано с TAU, и переводит UE в RRC_CONNECTED. Это не является идеальным решением, так как многие UE могут перемещать TA в своем уже сконфигурированном списке TA, поэтому это приводит к тому, что некоторые UE без необходимости переводятся в RRC_CONNECTED. (Термин "RLAU", используемый выше, можно рассматривать как относящийся к RNAU.)

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

Соответственно, на фиг. 6 показана блок-схема, иллюстрирующая примерный узел 30 сети доступа, который может быть сконфигурирован для функционирования в качестве базовой станции. Узел 30 сети доступа может представлять собой, например, gNB 5G. Узел 30 сети доступа предоставляет радиоинтерфейс для беспроводного устройства, например, радиоинтерфейс 5G для передачи по нисходящей линии связи и приема по восходящей линии связи, который реализуется через антенны 34 и схему 36 приемопередатчика. Схема 36 приемопередатчика включает в себя схемы передатчика, схемы приемника и связанные с ними схемы управления, которые в совокупности выполнены с возможностью передачи и приема сигналов в соответствии с технологией радиодоступа с целью предоставления сотовой связи или услуг WLAN, если это необходимо. Согласно различным вариантам осуществления услуги сотовой связи могут функционировать в соответствии с любым одним или несколькими сотовыми стандартами 3GPP, GSM, GPRS, WCDMA, HSDPA, LTE, LTE-Advanced и 5G. Узел 30 сети доступа также включает в себя схему 38 интерфейса связи для связи с узлами в базовой сети, другими одноранговыми радиоузлами и/или другими типами узлов в сети.

Узел 30 сети доступа также включает в себя одну или несколько схем 32 обработки, которые функционально связаны и выполнены с возможностью управления схемой 38 интерфейса связи и/или схемой 36 приемопередатчика. Схема 32 обработки содержит один или несколько цифровых процессоров 42, например, один или несколько микропроцессоров, микроконтроллеров, процессоров цифровых сигналов (DSP), программируемых вентильных матриц (FPGA), сложных программируемых логических устройств (CPLD), специализированных интегральных схем (ASIC) или любую их комбинацию. В более общем смысле, схема 32 обработки может содержать фиксированную схему или программируемую схему, которая специально сконфигурирована посредством выполнения программных инструкций, реализующих описанные в данном документе функциональные возможности, или может содержать некоторую комбинацию фиксированной и программируемой схемы. Процессор(ы) 42 может (могут) быть многоядерным(и).

Схема 32 обработки также включает в себя память 44. Память 44 в некоторых вариантах осуществления хранит одну или несколько компьютерных программ 46 и при необходимости данные 48 конфигурации. Память 44 обеспечивает невременное хранилище для компьютерной программы 46, и она может содержать один или несколько типов машиночитаемых носителей информации, таких как дисковое хранилище, твердотельное запоминающее устройство или любую их комбинацию. В качестве неограничивающего примера, запоминающее устройство 44 может содержать любое одно или несколько из: SRAM, DRAM, EEPROM, флэш-память, которые могут находиться в схеме 32 обработки и/или отдельно от схемы 32 обработки. В общем, память 44 содержит один или несколько типов машиночитаемых носителей информации, обеспечивающих невременное хранение компьютерной программы 46 и любых данных 48 конфигурации, используемых узлом 30 сети доступа. В данном документе "невременный" означает постоянный, полупостоянный, или по меньшей мере временное постоянное хранилище, и включает в себя как долговременное хранилище в энергонезависимой памяти, так и хранилище в рабочей памяти, например, для исполнения программы.

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

Схема 32 обработки также выполнена с возможностью выполнения соответствующего способа 700, показанного на фиг. 7A. Способ 700 включает в себя прием из беспроводного устройства сообщения с запросом на возобновление RRC (этап 702), где сообщение с запросом на возобновление RRC включает в себя указатель причины, указывающий только RNAU в качестве причины для возобновления подключенного состояния RRC. Способ 700 также включает в себя извлечение контекста для беспроводного устройства (этап 704) и определение на основе контекста того, представлен ли TAC соты, принимающей запрос на возобновление RRC, в списке TAI для беспроводного устройства (706). Способ 700 включает в себя выборочный ответ на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI (этап 708).

TAC может быть представлен в списке TAI, и сообщение о приостановке RRC может включать в себя информацию, конфигурирующую беспроводное устройство с новой зоной уведомления сети радиодоступа (RNA). В некоторых случаях TAC не представлен в списке TAI, и способ 700 дополнительно включает в себя прием, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением TAU.

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

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

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

Схема 32 обработки также выполнена с возможностью выполнения соответствующего способа 710, показанного на фиг. 7B. Способ 710 включает в себя прием из беспроводного устройства сообщения с запросом на возобновление RRC, которое включает в себя указатель причины, указывающий сигнализацию мобильности в качестве причины для возобновления подключенного состояния RRC (этап 712). Способ 710 также включает в себя извлечение контекста для беспроводного устройства (этап 714) и ответ на сообщение с запросом на возобновление RRC сообщением о возобновлении RRC (этап 716). Способ 710 дополнительно включает в себя прием, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением TAU (этап 718). Способ 710 также может включать в себя определение в ответ на сообщение с запросом на возобновление RRC того, следует ли изменить параметры контекста UE или перевести беспроводное устройство в неактивное состояние RRC, не дожидаясь истечения таймера неактивности RRC для беспроводного устройства.

В других вариантах осуществления схема 32 обработки узла 30 сети доступа выполнена с возможностью приема из беспроводного устройства сообщения с запросом на возобновление RRC. Сообщение с запросом на возобновление RRC включает в себя указатель причины, указывающий RNAU в качестве причины для возобновления подключенного состояния RRC. Схема 32 обработки выполнена с возможностью извлечения контекста для беспроводного устройства и определения на основе контекста того, представлен ли код зоны отслеживания (TAC) соты, принимающей запрос на возобновление RRC, в списке идентификаторов зоны отслеживания (TAI) для беспроводного устройства. Схема 32 обработки выполнена с возможностью выборочного ответа на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если представлен TAC в списке TAI.

Схема 32 обработки также выполнена с возможностью выполнения соответствующего способа 720, показанного на фиг. 7C. Способ 720 включает в себя прием из беспроводного устройства сообщения с запросом на возобновление RRC, которое включает в себя указатель причины, указывающий RNAU в качестве причины для возобновления подключенного состояния RRC (этап 722). Способ 720 также включает в себя извлечение контекста для беспроводного устройства (этап 724) и определение на основе контекста того, представлен ли TAC соты, принимающей запрос на возобновление RRC, в списке TAI для беспроводного устройства (этап 726). Способ 720 дополнительно включает в себя выборочный ответ на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI (этап 728).

TAC может быть представлен в списке TAI, и сообщение о приостановке RRC может включать в себя информацию, конфигурирующую беспроводное устройство с новой зоной уведомления сети радиодоступа (RNA). TAC может быть не представлен в списке TAI, и способ 720 может дополнительно содержать прием, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением TAU.

На фиг. 8 показан пример беспроводного устройства 50, которое выполнено с возможностью выполнения описанных в данном документе технологий для беспроводного устройства. Беспроводное устройство 50 может также упоминаться в различных контекстах как устройство радиосвязи, UE, целевое устройство, UE на основе связи между устройствами (D2D), UE на основе связи машинного типа или UE, способное к межмашинному взаимодействию (M2M), оборудованное датчиками UE, персональный цифровой помощник (PDA), беспроводной планшетный компьютер, мобильный терминал, смартфон, оборудование, встроенное в портативный компьютер (LEE), установленное в портативном компьютере (LME), беспроводной электронный USB-ключ, клиентское оборудование (CPE) и т.д.

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

Беспроводное устройство 50 также включает в себя одну или несколько схем 52 обработки, которые функционально связаны со схемой 56 радиоприемопередатчика и управляют ею. Схема 52 обработки содержит одну или несколько схем цифровой обработки, например, один или несколько микропроцессоров, микроконтроллеров, DSP, FPGA, CPLD, ASIC или любое их сочетание. В более общем смысле, схема 52 обработки может содержать фиксированную схему или программируемую схему, которая специально адаптирована для выполнения программных инструкций, реализующих описанные в данном документе функциональные возможности, или может содержать некоторое сочетание фиксированных и запрограммированных схем. Схема 52 обработки может быть многоядерной.

Схема 52 обработки также включает в себя память 64. Память 64 в некоторых вариантах осуществления хранит одну или несколько компьютерных программ 66 и при необходимости данные 68 конфигурации. Память 64 обеспечивает невременное хранилище для компьютерной программы 66, и она может содержать один или несколько типов машиночитаемых носителей информации, таких как дисковое хранилище, твердотельное запоминающее устройство или любое их сочетание. В качестве неограничивающего примера память 64 содержит любую одну или несколько из SRAM, DRAM, EEPROM и FLASH-памяти, которые могут находиться в схеме 52 обработки и/или отдельно от схемы 52 обработки. В общем, память 64 содержит один или несколько типов машиночитаемых носителей информации, обеспечивающих невременное хранение компьютерной программы 66 и любых данных 68 конфигурации, используемых беспроводным устройством 50.

Соответственно, в некоторых вариантах осуществления схема 52 обработки беспроводного устройства 50 выполнена с возможностью определения, во время нахождения в неактивном состоянии RRC, того, что необходимы как RNAU, так и TAU. Схема 32 обработки также выполнена с возможностью передачи сообщения с запросом на возобновление RRC в сеть в ответ на определение. Сообщение с запросом на возобновление RRC включает в себя указатель причины, указывающий только RNAU в качестве причины для возобновления подключенного состояния RRC.

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

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

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

На фиг. 9A показана блок-схема последовательности операций, иллюстрирующая соответствующий способ 900, реализованный в беспроводном устройстве 50. Как показано на этапе 902, способ 900 включает в себя определение, во время нахождения в неактивном состоянии RRC, того, что необходимы как RNAU, так и TAU. Способ 900 также включает в себя передачу сообщения с запросом на возобновление RRC в сеть в ответ на определение (этап 904). Сообщение с запросом на возобновление RRC включает в себя указатель причины, указывающий только RNAU в качестве причины для возобновления подключенного состояния RRC.

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

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

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

В некоторых вариантах осуществления способ 910 в беспроводном устройстве, показанном на фиг. 9B, включает в себя определение, во время нахождения в неактивном состоянии RRC, того, что требуется RNAU (этап 912). Определение того, что требуется RNAU, может включать в себя повторный выбор соты, в ходе которого выбирается сота, не принадлежащая RNA, сконфигурированной для беспроводного устройства. Способ 910 включает в себя оценку того, существует ли какая-либо другая причина для возобновления подключенного состояния RRC, помимо необходимости в RNAU (этап 914), и передачу сообщения с запросом на возобновление RRC в сеть в ответ на определение (этап 916). Сообщение с запросом на возобновление RRC включает в себя указатель причины, причем указатель причины указывает RNAU только в том случае, если упомянутая оценка не идентифицирует никакой другой причины для возобновления подключенного состояния RRC. В некоторых случаях оценка того, существует ли какая-либо другая причина для возобновления подключенного состояния RRC, включает в себя определение того, что требуется TAU. Указатель причины указывает сигнализацию мобильности в качестве причины возобновления подключенного состояния RRC. В других случаях оценка того, существует ли какая-либо другая причина для возобновления подключенного состояния RRC, включает в себя определение того, имеются ли какие-либо данные восходящей линии связи в буфере беспроводного устройства, и определение того, нужно ли беспроводному устройству отвечать на сообщение поискового вызова.

В некоторых вариантах осуществления способ 920, выполняемый в беспроводном устройстве 50, показанном на фиг. 9C, включает в себя определение в неактивном состоянии RRC того, что необходимы как RNAU, так и TAU (этап 922), и передачу сообщения с запросом на возобновление RRC в сеть в ответ на определение (этап 924). Сообщение с запросом на возобновление RRC включает в себя индикатор причины, указывающий сигнализацию мобильности в качестве причины возобновления подключенного состояния RRC. Способ 920 также включает в себя прием сообщения о возобновлении RRC в ответ на запрос на возобновление RRC (этап 926) и инициирование TAU в ответ на прием запроса на возобновление RRC (этап 928). Определение того, что необходимы как RNAU, так и TAU, может включать в себя выполнение повторного выбора соты, в ходе которого выбирается сота, не принадлежащая сконфигурированной RNA.

На фиг. 10 показана другая блок-схема последовательности операций способа, выполняемого в UE, согласно некоторым вариантам осуществления. На этапе 1000 UE инициирует сообщение с запросом на возобновление RRC с целью возобновить RRC-соединение. Обычно это называется передачей msg3.

В поз.1020 выполняется оценка в UE относительно того, каким является тип ответа из сети. Это сообщение иногда называется msg4. Если ответ из сети представляет собой сообщение о возобновлении RRC, которое приказывает UE перейти в RRC_CONNECTED, согласно некоторым вариантам осуществления настоящего изобретения, UE должно выполнить TAU по отношению к базовой сети. Это проиллюстрировано поз.1040. Если msg4 является сообщением 1060 о приостановке RRC, UE должно вместо этого вернуться в RRC_INACTIVE без выполнения TAU 1080.

На фиг. 11 показана другая блок-схема последовательности операций способа, выполняемого в UE, согласно некоторым вариантам осуществления. На фигуре показано, что происходит на стороне сети. В данном документе термин "сетевая сторона" используется для обозначения gNB, ng-eNB или любого другого узла RAN, который поддерживает приостановку работы UE с зоной, подобной RNA, и возобновление работы упомянутого UE по запросу.

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

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

В контексте UE имеется информация относительно того, с каким TAI-списком или с какой зоной регистрации CN сконфигурировано UE. Это сигнализируется из узла базовой сети, как описано выше, и предоставляется в узел сети доступа во вспомогательной информации "RRC неактивно". На этапе 1140 сеть будет проверять список TAI и сопоставлять информацию в этом списке с кодом зоны отслеживания соты, через которую UE в данный момент времени осуществляет доступ к "обслуживающей соте". Эта сота является сотой, в которую UE отправило сообщение с запросом на возобновление. Если TAC обслуживающей соты представлен в TAI-списке, то сеть выберет ответ на запрос на возобновление сообщением о приостановке RRC (этап 1160). В сообщении о приостановке RRC (RRC-Suspend) UE может быть сконфигурировано с новой RNA или может сохранить свою старую RNA. Кроме того, идентификаторы могут обновляться или не обновляться, так что UE в следующий раз, когда оно приостанавливается, может использовать другие или те же идентификаторы. UE будет приостановлено и перейдет обратно в состояние RRC_INACTIVE.

Если TAC обслуживающей соты не представлен в TAI-списке UE, как указано в информации о неактивной поддержке RRC, сеть ответит сообщением/процедурой 1180 возобновления RRC, которая выполнит переход UE из RRC_INACTIVE в RRC_CONNECTED. Это также указывает на то, что UE должно выполнить обновление зоны отслеживания.

UE может инициировать обновление зоны отслеживания уже в следующем сообщении из UE в сеть, msg5, указывающем TAU для NAS. Это дополнительно проиллюстрировано в схемах сигнализации на фиг. 12-15. Примеры вариантов осуществления могут включать в себя, в UE, ответ на сообщение msg3 со значением причины, указывающим, что UE должно выполнить обновление RNA; получить msg4, которое является сообщением о возобновлении функционирования; UE должно по меньшей мере выполнить обновление зоны отслеживания.

Другие примеры могут включать в себя, в сети, в случае приема сообщения msg3 с RNAU причины возобновления, извлечение контекста, и если CN Reg Area (список TAI) не включает в себя TAC текущей обслуживающей соты, отправку сообщения о возобновлении в msg4. Иначе, если CN Reg Area (список TAI) действительно включает в себя TAC обслуживающей в данный момент соты; отправку сообщения о приостановке в msg4, в противном случае, отправку сообщения о настройке RRRConnection в msg4.

Фиг. 12-13 используются для иллюстрации некоторых вариантов установления RRC-соединения. На фиг. 12 показано возобновление RRC-соединения (обновление RNA), и на фиг. 13 показано возобновление RRC-соединения (объединенное обновление RNA и TAU). Примерный текст для описания этих вариантов осуществления в документах стандартизации 3GPP может включать следующее:

------------------------------------------------------------------------------------------------------------

5.3.3.1

Целью этой процедуры является установление или возобновление RRC-соединения или выполнение обновления RNA. Установление RRC-соединения включает в себя установление SRB1 (и SRB1bis для NB-IoT). Процедура также используется для передачи начальной выделенной информации/сообщения NAS из UE в E-UTRAN.

E-UTRAN применяет процедуру следующим образом: при установлении RRC-соединения установить SRB1 и, для NB-IoT, SRB1bis; при возобновлении RRC-соединения восстановить конфигурацию AS из сохраненного контекста, включая возобновление SRB и DRB.

5.3.3.2 Инициирование

UE инициирует процедуру, когда более высокие уровни запрашивают установление или возобновление RRC-соединения тогда, когда UE находится в RRC_INACTIVE. UE использует процедуру возобновления при выполнении процедуры обновления зоны уведомлений RAN (RNAU).

После инициирования процедуры UE должно:

1> если UE возобновляет RRC-соединение:

...

1> запустить таймер T300;

1> если UE возобновляет RRC-соединение:

2> инициировать передачу сообщения RRCResumeRequest в соответствии с 5.3.3.3a;

1> иначе:

2> если оно сохранено, отбросить контекст AS UE и i-rnti;

2> инициировать передачу сообщения RRRConnectionRequest в соответствии с 5.3.3.3;

5.3.3.3a Действия, которые относятся к передаче сообщения RRRConnectionResumeRequest.

UE должно установить содержание сообщения RRCResumeRequest следующим образом:

...

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

2> установить для параметра resumeCause значение rna-update;

1> иначе

2> установить значение resumeCause в соответствии с информацией, принятой с верхних уровней;

...

UE должно представить сообщение RRRConnectionResumeRequest на нижние уровни для передачи.

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

5.3.3.4a Прием UE RRRConnectionResume

UE должно:

1> остановить таймер T300;

...

1> ввести RRC_CONNECTED;

1> указать более высоким уровням, что приостановленное RRC-соединение было возобновлено;

...

1> установить содержание сообщения RRRConnectionResumeComplete следующим образом:

...

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

...

1> отправить сообщение RRRConnectionResumeComplete на нижние уровни для передачи;

1> процедура завершается.

По истечении T300

UE должно:

1> если таймер T300 истекает:

...

2> информировать более высокие уровни об отказе установить RRC-соединение или об отказе возобновить RRC-соединение с указанием о приостановке, после чего процедура завершается;

Следует отметить, что после приема этого указания об отказе верхний уровень продолжит отправку сообщения после восстановления AS. В случае неудачного возобновления работы NAS из-за обновления зоны отслеживания одновременно с обновлением RNA, когда более высокие уровни запрашивают еще раз выполнить TAU, обновление RNA не выполняется.

В некоторых вариантах осуществления для первого второго варианта в ответ на запрос на возобновление RRC со значением причины 'rna-update' UE может принять либо сообщение о возобновлении RRC, либо сообщение о разъединении/приостановке RRC.

Если UE принимает сообщение о возобновлении, оно может вести себя точно так, как описано в тексте выше. Если UE принимает сообщение о приостановке после отправки обновления RNA, оно должно просто перейти в RRC_INACTIVE, и затем оно получит запрос из NAS для выполнения TAU, то есть оно отправит еще один запрос на возобновление RRC со значением причины 'mo-signaling', как также описано выше.

Другие варианты осуществления включают в себя первый второй вариант. В ответ на запрос на возобновление RRC со значением причины "rna-update" UE может принять сообщение о возобновлении RRC или сообщение об отключении/приостановке RRC.

Если UE принимает сообщение о возобновлении, оно может вести себя точно так, как описано в тексте выше. Если UE принимает сообщение о приостановке после отправки обновления RNA, оно должно просто перейти в RRC_INACTIVE, и затем оно получит запрос из NAS для выполнения TAU, то есть оно отправит еще один запрос на возобновление RRC со значением причины 'mo-signaling', как также описано выше.

Некоторые варианты осуществления включают в себя второй вариант, как показано на фиг. 14-15, показывающий вариант возобновления RRC-соединения (обновления RNA) и возобновления RRC-соединения (объединенного обновления RNA и TAU).

Целью этой процедуры является установление или возобновление RRC-соединения или выполнение обновления RNA. Установление RRC-соединения включает в себя установление SRB1 (и SRB1bis для NB-IoT). Процедура также используется для передачи начальной выделенной информации/сообщения NAS из UE в E-UTRAN.

E-UTRAN применяет процедуру следующим образом: при установлении RRC-соединения, установить SRB1 и, для NB-IoT, SRB1bis; при возобновлении RRC-соединения, восстановить конфигурацию AS из сохраненного контекста, включая возобновление SRB и DRB.

Этот вариант поясняется приведенным ниже текстом, аналогичным тексту выше.

5.3.3.2 Инициирование

UE инициирует процедуру, когда более высокие уровни запрашивают установление или возобновление RRC-соединения тогда, когда UE находится в RRC_INACTIVE. UE использует процедуру возобновления при выполнении процедуры RNAU (обновление зоны уведомлений RAN).

После инициирования процедуры UE должно:

...

1> если UE возобновляет RRC-соединение:

...

1> запустить таймер T300;

1> если UE возобновляет RRC-соединение:

2> инициировать передачу сообщения RRCResumeRequest в соответствии с 5.3.3.3a;

1> иначе:

2> если оно сохранено, отбросить контекст AS UE и i-rnti;

2> инициировать передачу сообщения RRRConnectionRequest в соответствии с 5.3.3.3;

5.3.3.3a Действия, которые относятся к передаче сообщения RRRConnectionResumeRequest

UE должно установить содержание сообщения RRCResumeRequest следующим образом:

...

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

2> установить для параметра resumeCause значение mo-signaling и не выполнять обновление RNA;

1> иначе

2> установить значение resumeCause в соответствии с информацией, принятой с верхних уровней;

...

UE должно представить сообщение RRRConnectionResumeRequest на нижние уровни для передачи.

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

5.3.3.4a Прием UE RRCConnectionResume

UE должно:

1> остановить таймер T300;

...

1> ввести RRC_CONNECTED;

1> указать более высоким уровням, что приостановленное RRC-соединение было возобновлено;

...

1> установить содержание сообщения RRRConnectionResumeComplete следующим образом:

...

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

...

1> отправить сообщение RRRConnectionResumeComplete на нижние уровни для передачи;

1> процедура завершается.

5.3.3.6 По истечение T300

UE должно:

1> по истечении таймера T300:

...

2> информировать более высокие уровни об отказе установить RRC-соединение или об отказе возобновить RRC-соединение с указанием о приостановке, после чего процедура завершается;

Следует отметить, что после приема этого указания об отказе верхний уровень продолжит отправку сообщения, когда AS будет восстановлена. В случае неудачного возобновления работы NAS из-за обновления зоны отслеживания одновременно с обновлением RNA, когда более высокие уровни запрашивают еще раз выполнить TAU, обновление RNA не выполняется.

------------------------------------------------------------------------------------------------------------

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

Некоторые варианты осуществления изобретения включают в себя UE, всегда выбирающее любую причину возобновления, отличную от обновления RNA, если такая причина применима, перед выбором причины обновления RNA при отправке запроса на возобновление RRC. Таким образом, когда имеется потребность в RNAU, если одновременно имеется какая-либо другая потребность из UE в возобновлении, должно быть выбрано значение причины для другой потребности.

На фиг. 16, в соответствии с различными вариантами осуществления, показана система связи, которая включает в себя телекоммуникационную сеть 1610, такую как сотовая сеть типа 3GPP, которая содержит сеть 1611 доступа, такую как gNB-RAN, и базовую сеть 1614 (например, 5GC). Сеть 1611 доступа содержит множество базовых станций 1612a, 1612b, 1612c. Каждая базовая станция 1612a, 1612b, 1612c может быть подключена к базовой сети 1614 через проводное или беспроводное соединение 1615. Первое пользовательское оборудование (UE) 1691, расположенное в зоне 1613c покрытия, выполнено с возможностью беспроводного подключения к или передачи сигналов поискового вызова с помощью соответствующей базовой станции 1612c. Второе UE 1692 в зоне 1613a покрытия беспроводным образом подключается к соответствующей базовой станции 1612a. Хотя в этом примере проиллюстрировано множество UE 1691, 1692, раскрытые варианты осуществления в равной степени применимы к ситуации, когда одиночное UE находится в зоне покрытия, или когда одиночное UE подключается к соответствующей базовой станции 1612.

Телекоммуникационная сеть 1610 подключена непосредственно к хост-компьютеру 1630, который может быть осуществлен в виде аппаратных средств и/или программного обеспечения автономного сервера, сервера, реализованного в облаке, распределенного сервера или в виде ресурсов обработки в ферме серверов. Хост-компьютер 1630 может находиться в собственности или под управлением поставщика услуг или может управляться поставщиком услуг или от имени поставщика услуг. Соединения 1621 и 1622 между телекоммуникационной сетью 1610 и хост-компьютером 1630 могут продолжаться непосредственно от базовой сети 1614 до хост-компьютера 1630 или могут проходить через вспомогательную промежуточную сеть 1620. Промежуточная сеть 1620 может представлять собой одну или комбинацию из более чем одной: общедоступной, частной или развернутой сети; промежуточной сети 1620, если таковая имеется, может представлять собой магистральную сеть или Интернет; в частности, промежуточная сеть 1620 может содержать две или более подсетей (не показаны).

Система связи, показанная на фиг. 16, в целом обеспечивает связность между подключенными UE 1691, 1692 и хост-компьютером 1630. Связность может быть описана как соединение 1650 поверх протокола IP (OTT). Хост-компьютер 1630 и подключенные UE 1691, 1692 выполнены с возможностью передачи данных и/или сигнализации через OTT-соединение 1650, используя сеть 1611 доступа, базовую сеть 1614, любую промежуточную сеть 1620 и возможную дополнительную инфраструктуру (не показана) в качестве посредников. OTT-соединение 1650 может быть прозрачным в том смысле, что участвующие устройства связи, через которые проходит OTT-соединение 1650, не знают о маршрутизации передач по восходящей и нисходящей линиям связи. Например, базовая станция 1612 может не знать или не нуждаться в информации о прошлой маршрутизации входящей передачи по нисходящей линии связи с данными, исходящими из хост-компьютера 1630, которые должны пересылаться (например, при передаче обслуживания) в подключенное UE 1691. Аналогичным образом, базовой станции 1612 не нужно знать о будущей маршрутизации исходящей передачи по восходящей линии связи, исходящей от UE 1691 в направлении хост-компьютера 1630.

Примерные реализации, в соответствии с вариантом осуществления, UE, базовой станции и хост-компьютера, обсужденные в предыдущих абзацах, теперь будут описаны со ссылкой на фиг. 17. В системе 1700 связи хост-компьютер 1710 содержит аппаратные средства 1715, включая интерфейс 1716 связи, выполненный с возможностью установления и поддержания проводного или беспроводного соединения с интерфейсом другого устройства связи системы 1700 связи. Хост-компьютер 1710 дополнительно содержит схему 1718 обработки, которая может иметь возможности хранения и/или обработки. В частности, схема 1718 обработки может содержать один или несколько программируемых процессоров, специализированные интегральные схемы, программируемые пользователем вентильные матрицы или их комбинации (не показаны), выполненные с возможностью исполнения инструкций. Хост-компьютер 1710 дополнительно содержит программное обеспечение 1711, которое хранится в или к которому обращается хост-компьютер 1710 и исполняется схемой 1718 обработки. Программное обеспечение 1711 включает в себя хост-приложение 1712. Хост-приложение 1712 может быть выполнено с возможностью предоставления услуги удаленному пользователю, такому как UE 1730, подключенному через OTT-соединение 1750, заканчивающееся в UE 1730 и хост-компьютере 1710. При предоставлении услуги удаленному пользователю хост-приложение 1712 может предоставлять пользовательские данные, которые передаются с использованием OTT-соединения 1750.

Система 1700 связи дополнительно включает в себя базовую станцию 1720, предусмотренную в телекоммуникационной системе и содержащую аппаратные средства, позволяющие ей обмениваться данными с хост-компьютером 1710 и с UE 1730. Аппаратные средства могут включать в себя интерфейс 1726 связи для настройки и поддержания проводного или беспроводного соединения с интерфейсом другого устройства связи системы 1700 связи, а также радиоинтерфейсом для установления и поддержания по меньшей мере беспроводного соединения 1770 с UE 1730, расположенным в зоне покрытия (на фиг. 17 не показана), обслуживаемой базовой станцией 1720. Интерфейс связи может быть выполнен с возможностью облегчения соединения 1760 с хост-компьютером 1710. Соединение 1760 может быть прямым, или оно может проходить через базовую сеть (на фиг. 17 не показана) телекоммуникационной системы и/или через одну или несколько промежуточных сетей за пределами телекоммуникационной системы. В показанном варианте осуществления базовая станция 1720 содержит блок 10 управления (например, gNB-CU), который управляет точками 30 радиодоступа (например, gNB-DU), которые обмениваются данными с UE 1730 и могут выполнять передачу обслуживания для него. Точка 30 радиодоступа была подробно описана ранее со ссылкой на фиг. 6.

Система 1700 связи дополнительно включает в себя уже упомянутое UE 1730. Его аппаратные средства 1735 могут включать в себя радиоинтерфейс 1737, выполненный с возможностью установления и поддержания беспроводного соединения 1770 с базовой станцией, обслуживающей зону покрытия, в которой в данный момент времени находится UE 1730. Аппаратные средства 1735 UE 1730 дополнительно включают в себя схему 1738 обработки, которая может содержать одно или более из: программируемых процессоров, специализированных интегральных схем, программируемых пользователем вентильных матриц или их комбинации (не показаны), адаптированные для исполнения инструкций. UE 1730 дополнительно содержит программное обеспечение 1731, которое хранится в UE 1730 или доступно для него и исполняется схемой 1738 обработки. Программное обеспечение 1731 включает в себя клиентское приложение 1732. Клиентское приложение 1732 может быть выполнено с возможностью предоставления услуги пользователю человеку или не человеку через UE 1730, с поддержкой хост-компьютера 1710. В хост-компьютере 1710 исполняющее хост-приложение 1712 может обмениваться данными с исполняющимся клиентским приложением 1732 через OTT-соединение 1750, оканчивающееся в UE 1730 и хост-компьютере 1710. При предоставлении услуги пользователю клиентское приложение 1732 может принимать данные запроса из хост-приложения 1712 и предоставлять пользовательские данные в ответ на данные запроса. OTT-соединение 1750 может передавать как данные запроса, так и пользовательские данные. Клиентское приложение 1732 может взаимодействовать с пользователем для выработки пользовательских данных, которые он предоставляет.

Следует отметить, что хост-компьютер 1710, базовая станция 1720 и UE 1730, показанные на фиг. 17, могут быть аналогичны или идентичны хост-компьютеру 1630, одной из базовых станций 1612a, 1612b, 1612c и одному из UE 1691, 1692, которые показаны на фиг. 16, соответственно. То есть внутренняя работа этих объектов может быть такой, как показано на фиг. 17, и независимо от этого топология окружающей сети может быть такой же, как на фиг. 16.

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

Беспроводное соединение 1770 между UE 1730 и базовой станцией 1720 находится в соответствии с идеями вариантов осуществления, описанных в настоящем раскрытии. Один или более различных вариантов осуществления позволяют повысить производительность услуг OTT, предоставляемых UE 1730 с использованием OTT-соединения 1750, в котором беспроводное соединение 1770 образует последний сегмент. Более конкретно, идеи этих вариантов осуществления позволяют сети избежать ненужного перевода UE в состояние RRC_CONNECTED и предоставить решение, которое позволяет избежать каких-либо "дублированных процедур", когда UE инициирует как RLAU, так и TAU. Эти варианты осуществления приведут к повышенной производительности, такой как повышенная и/или более согласованная пропускная способность и/или уменьшенные задержки для пользователей RAN, в том числе во время переходов в состояния ожидания/соединения.

Процедура измерения может выполняться с целью контроля скорости передачи данных, задержки и других показателей, которые улучшают один или несколько вариантов осуществления. Кроме того, могут существовать дополнительные сетевые функциональные возможности для реконфигурирования OTT-соединения 1750 между хост-компьютером 1710 и UE 1730 в ответ на изменения результатов измерений. Процедура измерения и/или сетевые функциональные возможности для реконфигурирования OTT-соединения 1750 могут быть реализованы в виде программного обеспечения 1711 хост-компьютера 1710 или в виде программного обеспечения 1731 UE 1730 или и того и другого. В вариантах осуществления датчики (не показаны) могут быть развернуты в или в связи с устройствами связи, через которые проходит OTT-соединение 1750; датчики могут участвовать в процедуре измерения, предоставляя значения контролируемых величин, приведенных в качестве примера выше, или предоставляя значения других физических величин, на основе которых программное обеспечение 1711, 1731 может вычислить или оценить контролируемые величины. Реконфигурирование OTT-соединения 1750 может включать в себя формат сообщения, настройки повторной передачи, предпочтительную маршрутизацию и т.д.; реконфигурирование не должно влиять на базовую станцию 1720, и оно может быть неизвестным или незаметным для базовой станции 1720. Такие процедуры и функциональные возможности известны и могут быть осуществлены в данной области техники. В некоторых вариантах осуществления измерения могут включать в себя собственную сигнализацию UE, облегчающую измерения, проводимые хост-компьютером 1710, пропускной способности, времени распространения, задержки и т.п. Измерения могут быть реализованы таким образом, чтобы программное обеспечение 1711 и 1731 заставляло передавать сообщения, в частности пустые или "фиктивные" сообщения с использованием OTT-соединения 1750, контролируя при этом время распространения, ошибки и т.д.

На фиг. 18 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи в соответствии с одним из вариантов осуществления. Система связи включает в себя хост-компьютер, базовую станцию и UE, которые аналогичны тем, которые описаны со ссылкой на фиг. 16 и 17. Для упрощения настоящего раскрытия в этом абзаце будут использоваться ссылки только на фиг. 18. На первом этапе 1810 хост-компьютер предоставляет пользовательские данные. На необязательном подэтапе 1811 первого этапа 1810 хост-компьютер предоставляет пользовательские данные путем исполнения хост-приложения. На втором этапе 1820 хост-компьютер инициирует передачу, переносящую пользовательские данные в UE. На необязательном третьем этапе 1830 базовая станция передает в UE пользовательские данные, которые были перенесены при передаче, инициированной хост-компьютером, в соответствии с идеями вариантов осуществления, описанных в настоящем раскрытии. На необязательном четвертом этапе 1840 UE исполняет клиентское приложение, связанное с хост-приложением, исполняемым хост-компьютером

На фиг. 19 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи в соответствии с одним из вариантов осуществления. Система связи включает в себя хост-компьютер, базовую станцию и UE, которые аналогичны тем, которые описаны со ссылкой на фиг. 16 и 17. Для упрощения настоящего раскрытия в этом абзаце будут использоваться ссылки только на фиг. 19. На первом этапе 1910 способа хост-компьютер предоставляет пользовательские данные. На необязательном подэтапе (не показан) хост-компьютер предоставляет пользовательские данные путем исполнения хост-приложения. На втором этапе 1920 хост-компьютер инициирует передачу, переносящую пользовательские данные в UE. Передача может проходить через базовую станцию в соответствии с идеями вариантов осуществления, описанных в настоящем раскрытии. На необязательном третьем этапе 1930 UE принимает пользовательские данные, переносимые при передаче.

На фиг. 20 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи в соответствии с одним из вариантов осуществления. Система связи включает в себя хост-компьютер, базовую станцию и UE, которые аналогичны тем, которые описаны со ссылкой на фиг. 16 и 17. Для упрощения настоящего раскрытия в этом абзаце будут использоваться ссылки только на фиг. 20. На необязательном первом этапе 2010 способа UE принимает входные данные, предоставленные хост-компьютером. Дополнительно или альтернативно, на необязательном втором этапе 2020 UE предоставляет пользовательские данные. На необязательном подэтапе 2021 второго этапа 2020 UE предоставляет пользовательские данные, исполняя клиентское приложение. В дополнительном необязательном подэтапе 2011 первого этапа 2010 UE исполняет клиентское приложение, которое предоставляет пользовательские данные в ответ на полученные входные данные, предоставленные хост-компьютером. При предоставлении пользовательских данных исполняемое клиентское приложение может дополнительно учитывать пользовательский ввод, полученный от пользователя. Независимо от конкретного способа, которым были предоставлены пользовательские данные, UE инициирует, на необязательном третьем подэтапе 2030, передачу пользовательских данных в хост-компьютер. На четвертом этапе 2040 способа хост-компьютер принимает пользовательские данные, переданные из UE, в соответствии с идеями вариантов осуществления, описанными в настоящем раскрытии.

На фиг. 21 показана блок-схема последовательности операций, иллюстрирующая способ, реализованный в системе связи, в соответствии с одним вариантом осуществления. Система связи включает в себя хост-компьютер, базовую станцию и UE, которые могут быть такими, которые описаны со ссылкой на фиг. 16 и 17. Для упрощения настоящего раскрытия в этот раздел будут включены только ссылки на чертежи на фиг. 21. На необязательном первом этапе 2110 способа в соответствии с идеями вариантов осуществления, описанными в этом раскрытии, базовая станция принимает пользовательские данные из UE. На необязательном втором этапе 2120 базовая станция инициирует передачу принятых пользовательских данных на хост-компьютер. На третьем этапе 2130 хост-компьютер принимает пользовательские данные, переносимые при передаче, инициированной базовой станцией.

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

На фиг. 22 показана примерная архитектура функционального модуля или схемы, которые могут быть реализованы в узле 30 сети доступа. Реализация включает в себя модуль 2202 приема для приема из беспроводного устройства сообщения с запросом на возобновление RRC, где сообщение с запросом на возобновление RRC включает в себя указатель причины, указывающий сигнализацию мобильности в качестве причины для возобновления подключенного состояния RRC. Реализация также включает в себя модуль 2204 извлечения контекста для извлечения контекста для беспроводного устройства и модуль 2206 ответа для ответа на сообщение с запросом на возобновление RRC сообщением о возобновлении RRC. Модуль 2202 приема также предназначен для приема, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением TAU.

На фиг. 23 показан другой пример функционального модуля или архитектуры схемы, которые могут быть реализованы в узле 30 сети доступа. Реализация включает в себя модуль 2202 приема для приема, из беспроводного устройства сообщения с запросом на возобновление RRC, причем упомянутое сообщение с запросом на возобновление RRC содержит указатель причины, указывающий только RNAU в качестве причины для возобновления подключенного состояния RRC. Реализация может включать в себя модуль 2204 извлечения контекста для извлечения контекста для беспроводного устройства, и модуль 2206 определения для определения на основе контекста того, представлен ли TAC соты, принимающей запрос на возобновление RRC, в списке TAI для беспроводного устройства. Реализация включает в себя модуль 2208 ответа для выборочного ответа на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC в случае, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI. На фиг. 24 показана примерная архитектура функционального модуля или схемы, которые могут быть реализованы в беспроводном устройстве 50. Реализация включает в себя модуль 2402 определения для определения, во время нахождения в неактивном состоянии RRC, того, что требуется RNAU. Реализация также включает в себя модуль 2404 оценки для оценки того, существует ли какая-либо другая причина для возобновления подключенного состояния RRC, помимо необходимости в RNAU, и модуль 2406 передачи для передачи сообщения с запросом на возобновление RRC в сеть в ответ на определение, где запрос на возобновление RRC включает в себя указатель причины, указывающий RNAU в случае, если оценка не выявляет никакой другой причины для возобновления подключенного состояния RRC.

На фиг. 25 показан другой пример функциональной архитектуры модуля или схемы, которые могут быть реализованы в беспроводном устройстве 50. Реализация включает в себя модуль 2502 определения для определения, во время нахождения в неактивном состоянии RRC, того, что необходимы как RNAU, так и TAU, и модуль 2504 передачи для передачи сообщения с запросом на возобновление RRC в сеть в ответ на определение, где сообщение с запросом на возобновление RRC включает в себя указатель причины, указывающий сигнализацию мобильности в качестве причины для возобновления подключенного состояния RRC. Реализация также включает в себя модуль 2506 приема для приема сообщения о возобновлении RRC в ответ на запрос на возобновление RRC и модуль 2508 инициирования для инициирования TAU в ответ на прием запроса на возобновление RRC.

Примерные варианты осуществления

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

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

определение, во время нахождения в неактивном состоянии управления радиоресурсами (RRC), того, что необходимо как обновление зоны уведомления сети радиодоступа (RNAU), так и обновление зоны отслеживания (TAU); и

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

2. Способ согласно примерному варианту 1 осуществления, дополнительно содержащий:

прием сообщения о возобновлении RRC в ответ на запрос на возобновление RRC; и

отправку сообщения о завершении возобновления RRC в ответ на сообщение о возобновлении RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением TAU.

3. Способ согласно варианту 2 осуществления, дополнительно содержащий:

переход в подключенное состояние RRC в ответ на сообщение о возобновлении RRC;

прием, после упомянутого перехода в подключенное состояние RRC, сообщения о приостановке подключения RRC; и

переход в неактивное состояние RRC в ответ на сообщение о приостановке RRC-соединения.

4. Способ согласно варианту 3 осуществления, дополнительно содержащий:

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

5. Способ согласно варианту 3 осуществления, дополнительно содержащий:

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

6. Способ согласно примерному варианту 1 осуществления, дополнительно содержащий:

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

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

7. Способ согласно варианту 6 осуществления, дополнительно содержащий:

определение, после приема сообщения о приостановке подключения RRC, того, что требуется TAU; и в ответ на это

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

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

определение, во время нахождения в неактивном состоянии управления радиоресурсами (RRC), того, что необходимо обновление зоны уведомления сети радиодоступа (RNAU);

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

прием сообщения о возобновлении RRC в ответ на запрос на возобновление RRC; и

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

9. Способ согласно варианту 8 осуществления, в котором упомянутое инициирование содержит:

отправку сообщения о завершении возобновления RRC в ответ на сообщение о возобновлении RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением TAU

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

определение, во время нахождения в неактивном состоянии управления радиоресурсами (RRC), того, что необходимо как обновление зоны уведомления сети радиодоступа (RNAU), так и обновление зоны отслеживания (TAU);

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

прием сообщения о возобновлении RRC в ответ на запрос на возобновление RRC; и

инициирование обновления зоны отслеживания (TAU) в ответ на прием запроса на возобновление RRC.

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

определение, во время нахождения в неактивном состоянии управления радиоресурсами (RRC), того, что необходимо обновление зоны уведомления сети радиодоступа (RNAU);

оценку того, существует ли какая-либо другая причина для возобновления подключенного состояния RRC, помимо необходимости RNAU; и

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

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

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

14. Способ, выполняемый в узле сети доступа системы беспроводной связи, содержащий:

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

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

определение на основе контекста того, представлен ли код зоны отслеживания (TAC) соты, принимающей запрос на возобновление RRC, в списке идентификаторов зоны отслеживания (TAI) для беспроводного устройства; и

выборочный ответ на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI.

15. Способ согласно примерному варианту 14 осуществления, в котором TAC представлен в списке TAI, и в котором сообщение о приостановке RRC включает в себя информацию, конфигурирующую беспроводное устройство с новой зоной уведомления сети радиодоступа (RNA).

16. Способ согласно варианту 15 осуществления, в котором TAC не представлен в списке TAI, и в котором способ дополнительно содержит прием, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением об обновлении зоны отслеживания (TAU).

17. Способ, выполняемый в узле сети доступа системы беспроводной связи, содержащий:

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

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

ответ на сообщение с запросом на возобновление RRC сообщением о возобновлении RRC; и

прием, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением обновления зоны отслеживания (TAU).

18. Способ согласно примерному варианту 17 осуществления, дополнительно содержащий определение в ответ на сообщение с запросом на возобновление RRC того, следует ли изменить параметры контекста UE, или следует ли перевести беспроводное устройство в неактивное состояние RRC без ожидания таймера неактивности RRC для беспроводного устройства до его истечения.

19. Беспроводное устройство, выполненное с возможностью выполнения способов согласно любому из примерных вариантов 1-13 осуществления.

20. Узел сети доступа, выполненный с возможностью выполнения способов согласно любому из примерных вариантов 14-18 осуществления.

21. Компьютерная программа, содержащая инструкции, которые при их исполнении по меньшей мере в одной схеме обработки предписывают по меньшей мере одной схеме обработки выполнять способ согласно любому из примерных вариантов 1-18 осуществления.

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

23. Способ, реализованный в системе связи, содержащей хост-компьютер, базовую станцию и пользовательское оборудование (UE), содержащий:

в хост-компьютере, предоставление пользовательских данных; и

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

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

извлечение контекста для UE;

определение на основе контекста того, представлен ли код зоны отслеживания (TAC) соты, принимающей запрос на возобновление RRC, в списке идентификаторов зоны отслеживания (TAI) для UE; и

выборочный ответ на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI.

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

в хост-компьютере, предоставление пользовательских данных; и

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

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

извлечение контекста для UE;

ответ на сообщение с запросом на возобновление RRC сообщением о возобновлении RRC; и

прием, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением обновления зоны отслеживания (TAU).

25. Способ согласно примерному варианту 24 или 25 осуществления, дополнительно содержащий:

в базовой станции, передачу пользовательских данных.

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

причем способ дополнительно содержит:

в UE, исполнение клиентского приложения, ассоциированного с хост-приложением.

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

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

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

извлечение контекста для UE;

определение на основе контекста того, представлен ли код зоны отслеживания (TAC) соты, принимающей запрос на возобновление RRC, в списке идентификаторов зоны отслеживания (TAI) для UE; и

выборочный ответ на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI.

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

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

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

извлечение контекста для UE;

ответ на сообщение с запросом на возобновление RRC сообщением о возобновлении RRC; и

прием, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением обновления зоны отслеживания (TAU).

29. Способ согласно примерному варианту 27 или 28 осуществления, дополнительно содержащий:

в базовой станции, прием пользовательских данных из UE.

30. Способ согласно варианту 29 осуществления, дополнительно содержащий:

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

31. Система связи, включающая в себя хост-компьютер, содержащий:

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

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

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

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

извлечения контекста для UE;

определения на основе контекста того, представлен ли код зоны отслеживания (TAC) соты, принимающей запрос на возобновление RRC, в списке идентификаторов зоны отслеживания (TAI) для UE; и

выборочного ответа на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI.

32. Система связи, содержащая хост-компьютер, содержащая:

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

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

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

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

извлечения контекста для UE;

ответа на сообщение с запросом на возобновление RRC сообщением о возобновлении RRC; и

приема, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением обновления зоны отслеживания (TAU).

33. Система связи согласно примерному варианту 31 или 32 осуществления, дополнительно включающая в себя базовую станцию.

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

35. Система связи согласно любому из примерных вариантов 31-34 осуществления, в которой:

схема обработки хост-компьютера выполнена с возможностью исполнения хост-приложения, тем самым предоставляя пользовательские данные; и

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

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

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

извлечения контекста для UE;

определения на основе контекста того, представлен ли код зоны отслеживания (TAC) соты, принимающей запрос на возобновление RRC, в списке идентификаторов зоны отслеживания (TAI) для UE; и

выборочного ответа на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI.

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

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

извлечения контекста для UE;

ответа на сообщение с запросом на возобновление RRC сообщением о возобновлении RRC; и

приема, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит или объединено с сообщением обновления зоны отслеживания (TAU).

38. Система связи согласно примерному варианту 36 или 37 осуществления, дополнительно содержащая базовую станцию.

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

40. Система связи согласно любому из примерных вариантов 36-39 осуществления, в которой:

хост-компьютер содержит схему обработки, выполненную с возможностью исполнения хост-приложения; и

UE выполнено с возможностью исполнения клиентского приложения, ассоциированного с хост-приложением, тем самым предоставляя пользовательские данные, которые должны быть приняты хост-компьютером.

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

Изобретение относится к области беспроводной связи. Технический результат заключается в возможности избегать любой дублированной сигнализации. Беспроводное устройство связи определяет, во время нахождения в неактивном состоянии управления радиоресурсами (RRC) по отношению к сети беспроводной связи, что необходимо обновление зоны уведомления сети радиодоступа (RNAU); оценивает, существует ли какая-либо другая причина для возобновления подключенного состояния RRC, помимо необходимости в RNAU; и передает сообщение с запросом на возобновление RRC в сеть беспроводной связи в ответ на упомянутое определение, причем упомянутое сообщение с запросом на возобновление RRC содержит указатель причины, при этом упомянутый указатель причины указывает RNAU в случае, когда упомянутая оценка не идентифицирует никакой другой причины для возобновления подключенного состояния RRC. 7 н. и 13 з.п. ф-лы, 30 ил.

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

определяют, во время нахождения в неактивном состоянии управления радиоресурсами (RRC) по отношению к сети беспроводной связи, что необходимо обновление зоны уведомления сети радиодоступа (RNAU);

оценивают, существует ли какая-либо другая причина для возобновления подключенного состояния RRC, помимо необходимости в RNAU; и

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

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

3. Способ по п. 1 или 2, в котором на этапе оценки, имеется ли какая-либо другая причина для возобновления подключенного состояния RRC, определяют, что необходимо обновление зоны отслеживания (TAU), при этом указатель причины указывает сигнализацию мобильности в качестве причины для возобновления подключенного состояния RRC.

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

5. Способ по п. 3, дополнительно содержащий этапы, на которых:

принимают сообщение о возобновлении RRC в ответ на запрос на возобновление RRC; и

инициируют TAU в ответ на прием запроса на возобновление RRC.

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

7. Способ связи, выполняемый в узле сети доступа системы беспроводной связи, содержащий этапы, на которых:

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

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

отвечают на сообщение с запросом на возобновление RRC сообщением о возобновлении RRC; и

принимают, в ответ на сообщение о возобновлении RRC, сообщение о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит сообщение об обновлении зоны отслеживания (TAU) или объединено с ним.

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

9. Способ связи, выполняемый в узле сети доступа системы беспроводной связи, содержащий этапы, на которых:

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

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

определяют на основе контекста, представлен ли код зоны отслеживания (TAC) соты, принимающей запрос на возобновление RRC, в списке идентификаторов зоны отслеживания (TAI) для беспроводного устройства связи; и

выборочно отвечают на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI.

10. Способ по п. 9, в котором TAC представлен в списке TAI, при этом сообщение о приостановке RRC включает в себя информацию, конфигурирующую беспроводное устройство связи с новой зоной уведомления сети радиодоступа (RNA).

11. Способ по п. 10, в котором TAC не представлен в списке TAI, при этом способ дополнительно содержит этап, на котором принимают в ответ на сообщение о возобновлении RRC сообщение о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит сообщение об обновлении зоны отслеживания (TAU) или объединено с ним.

12. Узел сети доступа, содержащий:

схему (36) приемопередатчика, выполненную с возможностью передачи и приема сигналов согласно технологии радиодоступа; и

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

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

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

ответа на сообщение с запросом на возобновление RRC сообщением о возобновлении RRC; и

приема, в ответ на сообщение о возобновлении RRC, сообщения о завершении возобновления RRC, причем сообщение о завершении возобновления RRC содержит сообщение об обновлении зоны отслеживания (TAU) или объединено с ним.

13. Узел сети доступа, содержащий:

схему (36) приемопередатчика, выполненную с возможностью передачи и приема сигналов согласно технологии радиодоступа; и

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

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

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

определения на основе контекста, представлен ли код зоны отслеживания (TAC) соты, принимающей запрос на возобновление RRC, в списке идентификаторов зоны отслеживания (TAI) для беспроводного устройства связи; и

выборочного ответа на сообщение с запросом на возобновление RRC либо сообщением о возобновлении RRC, если TAC не представлен в списке TAI, либо сообщением о приостановке RRC, если TAC представлен в списке TAI.

14. Беспроводное устройство (50) связи, содержащее:

схему (56) приемопередатчика, выполненную с возможностью передачи и приема сигналов согласно технологии радиодоступа; и

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

определения, во время нахождения в неактивном состоянии управления радиоресурсами (RRC) по отношению к сети беспроводной связи, что необходимо обновление зоны уведомления сети радиодоступа (RNAU);

оценки, существует ли какая-либо другая причина для возобновления подключенного состояния RRC помимо необходимости в RNAU; и

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

15. Беспроводное устройство (50) связи по п. 14, в котором схема (52) обработки выполнена с возможностью определения, что необходимо RNAU, путем выполнения повторного выбора соты, в ходе которого выбирается сота, не принадлежащая к зоне уведомления сети радиодоступа (RNA), сконфигурированной для беспроводного устройства (50) связи.

16. Беспроводное устройство (50) связи по п. 14 или 15, в котором схема (52) обработки выполнена с возможностью определения, необходимо ли обновление зоны отслеживания (TAU) в дополнение к RNAU, и, в этом случае, использования указателя причины, который указывает сигнализацию мобильности в качестве причины возобновления подключенного состояния RRC.

17. Беспроводное устройство (50) связи по п. 14 или 15, в котором схема (52) обработки выполнена так, что определение того, имеется ли какая-либо другая причина для возобновления подключенного состояния RRC, содержит определение, имеются ли какие-либо данные восходящей линии связи в буфере беспроводного устройства связи, и определение, нужно ли беспроводному устройству связи отвечать на сообщение поискового вызова.

18. Беспроводное устройство (50) связи по п. 16, в котором схема (56) приемопередатчика выполнена с возможностью:

приема сообщения о возобновлении RRC в ответ на запрос на возобновление RRC; и

инициирования TAU в ответ на прием запроса на возобновление RRC.

19. Беспроводное устройство (50) связи по п. 18, в котором определение, что необходимы как RNAU, так и TAU, содержит выполнение повторного выбора соты, в ходе которого выбирается сота, не принадлежащая к сконфигурированной зоне уведомления сети радиодоступа (RNA).

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