ОБЛАСТЬ ТЕХНИКИ

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

ВВЕДЕНИЕ

В типовой беспроводной, сотовой или сети радиосвязи беспроводные устройства, также известные как мобильные станции, терминалы и/или Оборудование Пользователя (UE), осуществляют связь через Сеть Радиодоступа (RAN) с одной или более базовыми сетями. RAN охватывает географическую зону, которая разделена на соты. Каждая сота обслуживается базовой станцией (например, базовой станцией радиосвязи (RBS) или сетевым узлом, который в некоторых сетях также может именоваться как, например, «NodeB», «eNodeB» или «eNB»). Сота является географической зоной, где покрытие радиосвязью обеспечивается базовой станцией радиосвязи на стороне базовой станции или стороне антенны в случае, когда антенна и базовая станция радиосвязи не совмещены. Одна базовая станция радиосвязи может обслуживать одну или более соты.

Универсальная Система Мобильной Связи (UMTS) является системой мобильной связи третьего поколения (3G), которая получила развитие из Глобальной Системы Связи для Подвижных Объектов (GSM) второго поколения (2G). Наземная сеть радиодоступа UMTS (UTRAN) по существу является RAN, использующей широкополосный множественный доступ с кодовым разделением (WCDMA) и/или Высокоскоростной Пакетный Доступ (HSPA), чтобы осуществлять связь с оборудованием пользователя.

На форуме, который называется Проектом Партнерства Третьего Поколения (3GPP), поставщики телекоммуникационных услуг предлагают и согласовывают стандарты для сетей третьего поколения и, в частности UTRAN, и исследуют улучшенную скорость передачи данных и емкость радиосвязи. В некоторых версиях RAN, как например в UMTS, несколько базовых станций может быть соединено (например, посредством наземных линий связи или сверхвысокочастотной связи) с узлом-контроллером, таким как контроллер сети радиосвязи (RNC) или контроллер базовых станций (BSC), который инспектирует и координирует различные активности множества соединенных с ним базовых станций. RNC, как правило, соединен с одной или более базовыми сетями.

В рамках 3GPP были завершены спецификации Развитой Пакетной Системы (EPS) и данная работа продолжается в будущих редакциях 3GPP. EPS содержит Развитую Универсальную Наземную Сеть Радиодоступа (E-UTRAN), также известную как Долгосрочное Развитие (LTE), радиодоступ, и Развитое Пакетное Ядро (EPC), также известное как базовая сеть Развития Системной Архитектуры (SAE). E-UTRAN/LTE является вариантом технологии радиодоступа 3GPP, в которой узлы базовой станции радиосвязи непосредственно соединены с базовой сетью EPC вместо RNC. В целом в E-UTRAN/LTE функции RNC распределены между узлами базовой станции радиосвязи (например, eNodeB в LTE) и базовой сетью. RAN у EPS обладает по существу плоской архитектурой, содержащей узлы базовой станции радиосвязи без представления отчета RNC.

Управление Радиоресурсами (RRC) может быть использовано в плоскости управления. Главные функции плоскости управления включают в себя следующие: широковещательная передача информации системы для поискового вызова как Уровня без Доступа (NAS), так и Уровня Доступа (AS); обработка RRC Соединения; распределение временных идентификаторов для UE; конфигурация носителя(ей) радиосвязи сигнализации для RRC Соединения; обработка носителей радиосвязи; функции администрирования Качества Услуги (QoS); функции обеспечения безопасности, включая администрирование ключей; функции мобильности (включая представление отчета об измерении UE и управление представлением отчета, передачу обслуживания, выбор и повторной выбор соты UE и управление выбором и повторным выбором соты); и прямой перенос сообщения NAS к/от UE.

Один объект Протокола Сходимости Пакетных Данных (PDCP) существует для каждого носителя радиосвязи для UE. PDCP используется как для плоскости управления (т.е., RRC), так и для плоскости пользователя (т.е. данные пользователя принимаются через сигнализацию туннелирования пользователя-протокола туннелирования GPRS (CTP-U)). Основная функция плоскости управления состоит в шифровании/дешифровании и защите целостности. Основные функции плоскости пользователя включают в себя: шифрование/дешифрование, сжатие и распаковка заголовка, используя Устойчивое Сжатие Заголовка (ROHC) и последовательную доставку, обнаружение дубликата и повторную передачу.

Слой Управления Линией Радиосвязи (RLC) предоставляет услуги слою PDCP. Один объект RLC существует для каждого носителя радиосвязи для UE. Основные функции для плоскости как управления, так и пользователя включают в себя: сегментацию/сцепление, обработку повторной передачи, обнаружение дубликата и последовательную доставку верхним слоям.

Управление Доступом к Среде (MAC) предоставляет услуги слою RLC в форме логических каналов и формирует отображение между логическими каналами и транспортными каналами. Основные функции MAC включают: планирование восходящей линии связи и нисходящей линии связи, представление отчета об информации планирования, повторные передачи Гибридного Автоматического Запроса Повторной Передачи (HARQ) и мультиплексирование/демультиплексирование данных по нескольким составляющим несущим применительно к агрегации несущих.

Физический Слой (PHY) предоставляет услуги слою MAC в форме транспортных каналов и обрабатывает отображение транспортных каналов в физических каналах.

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

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

Описанная выше функциональность сетевого узла (например, eNB) может быть развернута разными путями. В одном примере все слои протокола и связанная функциональность развернуты в одном и том же физическом узле, включающем антенну. Одним примером этого является Пико или Фемто eNodeB. Другим примером является разбиение типа Главный-Удаленный. В данном случае eNodeB разделен на главный блок и удаленный блок. Главный блок также может именоваться как Цифровой Блок (DU), а удаленный блок также может именоваться как Удаленный Блок Радиосвязи (RRU). В данном случае основной блок содержит все протоколы связи за исключением нижних частей слоя PHY, которые вместе этого помещены в удаленный блок. В дополнительном примере удаленный блок и антенна являются совмещенными. Это может именоваться системой Антенны с Интегрированным Радиоблоком (AIR).

RAN может обрабатывать неактивные UE. Статья 3GPP R3-161290 (доступна по адресу www.3.gpp.org в /ftp/tsg_ran/WG3_Iu/TSGR3_92/Docs/R3-161290.zip; включена в настоящее описание путем ссылки) на заседании 3GPP RAN 3 WG в мае 2016г. включает в себя предложение в отношении управляемого RAN неактивного состояния, как описано ниже.

