Радиотерминал, радиостанция, узел базовой сети и способ связи в них

Авторы патента:

ХАЯСИ Садафуку (JP)

ФУТАКИ Хисаси (JP)

H04W8/22 - Техника электрической связи

Владельцы патента RU 2701703:

НЕК КОРПОРЕЙШН (JP)

Изобретение относится к области беспроводной связи. Технический результат заключается в повышении эффективности процедуры связи, сокращении сообщений сигнализации и надлежащем выборе базовой сети. Радиотерминал содержит память и по меньшей мере один процессор, соединенный с памятью, при этом по меньшей мере один процессор выполнен с возможностью передавать на радиостанцию сообщение о завершении настройки соединения Управления Ресурсами Радиосвязи (RRC), включающее в себя вспомогательный информационный элемент пользовательского оборудования (UE), указывающий, который из множества типов архитектур связи для передачи пакета данных, относящийся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован. 4 н. и 6 з.п. ф-лы, 29 ил.

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

[0001] Настоящее раскрытие относится к системе радиосвязи, которая поддерживает множество типов архитектуры связи для передачи данных.

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

[0002] В Проекте Партнерства 3-его Поколения (3GPP) продолжается стандартизация Сотового Интернета Вещей (CIoT). Намеченный проект CIoT в 3GPP включает в себя проекты Долгосрочного Развития улучшенного для связи типа Машина с Машиной (LTE eMTC) и Узкополосного IoT (NB-IoT). Отличительные признаки проектов LTE eMTC и NB-IoT включают в себя сверхнизкое потребление питания Оборудованием Пользователя (UE), большое число устройств на соту, узкополосные спектры, и расширенные покрытия. В проекте LTE eMTC (Категория M), указывается, что Радиочастотной (RF) полосой пропускания UE приема является 1.4МГц. Между тем, в проекте NB-IoT, предполагается, что пиковая скорость для нисходящей линии связи и восходящей линии связи составляет 200Кбит/с или 144Кбит/с для оптимизации затрат, сокращения потребления питания, и расширения покрытия еще больше, и RF полоса пропускания UE составляет около 200кГц (эффективная полоса пропускания составляет 180кГц) как для восходящей линии связи, так и нисходящей линии связи.

[0003] Непатентная Литература 1 раскрывает несколько решений архитектуры связи для нечастой передачи небольших данных в NB-IoT. Эти решения включают в себя архитектуру для передачи данных через плоскость управления (Решение 2), и архитектуру для передачи данных через плоскость пользователя, включающую приостановку и возобновление соединения RRC (Решение 18). В Непатентной Литературе 1, поддержка Решения 2 является обязательной как для UE, так и сети, тогда как поддержка Решения 18 является опциональной как для UE, так и сети.

[0004] Решение 2 основано на облегченной архитектуре базовой сети (CN) для CIoT. В облегченной архитектуре CN, принимая во внимание типичные случаи использования для устройств CIoT, базовая сеть поддерживает только ограниченное число функций, в сравнении с их числом в объектах CN в соответствии с существующим стандартом LTE (т.е., Объекте Управления Мобильностью (MME) Обслуживающем Шлюзе (S-GW), и Шлюзе Сети с Коммутацией Пактов (P-GW)). Фиг. 1 показывает архитектуру сети для CIoT в случае без роуминга.

[0005] Узел Обслуживающего Шлюза (C-SGN) CIoT является новым логическим сетевым объектом. C-SGN является узлом CN как с плоскостью управления (CP), так и плоскостью пользователя (UP). C-SGN обеспечивает ограниченную процедуру Управления Мобильностью (MM) для устройств CIoT, процедуру передачи небольших данных, процедуру обеспечения безопасности для передачи небольших данных, и завершение интерфейса SGi для случая без роуминга. Функция P-GW может быть отделена от C-SGN. В данном случае, интерфейс S5 используется между C-SGN и P-GW. В случае роуминга, C-SGN обеспечивает интерфейс S8.

[0006] Интерфейс S1-lite (S1-легкий) является оптимизированной версией S1-C (S1-MME). Интерфейс S1-lite поддерживает необходимые сообщения S1 Прикладного Протокола (S1AP) и элементы информации (IE) для процедур CIoT, и поддерживает оптимизированные процедуры обеспечения безопасности. Для эффективной передачи небольших данных, данные пользователя доставляются через слой S1AP.

[0007] В частности, в случае исходящей с мобильного устройства (Мобильно Порожденной, MO) передачи небольших данных для случая без роуминга, UE передает сообщение Уровня Без Доступа (NAS) восходящей линии связи, несущее пакет небольших данных (например, Интернет Протокола (IP), не-IP, или Службы Коротких Сообщений (SMS)). Данное сообщение NAS восходящей линии связи прибывает на C-SGN через Базовую Станцию CIoT (CIoT BS). Сообщение NAS восходящей линии связи передается по Носителю Сигнализации Радиосвязи (SRB). Вследствие этого, необходимо настраивать Носитель Данных Радиосвязи (DRB). Кроме того, может быть опущено обеспечение безопасности Уровня Доступа (AS).

[0008] C-SGN дешифрует сообщение NAS восходящей линии связи, чтобы получить пакет небольших данных. C-SGN переадресовывает пакет небольших данных в соответствии с типом данных у пакета небольших данных. Применительно к небольшим данным IP, C-SGN отправляет их через интерфейс SGi. Применительно к SMS, C-SGN отправляет их объекту, относящемуся к SMS (например, Шлюзовому Центру Коммутации Мобильных Услуг SMS (SMS-GMSC), Центру Коммутации Мобильных Услуг Организации Межсетевого Обмена SMS (SMS-IWMSC), или маршрутизатору SMS). Применительно к небольшим данным Не-IP, C-SGN отправляет их Функции Экспонирования Возможностей Услуги (SCEF).

[0009] В случае оканчивающейся на мобильном устройстве (Мобильно Завершенной, MT) передачи небольших данных применительно к случаю без роуминга, C-SGN передает сообщение NAS нисходящей линии связи, несущее пакет небольших данных, к UE через CIoT BS. Какого-либо DRB также не требуется для передачи пакета небольших данных нисходящей линии связи и обеспечение безопасности AS может быть опущено.

[0010] CIoT BS, показанная на Фиг. 1, является базовой станцией расположенной в CIoT Сети Радиодоступа (CIoT RAN). LTE eNB, который выполнен с возможностью соединения с C-SGN, может быть использован вместо CIoT BS, показанной на Фиг. 1. Данный LTE eNB может быть eNB, который поддерживает проект LTE eMTC.

[0011] Между тем, архитектура в соответствии с решением 18 обеспечивает нечастую передачу небольших данных по плоскости пользователя. Архитектура в соответствии с решением 18 имеет свойство повторного использования информации, полученной от предыдущего соединения RRC для настройки последующего соединения RRC, тем самым сокращая число сигнализаций, требуемых для перехода состояния Управления Ресурсами Радиосвязи (RRC) UE.

[0012] В частности, UE переходит в режим RRC-Idle (RRC-Бездействие) из режима RRC-Connected (RRC-Соединено) и удерживает информацию касательно соединения RRC (например, Контекст Обеспечения Безопасности Уровня Доступа, связанную с носителем информацию (включая информацию о состоянии RoHC), и параметры L2/1, если применимо). Дополнительно, eNB и MME удерживает S1AP Контексты UE. Кроме того, eNB удерживает адреса туннеля S1-U.

[0013] Когда UE возвращается к режиму RRC-Connected, оно отправляет Запрос Возобновления Соединения RRC к eNB. eNB восстанавливает DRB, контекст обеспечения безопасности, и соединение S1AP, и туннель(и) S1-U на основе ранее удержанной информации касательно соединения RRC. Кроме того, eNB уведомляет MME об изменении состояния UE, используя новое сообщение S1AP (т.е., S1-AP Активный Контекст UE). MME меняет состояние Управления Соединением (ECM) Развитой Пакетной Системы (EPS) у UE на состояние ECM-Connected (ECM-Соединенное), и затем отправляет сообщение Запроса Модифицирования Носителя к S-GW. В результате, S-GW распознает, что UE находится в соединенном состоянии и, следовательно, переходит в состояние, в котором S-GW может передавать данные нисходящей линии связи к UE.

[0014] В решении 18, UE может возвращаться в RRC-Connected или ECM-Connected без передачи сообщения NAS (т.е., Запроса Услуги). Кроме того, в сравнении с унаследованной процедурой настройки соединения RRC, могут быть удалены следующие сообщения RRC:

- Завершена Настойка Соединения RRC;

- Команда Режима Обеспечения Безопасности RRC;

- Завершен Режим Обеспечения Безопасности RRC;

- Реконфигурация Соединения RRC; и

- Завершена Реконфигурация Соединения RRC.

[0015] Непатентная Литература 2 описывает, что UE может решать, во время процедуры прикрепления, какую из архитектуры решения 2 и архитектуры решения 18 оно хочет использовать. Кроме того, Непатентная Литература 2 описывает, что процедура AS и NAS может включать в себя информацию, позволяющую сети выбирать решение 2 или решение 18 для передачи данных.

Список Цитирования

Непатентная Литература

[0016] Непатентная Литература 1: 3GPP TR 23.720 V1.2.0 (2015-11), «3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for Cellular Internet of Things (Release 13)», ноябрь 2015г.

Непатентная Литература 2: 3GPP R2-156645, Qualcomm Incorporated, «NB-IoT SA2 architecture implications», 3GPP TSG RAN WG2 #92, Анахайм, США, 16-20 ноября 2015г.

Сущность изобретения

Техническая задача

[0017] Авторы изобретения изучили архитектуру связи для CIoT и архитектуру связи для сокращения энергопотребления радиотерминалов и обнаружили ряд проблем. Например, Непатентная Литература 1 и 2 не раскрывает конкретной процедуры для определения типа архитектуры, которая должна быть использована для передачи пакета данных для UE из множества типов архитектуры связи (например, решений 2 и 18). Авторы изобретения изучили конкретные процедуры связи, включающие определение (или выбор) архитектуры связи, используемой для UE, выступающего в качестве устройства CIoT и сформулировали ряд улучшений, которые способствуют, например, улучшению эффективности процедур связи, сокращению сообщений сигнализации, или надлежащему выбору CN.

[0018] Кроме того, например, Непатентная Литература 1 и 2 в достаточной степени не рассматривает мобильность UE, выступающих в качестве устройств CIoT. Мобильность устройств CIoT включает в себя смену соты в режиме бездействия (например, RRC-Idle) (т.е., мобильность в режиме бездействия) и смену соты в соединенном режиме (например, режиме RRC-Connected) (т.е., мобильность в соединенном режиме). Авторы изобретения сформулировали ряд улучшения для процедур мобильности для устройств CIoT.

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

Решение задачи

[0020] В первом аспекте, радиотерминал включает в себя память и, по меньшей мере, один процессор, соединенный с памятью. По меньшей мере, один процессор выполнен с возможностью передачи радиостанции сообщения запроса соединения Управления Ресурсами Радиосвязи (RRC), включающего в себя причину создания или другой элемент информации, указывающий, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован.

[0021] Во втором аспекте, способ в радиотерминале включает в себя этап, на котором передают радиостанции сообщение запрос соединения Управления Ресурсами Радиосвязи (RRC), включающее в себя причину создания или другой элемент информации, указывающий, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован.

[0022] В третьем аспекте, радиостанция включает в себя память и, по меньшей мере, один процессор, соединенный с памятью. По меньшей мере, один процессор выполнен с возможностью приема сообщения запроса соединения Управления Ресурсами Радиосвязи (RRC) от радиотерминала. По меньшей мере, один процессор дополнительно выполнен с возможностью извлечения, из сообщения запроса соединения RRC, причины создания или другого элемента информации, указывающего, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован.

[0023] В четвертом аспекте, способ в радиостанции включает в себя этапы, на которых: (a) принимают сообщение запрос соединения Управления Ресурсами Радиосвязи (RRC) от радиотерминала; и (b) извлекают, из сообщения запроса соединения RRC, причину создания или другой элемент информации, указывающий, какой из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает, или на который радиотерминал сконфигурирован.

[0024] В пятом аспекте, радиотерминал включает в себя память и, по меньшей мере, один процессор, соединенный с памятью. По меньшей мере, один процессор выполнен с возможностью передачи радиостанции сообщения о завершении настройки соединения Управления Ресурсами Радиосвязи (RRC), включающего в себя вспомогательный информационный элемент UE, указывающий, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован.

[0025] В шестом аспекте, способ в радиотерминале включает в себя этап, на котором передают радиостанции сообщение о завершении настройки соединения Управления Ресурсами Радиосвязи (RRC), включающее в себя вспомогательный элемент информации UE, указывающий, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован.

[0026] В седьмом аспекте, радиостанция включает в себя память и, по меньшей мере, один процессор, соединенный с памятью. По меньшей мере, один процессор выполнен с возможностью приема сообщения о завершении настройки соединения Управления Ресурсами Радиосвязи (RRC) от радиотерминала. По меньшей мере, один процессор дополнительно выполнен с возможностью извлечения, из сообщения о завершении настройки соединения RRC, вспомогательного элемента информации UE, указывающего, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован.

[0027] В восьмом аспекте, способ в радиостанции включает в себя этапы на которых: (a) принимают сообщение о завершении настройки соединения Управления Ресурсами Радиосвязи (RRC) от радиотерминала; и (b) извлекают, из сообщения о завершении настройки соединения RRC, вспомогательный элемент информации UE, указывающий, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован.

[0028] В девятом аспекте, радиостанция включает в себя память и, по меньшей мере, один процессор, соединенный с памятью. По меньшей мере, один процессор выполнен с возможностью приема сообщения о завершении настройки соединения Управления Ресурсами Радиосвязи (RRC) от радиотерминала. По меньшей мере, один процессор дополнительно выполнен с возможностью, когда второй тип архитектуры связи, в котором пакет данных передается через плоскость пользователя, выбирается, чтобы быть использованным для радиотерминала, из множества типов архитектуры связи, относящихся к Сотовому Интернету Вещей (CIoT), генерирования исходного сообщения UE, включающего в себя исходное сообщение Уровня без Доступа (NAS), извлеченное из сообщения о завершении настройки соединения RRC, и идентификатор конечной точки туннеля нисходящей линии связи, используемый во второй архитектуре связи. По меньшей мере, один процессор еще дополнительно выполнен с возможностью передачи исходного сообщения UE базовой сети.

[0029] В десятом аспекте, способ в радиостанции включает в себя этапы, на которых:

(a) принимают сообщение о завершении настройки соединения Управления Ресурсами Радиосвязи (RRC) от радиотерминала;

(b) когда второй тип архитектуры связи, в котором пакет данных передается через плоскость пользователя, выбирается, чтобы быть использованным для радиотерминала, из множества типов архитектуры связи, относящихся к Сотовому Интернету Вещей (CIoT), генерируют исходное сообщение UE, причем исходное сообщение UE включает в себя исходное сообщение Уровня без Доступа (NAS), извлеченное из сообщения о завершении настройки соединения RRC, и идентификатор конечной точки туннеля нисходящей линии связи, используемый во второй архитектуре связи; и

[0030] В одиннадцатом аспекте, узел базовой сети включает в себя память и, по меньшей мере, один процессор, соединенный с памятью. По меньшей мере, один процессор выполнен с возможностью приема исходного сообщения UE от базовой станции. Исходное сообщение UE включает в себя исходное сообщение Уровня без Доступа (NAS), переданное от радиотерминала, и элемент информации, указывающий тип архитектуры связи, определенный радиостанцией из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT). По меньшей мере, один процессор дополнительно выполнен с возможностью определения, на основе элемента информации, перенаправления исходного сообщения NAS к базовой сети, соответствующей определенному типу архитектуры связи. По меньшей мере, один процессор еще дополнительно выполнен с возможностью передачи радиостанции сообщения запроса перенаправления сообщения NAS, указывающего, что исходное сообщение NAS должно быть перенаправлено к соответствующей базовой сети.

[0031] В двенадцатом аспекте, способ в узле базовой сети включает в себя этапы, на которых:

(a) принимают исходное сообщение UE от базовой станции, причем исходное сообщение UE включает в себя исходное сообщение Уровня без Доступа (NAS), переданное от радиотерминала, и элемент информации, указывающий тип архитектуры связи, определенный радиостанцией из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT);

(b) определяют, на основе элемента информации, перенаправление исходного сообщения NAS к базовой сети, соответствующей определенному типу архитектуры связи; и

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

[0032] В тринадцатом аспекте, узел базовой сети включает в себя память и, по меньшей мере, один процессор, соединенный с памятью. По меньшей мере, один процессор выполнен с возможностью приема исходного сообщения UE от базовой станции. Исходное сообщение UE включает в себя исходное сообщение Уровня без Доступа (NAS), переданное от радиотерминала, и элемент информации, указывающий, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT) радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован. По меньшей мере, один процессор также выполнен с возможностью определения, на основе элемента информации, типа архитектуры связи, который должен быть использован для передачи пакета данных для радиотерминала. По меньшей мере, один процессор дополнительно выполнен с возможностью определения перенаправления исходного сообщения NAS к базовой сети, соответствующей определенному типу архитектуры связи. По меньшей мере, один процессор еще дополнительно выполнен с возможностью передачи радиостанции сообщения запроса перенаправления сообщения NAS, указывающего, что исходное сообщение NAS должно быть перенаправлено к соответствующей базовой сети.

[0033] В четырнадцатом аспекте, способ в узле базовой сети включает в себя этапы, на которых:

