Dragino LearnDragino Learn
  • LoRaWAN

    • What is LoRaWAN?
    • Benefits of LoRa Technology and LoRaWAN
    • Understanding the Difference Between the LoRaWAN Network Server and Application Server
    • LoRaWAN 1.0.4
    • Regional Parameters
    • End Device Activation
    • Device Classes
    • Message Types
    • Radio Propergation
    • Security
    • Security Mechanisms
    • Spreading Factors
    • Adaptive Data Rate (ADR)
    • LoRaWAN Relay (Based on TS011-1.0.1)
    • LoRaWAN Roaming
    • LoRaWAN Roaming in Practice: Asset Tracking and Wildlife Tracking Use Cases
    • Understanding Firmware Updates Over The Air in LoRaWAN
    • Glossary
    • Use Cases
      • LC01
        • Smart Irrigation
        • LC01 ThingsBoard Integration
      • LHT65N-VIB
        • Monitoring Vibration Anomalies of an Electric Motor Pump
      • Cattle Tracking
      • Asset Tracking and Logistics Monitoring
      • Smart Utilities
  • NB-IoT

    • What is NB-IoT?
    • Prerequisites
    • SIM Cards
    • Frequency Bands
    • Power Saving Modes in NB-IoT
    • NB-IoT Network Architecture
    • NB-IoT Application Layer and Cloud Integration
  • LTE-M

    • What is LTE-M?
    • LTE-M Architecture
    • LTE-M Communication Process
    • Power Saving Mechanisms in LTE-M
    • Mobility and Handover in LTE-M
    • Security and Authentication in LTE-M
    • Data Transmission Procedures
    • Industry Use Cases and Future Trends
    • LTE-M Challenges and Network Limitations

NB-IoT Application Layer and Cloud Integration

Narrowband IoT (NB-IoT) devices operate within cellular networks and are designed to transmit small amounts of data efficiently over long distances. Once a device connects to the network and sends its data, that information must be transmitted to a cloud platform or an application server for processing, visualization, and analysis. This step happens at the application layer, where protocols such as MQTT and CoAP play a key role in enabling seamless communication between NB-IoT devices and cloud platforms like AWS IoT Core, ThingsBoard, or HiveMQ.

Understanding the Application Layer

In the NB-IoT architecture, the application layer sits on top of the transport and network layers. Its primary function is to define how data is structured, transmitted, and interpreted between devices and cloud applications.

Unlike traditional TCP/IP-based systems, NB-IoT typically relies on lightweight, message-oriented protocols optimized for constrained devices and low-bandwidth connections. These protocols reduce overhead, minimize energy consumption, and improve reliability over cellular links.

Common IoT Protocols: MQTT and CoAP

MQTT (Message Queuing Telemetry Transport)

MQTT is one of the most popular application-layer protocols for IoT due to its simplicity and efficiency. It follows a publish/subscribe model and operates over TCP/IP. The three main components in MQTT communication are:

  • Publisher – The NB-IoT device that sends data (for example, temperature readings).
  • Broker – The intermediary server that receives messages and distributes them to clients who subscribe to specific topics.
  • Subscriber – The client (often a cloud service or dashboard) that receives messages from the broker.

An NB-IoT device might publish a JSON payload such as:

{ "device_id": "nb12345", "temperature": 22.5, "humidity": 58 }

This message could be sent to the topic sensors/environment on the MQTT broker. The broker then forwards it to any application subscribed to that topic.

Advantages of MQTT for NB-IoT:

  • Small data packets (minimal header overhead)
  • Retained messages and Quality of Service (QoS) levels
  • Easy integration with cloud brokers (HiveMQ, AWS IoT, Eclipse Mosquitto)
  • Works well with persistent cellular connections

CoAP (Constrained Application Protocol)

CoAP is a lightweight, RESTful protocol designed specifically for constrained devices. It operates over UDP, which makes it faster and more energy-efficient than TCP in many NB-IoT use cases.