Если поддерживается управляемый RAN неактивный режим, то это означает, что переход из неактивного состояния в активное состояние в RAN будет прозрачным для CN. В нисходящей линии связи по умолчанию пакеты нисходящей линии связи будут отправляться последнему узлу, с которым было соединено UE (узел RAN привязки). Тот узел отвечает за инициирование поискового вызова UE в зоне поискового вызова, в которую UE разрешено перемещаться без уведомления сети. В восходящей линии связи UE выполняет процедуру уровня RAN для перехода в активное состояние чтобы передавать данные. Если UE переместилось в другой режим RAN, тогда новый узел RAN будет наиболее вероятно осуществлять выборку контекста UE из другого узла RAN, и при необходимости уведомлять CN о том, что UE переместилось в новый узел. Если UE перемещается за пределы зоны поискового вызова, UE может уведомлять сеть о мобильности с тем, чтобы можно было обновить зону поискового вызова. Данная процедура может инициировать повторное определение местоположения узла RAN или узел RAN может быть сохранен.

Нижеследующие функции RAN могут быть включены для неактивного режима: (a) поисковый вызов для данных нисходящей линии связи; (b) выборка контекста для обработки перемещающихся UE (может быть сходной с существующей процедурой LTE); и (c) обновление мобильности (возможно, что это использует механизм сходный с выборкой контекста). Для обеспечения этих механизмов требуется чтобы UE был распределен уникальный идентификатор RAN, идентифицирующий контекст UE в RAN. В случае, когда происходит любой сбой, при котором невозможно извлечь контекст RAN у UE, предполагается, что контекст RAN может быть воссоздан, как это случилось бы в случае настройки нового соединения. Примеры иллюстрируются на Фигурах 1 и 2.

Фигуры 1 и 2 являются структурными схемами, иллюстрирующими сигнализацию между узлом базовой сети, сетевым узлом и беспроводным устройством. На Фигуре 1 узел 320 базовой сети находится на связи с 3 сетевыми узлами 120. UE 110 было последний раз соединено с сетевым узлом 120b. UE 110 может перемещаться по локальной зоне без представления отчета сети. Узел 320 базовой сети поддерживает соединение с сетевым узлом 120b.

Когда прибывает пакет для доставки UE 110, узел 320 базовой сети контактирует с сетевым узлом 120b. Сетевой узел 120b осуществляет поисковый вызов UE 110. Сетевой узел 120b также выдает инструкцию сетевым узлам 120a и 120b на осуществление поискового вызова UE 110.

На Фигуре 2 узел 320 базовой сети находится на связи с 3 сетевыми узлами 120. UE 110 было последний раз соединено с сетевым узлом 120b. UE 110 может перемещаться в локальной зоне без представления отчета сети. Узел 320 базовой сети поддерживает соединение с сетевым узлом 120b.

Когда UE 110 имеет данные для передачи, UE 110 отправляет запрос соединения или обновления мобильности сетевому узлу 120a, например. Сетевой узел 120a отправляет запрос коммутации канала узлу 320 базовой сети. Сетевой узел 120 также осуществляет выборку контекста UE 110 из сетевого узла 120b.

Базовая сеть Следующего Поколения (NG) должна учитывать конечные автоматы, включенные в протокол RRC в рамках новой RAT. Например, конечный автомат мобильности для RRC может иметь состояние Соединение Неактивно (в дополнение к состоянию RRC Соединено и состоянию RRC Бездействие). Состояние Соединение Неактивно также может именоваться Неактивным состоянием. Конфигурируемость состояния RRC Соединение Неактивно может потребоваться чтобы поддерживать свойства, которые требуют гибкости, такие как разнообразные требования случаев использования 5G, перспективность и быстрое время вывода на рынок новых услуг.

С точки зрения базовой сети Нового Поколения UE считается находящимся в состоянии NG CM-СОЕДИНЕНО, когда UE находится в состоянии RRC Соединение Неактивно на слое RRC. Состояние RRC Соединение Неактивно является состоянием, при котором UE на уровне Уровня Доступа (AS) ведет себя так, как если бы оно было в состоянии RRC_БЕЗДЕЙСТВИЕ. Тем не менее UE по-прежнему обладает выделенным активным соединением сигнализации и каналами плоскости пользователя между ее обслуживающим узлом RAN и CN. Когда UE переходит между состоянием RRC Соединено и состоянием RRC Соединение Неактивно, то событие является невидимым для базовой сети, поскольку не ожидается никакой сигнализации в направлении базовой сети на основании перехода. Также базовая сеть не должна осуществлять поисковый вызов UE, когда UE находится в состоянии RRC Соединение Неактивно, поскольку как плоскость управления, так и плоскость пользователя остаются созданными между RAN и базовой сетью.

Характеристики состояния RRC Соединение Неактивно включают в себя: (a) UE считается находящимся в состоянии NG CM-СОЕДИНЕНО в UE и CN; (b) конфигурируемое для обслуживания услуг(и), запрошенной UE, что означает, что состояние RRC Соединение Неактивно может быть сконфигурировано на основании характеристик и требований приложения(ий), работающего в UE, подписки и активности UE (базовая сеть может предоставлять связанную информацию RAN); (c) основанная на UE мобильность стимулированная процедурой повторного выбора соты с конфигурацией от сети, управляемая сетью передача обслуживания не поддерживается; (d) UE выполняет регистрацию Зоны в CN, когда UE перемещается за пределы зарегистрированной зон(ы); (e) контекст Уровня Доступа (AS) сохраняется в RAN и UE; (f) переход из состояния RRC Соединение Неактивно в состояние RRC Соединено стимулируется процедурами Приостановки и Возобновления, определенными для LTE в Rel-13 (не требуется выполнять сигнализацию перехода для CN и Контекст AS может быть перенесен между узлами RAN); (g) остаются созданными соединения U-плоскости и C-плоскости между RAN и базовой сетью; (h) администрирование достижимостью UE будет осуществляться посредством RAN при поддержке со стороны базовой сети; (i) администрирование поискового вызова UE будет осуществляться посредством RAN; (j) CN будет переходить в состояние NG-CM БЕЗДЕЙСТВИЕ по запросу RAN; (k) распределенное администрирование мобильности при котором сеть сопровождает UE на уровне CN; (l) в данном состоянии не осуществляется Rx/Tx Данных; (m) чтобы поддерживать развертывания LTE и NR эффективным образом решение в отношении перехода состояния должно не допускать или минимизировать сигнализацию UE, когда UE переключается между NR и Развитой E-UTRA в Активном состоянии.