(a) принимают исходное сообщение UE от базовой станции, причем исходное сообщение UE включает в себя исходное сообщение Уровня без Доступа (NAS), переданное от радиотерминала, и элемент информации, указывающий, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT) радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован;

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

(c) определяют перенаправление исходного сообщения NAS к базовой сети, соответствующей определенному типу архитектуры связи; и

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

[0034] В пятнадцатом аспекте, программа включает в себя набор инструкций (коды программного обеспечения), которые, когда загружаются в компьютер, предписывают компьютеру выполнять способ в соответствии с описанным выше вторым, четвертым, шестым, восьмым, десятым, двенадцатым, или четырнадцатым аспектом.

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

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

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

[0036] Фиг. 1 является схемой, показывающей пример архитектуры CIoT;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0037] Конкретные варианты осуществления описываются далее подробно со ссылкой на чертежи. Одни и те же или соответствующие элементы обозначены одними и теми же символами на всех чертежах, и дублирующие объяснения опущены при необходимости для ясности.

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

[0039] Нижеследующие описания вариантов осуществления главным образом сконцентрированы на сетях радиосвязи для CIoT, включая LTE eMTC и NB-IoT. Тем не менее, эти варианты осуществления также могут быть применены к сетям радиосвязи для другого CIoT.

[0040] Первый вариант осуществления

Фиг. 2 показывает пример конфигурации сети радиосвязи в соответствии с некоторыми вариантами осуществления, включая данный вариант осуществления. В примере, показанном на Фиг. 2, UE 1, которое функционирует в качестве устройства CIoT, осуществляет связь с сервером 4 приложений через Сеть 2 Радиодоступа (RAN) CIoT и Базовую Сеть 3 (CN). RAN 2 поддерживает множество типов архитектуры связи для передачи пакета данных, относящейся к CIoT. RAN 2 осуществляет широковещательную передачу, в соте, информации, которая явным или неявным образом указывает множество типов архитектуры связи, поддерживаемых RAN 2, посредством использования Блока Главной Информации (MIB) или Блока Информации Системы (SIB), например. UE 1 поддерживает, по меньшей мере, один из этих типов архитектуры связи. CN 3 поддерживает эти типы архитектуры связи. CN 3 может включать в себя выделенные CN (DCN), причем каждая ассоциирована с одним из типов архитектуры связи.

[0041] В некоторых реализациях, множество типов архитектуры связи может включать в себя первый и второй типы архитектуры связи, соответствующие соответственно решениям 2 и 18, которые раскрываются в Непатентной Литературе 1. В первом типе архитектуры связи, пакеты данных пользователя, передаваемые или принимаемые посредством UE 1, переносятся через плоскость управления (например, сообщения NAS, передаваемые между UE и MME/C-SGN). В первом типе архитектуры связи, RAN 2 не требуется настраивать DRB для передачи пакета данных для UE 1. Кроме того, касательно SRB, используемого для передачи пакета данных, обеспечение безопасности Уровня Доступа (AS) (т.е., шифрование и дешифрование данных плоскости управления и защита целостности и верификация целостности данных плоскости управления) посредством RAN 2 может быть опущено. Другими словами, процессы слоя Протокола Конвергенции Пакетных Данных (PDCP) для SRB, используемого для передачи пакета данных, могут быть опущены. В данном случае, пакеты данных для UE 1 шифруются и дешифруются посредством UE 1 и CN 3 (например, MME или C-SGN) посредством использования ключей обеспечения безопасности NAS. В противоположность этому, во втором типе архитектуры связи, пакеты данных пользователя, передаваемые или принимаемые посредством UE 1, переносятся через плоскость пользователя (например, носитель EPS, включающий в себя DRB и туннель Протокола Туннелирования (GTP) Пакетной Радиосвязи Общего Назначения (GPRS)).

[0042] UE 1 может поддерживать любой из или как LTE eMTC, так и NB-IoT. Другими словами, UE 1 может поддерживать любую из или как CIoT RAT (NB-IoT RAT), так и LTE RAT (eMTC). RAN 2 может включать в себя любое из или как CIoT BS, поддерживающую CIoT RAT (NB-IoT RAT), так и eNB, поддерживающий LTE RAT (eMTC). CN 3 может включать в себя C-SGN, или MME и S-GW, или как то, так и другое. Кроме того, CN 3 может включать в себя другие сетевые объекты, такие как P-GW, Сервер Домашнего Абонента (HSS), и Функцию Правил Политики и Тарификации (PCRF).

[0043] Фиг. 3 является циклограммой, показывающей пример процедуры связи в соответствии с данным вариантом осуществления. В процедуре, показанной на Фиг. 3, тип архитектуры связи, который должен быть использован для передачи пакета данных для UE 1, определяется во время процедуры для прикрепления UE 1 к CN 3. UE 1 определяет тип архитектуры связи, который должен быть использован для передачи пакета данных для UE 1 и передает RAN 2 сообщение Запрос Соединения RRC, включающее в себя причину создания, явным или неявным образом указывающую определенный тип архитектуры связи.

[0044] На этапе 301, UE 1 определяет (или выбирает) тип архитектуры связи, который должен быть использован для передачи пакета данных для UE 1. В некоторых реализациях, UE 1 может выбирать тип архитектуры связи, который должен быть использован, на основе возможности UE по умолчанию, которая была предварительно сконфигурирована в UE 1. Дополнительно или в качестве альтернативы, UE 1 может измерять мощность приема опорного сигнала (RSRO) от RAN 2 или оцененные потери при распространении между UE 1 и RAN 2 (CIoT-BS/eNB) и выбирать тип архитектуры связи, который должен быть использован, на основе измеренных RSRP или потерь при распространении. Дополнительно или в качестве альтернативы, UE 1 может определять необходимый уровень улучшения покрытия (CE) на основе измеренных RSRP или потерь при распространении, и выбирать тип архитектуры связи на основе определенного уровня CE. Дополнительно или в качестве альтернативы, UE 1 может выбирать тип архитектуры связи в соответствии с инициирующим событием передачи данных (например, mo-Data, mo-ExceptionData, mt-Access, или mo-Signaling). Дополнительно или в качестве альтернативы, UE 1 может выбирать тип архитектуры связи в соответствии с типом приложения, которое выполняет передачу пакета данных.

[0045] На этапе 302, UE 1 запускает процедуру произвольного доступа. Т.е., UE 1 передает преамбулу произвольного доступа (т.е., преамбулу Канала Произвольного Доступа (RACH)) RAN 2 и принимает сообщение ответа произвольного доступа (RAR) от RAN 2.

[0046] На этапе 303, UE 1 передает третье сообщение (Msg3) в процедуре произвольного доступа (т.е., сообщение Запрос Соединения RRC) RAN 2. Данное сообщение Запрос Соединения RRC передается посредством SRB 0 по Общему Каналу Управления (CCCH). Сообщение Запрос Соединения RRC включает в себя элемент управления причины создания, явным или неявным образом указывающий тип архитектуры связи, определенный (или выбранный) UE 1.

[0047] Касательно причины создания, указывающей тип архитектуры связи, например, одна из обычных причин создания (например, mo-Data, mo-ExceptionData, mo-Signaling, mt-Access) может быть использована для указания первого (или второго) типа архитектуры связи, и конкретная причина создания может быть использована для указания второго (или первого) типа архитектуры связи. Когда конкретная причина создания используется для первого типа архитектуры связи, она может быть, например, информацией (например, mo-DataOverNAS, mo-ExceptionDataOverNAS, mo-SignalingDataOverNAS, или Mt-AccessDataOverNAS), указывающей тип архитектуры связи, в котором данные пользователя передаются посредством сообщения NAS. Когда конкретная причина создания используется для второго типа архитектуры связи, она может быть, например, информацией (например, mo-DataUP, Mo-ExceptionDataUP, Mo-SignalingUP, или Mt-AccessUP), указывающей, что конфигурируется DRB и данные пользователя передаются через Плоскость Пользователя (UP) (сообщение AS).

[0048] На этапе 304, по приему сообщения Запрос Соединения RRC, RAN 2 передает сообщение Настройка Соединения RRC UE 1. Данное сообщение Настройка Соединения RRC передается посредством SRB 0 по CCCH. Сообщение Настройка Соединения RRC включает в себя информацию конфигурации касательно SRB1 и позволяет последующей сигнализации использовать Выделенный Канал Управления (DCCH).

[0049] Сообщение Настройка Соединения RRC может указывать потребность в PDCP. В частности, сообщение Настройка Соединения RRC может указывать потребность в PDCP (например, используется ли PDCP сходно с обычным образом) для UE 1. В некоторых реализациях, информация флага, указывающая потребность в PDCP, может быть включена в IE RadioResourceConfigDedicated или другой IE, включенный в сообщение Настройка Соединения RRC.

[0050] В некоторых реализациях, конфигурация PDCP (pdcp-Config), включенная в сообщение Настройка Соединения RRC, может указывать потребность в PDCP. Данная конфигурация PDCP может включать в себя информацию флага, указывающую потребность в PDCP (например, используется ли PDCP сходно с обычным образом) для UE 1. Конфигурация PDCP может включать в себя информацию, указывающую, должна ли быть задействована конфигурация по умолчанию у PDCP Config у SRB 1 для UE 1. Конфигурация PDCP может включать в себя конкретный PDC Config (например, RLC-SAP и длину Порядкового Номера (SN) PDCP, применяемую к SRB 1). В качестве альтернативы, RAN 2 может определять, включать ли конфигурацию PDCP (pdcp-Config) в сообщение Настройка Соединения RRC в зависимости от типа архитектуры связи, определенного посредством UE 1. В частности, если UE 1 выбирает второй тип архитектуры связи, RAN 2 может включать конфигурацию PDCP для SRB 1 в сообщение Настройка Соединения RRC.

[0051] На этапе 305, UE 1 передает сообщение Завершена Настройка Соединения RRC к RAN 2. Данное сообщение Завершена Настройка Соединения RRC передается посредством SRB 1 по DCCH. Сообщение Завершена Настройка Соединения RRC несет исходное сообщение NAS. Отметим, что поскольку Фиг. 3 показывает процедуру прикрепления, исходным сообщением NAS является сообщение Запрос Прикрепления. Данное сообщение Запрос Прикрепления включает в себя Элемент Информации (IE) типа прикрепления EPS установленный в «CIoT Прикрепление».

[0052] RAN 2 принимает сообщение Завершена Настройка Соединения RRC от UE 1 и отправляет исходное сообщение NAS (т.е., сообщение Запрос Прикрепления), извлеченное из сообщения Завершена Настройка Соединения RRC к CN 3 (например, MME или C-SGN), используя S1AP: Исходное сообщение UE. Исходное сообщение NAS (т.е., сообщение Запрос Прикрепления) встраивается в Элемент Информации (IE) NAS-Протокольной Единицы Данных (PDU) у S1AP: Исходное сообщение UE. RAN 2 может встраивать элемент информации, указывающий тип архитектуры связи определенный (или выбранный) UE 1 в S1AP: Исходное сообщение UE. RAN 2 может выбирать, из DCN в CN 3, DCN, соответствующую типу архитектуры связи, определенному посредством UE 1, и отправлять S1AP: Исходное сообщение UE, несущее исходное сообщение NAS (т.е., сообщение Запрос Прикрепления) к выбранной DCN.

[0053] На этапе 306, CN 3 (например, MME или C-SGN) выполняет процедуру аутентификации и обеспечения безопасности и тем самым настраивает обеспечение безопасности NAS. Сообщение(ия) NAS нисходящей линии связи, необходимое для процедуры аутентификации и обеспечения безопасности (т.е., Запрос Аутентификации и Команда Режима Обеспечения Безопасности NAS) передается посредством сообщения RRC: Перенос Информации DL по SRB 1. Сходным образом, сообщение(ия) NAS восходящей линии связи для процедуры аутентификации и обеспечения безопасности (т.е., Ответ Аутентификации и Завершен Режим Обеспечения Безопасности NAS) передается посредством сообщения RRC: Перенос Информации UL по SRB 1.

[0054] На этапе 307, CN 3 (например, MME или C-SGN) отправляет сообщение NAS: Прикрепление Принято к UE 1. Настройка сеанса для UE 1 (например, DRB и носителя S1) не требуется. Соответственно, CN 3 (например, MME или C-SGN) не требуется отправлять сообщение S1AP: Запрос Настройки Исходного Контекста к RAN 2 (например, CIoT-BS или eNB). Таким образом, сообщение Прикрепление Принято может быть передано от CN 3 к RAN 2 посредством сообщения S1AP: Транспорт NAS Нисходящей Линии Связи. RAN 2 передает сообщение Прикрепление Принято к UE 1 по SRB 1, используя сообщение RRC: Перенос Информации DL.

[0055] UE 1 принимает сообщение Прикрепление Принято от CN 3 через RAN 2. Сообщение Прикрепление Принято может указывать тип данных переноса (например, IP, не-IP, или SMS) и адрес UE (например, IP-адрес). По приему сообщения Прикрепление Принято, UE 1 передает сообщение NAS: Прикрепление Завершено к CN 3. Данное сообщение Прикрепление Завершено передается к RAN 2 посредством сообщения RRC: Перенос Информации UL по SRB 1. RAN 2 переадресовывает принятое сообщение Прикрепление Завершено к CN 3, используя сообщение S1AP: Транспорт NAS Восходящей Линии Связи.

[0056] На этапе 308, RAN 2 передает сообщение Освобождение Соединения RRC к UE 1 по SRB 1. CN 3 может запрашивать у RAN 2 освободить соединение RRC с UE 1 посредством отправки сообщения S1AP: Команда Освобождения Контекста UE к RAN 2. По приему сообщения Освобождение Соединения RRC, UE 1 переходит из режима RRC-Connected в режим RRC-Idle. Применительно к UE 1, выступающего в качестве устройства CIoT, другой режим приостановки или состояние отличное от существующего режима RRC-idle может быть определено. Таким образом, по приему сообщения Освобождение Соединения RRC, UE 1 может переходить в режим RRC-Idle или другой режим приостановки. Другой режим приостановки или состояние может быть использован во втором типе архитектуры связи для того, чтобы удерживать информацию касательно соединения RRC (например, Контекст Обеспечения Безопасности Уровня Доступа, относящаяся к носителю информация, и параметры L2/1).

[0057] Сообщение Прикрепление Принято на этапе 307, сообщение Освобождение Соединения RRC на этапе 308, или другое сообщение NAS нисходящей линии связи, переданное от CN 3 к UE 1, может явным или неявным образом указывать тип архитектуры связи, который должен быть использован для UE 1 (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры).

[0058] На этапе 309, UE 1 записывает (сохраняет) тип архитектуры связи, сконфигурированный во время процедуры прикрепления.

[0059] Процедура, показанная на Фиг. 3, может быть модифицирована следующим образом. UE 1 может включать, в дополнение к обычной причине создания, другой элемент информации в сообщении Запрос Соединения RRC (этап 303), чтобы указывать тип архитектуры связи. Данный элемент информации может быть, например, элементом информации, указывающим, какой из первого и второго типов архитектуры связи UE 1 выбрало (например, Выбранный Тип Архитектуры или Применяемый Тип Архитектуры). Например, UE 1 может устанавливать значение элемента информации в «DataOverNAS (DONAS)» или «Тип 1» для того, чтобы указывать первый тип архитектуры связи, и устанавливать значение элемента информации в «RRC-Suspend» или «Тип 2» для того, чтобы указывать второй тип архитектуры связи.

[0060] Например, описанный выше элемент информации может быть определен в качестве «SelectedArcType ENUMERATED {type1, type2} (или {DataOverNAS, rrc-Suspend})». В качестве альтернативы, элемент информации может быть информацией флага, указывающей, что был выбран первый тип архитектуры связи (например, SelectedArcType ENUMERATED {type1}, или ArcType1 ENUMERATED {true}). В качестве альтернативы, элемент информации может быть информацией флага, указывающей, что был выбран второй тип архитектуры связи (например, SelectedArcType ENUMERATED {type2}, или ArcType2 ENUMERATED {true}).

[0061] Если UE 1 реализует способ передачи информации флага, указывающей, что был выбран один из двух типов архитектуры связи (например, второй тип архитектуры связи), использование другого типа архитектуры связи (например, первого типа архитектуры связи) посредством UE 1 может быть определено в качестве конфигурации по умолчанию (или базовой конфигурации). Таким образом, когда UE 1 не передает информацию флага, это неявным образом указывает, что UE 1 выбрало тип архитектуры связи по умолчанию. Т.е., если RAN 2 не принимает информацию флага, RAN 2 распознает, что UE 1 выбрало тип архитектуры связи по умолчанию.

[0062] Процедура, показанная на Фиг. 3 может быть дополнительно модифицирована следующим образом. RAN 2 может использовать тип архитектуры связи отличный от типа архитектуры связи, указанного UE 1 в сообщении Запрос Соединения RRC (этап 303). В данном случае, RAN 2 может уведомлять UE 1 о данном отличном типе архитектуры связи (например, Применяемом Типе Архитектуры или Выбранном Типе Архитектуры) используя сообщение Настройка Соединения RRC (этап 304). В качестве альтернативы, RAN 2 может передавать UE 1 на этапе 304 сообщение Отклонение Соединения RRC, вместо сообщения Настройка Соединения RRC, и уведомлять UE 1 об отличном типе архитектуры связи, используя данное сообщения. По приему уведомления об отличном типе архитектуры связи, UE 1 может прекращать текущую процедуру прикрепления и перезапускать новую процедуру настройки соединения RRC. В качестве альтернативы, UE 1 может продолжать текущую процедуру прикрепления и процедуру настройки соединения RRC в соответствии с уведомлением об отличном типе архитектуры связи, переданным от RAN 2.