CoAP uses familiar HTTP-like methods such as GET, POST, PUT, and DELETE. However, its messages are compact and optimized for low-power devices.

Example CoAP request:

POST coap://myserver.com/sensors/data
Payload: {"device_id": "nb12345", "moisture": 45}

Advantages of CoAP for NB-IoT:

  • Low overhead, ideal for short, infrequent messages
  • Built-in reliability (confirmable and non-confirmable messages)
  • Easy mapping to HTTP for web integration
  • Suitable for battery-powered devices

Sending Sensor Data to the Cloud

Once the NB-IoT device gathers sensor data (temperature, humidity, or location), it must format the data and send it to the network’s packet gateway. From there, the data travels through the operator’s core network and reaches an application server or cloud platform.

The communication path typically looks like this:

To send data:

  1. The NB-IoT module initializes a connection using AT commands.
  2. The device establishes an MQTT or CoAP session.
  3. The sensor readings are encoded into JSON or binary format.
  4. The message is published to a cloud broker topic or endpoint.
  5. The cloud application processes and stores the data for visualization or analytics.

Integration Examples

NB-IoT with AWS IoT Core

AWS IoT Core offers a managed MQTT broker and secure communication using TLS. NB-IoT devices can connect directly to AWS IoT Core or through an intermediary server that translates NB-IoT payloads to MQTT messages.

Example flow:

  1. Device publishes data to the NB-IoT operator’s UDP endpoint.
  2. The operator forwards it to AWS IoT Core using MQTT over TLS.
  3. AWS IoT Core rules route the data to services like DynamoDB, S3, or AWS Lambda.
  4. Users visualize data in AWS QuickSight or a web dashboard.

NB-IoT with ThingsBoard

ThingsBoard supports both MQTT and CoAP protocols. Devices can directly publish sensor data to the ThingsBoard endpoint:

  • MQTT: mqtt.thingsboard.cloud
  • CoAP: coap.thingsboard.cloud

The dashboard provides real-time charts, device management, and alarms. Payloads are typically JSON-encoded for easy parsing.

NB-IoT with HiveMQ

HiveMQ is a high-performance MQTT broker known for scalability and real-time IoT data handling. It is well-suited for NB-IoT because it supports:

  • Secure MQTT over TLS
  • Advanced topic filtering
  • Persistent sessions for mobile devices

A device can connect using AT commands or an embedded MQTT client library to publish data periodically to HiveMQ Cloud.

Data Formats: JSON and Binary Payloads

NB-IoT devices must balance readability and bandwidth efficiency when sending data. Two common formats are:

JSON (JavaScript Object Notation)

Readable and easy to parse:

{
  "device_id": "nb6789",
  "pressure": 1013,
  "battery": 3.7
}

Advantages:

  • Human-readable
  • Widely supported by cloud services

Disadvantages:

  • Larger size compared to binary

Binary Payloads

Compact and faster to transmit:

0x01 0x3F 0x7A 0xB2

Advantages:

  • Minimal overhead, reduced data cost
  • Faster transmission

Disadvantages:

  • Harder to debug and requires encoding/decoding logic

Many developers choose JSON during testing and switch to binary for production to save power and bandwidth.

Summary

The application layer in NB-IoT is the bridge between the physical device and the digital world. Through lightweight protocols like MQTT and CoAP, NB-IoT devices can efficiently send sensor data to the cloud. Once in the cloud, platforms such as AWS IoT Core, ThingsBoard, and HiveMQ handle data ingestion, storage, and visualization.

A well-designed NB-IoT application layer focuses on:

  • Choosing the right protocol based on bandwidth and power constraints
  • Using compact yet meaningful data formats
  • Ensuring secure and reliable cloud integration

By mastering this layer, developers can build scalable, low-power IoT solutions that seamlessly connect field devices to powerful cloud analytics systems.

Prev
NB-IoT Network Architecture