Фигура 3 является схемой перехода состояний, иллюстрирующей конечный автомат RRC в модели конечного автомата NG CM/MM при использовании состояния RRC СОЕДИНЕНИЕ НЕАКТИВНО. Проблема конкретного конечного автомата состоит в том, что переходы между состоянием RRC СОЕДИНЕНО и состоянием RRC СОЕДИНЕНИЕ НЕАКТИВНО считаются как проводимые без сигнализации для NGCN. Это оказывает влияние на определенные функции, поддерживаемые в CN (например, информацию о местоположении UE после перехода в состояние RRC СОЕДИНЕНИЕ НЕАКТИВНО больше нельзя считать надежной, так как UE не информирует сеть о его местонахождении с детализацией, как когда оно находится в состоянии RRC СОЕДИНЕНО, например, на уровне соты).

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

В конкретных вариантах осуществления уведомление включает в себя информацию о местоположении UE. Первым состоянием RRC может быть состояние RRC СОЕДИНЕНО, а вторым состоянием RRC может быть состояние RRC СОЕДИНЕНИЕ НЕАКТИВНО (или просто состояние RRC НЕАКТИВНО). Запрос на подписку может содержать элемент информации (IE) в ЗАПРОСЕ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, а ответ на подписку может содержать IE в ОТВЕТЕ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА.

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

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

В конкретных вариантах осуществления уведомление включает в себя информацию о местоположении UE. Первым состоянием RRC может быть состояние RRC СОЕДИНЕНО, а вторым состоянием RRC может быть состояние RRC СОЕДИНЕНИЕ НЕАКТИВНО. Запрос на подписку может содержать IE в ЗАПРОСЕ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, а ответ на подписку может содержать IE в ОТВЕТЕ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА.

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

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

В конкретных вариантах осуществления уведомление включает в себя информацию о местоположении UE. Первым состоянием RRC может быть состояние RRC СОЕДИНЕНО, а вторым состоянием RRC может быть состояние RRC СОЕДИНЕНИЕ НЕАКТИВНО (или просто состояние RRC НЕАКТИВНО). Запрос на подписку может содержать IE в ЗАПРОСЕ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, а ответ на подписку может содержать IE в ОТВЕТЕ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА.

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

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

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

В конкретных вариантах осуществления уведомление включает в себя информацию о местоположении UE. Первым состоянием RRC может быть состояние RRC СОЕДИНЕНО, а вторым состоянием RRC может быть состояние RRC СОЕДИНЕНИЕ НЕАКТИВНО. Запрос на подписку может содержать IE в ЗАПРОСЕ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, а ответ на подписку может содержать IE в ОТВЕТЕ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА.

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

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

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

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

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

Определенны варианты осуществления настоящего изобретения могут предоставлять одно или более технические преимущества. Например, некоторые варианты осуществления могут преимущественно предоставлять CN возможность подписки на определенную информацию, доступную в RAN (например, переход UE между состоянием RRC СОЕДИНЕНО и состоянием RRC СОЕДИНЕНИЕ НЕАКТИВНО). CN может использовать информацию в качестве входных данных для ее функций (например, основанных на надежности знания о местоположении UE). В качестве примера CN может регулировать свое поведение для осуществления мониторинга местоположения UE во время периодов состояния неактивного соединения, когда UE не соединено с системой на уровне AS и когда не обязательно представлять отчет об изменении местоположения (например, смена соты). Прочие преимущества могут быть легко доступны специалисту в соответствующей области техники. Определенные варианты осуществления могут не иметь, иметь некоторые или все из перечисленных преимуществ.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

Фигура 3 является диаграммой перехода состояния, иллюстрирующей конечный автомат RRC в рамках модели конечного автомата NG CM/MM при использовании состояния RRC СОЕДИНЕНИЕ НЕАКТИВНО;

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

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

Фигура 6 является схемой сигнализации, иллюстрирующей процедуру НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, в соответствии с некоторыми вариантами осуществления;

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

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

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

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

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

Фигура 12A является структурной схемой, иллюстрирующей примерный вариант осуществления сетевого узла;

Фигура 12B является структурной схемой, иллюстрирующей компоненты сетевого узла;

Фигура 13A является структурной схемой, иллюстрирующей примерный вариант осуществления узла базовой сети; и

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

ПОДРОБНОЕ ОПИСАНИЕ

Базовая сеть Нового Поколения (NG) должна учитывать конечные автоматы, включенные в протокол управления радиоресурсами (RRC) в рамках новой радиосвязи (NR) 5G. Например, конечный автомат мобильности для RRC может иметь состояние Соединение Неактивно (в дополнение к состоянию RRC Соединено и состоянию RRC_Бездействие). Состояние Соединение Неактивно также может именоваться как Неактивное состояние. Конфигурируемость состояния RRC Соединение Неактивно может потребоваться чтобы поддерживать свойства, которые требуют гибкости, такие как разнообразные требования случаев использования 5G, перспективность и быстрое время вывода на рынок новых услуг.

С точки зрения базовой сети Нового Поколения оборудование пользователя (UE) считается находящимся в состоянии NG CM-СОЕДИНЕНО, когда UE находится в состоянии RRC Соединение Неактивно на слое RRC. Состояние RRC Соединение Неактивно является состоянием, при котором UE на уровне Уровня Доступа (AS) ведет себя так, как если бы оно было в состоянии RRC_БЕЗДЕЙСТВИЕ. Тем не менее UE по-прежнему обладает выделенным активным соединением сигнализации и каналами плоскости пользователя между ее обслуживающим узлом RAN и базовой сетью (CN). Когда UE переходит между состоянием RRC Соединено и состоянием RRC Соединение Неактивно то событие является невидимым для базовой сети, поскольку не ожидается никакой сигнализации в направлении базовой сети на основании перехода. Также базовая сеть не должна осуществлять поисковый вызов UE, когда UE находится в состоянии RRC Соединение Неактивно, поскольку как плоскость управления

Проблема конкретного конечного автомата состоит в том, что переходы между состоянием RRC СОЕДИНЕНО и состоянием RRC СОЕДИНЕНИЕ НЕАКТИВНО считаются как проводимые без сигнализации для базовой сети следующего поколения (NGCN). Это оказывает влияние на определенные функции, поддерживаемые в CN (например, информацию о местоположении UE после перехода в состояние RRC СОЕДИНЕНИЕ НЕАКТИВНО больше нельзя считать надежной, так как UE не информирует сеть о его местонахождении с детализацией, как когда оно находится в состоянии RRC СОЕДИНЕНО, например, на уровне соты).

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

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

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

Конкретные варианты осуществления описываются со ссылкой на Фигуры 4-13B чертежей, причем аналогичные числа используются для аналогичных и соответствующих частей различных чертежей. LTE и NR используются на всем протяжении данного изобретения в качестве примерных сотовых систем, но идеи, представленные в данном документе, могут также применяться к другим системам беспроводной связи.