[0063] Когда второй тип архитектуры связи, в котором пакеты данных пользователя передаются через плоскость пользователя (например, носитель EPS, включающий в себя DRB и туннель Протокола Туннелирования GPRS (GTP)), используется для UE 1, CN 3 может включать сообщение NAS: Прикрепление Принято в сообщение S1AP: Запрос Настройки Исходного Контекста и передавать их к RAN 2 на этапе 307. Данное сообщение S1AP: Запрос Настройки Исходного Контекста включает в себя ключ обеспечения безопасности (K_eNB) и Алгоритм Обеспечения Безопасности UE, используемый для UE 1. RAN 2 может выполнять настройку обеспечения безопасности AS в соответствии с принятым ключом обеспечения безопасности (K_eNB) и Алгоритмом Обеспечения Безопасности UE. Настройка обеспечения безопасности AS может быть выполнена до и после передачи сообщения NAS: Прикрепление Принято к UE 1.

[0064] Несмотря на то, что Фиг. 3 показывает Мобильно Порожденную (MO) передачу данных, процедура, сходная с той, что показана на Фиг. 3, может быть применена к Мобильно Завершенной (MT) передаче данных.

[0065] В примере, показанном на Фиг. 3, UE 1 определяет тип архитектуры связи, который должен быть использован для передачи пакета данных для UE 1 и передает RAN 2 сообщение Запрос Соединения RRC, включающее в себя причину создания или другой элемент информации, указывающий определенный тип архитектуры связи. Использование причины создания или другого элемента информации, включенного в сообщение Запрос Соединения RRC, чтобы указывать тип архитектуры связи, определенный посредством UE 1, предоставляет следующие преимущества, например. Во-первых, оно позволяет UE 1 передавать тип архитектуры связи, определенный посредством UE 1, в качестве информации AS (RRC), вместо информации NAS. Вследствие этого, RAN 2 может распознать тип архитектуры связи желаемый UE 1, и, следовательно, RAN 2 может выполнять процесс (например, выбор CN (DCN)) в соответствии с типом архитектуры связи, желаемым UE 1. Во-вторых, оно позволяет UE 1 уведомлять RAN 2 о типе архитектуры связи, определенном посредством UE 1, до создания соединения RRC. Таким образом, RAN 2 может сократить число сообщений сигнализации, требуемое для настройки соединения RRC в соответствии с типом архитектуры связи, определенным посредством UE 1.

[0066] Второй вариант осуществления

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

[0067] Этапы с 401 по 404 являются сходными с этапами с 301 по 304, показанными на Фиг. 3. Тем не менее, сообщение Запрос Соединения RRC на этапе 403 не указывает тип архитектуры связи, определенный (выбранный) посредством UE 1.

[0068] На этапе 405, UE 1 передает сообщение Завершена Настройка Соединения Связи RRC к RAN 2. Данное сообщение Завершена Настройка Соединения RRC передается посредством SRB 1 по DCCH. Сообщение Завершена Настройка Соединения RRC включает в себя исходное сообщение NAS и вспомогательный Элемент Информации (IE) UE касательно типа архитектуры связи, определенного посредством UE 1, который явным или неявным образом указывает тип архитектуры связи. Вспомогательный IE UE может быть информацией NAS или может быть информацией AS (RRC).

[0069] Когда вспомогательный IE UE является информацией AS (RRC), в зависимости от типа архитектуры связи, определенного посредством UE 1, RAN 2 может передавать конфигурацию PDCP (pdcp-Config) для SRB 1 к UE 1 или может уведомлять UE 1 о том, что используется (применяется) слой PDCP. В частности, RAN 2 может передавать конфигурацию PDCP для SRB 1 к UE 1, когда UE 1 выбирает второй тип архитектуры связи.

[0070] RAN 2 принимает сообщение Завершена Настройка Соединения RRC от UE 1 и отправляет CN 3 исходное сообщение NAS (т.е., сообщение Запрос Прикрепления), извлеченный из сообщения Завершена Настройка Соединения RRC (например, MME или C-SGN), используя исходное сообщение UE. Когда вспомогательным IE UE является информация AS (RRC), RAN 2 может выбирать, из DCN в CN 3, DCN соответствующую типу архитектуры связи, определенному посредством UE 1, и отправлять Исходное сообщение UE, несущее исходное сообщение NAS (т.е., сообщение Запрос Прикрепления) к выбранной DCN. В противоположность этому, когда вспомогательным IE UE является информация NAS, вспомогательный IE UE включается в Элемент Информации (IE) NAS-PDU S1AP: Исходное сообщение UE вместе с исходным сообщением NAS. В данном случае, RAN 2 может принимать уведомление явным или неявным образом указывающее тип архитектуры связи, определенный посредством UE 1 от CN 3, используя, например, сообщение Запрос Настройки Исходного Контекста (например, IE Типа Архитектуры).

[0071] Этапы с 406 по 409 являются сходными с этапами с 306 по 309, показанными на Фиг. 3.

[0072] Процедура, показанная на Фиг. 4, может быть модифицирована, например, следующим образом. RAN 2 или CN 3 могут использовать тип архитектуры связи отличный от типа архитектуры связи, указываемого UE 1 в сообщении Завершена Настройка Соединения RRC или сообщении Запрос Прикрепления от UE 1 (этап 404).

[0073] В ответ на сообщение Завершена Настройка Соединения RRC (этап 404), RAN 2 может передавать сообщение Отклонение Соединения RRC, указывающее отличный тип архитектуры связи (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры) к UE 1. В данном случае, UE 1 может перезапускать новую процедуру Настройка Соединения RRC.

[0074] В качестве альтернативы, CN 3 может уведомлять UE 1 об отличном типе архитектуры связи (например, Применяемом Типе Архитектуры или Выбранном Типе Архитектуры), используя сообщение Прикрепление Принято (этап 407). В данном случае, UE 1 может прекращать текущую процедуру прикрепления и перезапускать процедуру настройки соединения RRC. В качестве альтернативы, UE 1 может продолжать текущую процедура прикрепления в соответствии с уведомлением об отличном типе архитектуры связи, переданном от RAN 2.

[0075] Когда второй тип архитектуры связи, в котором пакеты данных пользователя передаются через плоскость пользователя (например, носитель EPS, включающий в себя DRB и туннель Протокола Туннелирования GPS (GTP)), используется для UE 1, CN 3 может включать сообщение NAS: Прикрепление Принято в сообщение S1AP: Запрос Настройки Исходного Контекста и передавать их к RAN 2 на этапе 407. Данное сообщение S1AP: Запроса Настройки Исходного Контекста включает в себя ключ обеспечения безопасности (K_eNB) и Алгоритм Обеспечения Безопасности UE, используемые для UE 1. RAN 2 может выполнять настройку обеспечения безопасности AS в соответствии с принятым ключом обеспечения безопасности (K_eNB) и Алгоритмом Обеспечения Безопасности UE. Настройка обеспечения безопасности AS может быть выполнена до или после передачи сообщения NAS: Прикрепление Принято к UE 1.

[0076] Несмотря на то, что Фиг. 4 показывает Мобильно Порожденную (MO) передачу данных, процедура, сходная с той, что показана на Фиг. 4, может быть применена к Мобильно Завершенной (MT) передаче данных.

[0077] В примере, показанном на Фиг. 4, UE 1 определяет тип архитектуры связи, который должен быть использован для передачи пакета данных для UE 1 и передает RAN 2 сообщение Завершена Настройка Соединения RRC, включающее в себя вспомогательный IE UE, указывающий определенный тип архитектуры связи. Использование сообщения Завершена Настройка Соединения RRC, чтобы указывать тип архитектуры связи, определенный посредством UE 1, предоставляет следующие преимущества, например. В некоторых реализациях, оно позволяет UE 1 передавать тип архитектуры связи, определенный посредством UE 1, в качестве информации NAS. Вследствие этого, UE 1 может легко уведомлять CN 3 о типе архитектуры связи, желаемом UE 1.

[0078] Третий вариант осуществления

[0079] Этапы с 501 по 504 являются сходными с этапами с 402 по 405, показанными на Фиг. 4. Тем не менее, сообщение Завершена Настройка Соединения RRC на этапе 504 включает в себя элемент информации касательно типов архитектуры связи (например, Поддерживаемый UE Тип Архитектуры), который явным или неявным образом указывает один или более типы архитектуры связи, поддерживаемые UE 1. Соответственно, данный элемент информации позволяет RAN 2 (например, CIoT-BS или eNB) обнаруживать один или более типы архитектуры связи, поддерживаемые UE 1.

[0080] Данный элемент информации может указывать, например, тип(ы) архитектуры связи, поддерживаемый UE 1 (например, {type1, type2, …}, или {DONAS, RRC-Suspend, …}). Элемент информации может быть битовой картой, указывающей, какой один или более из множества типов архитектуры связи, поддерживаются UE 1. Элемент информации может быть флагом или битовой картой, указывающей, поддерживается ли UE 1 один или более опциональные типы архитектуры связи отличные от типа архитектуры связи по умолчанию. Т.е., элемент информации может указывать, что поддерживается опциональный тип архитектуры связи (например, поддерживается typeX), или может указывать поддерживается ли опциональный тип архитектуры связи (например, Поддержка typeX=ENUMERATED {true, …}, или {Поддерживается, Не Поддерживается}). Описанные выше значения «type1» и «type2» (и «typeX») могут быть заменены именами, которые указывают тип архитектуры связи более конкретным образом, такими как «DataOverNAS (DONAS)» или «RRC-Suspend».

[0081] На этапе 505, RAN 2 определяет тип архитектуры связи, который должен быть использован UE 1, с учетом одного или более типов архитектуры связи, поддерживаемых UE 1. В некоторых реализациях, RAN 2 может выбирать тип архитектуры связи, используемый для UE 1, на основе возможности UE по умолчанию, которая была предварительно сконфигурирована в UE 1. Дополнительно или в качестве альтернативы, RAN 2 может выбирать тип архитектуры связи, используемый для UE 1, на основе принятой мощности на UE 1 опорного сигнала, переданного от RAN 2 (т.е., RSPR) или оцененных потерь при распространении между UE 1 и RAN 2 (например, CIoT-BS/eNB). Результат измерения RSRP или потерь при распространении может быть отправлен от UE 1 к RAN 2. Дополнительно или в качестве альтернативы, RAN 2 может выбирать тип архитектуры связи, используемый для UE 1, на основе возможности сети у CN 3. Дополнительно или в качестве альтернативы, RAN 2 может выбирать тип архитектуры связи, используемый для UE 1, на сновании нагрузки на RAN 2 (например, нагрузки Соты, нагрузки Слоя Транспортной Сети (TNL) S1, числа Соединенных UE, или числа UE, чей контекст UE сохранен).

[0082] В зависимости от типа архитектуры связи, определенного посредством UE 1, RAN 2 может передавать конфигурацию PDCP (pdcd-Config) для SRB 1 к UE 1 или может уведомлять UE 1 о том, что используется (применяется) слой PDCP. В частности, RAN 2 может передавать конфигурацию PDCP для SRB 1 к UE 1, когда RAN 2 выбирает второй типа архитектуры связи для UE 1.

[0083] На этапе 506, RAN 2 отправляет исходное сообщение NAS (т.е., сообщение Запрос Прикрепления), извлеченное из сообщения Завершена Настройка Соединения RRC к CN 3 (например, MME или C-SGN), используя S1AP: Исходное сообщение UE. Исходное сообщение NAS (т.е., сообщение Запрос Прикрепления) встраивается в Элемент Информации (IE) NAS-PDU у S1AP: Исходное сообщение UE. RAN 2 может включать элемент информации, указывающий тип архитектуры связи, определенный на этапе 505, в S1AP: Исходное сообщение UE. RAN 2 может выбирать, из DCN в CN 3, DCN соответствующую типу архитектуры связи, определенному на этапе 505, и отправлять S1AP: Исходное сообщение UE, несущее исходное сообщение NAS (т.е., сообщение Запрос Прикрепления) к выбранной DCN.

[0084] Этапы с 507 по 510 являются сходными с этапами с 306 по 309 на Фиг. 3 или этапами с 406 по 409 на Фиг. 4.

[0085] Когда второй тип архитектуры связи используется для UE 1, процедура, показанная на Фиг. 5, может быть изменена так, что настройка обеспечения безопасности AS выполняется как и в случае описанных выше других процедур. Несмотря на то, что Фиг. 5 показывает Мобильно Порожденную (MO) передачу данных, процедура, сходная с той, что показана на Фиг. 5, может быть применена к Мобильно Завершенной (MT) передаче данных.

[0086] Четвертый вариант осуществления

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

[0087] Этапы 601 и 602 являются сходными с этапами 302 и 303, показанными на Фиг. 3. Тем не менее, сообщение Запрос Соединения RRC на этапе 602 включает в себя элемент информации, указывающий один или более типы архитектуры связи, поддерживаемые UE 1 (например, Поддерживаемый UE Тип Архитектуры). Данный элемент информации является информацией AS (RRC). Соответственно, данный элемент информации позволяет RAN 2 (например, CIoT-BS или eNB) обнаруживать один или более типы архитектуры связи, поддерживаемые UE 1.

[0088] На этапе 603, RAN 2 определяет тип архитектуры связи, используемый для UE 1, с учетом одного или более типов архитектуры связи, поддерживаемых UE 1.

[0089] Этап 604 является сходным с этапом 304 на Фиг. 3. Тем не менее, сообщение Настройка Соединения RRC на этапе 604, может указывать тип архитектуры связи, определенный посредством RAN 2 на этапе 603 (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры).

[0090] Этапы 605 и 606 являются сходными с этапами 305 на Фиг. 3. Тем не менее, RAN 2 может включать элемент информации, указывающий тип архитектуры связи, определенный на этапе 603 (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры) в S1AP: Исходное сообщение UE. RAN 2 может выбирать, из DCN в CN 3, DCN соответствующую типу архитектуры связи, определенному на этапе 603, и отправляет S1AP: Исходное сообщение UE, несущее исходное сообщение NAS (т.е., сообщение Запрос Прикрепления) к выбранной DCN.

[0091] Этапы с 607 по 610 являются сходными с этапами с 306 по 309 на Фиг. 3 или этапами с 507 по 510 на Фиг. 5.

[0092] Когда второй тип архитектуры связи используется для UE 1, процедура, показанная на Фиг. 6, может быть изменена так, что настройка обеспечения безопасности AS выполняется как и в случае описанных выше других процедур. Несмотря на то, что Фиг. 6 показывает Мобильно Порожденную (MO) передачу данных, процедура, сходная с той, что показана на Фиг. 6, может быть применена к Мобильно Завершенной (MT) передаче данных.

[0093] Пятый вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. Данный вариант осуществления предоставляет другую процедуру связи, включающую определение (или выбор) архитектуры связи, используемой для UE 1. Фиг. 7 является циклограммой, показывающей пример процедуры связи в соответствии с данным вариантом осуществления. В процедуре, показанной на Фиг. 7, RAN 2 определяет тип архитектуры связи, используемый для передачи пакета данных для UE 1, во время процедуры для прикрепления UE 1 к CN 3. Отметим, что процедура, показанная на Фиг. 7 отличается от тех, что показаны на Фиг. 5 и 6 тем, что элемент информации касательно типов архитектуры связи, поддерживаемых UE 1 (например, Поддерживаемый UE Тип Архитектуры), который явным или неявным образом указывает один или более типы архитектуры связи, поддерживаемые UE 1, передается в качестве информации NAS совместно с исходным сообщением NAS (т.е., сообщением Запрос Прикрепления).

[0094] Этапы с 701 по 704 являются сходными с этапами с 402 по 405, показанными на Фиг. 4. Тем не менее, на этапе 704, UE 1 передает элемент информации NAS, указывающий один или более типы архитектуры связи, поддерживаемые UE 1 (например, Поддерживаемый UE Тип Архитектуры) вместе с сообщением Запрос Прикрепления. Данный элемент информации NAS может указывать, например, тип(ы) архитектуры связи, поддерживаемый UE 1 (например, {type1, type2, …}, или {DONAS, RRC-Suspend, …}). В качестве альтернативы, элемент информации NAS может указывать, что поддерживается опциональный тип архитектуры связи (например, поддерживается typeX), или может указывать поддерживается ли опциональный тип архитектуры связи (например, Поддержка typeX=ENUMERATED {true, …}, или {Поддерживается, Не Поддерживается}). Описанные выше значения «type1» и «type2» (и «typeX») могут быть заменены именами, которые указывают тип архитектуры связи более конкретным образом, такими как «DataOverNAS (DONAS)» или «RRC-Suspend».

[0095] На этапе 705, CN 3 отправляет сообщение S1AP: Запрос Настройки Исходного Контекста, указывающее один или более типы архитектуры связи, поддерживаемые UE 1 (например, Поддерживаемый UE Тип Архитектуры) к RAN 2. На этапе 706, RAN 2 определяет тип архитектуры связи, используемый для UE 1 с учетом одного или более типов архитектуры связи, поддерживаемых UE 1, на основе информации принятой от CN 3. RAN 2 может уведомлять CN 3 об определенном типе архитектуры связи используя сообщение S1AP: Ответ Настройки Исходного Контекста (этап 707).

[0096] Этапы с 708 по 711 являются сходными с этапами с 306 по 309 на Фиг. 3, этапами с 507 по 510 на Фиг. 5, или этапами с 607 по 610 на Фиг. 6.

[0097] Когда второй тип архитектуры связи используется для UE 1, процедура, показанная на Фиг. 7, может быть изменена так, что настройка обеспечения безопасности AS выполняется как и в случае описанных выше других процедур. Несмотря на то, что Фиг. 7 показывает Мобильно Порожденную (MO) передачу данных, процедура, сходная с той, что показана на Фиг. 7, может быть применена к Мобильно Завершенной (MT) передаче данных.

