ГОСТ Р 59026-2024. Национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей. Протокол беспроводной передачи данных NB-IoT. Основные параметры

(утв. и введен в действие Приказом Росстандарта от 07.10.2024 № 1399-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р 59026-2020"]:::rst
  click n0 "https://bukva.ai/docs/standart-gost-r-59026-2020" "ГОСТ Р 59026-2020. Национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей. Протокол беспроводной передачи данных на основе стандарта LTE в режиме... "
  n1["ГОСТ Р 59026-2024"]:::doc
  click n1 "https://bukva.ai/docs/standart-gost-r-59026-2024" "ГОСТ Р 59026-2024. Национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей. Протокол беспроводной передачи данных NB-IoT. Основные параметры (утв. и в"
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 7 октября 2024 г. № 1399-ст

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

ИНТЕРНЕТ ВЕЩЕЙ

ПРОТОКОЛ БЕСПРОВОДНОЙ ПЕРЕДАЧИ ДАННЫХ NB-IoT. ОСНОВНЫЕ ПАРАМЕТРЫ

Information technology. Internet of things. NB-IoT wireless data transmission protocol. Key parameters

ГОСТ Р 59026-2024

ОКС 35.020

35.110

Дата введения 1 ноября 2024 года

Предисловие

1 РАЗРАБОТАН Публичным акционерным обществом «Мобильные ТелеСистемы» (ПАО «МТС»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 «Кибер-физические системы»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 7 октября 2024 г. № 1399-ст

4 ВЗАМЕН ГОСТ Р 59026-2020

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

1 Область применения

Настоящий стандарт распространяется на оборудование беспроводной передачи данных NB-IoT и устанавливает его основные параметры.

Требования настоящего стандарта следует учитывать при разработке, изготовлении и эксплуатации оборудования беспроводной передачи данных NB-IoT.

Настоящий стандарт, определяющий функционирование NB-IoT, допускается использовать как основу реализации цифровых решений в различных отраслях экономики — строительство, ЖКХ, «умный город», промышленность, сельское хозяйство, транспорт, логистика и др.

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

2 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

2.1 узкополосный интернет вещей; NB-IoT: Технология радиодоступа, входящая в состав сотового IoT, стандартизированная 3GPP для интернета вещей.

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

Примечание - Сотовый IoT поддерживает оба вида трафика: IP и не-IP.

2.3 эталонная чувствительность (reference sensitivity): Минимальная средняя мощность сигнала, подаваемая на антенный порт абонентского устройства (UE), при которой пропускная способность UE составляет не менее 95% от максимальной пропускной способности данного UE.

2.4 uplink-канал; UL (uplink): Канал связи восходящих сообщений от абонентского устройства.

2.5 downlink-канал; DL (downlink): Канал связи нисходящих сообщений к абонентскому устройству.

2.6 доверенный AS: Сервер приложений, расположенный внутри контура сети.

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

3 Сокращения и обозначения

3.1 В настоящем стандарте применены следующие сокращения:

АСУТП — автоматизированная система управления технологическим процессом;

КИИ — критическая информационная инфраструктура;

СКУД — система контроля и управления доступом;

СХ — сельское хозяйство;

УСПД — устройство сбора и передачи данных;

AF — прикладная функция (Application Function);

AM — режим передачи с подтверждениями (Acknowledged Mode);

AMF — функция управления доступом и мобильностью (Access and Mobility management Function);

API — интерфейс программирования приложений (Application Programming Interface);

APN — имя точки доступа (Access Point Name);

ARQ — автоматический повторный запрос (Automatic Repeat Request);

AS — сервер приложений (Application Server);

BCCH — широковещательный канал управления (Broadcast Control Channel);

BCH — широковещательный канал (Broadcast Channel);

BPSK — двоичная фазовая манипуляция (Binary Phase-Shift Keying);

CCCH — общий канал управления (Common Control Channel);

CoAP — протокол ограниченного приложения (Constrained Application Protocol);

CP — плоскость управления (Control Plane);

CRC — циклический избыточный код (Cyclic Redundancy Check);

CRS — референсный сигнал ячейки сети (Cell-specific Reference Signal);

CSGN — узел шлюза обслуживания сотового интернета вещей (Cellular IoT Serving Gateway Node);

CU — центральный блок (Central Unit);

DCCH — выделенный канал управления (Dedicated Control Channel);

DCI — управляющая информация downlink-канала (Downlink Control Information);

DL-SCH — общий downlink-канал (Downlink Shared Channel);

DMRS — референсный сигнал демодуляции (Demodulation Reference Signal);

DTCH — выделенный канал трафика (Dedicated Traffic Channel);

DU — распределенный блок (Distributed Unit);

EARFCN — номер частотного радиоканала (E-UTRA Absolute Radio Frequency Channel Number);

eDRX — расширенный прерывистый прием (Extended Discontinuous Reception);

eNB — базовая станция сети (eNodeB);

EPC — ядро пакетной сети нового поколения (Evolved Packet Core);

EPS — пакетная система нового поколения (Evolved Packet SYstem);

FDD — частотный дуплекс (Frequency Division Duplex);

GEO — геостационарная орбита (Geostationary Earth Orbit);

GNSS — глобальная спутниковая навигационная система (Global Navigation Satellite System);

GSM — глобальная система мобильной связи (Global System for Mobile Communications);

GTP — группа протоколов соединения на основе IP, используемая в сетях GSM, UMTS и LTE (GPRS Tunneling Protocol);

GTP-U — протокол передачи пользовательского трафика через туннели стандарта GTP (GPRS Tunneling Protocol For User Plane);

GUI — графический интерфейс пользователя (Graphical User Interface);

HARQ — гибридная схема с автоматическим запросом повторной передачи (Hybrid AUtomatic REpeat REquest);

HSS — сервер домашних абонентов (Home Subscriber Server);

HTTP — протокол передачи гипертекста (Hypertext Transfer Protocol);

HTTPS — защищенный протокол передачи гипертекста (Hypertext Transport Protocol Secure);

IMSI — международный идентификатор мобильного абонента (International Mobile Subscriber Identity);

IIoT — промышленный интернет вещей (Industrial IoT);

IoT — интернет вещей (Internet of Things);

IP — интернет-протокол (Internet Protocol);

LEO — низкая околоземная орбита (Low-earth Orbit);

LTE — стандарт беспроводной высокоскоростной передачи данных (Long Term EVolution);

LWM2M — облегченный протокол для управления устройствами M2M или IoT (Lightweight M2M);

M2M — межмашинное взаимодействие (Machine-to-machine);

MAC — управление доступом к среде (Media Access Control);

MEO — средняя околоземная орбита (Medium-earth ORbit);

MIB — блок системной информации (Master Information Block);

MME — объект управления мобильностью (Mobility Management Entity);

MO — сообщение, отправленное с мобильного устройства (Mobile Originated);

MONTE — мониторинг устройств (Monitoring Events);

MQTT — протокол обмена сообщениями по шаблону издатель — подписчик (Message Queuing Telemetry Transport);

MQTT-SN — протокол MQTT для сенсорных сетей (MQTT for Sensor Networks);

MT — сообщение, доставленное на мобильное устройство (Mobile terminated);

NAS — сигнальный протокол, не терминируемый на узлах сети радиодоступа (Non-access Stratum);

NCCE — элемент узкополосного канала управления (Narrowband control channel element);

NEF — функция обеспечения взаимодействия с внешними приложениями (Network Exposure Function);

NIDD — передача данных без использования стека протоколов IP (Non-IP Data Delivery);

NPBCH — узкополосный физический широковещательный канал (Narrowband PHysical BRoad-cast CHanneL);

NPDCCH — узкополосный физический downlink-канал управления (Narrowband Physical Downlink Control Channel);

NPDSCH — узкополосный физический общий downlink-канал (Narrowband Physical Downlink Shared Channel);

NPRACH — узкополосный физический канал случайного доступа (Narrowband Physical Random Access Channel);

NPRS — узкополосный референсный сигнал позиционирования (Narrowband Positioning Reference Signal);

NPSS — сигнал первичной синхронизации (Narrowband Primary Synchronization Signal);

NPUSCH — узкополосный физический uplink-канал общего пользования (Narrowband Physical Uplink Shared Channel);

NRS — узкополосный референсный сигнал (Narrowband Reference Signal);

NSSS — сигнал вторичной синхронизации (Narrowband Secondary Synchronization Signal);

NTN — неназемные сети связи (Non-terrestrial Network);

NWUS — узкополосный сигнал пробуждения (Narrowband wake up signal);

OFDM — мультиплексирование с ортогональным частотным разделением (Orthogonal Frequency Division Multiplexing);

OFDMA — ортогональный многостанционный доступ с частотным разделением каналов (Orthogonal Frequency Division Multiple Access);

PCCH — канал посылки пейджинговых сообщений (Paging Control Channel);

PCF — функция управления политиками (Policy Control Function);

PCH — пейджинговый канал (Paging Channel);

PDCP — протокол управления пакетными данными (Packet Data Convergence Protocol);

PDU — блок протокольных данных (Protocol Data Unit);

PGW — пакетный шлюз (Packet Data Network Gateway);

PHY — физический уровень (Physical Layer);

PSM — режим экономии энергии (Power Saving Mode);

PtP — точка-точка (Point-to-point);

QoS — качество обслуживания (Quality of Service);

QPSK — квадратурная фазовая манипуляция (Quadrature Phase Shift Keying);

RACH — транспортный канал случайного доступа (Random Access CHannel);

RAU — корректировка зоны маршрутизации (Routing Area Update);

REST — передача состояния представления (Representational State Transfer);

RLC — протокол управления радиоканалом (Radio Link Control);

RRC — протокол управления радиоресурсами (Radio Resource Control);

S1-U — интерфейс связи между eNodeB и SGW (S1 — User Plane);

S1AP — протокол прикладного уровня между eNodeB и MME (S1 — Application protocol);

SAP — точка доступа к службам (Service Access Point);

SC-FDMA — множественный доступ с частотным разделением каналов с одной несущей частотой (Single-carrier Frequency Division Multiple Access);

SCADA — диспетчерское управление и сбор данных (Supervisory Control and Data Acquisition);

SCEF — узел экспонирования сервисных возможностей (Service Capability Exposure Function);

SCTP — протокол передачи с управлением потока — протокол транспортного уровня (Stream Control Transmission Protocol);

SDU — блок служебных данных (Service Data Unit);

SGi — интерфейс между PGW и внешними IP-сетями (Service Gateway Interface);

SGSN — обслуживающий узел поддержки GPRS (Serving GPRS support node);

SGW — обслуживающий шлюз (Serving Gateway);

SIB — блок системной информации (System information block);

SMF — функция управления сессиями (Session Management Function);

SMPP — одноранговая передача коротких сообщений (Short Message Peer-to-peer);

SMS — служба коротких сообщений (Short Message Service);

SMSC — SMS-центр (SMS Centre);

TA — временная компенсация (Timing Advance);

TAU — обновление зоны отслеживания (Tracking Area Update);

TCP — протокол управления передачей (Transmission Control Protocol);

TDD — временное разделение каналов (Time Division Duplex);

TM — прозрачный режим (Transparent Mode);

TTC — технология передачи «телеметрия, отслеживание, управление» (Telemetry, Track and Command);

UCI — управляющая информация uplink-канала (Uplink Control Information);

UDM — модуль управления данными пользователей (Unified Data Management);

UDP — протокол пользовательских датаграмм (User Diagram Protocol);

UE — абонентское устройство (User Equipment);

UL-SCH — общий канал для передачи данных вверх (Uplink Shared Channel);

UM — режим передачи без подтверждений (Unacknowledged Mode);

UP — пользовательская плоскость в сетях связи (User Plane);

UPF — функция передачи данных пользователей (User Plane Function);

VPN — виртуальная частная сеть (Virtual Private Network);

16QAM — квадратурная амплитудная модуляция с числом уровней 16 (16-Quadrature amplitude Modulation);

2G — мобильная связь второго поколения (2-nd Generation);

3G — мобильная связь третьего поколения (3-rd Generation);

3GPP — партнерский проект по развитию систем третьего поколения (3-rd Generation Partnership Project);

4G — мобильная связь четвертого поколения (4-th Generation);

5G — мобильная связь пятого поколения (5-th Generation).

3.2 В настоящем стандарте применены следующие обозначения:

FUL_low — низшая частота uplink-канала;

FUL_high — высшая частота uplink-канала;

FDL_low — низшая частота downlink-канала;

FDL_high — высшая частота downlink-канала;

NOffs-DL — смещение для расчета EARFCN downlink-канала;

NOffs-UL — смещение для расчета EARFCN uplink-канала.

4 Параметры радиоинтерфейса для функционирования NB-IoT

4.1 Диапазоны рабочих частот downlink- и uplink-каналов NB-IoT <*>

Диапазоны рабочих частот downlink- и uplink-каналов NB-IoT <*> приведены в таблице 1 [1].

<*> На территории Российской Федерации использование частот должно осуществляться в соответствии с решением Государственной комиссии по радиочастотам от 28 декабря 2017 г. № 17-44-06.

Таблица 1

Диапазоны рабочих частот downlink- и uplink-каналов NB-IoT

4.2 Конфигурации частотного ресурса канала передачи данных NB-IoT

Существует несколько конфигураций частотного ресурса канала передачи данных NB-IoT:

• Standalone — независимая работа канала NB-IoT;
• Guard-band — работа канала NB-IoT в защитном интервале полосы канала LTE;
• In-band — работа канала NB-IoT внутри канала LTE.

Конфигурация полосы пропускания канала приведена в таблице 2.

Таблица 2

Конфигурация полосы пропускания канала LTE

Конфигурации полосы пропускания каналов NB-IoT указаны в таблице 3.

Таблица 3

Конфигурации полосы пропускания каналов NB-IoT

На рисунке 1 показаны варианты размещения канала NB-IoT в режиме Standalone.

Рисунок 1 — Варианты размещения канала NB-IoT в режиме Standalone

На рисунке 2 показано размещение канала NB-IoT в режиме In-band.

Рисунок 2 — Размещение и конфигурация полосы пропускания канала NB-IoT в режиме работы In-band

На рисунке 3 показано размещение канала NB-IoT в режиме Guard-band.

Рисунок 3 — Размещение и конфигурация полосы пропускания канала NB-IoT в режиме работы Guard-band

4.3 Расположение NB-IoT каналов

Несущая частота downlink-канала NB-IoT обозначается EARFCN в диапазоне от 0 до 262 143 и смещением номера канала NB-IoT по отношению к EARFCN в диапазоне {-10; -9; -8; -7; -6; -5; -4; -3; -2; -1; -0,5; 0; 1; 2; 3; 4; 5; 6; 7; 8; 9} для FDD и в диапазоне {-10; -9; -8,5; -8; -7; -6; -5; -4,5; -4; -3; -2; -1; -0,5; 0; 1; 2; 3; 3,5; 4; 5; 6; 7; 7,5; 8; 9} для TDD.

Соотношение между EARFCN, смещением номера канала NB-IoT по отношению к EARFCN и несущей частотой в МГц downlink-канала определяют выражением:

FDL = FDL_low + 0,1·(NDL — NOffs-DL) + 0,0025·(2MDL + 1),

где FDL — несущая частота downlink-канала NB-IoT;

FDL_low и NOffs-DL указаны в таблице 4;

NDL — EARFCN downlink-канала;

MDL — смещение номера канала NB-IoT по отношению к EARFCN downlink-канала.

Несущая частота uplink-канала NB-IoT обозначается EARFCN в диапазоне от 0 до 262 143 и смещением номера канала NB-IoT по отношению к EARFCN в диапазоне {-10; -9; -8; -7; -6; -5; -4; -3; -2; -1; 0; 1; 2; 3; 4; 5; 6; 7; 8; 9} для FDD и в диапазоне {-11; -10; -9,5; -9; -8,5; -8; -7,5; -7; -6,5; -6; -5,5; -5; -4,5; -4; -3,5; -3; -2,5; -2; -1,5; -1; -0,5; 0; 0,5; 1; 1,5; 2; 2,5; 3; 3,5; 4; 4,5; 5; 5,5; 6; 6,5; 7; 7,5; 8; 8,5; 9; 9,5; 10; 11} для TDD.

Соотношение между EARFCN, смещением номера канала NB-IoT по отношению к EARFCN и несущей частотой в МГц uplink-канала определяют выражением:

FUL = FUL_low + 0,1·(NUL — NOffs-UL) + 0,0025·(2MUL),

где FUL — несущая частота uplink-канала NB-IoT;

FUL_low и NOffs-UL указаны в таблице 4;

NUL — EARFCN uplink-канала;

MUL — смещение номера канала NB-IoT по отношению к EARFCN uplink-канала.

Разнос несущих соседних частотных каналов, имеющих полосы пропускания канала BWChannel(1) и BWChannel(2), определяется как (BWChannel(1) + BWChannel(2))/2.

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

Примечания

1 Для режимов работы In-band или Guard-band значения NDL или NUL отличаются от значения EARFCN, соответствующего несущей частоте downlink- или uplink-канала.

2 Для режима работы In-band или Guard-band в случае FDD не применимо значение MDL = -0,5; в случае TDD не применимы значения MDL{-0,5; +3,5; -4,5; +7,5; -8,5}.

Значения EARFCN для различных диапазонов рабочих частот для функционирования NB-IoT приведены в таблице 4 <*>.

<*> На территории Российской Федерации использование указанных параметров должно осуществляться в соответствии с Приказом Министерства связи и массовых коммуникаций РФ от 6 июня 2011 г. № 128 «Об утверждении Правил применения абонентских терминалов сетей подвижной радиотелефонной связи стандарта LTE».

Таблица 4

Значения EARFCN для различных диапазонов рабочих частот для функционирования NB-IoT

5 Категории абонентских устройств NB-IoT

Настоящий стандарт определяет две категории абонентских устройств NB-IoT. Основные параметры категорий NB1 и NB2 представлены в таблице 5 [2].

Таблица 5

Основные параметры категорий абонентских устройств NB-IoT

Допустимые уровни внеполосных излучений абонентских устройств категорий NB1 или NB2 указаны в таблице 6. Значения допустимых уровней внеполосных излучений для значений частот \Delta f_{OOB} между указанными в таблице линейно интерполируются. Для значений частот \Delta f_{OOB} , больше указанных в таблице, применяются требования к уровням побочных излучений.

Таблица 6

Допустимые уровни внеполосных излучений абонентских устройств категорий NB1 и NB2

Допустимые уровни побочных излучений абонентских устройств категорий NB1 или NB2 указаны в таблице 7.

Таблица 7

Допустимые уровни побочных излучений абонентских устройств категорий NB1 и NB2

Минимальный набор рекомендуемых функций для абонентских устройств категорий NB1 и NB2, определен в таблице 8.

Таблица 8

Минимальный набор рекомендуемых функций для абонентских устройств категорий NB1 и NB2

6 Архитектура сети NB-IoT

6.1 Общая архитектура

Общая архитектура сети NB-IoT представлена на рисунке 4 [3].

Основные каналы коммуникаций включают Control Plane (CP) и User Plane (UP). Control Plane предназначен для обмена служебными сообщениями между различными элементами сети и служит для обеспечения мобильности абонентских устройств и установления/поддержания сессии передачи данных. User Plane — это канал передачи пользовательских данных.

Механизмы оптимизации CP и UP (CIoT EPS optimization) для NB-IoT реализованы на узлах MME, SGW и PGW, которые объединяются в единый элемент CSGN. Несмотря на то, что CP предназначен для передачи сигнальной информации, в NB-IoT он адаптирован для передачи пользовательских данных (как IP, так и non-IP) и SMS в сообщениях NAS. В NB-IoT передача SMS обеспечивается без регистрации устройства в голосовом домене.

Для абонентских устройств NB-IoT поддержка CP CIoT оптимизации является обязательной. Поскольку CP использует плоскость управления для пересылки пакетов данных, передача или прием сообщений отправляется, как сообщения сигнализации NAS, между UE и MME. По сравнению с процедурой Service Request, UE избегает установки безопасности Access Stratum и установления сквозных каналов (default bearer), необходимых при каждой передаче данных.

Рисунок 4 — Общая схема сети NB-IoT

CP CIoT оптимизация обеспечивает поддержку эффективной транспортировки пользовательских данных или SMS-сообщений через CP через MME без запуска установления радиоканала.

Элемент SCEF представляет собой узел экспонирования сервисных возможностей и является посредником между сетью и сервером приложений AS. SCEF включает в себя функции идентификации/аутентификации абонентских устройств и определения правил обмена данными между устройством и AS, предоставляя возможность серверам приложений получать данные и управлять устройствами через единый API-интерфейс. SCEF также является единым окном доступа к набору сервисов оператора по управлению и контролю за абонентскими устройствами.

При использовании SCEF идентификатором абонентского устройства является «external ID», который определяется в формате «@».

Ключевые функции и сервисы SCEF включают:

• привязка идентификатора сим-карты (IMSI) к external ID;
• NIDD передача;
• групповые операции, с использованием external group ID;
• поддержка режима передачи данных с подтверждением;
• буферизация MT данных;
• аутентификация и авторизация устройств и серверов приложений;
• одновременное использование данных одного абонентского устройства несколькими AS;
• поддержка специальных функций контроля состояния абонентского устройства (MONTE);
• триггеринг устройств (передача данных в SMS);
• обеспечение роуминга non-IP данных.

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

В сети NB-IoT рекомендуется применять следующие способы передачи данных в порядке убывания предпочтения:

• режим передачи NIDD;
• протокол передачи данных CoAP (стек IP/UDP);
• протоколы MQTT-SN и LWM2M (стек IP/UDP);
• проприетарные бинарные протоколы на основе UDP.

6.2 Архитектура сети для передачи пакетов NIDD

6.2.1 Передача NIDD без SCEF через интерфейс SGi

В случае отсутствия SCEF, non-IP данные могут передаваться к AS через Point-to-Point (PtP) тоннель от PGW, в таком случае инкапсуляция в IP производится на нем. Сервер приложений может быть подключен непосредственно к PGW. Адрес сервера приложений определяется на этапе создания APN. В случае если требуется конверсия протоколов, интеграция может осуществляться через IoT-шлюз.

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

Архитектура сети для передачи NIDD без SCEF представлена на рисунке 5 [3].

Рисунок 5 — Передача NIDD без SCEF через интерфейс SGi

Для данного вида передачи существуют следующие ограничения:

• требуется поддержка UDP API со стороны AS;
• требуется реализация идентификации и аутентификации устройств на уровне приложения как со стороны AS, так и со стороны устройства. Это приводит к увеличению передаваемого объема служебной информации и увеличивает нагрузку на сеть NB-IoT;
• обратный канал (управления устройством) доступен не в произвольные моменты времени, а только в короткие промежутки времени после передачи данных от устройства. Снятие данного ограничения возможно путем использования статических IP-адресов и выделенного корпоративного APN;
• доставка данных не гарантируется на уровне транспортного протокола UDP при передаче между CSGN/PGW и AS, необходима реализация гарантированной доставки на уровне приложения (протоколы CoAP, LWM2M и др.);
• взаимодействие возможно только с одним AS PtP.

6.2.2 Передача NIDD через SCEF

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

Архитектура сети для передачи NIDD через SCEF представлена на рисунке 6 [3].

Взаимодействие сервера приложений с SCEF осуществляется по NIDD REST API. Информация о доступности устройств передается по MONTE REST API.

Технология оптимизации передачи данных NIDD NB-IoT не использует стек протоколов IP и позволяет сократить время нахождения устройств в активном состоянии, обеспечивает обслуживание большего количества устройств в одной локации, улучшает энергоэффективность и обеспечивает безопасность устройств при доступе извне, так как взаимодействие с устройством осуществляется через узел SCEF без прямого доступа устройства в сеть Интернет.

Рисунок 6 — Передача NIDD через SCEF

6.3 Архитектура сети для передачи данных IP

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

Передача данных применима ко всем протоколам, базирующимся на IP: TCP, UDP, CoAP, LWM2M, HTTP, MQTT и т.д. Интеграция может быть проведена как для внешних серверов приложений, так и для доверенных серверов приложений, расположенных внутри контура сети.

Архитектура сети для передачи данных IP представлена на рисунке 7 [3].

Рисунок 7 — Передача данных IP

Для передачи данных устройство должно открыть IP-сессию, после чего данные передаются непосредственно на IP-адрес сервера приложений.

Данный метод интеграции относится к нецелевым и не рекомендуется для массового применения. Рекомендуется интеграция с использованием NIDD. Допускается интеграция с использованием протокола UDP [4].

7 Стек протокола передачи данных NB-IoT

7.1 Стек протокола передачи данных

Стеки протокола передачи данных NB-IoT с использованием CP и UP представлены на рисунках 8 и 9.

В случае передачи данных NB-IoT с использованием CP для абонентских устройств, которые поддерживают только CP CIoT оптимизацию, PDCP не используется. Для абонентских устройств, которые поддерживают CP CIT оптимизацию и передачу данных S1-U или UP CIoT оптимизацию, PDCP не используется до тех пор, пока не будет активирована безопасность Access Stratum.

<*> Опционально.

Рисунок 8 — Стек протокола передачи данных NB-IoT с использованием CP

<*> Опционально.

Рисунок 9 — Стек протокола передачи данных NB-IoT с использованием UP

7.2 Взаимосвязь уровней стека и каналов передачи данных

Взаимосвязь уровней и каналов NB-IoT представлена на рисунке 10 [5].

Рисунок 10 — Взаимосвязь уровней стека и каналов передачи данных

Овалы между различными уровнями/подуровнями на рисунке 10 обозначают точки доступа к службам (SAP). Уровень PHY предусматривает транспортный канал к MAC. Уровень MAC предусматривает логические каналы к RLC уровня 2.

Схема физических, транспортных и логических каналов в downlink-канале представлена на рисунке 11.

Рисунок 11 — Схема каналов в downlink-канале

Схема физических, транспортных и логических каналов в uplink-канале представлена на рисунке 12.

Рисунок 12 — Схема каналов в uplink-канале

7.3 Уровень PHY

7.3.1 Функции

Уровень PHY обеспечивает [6]:

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

7.3.2 Downlink-канал

7.3.2.1 Физические каналы и сигналы

Для NB-IoT определены следующие физические downlink-каналы:

• NPBCH (Narrowband Physical Broadcast Channel) — узкополосный физический широковещательный канал;
• NPDSCH (Narrowband Physical Downlink Shared Channel) — узкополосный физический общий downlink-канал;
• NPDCCH (Narrowband Physical Downlink Control Channel) — узкополосный физический downlink-канал управления.

Для NB-IoT определены физические сигналы, используемые для целей синхронизации и измерений:

• NRS (Narrowband Reference Signal) — узкополосный референсный сигнал;
• NPSS/NSSS (Narrowband Primary/Secondary Synchronization Signals) — сигналы первичной и вторичной синхронизации;
• NPRS (Narrowband Positioning Reference Signal) — узкополосный референсный сигнал позиционирования;
• NWUS (Narrowband Wake Up Signal) — узкополосный сигнал пробуждения.

Формирование сигнала физического downlink-канала включает следующие этапы (см. рисунок 13):

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

Рисунок 13 — Обработка физического downlink-канала

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

Таблица 9

Схемы модуляции NPDSCH

7.3.2.2 Узкополосный физический общий канал NPDSCH

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

Каждое кодовое слово NPDSCH может быть распределено в один или несколько подкадров, каждый из которых должен быть передан заданное число раз.

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

• подкадр не используется для передачи NPBCH, NPSS или NSSS;
• предполагается, что абонентское устройство не будет использовать данные ресурсные элементы для NRS, за исключением специального подкадра;
• не происходит перекрытия с ресурсными элементами, используемыми для CRS.

7.3.2.3 Узкополосный физический широковещательный канал NPBCH

Абонентское устройство должно предполагать, что для передачи NPBCH используются антенные порты 2000 и 2001. Для целей распределения абонентское устройство должно предполагать, что независимо от фактической конфигурации присутствуют специфичные для соты референсные сигналы для антенных портов 0 — 3 и узкополосные референсные сигналы для антенных портов 2000 и 2001.

7.3.2.4 Узкополосный физический downlink-канал управления NPDCCH

NPDCCH передает управляющую информацию (DCI) в виде совокупности одного или двух последовательных элементов канала управления (NCCE). Элемент канала управления NCCE соответствует 6 последовательным поднесущим в подкадре, NCCE 0 занимает поднесущие с 0 по 5, а NCCE 1 — поднесущие с 6 по 11. Различные форматы NPDCCH указаны в таблице 10. Для формата NPDCCH 1 два NCCE принадлежат одному и тому же подкадру.

В подкадре могут быть переданы один или два NPDCCH.

Таблица 10

Форматы NPDCCH

Распределение по ресурсным элементам на антенный порт p должно осуществляться в порядке возрастания сначала индекса k, а затем индекса l, начиная с первого слота и заканчивая вторым слотом в подкадре.

7.3.2.5 Узкополосный референсный сигнал NRS

Референсные сигналы передаются на один или два антенных порта.

Если на более высоких уровнях указано, что абонентское устройство может считать N_{ID}^{cell} равным N_{ID}^{Ncell} , то абонентское устройство может предположить:

• количество антенных портов для специфичных для соты референсных сигналов такое же, как и для узкополосных референсных сигналов;
• антенные порты для специфичных для соты референсных сигналов {0, 1} эквивалентны антенным портам для узкополосных референсных сигналов {2000, 2001};
• специфичные для соты референсные сигналы доступны во всех подкадрах, где доступны узкополосные референсные сигналы.

Если на более высоких уровнях не указано, что абонентское устройство может считать N_{ID}^{cell} равным N_{ID}^{Ncell} , то абонентское устройство может предположить:

• количество антенных портов для специфичных для соты референсных сигналов определяется из параметра более высокого уровня eutra-NumCRS-Ports;
• специфичные для соты референсные сигналы доступны во всех подкадрах, где доступны узкополосные референсные сигналы.

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

Не допускается передача узкополосных референсных сигналов в подкадрах, содержащих NPSS или NSSS.

Не допускается передача узкополосных референсных сигналов в специальном подкадре для конфигураций 0 и 5 в случае структуры кадра типа 2.

На рисунке 14 показаны ресурсные элементы, используемые для передачи референсного сигнала. Обозначение Rp используется для обозначения ресурсного элемента, используемого для передачи референсного сигнала на антенный порт p.

7.3.2.6 Узкополосный референсный сигнал позиционирования NPRS

Передачу NPRS проводят только в ресурсных блоках несущих NB-IoT, настроенных для передачи NPRS. В подкадре для передачи NPRS начальные позиции символов OFDM для передачи NPRS должны быть идентичны позициям в подкадре, в котором все символы OFDM имеют ту же самую длину циклического префикса, что и символы OFDM для передачи NPRS. NPRS определяют только для \Delta f = 15kHz и нормального циклического префикса.

Передачу NPRS осуществляют через антенный порт 2006.

Если параметр более высокого уровня nprsBitmap не определен, для передачи NPRS не должны быть использованы ресурсные элементы в символах OFDM 5 и 6. Если периодичность NPRS типа 1 равна периодичности NPRS типа 2, предполагается, что абонентское устройство не настраивается с перекрытием ресурсных элементов между NPRS типа 1 и NPRS типа 2. В обратном случае ресурсный элемент, настроенный для NPRS типа 1, не должен быть использован для NPRS типа 2.

Рисунок 14 — Распределение узкополосных референсных сигналов downlink-канала (нормальный циклический префикс)

На рисунках 15 и 16 показаны распределения при передаче сигнала NPRS для различных режимов работы NB-IoT.

Рисунок 15 — Распределение NPRS (operationModeInfoNPRS установлен на режим In-band, nprsBitmap сконфигурирован)

Рисунок 16 — Распределение NPRS (operationModeInfoNPRS установлен на режим работы Standalone или Guard-band, nprsBitmap сконфигурирован)

7.3.2.7 Узкополосный сигнал пробуждения NWUS

Для всех символов NWUS в подкадре должен быть использован один и тот же антенный порт. Абонентское устройство не должно предполагать, что NWUS передается через тот же антенный порт, что и любой из референсных сигналов downlink-канала или сигналов синхронизации. Если сконфигурирован только один порт NRS, абонентское устройство может предположить, что для передачи всех подкадров NWUS используется один и тот же антенный порт; в противном случае — что один и тот же антенный порт используется для передачи NWUS в подкадрах w0 + 2n и w0 + 2n + 1, где w0 — первый подкадр передачи NWUS, n = 0, 1, ... .

Для несущей NB-IoT, для которой абонентское устройство получает параметр более высокого уровня OperationModeInfo, указывающий режим работы Standalone или Guard-band, а также для несущей NB-IoT, для которой присутствует DL-CarrierConfigCommon-NB и отсутствует inbandCarrierInfo, распределение ресурсов для трех первых символов OFDM в подкадре выполняют следующим образом:

• ресурсный элемент (k,7) распределяется в ресурсный элемент (k,0) каждого индекса k по 12 назначенным поднесущим;
• ресурсный элемент (k,8) распределяется в ресурсный элемент (k,1) каждого индекса k по 12 назначенным поднесущим;
• ресурсный элемент (k,9) распределяется в ресурсный элемент (k,2) каждого индекса k по 12 назначенным поднесущим.

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

7.3.2.8 Узкополосный первичный сигнал синхронизации NPSS

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

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

7.3.2.9 Узкополосный вторичный сигнал синхронизации NSSS

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

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

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

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

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

7.3.2.10 Управляющая информация downlink-канала (DCI)

Таблица 11 определяет сопоставление DCI физическому каналу [7].

Таблица 11

Сопоставление DCI физическому каналу

Для DCI применяются схема и скорость кодирования, указанные в таблице 12.

Таблица 12

Схема и скорость кодирования DCI

7.3.3 Uplink-канал

7.3.3.1 Физические каналы и сигналы

Для NB-IoT определены следующие физические каналы:

• NPUSCH (Narrowband Physical Uplink Shared Channel) — узкополосный физический общий канал;
• NPRACH (Narrowband Physical Random Access Channel) — узкополосный физический канал случайного доступа.

Для NB-IoT определен один физический сигнал uplink-канала:

• DMRS (Demodulation Reference Signal) — референсный сигнал демодуляции.

Формирование сигнала физического uplink-канала включает следующие этапы (см. рисунок 17):

• вставка CRC;
• кодирование канала;
• согласование скоростей;

Рисунок 17 — Обработка физического uplink-канала

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

7.3.3.2 Узкополосный физический общий канал NPUSCH

NPUSCH поддерживает два формата:

• формат NPUSCH 1, используемый для передачи UL-SCH;
• формат NPUSCH 2, используемый для передачи управляющей информации по uplink-каналу (UCI).

В случае повторений NPUSCH последовательность скремблирующего кода должна быть повторно инициализирована после каждой M_{identical}^{NPUSCH} передачи кодового слова, и для первого слота и кадра, используемых для передачи повтора, должны быть установлены ns и nf соответственно.

Модуляцию NPUSCH проводят с использованием схем модуляции, указанных в таблице 13.

Таблица 13

Схемы модуляции

Каждое кодовое слово NPUSCH может быть распределено на одну или более ресурсную единицу, каждая из которых должна быть передана M_{rep}^{NPUSCH} раз.

Для формата NPUSCH 1 и 2 в структуре кадра типа 2 при \Delta f = 3,75kHz :

• передача NPUSCH выполняется в первом наборе слотов, охватывающем два последовательных подкадра uplink-канала, не перекрывающихся ни с одним подкадром uplink-канала, сконфигурированным как недействительный;
• для конфигурации TDD 1 и 4, если начальная позиция для NPUSCH указана как второй из двух последовательных подкадров uplink-канала, передача NPUSCH откладывается до начала двух последовательных подкадров uplink-канала.

7.3.3.3 Узкополосный физический канал случайного доступа NPRACH

Конфигурация NPRACH, предоставляемая более высокими уровнями, включает:

• периодичность ресурса NPRACH (nprach-Periodicity);
• положение частоты первой поднесущей, выделенной для NPRACH (nprach-SubcarrierOffset);
• количество поднесущих, выделенных для NPRACH (nprach-NumSubcarriers);
• количество начальных поднесущих, выделенных для случайного доступа, инициированного абонентским устройством (nprach-NumCBRA-StartSubcarriers);
• количество повторений NPRACH за одну попытку (numRepetitionsPerPreambleAttempt);
• время начала NPRACH (nprach-StartTime),
• доля для расчета начального индекса поднесущей для диапазона поднесущих NPRACH, зарезервированных для индикации поддержки абонентского устройства многотональной передачи (nprach-SubcarrierMSG3-RangeStart).

7.3.3.4 Референсный сигнал демодуляции DMRS

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

7.3.3.5 Управляющая информация uplink-канала (UCI)

Таблица 14 определяет сопоставление UCI физическому каналу [7].

Таблица 14

Сопоставление UCI физическому каналу

Для UCI применяются схема и скорость кодирования, указанные в таблице 15.

Таблица 15

Схема и скорость кодирования UCI

7.4 Уровень MAC

7.4.1 Функции и структура

Уровень MAC обеспечивает:

• выполнение HARQ-операций;
• сопоставление (mapping) логических каналов транспортным каналам;
• мультиплексирование/демультиплексирование логических каналов в транспортные блоки;
• приоритизацию логических каналов;
• работу планировщика ресурсов;
• исполнение процедур случайного доступа и прерывистого приема (DRX);
• взаимодействие (сервисы) с верхними уровнями (передача данных, выделение радиоресурсов);
• взаимодействие (сервисы) с нижними уровнями (передача данных, сигнализация, измерения).

Возможная структура уровня MAC представлена на рисунке 18 [8].

Рисунок 18 — Структура уровня MAC

MAC PDU — это битовая строка, выравненная по байтам, т.е. количество разрядов которой кратно 8. MAC PDU состоит из заголовка MAC, нуля или более блоков служебных данных MAC (MAC SDU), нуля или нескольких элементов управления MAC и, опционально, дополнения, согласно рисунку 19. Порядок следования байтов каждого поля параметра в MAC PDU является прямым, т.е. от старшего разряда к младшему.

Рисунок 19 — Структура MAC PDU [8]

Заголовок MAC и MAC SDU имеют переменные размеры.

Заголовок MAC состоит из одного или нескольких подзаголовков MAC. Подзаголовки MAC соответствуют MAC SDU, элементам управления MAC или дополнению и имеют тот же порядок, что и соответствующие MAC SDU, элементы управления MAC и дополнение.

На каждый транспортный блок объекта MAC может быть передан максимум один MAC PDU.

7.4.2 Downlink-канал

Для downlink-канала определены три транспортных канала:

• BCH (Broadcast Channel) — вещательный канал;
• PCH (Paging Channel) — пейджинговый канал;
• DL-SCH (Downlink Shared Channel) — общий downlink-канал.

Для downlink-канала определены пять логических каналов:

• BCCH (Broadcast Control Channel) — широковещательный канал управления, переносящий системную информацию (MIB) всем абонентским устройствам в соте;
• PCCH (Paging Control Channel) — канал посылки пейджинговых сообщений для абонентских устройств, местонахождение которых не определено с точностью до соты;
• CCCH (Common Control Channel) — общий канал управления для передачи управляющей информации абонентскому устройству до назначения ему выделенного канала управления (DCCH);
• DTCH (Dedicated Traffic Channel) — выделенный канал трафика абонентского устройства;
• DCCH (Dedicated Control Channel) — выделенный канал управления для передачи управляющей информации абонентскому устройству.

7.4.3 Uplink-канал

Для uplink-канала определены два транспортных канала:

• RACH (Random Access Channel) — транспортный канал случайного доступа;
• UL-SCH (Uplink Shared Channel) — транспортный общий uplink-канал.

Для uplink-канала определены три логических канала:

• CCCH (Common Control Channel) — общий канал для передачи управляющей информации от абонентского устройства до назначения ему выделенного канала управления (DCCH);
• DTCH (Dedicated Traffic Channel) — выделенный канал трафика абонентского устройства;
• DCCH (Dedicated Control Channel) — выделенный канал для передачи управляющей информации от абонентского устройства.

7.5 Уровень RLC

7.5.1 Функции и структура

Функции RLC уровня выполняются RLC-объектами. RLC-объект функционирует в одном из трех режимов передачи: TM (прозрачный режим), UM (режим передачи без подтверждения) и AM (режим передачи с подтверждением). Таким образом, в зависимости от режима передачи данных объект RLC классифицируется как объект TM RLC, объект UM RLC или объект AM RLC.

Уровень RLC обеспечивает [9]:

• передачу PDU на верхние уровни;
• исправление ошибок через ARQ (для передачи данных в режиме AM);
• конкатенацию, сегментацию и повторную сборку RLC SDU (для передачи данных в режимах UM и AM);
• повторную сегментацию PDU данных RLC (для передачи данных в режиме AM);
• изменение порядка PDU данных RLC (для передачи данных в режимах UM и AM);
• обнаружение повторных пакетов (для передачи данных в режимах UM и AM);
• сброс RLC SDU (для передачи данных в режимах UM и AM);
• восстановление RLC;
• обнаружение ошибок протокола (для передачи данных в режиме AM);
• взаимодействие (сервисы) с верхними уровнями (передача данных TM, UM и AM);
• взаимодействие (сервисы) с нижними уровнями (обмен данными, получение уведомлений о возможности передачи данных).

Для объекта RLC, сконфигурированного в eNB, существует равноправный объект RLC, сконфигурированный в UE, и наоборот. Модель уровня RLC представлена на рисунке 20.

Рисунок 20 — Модель уровня RLC [9]

По отношению ко всем типам объектов RLC применяются следующие положения:

• поддерживаются RLC SDU переменных размеров, выравненные по байтам, т.е. количество разрядов которых кратно 8;
• RLC PDU формируются только тогда, когда возможность передачи подтверждена нижним уровнем (т.е. MAC), после этого происходит доставка на нижний уровень.

RLC PDU может быть RLC PDU данных или RLC PDU управления. RLC PDU данных используются объектами TM RLC, UM RLC и AM RLC для передачи PDU на верхние уровни. RLC PDU управления используются объектами AM RLC для выполнения процедур ARQ.

RLC PDU — это битовая строка, выравненная по байтам, т.е. количество разрядов которой кратно 8. Порядок следования байтов каждого поля параметра в PDU MAC является прямым, т.е. от старшего разряда к младшему.

RLC PDU для объекта TM RLC состоит только из поля данных и не включает заголовков RLC (см. рисунок 21).

Рисунок 21 — RLC PDU для объекта TM RLC

RLC PDU для объекта UM RLC состоит из поля данных и заголовка UMD PDU. Заголовок UMD PDU включает фиксированную и расширенную части. Длина фиксированной части равна одному байту. Пример UMD PDU с фиксированной частью заголовка представлен на рисунке 22.

Рисунок 22 — RLC PDU для объекта UM RLC с фиксированной частью заголовка UMD PDU

RLC PDU для объекта AM RLC состоит из поля данных и заголовка AMD PDU. Заголовок AMD PDU включает фиксированную и расширенную части. Пример AMD PDU с фиксированной частью заголовка представлен на рисунке 23.

Рисунок 23 — RLC PDU для объекта AM RLC с фиксированной частью заголовка AMD PDU

7.6 Уровень PDCP

PDCP уровень обеспечивает [10]:

• передачу данных UP;
• передачу данных CP;
• сжатие заголовка;
• сжатие данных uplink-канала;
• контроль целостности;
• взаимодействие (сервисы) с верхними уровнями (передача данных UP, CP, сжатие заголовка и данных, контроль целостности);
• взаимодействие (сервисы) с нижними уровнями (сервисы успешной/неподтвержденной передачи данных, последовательная доставка, отбрасывание дубликатов).

При использовании CP CIoT EPS оптимизации до момента активации механизмов безопасности уровень PDCP исключается из стека протоколов.

Возможная структура уровня PDCP представлена на рисунке 24.

Рисунок 24 — Структура уровня PDCP

PDCP PDU и PDCP SDU — это битовые строки, выравненные по байтам, т.е. количество разрядов которых кратно 8. Порядок следования байтов каждого поля параметра является прямым, т.е. от старшего разряда к младшему. Максимальный поддерживаемый размер PDCP PDU и PDCP SDU составляет 1600 октетов.

На рисунке 25 представлен формат PDCP PDU данных.

Рисунок 25 — PDCP PDU

Описание объекта PDCP представлено на рисунке 26.

Рисунок 26 — Объект PDCP

7.7 Уровень RRC

RRC-уровень обеспечивает [11]:

• трансляцию системной информации, относящейся к уровню NAS;
• трансляцию системной информации, относящейся к уровню AS;
• пейджинг;
• установление, поддержание и освобождение RRC-соединения;
• функции безопасности, включая управление ключами;
• функции управления QoS;
• прямую передачу сообщений NAS в/из NAS из/в UE;
• взаимодействие (сервисы) с верхними уровнями (трансляция управляющей информации и данных позиционирования, получение уведомлений, передача выделенной управляющей информации);
• взаимодействие (сервисы) с нижними уровнями (проверка целостности, передача данных с поддержкой сегментации и конкатенации).

Модель состояний уровня RRC приведена на рисунке 27 [11].

Состояния RRC включают в себя следующие состояния:

• RRC_IDLE (ожидание);
• RRC_CONNECTED (соединение).

В состоянии RRC-IDLE абонентское устройство:

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

В состоянии RRC-CONNECTED абонентское устройство:

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

Рисунок 27 — Модель состояний уровня RRC

• мониторит канал управления NPDCCH;
• выполняет прием/передачу данных.

На уровне RRC применяются процедуры, относящиеся к системной информации, управлению соединением, измерениям, общей обработке ошибок и SC-PTM. Помимо указанных, применяются также следующие процедуры:

а) DL information transfer;

б) UL information transfer;