Фигура 4 является структурной схемой, иллюстрирующей примерную беспроводную сеть в соответствии с конкретным вариантом осуществления. Беспроводная сеть 100 включает в себя одно или более беспроводные устройства 110 (такие как мобильные телефоны, интеллектуальные телефоны, компьютеры класса лэптоп, планшетные компьютеры устройства MTC или любые другие устройства, которые могут обеспечивать беспроводную связь) и множество сетевых узлов 120 (таких как базовые станции или eNodeB). Сетевой узел 120 обслуживает зону 115 покрытия (также именуемую как сота 115).

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

В некоторых вариантах осуществления беспроводное устройство 110 может именоваться неограничивающим понятием «UE». UE может включать в себя любой тип беспроводного устройства, выполненного с возможностью осуществления связи с сетевым узлом или другим UE через сигналы радиосвязи. UE может быть выполнено в виде устройства радиосвязи, целевого устройства, UE связи типа устройство с устройством (D2D), UE машинного типа или UE с поддержкой связи типа машина с машиной (M2M), датчика, оборудованного UE, iPAD, Планшета, мобильных терминалов, интеллектуальных телефонов, оборудования со встраиваемым лэптопом (LEE), оборудования с монтируемым лэптопом (LME), USB-адаптера, Оборудования Установленного у Пользователя (CPE) и т.д.

В некоторых вариантах осуществления сетевой узел 120 может включать в себя любой тип сетевого узла, такого как базовая станция, базовая станция радиосвязи, базовая станция приемопередатчика, контроллер базовых станций, сетевой контроллер, развитый Узел-B (eNB), Узел-B, базовой станции с поддержкой нескольких RAT, Объект Координации Многоадресной передачи/нескольких сот (MCE), узел-ретранслятор, точка доступа, точка доступа радиосвязи, Удаленный Блок Радиосвязи (RRU), Удаленный Головной Блок Радиосвязи (RRH), узел базовой сети (например, MME, узел SON, координирующий узел и т.д.) или даже внешний узел (например, сторонний узел, узел внешний для текущей сети) и т.д.

Беспроводные сигналы 130 могут включать в себя как передачи нисходящей линии связи (от сетевого узла 120 радиосвязи к беспроводным устройствам 110), так и передачи восходящей линии связи (от беспроводных устройств 110 к сетевому узлу 120 радиосвязи).

Каждый сетевой узел 120 может иметь один передатчик или несколько передатчиков для передачи беспроводных сигналов 130 беспроводным устройствам 110. В некоторых вариантах осуществления сетевой узел 120 может содержать систему с множеством входов и множеством выходов (MIMO). Подобным образом каждое беспроводное устройство 110 может иметь один приемник или несколько приемников для приема сигналов 130 от сетевых узлов 120.

Сеть 100 может включать агрегацию несущих. Например, беспроводное устройство 110 может обслуживаться как сетевым узлом 120a, так и 120b и осуществлять связь для передачи беспроводных сигналов 130 как с сетевым узлом 120a, так и с 120b.

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

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

В некоторых вариантах осуществления узел 320 базовой сети может осуществлять администрирование создания сеансов связи и различные другие функциональные возможности для беспроводных устройство 110. Беспроводные устройства 110 могут осуществлять обмен определенными сигналами с узлом 320 базовой сети, используя слой уровня без доступа. В сигнализации уровня без доступа сигналы между беспроводными устройствами 110 и узлом 320 базовой сети могут прозрачным образом проходить через сеть радиодоступа. В определенных вариантах осуществления сетевые узлы 120 могут взаимодействовать с одним или более сетевыми узлами 120 через меж-узловой интерфейс, такой как, например, интерфейс X2.

Беспроводное устройство 110 может включать в себя информацию о состоянии, такую как информацию о состоянии управления радиоресурсами (RRC). Например, беспроводное устройство 110 может находиться в одном из состояний RRC: БЕЗДЕЙСТВИЕ, СОЕДИНЕНО или СОЕДИНЕНИЕ НЕАКТИВНО. Сетевой узел 120 (или контроллер сети радиосвязи) может управлять состоянием беспроводного устройства 110. В некоторых вариантах осуществления сетевой узел 120 может отправлять уведомления узлу 320 базовой сети или переходы состояния беспроводного устройства 110. Например, узел 320 базовой сети может зарегистрироваться или подписаться на уведомление об изменении состояния беспроводного устройства 110. По определению изменения состояния сетевой узел 120 может уведомлять узел 320 базовой сети об изменении состояния. Уведомление может включать в себя информацию о местоположении. Уведомления о состоянии описываются более подробно ниже в отношении Фигура 5-10.

В беспроводной сети 100 каждый сетевой узел 120 радиосвязи может использовать любую подходящую технологию доступа, такую как долгосрочное развитие (LTE), Усовершенствованное-LTE, NR, UMTS, HSPA, GSM, cdma2000, WiMax, WiFi, и/или другие подходящие технологии радиодоступа. Беспроводная сеть 100 может включать в себя любое подходящее сочетание из одной или более технологий радиодоступа. В качестве примера различные варианты осуществления могут быть описаны в контексте определенных технологий радиодоступа. Тем не менее объем раскрытия не ограничивается примерами и другие варианты осуществления могут использовать отличные технологии радиодоступа.

Как описано выше, варианты осуществления беспроводной сети могут включать в себя одно или более беспроводные устройства и один или более разных типов сетевые узлы радиосвязи, выполненные с возможностью осуществления связи с беспроводными устройствами. Сеть также может включать в себя любые дополнительные элементы, подходящие для обеспечения связи между беспроводными устройствами или между беспроводными устройствами и другим устройством связи (таким как стационарный телефон). Беспроводное устройство может включать в себя любое подходящее сочетание аппаратного обеспечения и/или программного обеспечения. Например, в конкретных вариантах осуществления беспроводное устройство, такое как беспроводное устройство 110, может включать в себя компоненты, описанные ниже в отношении Фигуры 11. Подобным образом сетевой узел может включать в себя любое подходящее сочетание аппаратного обеспечения и/или программного обеспечения. Например, в конкретных вариантах осуществления сетевой узел, такой как сетевой узел 120, может включать в себя компоненты, описанные ниже в отношении Фигуры 12A. Узел базовой сети может включать в себя любое подходящее сочетание аппаратного обеспечения и/или программного обеспечения. Например, в конкретных вариантах осуществления узел базовой сети, такой как узел 320 базовой сети, может включать в себя компоненты, описанные ниже в отношении Фигуры 13A.

Варианты осуществления, раскрытые в данном документе, основаны на принципе, что базовая сеть становится осведомлена о том, находится ли UE в состоянии RRC СОЕДИНЕНИЕ НЕАКТИВНО или может стать находящимся в состоянии RRC СОЕДИНЕНИЕ НЕАКТИВНО. Описываются две группы вариантов осуществления - основанное на подписке уведомление и автономное инициированное RAN уведомление. Эти первичные варианты осуществления, включая их вариации, описываются более подробно ниже.