[0098] Шестой вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. Данный вариант осуществления предоставляет другую процедуру связи, включающую определение (или выбор) архитектуры связи, используемой для UE 1. Фиг. 8 является циклограммой, показывающей пример процедуры связи в соответствии с данным вариантом осуществления. В процедуре, показанной на Фиг. 8, RAN 2 определяет тип архитектуры связи, используемый для передачи пакета данных для UE 1, во время процедуры для прикрепления UE 1 к CN 3. Отметим, что процедура, показанная на Фиг. 8, отличается от тех, что показаны на Фиг. с 5 по 7 тем, что элемент информации касательно типов архитектуры связи (например, Поддерживаемый UE Тип Архитектуры), который явным или неявным образом указывает один или более типы архитектуры связи, поддерживаемые UE 1, передается от HSS 5 к RAN 2 через CN 3 (например, MME или C-SGN).

[0099] Этапы с 801 по 804 являются сходными с этапами с 701 по 704, показанными на Фиг. 7. Тем не менее, на этапе 804, UE 1 не требуется передавать элемент информации NAS (например, Поддерживаемый UE Тип Архитектуры), указывающий один или более типы архитектуры связи, поддерживаемые UE 1.

[0100] На этапе 805, CN 3 (например, MME или C-SGN) выполняет процедуру аутентификации и обеспечения безопасности и тем самым настраивает обеспечение безопасности NAS. На этапе 806, когда CN 3 (например, MME или C-SGN) принимает информацию аутентификации, касательно UE 1 от HSS 5, CN 3 дополнительно принимает один или более типы архитектуры связи, поддерживаемые UE 1 (например, Поддерживаемый UE Тип Архитектуры) от HSS 5. HSS 5 осуществляет администрирование Поддерживаемого UE Типа Архитектуры в качестве информации абонента касательно UE 1.

[0101] Этапы с 807 по 809 являются сходными с этапами с 705 по 707 на Фиг. 7. Этапы с 810 о 812 являются сходными с этапами с 307 по 309 на Фиг. 3, этапами с 508 по 510 на Фиг. 5, этапами с 608 по 611 на Фиг. 6, или этапами с 709 по 711 на Фиг. 7.

[0102] Когда второй тип архитектуры связи используется для UE 1, процедура, показанная на Фиг. 8, может быть изменена так, что настройка обеспечения безопасности AS выполняется как и в случае описанных выше других процедур. Несмотря на то, что Фиг. 8 показывает Мобильно Порожденную (MO) передачу данных, процедура, сходная с той, что показана на Фиг. 8, может быть применена к Мобильно Завершенной (MT) передаче данных.

[0103] Седьмой вариант осуществления

[0104] Этапы с 901 по 904 являются сходными с этапами с 701 по 704 на Фиг. 7. Т.е., на этапе 904, CN 3 (например, MME или C-SGN) принимает элемент информации касательно типов архитектуры связи (например, Поддерживаемый UE Тип Архитектуры), который явным или неявным образом указывает один или более типы архитектуры связи, поддерживаемые UE 1, вместе с сообщением Запрос Прикрепления от UE 1.