в) UE Capability transfer;

г) UE information (не применимо для UE, поддерживающих только CP CIoT EPS optimization);

д) PUR Configuration Request;

е) Neighbour Relation Reporting for SON ANR in NB-IoT.

Системная информация разделена на блоки MIB и SIB, включая MasterInformationBlock-NB, MasterInformationBlock-TDD-NB и SystemInformationBlockTypeX-NB.

MasterInformationBlock-NB (MIB-NB) и MasterInformationBlock-TDD-NB (MIB-TDD-NB) используют фиксированное расписание с периодичностью 640 мс и повторениями в пределах 640 мс. Передача данных организуется в восьми независимо декодируемых блоках длительностью 80 мс. SystemInformationBlockType1-NB (SIB1-NB) использует фиксированное расписание с периодичностью 2560 мс.

Процедуры управления RRC соединением включают:

а) paging;

б) RRC connection establishment;

в) RRC connection resume (не применимо для UE, поддерживающих только CP CIoT EPS optimisation);

г) Initial security activation (не применимо для UE, поддерживающих только CP CIoT EPS optimisation);

д) RRC connection reconfiguration (не применимо для UE, поддерживающих только CP CIoT EPS optimisation);

е) RRC connection re-establishment;

ж) RRC connection release;

и) RRC connection release requested by upper layers;