Конкретные варианты осуществления включают в себя основанное на подписке уведомление. В соответствии с определенными вариантами осуществления CN осуществляет подписку у RAN так, что RAN предоставляет информацию касательно UE, включая находится ли UE в состоянии RRC СОЕДИНЕНО или состоянии RRC СОЕДИНЕНИЕ НЕАКТИВНО, для CN. Информация может быть использована CN чтобы определять, каким образом осуществлять администрирование определенных функций, например, в отношении знаний касательно детализации местоположения UE.

Конкретные варианты осуществления включают в себя функционально-законченную процедура, которая включает в себя процедуру по интерфейсу CN/RAN. Пример иллюстрируется на Фигуре 4.

Фигура 5 является циклограммой, иллюстрирующей подписку базовой сети у сети радиодоступа, в соответствии с некоторыми вариантами осуществления. На этапе 1 UE соединяется с сетью и может принимать и пересылать данные плоскости пользователя и данные плоскости управления. На этапе 2 базовая сеть отправляет RAN запрос на подписку на переходы UE между состоянием RRC СОЕДИНЕНО и состоянием RRC СОЕДИНЕНИЕ НЕАКТИВНО. Запрос может включать в себя параметры, описывающие подробности подписки и/или запросы особых данных (например, запрос текущего местоположения).

На этапе 3 RAN предоставляет ответ базовой сети, указывающий, осуществляет ли RAN принятие запроса подписки из этапа 2, и предоставляет подробности, относящиеся к принятой подписке и/или запрошенным данным (например, ответ текущего местоположения). На этапе 4 по переходу UE (например, из состояния RRC СОЕДИНЕНО в состояние RRC СОЕДИНЕНИЕ НЕАКТИВНО), RAN отправляет уведомление базовой сети. Уведомление может включать в себя параметры, описывающие поведение UE, сконфигурированное сетью. Параметры возможно были запрошены на этапе 2.

Другая альтернатива состоит во включении механизма подписки в процедуру Настройки Соединения, т.е., уже на этапе 1 на Фигуре 4. Альтернативный вариант осуществления подробно описывается ниже на основании процедуры НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА UE в LTE. Новая функция показана по отношению к текущей стандартизованной процедуре. Например, вариант осуществления может быть описан в отношении процедуры Настройки Соединения, описанной в Разделе 8.3.1. документа 3GPP TS 36.413vl3.3.0 (который во всей своей полноте включен в настоящее описание путем ссылки). В соответствии с определенными вариантами осуществления процедура подписки встраивается в процедуру настройки контекста UE по интерфейсу CN/RAN.

Цель процедуры НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА состоит в создании необходимого общего начального Контекста UE, включая контекст E-RAB, Ключ Обеспечения Безопасности, Список Ограничения Передачи Обслуживания, возможности Радиосвязи UE и Возможности Обеспечения Безопасности UE и т.д. Процедура использует ассоциированную с UE сигнализацию. Пример иллюстрируется на Фигуре 6.

Фигура 6 является схемой сигнализации, иллюстрирующей процедуру НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА в соответствии с некоторыми вариантами осуществления. Схема сигнализации является воспроизведением Фигуры 8.3.1.2-1 из документа 3GPP TS 36.413v13.3.0.

В случае создания E-RAB, EPC должно быть подготовлено принимать данные пользователя до того, как сообщение ОТВЕТА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА было принято MME. Если не существует ассоциированного с UE логического S1-соединения, то ассоциированное с UE логическое S1-соединение должно быть создано при приеме сообщения ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА.

Сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА должно содержать в IE Списка E-RAB для Настройки (E-RAB to Be Setup List) информацию, которая требуется eNB, чтобы создать новую конфигурацию E-RAB, состоящую из по меньшей мере одного дополнительного E-RAB.

IE Позиции Списка E-RAB для Настройки может содержать:

- IE NAS-PDU;

- IE ID Корреляции в случае операции LIPA,

- IE ID Корреляции SIPTO в случае операции SIPTO@LN,

- IE Типа Носителя.

Сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА может содержать

- IE Активации Трассировки.

- IE Списка Ограничений Передачи Обслуживания, который может содержать ограничения роуминга или доступа.

- IE Возможности Радиосвязи UE.

- IE ID Профиля Абонента для RAT/приоритета Частоты.

- IE Индикатора Нейтрализации Неисправности CS.

- IE Возможной Операции SRVCC.

- IE Статуса Членства в CSG.

- IE Зарегистрированного LAI.

- IE GUMMEI, который указывает MME, обслуживающий UE и должен присутствовать только в соответствии с подстатьями 4.6.2 и 4.7.6.6 документа TS 36.300.

- IE MME UE S1AP ID 2, который указывает MME UE S1AP ID, назначенный посредством MME, и должен присутствовать только в соответствии с подстатьей 4.6.2 документа TS 36.300.

- IE Разрешенной Основанной на Администрировании MDT.

- IE Списка PLMN Основанной на Администрировании MDT.

- IE Индикатора Дополнительной Нейтрализации Неисправности CS.

- IE Маскированного IMEISV.

- IE Ожидаемого Поведения UE.

- IE Авторизованной ProSe.

- IE Индикатора Поддержки CIoT Плоскости Пользователя UE.

- IE Запроса на Подписку, например, осуществляющий подписку на переход UE между состоянием RRC СОЕДИНЕНО и состоянием RRC СОЕДИНЕНИЕ НЕАКТИВНО.

Сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА должно содержать IE ID Профиля Абонента для RAT/приоритета Частоты, если доступен в MME.

Если IE ID Корреляции включен в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА по отношению к eNB с функцией L-GW для операции LIPA, тогда eNB должен использовать данную информацию для операции LIPA применительно к рассматриваемому E-RAB.

Если IE ID Корреляции SIPTO включен в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА по отношению к eNB с функцией L-GW для операции SIPTO@LN, тогда eNB должен использовать данную информацию для операции SIPTO@LN применительно к рассматриваемому E-RAB.

Если IE Типа Носителя включен в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА и установлен в «не IP», тогда eNB должен не выполнять сжатие заголовка применительно к рассматриваемому E-RAB.

Если IE Маскированного IMEISV содержится в ЗАПРОСЕ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, то целевой eNB должен, если поддерживается, использовать его чтобы определять характеристики UE для последующей обработки.

Если IE Ожидаемого Поведения UE включен в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, то eNB должен, если поддерживается, сохранять данную информацию и может использовать ее, чтобы определять время соединения RRC.

