Рассмотрим по шагам процедуру передачи M2M терминалом (M2M-UE) блока телеметрической информации посредством сети узкополосного интернета вещей – NB-IoT (Narrow Band Internet of Things).
Исходные данные:
- Конфигурационные параметры сети NB-IoT статичны и неизменны.
- M2M-UE уже зарегистрирован в сети NB-IoT и находится в режиме энергосбережения (PSM – Power Saving Mode). Состояние RRC – "приостановлено" (suspend) с сохранением во внутренней памяти текущего AS-контекста.
- M2M-UE находится в неизменном положении и в зоне действия одной и той же соты сети NB-IoT.
- Для повышения помехоустойчивости используются повторные передачи сообщений (ОДИН цикл передачи для CE_level-0, ДВА цикла передачи для CE_level-1 и ЧЕТЫРЕ цикла передачи для CE_level-2), при этом все сообщения успешно доставляются от передатчика получателю (отсутствуют HARQ NACK).
- Для передачи блока полезных данных используется оптимизация на уровне пользовательского трафика – User Plane CIoT EPS optimization.
- M2M-UE поддерживает передачу данных в ресусрных единицах (RU), содержащих несколько поднесущих (multi-tone).
Расчет времени передачи сообщения NB-IoT терминалом
Схематично взаимодействие M2M терминала (M2M-UE) с базовой станцией (eNB) показана на Рис. 1 и Рис. 2.
Рис. 1 (UL Data Transfer – Call Flow)
Рис. 2 (UL Data Transfer –энергопотребление)
Шаг-1 (выход из режима PSM)
M2M терминал (M2M-UE) в результате срабатывания внутреннего, либо внешнего события выходит из режима энергосбережения (PSM) и запускает процедуру передачи сообщения (шаги 2-10).
Шаг-2 (синхронизация)
На данном шаге M2M-UE выполняет повторную синхронизацию с фреймовой структурой сети, посредством приема первичного (Narrowband Primary Synchronization Signal – NPSS) и вторичного (Narrowband Secondary Synchronization Signal – NSSS) сигналов синхронизации.
NPSS транслируется в 5-ом субфрейме каждого радифрейма, NSSS транслируется в последнем (9-ом) субфрейме только четных радио-фреймов. При этом, в частотной области оба сигнала передаются на всех ресурсных элементах за исключением последнего, во временной – на всех символах, кроме первых 3-х. В качестве сигналов используются последовательности Задова-Чу.
Продолжительность процедуры синхронизации определяется уровнем радиосигнала, а также наличием интерференции. Результаты исследований приведены в [9] «R1-156009; Ericsson; Narrowband LTE – Synchronization Channel Design and Performance» – см.Табл. 1.
Табл. 1 (время синхронизации, мс)
Шаг-3 (прием информации мастер-блока)
Мастер блок (MIB-NB – Narrowband Master Information Block) имеет размер 34 бита и передается в широковещательном физическом канале (NPBCH – Narrowband Physical Broadcast Channel). После выполнения процедур вычисления и вставки CRC, канального кодирования, перемежения и выравнивания скорости) размер MIB достигает 1600 бит. Далее MIB разделяется на 8 независимых субблоков, длиной 200бит каждый. Первый субблок передается в 0-ом субфрейме радио-фрейма, для которого соблюдается условие SFN mod 64 = 0 и затем повторяется в 7-ми последующих радио-фреймах. Далее аналогичным образом идет передача субблоков со 2-го по 8-ой. Таким образом, каждый субблок передается 8 раз в течение 80 мс, а весь блок MIB – в течение 640мс.
Согласно исследованиям, приведенным в [11] «R1-156013; Ericsson; Coverage analysis in stand-alone operation» для терминалов, находящихся в хороших (MCL=144dB) и нормальных (MCL=154dB) радиоусловиях, для декодирования MIB достаточным является прием одной копии каждого субблока. Для терминалов, находящихся в плохих радиоусловиях (MCL=164dB) для декодирования MIB потребуется прием 4-х копий каждого субблока – см. Табл. 2.
Табл. 2 (время приема информации мастер-блока)
Рис. 3
Шаг-4 (прием информации системных-блоков)
Учитывая, что конфигурационные параметры сети NB-IoT статичны, содержимое информации, передаваемое в системных блоках, является неизменным с момента предыдущего выхода M2M-UE в эфир, что индицируется полем MIB.systemInfoValueTag мастер блока. Следовательно, M2M терминал может повторно не принимать системные блоки.
Шаг-5 (передача преамбулы случайного доступа)
Для передачи преамбулы в рамках процедуры запроса доступа к сети связи используется канал NPRACH. Периодичность выделения ресурса для данного канала определяется политикой оператора и может составлять 40мс, 80мс, 160мс, 240мс, 320мс, 640мс, 1280мс и 2560мс. В соответствии с конфигурацией сети для каждого уровня качества радиопокрытия (CE-level_0, level_1 или level_2) M2M-UE для формирования символьной группы (symbol group) должен использовать один из 3-х возможных форматов преамбулы. Символьная группа содержит циклический префикс CP и последовательность из K идентичных символов – см. Рис. 4.
Рис. 4 (символьная группа)
Передача символьной группы осуществляется M2M терминалом G раз со скачками по частоте при каждой передаче – см. Рис. 5. По завершении первого сеанса передачи терминал, не дожидаясь ответа от сети, осуществляет повторные сеансы. В раках каждого повтора (по аналогии с первым сеансом) символьная группа передается G раз. Кол-во повторных передач для канала NPRACH определяется настройками сети и может составлять 1, 2, 4, 8, 16, 32, 64 или 128.
Рис. 5 (сеанс передачи символьной группы)
Сводная информация по доступным форматам преамбулы приведена в Табл. 3.
Табл. 3 (форматы преамбулы)
Согласно исследованиям, приведенным в [15] «Luca Feltrin, NarrowBand-IoT: A Survey on Downlink and Uplink Perspectives» для терминалов, находящихся в хороших радиоусловиях (MCL=-144dB) оптимальным является использование format-0 с одним сеансом передачи, в нормальных радиоусловиях (MCL=-154dB) – format 1 и 2 сеанса, в плохих радиоусловиях (MCL=-164dB) – format 1 и 4 сеанса – см. Рис. 6 и Табл. 4.
Рис. 6 (NPRACH)
Табл. 4 (время передачи преамбулы)
Шаг-6 (прием msg2)
M2M терминал принимает от сети сообщение msg2 (RAR отклик – см. Рис. 7), начиная с 3-го субфрейма после завершения передачи преамбулы и в течение окна приема (ra-ResponseWindowSize), определенного для соответствующего уровня качества радиопокрытия (CE level 0, level 1 и level 2). msg2 передается базовой станцией в канале NPDCCH. Длительность окна приема ra-ResponseWindowSize составляет от 1 до 10 периодов NPDCCH (в соответствии с политикой оператора связи), т.е. от 4мс до 22минут.
Рис. 7 (msg2)
Оценка времени приема сообщений msg2 для различных радиоусловий приведена в Табл. 5.
Табл. 5 (время приема msg2)
Шаг-7 (передача msg3)
Оценка времени передачи сообщения msg3 для различных радиоусловий приведена в Табл. 6.
Табл. 6 (передача msg3)
Шаг-8 (прием msg4)
Сообщение msg4 ожидается в течение действия таймера Contention Resolution Timer – от 1 до 64 NPDCCH периодов, т.е. от 4мс до 2,3часов. Получение сообщения msg4 включает в себя получение через NPDCCH команды выделения ресурса канала NPDSCH (DCI N1) и собственно получение самого сообщения. Факт получения сообщения msg4 M2M-UE подтверждает этикеткой HARQ ACK через канал NPUSCH Format 2. Оценка времени приема сообщений msg4 для различных радиоусловий приведена в Табл. 7.
Табл. 7 (прием msg4)
(1) – посредством DCI-N1 базовая станция (eNB) может передать HARQ-NACK, уведомляя M2M терминал (M2M-UE) о неуспешном приеме ранее отправленного терминалом сообщения и выделить M2M-UE ресурс NPUSCH для его повторной передачи, либо выделить M2M-UE ресурс NPUSCH для передачи нового сообщения.
(2) – указывается не реальное кол-во циклов передачи, совершаемое eNB, а усредненное кол-во, необходимое M2M терминалу для успешного декодирования переданного ему сообщения.
Шаг-9 (передача сообщения "rrcConnectionResumeComplete")
На данном шаге M2M-UE:
- осуществляет прием DCI-N0 (выделение ресурса NPUSCH – UL grant);
- передает сообщение "rrcConnectionResumeComplete".
Оценка времени передачи сообщения "rrcConnectionResumeComplete") для различных радиоусловий приведена в Табл. 8.
Табл. 8 (передача сообщения "rrcConnectionResumeComplete")
(2) – указывается не реальное кол-во циклов передачи, совершаемое eNB, а усредненное кол-во, необходимое M2M терминалу для успешного декодирования переданного ему сообщения.
В штатном режиме на данном шаге процедура случайного доступа заканчивается. В случае любых сбоев M2M терминал (M2M-UE) в период, не превышающий 9 минут, должен повторить попытку. Кол-во попыток доступа определяется политикой оператора и не превышает 10-ти. Далее – M2M-UE снижает класс радиопокрытия (CE level) и выполняет еще один цикл процедуры доступа.
Шаг-10 (передача блока полезной информации)
На данном шаге M2M-UE:
- осуществляет прием DCI-N0 (выделение ресурса NPUSCH – UL grant);
- формирует блок передаваемых данных и передает его через радиоэфир в рамках выделенного ресурса.
- получает от базовой станции отрицательное подтверждение получения переданного блока данных (HARQ NACK) если блок данных был получен неуспешно и описание ресурса для повторной передачи (UL-grant).
Табл. 9 (передача msg3 / прием msg4)
(2) – указывается не реальное кол-во циклов передачи, совершаемое eNB, а усредненное кол-во, необходимое M2M терминалу для успешного декодирования передаваемого ему сообщения.
Формирование блока передаваемых данных включает в себя (см. Рис. 8 и Табл. 10):
- формирование PDCP PDU;
- формирование RLC PDU (предполагаем, что используется режим прозрачной передачи RLC TM, не имеющий заголовка);
- формирование MAC PDU;
- добавление к блоку данных битов контрольной суммы (CRC);
- кодирование передаваемых данных посредством турбо кодера (turbo coder);
- выравнивание скорости (rate matching).
Рис. 8 (формирование блока полезной информации)
Табл. 10 (UL payload overhead)
Оценка времени передачи блока данных для различных радиоусловий и величины полезной нагрузки приведена в Табл. 11, Табл. 12 и Табл. 13.
Табл. 11 (ресурсная единица)
Табл. 12 (время передачи payload, 10байт)
Табл. 13 (время передачи payload, 100байт)
(3) – см. Table 16.5.1.2-2 рекомендации 3GPP TS 36.213
(4) – см. Table 16.5.1.1-2 рекомендации 3GPP TS 36.213
Итоговые данные по передаче сообщения M2M терминалом данных приведены в Табл. 14 и Табл. 15.
Табл. 14
(5) – оценка продолжительности ожидания M2M терминалом (в состоянии Idle) получения соответствующего сообщения от сети.
(6) – оценка продолжительности ожидания M2M терминалом (в состоянии Idle) момента начала выделенного ресурса для передачи соответствующего сообщения.
Табл. 15
Расчет энергопотребления NB-IoT терминала
Данные по энергопотреблению NB-IoT модема приведены в Табл. 16. Данные сформированы в соответствии с [8] «R1-156006, NB-IoT - Battery lifetime evaluation». При этом предполагается использование источника автономного электропитания с рабочим напряжением от 2.4В до 3.6В (номинальное напряжение 3.0В); энергопотребление в режиме передачи включает в себя энергопотребление внутренних цепей (90Вт) и энергопотребление усилителя мощности (КПД=44%).
Табл. 16 (энергопотребление NB-IoT модема)
В Табл. 17 приведены расчеты времени жизни АКБ, емкостью 2100мАч, для различных радиоусловий при интенсивности передачи 1 сообщение в час.
Табл. 17 (время жизни АКБ [лет] при интенсивности отправки 1msg/час)
[1] 3GPP TS 36.211: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation"
[2] 3GPP TS 36.212: "Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding".
[3] 3GPP TS 36.213: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures".
[4] 3GPP TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification".
[5] 3GPP TS 36.322: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification".
[6] 3GPP TS 36.323: "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) Specification".
[7] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification".
[8] R1-156006, "NB-IoT - Battery lifetime evaluation", Ericsson, ZTE, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia, Intel, Samsung, LGE.
[9] R1-156009, "Narrowband LTE – Synchronization Channel Design and Performance", Ericsson.
[10] R1-156011, "Narrowband LTE – Random Access Design", Ericsson.
[11] R1-156013, "Coverage analysis in stand-alone operation", Ericsson.
[12] R1-156525, "NB-IoT performance evaluation: Stand-alone operation", Intel Corporation.
[13] "CAT-M & NB-IoT Design and Conformance Test", JianHuaWu, Keysight Technologies.
[14] "Overview of Narrowband IoT in LTE Rel-13", Rapeepat Ratasuk, Nitin Mangalvedhe, Yanji Zhang, Michel Robert, Jussi-Pekka Koskinen Mobile Radio Research Lab, Nokia Bell Labs.
[15] "NarrowBand-IoT: A Survey on Downlink and Uplink Perspectives", Luca Feltrin, Galini Tsoukaneri, Massimo Condoluci, Member, IEEE, Chiara Buratti, Toktam Mahmoodi, Senior Member, IEEE, Mischa Dohler, Fellow, IEEE, and Roberto Verdone, Senior Member, IEEE.