к) Radio resource configuration;

л) Radio link failure related actions;

м) UE actions upon leaving RRC_CONNECTED;

н) Action upon receiving PUR release request;

п) Unified Access Control.

8 Режимы энергосбережения NB-IoT

8.1 Режим энергосбережения PSM

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

Абонентское устройство активирует режим PSM путем запроса значения времени активности во время процедуры регистрации Attach и TAU/RAU с передачей значений двух таймеров T3412-Extended и T3324. Если сеть поддерживает режим PSM и принимает, что абонентское устройство использует режим PSM, то сеть подтверждает использование режима PSM путем назначения значения времени активности. При определении значения времени активности сеть учитывает значение, запрашиваемое абонентским устройством, максимальное время ответа, а также локальную конфигурацию MME/SGSN. При необходимости изменить значение времени активности, например при изменении условий, абонентское устройство делает запрос желаемого значения в процедуре TAU/RAU.

Находясь в режиме PSM, устройство периодически инициирует процедуру актуализации TAU (Tracking Area Update) для того, чтобы сообщить сети о своей доступности и обновить местоположение. Обновление местоположения может быть важно для подвижных устройств. Частота процедуры TAU задается таймером T3412-Extended, максимальное значение которого составляет 35 712 000 с (приблизительно 413 дней).

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

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

