Impacto del modo ‘Non Internet Data Delivery’ en las comunicaciones IoT ante la llegada del 5G

Las tecnologías disponibles actualmente de manera mayoritaria para comunicar dispositivos IoT son Sigfox / LoRaWAN en banda no licenciada ISM y LTE Cat-M Cat-NB (NB-IoT) en banda licenciada. Como bien sabemos Sigfox y LoRaWAN no utilizan capa de transporte IP (Internet Protocol), sino que el paquete de datos transmitido por el dispositivo es identificado en la estación o estaciones base que lo reciben por un compacto identificador único del dispositivo, lo que permite guardar el dato en la BBDD a disposición del servicio IoT asociado. Las tecnologías bajo LTE (al igual que su predecesora GPRS) sin embargo transportan el dato utilizando protocolo IP. Esto da al dispositivo IoT mucha más versatilidad, pues tiene capacidad de direccionar el destino o destinos de sus envíos y elegir entre diversos protocolos de transporte como UDP, TCP e implementar seguridad estandarizada (DTLS, TLS, …). La versatilidad del protocolo IP sin embargo tiene su contrapartida, que se hace más relevante según empezamos a ver en el horizonte la llegada del 5G y su promesa de despliegues masivos de dispositivos. IP significa encapsular el dato (nuestra carga útil) en una trama con unas cabeceras que, resumiendo, están pensadas para un enrutamiento de los paquetes en la red global Internet. Lo cual en aplicaciones IoT donde prácticamente todos los paquetes enviados son de 10-20 bytes de carga útil, la sobrecarga que supone el protocolo IP/UDP es significativo. En este artículo revisamos la tecnología NIDD (Non Internet Data delivery) que está definida en el estándar 3GPP desde la Release 13 (con la primera especificación de NB-IoT), su potencial y los beneficios que puede ofrecer de cara a la llegada del 5G al IoT.

1.      Introducción

Entre las tecnologías LPWAN de espectro libre populares en Europa, Sigfox es la que introduce menos datos de cabecera, sólo 14 bytes adicionales a una carga útil de 12 bytes. LoRaWAN es mucho más complejo. La capacidad de una red LoRaWAN depende de la densidad de gateways disponibles en la red y los mecanismos de adaptación (ADR) que ajustan el data rate de manera adaptativa a través del factor de expansión (SF).

La característica que comparten ambas tecnologías es que sólo necesitan de que el dato del dispositivo llegue a la estación base o Gateway, desde donde, ya por protocolo IP, queda disponible para la plataforma IoT y aplicación de usuario. Por tanto, la información de enrutamiento que la trama ha de contener se reduce significativamente.

Por su parte, la tecnología NB-IoT, se especificó para acceso radio licenciado en la banda LTE en los 3GPP Release 13, 14 y 15, como alternativa a las tecnologías de acceso libre, y es la tecnología elegida para los servicios celulares de comunicaciones masivas de dispositivos IoT (mMTC) que se irá ampliando y mejorando en las siguientes Release del estándar 5G. Los principales proveedores de telefonía móvil están desplegando sus redes NB-IoT como solución de cobertura global para desplegar servicios de IoT masivos en todo el mundo. La especificación permite desplegar esta tecnología “in band”, utilizando recursos de las portadoras LTE, reutilizando bloques no usados como las portadoras de guarda de la banda LTE o stand-alone, usando de manera dedicada frecuencias que se venían usando para servicios GSM, como se puede ver en la figura siguiente.

Además, ya en la 3GPP Release 13, se definió para NB-IoT un modo de transmisión sin hacer uso de protocolo IP, NIDD (Non IP Data Delivery). Este método de encapsular el dato, permite optimizar y ampliar la transmisión de carga útil en la trama eliminando la necesidad de dedicar decenas de bytes de las cabeceras en el protocolo IP, y los protocolos de aplicación TCP o UDP. El método NIDD, por tanto, reduce la sobrecarga en la gestión de las tramas que se necesita para mantener los grupos de IPs estáticas en los dispositivos y amplia la carga útil de cada trama en contraposición al modo de transporte usado mayoritariamente para NB-IoT a través de UDP sobre IP.

