Device to Cloud Getting Started Onboard UDP Devices Setup BC660K-GL Development Board

Introduction

This chapter describes how to set up the Quectel BC660K-GL development board for Device to Cloud UDP communication.

  1. Access the dev kit from your computer.
  2. Attach to the NB-IoT network.
  3. Send and receive UDP data.

All useful resources

Use these resources together with the command examples on this page:

ResourceLink
Quectel BC660K-GL product pageBC660K-GL NB2
D2C UDP endpoint and onboarding flowUDP Step by Step
UDP device provisioning APIOnboard UDP devices
UDP uplink/downlink API detailsSend and receive IoT data

Setup the Device

Access DevKit from your Computer

This section describes two common device types and provides a short, vendor-agnostic quick-start checklist that applies to both categories. The goal is to give a single, consistent onboarding flow for devices that use AT commands to connect to the NB‑IoT network.

  • Device types

    • Module (embedded modem): a standalone modem module mounted on your custom board. Typically requires a USB‑UART bridge or an external MCU to provide power and a serial connection.
    • Dev kit / evaluation board: an adapter or development board that exposes the modem via a USB‑serial interface. Dev kits are convenient for testing but behave like a module from the network’s perspective.

  • Common preparation checklist (applies to both types)

    1. Hardware: attach the antenna and insert a Device to Cloud SIM card before powering the device. Please contact D2C support to get a SIM card.
    2. Connect serial console: use the board’s USB cable or a USB‑UART adapter to open a serial console. Configuration of your serial console depends on the module. Please consult the user manual of your module. Baudrate of Quectel BC660K-GL: 115200. On Linux the device usually appears as /dev/ttyUSB0 (or /dev/ttyACM0), on Windows install the USB‑UART driver if required.
    3. Permissions (Linux): if you cannot open the serial device, add your user to the dialout group:
    $ sudo usermod -a -G dialout $USER
  1. Open terminal program (screen, picocom, minicom, PuTTY):
    $ screen /dev/ttyUSB0 115200
  1. Power on the device and observe the boot console. A short boot banner or ROM messages are normal.

Query device information

# Check that modem respond on serial terminal
> AT
< OK

# Disable auto‑sleep so the console stays responsive:
> AT+QSCLK=0
< OK

# Enable command echo to simplify interactive work:
> ATE1
< OK

# Read basic device information and IMEI (used for registration and troubleshooting):
> ATI
< Quectel_Ltd
< Quectel_BC660K-GL
< Revision: BC660KGLAAR01XXX
< OK

# Get IMEI
> AT+CGSN=1
< +CGSN: 999907050041452
< OK

Please make sure that you use urn:gsma:imei:999907050041452 as the nodeID in your device provisioning request. Replace the IMEI with the IMEI of your device.

Attach to NB-IoT Network

After console access works, configure your network parameters (band, APN, optional operator), restart the module, and verify IP assignment.

Setup network configuration

# Restart the module so settings take effect
> AT+QRST=1
< OK
< RDY

# Deactivate auto-sleep
> AT+QSCLK=0
< OK

# Optional: disable power save mode
> AT+CPSMS=0
< OK

# Enable command echo
> ATE1
< OK

# Disable UE functionality (turn off radio) before changing some settings
> AT+CFUN=0
< OK

# Enable signaling connection status
> AT+CSCON=1
< OK

# Set default APN (generic placeholder)
> AT+QCGDEFCONT="IP","<your-apn-here>"
< OK

# Set Device to Cloud APN (Telekom)
> AT+QCGDEFCONT="IP","DEVICE-TO-CLOUD.IOT.TELEKOM.DE"
< OK

# Optionally set operator manually (example: Telekom Germany)
> AT+COPS=1,2,"26201"
< OK

# Optionally Set mobile operation band (example for Telekom Germany NB-IoT)
> AT+QBAND=1,8
< OK