Временная диаграмма режима энергосбережения PSM представлена на рисунке 28.

Рисунок 28 — Временная диаграмма режима энергосбережения PSM

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

Абонентское устройство находится в режиме PSM до события, инициируемого абонентским устройством (например, RAU/TAU, исходящие данные мобильной станции или отключение).

Если абонентское устройство выполняет какую-либо периодическую передачу данных по uplink-каналу с периодичностью, аналогичной значению таймера TAU/RAU, рекомендуется увеличить значение таймера TAU/RAU, чтобы избежать увеличение энергопотребления.

8.2 Расширенный режим прерывистого приема eDRX

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

Для согласования использования режима eDRX абонентское устройство запрашивает параметры eDRX во время процедуры регистрации и процедуры RAU/TAU. SGSN/MME может отклонить или принять запрос абонентского устройства на включение eDRX. При принятии eDRX, SGSN/MME на основе политики оператора и значений длины цикла eDRX в данных HSS (при наличии) может предоставить значения параметров eDRX, отличные от запрашиваемых абонентским устройством. В этом случае абонентское устройство должно использовать eDRX с принятыми параметрами eDRX. Если абонентское устройство не получило параметры eDRX в принятом сообщении в результате того, что SGSN/MME отклонил запрос или SGSN/MME не поддерживает eDRX, то абонентское устройство должно применить обычный режим прерывистого приема DRX.