По приему сообщения ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА eNB должно

- пытаться исполнить запрошенную конфигурацию E-RAB.

- сохранять Агрегированную Максимальную Скорость Передачи Битов UE в контексте UE и использовать принятую Агрегированную Максимальную Скорость Передачи Битов UE для не-GBR Носителей применительно к рассматриваемому UE.

- пропускать значение, содержащееся в IE ID E-RAB и IE NAS-PDU, принятое для E-RAB, для каждого созданного носителя радиосвязи Данных, к протоколу радиоинтерфейса. eNB не должен отправлять NAS PDU, ассоциированные с несостоятельными носителями радиосвязи Данных к UE.

- сохранять принятый Список Ограничений Передачи обслуживания в контексте UE.

- сохранять принятые Возможности Радиосвязи UE в контексте UE.

- сохранять принятый ID Профиля Абонента для RAT/приоритет Частоты в контексте UE и использовать его как определено в документе TS 36.300.

- сохранять принятую Возможную Операцию SRVCC в контексте UE и использовать ее как определено в документе TS 23.216.

- сохранять принятые Возможности Обеспечения Безопасности UE в контексте UE.

- сохранять принятый Ключ Обеспечения Безопасности в контексте UE, использовать его и ассоциировать его с начальным значением NCC, как определено в TS 33.401.

- сохранять принятый Статус Членства в CSG, если поддерживается, в контексте UE.

- сохранять принятую информацию Разрешенной Основанной на Администрировании MDT, если поддерживается, в контексте UE.

- сохранять принятую информацию Списка PLMN Основанной на Администрировании MDT, если поддерживается, в контексте UE.

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

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

Применительно к Настройке Начального Контекста начальное значение для Счетчика Цепи Следующего Скачка сохраняется в контексте UE.

Распределение ресурсов в соответствии со значениями IE Приоритета Распределения и Удержания должно следовать принципам, описанным в процедуре Настройки E-RAB.

eNB должен использовать информацию в IE Списка Ограничений Передачи Обслуживания, если присутствует в сообщении ЗАПРОСА НАСТОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, чтобы

- определять цель для последующего действия мобильности, для которое eNB предоставляет информацию о цели действия мобильности по отношению к UE, за исключением того, если IE Индикатора Нейтрализации Неисправности CS установлен в «Высокий Приоритет Нейтрализации Неисправности CS» и не присутствует IE Индикатора Дополнительной Нейтрализации Неисправности CS, в каком случае eNB может использовать информацию в IE Списка Ограничений Передачи Обслуживания;

- выбирать правильную SCG во время операции двойной соединяемости.

Если IE Списка Ограничений Передачи Обслуживания не содержится в сообщении ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, eNB должен считать, что не применяется ограничение роуминга и доступа к UE. eNB также должен считать, что не применяется ограничение роуминга и доступа к UE, когда:

- один из E-RAB настройки имеет конкретное значение ARP (TS 23.401);

- IE Индикатора Нейтрализации Неисправности CS установлен в «Высокий Приоритет Нейтрализации Неисправности CS» и не присутствует IE Индикатора Дополнительной Нейтрализации Неисправности CS и в случае, когда применяется IE Списка Ограничений Передачи Обслуживания, не находят подходящую цель, в каком случае он должен осуществлять обработку в соответствии с документом TS 23.272;

- IE Индикатора Нейтрализации Неисправности CS установлен в «Высокий Приоритет Нейтрализации Неисправности CS» и IE Индикатора Дополнительной Нейтрализации Неисправности CS установлен в «нет ограничения», в каком случае он должен осуществлять обработку в соответствии с документом TS 23.272.

Если IE Активации Трассировки включен в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, тогда eNB должен, если поддерживается, инициировать запрошенную функцию трассировки, как описано в документе TS 32.422. В частности, eNB должен, если поддерживается:

- если IE Активации Трассировки не включает в себя IE Конфигурации MDT, инициировать запрошенный сеанс трассировки, как описано в документе TS 32.422;

- если IE Активации Трассировки включает в себя IE Активации MDT в IE Конфигурации MDT, установленный в «Немедленные MDT и Трассировку», инициировать запрошенный сеанс трассировки и сеанс MDT, как описано в документе TS 32.422;

- если IE Активации Трассировки включает в себя IE Активации MDT в IE Конфигурации MDT, установленный в «Только Немедленная MDT», «только Зарегистрированная MDT» или «Зарегистрированная MBSFN MDT», инициировать запрошенный сеанс MDT как описано в документе TS 32.422 и eNB должен игнорировать IE Интерфейсов для Трассировки и IE Глубины Трассировки.

- если IE Активации Трассировки включает в себя IE Информации Местоположения MDT в IE Конфигурации MDT, сохранять данную информацию и учитывать ее в запрошенном сеансе MDT.

- если IE Активации Трассировки включает в себя IE Списка PLMN основанной на Сигнализации MDT в IE Конфигурации MDT, то eNB может использовать его, чтобы распространять Конфигурацию MDT, как описано в документе TS 37.320.

- если IE Активации Трассировки включает в себя IE MBSFN-ResultToLog в IE Конфигурации MDT, то учитывать его для Конфигурации MDT, как описано в TS 37.320.

- если IE Активации Трассировки включает в себя IE MBSFN-AreaId в IE MBSFN-ResultToLog внутри IE Конфигурации MDT, то учитывать его для Конфигурации MDT, как описано в документе TS 37.320.

Если IE Индикатора Нейтрализации Неисправности CS включен в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, то он указывает, что Контекст UE, который должен быть настроен, подвергается Нейтрализации Неисправности CS. eNB должен отвечать сообщением ОТВЕТА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА и затем действовать как определено в документе TS 23.272.

Если IE Зарегистрированного LAI включен в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, то это указывает на то, что eNB может учитывать IE Зарегистрированного LAI при выборе целевой соты или частоты и затем действовать как определено в документе TS 23.272.

Если IE Возможностей Обеспечения Безопасности UE, включенный в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, содержит только алгоритм EIA0, как определено в документе TS 33.401, и если данный алгоритм EIA0 определен в сконфигурированном списке разрешенных алгоритмом защиты целостности в eNB (TS 33.401), то eNB должен использовать это и игнорировать ключи, принятые в IE Ключа Обеспечения Безопасности.

Если IE GUMMEI содержится в сообщении ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, eNB должен, если поддерживается, сохранять данную информацию в контексте UE и использовать ее для последующих передач обслуживания X2.

Если IE MME UE S1AP ID содержится в сообщении ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, eNB должен, если поддерживается, сохранять данную информацию в контексте UE и использовать ее для последующих передач обслуживания X2.