# Enable UE functionality (turn on radio)
> AT+CFUN=1
< OK
< +CPIN: READY
< +CEREG: 2
< +CSCON: 1
< +IP: 10.32.129.20
< +CEREG: 1
< +CSCON: 0
# When CEREG return status code 1 and you see an IP address the module has successfully connected with the network


# Optionally, verify assigned IP address
> AT+CGPADDR?
< +CGPADDR: 0,"10.32.129.20"
< +CGPADDR: 1
< +CGPADDR: 2

Send and receive UDP

# Resolve hostname to IP (Device to Cloud APN)
> AT+QIDNSGIP=0,"udp.d2c.iot.telekom.de"
< +CSCON: 1
< +QIDNSGIP: 0,1,0
< +QIDNSGIP: 172.27.130.100
< +CSCON: 0

# Configure payload format (text mode)
> AT+QICFG="dataformat",0,0
< OK

# Show remote address on receive URCs
> AT+QICFG="showRA",1
< OK

# Open UDP socket service (context 0, socket 0, local port 1234)
> AT+QIOPEN=0,0,"UDP SERVICE","10.32.129.20",1,1234,1
< OK
< +QIOPEN: 0,0

# Query socket state
> AT+QISTATE=1,0
< +QISTATE: 0,"UDP SERVICE","10.32.129.20",15501,1234,2,0,1

# Send UDP payload to D2C endpoint
# Start typing what you want to send after you executed the command
# Press Ctrl+Z on your keyboard the send the data to the server
# The text that you wrote on the serial terminal is not shown
> AT+QISEND=0,"udp.d2c.iot.telekom.de",15501
>
< OK
< SEND OK

# Close socket
> AT+QICLOSE=0
< OK

Send and Receive via UDP

Preliminary work

Before testing UDP send/receive, make sure you have:

  • Registered the device with the correct nodeID / IMEI mapping in D2C.
  • Attached to the network and obtained an IP address.
  • Opened a UDP socket to the D2C endpoint.

This section shows what happens on the modem side when uplink and downlink messages are exchanged with the platform.

Uplink (device → platform): When the modem sends data to the D2C UDP endpoint, the platform receives and stores the data as a received-msg content instance in DMO.

Downlink (platform → device): When a downlink message is created in the outgoing-msg container, the platform delivers it to the modem. The delivery timing depends on the queuing mode.

Receiving downlink messages — queuing disabled

When an outgoing-msg is created without queuing (or with queuing:disabled):

{
  "m2m:cin": {
    "con": "Hello 12"
  }
}

The data is not immediately received by the modem. The platform forwards the message right away, but the mobile network can only deliver it when the modem switches from idle mode to connected mode. How long and how often the modem switches depends on the modem and network configuration.

Modem output:

< +CSCON: 1
< +CSCON: 0
< +CSCON: 1
< +QIURC: "recv",0,8,"172.27.130.100",15501,"Hello 30"
< +QIURC: "recv",0,8,"172.27.130.100",15501,"Hello 31"
< +QIURC: "recv",0,8,"172.27.130.100",15501,"Hello 32"
< +CSCON: 0

Receiving downlink messages — queuing enabled

When an outgoing-msg is created with queuing:enabled:

{
  "m2m:cin": {
    "con": "Hello 10",
    "lbl": ["queuing:enabled"]
  }
}

The platform holds the message until the device sends an uplink datagram. The queued data is then received immediately after the modem sends data to the server:

Modem output:

> AT+QISEND=0,"udp.d2c.iot.telekom.de",15501
< >
< OK
< SEND OK
< +CSCON: 1
< +QIURC: "recv",0,8,"172.27.130.100",15501,"Hello 10"
< +QIURC: "recv",0,8,"172.27.130.100",15501,"Hello 11"
< +QIURC: "recv",0,8,"172.27.130.100",15501,"Hello 12"
< +CSCON: 0
Important:
With queuing enabled, the platform holds all pending messages until the device sends an uplink datagram. At that point, queued messages are delivered in order (oldest first) with a fixed 1-second interval between them.

Next step

Use the API to onboard your UDP devices to Device to Cloud.