Если абонентское устройство запрашивает одновременное включение режимов PSM и eDRX, то SGSN/MME может:

а) Включить только режим PSM, т.е. не принимать запрос на eDRX.

б) Включить только режим eDRX, т.е. не принимать запрос на PSM.

в) Включить как режим PSM (т.е. указать время активности), так и режим eDRX (т.е. указать параметры eDRX).

Решение по запросу одновременного включения режимов PSM и eDRX зависит от реализации, локальной конфигурации и другой информации, доступной в SGSN/MME. Для одновременного включения режимов PSM и eDRX время активности режима PSM должно превышать значение цикла eDRX (см. 7.1). Выбранный метод используется до следующей процедуры регистрации или процедуры RAU/TAU, после чего решение может быть обновлено.

Примечание - Для снижения энергопотребления таймер повторения процедуры TAU должен быть дольше, чем цикл eDRX.

Таймер TeDRX запускается в сети и на абонентском устройстве при соответственно передаче и приеме сообщения Attach Accept или RAU Accept, в котором предоставлены параметры eDRX. Таким образом, Tref в сети соответствует моменту, когда отправляется сообщение Accept RAU, а на абонентском устройстве — моменту, когда принимается соответствующее сообщение Accept.

Таймер TeDRX поддерживается и используется только тогда, когда процедура регистрации Attach или RAU успешно выполнена, и не зависит от состояния PMM абонентского устройства, т.е. переходы между состоянием idle и состоянием connected не влияют на таймер TeDRX.