[0105] На этапе 905, CN 3 определяет тип архитектуры связи, используемый для UE 1, с учетом одного или более типов архитектуры связи, поддерживаемых UE 1 (например, Поддерживаемый UE Тип Архитектуры). В некоторых реализациях, CN 3 может выбирать тип архитектуры связи, используемый для UE 1, на основе возможности UE по умолчанию, которая была предварительно сконфигурирована в UE 1. Дополнительно или в качестве альтернативы, CN 3 может выбирать тип архитектуры связи, используемый для UE 1, на основе возможности сети у RAN 2 (например, CIoT Bs или eNB). Дополнительно или в качестве альтернативы, CN 3 может выбирать тип архитектуры связи, используемый для UE 1, на основе нагрузки на CN 3 (например, нагрузки Слоя Транспортной Сети (TNL) S1, числа Соединенных UE, числа UE, чей контекст UE сохранен). Дополнительно или в качестве альтернативы, CN 3 может выбирать типа архитектуры связи, используемый для UE 1, на основе Качества Услуги (QoS) применяемого к UE 1 (например, Идентификатора Класса QoS (QCI), Приоритета Распределения и Сохранности (ARP), типа ресурса (Гарантированная Скорость передачи Битов (GBR) или не-GBR).

[0106] На этапе 906, CN 3 отправляет сообщение S1AP: Запрос Настройки Исходного Контекста, указывающее тип архитектуры связи, определенный на этапе 905 (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры) к RAN 2. RAN 2 может отправлять ответ на уведомление, принятое на этапе 906 (этап 907).

[0107] Этапы с 908 по 911 являются сходными с этапами с 306 по 309 на Фиг. 3, этапами с 406 по 409 на Фиг. 4, этапами с 507 по 510 на Фиг. 5, этапами с 607 по 610 на Фиг. 6, или этапы с 708 по 711 на Фиг. 7.

[0108] Когда второй тип архитектуры связи используется для UE 1, процедура, показанная на Фиг. 9, может быть изменена так, что настройка обеспечения безопасности AS выполняется как и в случае описанных выше других процедур. Несмотря на то, что Фиг. 9 показывает Мобильно Порожденную (MO) передачу данных, процедура, сходная с той, что показана на Фиг. 9, может быть применена к Мобильно Завершенной (MT) передаче данных.

[0109] Восьмой вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. Данный вариант осуществления предоставляет другую процедуру связи, включающую определение (или выбор) архитектуры связи, используемой для UE 1. Фиг. 10 является циклограммой, показывающей пример процедуры связи в соответствии с данным вариантом осуществления. В процедуре, показанной на Фиг. 10, CN 3 определяет тип архитектуры связи, используемой для передачи пакета данных для UE 1, во время процедуры для прикрепления UE 1 к CN 3. Отметим, что процедура, показанная на Фиг. 10, отличается от той, что показан на Фиг. 9 тем, что элемент информации касательно типов архитектуры связи (например, Используемый UE Тип Архитектуры), который явным или неявным образом указывает один или более типы архитектуры связи, поддерживаемые UE 1, передается от HSS 5 к CN 3 (например, MME или C-SGN).

[0110] Этапы с 1001 по 1006 являются сходными с этапами с 801 по 806 на Фиг. 8. Этапы с 1007 по 1009 являются сходными с этапами с 905 по 907 на Фиг. 9. Этапы с 1010 по 1012 являются сходными с этапами с 307 по 309 на Фиг. 3, этапами с 407 по 409 на Фиг. 4, этапами с 508 по 510 на Фиг. 5, этапами с 608 по 610 на Фиг. 6, этапами с 709 по 711 на Фиг. 7, этапами с 810 по 812 на Фиг. 8, или этапами с 909 по 911 на Фиг. 9.

[0111] Когда второй тип архитектуры связи используется для UE 1, процедура, показанная на Фиг. 10, может быть изменена так, что настройка обеспечения безопасности AS выполняется как и в случае описанных выше других процедур. Несмотря на то, что Фиг. 10 показывает Мобильно Порожденную (MO) передачу данных, процедура, сходная с той, что показана на Фиг. 10, может быть применена к Мобильно Завершенной (MT) передаче данных.

[0112] Девятый вариант осуществления

[0113] Фиг. 11 показывает случай, где первый тип архитектуры связи используется для UE 1. Как уже описывалось, в первом типе архитектуры связи, пакеты данных пользователя, передаваемые или принимаемые посредством UE 1, переносятся через плоскость управления (например, сообщение NAS, передаваемое между UE и MME/C-SGN). Между тем, Фиг. 12 показывает случай, где второй тип архитектуры связи используется для UE 1. Во втором типе архитектуры связи, пакеты данных пользователя, передаваемые или принимаемые посредством UE 1, переносятся через плоскость пользователя (например, носитель EPS, включающий в себя DRB и туннель Протокола Туннелирования GPS (GTP)).

[0114] Обращаясь к Фиг. 11, UE 1 определяет (выбирает) тип архитектуры связи, используемый для передачи пакета данных для UE 1 на этапе 1101. Определение типа архитектуры может учитывать параметры, сходные с теми, что на этапе 301 на Фиг. 3. В примере, показанном на Фиг. 11, UE 1 может определять (или выбирать) тип архитектуры связи при каждой возможности передачи. Соответственно, UE 1 может учитывать параметр(ы), который динамически меняется при каждой возможности передачи. Например, UE 1 может выбирать тип архитектуры связи в соответствии с инициирующим событием передачи данных (например, mo-Data, mo-ExceptionData, mt-Access, или mo-Signaling). Дополнительно или в качестве альтернативы, UE 1 может выбирать тип архитектуры связи в соответствии с типом приложения, которое выполняет передачу пакета данных.

[0115] Этапы с 1102 по 1106 являются сходными с этапами с 302 по 305 на Фиг. 3. Тем не менее, пример на Фиг. 11 показывает переход из режима RRC-Idle (или другого режима приостановки) в режим RRC-Connected, выполняемый после прикрепления. Кроме того, в примере, показанном на Фиг. 11, UE 1 выбирает первый тип архитектуры связи на этапе 1101. Таким образом, исходное сообщение NAS, передаваемое посредством UE 1 на этапе 1105, является сообщением NAS, несущим небольшие данные. Т.е., комбинированные передачи небольших данных в исходном сообщении NAS.

[0116] На этапе 1106, RAN 2 отправляет исходное сообщение NAS (т.е., сообщение NAS, несущее небольшие данные), извлеченное из сообщения Завершена Настройка Соединения RRC к CN 3 (например, MME или C-SGN), используя S1AP: Исходное сообщение UE. Исходное сообщение NAS (т.е., сообщение NAS, несущее небольшие данные) встроено в Элемент Информации (IE) NAS-PDU S1AP: Исходное сообщение UE. RAN 2 может включать элемент информации, явным или неявным образом указывающий первый тип архитектуры связи, определенный посредством UE 1, в S1AP: Исходное сообщение UE. RAN 2 может выбирать, из DCN в CN 3, DCN соответствующую первому типу архитектуры связи, определенному посредством UE 1, и отправлять S1AP: Исходное сообщение UE к выбранной DCN.

[0117] На этапе 1107, CN 3 (например, MME или X-SGN) дешифрует сообщение NAS восходящей линии связи, переданное от UE 1, чтобы получить пакет небольших данных. На этапе 1108, CN 3 переадресовывает пакет небольших данных в соответствии с типом данных у пакета небольших данных. Когда ожидается, что должна быть передана ACK или ответ на Мобильно Порожденный небольшой пакет, CN 3 принимает поступающий ответный пакет данных нисходящей линии связи (этап 1109). На этапе 1110, CN 3 шифрует пакет данных нисходящей линии связи и генерирует сообщение NAS нисходящей линии связи, несущее зашифрованный пакет данных нисходящей линии связи. На этапе 1111, CN 3 отправляет сообщение S1AP: Транспорта NAS DL к RAN 2. На этапе 1112, RAN 2 передает сообщение RRC: Перенос Информации DL к UE 1 по SRB 1. Данное сообщение Перенос Информации DL включает в себя сообщение NAS нисходящей линии связи, несущее зашифрованный пакет данных нисходящей линии связи, предназначенный для UE 1.

[0118] Далее, обращаясь к Фиг. 12, этап 1201 на Фиг. 12 является сходным с этапом 1101 на Фиг. 11. Тем не менее, в примере, показанном на Фиг. 12, UE 1 выбирает второй тип архитектуры связи для передачи пакета данных для UE 1.

[0119] Этапы с 1202 по 1206 являются сходными с этапами с 1102 по 1106 на Фиг. 11. Тем не менее, поскольку второй тип архитектуры связи используется в примере, показанном на Фиг. 12, исходное сообщение NAS, передаваемое посредством UE 1 на этапе 1205, является сообщением Запрос Услуги.

[0120] На этапе 1206, RAN 2 отправляет исходное сообщение NAS (т.е., сообщение Запрос Услуги), извлеченное из сообщения Завершена Настройка Соединения RRC к CN 3 (например, MME или C-SGN), используя S1AP: Исходное сообщение UE. Исходное сообщение NAS (т.е., сообщение Запрос Услуги) встраивается в Элемент Информации (IE) NAS-PDU S1AP: Исходное сообщение UE. RAN 2 может включать элемент информации, явным или неявным образом указывающий второй тип архитектуры связи, определенный UE 1, в S1AP: Исходное сообщение UE. RAN 2 может выбирать, из DCN в CN 3, DCN соответствующую второму типу архитектуры связи, определенному посредством UE 1, и отправлять S1AP: Исходное сообщение UE к выбранной DCN.

[0121] Этапы с 1207 по 1211 являются сходными с процедурой создания носителя EPS в существующей процедуре запроса услуги. На этапах 1212 и 1213 UE 1 передает данные восходящей линии связи по носителя восходящей линии связи через S-GW 6 и RAN 2 и принимает данные нисходящей линии связи по носителю нисходящей линии связи через S-GW 6 и RAN 2.

[0122] На этапе 1214, UE 1, RAN 2, и CN 3 приостанавливают соединение RRC. UE 1 переходит из режима RRC-Connected в режим RRC-Idle (или другой режим приостановки) и удерживает информацию касательно соединения RRC (например, Контекст Обеспечения Безопасности Уровня Доступа, связанную с носителем информацию (включая информацию о состоянии RoHC), и параметры L2/1, если применимо) в то время, пока оно в режиме RRC-Idle (или другом режиме приостановки). Сходным образом, RAN 2 удерживает информацию касательно соединения RRC для UE 1 (например, Контекст Обеспечения Безопасности Уровня Доступа, связанную с носителем информацию (включая информацию о состоянии RoHC), и параметры L2/1, если применимо). Кроме того, RAN 2 и CN 3 удерживают S1AP Контексты UE. Кроме того, RAN 2 удерживает адреса туннеля S1-U. Таким образом, UE 1, RAN 2, и CN 3 могут повторно использовать информацию, полученную из предыдущего соединения RRC, для последующей настройки соединения RRC.

[0123] Несмотря на то, что Фиг. 11 и 12 показывают Мобильно Порожденную (MO) передачу данных, процедуры, сходные с теми, что показаны на Фиг. 11 и 12, могут быть применены к Мобильно Завершенной (MT) передаче данных.

[0124] Процедура, показанная на Фиг. 12 может быть модифицирована следующим образом. В некоторых реализациях, S1AP: Исходное сообщение UE на этапе 1206 может указывать идентификатор конечной точки туннеля нисходящей линии связи, используемый во второй архитектуре связи. Идентификатор конечной точки туннеля нисходящей линии связи указывает конечную точку туннеля в RAN 2 у носителя между RAN 2 и CN 3, который используется для передачи пакета данных для UE 1 во втором типе архитектуры связи. Идентификатор конечной точки туннеля нисходящей линии связи может быть S1 eNB TEID (т.е., S1 TEID (DL)) у носителя S1 (т.е., туннеля GTP). Кроме того, S1AP: Исходное сообщение UE на этапе 1206 может указывать адрес RAN 2 (например, адрес eNB), используемый для передачи пакета данных для UE 1 во втором типе архитектуры связи. Таким образом, можно опустить передачу сообщения Запрос Модифицирования Носителя от MME к S-GW и сообщение Ответ Модифицирования Носителя от S-GW к MME, которые необходимы в существующей процедуре создания носителя EPS. Дополнительно или в качестве альтернативы, можно опустить передачу сообщения Ответ Настройки Исходного Контекста от eNB к MME, которое необходимо в существующей процедуре создания носителя EPS. В CIoT, RAN 2 и CN 3 требуется иметь возможность осуществления связи с большим числом устройств CIoT. Посредством исключения передачи этих сообщений сигнализации, можно внести вклад в сокращение относящейся к CIoT нагрузки в RAN 2 и CN 3.

[0125] В примерах, показанных на Фиг. 11 и 12, UE 1 определяет тип архитектуры связи, используемый для передачи пакета данных для UE 1, и передает RAN 2 сообщение Запрос Соединения RRC, включающее в себя причину создания, указывающую определенный тип архитектуры связи. Соответственно, примеры, показанные на Фиг. 11 и 12 могут обеспечивать точно такие же преимущества, как пример, показанный на Фиг. 3. Кроме того, примеры, показанные на Фиг. 11 и 12, позволяют UE 1 определять тип архитектуры связи, используемый для передачи пакета данных для UE 1, во время процедуры настройки соединения RRC, в которой UE 1 переходит из режима RRC-Idle (или другого режима приостановки) в режим RRC-Connected, чтобы выполнять передачу пакета данных после прикрепления.

[0126] Десятый вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. Данный вариант осуществления предоставляет другую процедуру связи, включающую определение (или выбор) архитектуры связи, используемой для UE 1. Фиг. 13 и 14 показывают циклограмму, показывающую пример процедуры связи в соответствии с данным вариантом осуществления. В процедуре, показанной на Фиг. 13 и 14, UE 1 определяет тип архитектуры связи, используемый для передачи пакета данных для UE 1, во время процедуры настройки соединения RRC, в которой UE 1 переходит из режима RRC-Idle (или другого режима приостановки) в режим RRC-Connected, чтобы выполнять передачу пакета данных после прикрепления. Фиг. 13 показывает случай, где первый тип архитектуры связи используется для UE 1. Между тем, Фиг. 14 показывает случай, где второй тип архитектуры связи используется для UE 1. Отметим, что процедуры на Фиг. 13 и 14 отличаются от процедур на Фиг. 11 и 12 тем, что тип архитектуры связи, определенный UE 1, отправляется к RAN 2 посредством сообщения Завершена Настройка Соединения RRC.

[0127] Обращаясь к Фиг. 13, этапы с 1301 по 1312 являются сходными с этапами с 1101 по 1112 на Фиг. 11. Тем не менее, в процедуре на Фиг. 13, UE 1 передает, к RAN 2, Вспомогательный Элемент Информации (IE) UE, явным или неявным образом указывающий первый тип архитектуры связи, определенный посредством UE 1, используя сообщение Завершена Настройка Соединения RRC (этап 1305), как в процедуре на Фиг. 4.

[0128] Далее, обращаясь к Фиг. 14, этапы с 1401 по 1414 являются сходными с этапами с 1201 по 1214 на Фиг. 12. Тем не менее, в процедуре на Фиг. 14, UE 1 передает, к RAN 2, Вспомогательный Элемент Информации (IE) UE, явным или неявным образом указывающий второй тип архитектуры связи, определенный посредством UE 1, используя сообщение Завершена Настройка Соединения RRC (этап 1405), как в процедуре на Фиг. 4.

[0129] Несмотря на то, что Фиг. 13 и 14 показывают Мобильно Порожденную (MO) передачу данных, процедуры, сходные с теми, что показаны на Фиг. 13 и 14, могут быть применены к Мобильно Завершенной (MT) передаче данных.

[0130] В примерах, показанных на Фиг. 13 и 14, UE 1 определяет тип архитектуры связи, используемый для передачи пакета данных для UE 1, и передает RAN 2 сообщение Завершена Настройка Соединения RRC, включающее в себя вспомогательный IE UE, указывающий определенный тип архитектуры связи. Соответственно, примеры, показанные на Фиг. 13 и 14, могут предоставлять точно такие же преимущества, как пример, показанный на Фиг. 4. Кроме того, пример, показанный на Фиг. 13 и 14 позволяет UE 1 определять тип архитектуры связи, используемый для передачи пакета данных для UE 1, во время процедуры настройки соединения RRC в которой UE 1 переходит из режима RRC-Idle (или другого режима приостановки) в режим RRC-Connected, чтобы выполнять передачу пакета данных после прикрепления.

[0131] Одиннадцатый вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. Данный вариант осуществления предоставляет другую процедуру связи, включающую определение (или выбор) архитектуры связи, используемой для UE 1. Фиг. 15 и 16 показывают циклограмму, показывающую пример процедуры связи в соответствии с данным вариантом осуществления. В процедуре, показанной на Фиг. 15 и 16, RAN 2 определяет тип архитектуры связи, используемый для передачи пакета данных для UE 1, во время настройки соединения RRC, в которой UE 1 переходит из режима RRC-Idle (или другого режима приостановки) в режим RRC-Connected, чтобы выполнять передачу пакета данных после прикрепления. Фиг. 15 показывает случай, где первый тип архитектуры связи используется для UE 1. Между тем, Фиг. 16 показывает случай, где второй тип архитектуры связи используется для UE 1. Отметим, что процедуры на Фиг. 15 и 16 отличаются от процедур на Фиг. 11 и 12 тем, что RAN 2 определяет тип архитектуры связи.

[0132] Обращаясь к Фиг. 15, этапы с 1501 по 1505 являются сходными с этапами с 601 по 605 на Фиг. 6. Тем не менее, пример на Фиг. 15 показывает переход из режима RRC-Idle (или другого режима приостановки) в режим RRC-Connected, выполняемый после прикрепления. Кроме того, в примере, показанном на Фиг. 15, RAN 2 выбирает первый тип архитектуры связи для UE 1 на этапе 1503. Таким образом, исходное сообщение NAS, передаваемое посредством UE 1 на этапе 1505, является сообщением NAS, несущим небольшие данные. Т.е., комбинированные передачи небольших данных в исходном сообщении NAS. Сообщение Настройка Соединения RRC на этапе 1504 может явным или неявным образом указывать первый тип архитектуры связи, определенный посредством RAN 2 на этапе 1503 (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры).

[0133] Когда RAN 2 явным образом указывает тип архитектуры связи, RAN 2 может передавать UE 1 сообщение Настройка Соединения RRC, включающее в себя элемент информации слоя AS (например, слоя RRC) или элемент информации слоя NAS, указывающий тип архитектуры связи. Когда передается элемент информации NAS, указывающий тип архитектуры связи, слой NAS у UE 1 может отправлять информацию, указывающую тип архитектуры связи, который должен быть использован, слою AS у UE 1, или может запускать передачу данных в соответствии с типом архитектуры связи. С другой стороны, когда RAN 2 неявным образом указывает тип архитектуры связи, RAN 2 может уведомлять UE 1 о выбранном типе архитектуры связи посредством включения информации конфигурации для выбранного типа архитектуры связи в сообщение Настройка Соединения RRC.

[0134] На этапе 1506, RAN 2 отправляет исходное сообщение NAS (т.е., сообщение NAS, несущее небольшие данные), извлеченное из сообщения Завершена Настройка Соединения RRC к CN 3 (например, MME или C-SGN), используя S1AP: Исходное сообщение UE. Исходное сообщение NAS (т.е., сообщение NAS, несущее небольшие данные) встраивается в Элемент Информации (IE) NAS-PDU у S1AP: Исходное сообщение UE. RAN 2 может включать элемент информации, указывающий тип архитектуры связи, определенный на этапе 1503 (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры) в S1AP: Исходное сообщение UE. RAN 2 может выбирать, из DCN в CN 3, DCN соответствующую типу архитектуры связи, определенному на этапе 1503, и отправлять S1AP: Исходное сообщение UE, несущее исходное сообщение NAS (т.е., сообщение Запрос Прикрепления) к выбранной DCN.

[0135] Этапы с 1507 по 1512 являются сходными с этапами с 1107 по 1112 на Фиг. 11 или этапами с 1307 по 1312 на Фиг. 13.

[0136] Далее, обращаясь к Фиг. 16, этапы с 1601 по 1606 являются сходными с этапами с 1501 по 1505 на Фиг. 15. Тем не менее, на этапе 1603, RAN 2 выбирает второй тип архитектуры связи для UE 1. Таким образом, исходное сообщение NAS, передаваемое посредством UE 1 на этапе 1605, является сообщением Запрос Услуги. Сообщение Настройка Соединения RRC на этапе 1604 может явным или неявным образом указывать второй тип архитектуры связи, определенный RAN 2 на этапе 1603 (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры).

[0137] Этапы 1606-1614 являются сходными с этапами с 1206 по 1214 на Фиг. 12 или этапами 1406-1414 на Фиг. 14.

[0138] Несмотря на то, что Фиг. 15 и 16 показывают Мобильно Порожденную (MO) передачу данных, процедуры, сходные с теми, что показаны на Фиг. 15 и 16, могут быть применены к Мобильно Завершенной (MT) передаче данных.

[0139] Пример, показанный на Фиг. 15 и 16, позволяет RAN 2 определять тип архитектуры связи, используемый для передачи пакета данных для UE 1, во время процедуры настройки соединения RRC, в которой UE 1 переходит из режима RRC-Idle (или другого режима приостановки) в режим RRC-Connected, чтобы выполнять передачу пакета данных после прикрепления.

[0140] Двенадцатый вариант осуществления

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

[0141] Фиг. 17 является циклограммой, показывающей пример процедуры связи в соответствии с данным вариантом осуществления. В примере, показанном на Фиг. 17, CN 3 включает в себя первую (выделенную) базовую сеть ((D)CN-1 3A), соответствующую первому типу архитектуры связи, и вторую (выделенную) базовую сеть ((D)CN-2 3B), соответствующую второму типу архитектуры связи.

[0142] Этап 1701 является сходным с этапом 504 на Фиг. 5. Т.е., UE 1 передает сообщение Завершена Настройка Соединения RRC во время процедуры настройки соединения RRC для исходного прикрепления. Сообщение Завершена Настройка Соединения RRC на этапе 1701 включает в себя элемент информации, явным или неявным образом указывающий один или более типы архитектуры связи, поддерживаемые UE 1 (например, Поддерживаемый UE Тип Архитектуры). Данный элемент информации является информацией AS (RRC).

[0143] На этапе 1702, сходно с этапом 505 на Фиг. 5, RAN 2 определяет тип архитектуры связи, используемый для UE 1, с учетом одного или более типов архитектуры связи, поддерживаемых UE 1. Кроме того, RAN 2 выбирает, из множества (выделенных) базовых сетей, включенных в CN 3, (выделенную) базовую сеть, соответствующую определенному типу архитектуры связи. Т.е., когда RAN 2 выбирает первый тип архитектуры связи для UE 1, она выбирает CN-1 3A и отправляет S1AP: Исходное сообщение UE к CN-1 3A (этап 1703). Когда RAN 2 выбирает второй тип архитектуры связи для UE 1, она выбирает CN-2 3B и отправляет Исходное сообщение UE к CN-2 3B (этап 1704). Данное Исходное сообщение UE может указывать тип архитектуры связи, выбранный RAN 2 (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры).

[0144] Этапы с 1705 по 1708 являются сходными с этапами с 507 по 510 на Фиг. 5. Сообщение Прикрепление Принято на этапе 1706, сообщение Освобождение Соединения RRC на этапе 1707, или другое сообщение NAS нисходящей линии связи, передаваемое от CN 3 (т.е., CN-1 3A или CN-2 3B) к UE 1 может явным или неявным образом указывать тип архитектуры связи, используемый для UE 1.

[0145] Когда UE 1 выполняет передачу данных после прикрепления в соответствии с процедурой, показанной на Фиг. 17, UE 1 может указывать информацию касательно выделенной CN, в которой UE 1 было зарегистрировано (т.е., информацию касательно MME или C-SGN), используя Элемент Информации (IE) Зарегистрированного MME, включенный в сообщение Завершена Настройка Соединения RRC. RAN 2 может использовать IE Зарегистрированного MME в сообщении Завершена Настройка Соединения RRC, чтобы выбирать тип архитектуры связи, применяемый к UE 1, и выбирать (выделенную) CN. Т.е., когда IE Зарегистрированного MME указывает узел NAS (например, MME/C-SGN) у CN-1 3A, RAN 2 выбирает первый тип архитектуры связи и CN-1 3A для UE 1, тогда как, когда IE Зарегистрированного MME указывает узел NAS (например, MME/C-SGN) у CN-2 3B, RAN 2 выбирает второй тип архитектуры связи и CN-2 3B для UE 1. IE Зарегистрированного C-SGN, IE Зарегистрированной DCN, или Тип Использования UE могут быть использованы в дополнение к или вместо IE Зарегистрированного MME.

[0146] В примере, показанном на Фиг. 17, RAN 2 определяет тип архитектуры связи, используемый для UE 1, и выбирает (выделенную) базовую сеть, в которую должно быть передано Исходное сообщение UE. Таким образом это позволяет RAN 2 выбирать надлежащую (выделенную) базовую сеть в соответствии с динамическим определением в RAN 2 типа архитектуры связи, используемого для UE 1.

[0147] Тринадцатый вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. Тем не менее, CN 3 включает в себя множество (выделенных) базовых сетей. RAN 2 выполнена с возможностью определения типа архитектуры связи, используемого для передачи пакета данных для UE 1. CN 3 выполнена с возможностью выполнения перенаправления (или перенацеливания) Исходного сообщения UE так, что Исходное сообщение UE передается в надлежащую (выделенную) базовую сеть, соответствующую типу архитектуры связи, определенному RAN 2.

[0148] Фиг. 18 является циклограммой, показывающей пример процедуры связи в соответствии с данным вариантом осуществления. В примере, показанном на Фиг. 18, CN 3 включает в себя первую (выделенную) базовую сеть ((D)CN-1 3A), соответствующую первому типу архитектуры связи, и вторую (выделенную) базовую сеть ((D)CN-2 3B), соответствующую второму типу архитектуры связи.

[0149] Этапы 1801 и 1805 являются сходными с этапами 504 и 505 на Фиг. 5. RAN 2 принимает сообщение Завершена Настройка Соединения RRC, включающее в себя исходное сообщение NAS, от UE 1. RAN 2 затем передает тип архитектуры связи, используемый для UE 1, с учетом одного или более типов архитектуры связи, поддерживаемых UE 1.

[0150] На этапе 1803, RAN 2 отправляет S1AP: Исходное сообщение UE предварительно назначенной или произвольно выбранной (выделенной) базовой сети. Данное Исходное сообщение UE включает в себя элемент информации, явным или неявным образом указывающий тип архитектуры связи, используемый для UE 1 (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры). В примере, показанном на Фиг. 18, RAN 2 отправляет Исходное сообщение UE (выделенной) базовой сети CN-2 3B. Предварительно назначенной (выделенной) базовой сетью может быть, например, базовая сеть, которая поддерживает тип архитектуры связи по умолчанию.

[0151] На этапе 1804, узел NAS (например, MME/C-SGN), расположенный в CN 3 (т.е., CN-2 3B в данном примере), принимает Исходное сообщение UE от RAN 2 и обращается к элементу информации, указывающему тип архитектуры связи (например, применяемый Тип Архитектуры или Выбранный Тип Архитектуры), включенному в принятое Исходное сообщение UE. Когда тип архитектуры связи, используемый для UE 1, ассоциирован с CN-2 3B, узел NAS, расположенный в CN-2 3B, продолжает процесс прикрепления на основе сообщения Запрос Прикрепления, включенного в Исходное сообщение UE. С другой стороны, когда тип архитектуры связи, используемый для UE 1, ассоциирован с другой (выделенной) базовой сетью (т.е., CN-1 3A в данном примере), узел NAS, расположенный в CN-2 3B, запрашивает у RAN 2 перенаправление Исходного сообщения UE в CN-1 3A. В частности, как показано на Фиг. 18, CN-2 3B отправляет сообщение S1AP: Запрос Перенаправления Сообщения NAS к RAN 2. Данное сообщение Запрос Перенаправления Сообщения NAS включает в себя идентификатор (выделенной) базовой сети, в которую Исходное сообщение UE должно быть отправлено (например, ID Группы MME, ID Группы C-SGN, ID Группы DCN, и Дополнительный Глобальный Уникальный Временный Идентификатор (GUTI)).

[0152] На этапе 1804, чтобы определить перенаправление Исходного сообщения UE, CN 3 может дополнительно рассматривать данные подписки у UE 1, извлеченные из HSS 5 (например, Возможности UE или Тип Использования UE (например, C-IoT, общая MTC, или устойчивая к задержке MTC)).

[0153] На этапе 1805, по приему сообщения S1AP: Запрос Перенаправления Сообщения NAS, RAN 2 перенаправляет Исходное сообщение UE в базовую сеть (CN-1 3A в данном примере), назначенную в сообщении Запрос Перенаправления Сообщения NAS.

[0154] Этапы с 1806 по 1809 являются сходными с этапами с 1705 по 1708 на Фиг. 17. Сообщение Прикрепление Принято на этапе 1807, сообщение Освобождение Соединения RRC на этапе 1808, или другое сообщение NAS нисходящей линии связи, переданное от CN 3 (т.е., CN-1 3A или CN-2 3B) к UE 1, может явным или неявным образом указывать тип архитектуры связи, используемый для UE 1.

[0155] Когда UE 1 выполняет передачу данных после прикрепления в соответствии с процедурой, показанной на Фиг. 18, UE 1 может указывать информацию касательно выделенной CN, в которой UE 1 было зарегистрировано (т.е., информацию касательно MME или C-SGN), используя Элемент Информации (IE) Зарегистрированного MME, включенный в сообщение Завершена Настройка Соединения RRC. RAN 2 может использовать IE Зарегистрированного MME в сообщении Завершена Настройка Соединения RRC, чтобы выбирать тип архитектуры связи, применяемый к UE 1, и выбирать (выделенную) CN. Т.е., когда IE Зарегистрированного MME указывает узел NAS (например, MME/C-SGN) у CN-1 3A, RAN 2 выбирает первый тип архитектуры связи и CN-1 3A для UE 1, тогда как, когда IE Зарегистрированного MME указывает узел NAS (например, MME/C-SGN) у CN-2 3B, RAN 2 выбирает второй тип архитектуры связи и CN-2 3B для UE 1.

[0156] В примере, показанном на Фиг. 18, CN 3 распознает тип архитектуры связи, определенный RAN 2, и перенаправляет Исходное сообщение UE в соответствии с типом архитектуры связи, определенным RAN 2. Это, таким образом, позволяет CN 3 обрабатывает Исходное сообщение UE в надлежащей (выделенной) базовой сети в соответствии с динамическим определением в RAN 2 типа архитектуры связи, используемого для UE 1.

[0157] Четырнадцатый вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. Тем не менее, CN 3 включает в себя множество (выделенных) базовых сетей. CN 3 выполнена с возможностью определения типа архитектуры связи, используемого для передачи пакета данных для UE 1, и выполнения перенаправления (перенацеливания) Исходного сообщения UE так, что Исходное сообщение UE передается надлежащей (выделенной) базовой сети, соответствующей типу архитектуры связи, определенному посредством CN 3.

[0158] Фиг. 19 является циклограммой, показывающей пример процедуры связи в соответствии с данным вариантом осуществления. В примере, показанном на Фиг. 19, CN 3 включает в себя первую (выделенную) базовую сеть ((D)CN-1 3A), соответствующую первому типу архитектуры связи, и вторую (выделенную) базовую сеть ((D)CN-2 3B), соответствующую второму типу архитектуры связи. Процедура, показанная на Фиг. 19 отличается от той, что показана на Фиг. 18 тем, что CN 3 определяет тип архитектуры связи, используемой для UE 1.

[0159] Этапы 1901 и 1902 являются сходными с этапом 904 на Фиг. 9. Т.е., на этапе 1901, UE 1 передает RAN 2 сообщение Завершена Настройка Соединения RRC, несущее информацию Выделенного NAS, включающую в себя исходное сообщение NAS (т.е., сообщение Запрос Прикрепления) и один или более типы архитектуры связи, поддерживаемые UE 1 (например, Поддерживаемый UE Тип Архитектуры). На этапе 1902, RAN 2 извлекает выделенную информацию NAS из сообщения Завершена Настройка Соединения RRC. RAN 2 затем отправляет S1AP: Исходное сообщение UE, несущее NAS-PDU, включающую в себя извлеченную выделенную информацию NAS предварительно назначенной или произвольно выбранной (выделенной) базовой сети. В примере, показанном на Фиг. 19, RAN 2 отправляет Исходное сообщение UE (выделенной) базовой сети CN-2 3B.

[0160] Этап 1903 является сходным с этапом 905 на Фиг. 9. Т.е., узел NAS (например, MME/C-SGN), расположенный в CN 3 (т.е., CN-2 3B в данном примере, определяет тип архитектуры связи, используемый для UE 1, с учетом одного или более типов архитектуры связи, поддерживаемых UE 1 (например, Поддерживаемый UE Тип Архитектуры). Чтобы определять тип архитектуры связи, узел NAS, расположенный в CN-2 3B, может дополнительно рассматривать данные подписки у UE 1, извлеченные из HSS 5 (например, Возможности UE или Тип Использования UE).

[0161] Этапы с 1904 по 1909 являются сходными с этапами с 1804 по 1809 на Фиг. 18. Тем не менее, сообщение S1AP: Запрос Перенаправления Сообщения NAS на этапе 1904 может включать в себя элемент информации, явным или неявным образом указывающий тип архитектуры связи, используемый для UE 1, определенный посредством CN-2 3B (например, Применяемый Тип Архитектуры или Выбранный Тип Архитектуры). Таким образом, RAN 2 может распознать тип архитектуры связи, используемый для UE 1.

[0162] В примере, показанном на Фиг. 19, CN 3 определяет тип архитектуры связи для UE 1 и перенаправляет Исходное сообщение UE в соответствии с определенным типом архитектуры связи. Это, таким образом, позволяет CN 3 обрабатывать Исходное сообщение UE в надлежащей (выделенной) базовой сети в соответствии с динамическим определением в CN 3 типа архитектуры связи, используемого для UE 1.

[0163] Пятнадцатый вариант осуществления

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

[0164] Например, UE 1 может передавать элемент информации (например, вспомогательный IE UE), указывающий тип архитектуры связи, используя заголовок RLC, заголовок MAC, или Элемент Управления MAC (MAC CE) на слое ниже, чем RRC (т.е., RLC или MAC). Дополнительно или в качестве альтернативы, UE 1 может передавать информацию, указывающую опускание процесса PDCP (например, процесс обеспечения безопасности AS) RAN 2, используя заголовок RLC, заголовок MAC, или MAC CE. В частности, когда первый тип архитектуры связи включает опускание процесса PDCP, UE 1 может передавать, по меньшей мере, одно из следующего: элемент информации, указывающий первый тип архитектуры связи, и элемент информации, указывающий опускание процесса PDCP, используя MAC CE.

[0165] Например, когда UE 1 определяет (выбирает) первый тип архитектуры связи на этапе 401 на Фиг. 4, UE 1 может опускать процесс PDCP для SRB 1, чтобы передавать сообщение Завершена Настройка Соединения RRC (этап 405). Соответственно, UE 1 передает, по меньшей мере, один элемент информации, указывающий первый тип архитектуры связи, и элемент информации, указывающий опускание процесса PDCP, используя MAC CE. Посредством использования MAC CE, RAN 2 может распознать, в ее процессе MAC перед ее процессом PDCP, что процесс PDCP в UE 1 был опущен дал сообщения, принятого от UE 1 (включая Завершена Настройка Соединения RRC).

[0166] Шестнадцатый вариант осуществления

Несмотря на то, что описанные выше варианты осуществления предоставляют примеры, в которых процедура произвольного доступа, включающая передачу преамбулы произвольного доступа, выполняется, когда UE 1 переходит из режима RRC-Idle (или другого режима приостановки) в режим RRC-Connected, настоящее раскрытие не ограничивается такими примерами. Другие процедуры произвольного доступа могут быть реализованы в UE 1 и RAN 2. В некоторых реализациях, UE 1 может передавать небольшое (или короткое) сообщение, вместо преамбулы произвольного доступа (т.е., преамбула RACH), по RACH. В данном случае, сообщение, передаваемое по RACH, может указывать тип архитектуры связи, который определен (или выбран) или поддерживается посредством UE 1. Это позволяет UE 1 информировать RAN 2 о типе архитектуры связи, определенном (или выбранном) или поддерживаемом посредством UE 1, до создания соединения RRC. Таким образом, например, RAN 2 может генерировать сообщение ответа RA с учетом типа архитектуры связи, принятого от UE 1. Сообщение ответа RA может включать в себя индикатор отсрочки, определенный на основе типа архитектуры связи, принятого от UE 1.

[0167] Семнадцатый вариант осуществления

Ресурсы RACH, которые используются UE 1, когда UE 1 переходит из режима RRC-Idle (или другого режима приостановки) в режим RRC-Connected, могут быть распределены соответственно множеству типов архитектуры связи. В данном случае, UE 1 может использовать конкретный ресурс RACH для первой передачи RACH, содержащей преамбулу или небольшое (короткое) сообщение, чтобы неявным образом указывать тип архитектуры связи, определенный или (выбранный) или поддерживаемый посредством UE 1. Это позволяет UE 1 информировать RAN 2 о типе архитектуры связи определенном (или выбранном) или поддерживаемом посредством UE 1, до создания соединения RRC. Таким образом, например. RAN 2 может генерировать сообщение ответа RA с учетом типа архитектуры связи, принятого от UE 1. Сообщение ответа RA может включать в себя индикатор отсрочки, определенный на основе типа архитектуры связи, принятого от UE 1.

[0168] Восемнадцатый вариант осуществления

Описанные выше варианты осуществления могут быть применены к любой из или как к связи NB-IoT, так и связи LTE eMTC. Кроме того, описанные выше варианты осуществления могут быть применены к связи LTE, связи Усовершенствованного-LTE, и другой связи UE в соответствии с модифицированными версиями этих стандартов.

[0169] Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. Отметим, что UE 1 в соответствии с данным вариантом осуществления может быть устройством CIoT (например, NB-IoT или LTE eMTC), или может быть UE в соответствии с LTE, Усовершенствованным-LTE, или модифицированными версиями этих стандартов. Данный вариант осуществления предоставляет примеры мобильности в случае, где один из описанных выше типов архитектуры связи применяется к UE 1.

[0170] Мобильность UE 1 включает в себя смену соты в режиме бездействия (например, RRC-Idle или другом режиме приостановки) (т.е., мобильность режима-бездействия) и смену соты в соединенном режиме (например, RRC-Connected) (т.е., мобильность соединенного-режима). Мобильность режима-бездействия включает в себя процедуру повторного выбора соты в режиме бездействия. Мобильность соединенного-режима включает в себя процедуры обратной и прямой передачи обслуживания в соединенном режиме (например, освобождение RRC с перенацеливанием).

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

[0172] В некоторых реализациях, RAN 2 может отключать функции для мобильности в режиме RRC-Connected (например, передачу обслуживания и перенацеливание) для UE 1, к которому применяется первый (или второй) тип архитектуры связи. Другими словами, UE 1 может деактивировать функции (например, отчет об измерении, передача обслуживания, и перенацеливание) для мобильности в режиме RRC-Connected. Дополнительно или в качестве альтернативы, RAN 2 может отключать функции для мобильности в режиме RRC-Idle (например, повторной выбор соты) для UE, к которой применяется второй (или первый) тип архитектуры связи. Другими словами, UE 1 может деактивировать функции (например, повторный выбор соты и измерение) для мобильности в режиме RRC-Idle.

[0173] В некоторых реализациях, функции для мобильности в режиме RRC-Idle и режиме RRC-Connected могут быть активированы для UE 1, к которому применяется первый (или второй) тип архитектуры связи. В данном случае, UE 1 может работать следующим образом, чтобы осуществлять смену соты в режиме RRC-Idle или RRC-Connected.

[0174] Например, по выполнению повторного выбора соты, UE 1 может освобождать (или отбрасывать) информацию касательно типа архитектуры связи, который был сконфигурирован в (или применялся к) UE 1 в соте до повторного выбора соты.

[0175] Например, во время процедуры передачи обслуживания в режиме RRC-Connected (т.е., обратная передача обслуживания), UE 1 может освобождать (или отбрасывать) информацию касательно типа архитектуры связи, который был сконфигурирован в (или применялся к) UE 1 в ответ на прием инструкции передачи обслуживания от исходного узла (узла-источника) RAN (например, исходного eNB или исходной CIoT BS), расположенного в RAN 2. Инструкция передачи обслуживания может быть, например, сообщением Реконфигурация Соединения RRC, включающим в себя mobilityControlInfo IE.

[0176] Например, во время освобождения RRC с помощью процедуры перенацеливания в режиме RRC-Connected, UE 1 может освобождать (или отбрасывать) информацию касательно типа архитектуры связи, который был сконфигурирован в (или применялся к) UE 1 в ответ на прием, от исходного узла RAN (например, исходного eNB или исходной CIoT), расположенного в RAN 2, сообщения Освобождение Соединения RRC для запроса перенацеливания, UE 1 может освобождать (или отбрасывать) информацию касательно типа архитектуры связи, который был сконфигурирован в (или применялся к) UE 1 в соте до повторного выбора соты. В данном случае, причина освобождения, используемая в сообщении Освобождение Соединения RRC, может быть установлена в «другое». В качестве альтернативы, новая причина (например, redirectionForCIoT, redirectionForCellUpdate, redirectionRequired, или cellUpdateRequired) может быть определена и использована для причины освобождения.

[0177] После смены соты у UE 1, UE 1, RAN 2, и CN 3 могут определять (или выбирать) тип архитектуры связи, который должен быть использован для UE 1, в соответствии с любым из способов, описанных в описанных выше вариантах осуществления. В качестве альтернативы, после смены соты, UE 1 может выполнять передачу данных в соответствии с существующим образом в LTE и Усовершенствованном-LTE (т.е., UE 1 может возвращаться к унаследованному/обычному механизму).

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

[0179] Девятнадцатый вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. UE 1 в соответствии с данным вариантом осуществления может быть устройством CIoT (например, NB-IoT или LTE eMTC), или может быть UE в соответствии с LTE, Усовершенствованным-LTE, или модифицированными версиями этих стандартов. Данный вариант осуществления предоставляет примеры мобильности режима-бездействия в случае, где один из описанных выше типов архитектуры связи применяется к UE 1.

[0180] UE 1 в соответствии с данным вариантом осуществления передает к RAN 2 или CN 3, после выполнения повторного выбора соты, элемент информации, явным или неявным образом указывающий тип архитектуры связи, который был сконфигурирован в (или применен к) UE 1 до повторного выбора соты. В частности, UE 1 может передавать элемент информации, когда UE 1 переходит в режим RRC-Connected первый раз после повторного выбора соты.

[0181] Фиг. 20 и 21 являются циклограммами, показывающими примеры процедур связи в соответствии с данным вариантом осуществления. Фиг. 20 показывает случай, где первый тип архитектуры связи используется для UE 1. Между тем, Фиг. 21 показывает случай, где второй тип архитектуры связи используется для UE 1. В примерах, показанных на Фиг. 20 и 21, RAN 2 включает в себя RAN-1 2A и RAN-2 2B. RAN-1 2A соответствует узлу RAN (например, CIoT BS или eNB) до смены соты (повторного выбора соты) и RAN-2 2B соответствует узлу RAN после смены соты.

[0182] Обращаясь к Фиг. 20, на этапе 2001, тип архитектуры связи, используемый для UE 1, определяется в соответствии с любой из процедур, описанных в с первого по семнадцатый вариантах осуществления и UE 1 конфигурируется с помощью определенного типа архитектуры связи. В примере, показанном на Фиг. 20, UE 1 использует первый тип архитектуры связи. На этапе 2002, RAN-1 2A передает сообщение Освобождение Соединения RRC к UE 1 по SRB 1. На этапе 2003, UE 1 записывает (сохраняет) тип архитектуры связи с помощью которого UE 1 было сконфигурировано и переходит в режим RRC-Idle (или другой режим приостановки). В примере, показанном на Фиг. 20, UE 1 использует первый тип архитектуры связи.

[0183] UE 1 измеряет обслуживающую соту и соседнюю соту(ы) в режиме RRC-Idle (или другом режиме приостановки). На этапе 2004, UE 1 выполняет повторный выбор соты. На этапе 2005 и 2006, UE 1 и RAN-2 2B выполняют процедуру создания соединения RRC так, что UE 1 переходит в режим RRC-Connected первый раз после повторного выбора соты. Во время данной процедуры, UE 1 передает элемент информации (например, информацию Сконфигурированного типа-архитектуры), явным или неявным образом указывающий тип архитектуры связи, который был сконфигурирован в (или применен к) UE 1 до повторного выбора соты, к RAN-2 2B. Данный элемент информации может быть передан посредством, например, сообщения Запрос Соединения RRC или сообщения Завершена Настройка Соединения RRC. В примере, показанном на Фиг. 20, элемент информации указывает первый тип архитектуры связи. Это позволяет RAN-2 2B распознавать тип архитектуры связи, который был сконфигурирован в (или применен к) UE 1 до повторного выбора соты и, следовательно, RAN-2 может выполнить операции соответствующие типу архитектуры связи, с помощью которого было сконфигурировано UE 1.

[0184] На этапе 2007, UE 1 выполняет любую передачу или как передачу данных UL, так и прием данных DL, используя сообщение NAS. Сходно с девятым и десятым вариантами осуществления, UE 1 может передавать сообщение NAS, содержащее данные UL по SRB 1, используя сообщение Завершена Настройка RRC или сообщения RRC: Перенос Информации UL. UE 1 может принимать сообщение NAS, содержащее данные DL по SRB 1, используя сообщение RRC: Перенос Информации DL.

[0185] Процедура, показанная на Фиг. 20, может быть модифицирована следующим образом. Например, RAN-2 2B может осуществлять связь с CN 3, чтобы аутентифицировать и одобрять UE 1.

[0186] UE 1 может использовать сообщение NAS, чтобы передавать CN 3 элемент информации (например, информацию Сконфигурированного типа-архитектуры), явным или неявным образом указывающий тип архитектуры связи, который был сконфигурирован в (или применен к) UE 1 до повторного выбора соты. В данном случае, CN 3 может отправлять, к RAN-2 2B, элемент информации, указывающий тип архитектуры связи, который был сконфигурирован в (или применен к) UE 1.

[0187] Вместо передачи элемента информации, указывающего тип архитектуры связи, сконфигурированный в (или примененный к) UE 1, UE 1 может передавать, RAN-2 2B, элемент информации, указывающий возобновление уже сконфигурированного типа архитектуры связи и элемент информации, указывающий соту или узел RAN до повторного выбора соты (например, ID Физической Соты (PCI), частоту Несущей (EARFCN), или Глобальный ID Соты E-UTRAN (ECGI)). В данном случае, RAN-2 2B может спрашивать у узла RAN, который осуществляет администрирование соты до повторного выбора соты о типе архитектуры связи, который был сконфигурирован в (или применялся к) UE 1.

[0188] UE 1 может передавать к CN 3 элемент информации, указывающий возобновление уже сконфигурированного типа архитектуры связи. В данном случае, CN 3 может отправлять, к RAN-2 2B, элемент информации, указывающий тип архитектуры связи, который был сконфигурирован в (или применялся к) UE 1.

[0189] Далее, обращаясь к Фиг. 21, на этапе 2101, тип архитектуры связи, используемый для UE 1, определяется в соответствии с любой из процедур, описанных в с первого по семнадцатый вариантах осуществления и UE 1 конфигурируется с помощью определенного типа архитектуры связи. В примере, показанном на Фиг. 21, UE 1 использует второй тип архитектуры связи. На этапе 2102, RAN-1 2A передает сообщение RRC (например, сообщение Приостановка Соединения RRC), чтобы приостановить соединение RRC с UE 1. По приему сообщения RRC, UE 1 переходит из режима RRC-Connected в режим RRC-Idle (или другой режим приостановки) и удерживает информацию касательно соединения RRC, в то время, пока оно находится в режиме RRC-Idle (или другом режиме приостановки) (этап 2103). Сходным образом, RAN-1 2A и CN 3 удерживают контекст, который относится к UE 1, необходимый для приостановки соединения RRC (этап 2103). UE 1 и RAN-1 2A дополнительно сохраняют тип архитектуры связи, с помощью которого UE 1 было сконфигурировано (т.е., второй тип архитектуры связи в данном примере) (этап 2104).

[0190] Этапы 2105 и 2106 являются сходными с этапами 2004 и 2005 на Фиг. 20. Тем не менее, в сообщении RRC, передаваемом на этапе 2106, элемент информации (например, информация Сконфигурированного типа-архитектуры), который явным или неявным образом указывает тип архитектуры связи, который был сконфигурирован в (или применялся к) UE 1, указывает второй тип архитектуры связи. Кроме того, сообщение RRC, передаваемое на этапе 2106, включает в себя элемент информации (например, PCI или ECGI), указывающий соту или узел RAN до повторного выбора соты.

[0191] На этапе 2107, по приему сообщения RRC на этапе 2106, RAN-2 2B запрашивает контекст UE у RAN-1 2A до повторного выбора соты. На этапе 2098, RAN-1 2A отправляет контекст UE, удерживаемый в RAN-1 2A, к RAN-2 2B. На этапе 2109, RAN-2 2B осуществляет связь с CN 3, чтобы возобновить приостановленное соединение RRC. В частности, RAN-2 2B может отправлять сообщение S1-AP: Активный Контекст UE к CN 3 и принимать сообщение S1-AP: Ack Активный Контекст UE от CN 3. Сообщение S1-AP: Активный Контекст UE инициирует процедуру для модифицирования носителя S1 в CN 3. Данная процедура включает в себя, например, передачу сообщения Запрос Модифицирования Носителя от MME (или C-SSN) к S-GW и передачу сообщения Ответ Модифицирования Носителя от S-GW к MME (или C-SSN).

[0192] На этапе 2110, RAN-2 2B передает сообщение RRC, указывающее завершение возобновления соединения RRC (например, сообщение Завершено Возобновление Соединения RRC) к UE 1. Данное сообщение RRC включает в себя информацию обеспечения безопасности AS. На этапе 2111, UE 1 и RAN-2 2B создают обеспечение безопасности AS. На этапе 2112, UE 1 передает данные UL через RAN-2 2B по носителю UL и принимает данные DL через RAN-2 2B по носителю DL.

[0193] Как описано выше, в данном варианте осуществления, после выполнения повторного выбора соты, UE 1 передает RAN-2 2B или CN 3 элемент информации (например, информацию Сконфигурированного типа-архитектуры), явным или неявным образом указывающий тип архитектуры связи, который был сконфигурирован в (или применялся к) UE 1 до повторного выбора соты. Таким образом можно предотвратить несовместимость (или несоответствие) между конфигурацией типа архитектуры связи в UE 1 и той, что в сети после смены соты.

[0194] Двадцатый вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. UE 1 в соответствии с данным вариантом осуществления может быть устройством CIoT (например, NB IoT или LTE eMTC), или может быть UE в соответствии с LTE, Усовершенствованным-LTE, или модифицированными версиями этих стандартов. Данный вариант осуществления предоставляет примеры мобильности соединенного-режима в случае, где один из описанных выше типов архитектуры связи применяется к UE 1.

[0195] В данном варианте осуществления, при выполнении передачи обслуживания UE 1, исходный узел RAN (например, CIoT BS или eNB) передает Запрос Передачи Обслуживания, включающий в себя элемент информации, явным или неявным образом указывающий тип архитектуры связи, который был сконфигурирован в UE 1 (т.е., использовался для UE 1) целевому узлу (узлу-адресату) RAN (например, CIoT BS или eNB).

[0196] Фиг. 22 и 23 являются циклограммами, показывающими примеры процедур связи в соответствии с данным вариантом осуществления. Фиг. 22 показывает случай, где первый тип архитектуры связи используется для UE 1. Между тем, Фиг. 23 показывает случай, где второй тип архитектуры связи используется для UE 1. В примерах, показанных на Фиг. 22 и 23, RAN 2 включает в себя RAN-1 2A и RAN-2 2B. RAN-1 2A соответствует исходному узлу RAN (например, CIoT BS или eNB), а RAN-2 2B соответствует целевому узлу RAN.

[0197] Обращаясь к Фиг. 22, на этапе 2201, тип архитектуры связи, используемый для UE 1, определяется в соответствии с любой из процедур, описанных в с первого по семнадцатый вариантах осуществления, и UE 1 конфигурируется с помощью определенного типа архитектуры связи. В примере, показанном на Фиг. 22, UE 1 использует первый тип архитектуры связи. На этапе 2202, UE 1 находится в режиме RRC-Connected. Соответственно, на этапе 2202, UE 1 может выполнять любую из или как передачу данных UL, так и прием данных DL, используя сообщение NAS.

[0198] На этапе 2203, UE 1 передает отчет измерения, указывающий результат измерения обслуживающей соты и соседней сот(ы) исходной RAN-1 2A. На этапе 2004, исходный RAN-1 2A определяет передачу обслуживания UE 1 в целевую RAN-2 2B. На этапе 2005, исходная RAN-1 2A отправляет запрос передачи обслуживания к целевой RAN-2 2B. Данный запрос передачи обслуживания включает в себя элемент информации (например, информацию типа-архитектуры), указывающий тип архитектуры связи, используемый для UE 1 в исходной RAN-1 2A (т.е., первый тип архитектуры связи в данном примере).

[0199] На этапе 2206, по приему запроса передачи обслуживания, целевая RAN-2 2B отправляет сообщение ответа на запрос передачи обслуживания (например, сообщение Квитанция Запроса Передачи Обслуживания) к исходной RAN-1 2A. В некоторых реализациях, данное сообщение ответа указывает, поддерживает ли целевая RAN-2 2B тип архитектуры связи, о котором она была уведомлена исходной RAN-1 2A. В качестве альтернативы, сообщение ответа явным или неявным образом указывает (измененный) тип архитектуры связи, который должен быть использован для UE 1 в целевой RAN-2 2B.

[0200] На этапе 2207, исходная RAN-1 2A передает UE 1 инструкцию передачи обслуживания, включающую в себя элемент информации (например, информацию типа-архитектуры), указывающий, что текущий тип архитектуры связи непрерывно используется после передачи обслуживания, или указывающий (измененный) тип архитектуры связи, который должен быть применен к UE 1 после передачи обслуживания. Инструкция передачи обслуживания может быть, например, сообщением Реконфигурация Соединения RRC, включающим в себя IE MobilityControlInfo. В примере, показанном на Фиг. 22, первый тип архитектуры связи используется для UE 1 также в целевой RAN-2 2B.

[0201] На этапе 2208, UE 1 выполняет процедуру произвольного доступа для того, чтобы синхронизировать целевую соту (т.е., целевую RAN-2 2B). На этапе 2209, UE 1 передает сообщение Завершена Реконфигурация Соединения RRC, включающее в себя подтверждение передачи обслуживания (например, Передача Обслуживания Подтверждена) к целевой RAN-2 2B. На этапе 2210, UE 1 выполняет любую из или как передачу UL, так и передачу DL в соответствии с типом архитектуры связи, указанным от исходной RAN-1 2A на этапе 2207. В примере, показанном на Фиг. 22, первый тип архитектуры связи используется для UE 1 также в целевой RAN-2 2B. Соответственно, на этапе 2210, UE 1 может выполнять любую из или как передачу данных UL, так и прием данных DL, используя сообщение NAS.

[0202] Процедура, показанная на Фиг. 22 может быть модифицирована следующим образом. На этапе 2205, запрос передачи обслуживания может указывать, что UE 1 было авторизовано на использование первого типа архитектуры связи.

[0203] Далее, обращаясь к Фиг. 23, на этапе 2301, тип архитектуры связи, используемый для UE 1, определяется в соответствии с любой из процедур, описанных в с первого по семнадцатый вариантах осуществления, и UE 1 конфигурируется с помощью определенного типа архитектуры связи. В примере, показанном на Фиг. 23, UE 1 использует второй тип архитектуры связи. На этапе 2302, выполняется процедура создания носителя для UE 1. На этапе 2302, UE 1 передает данные UL через RAN-1 2A по носителю UL и принимает данные DL через RAN-1 2A по носителю DL.

[0204] Этапы с 2304 по 2310 являются сходными с этапами 2203-2209 на Фиг. 22. Тем не менее, в примере, показанном на Фиг. 23, целевая RAN-2 2B использует второй тип архитектуры связи для UE 1. На этапе 2311, целевая RAN-2 2B осуществляет связь с CN 3, чтобы поменять маршрут носителя(ей) S1 для UE 1, как в случае обычной процедуры передачи обслуживания. Например, целевая RAN-2 2B отправляет сообщение S1AP: Запрос Переключения Пути к CN 3 и принимает сообщение S1AP: Ack Запроса Переключения Пути от CN 3.

[0205] На этапе 2312, UE 1 передает данные UL через целевую RAN-2 2B по носителю UL и принимает данные DL через целевую RAN-2 2B по носителю DL.

[0206] На этапе 2313, UE 1, целевая RAN-2 2B, и CN 3 приостанавливают соединение RRC.

[0207] Процедуры на Фиг. 22 и 23 могут быть объединены при необходимости. Т.е., как уже описывалось, целевая RAN-2 2B может применять к UE 1 тип архитектуры связи отличный от того, что применялся к UE 1 в исходной RAN-1 2A. Соответственно, на Фиг. 22, когда сообщение ответа передачи обслуживания (этап 2206) указывает, что второй тип архитектуры связи должен быть использован для UE 1 в целевой RAN-2 2B, этапы с 2311 по 2313, показанные на Фиг. 23, могут быть выполнены вместо выполнения этапа 2210. Тоже самое справедливо для обратного случая.

[0208] Как описано выше, в данном варианте осуществления, исходная RAN-1 2A передает, целевой RAN-2 2B, Запрос Передачи Обслуживания, включающий в себя элемент информации, указывающий тип архитектуры связи, который был сконфигурирован в UE 1 (т.е., использовался для UE 1). Таким образом можно предотвратить несовместимость (или несоответствие) между конфигурацией типа архитектуры связи в UE 1 и той, что в целевой RAN-2 2B.

[0209] Кроме того, в данном варианте осуществления, целевая RAN-2 2B отправляет исходной RAN-1 2A сообщение ответа передачи обслуживания, включающее в себя элемент информации, указывающий, поддерживает ли целевая RAN-2 2B тип архитектуры связи, о котором она была уведомлена исходной RAN-1 2A, или указывающий (измененный) тип архитектуры связи, который должен быть использован для UE 1 в целевой RAN-2 2B. Кроме того, исходная RAN-1 2A передает UE 1 инструкцию передачи обслуживания, включающую элемент информации, указывающий тип архитектуры связи, который должен быть использован для UE 1 в целевой RAN-2 2B. Это позволяет целевой RAN-2 2B использовать, для UE 1, тип архитектуры связи отличный от того, что использовался в исходной RAN-1 2A.

[0210] Двадцать первый вариант осуществления

Пример конфигурации сети радиосвязи в соответствии с данным вариантом осуществления является сходным с тем, что показан на Фиг. 2. UE 1 в соответствии с данным вариантом осуществления может быть устройством CIoT (например, NB-IoT или LTE eMTC), или может быть UE в соответствии с LTE, Усовершенствованным-LTE, или модифицированными версиями этих стандартов. Данный вариант осуществления предоставляет примеры мобильности соединенного-режима в случае, где один из описанных выше типов архитектуры связи применяется к UE 1.

[0211] В данном варианте осуществления, во время процедуры прямой передачи обслуживания в соединенном режиме, UE 1 передает целевой RAN-2 2B элемент информации, явным или неявным образом указывающий тип архитектуры связи, который был сконфигурирован в (или применялся к) UE 1 в исходной RAN-1 2A. В частности, UE 1 может передавать данный элемент информации, используя сообщение Повторное Создание Соединения RRC к целевой RAN-2 2B. Процедура прямой передачи обслуживания может запускаться, когда RAN-1 2A передает сообщение «освобождение RRC с перенацеливанием» к UE 1. В качестве альтернативы, процедура прямой передачи обслуживания может добровольно запускаться UE 1 в ответ на истечение таймера Сбоя Линии Радиосвязи (RLF).

[0212] Фиг. 24, 25A и 25B являются циклограммами, показывающими примеры процедур связи в соответствии с данным вариантом осуществления. Фиг. 24 показывает случай, где первый тип архитектуры связи используется для UE 1. Между тем, Фиг. 25A и 25B показывают случай, где второй тип архитектуры связи используется для UE 1. В примерах, показанных на Фиг. 24, 25A и 25B, RAN 2 включает в себя RAN-1 2A и RAN-2 2B. RAN-1 2A соответствует исходному узлу RAN (например, CIoT BS или eNB), а RAN-2 2B соответствует целевому узлу RAN.

[0213] Обращаясь к Фиг. 24, этапы с 2401 по 2403 являются сходными с этапами с 2201 по 2203 на Фиг. 22. На этапе 2404, исходная RAN-1 2A передает UE 1 сообщение освобождения RRC, указывающее перенацеливание на целевую RAN-2 2B. По приему сообщения освобождения RRC, UE 1 выполняет повторный выбор соты (этап 2405). Отметим, что этап 2404 не обязательно должен быть выполнен. В частности, UE 1 может добровольно выполнять (повторный) выбор соты (этап 2405) в ответ на истечение таймера RLF.

[0214] На этапе 2406, UE 1 передает сообщение запроса повторного создания соединения RRC целевой RAN-2 2B. Данное сообщение запроса повторного создания соединения RRC включает в себя элемент информации касательно типа архитектуры связи (например, информация Сконфигурированного типа-архитектуры), который явным или неявным образом указывает тип архитектуры связи, который был сконфигурирован в (или применялся к) UE 1 в исходной RAN-1 2A.

[0215] На этапе 2407, целевая RAN-2 2B передает сообщение Повторное Создание Соединения RRC к UE 1. Данное сообщение может включать в себя элемент информации касательно типа архитектуры связи (например, информацию типа-архитектуры), который указывает, что текущий тип архитектуры связи непрерывно используется, или указывает явным или неявным образом (измененный) тип архитектуры связи, применяемый к UE 1 в целевой RAN-2 2B.

[0216] В примере, показанном на Фиг. 24, целевая RAN-2 2B использует первый тип архитектуры связи для UE 1. Таким образом, этап 2408 является сходным с этапом 2210 на Фиг. 22.

[0217] Далее, обращаясь к Фиг. 25A и 25B, этапы с 2501 по 2504 являются сходными с этапами с 2301 по 2304 на Фиг. 23.

[0218] Этапы с 2505 по 2508 являются сходными с этапами с 2404 по 2407 на Фиг. 24. В примере, показанном на Фиг. 25A и 25B, целевая RAN-2 2B использует второй тип архитектуры связи для UE 1. Таким образом, этапы с 2509 по 2514 являются сходными с этапами с 2107 по 2112 на Фиг. 21.

[0219] Этап 2515 является сходным с этапом 2313 на Фиг. 23.

[0220] Процедура, показанная на Фиг. 25A и 25B может быть модифицирована следующим образом. Сообщение освобождения соединения RRC на этапе 2505 может указывать ID Возобновления. ID Возобновления является идентификатором, который RAN 2 назначает UE 1 для приостановки RRC. RAN 2 использует ID Возобновления, чтобы ассоциировать UE 1 с ранее сохраненным контекстом UE. В некоторых реализациях, исходная RAN-1 2A определяет ID Возобновления и передает его UE 1 и целевой RAN-2 2B. В качестве альтернативы, целевая RAN-2 2B может определять ID возобновления и передавать его к UE 1 через исходную RAN-1 2A.

[0221] Как описано выше, в данном варианте осуществления, после выполнения повторного выбора соты, относящегося к прямой передаче обслуживания, UE 1 передает целевой RAN-2 2B элемент информации, указывающий тип архитектуры связи, который был сконфигурирован в (или применялся к) UE 1 в исходной RAN-1 2A (например, информацию Сконфигурированного типа-архитектуры). Таким образом можно предотвратить несовместимость (или несоответствие) между конфигурацией типа архитектуры связи в UE 1 и тем, что в целевой RAN-2 2B.

[0222] Двадцать второй вариант осуществления

3GPP начинает работу над стандартизацией 5G, т.е., 3GPP Редакция 14, в 2016г, чтобы сделать 5G коммерческой реальностью в 2020г. Ожидается, что 5G будет реализован посредством последующее улучшения/развития LTE и Усовершенствованного-LTE и инновационного развития, благодаря внедрению нового радиоинтерфейса 5G (т.е., Технологии Радиодоступа (RAT)). Новая RAT (т.е., Новая 5G RAT) поддерживает, например, полосы частот выше полос частот (например, 6ГГц или ниже), поддерживаемых LTE/Усовершенствованным-LTE и это является улучшением/развитием. Например, новая RAT поддерживает полосы сантиметрового диапазона (10ГГц или выше) и полосы миллиметрового диапазона (30ГГц или выше).

[0223] Более высокая частота может обеспечивать более высокоскоростную связь. Тем не менее, из-за ее свойств частоты, покрытие более высокой частоты является более локальным. Вследствие этого, высокие частоты используются, чтобы увеличивать емкость и скорости передачи данных в конкретных зонах, в то время как покрытие широкой зоны обеспечивается посредством более низких частот. Т.е., для того, чтобы гарантировать стабильность связи Новой 5G RAT на полосах высоких частот, требуется плотная интеграция и взаимодействие между LTE/Усовершенствованным-LTE и Новой 5G RAT. Поддерживающий 5G радиотерминал (т.е., 5G Оборудование Пользователя (UE)) соединен как с сотой полосы низких частот, так и сотой полосы высоких частот (т.е., сотой LTE/Усовершенствованного-LTE и новой 5G сотой) посредством использования Агрегации Несущих (CA) или Возможности Двойного Соединения (DC) или их модифицированной методики.

[0224] Понятие «LTE» используемое в данном техническом описании, включает в себя улучшения LTE и Усовершенствованного-LTE для 5G, чтобы обеспечивать плотное взаимодействие с Новой 5G RAT, при условии, что не указано иное. Такие улучшения LTE и Усовершенствованного-LTE также именуются как Усовершенствованное-LTE Pro, LTE+, или улучшенное LTE (eLTE). Кроме того, понятие «5G» или «Новое 5G» в данном техническом описании используется, для удобства, чтобы указывать радиоинтерфейс (RAT), который вновь вводится для систем мобильной связи пятого поколения (5G), и узлов, сот, слоев протокола, и т.д., относящихся к данному радиоинтерфейсу. Названия нового вводимого радиоинтерфейса (RAT), и узлов, сот, и слоев протокола, связанных с ним, будут определены в будущем по ходу работы по стандартизации. Например, LTE RAT может именоваться Первичной RAT (P-RAT или pRAT) или Главной RAT. Между тем, Новая 5G RAT может именоваться Вторичной RAT (S-RAT или sRAT).

[0225] С первого по двадцать первый варианты осуществления, описанные выше, могут быть применены к 5G сети радиосвязи, которая обеспечивает плотное взаимодействие между LTE RAT и Новой 5G RAT. В некоторых реализациях, UE 1, RAN 2, и CN 3 могут выполнять любую из процедур прикрепления, описанных в с первого по восьмой вариантах осуществления, в LTE RAT и затем выполнять передачу данных в Новой 5G RAT в соответствии с типом архитектуры связи, определенным (или выбранным) в процедуре прикрепления.

[0226] Например, когда первый тип архитектуры связи используется для UE, UE 1 может передавать данные, используя сообщение Перенос Информации UL в соте 5G, вместо использования сообщения Завершена Настройка Соединения RRC в соте LTE, и принимать данные, используя сообщение перенос Информации DL в соте 5G. Например, когда второй тип архитектуры связи используется для UE 1, UE 1, RAN 2, и CN 3 могут выполнять приостановку и возобновление соединения RRC в соте 5G. В данном процессе, UE 1 и RAN 2 могут быть соединены как с узлом базовой сети для связи в соте LTE, так и узлом базовой сети отличным от того, который для связи в соте LTE.

[0227] Наконец, будут описаны примеры конфигурации UE 1, узла в RAN 2 (например, CIoT BS и eNB) и узла в CN 3 (например, C-SGN и MME) в соответствии с описанными выше вариантами осуществления. Фиг. 26 является структурной схемой, показывающей пример конфигурации UE 1. Радиочастотный (RF) приемопередатчик 2601 выполняет обработку аналогового RF сигнала, чтобы осуществлять связь с RAN 2. Обработка аналогового RF сигнала, выполняемая RF приемопередатчиком 2601 включает в себя частотное преобразование с повышением частоты, частотное преобразование с понижением частоты, и усиление. RF приемопередатчик 2601 связан с антенной 2602 и процессором 2603 основной полосы частот. Т.е., RF приемопередатчик 2601 принимает данные модулированного символа (или данные OFDM-символа) от процессора 2603 основной полосы частот, генерирует RF сигнал передачи, и подает сгенерированный RF сигнал передачи на антенну 2602. Кроме того, RF приемопередатчик 2601 генерирует сигнал приема основной полосы частот, основанный на RF сигнале приема, принятом антенной 2602, и подает сгенерированный сигнал приема основной полосы частот на процессор 2603 основной полосы частот.

[0228] Процессор 2603 основной полосы частот выполняет цифровую обработку сигнала основной полосы частот (т.е., обработку плоскости данных) и обработку плоскости управления для радиосвязи. Цифровая обработка сигнала основной полосы частот включает в себя (a) сжатие/распаковку данных, (b) сегментацию/сочленение данных, (c) составление/разложение формата передачи (т.е., кадра передачи), (d) кодирование/декодирование канала, (e) модуляцию (т.е., отображение символа)/демодуляцию, и (f) генерирование данных OFDM-символа (т.е., OFDM-сигнала основной полосы частот) посредством Обратного Быстрого Преобразования Фурье (IFFT). С другой стороны, обработка плоскости управления включает в себя администрирование связи слоя 1 (например, управление мощностью передачи), слоя 2 (например, администрирование ресурсов радиосвязи и обработка гибридного автоматического запроса повторной передачи (HARQ)), и слоя 3 (например, сигнализация касательно прикрепления, мобильности, и администрирование вызова).

[0229] В случае LTE и Усовершенствованного-LTE, например, цифровая обработка сигнала основной полосы частот, выполняемая процессором 2603 основной полосы частот, может включать в себя обработку сигнала слоя Протокола Конвергенции Пакетных Данных (PDCP), слоя Управления Линией Радиосвязи (RLC), слоя Управления Доступом к Среде (MAC) и Физического (PHY) слоя. Кроме того, обработка плоскости управления, выполняемая процессором 2603 основной полосы частот, может включать в себя обработку протокола Уровня без Доступа (NAS), протокола RRC, и Элемента Управления MAC (MAC CE).

[0230] Процессор 2603 основной полосы частот может включать в себя процессор модема (например, Цифровой Сигнальный Процессор (DSP)), который выполняет цифровую обработку сигнала основной полосы частот, и процессор стека протоколов (например, Центральный Блок Управления (CPU) или Микропроцессорный Блок (MPU)), который выполняет обработку плоскости управления. В данном случае, процессор стека протоколов, который выполняет обработку плоскости управления, может быть интегрирован с прикладным процессором 2604, который описывается в нижеследующем.

[0231] Прикладной процессор 2604 также может именоваться как CPU, MPU, микропроцессор, или ядро процессора. Прикладной процессор 2604 может включать в себя множество процессоров (ядер процессора). Прикладной процессор 2604 загружает программу программного обеспечения системы (Операционную систему (OS)) и разнообразные прикладные программы (например, приложение голосового вызова, WEB-браузер, почтовую программу, приложение работы камеры, и приложение проигрывателя музыки) из памяти 2606 или из другой памяти (не показано) и исполняет эти программы, тем самым обеспечивая разнообразные функции UE 1.

[0232] В некоторых реализациях, как представлено пунктирной линией (2605) на Фиг. 26, процессор 2603 основной полосы частот и прикладной процессор 2604 могут быть интегрированы в едином чипе. Другими словами, процессор 2603 основной полосы частот и прикладной процессор 2604 могут быть реализованы в едином устройстве 2605 Системы на Кристалле (SoC). Устройство SC может именоваться системой Большой Интегральной Микросхемы (LSI) или набором микросхем.

[0233] Память 2606 является энергозависимой памятью, энергонезависимой памятью, или их сочетанием. Память 2606 может включать в себя множество устройств памяти, которые являются физически независимыми друг от друга. Энергозависимая память является, например, Статической Памятью с Произвольным Доступом (SRAM), Динамической RAM (DRAM), или их сочетанием. Энергонезависимая память является, например, программно-маскируемой Постоянной Памятью (MROM), Электрически Стираемой Программируемой ROM (EEPROM), флэш-памятью, накопителем на жестком диске, или любым их сочетанием. Память 2606 может включать в себя, например, внешнее устройство памяти, доступ к которому может быть осуществлен посредством процессора 2603 основной полосы частот, прикладного процессора 2604, и SC 2605. Память 2606 может включать в себя внутреннее устройство памяти, которое является интегрированным в процессор 2603 основной полосы частот, прикладной процессор 2604, или SC 2605. Кроме того, память 2606 может включать в себя память в Универсальной Карте на основе Интегральной Микросхемы (UICC).

[0234] Память 2606 может хранить один или более модули 2607 программного обеспечения (компьютерные программы), включающие в себя инструкции и данные, чтобы выполнять обработку посредством UE 1, описанную в вышеприведенных вариантах осуществления. В некоторых реализациях, процессор 2603 основной полосы частот или прикладной процессор 2604 может загружать один или более модули 2607 программного обеспечения из памяти 2606 и исполнять загруженные модули программного обеспечения, тем самым выполняя обработку UE 1, описанную в вышеприведенных вариантах осуществления.

[0235] Фиг. 27 является структурной схемой, показывающей пример конфигурации узла в RAN 2 (например, CIoT BS или eNB) в соответствии с описанными выше вариантами осуществления. Как показано на Фиг. 27, узел включает в себя RF приемопередатчик 2701, сетевой интерфейс 2703, процессор 2704, и память 2705. RF приемопередатчик 2701 выполняет обработку аналогового RF сигнала, чтобы осуществлять связь с радиотерминалом 1. RF приемопередатчик 2701 может включать в себя множество приемопередатчиков. RF приемопередатчик 2701 соединен с антенной 2702 и процессором 2704. RF приемопередатчик 2701 принимает данные модулированного символа (или данные OFDM-символа) от процессора 2704, генерирует RF сигнал передачи, и подает сгенерированный RF сигнал передачи на антенну 2702. Кроме того, RF приемопередатчик 2701 генерирует сигнал приема основной полосы пропускания, основанный на RF сигнале приема, принятом посредством антенны 2702, и подает данный сигнал процессору 2704.

[0236] Сетевой интерфейс 2703 используется, чтобы осуществлять связь с сетевым узлом (например, MME, C-SGN, и S-GW). Сетевой интерфейс 2703 может включать в себя, например, карту сетевого интерфейса (NIC), в соответствии с группой стандартов IEEE 802.3.

[0237] Процессор 2704 выполняет цифровую обработку сигнала основной полосы частот (т.е., обработку плоскости данных) и обработку плоскости управления для радиосвязи. В случае LTE или Усовершенствованного-LTE, например, цифровая обработка сигнала основной полосы частот, выполняемая процессором 2704, может включать в себя обработку сигнала слоя PDCP, слоя RLC, слоя MAC, и слоя PHY. Кроме того, обработка плоскости управления, выполняемая процессором 2704, может включать в себя обработку протокола S1, протокола RRC, и MAC CE.

[0238] Процессор 2704 может включать в себя множество процессоров. Процессор 2704 может включать в себя, например, процессор модема (например, DSP), который выполняет цифровую обработку сигнала основной полосы частот и процессор стека протоколов (например, CPU или MPU), который выполняет обработку плоскости управления.

[0239] Память 2705 составлена из сочетания энергозависимой памяти и энергонезависимой памяти. Энергозависимая память является, например, SRAM, DRAM, или их сочетанием. Энергонезависимая память является, например, MROM, PROM, флэш-памятью, накопителем на жестком диске, или их сочетанием. Память 2705 может включать в себя хранилище, расположенное отдельно от процессора 2704. В данном случае, процессор 2704 может осуществлять доступ к памяти 2705 через сетевой интерфейс 2703 или интерфейс I/O (не показано).

[0240] Память 2705 может хранить один или более модули 2706 программного обеспечения (компьютерные программы), включающие в себя инструкции и данные, чтобы выполнять обработку посредством узла в RAN 2 (например, CIoT BS или eNB), описанную в вышеприведенных вариантах осуществления. В некоторых реализациях, процессор 2704 может загружать один или более модули 2706 программного обеспечения из памяти 2705 и исполнять загруженные модули программного обеспечения, тем самым выполняя обработку любого узла в RAN 2, описанную в вышеприведенных вариантах осуществления.

[0241] Фиг. 28 является структурной схемой, показывающей пример конфигурации узла в CN 3 (например, C-SGN или MME) в соответствии с описанными выше вариантами осуществления. Как показано на Фиг. 28, узел включает в себя сетевой интерфейс 2801, процессор 2802, и память 2803. Сетевой интерфейс 2801 используется, чтобы осуществлять связь с сетевым узлом (например, C-SGN, MME, HSS, S-GW, P-GW, CIoT BS, и eNB). Сетевой интерфейс 2801 может включать в себя, например, карту сетевого интерфейса (NIC), в соответствии с группой стандартов IEEE 802.3.

[0242] Процессор 2802 загружает один или более модули 2804 программного обеспечения (компьютерные программы) из памяти 2803 и исполняет загруженные модули программного обеспечения, тем самым выполняя обработку любого узла в CN 3 (например, C-SGN или MME), описанную в вышеприведенных вариантах осуществления. Процессор 2802 может быть, например, микропроцессором, MPU, или CPU. Процессор 2802 может включать в себя множество процессоров.

[0243] Память 2803 составлена из сочетания энергозависимой памяти и энергонезависимой памяти. Память 2803 может включать в себя хранилище, расположенное отдельно от процессора 2802. В данном случае, процессор 2802 может осуществлять доступ к памяти 2803 через интерфейс I/O (не показано).

[0244] Как описано со ссылкой на Фиг. с 26 по 28, каждый из процессоров, включенных в UE 1, узлы в RAN 2 и узлы в CN 3 в вышеприведенных вариантах осуществления, исполняет одну или более программы, включающие в себя набор инструкций, чтобы предписывать компьютеру выполнять алгоритм, описанный выше со ссылкой на чертежи. Эти программы могут быть сохранены на разнообразных типах не временных машиночитаемых носителей информации и посредством их подаваться компьютерам. Не временные машиночитаемые носители информации включают в себя разнообразные типы вещественных запоминающих носителей информации. Примеры не временных машиночитаемых носителей информации включают в себя магнитный записывающий носитель информации (такой как гибкий диск, магнитная лента, накопитель на жестком диске), магнитооптический записывающий носитель информации (такой как магнитооптический диск), Постоянную Память на Компакт Диске (CD-ROM), CD-R, CD-R/W, и полупроводниковую память (такую как программно-маскируемая ROM, Программируемая ROM (PROM), Стираемая PROM (EPROM), флэш ROM, и Память с Произвольным Доступом (RAM)). Эти программы могут быть поданы компьютерам посредством использования разнообразных типов временных машиночитаемых носителей информации. Примеры временных машиночитаемых носителей информации включают в себя электрический сигнал, оптический сигнал, и электромагнитную волну. Временные машиночитаемые носители информации могут быть использованы, чтобы подавать программы компьютеру через проводную линию связи (например, электрические провода или оптические волокна) или беспроводную линию связи.

[0245] Другие варианты осуществления

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

[0246] RAN 2, описанная в вышеприведенных вариантах осуществления, может быть Облачной Сетью Радиодоступа (C-RAN). C-RAN также именуется Централизованной RAN. Другими словами, процессы и операции, выполняемые посредством RAN 2, или CIoT BS или eNB в RAN 2, описанные в вышеприведенных вариантах осуществления, могут быть обеспечены посредством одного или сочетания из Цифрового Блока (DU) и Блока Радиосвязи (RU) включенных в архитектура C-RAN. DU также именуется Блоком Основной Полосы Частот (BBU). RU также именуется Удаленной Головкой Радиосвязи (RRH) или Удаленным Оборудованием Радиосвязи (RRE). Т.е., процессы и операции, выполняемые посредством RAN 2, CIoT BS, или eNB, описанные в вышеприведенных вариантах осуществления, могут быть обеспечены посредством любой одной или более радиостанций (узлов RAN).

[0247] Описанные выше варианты осуществления могут быть применены к любой из или как к связи в NB-IoT, так и связи в LTE eMTC. Кроме того, описанные выше варианты осуществления могут быть применены к связи UE в соответствии с LTE, Усовершенствованным-LTE или их модификациями. Кроме того, описанные выше варианты осуществления не ограничиваются LTE, Усовершенствованным-LTE или их модификациями, и также могут быть применены к другим сетям радиосвязи.

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

[0249] Данная заявка основана на и по ней испрашивается приоритет Японской патентной заявки № 2015-256034, поданной 28 декабря 2015г., раскрытие которой во всей своей полноте включено в настоящее описание посредством ссылки.

Перечень ссылочных обозначений

[0250] 1 Оборудование пользователя (UE)

2 Сеть радиодоступа (RAN)

3 Базовая сеть (CN)

4 Сервер приложений

5 Сервер домашнего абонента (HSS)

6 Обслуживающий шлюз (S-GW)

2603 Процессор основной полосы частот

2604 Прикладной процессор

2606 Память

2704 Процессор

2705 Память

2802 Процессор

2803 Память

1. Радиотерминал, содержащий:

память и

по меньшей мере один процессор, соединенный с памятью,

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

2. Радиотерминал по п.1, при этом

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

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

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

4. Долговременный машиночитаемый носитель информации, хранящий программу для предписания компьютеру выполнять способ связи в радиотерминале, при этом способ содержит этап, на котором передают на радиостанцию сообщение о завершении настройки соединения Управления Ресурсами Радиосвязи (RRC), включающее в себя вспомогательный элемент информации пользовательского оборудования (UE), указывающий, который из множества типов архитектуры связи для передачи пакета данных, относящейся к Сотовому Интернету Вещей (CIoT), радиотерминал хочет использовать, радиотерминал поддерживает или на который радиотерминал сконфигурирован.

5. Радиостанция, содержащая:

память и

по меньшей мере один процессор, соединенный с памятью,

при этом по меньшей мере один процессор выполнен с возможностью:

принимать сообщение о завершении настройки соединения Управления Ресурсами Радиосвязи (RRC) от радиотерминала и

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

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

7. Радиостанция по п.6, в которой по меньшей мере один процессор дополнительно выполнен с возможностью:

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

передавать в выбранную базовую сеть исходное сообщение Уровня без Доступа (NAS), извлеченное из сообщения о завершении настройки соединения RRC.

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

9. Радиостанция по п.7 или 8, при этом

по меньшей мере один процессор выполнен с возможностью:

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

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

10. Радиостанция по любому из пп.5-8, при этом

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

Изобретение относится к технике связи. Техническим результатом является необходимость надежной доставки на уровне 2, например, с использованием механизма автоматического повторного запроса.

Беспроводная док-система для аудио-видеоретрансляции // 2701489

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

Способ и устройство передачи данных // 2701383

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

Способ и устройство для управления мощностью // 2701380

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

Система аутентификации для мобильного терминала данных // 2701208

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

Устройство // 2701205

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

Способ бесконтактного считывания и записи с носителя информации // 2701127

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

Геолокация субъектов на основе производной социальной сети // 2701122

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

Улучшенное полупостоянное распределение ресурсов для трафика v2v // 2701117

Изобретение относится к области вычислительной техники. Технический результат заключается в повышении эффективности выделения ресурсов.

Определение и использование области физического восходящего канала управления (pucch) для связи между машинами (мтс) // 2701063

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