Если IE Разрешенной Основанной на Администрировании MDT содержится в сообщении ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, то eNB должен использовать его, если поддерживается, вместе с информацией в IE Списка PLMN Основанной на Администрировании MDT, если доступна в контексте UE, чтобы обеспечить последующий выбор UE для основанной на администрировании MDT, определенной в документе TS 32.422.

Если IE Индикатора Поддержки CIoT Плоскости Пользователя UE включен в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА и установлен в «поддерживается», то eNB должен, если поддерживается, учитывать, что Оптимизация EPS CIoT Плоскости Пользователя, как указано в документе TS 23.401 поддерживается для UE.

eNB должен представлять отчет MME в сообщении ОТВЕТА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА об успешном создании процедур обеспечения безопасности с UE и о результате для всех запрошенных E-RAB следующим образом:

- Список E-RAB, которые успешно созданы, должен быть включен в IE Списка Настроенных E-RAB

- Список E-RAB, которые не удалось создать, должен быть включен в IE Списка E-RAB с Неудавшейся Настройкой.

Когда eNB представляет отчет о неуспешном создании E-RAB, значение причины должно быть достаточно точным, чтобы позволить MME узнать причину неуспешного создания, например, «Радиоресурсы недоступны», «Сбой Процедуры Радиоинтерфейса».

После отправки сообщения ОТВЕТА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА процедура завершается в eNB.

Если IE Запроса на Подписку включен в сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА, то eNB оценивает его содержимое и отвечает CN в сообщении ОТВЕТА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА результатом запроса на подписку, т.е. будет ли eNB предоставлять информацию, на которую подписывается CN, и о способе, которым информация (или ее подмножество) будет предоставляться.

В отношении табличного описания ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА и ОТВЕТА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА дополнительные IE могут быть закодированы согласно следующим примерным изменениям по отношению к текущему документу TS36.413, начиная с Раздела 9.1.4.1:

9.1.4.1 ЗАПРОС НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА

Данное сообщение отправляется посредством MME, чтобы запросить настройку контекста UE.

Направление: MME → eNB

Имя IE/Группы Наличие Диапазон Тип IE и ссылка Описание семантики Критичность Назначенная критичность Тип сообщения Обязательный 9.2.1.1 ДА отклонить MME UE S1AP ID Обязательный 9.2.3.3 ДА отклонить eNB UE S1AP ID Обязательный 9.2.3.4 ДА отклонить Агрегированная Максимальная Скорость Передачи Битов UE Обязательный 9.2.1.20 ДА отклонить Список E-RAB для Настройки 1 ДА отклонить >IE Позиции Списка E-RAB для Настройки 1 ..
<maxnoofE-RABs> КАЖДЫЙ отклонить >>ID E-RAB Обязательный 9.2.1.2 - >>Параметры QoS Уровня E-RAB Обязательный 9.2.1.15 Включает необходимые параметры QoS. >>Адрес Транспортного Слоя Обязательный 9.2.2.1 - >>GTP-TEID Обязательный 9.2.2.2 - >>NAS-PDU Необязательный 9.2.3.5 - >>ID Корреляции Необязательный 9.2.1.80 ДА игнорировать >>ID Корреляции SIPTO Необязательный ID Корреляции 9.2.1.80 ДА игнорировать >>Тип Носителя Необязательный 9.2.1.116 ДА отклонить Возможности Обеспечения Безопасности UE Обязательный 9.2.1.40 ДА отклонить Ключ Обеспечения Безопасности Обязательный 9.2.1.41 KeNB предоставляется после генерирования ключа в MME, см. TS 33.401 ДА отклонить Активация трассировки Обязательный 9.2.1.4 ДА игнорировать Список Ограничения Передачи Обслуживания Обязательный 9.2.1.22 ДА игнорировать Возможности Радиосвязи UE Обязательный 9.2.1.27 ДА игнорировать ID Профиля Абонента для RAT/приоритет Частоты Обязательный 9.2.1.39 ДА игнорировать Индикатор Нейтрализации Неисправности CS Обязательный 9.2.3.21 ДА отклонить Возможная Операция SRVCC Обязательный 9.2.1.58 ДА игнорировать Статус Членства в CSG Обязательный 9.2.1.73 ДА игнорировать Зарегистрированный LAI Обязательный 9.2.3.1 ДА игнорировать GUMMEI Обязательный 9.2.3.9 Данный IE указывает MME, обслуживающий UE. ДА игнорировать MME UE S1AP ID 2 Обязательный 9.2.3.3 Данный IE указывает MME UE S1AP ID назначенный посредством MME. ДА игнорировать Разрешенная Основанная на Администрировании MDT Обязательный 9.2.1.83 ДА игнорировать Список PLMN Основанной на Администрировании MDT Обязательный Список PLMN MDT 9.2.1.89 ДА игнорировать Индикатор Дополнительной Нейтрализации Неисправности CS Условный - ifCSFBhig
hpriority 9.2.3.37 ДА игнорировать Маскированный IMEISV Обязательный 9.2.3.38 ДА игнорировать Ожидаемое поведение UE Обязательный 9.2.1.96 ДА игнорировать Авторизованная ProSe Обязательный 9.2.1.99 ДА игнорировать Индикатор Поддержки CIoT Плоскости Пользователя UE Обязательный 9.2.1.113 ДА игнорировать Запрос на Подписку Обязательный ПЕРЕЧИСЛИМЫЙ (Указание Активного-Неактивного Состояния, Информация о Местоположении, Указание Неактивного Состояния и Местоположения …) ДА игнорировать

9.1.4.3 ОТВЕТ НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА

Данное сообщение отправляется посредством eNB, чтобы подтвердить настройку контекста UE.

Направление: eNB → MME

Имя IE/Группы Наличие Диапазон Тип IE и ссылка Описание семантики Критичность Назначенная критичность Тип сообщения Обязательный 9.2.1.1 ДА отклонить MME UE S1AP ID Обязательный 9.2.3.3 ДА игнорировать eNB UE S1AP ID Обязательный 9.2.3.4 ДА игнорировать Список Настроенных E-RAB 1 ДА игнорировать >IE Позиции Списка Настроенных E-RAB 1 ..
<maxnoofE-RABs> КАЖДЫЙ игнорировать >>ID E-RAB Обязательный 9.2.1.2 - >>Адрес Транспортного Слоя Обязательный 9.2.2.1 - >>GTP-TEID Обязательный 9.2.2.2 - Список E-RAB с Неудавшейся Настройкой Необязательный Список E-RAB 9.2.1.36 Значение для ID E-RAB должно присутствовать только один раз в IE Списка Настроенных E-RAB и IE Списка E-RAB с Неудавшейся Настройкой. ДА игнорировать Диагностика Критичности Обязательный 9.2.1.21 ДА игнорировать Ответ на Подписку Обязательный ПЕРЕЧИСЛИМЫЙ (Указание Активного-Неактивного Состояния, Информация о Местоположении, Указание Неактивного Состояния и Местоположения, Отклоненная Подписка …) ДА игнорировать