Для повышения надежности пейджинга, например, во избежание пропусков сообщений из-за повторного выбора соты или из-за несовершенной синхронизации параметра Tref между абонентским устройством и SGSN, используется время окна передачи пейджинга TPTW. После окончания цикла eDRX абонентское устройство слушает сеть в течение времени окна передачи пейджинга PTW (см. рисунок 29). Во время PTW абонентское устройство слушает сеть с использованием параметров обычного режима DRX (TDTX), таким образом за указанное время предоставляется несколько возможностей для пейджинга. Информация для применения PTW предоставляется абонентскому устройству при согласовании eDRX.

Рисунок 29 — Циклы расширенного режима прерывистого приема eDRX

Допустимые значения длительности цикла eDRX представлены в таблице 16 [12].

Таблица 16

Значения длительности цикла eDRX

Допустимые значения длительности окна передачи пейджинга PTW представлены в таблице 17 [12].

Таблица 17

Значения длительности окна передачи пейджинга PTW

9 Расширение возможностей NB-IoT

9.1 Интеграция в 5G

Общие требования к технологии 5G затрагивают три основных варианта использования [13] - [15] и 3GPP [16]:

• мобильный IoT/массовый IoT/LPWA: улучшенное покрытие сети, длительный срок службы устройств и высокая плотность соединений;
• критически важные коммуникации: высокопроизводительный, сверхнадежный IIoT с низкой задержкой и критически важные приложения (критический IoT, URLLC);
• улучшенная мобильная широкополосная связь: повышенная производительность и более удобный доступ пользователей к мультимедийному контенту для коммуникации, ориентированной на человека.