En definitiva, ofrece una arquitectura que se aproxima a Sigfox y LoRaWAN, esto es, el dato ha de llegar a la infraestructura propietaria del operador, a partir de ahí el usuario ha de recuperar el mismo desde la plataforma que le ofrece el operador. El dato no llega directamente a la plataforma IoT del usuario. Esta simplificación de la capacidad de enrutado del dispositivo IoT permite reducir el tamaño de la cabecera de la trama, mejorando la eficiencia de la transmisión.

2.      Diferencias a nivel de trama, tiempo de transmisión y capacidad

Si atendemos a las estructuras de trama de las diferentes tecnologías y los tiempos de transmisión de cada una de ellas, podemos inferir el impacto que tiene el uso de las cabeceras en los diferentes protocolos frente a la capacidad de transmisión de datos útiles y los tiempos de transmisión que se manejan para estos datos en cada una de las tres tecnologías.

–Sigfox

En la estructura de trama para el UpLink que se puede ver en la figura 2 vemos que, por cada 12 bytes máximos de carga útil, la trama necesita invertir de 12 a 14 bytes entre cabecera y bytes de verificación y autentificación (si el payload es menor de 12 bytes, el espacio libre se rellena por protocolo para mantener el tamaño de las tramas uniforme).

El tiempo de transmisión requerido para cada trama, depende de la región y del payload que se necesite transmitir (SigFox tiene predefinidos unas longitudes de datos de transmisión, y si la longitud de los datos que se van a enviar cae entre esas dos longitudes, el protocolo rellena ese espacio libre hasta completar la longitud predefinida.En Europa, RC1, se puede ver en la tabla siguiente que para una longitud predefinida de 12 bytes de información (por encima de 8 bytes, se rellena hasta completar los 12) se necesitan 2 segundos de transmisión (En Europa se han definido unas restricciones de uso que del ciclo de trabajo por hora a un 1%, que limita el número máximo de mensajes que se pueden enviar)

–LoRaWAN

LoRa es una tecnología que opera en espectro no licenciado, por debajo de 1GHz. LoRa es el protocolo que define el PHY, la capa física, y LoRaWAN define el protocolo de comunicaciones y la arquitectura del sistema. LoRaWAN usa una arquitectura en estrella en la que los gateways actúan como relay entre los dispositivos IoT y el servidor de red (se pueden hacer despliegue tipo mesh incrementando el alcance y aumentando el tamaño de las celdas a las que da servicio cada gateway.

El tamaño máximo de la carga útil depende del data rate (DR) usado para transmitir los datos en los uplinks (LoRaWAN usa una modulación Chirp Spread Spectrum, CSS, y según el factor de expansión espectral (FS) que use, es más o menos eficiente en cuanto a bit rate). La carga útil va desde los 11 bytes para un DR0 hasta los 242 bytes para diferentes data rate en función de la frecuencia del canal por mensaje y factor de expansión.

Respecto a la trama MAC, esta se compone de una cabecera (MHDR), la carga útil (MACPayload) y 4 bytes de integridad (MIC). La cabecera MHDR está formada por 1 byte que especifica el tipo de mensaje y la versión del formato de la trama con la que ha sido codificada y el MACPayload a su vez incluye una cabedera de trama (FHDR), que contiene de 7 a 23 bytes, un campo de puerto opcional de 1 byte y los Nbytes de la carga útil en el campo FRMPayload, que dependen, como se ha indicado del DR y por tanto del factor de dispersión usado. En resumen, LoRaWAN usa entre 12 y 29 bytes para conformar la cabecera de los mensajes de la trama, aunque por el contrario su capacidad transportar carga útil es mayor y dinámica.

El tiempo de transmisión requerido para enviar cada trama depende del factor de expansión utilizado. La modulación CSS, consiste en expandir la secuencia de bits en el espectro, multiplicando la señal con unas secuencias de bits con una tasa binaria muy superior para crear señales con componentes frecuenciales más elevadas (se denominan chips para distinguirlos de los bits originales no codificados).

El tiempo que permanece el dato en el aire depende, como hemos dicho del factor de expansión y de la longitud del enlace. Si se consideran, por ejemplo, el envío de un mensaje de 11 bytes de payload para una transmisión uplink en un canal de 125kHz, se puede estimar el tiempo que se tarda en enviar el mensaje en la figura siguiente:

–NB-IoT (LTE CatNB)

La pila de protocolos usado por la tecnología es fundamentalmente la pila utilizada en las comunicaciones LTE reducida y mejorada para evitar en la mayor medida posible el overhead. Esto es así que se considera a la pila de protocolo de NB-IoT como un nuevo interface de comunicaciones móviles dentro del estándar LTE. Además, el 5G como evolución del LTE considera del mismo modo al NB-IoT como una de las tecnologías que están bajo el paraguas de la próxima generación de tecnologías de acceso móvil, categorizada dentro de  la categoría de comunicaciones masivas tipo máquina (mMTC).

NB-IoT, usa las mismas bandas de frecuencia LTE licenciadas. Un canal LTE dispone de 12 subportadoras de 15 kHz (180 kHZ) con modulación OFDM para las comunicaciones downlink y de 3,75 kHz o 15 kHz con modulación SC-FDMA para el uplink (el ancho de la subportadora lo selecciona la estación base de LTE, el eNB)

Esta tecnología permite el uso de tramas de datos con una longitud máxima del payload de hasta 1600 bytes, frente a los 243 bytes que permite LoRaWAN o los 12 bytes de Sigfox, multiplicando la capacidad y permitiendo su uso para todas aquellas aplicaciones IoT que necesitan enviar datos de gran tamaño. Además, es una tecnología que tiene mayor escalabilidad que sus competidoras y permite la conectividad de más de 100K dispositivos, mientras que Lora y Sigfox solo pueden llegar hasta los 50K dispositivos.

En el caso de una transmisión UDP sobre capa de red IP, el encapsulado del mensaje añade a la carga útil una cabecera que puede ir de 28 bytes mínimo a 68 bytes de longitud máxima (la cabecera IP va de 20 a 60 bytes mientras que la cabecera UDP añade 8 bytes extras). En aplicaciones donde el payload es elevado, el impacto de la cabecera IP/UDP no es significativo, pero en aquellas aplicaciones IoT donde el payload se acerca al tamaño de la propia cabecera, por ejemplo, el envío de un mensaje de 100 bytes puede implicar que en realidad se envíen 168 bytes, lo que supone invertir más de un 40% de los datos, en bytes con información de cabecera, implicando un overhead excesivo para mensajes de poca entidad.

Es por este motivo por el que, en la 3GPP Release 13, se introduce el encapsulado de datos sin añadir las cabeceras UDP IP, mediante el método NIDD (Non IP Data Delivery).

Este método optimiza el envío de datos evitando el overhead, con un coste añadido. Cuando se usan mensajes sin información IP/UDP, al no disponer de destino IP, puerto de destino o dirección de envío, queda bajo la responsabilidad de los Operadores de Telefonía Móvil, la identificación del mensaje, mantener la disponibilidad del mismo desde el momento en el que se almacena y tenerlo a disposición del destinatario.

Sin intención de profundizar en este artículo, en la arquitectura general para las redes LTE, el 3GPP especifica dos caminos para la conexión y envío de datos de los dispositivos en la red LTE:

1.Mediante una conexión PDN (Packet Data Network), en la que se le solicita la conexión a la red para el envío de datos al equipo IoT (User Equipment, UE)

2.Sin una conexión PDN: Es una mejora introducida por la 3GPP Release 13, para permitir que los UE que soportan CIoT (Cellular Internet of Things), permanezcan conectados sin necesidad de una conexión PDN, lo que permite a los dispositivos permanecer largos periodos de tiempo inactivos y transmitir solo en periodos de tiempo muy cortos.

Para los dispositivos que hacen uso de una conexión PDN con la red, la 3GPP Release 13 introduce dos opciones extras de conectividad para los dispositivos IoT usando el sistema EPS (Evolved Packet System) de la red, sin necesidad de usar cabeceras IP / UDP (NIDD):

1. Usando una optimización del Control Plane CIoT EPS

2. Usando una optimización del User Plane CIoT EPS

El mecanismo tradicional para transportar información en la red LTE ha sido el uso de IP sobre User Plane, pero para servicios, como el IoT, que transmiten ocasionalmente pequeñas cantidades de información, la utilización del Control Plane optimiza el consumo de energía debido a que la cantidad de señalización necesaria se ve muy reducida. Con la opción de Control Plane CIoT EPS, se plantean dos aproximaciones para solucionar el problema de que los dispositivos NIDD IoT no sean accesibles directamente a través de una dirección IP.

Por un lado, mediante la asignación de una IP al dispositivo IoT por el operador a través de un nodo intermedio que forma parte del core de la red móvil del operador, el PGW (Packet Data Network Gateway) y el envío de los datos NIDD como paquetes UDP a las plataformas IoT y viceversa (haciendo el PGW las veces de “enrutador” de los paquetes NIDD). Esto opción implica un riesgo de seguridad, ya que expone el PGW al exterior.

O una segunda aproximación, mediante la introducción de un nuevo elemento en la red LTE (ó 5G), el SCEF (Service Capability Exposure Function), que es un nodo securizado y pensado para hacer de interfaz entre el core de la red y el exterior de la red sin exponerlo a riesgos de seguridad. Esta última es la aproximación que, operadores como Vodafone, ven más viable.

El modo de funcionamiento sería, una vez el mensaje ha sido recibido por la red, que el SCEF se encargue de transportar el payload, encapsulándolo con una capa extra, NAS (Non-access stratum), generando unidades NAS PDUs (Protocol Data Units) para hacerlo accesible por la aplicación de destino (la plataforma IoT).

Por lo tanto, la transmisión de datos sobre User Plane en modo NIDD, hace uso de un túnel de datos no-IP que hace que sea transparente para la capa de aplicación. Para la plataforma IotT, los datos que se le envían sí tienen una IP asignada por un Nodo Gateway de la red, el C-SGN (CIoT Serving Gateway Node), que a su vez usa el SCEF de interfaz con el exterior, como se puede ver en la imagen siguiente:

NB-IoT al estar diseñado en la capa de transporte sobre el protocolo UDP no permite utilizar protocolos de aplicación como MQTT que se apoyan en el protocolo TCP. En cambio, sí que se puede utilizar el protocolo de transporte CoAP (Constrained Application Protocol) que está diseñado inicialmente sobre UDP. Este protocolo, sirve como base para implementar el protocolo de aplicación LWM2M (OMA Lightweight M2M), definido por la Open Mobile Alliance.

Ambos son los dos protocolos más apropiados para hacer uso de la tecnología NB-IoT.  En las figuras 13 y 14 se puede ver la estructura de la trama de datos en ambos protocolos (obviando la cabecera UDP/IP en el caso de usarse esa opción):

Hacer notar que CoAP proporciona seguridad en la capa de transporte a través del protocolo Datagram Transport Layer Security (DTLS) y mantiene un control del flujo de datos con el único requisito de que el mensaje de payload encaje en el datagrama del protocolo, para poder ser usado por cualquier tecnología que use este protocolo (como es NB-IoT NIDD o en la telefonía móvil, el SMS)

El protocolo LWM2M, por su parte, mejora CoAP añadiendo una capa donde se indican los path de las URIs y establece un modelo de representación del dato en los dispositivos, consiguiendo mayor eficiencia binaria optimizando el número de bytes usados para contener el payload del mensaje. En la siguiente imagen se puede ver como LWM2M mapea los campos a partir del mensaje CoAP:

Si analizamos el impacto que tiene el uso de estos protocolos de transporte y aplicación, con la opción NIDD, frente al protocolo CoAP sobre UDP, se puede estimar que el ahorro en bytes al eliminar las cabeceras IP puede llegar más allá de los 28 bytes en el envío de payload , como se puede ver en el ejemplo de la figura siguiente:

Si analizamos el coste en mensajes de protocolo y overhead para el envío del mismo paquete de datos con protocolo CoAP/LWM2M, tanto en modo UDP como en modo NIDD, vemos que en ambos casos es extremadamente ligero (Figura 17).

Se implementa un protocolo registro y desregistro del dispositivo con el servidor. Para este registro, LWM2M solo necesita del envío de dos mensajes de registro CoAP, y a partir de que se crea el registro, el servidor envía una petición para que comience el envío de mensajes de manera asíncrona por parte de los dispositivos. LWM2M ordena los envíos mediante un par de mensajes de confirmación (CoAP CON Notify y CoAP ACK, que, aunque son recomendables debido a que NB-IoT no previene la pérdida de paquetes, no son obligatorios y se podría por tanto prescindir de ellos reduciendo aún más el gasto de bytes en mensajes propios de protocolo).

Tanto CoAP como LWM2M , usan identificadores de recursos (URIs) y solo añaden 4 bytes de cabecera fija en los que se codifican los mensajes de los métodos GET, POST, PUT, DELETE, frente a los 28 bytes extra que serían necesarios si se implementase CoAP sobre IP/UDP.

3.      Impacto y relevancia del modo NIDD en las comunicaciones IoT

El modo NIDD introducido en 3GPP Release 13, hemos visto que reduce significativamente el overhead en los mensajes enviados en las redes IoT. Consideremos las futuras redes IoT extensas del orden de 90 o 100K dispositivos que se esperan una vez los operadores tengan desplegadas para la tecnología 5G para las comunicaciones masivas tipo máquina (mMTC), que se prevé que suponga el 50% del uso de las redes 5G en el mundo. Hemos visto que los bytes de overhead de ahorro en cada uno de los mensajes enviados a la red por cada uno de eso dispositivos puede llegar a tener un impacto significativo en el tiempo necesario para enviar el payload de cada dispositivo o lo que es lo mismo en el tiempo de ocupación del espectro. En el caso de payloads pequeños, del orden de 12 bytes o menos, esto implicaría directamente ahorros de consumo de energía en la transmisión por cada dispositivo IoT que podrían llegar a reducirse casi a un 30% del consumo para la transmisión respecto al modo NB-IoT UDP.

Se pueden encontrar algunos estudios comparativos de estas tecnologías. En NB-IoT la tasa de transferencia de datos es dinámica, pudiéndose llegar a los 21kbps con una sola portadora. Fijando la tasa en 6000 bps, considerando una cobertura del nodo IoT buena (con un link Budget de 154dB), se puede ver en la tabla siguiente que para el envío de la misma cantidad de información, el modo NB-IoT NIDD, reduce prácticamente a la mitad el tiempo de transmisión respecto al modo NB-IoT UDP, reduciendo el consumo y alargando sustancialmente la vida útil de la batería (ambos, frente a SigFox que se muestra mucho más exigente)

Con respecto a tecnologías no licenciadas como SigFox y Lora, en aplicaciones donde la longitud de los datos de la cabecera son superiores al payload del mensaje, como hemos planteado en el artículo, esta reducción de los datos enviados impactaría en el coste fijo de los datos consumidos por dispositivo a través de las redes 5G NB-IoT que tengan desplegadas los operadores de telefonía móvil, haciendo más atractiva la tecnología NB-IoT NIDD por permitir más capacidad, mayor número de dispositivos conectados y con un coste más ajustado del que tendría a través de conexiones NB-IoT sobre UDP.                                  

Estos beneficios del modo de operación NIDD del NB-IoT, son lo que han despertado el interés de fabricantes de chips y operadores, por las ventajas que ofrece frente a los modos de operación UDP del NB-IoT.

Operadores como Verizone, en EEUU, ya permiten las conexiones Non-IP PDN (conexiones NIDD) solo para dispositivos NB-IoT a través de una API de la compañía, ThingSpace, viendo como recae en el operador de telefonía móvil la responsabilidad de tener disponibles los paquetes de datos una vez los recibe y por tanto evidenciando la necesidad de adaptar su infraestructura para acoger este modo de trabajo. Es la red del operador la que gestiona los dispositivos que se van a conectar a la red, los activa, habilita los envíos de datos y deshabilita los dispositivos en la red en caso de ser necesario. En el caso de Verizon, incluso desarrollado ya planes de precios específicos para el uso de esta tecnología.

Uno de los mercados que va a marcar el ritmo del desarrollo de esta tecnología, es el mercado asiático.  El interés en el NIDD NB-IoT es creciente a raíz de que MediaTek, uno de los principales fabricantes de componentes para comunicaciones inalámbricas, anunciara en 2020 el lanzamiento de su SoC MT2625 NB-IoT R14, qué ha sido validado con el protocolo de aplicación LWM2M a través de NIDD en la red del operador Softbank Corp. en Japón, situando al operador a la vanguardia de esta tecnología.

En esta validación han participado, además, algunas de las empresas más importantes del ecosistema IoT, como son Microsoft Japan, Amazon Web Services (AWS), DK Corporation, Affirmed Networks and SB Cloud, y prevén que con la implementación del NIDD en el país nipón, se popularice drásticamente.

TST-Japan (filial de TST para el desarrollo del IoT en Japón), ya está trabajando con el operador Softbank en el desarrollo de dispositivos comerciales basados IoT que implementan el protocolo LWM2M a través de NIDD. Es un proyecto pionero en el país y también a nivel global, fiel a la política de TST de trabajar con los operadores desde los primeros pilotos de cada novedad tecnológica.

En contraposición con Japón y EE.UU., este modo de funcionamiento NIDD del estándar NB-IoT aún no está disponible en España, ni en Europa.

4.      Conclusiones

Las tecnologías de acceso a las redes 5G para dispositivos IoT de diferente naturaleza y diferentes necesidades, que se desarrollen en los próximos años, van a marcar el paso para la expansión y el crecimiento del uso de dispositivos IoT a nivel global.

Si se comparan las diferentes tecnologías IoT, atendiendo a parámetros como el overhead, la tasa máxima de transferencia de datos, el payload máximo que es capaz de transportar por trama y el tiempo que tarda en el envío de los datos (sin repeticiones), en la tabla siguiente se pueden ver la performance de cada una de las tecnologías analizadas frente al NIDD.

A pesar de que aparentemente el NB-IoT está en clara ventaja frente a las dos tecnologías no licenciadas, SigFox y Lora, habría que realizar un análisis más exhaustivo en términos de consumo de energía de cada una de ellas, donde entran en juego las características y los protocolos de envío de datos, los consumos de energía durante los periodos de reposo, el registro en la red etc, propios de cada tecnología, donde aparentemente, SigFox y Lora podrían seguir siendo más ventajosas que el NB-IoT para el envío de datos de pequeño tamaño.

Aun así, la aparición de los primeros SoC NIDD NB-IoT y las experiencias de operadores como Verizon en EEUU y sobre todo la de Softbank en Japón, muestran el camino que va a ser necesario recorrer en Europa y España en los próximos años, para desarrollar estas tecnologías y seguir siendo una potencia mundial en tecnologías IoT.

Francisco Alcalá es CEO y Miguel Ángel López es director de Innovación de TST Sistemas.

REFERENCIAS

[1] Kais Mekkia, Eddy Bajica, Frederic Chaxela, Fernand Meyerb. (2018). A comparative study of LPWAN technologies for large-scale IoT deployment. (a)Research Centre for Automatic Control of Nancy, Campus Sciences, BP 70239, Vandoeuvre, 54506, France; (b)OKKO SAS, 34 Rue Nationale, Puttelange-aux-Lacs, 57510, France.

[2] Rashmi Sharan Sinha, Yiqiao Wei, Seung-Hoon Hwang. A survey on LPWA technology: LoRa and NB-IoT. (2017). Division of Electronics and Electrical Engineering, Dongguk University-Seoul, Republic of Korea.

[3] Sergey Slovetskiy, (T-Mobile), Poornima Magadevan (T-Mobile), Yun Zhang (Ericsson), Sandeep Akhouri (Ericsson). Lightweight M2M 1.1: Managing Non-IP Devices in Cellular IoT Networks. October 2018.

[4] Anna Larmo, Antti Ratilainen, Juha Saarinen. Impact of CoAP and MQTT on NB-IoT. System Performance. (1) Ericsson Research, 02420 Jorvas, Finland; (2) Ukkoverkot, 00180 Helsinki, Finland. 2 Ukkoverkot, 00180 Helsinki, Finland.

[5] Martin Stusek, Krystof Zeman, Pavel Masek, Jindriska Sedova, and Jiri Hosek. IoT Protocols for Low-power Massive IoT: A Communication Perspective. (1) Department of Telecommunications, Brno University of Technology, Brno, Czech Republic, (2)Faculty of Economics and Administration, Masaryk University, Brno, Czech Republic.

[6] Jonathan de Carvalho Silva, Joel J. P. C. Rodrigues, Antonio M. Alberti, Petar Solic, Andre L. L. Aquino. “LoRaWAN – A Low Power WAN Protocol for Internet of Things: a Review and Opportunities”. (1) National Institute of Telecommunications (Inatel), Santa Rita do Sapucaí – MG, Brazil; (2) Instituto de Telecomunicacoes, Portugal; (3)University of Fortaleza (UNIFOR), Fortaleza – CE, Brazil; (4)University of Split, Split, Croatia;  (5)Computer Institute, Federal University of Alagoas, Maceió – AL, Brazil

[7]    Lluís Casals, Bernat Mir, Rafael Vidal and Carles Gomez. “Modeling the Energy Performance of LoRaWAN”. Department of Network Engineering, Universitat Politècnica de Catalunya/Fundació i2Cat, C/Esteve Terradas, 7, 08860 Castelldefels, Spain; lluis.casals@entel.upc.edu (L.C.); bernatmir13@gmail.com (B.M.); rafael.vidal@entel.upc.edu (R.V.)

[8] RFC760. STANDARD INTERNET PROTOCOL. January 1980

[9] RFC 768. USER DATAGRAM PROTOCOL. August 1980

[10] RFC 7252. THE CONSTRAINED APPLICATION PROTOCOL (CoAP). June 2014

[11] RFC 7959 BLOCK-WISE TRANSFER IN CoAP. August 2016

[12] LoRa™ Modulation Basics. AN1200.22. SEMTECH. May 2015.

[13] Sigfox device cookbook: communication configuration. SigFox. (2018)

[14] IoT Solution Developer Protocols Guide. T-Mobile

[15] Lightweight Machine to Machine Technical Specification: Core. Open Mobile Alliance. June 2018.

[16] Lightweight Machine to Machine Technical Specification: Transport Bindings. Open Mobile Alliance. June 2018.

[17] https://omaspecworks.org/managing_non-ip_devices_in_cellular_iot_networks/

[18] https://tools.ietf.org/id/draft-ietf-core-coap-04.xml#rfc.section.2.1

[19] https://onlinelibrary.wiley.com/doi/full/10.1002/itl2.74

[20] https://lora-developers.semtech.com/library/tech-papers-and-guides/understanding-adr

[21] https://lora-developers.semtech.com/library/tech-papers-and-guides/lora-and-lorawan/

[22] https://avbentem.github.io/airtime-calculator/ttn/eu868

[23] https://www.u-blox.com/sites/default/files/SARA-N2-Application-Development_AppNote_%28UBX-16017368%29.pdf

[24] https://www.gsma.com/iot/wp-content/uploads/2019/07/201906-GSMA-NB-IoT-Deployment-Guide-v3.pdf

[25] https://en.wikipedia.org/wiki/Constrained_Application_Protocol

[26] https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2018/pdf/BRKSPM-2007.pdf

[27] https://www.tdx.cat/bitstream/handle/10803/7040/04AMCA04de15.pdf

[28] https://techradar.softwareag.com/technology/5g-scef/

[29] https://www.linkedin.com/pulse/sigfox-versus-nb-iot-power-consumption-harald-naumann/

[30] http://www.gsm-modem.de/M2M/m2m-faq/comparison-energy-consumption-lpwan-sigfox-lorawan-nb-iot/

[31] https://thingspace.verizon.com/documentation/apis/connectivity-management/working-with-verizon/about-non-ip-data-delivery.html