В IE описанных в табличном описании выше CN может отправлять запрос RAN в отношении подписки на предоставление разной информации. Примеры включают в себя, но не ограничиваются, подписку на представление отчета по переходам между активным состоянием (т.е., RRC_CONNECTED) и состоянием неактивного соединения. Другой пример состоит в представлении отчета об информации о местоположении (например, представление отчета об изменении местоположения на уровне соты, уровне зоны регистрации или уровне зоны отслеживания и т.д.). Другой пример состоит в представлении отчета об обоих типах информации вместе (т.е. указание перехода состояния и информации о местоположении).

RAN может отвечать посредством квитирования подписки на запрошенную информацию, которое будет инициировать будущее представление отчета через новую или существующую процедуры как в режиме с квитированием (Класс1), так и режиме без квитирования (Класс2), или посредством отклонения подписки. Другим способом кодирования IE в сообщениях запроса и ответа было бы, чтобы CN перечисляла некоторое число элементов информации, по которым RAN запрашивает подписку для представления отчета. RAN отвечает эквивалентным списком, где информация, для которой осуществлено принятие подписки, не включена. В варианте осуществления выше CN включает запрос на предоставление определенного типа информации по возникновению конкретных событий при создании контекста UE. После положительного ответа от eNB для CN о том, что информация будет предоставлена согласно сконфигурированным правилам, RAN будет сигнализировать CN запрошенную информацию, когда возникают сконфигурированные события.

Такая сигнализация может происходить в различных форматах. Сигнализация может происходить через новую процедуру Класса 2, которая включает запрошенную информацию. Сигнализация может происходить через существующую процедуру, такую как Указание/Подтверждение Модификации Контекста UE, которая иллюстрируется на Фигуре 7.

Фигура 7 является схемой сигнализации, иллюстрирующей указание модификации контекста оборудования пользователя, в соответствии с некоторыми вариантами осуществления. В иллюстрируемой процедуре eNB указывает информацию, сконфигурированную для представления отчет посредством CN, в Указании Модификации Контекста UE. CN подтверждает корректное принятие такой информации в Подтверждении Модификации Контекста UE.

В дополнительных вариантах осуществления обмен информацией между RAN и CN может обеспечиваться через процедуры, которые транспортируют NAS PDU. Например, запрос от CN, чтобы подписаться на переходы UE между состоянием RRC СОЕДИНЕНО и состоянием RRC СОЕДИНЕНИЕ НЕАКТИВНО, может быть предоставлен через процедуру ТРАНСПОРТА NAS DL. Данная процедура может включать в себя потенциальные параметры, описывающие подробности подписки и опционально запрос конкретных данных (например, запрос текущего местоположения).

RAN может отвечать на данный запрос через ТРАНСПОРТ NAS UL или другие процедуры, чтобы осуществлять транспортировку NAS PDU в восходящей линии связи. Данная процедура может указывать, осуществила ли RAN принятие запроса на подписку, и предоставлять подробности, относящиеся к принятой подписке и данным, если запрошены (например, ответ о текущем местоположении). В качестве альтернативы процедура может включать в себя только запрошенные данные, если произошли события, инициирующие представление отчета о данных.

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

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

Конкретные варианты осуществления включают в себя отдельную процедуру автономного инициированного RAN уведомления базовой сети, которая может включать в себя процедуру по интерфейсу CN/RAN. RAN уведомляет базовую сеть в любое время, когда она считает, что UE становится потенциально находящимся в состоянии RRC СОЕДИНЕНИЕ НЕАКТИВНО. Пример иллюстрируется на Фигуре 8.

Фигура 8 является циклограммой, иллюстрирующей автономное уведомление базовой сети со стороны сети радиодоступа, в соответствии с некоторыми вариантами осуществления. На этапе 1 UE соединяется с сетью и может принимать и переносить данные плоскости пользователя и данные плоскости управления. На этапе 2 RAN делает вывод о том, что UE может потенциально находиться в состоянии RRC СОЕДИНЕНИЕ НЕАКТИВНО. Данное определение может быть основано на многообразии разных факторов, включая, но не ограничиваясь, шаблон активности.

На этапе 3 RAN указывает базовой сети, что UE может потенциально, например, на основании его шаблона активности, находиться в состоянии RRC СОЕДИНЕНИЕ НЕАКТИВНО. На этапе 4 CN осуществляет квитирование приема уведомления с этапа 3. На этапе 5 CN использует указание, принятое от RAN на этапе 3, например, при администрировании свойств, которые основываются на знании местоположения UE.

Другой альтернативой вышеприведенного является включение механизма в процедуру Настройки Соединения, т.е., уже на этапе 1 на Фигуре 6. Это подробно приводится ниже на основании процедуры Настройки Начального Контекста UE в LTE. Конкретные варианты осуществления включают в себя встроенную процедуру автономного инициированного RAN уведомления базовой сети. В соответствии с определенными вариантами осуществления процедура подписки встраивается в процедуру настройки контекста UE по интерфейсу CN/RAN.

Новая функция показана по отношению к текущей стандартизованной процедуре. Например, вариант осуществления может быть описан по отношению к процедуре Настройки Соединения, описанной в Разделе 8.3.1 документа 3GPP TS 36.413v13.3.0.

Цель процедуры Настройки Начального Контекста состоит в создании общего начального Контекста UE, включая контекст E-RAB, Ключ Обеспечения Безопасности, Список Ограничения Передачи Обслуживания, возможности Радиосвязи UE и Возможности Обеспечения Безопасности UE и т.д. Процедура использует ассоциированную с UE сигнализацию.

Пример иллюстрируется на Фигуре 6 (воспроизведением Фигуры 8.3.1.2-1 из документа 3GPP TS 36.413v13.3.0). В случае создания E-RAB, EPC должно быть подготовлено принимать данные пользователя до того, как сообщение ОТВЕТА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА было принято MME. Если не существует ассоциированного с UE логического S1-соединения, то ассоциированное с UE логическое S1-соединение должно быть создано при приеме сообщения ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА.

Сообщение ЗАПРОСА НАСТРОЙКИ НАЧАЛЬНОГО КОНТЕКСТА должно содержать в IE Списка E-RAB для Настройки информацию, которая требуется eNB, чтобы создать новую конфигурацию E-RAB, состоящую из по меньшей мере одного дополнительного E-RAB.