3GPP включил технологию NB-IoT в часть семейства стандартов 5G, т.е. развитие 5G проводится в том числе путем использования NB-IoT как части спецификаций 5G. Размещение канала NB-IoT предусмотрено непосредственно в полосе частот 5G аналогично технологии LTE (см. рисунок 30) [17].

Рисунок 30 — Размещение канала NB-IoT в полосе частот LTE и 5G

Внутриполосная работа NB-IoT в пределах полосы пропускания несущей 5G NR достигается путем применения:

• модуляции и структуры кадра технологии 5G, совместимой с NB-IoT [17];
• дуплексной частотной конфигурации 5G, позволяющей выравнивать сетки поднесущих 5G и NB-IoT [18];
• поддержки конфигурации «прямой совместимости» [19].

Архитектура NB-IoT в сети 5G представлена на рисунке 31 [20].

Рисунок 31 — Архитектура NB-IoT в сети 5G

На рисунке 31 указаны следующие основные программные модули и сетевые функции:

• базовая станция gNB;
• функция управления доступом и мобильностью AMF (Access and Mobility Management Function);
• функция управления сессиями SMF (Session Management Function);
• функция передачи данных пользователей UPF (User Plane Function);
• модуль управления данными пользователей UDM (Unified Data Management);
• функция управления политиками PCF (Policy Control Function);
• функция обеспечения взаимодействия с внешними приложениями NEF (Network Exposure Function);
• прикладная функция AF (Application Function).

9.2 Интеграция в NTN

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

Интеграция NB-IoT в NTN позволяет реализовать бесшовный переход связи между NTN-сетью и наземной сетью.

Схема NTN-связи представлена на рисунке 32 [21].

Рисунок 32 — Схема NTN-связи

Диапазоны рабочих частот NTN downlink- и uplink-каналов для функционирования NB-IoT приведены в таблице 18 [21].

Таблица 18

Диапазоны рабочих частот NTN downlink- и uplink-каналов для NB-IoT

3GPP разделяет спутники по типу орбит [22]:

• LEO (Low-Earth Orbit) — спутники на низкой орбите с высотой от 300 км до 2000 км;
• MEO (Medium-Earth Orbit) — спутники на средней орбите с высотой от 8000 км до 20 000 км;
• GEO (Geostationary Earth Orbit) — спутники на геостационарной орбите с высотой 35 786 км.

Расстояние от абонентского устройства до спутника является гораздо большим по сравнению со сценарием наземных сетей, что обуславливает задержки распространения сигнала. В таблице 19 приведены максимальные задержки распространения сигнала по радиолинии «телефон — спутник — наземный шлюз» для разных орбит спутника [22].

Таблица 19

Максимальные задержки распространения сигнала для разных орбит спутника

Для компенсации задержек распространения сигнала предназначен механизм синхронизации Timing Advance (TA).

Полная задержка распространения сигнала от шлюза до телефона TAfull равна сумме задержек, вводимых сервисной (TAUE) и фидерной (TAcommon) линиями (см. рисунок 33):

TAfull = TAUE + TAcommon.

Рисунок 33 — Задержка распространения сигнала в NTN-сети

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

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

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

Полученные задержки учитываются механизмом компенсации TA. Для синхронизации uplink-канала перед выполнением произвольного доступа абонентское устройство должно автономно предварительно компенсировать временной сдвиг и доплеровский сдвиг частоты, принимая в расчет общие параметры TA, позицию абонентского устройства и позицию спутника через информацию об эфемеридах. В режиме подключения абонентское устройство должно непрерывно обновлять временной сдвиг и предварительную компенсацию частоты. При этом абонентское устройство не проводит определение GNSS и не выполняет передачи данных из-за устаревшей информации об эфемеридах, общих параметрах TA или GNSS на основе таймеров. В режиме соединения, при наличии устаревшей информации об эфемеридах и общих параметрах TA, абонентское устройство повторно получает передаваемые параметры, при устаревшем положении GNSS абонентское устройство переходит в режим ожидания. Абонентские устройства могут сообщать о временном сдвиге при первоначальном доступе или в режиме соединения. В режиме подключения поддерживается триггерная передача параметров TA.

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

Приложение А (справочное)

ОТРАСЛЕВОЕ ПРИМЕНЕНИЕ ТЕХНОЛОГИИ NB-IoT

А.1 Критерии выбора технологии NB-IoT

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

Сеть NB-IoT имеет существенное преимущество по отношению к сетям 2G/3G/4G в части зоны покрытия и проникновения сигнала в труднодоступные места (например, подвалы и помещения с коммуникациями в зданиях). Преимущество обеспечивается более помехоустойчивыми узкополосными сигналами, а также встроенным механизмом переповтора передаваемых пакетов данных.

Основные критерии выбора технологии NB-IoT:

• наличие сети доступа на территории Российской Федерации;
• отсутствие внутрисетевого роуминга;
• энергоэффективность абонентского устройства: работа устройства от одного комплекта батарей — длительный срок (до 10 лет);
• надежность передачи данных;
• подключение большого числа устройств в одной локации;
• низкая стоимость устройства;
• расширенная зона покрытия и глубокое проникновение сигнала в труднодоступные места (например, подвалы, колодцы, технические помещения);
• допустимость низких скоростей и задержек передачи данных.

А.2 Отрасли применения технологии

Примеры использования систем NB-IoT в различных отраслях экономики представлены в таблице А.1.

Таблица А.1

Отрасли применения технологии NB-IoT

Примеры оборудования с реализацией технологии NB-IoT представлены в таблице А.2.

Таблица А.2

Примеры оборудования с реализацией технологии NB-IoT

А.3 Характеристики передачи данных в сети NB-IoT

Максимальная скорость передачи данных в сети NB-IoT, достижимая при идеальных условиях радиоприема, при монопольном использовании абонентом всех ресурсов соты, с учетом реализации всех механизмов оптимизации, указана в таблице А.3.

Таблица А.3

Максимальные скорости передачи данных

Рекомендуемые модели передачи сообщений для абонентского оборудования приведены в таблице А.4 [23].

Таблица А.4

Рекомендуемые модели передачи сообщений для абонентского оборудования в сети NB-IoT

Рекомендации для разработки устройств и реализации приложений представлены в [24].

Приложение Б (справочное)

ПРИМЕР ЗНАКА, ПОДТВЕРЖДАЮЩЕГО КОРРЕКТНОСТЬ ИСПОЛЬЗОВАНИЯ УСТРОЙСТВА NB-IoT В ВЫБРАННОМ СЦЕНАРИИ ПРИМЕНЕНИЯ

Рисунок Б.1 — Пример знака, подтверждающего корректность использования устройства NB-IoT в выбранном сценарии применения

БИБЛИОГРАФИЯ