Now that you have a PicoLTE IoT kit, it is time to set it up.
This page contains all the necessary information to understand and setup the NB-IoT End-to-End Data Delivery demonstrator with the PicoLTE and C030 application board. It should be read carefully before using the system. The configuration files and all related tools and embedded firmware should be stored for future reference. The page will provide a walkthrough of the startup procedure for both the LTE NB-IoT EPS or NIDD and the C030 device. The goal is to perform an End-to-End communication between a typical IoT application using different sensors on the C030 board and publishing those measurements to a cloud-based service using Non-IP Data path between the eNodeB and the device.
*Refer to your Nutaq provided set up manual for more details.
Don’t have your own PicoLTE yet?
Setting up your PicoLTE
The PicoLTE is an LTE network-in-a-box providing an LTE evolved packet system (EPS). It can run both eNodeB to provide E-UTRAN radio access and EPC to handle control and data planes of LTE User equipments. The main purpose of this application note is to illustrate how to setup a NB-IoT LTE/4G network to publish the measurement of sensors to a cloud service.
The eNodeB will provide NB-IoT E-UTRAN radio access to the NB-IoT modem of the C030 application board.
The PicoLTE is used to provide NB-IoT connectivity (both eNodeB and EPC) while Ublox’s C030 is used in Non-IP mode to exchange Non-IP Date with remote application servers. C030 is connected to PicoLTE over RF cables (figure 1).
In this NB-IoT End-to-End scenario, only MO NonIP data is considered. The data measured by sensors on the C030 — GPS, temperature, humidity, acceleration — will be published by the NB-IoT N211 modem to the cloud through the PicoLTE EPS.
This demonstrator can be replicated to perform conducted or Over-The-Air communication. Figure 1 illustrates a conducted setup where C030 is connected to PicoLTE over RF cables. OTA setup must be installed in anechoic chamber to avoid interference with operators. OTA setup is not part of the scope of this application note.
Figure 1 — PicoLTE and C030 setup to test End-to-End Data Delivery
A typical conducted setup including RF modules such as RF power splitter/combine, circulator and attenuator is depicted in figure 2. It is possible to test multiple devices simultaneously depending on the number of channels of the power splitter combiner. One should notice that the RF devices are frequency dependent and should use the suitable and Power splitter/combiner, circulator and attenuator to the operating carrier frequency. C030-N211 can operate at band 8 or 20. Thus, the selected RF devices must support those bands.
Figure 2 — PicoLTE and C030 conducted setup
PicoLTE eNodeB Configuration.
For demonstration purpose, the PicoLTE is running NB-IoT cell in standalone mode at 801 MHz (LTE band 20) as depicted in figure 2. The configuration files are provided in the directory /opt/nutaq/picolte/examples/eps/ciot/nb-iot/nb1/standalone/enb.
The main configuration file is enb.cfg located in the “./enb” directory. It includes the following configuration files:
Configuration file |
Description |
|---|---|
| enb.cfg | This is the main configuration file. It is JASON-based syntax. |
| sib1.asn | System Information Block 1 (SIB1) configuration file. It is ASN-based syntax. |
| sib2_nb.asn | System Information Block 2 (SIB2) configuration file for LTE Narrow Band scenario. It is ASN-based syntax. |
| drb_nb.asn | Data Radio Bearer (DRB) configuration file for LTE Narrow Band scenario. It is JSON-based syntax. |
| rf_driver.cfg | This is the configuration file of the Radio Head and DUC/DDC logic implemented on the FPGA. It is JSON-based syntax. |
| rf_front_end.cfg |
Look up table of amplifier gains. The suitable gains are selected based on the required output power defined in the configuration file rf_driver.cfg. NB: Do not edit rf_front_end.cfg configuration file. |
Table 1 — eNodeB’s configuration files
The eNodeB is connected to the EPC and supports different PDNs including the Non-IP PDN to handle Non-IP connectivity and NIDD both for MO and MT cases.
Setting the DL/UL central frequencies
As the DL and UL central frequencies in LTE are related, one can use the DL EARFCN to setup the operating carrier frequencies both for the Uplink and Down Link. The DL EARFCN for standard LTE bands can be configured in the enb.cfg configuration file located in the folder ./enb. The parameter’s name is dl_earfcn.
Parameter |
Description |
|---|---|
| dl_earfcn |
Downlink EARFCN Example: dl_earfcn: 6250,/*DL: 801 MHz and UL: 842 MHz (Band 20) */ |
Table 2 — Setting DL EARFCN
Figure 3 — Spectrum of the NB-IoT cell at 801 MHz (LTE Band 20)
There are many web tools that can be used to find the suitable EARFCN depending on your setup. The following one proposes the computation of both carrier frequency and ARFCNs: http://niviuk.free.fr/lte_band.php.
Setting the Output Power
The output Power can be configured in the rf_driver.cfg configuration file located in the folder ./enb. The parameter’s name is power_output.
Parameter |
Description |
|---|---|
| power_output |
Power output (dBm). For the radio640, the range is between -39 (minimum value) and -8 (maximum value). Example: power_output:-10,/*Power output [dBm] set to -10 dBm*/ |
Table 3 — Setting RF Output Power
Setting the RX Gain
The receiving gain can be configured in the rf_driver.cfg configuration file located in the folder ./enb. The parameter’s name is rx_front_end_gain.
Parameter |
Description |
|---|---|
| power_output |
Rx Variable Gain Amplifier in dB. the values for the radio640 depends on the bands used. 0dB is the maximum value and 70dB is the minimum value. Example: rx_front_end_gain: 30,/*Set Total RX Gain to 30 dB*/ |
Table 4 — Setting Receiving Gain
Setting the RF port
The RF port can be configured in the rf_driver.cfg configuration file located in the folder ./enb. The parameters names are downlink_rf_port_x and upink_rf_port_x, where x is the cell index. The following table specifies the suitable RF ports for one cell scenario. In the case of multiple cells please refer to PicoLTE’s User Guide for more details about multiple cell configuration.
Parameter |
Description |
Physical RF Port |
|---|---|---|
| downlink_rf_port_0 | Cells indexes assignment to physical RF ports.
Example: downlink_rf_port_0: 1,/*One Cell transmitting on RF port TRX1*/ |
Transmission mode 1
Transmission mode 2
|
| uplink_rf_port_0 | Cells indexes assignment to physical RF ports
Example: uplink_rf_port_0: 1,/*One Cell receiving on RF port RX1*/ |
Transmission mode 1
Transmission mode 2
|
Table 5 — Setting RF ports
Enable or Disable Scrambling
The scrambling here refers to NPBCH/BCCH changes as specified in 3GPP release 13.5. The parameter’s name is rel13_5 and can be configured in the enb.cfg configuration file.
Parameter |
Description |
|---|---|
| rel13_5 | Release 13.5 NPBCH/BCCH scrambling changes.
Example: rel13_5: true,/* release 13.4 NPMCH/BCCH scrambling changes */ |
Table 6 — Setting NPBCH/BCCH Scrambling
To tune any other parameter not listed on this page, please read the description of this parameter in the configuration parameters User Guide and contact support@nutaq.com for any help.
PicoLTE EPC Configuration
For demonstration purpose, the PicoLTE is running an EPC configuration allowing the management of NB-IoT devices. The configuration files are provided in the directory /opt/nutaq/picolte/examples/eps/ciot/nb-iot/nb1/standalone/epc.
The main configuration file is mme.cfg located in the “./epc” directory. It might include the UE Data Base if it is not already defined there using the JSON List of Objects: ue_db. Every object of this list defines a subscriber which is defined by the USIM information.
Configuration file |
Description |
|---|---|
| mme.cfg | This is the main configuration file. It is JASON-based syntax. |
| ue_db-ims.cfg | User Equipment Data Base. It is a JASON-based syntax. |
Table 7 — EPC’s configuration files
Enable or Disable Control Plane CIoT Optimization
Control Plane Cellular IoT EPS optimization is a feature of CIoT. It can be enabled using the parameter cp_ciot_opt in the configuration file mme.cfg. Notice that current NB-IoT modems including N211 on the C030 application boards support only CP-CIoT EPS optimization and not the DRB optimization. Therefore, the cp_ciot_opt must be set to true.
Parameters |
Description |
|---|---|
| cp_ciot_opt |
Control Plane Cellular IoT EPS optimization support Example: cp_ciot_opt: true,/*Enable Control Plane Cellular IoT EPS optimization */ |
Table 8 — Setting Control Plane CIoT Optimization
PDN Definition
One or multiple PDNs can be defined in the mme.cfg configuration file using the pdn_list. It is a JSON list of one or more PDNs objects. The following table summarize the key parameters of a PDN object.
Parameter |
Description |
|---|---|
| pdn_type |
Select the PDN type. The available PDN types are ipv4, ipv6, ipv4v6, non-ip (default = ipv4) |
| access_point_name | Set the Access Point Name |
| first_ip_addr | First available IPv4 address |
| last_ip_addr | Last available IPv4 address |
| ip_addr_shift | The allocated IPv4 addresses are allocated starting from first_ip_addr with a difference of 2^ip_addr_shift. Hence last_ip_addr – first_ip_addr must be a multiple of 2^ip_addr_shift. This options is useful in case of inter_UE communication to ensure that the IPv4 address of a given UE is the only one in its netmask. |
| p_cscf_addr | IPv4 or IPv6 addresses of the PCSCF servers (VoLTE). |
| dns_addr | IPv4 or IPv6 addresses of the DNS servers. |
| first_ipv6_prefix | First available global IPv6 prefix used in Router Advertisement message sent to the UE (only the high 8 bytes of the IPv6 address are meaningful). Note that the selected prefix will also be used as the interface identifier sent in NAS signalling. |
| last_ipv6_prefix | Last available global IPv6 prefix used in Router Advertisement message sent to the UE (only the high 8 bytes of the IPv6 address are meaningful). Note that the selected prefix will also be used as the interface identifier sent in NAS signalling. |
| erabs |
Array of objects. Each element defines an E-RAB (E-UTRAN Radio Access Bearer) associated to the PDN. The first E-RAB is the default radio bearer and must always be present. The additional E-RABs are dedicated radio bearers and must include a Traffic Flow Template (TFT) unless they are defined as UE initiated. qci – QoS Class Identifier of the E-RAB. priority_level – Priority level. pre_emption_capability – Enumeration: shall_not_trigger_pre_emption or may_trigger_pre_emption. pre_emption_vulnerability – Enumeration: not_pre_emptable or pre_emptable. |
|
Example NonIP |
{ pdn_type: “non-ip”, // access_point_name: “internet”, //first_ip_addr: “192.168.3.2”, //last_ip_addr: “192.168.3.254”, //ip_addr_shift: 2, /* difference between allocated IP addresses is 4 */ //p_cscf_addr: [“192.168.3.1”], //dns_addr: “8.8.8.8”, /* Google DNS address */ //erabs: [{ qci: 9, //priority_level: 15, //pre_emption_capability: “shall_not_trigger_pre_emption”, //pre_emption_vulnerability: “not_pre_emptable”, //},], }, |
Table 9 — Public Data Network parameters
NonIP PDN
The EPC can handle:
- Non-IP PDN connection establishment
- MO Non-IP data
- MT Non-IP data
- Non-IP Events
The EPC provides an API that can be used by an external service to register to Non-IP events and forward Non-IP Data both on the Uplink and Downlink side between the remote application server and the EPC. The EPC handles Non-IP traffic to and from the NB-IoT devices.
A Non-IP PDN must be configured to enable NonIP Data Delivery. We just need to set the pdn_type parameter of a PDN object to “non-ip”.
UE Data Base
The UE Data base can be defined in the mme.cfg configuration file or it can be defined in a separate file and included in the mme.cfg configuration file using the directive include (include “ue_db-ims.cfg“,). The parameter ue_db is a JSON array of objects that must be used to configure the user database. Each element of this array is an entry for one user. The following properties are available:
Parameter |
Description |
|---|---|
| sim_algo |
Optional enumeration, xor, milenage or tuak (default = xor). Set the SIM authentication algorithm. Note: test USIM cards use the XOR algorithm. |
| imsi | Set the IMSI. |
| amf | Set the Authentication Management Field. |
| sqn | Set the initial sequence number. For the XOR algorithm, the actual value does not matter. For the Milenage or TUAK algorithm, a sequence number resynchronization is initiated if the sequence number does not match the one store in the USIM. |
| K | Set the user secret key (as a 16-byte hexadecimal string). |
| multi_sim | If set to true, allow several UEs to have the same IMSI (useful when using several identical test SIM cards in different UEs at the same time). They are distinguished with their IMEI. Note: it is only allowed with the XOR authentication algorithm. |
| Example |
ue_db: [ { sim_algo: “xor”, /* USIM authentication algorithm: xor, milenage or tuak */ imsi: “001010123456789”, /* Anritsu Test USIM */ amf: 0x9001, /* Authentication Management Field */ sqn: “000000000000”, /* Sequence Number */ K: “00112233445566778899aabbccddeeff”, /* Anritsu Test USIM */ multi_sim: true, }, /* Add new entries for each IMSI/K */ ], |
Table 10 — Setting the UE Database
End-to-End Non-IP versus IP Data Path
The eNodeB is connected to the EPC and supports different PDNs including an IPv4 type PDN. This PDN allows to bring internet connectivity to the registered devices using the APN “internet”. It basically allows end-to-end connectivity and data delivery in both direction Mobile Originating and Mobile Terminating cases.
Once the devices register to the network and establish EPS bearer towards the NonIP PDN, they can connect to remote servers on the cloud. All the NonIP traffic in both direction (MO or MT) travel on the red coloured data path.
Figure 4 — IP Data Path for End-to-End IoT use cases
The NIDD Server handles Non-IP Data delivery to and from the C030 NB-IoT device. It registers to Non-IP events managed by the EPC and process Non-IP Data transmitted by the UEs to the remote application server. If a Non-IP event is generated by the EPC, the NIDD Server acquires the data transmitted by the UEs and forward them to the remote application server immediately. For MT Non-IP Data, the NIDD server forwards the data send by the AS to the EPC in Non-IP packets to the C030 NB-IoT device identified by a unique ID which is IMSI of its USIM card.
C030 NB-IoT Application Board
The u-blox C030 application board is an out-of-the-box rapid prototyping solution for IoT applications supporting new LPWA (low power wide area) cellular technologies, such as NB-IoT, and existing 2G/3G networks. The board is powered by an integrated, ARM Mbed compatible Cortex-M4 host CPU with 1 MB FLASH and 256 kB RAM, leaving ample space for software development and debugging.
C030-N211 application board is an Mbed-enabled NB-IoT starter kit with SARA-N211 (NB-IoT), MAX-M8C, and Cortex M4 CPU. It allows:
- Quick prototyping with Arm Mbed on integrated host CPU
- Simple testing of positioning applications with integrated GNSS
- Ideal for ultra-low power designs and compact form factors
- Easily capture sensor data with Arduino shields
N211 Modem’s firmware
N211 has currently two firmware version used basically to test the following applications:
- End-to-End LWM2M/CoAP
- NonIP Data Delivery
- UDP Echo
Table 11 summarizes the available firmware of N211 modem and the list of application we tested so far with C030 application board.
C030 N211-FWPKG |
C030 STM32-Mbed |
Sensors |
|
|---|---|---|---|
| LWM2M/CoAP | 06.57, A01.02 | Mbed program generated by uArgus (Windows Mbed toolchain) | Temperature |
| NonIP Data Delivery | 06.57, A01.02 | c030-3LED_ModemAccess_ProductionFirmware.bin | Data generated on the Host PC STM32 By-pass (3LED ModemAccess Production FW) |
| UDP Echo | 06.57, A07.03 | c030-3LED_ModemAccess_ProductionFirmware.bin | Data generated on the Host PC STM32 By-pass (3LED ModemAccess Production FW) |
Table 11 — N211 firmware vs tested applications
To upgrade or downgrade the firmware of N211 modem, contact Ublox to get the software for that.
Ubidots Cloud Service
For demonstration purpose we propose to use Ubidots cloud server as it is simple and easy to setup. For this you need to load the Bypass firmware on the application MCU, create your account on Ubidots portal, get your token then you should be able to replicate the Non-IP demonstrator and test both UL and DL NonIP Data Delivery.
Device Registration
Register a new device
Ubidots provides Web portal to register and manage IoT devices. One can register a new device using the IMEI of the NB-IoT modem on C030 and can assign a name to this new device.
NonIP Data Delivery Management
On the C030 we generate random data varying between 34 and 45 to simulate body temperature. The data are transmitted in Non-IP mode to the EPC over NAS. A websocket-based server is running on the PicoLTE to handle NIDD. When a Non-IP event is generated by the EPC, the NIDD server captures the Non-IP packets and forward them to a remote application server. We used Ubidots for demonstration purpose. The user can connect to Ubidots and display in a user friendly graphical way the evolution of the transmitted temperature in real time as illustrated in Figure 5.
Figure 5 — Data published on Ubidots cloud server
The list of the registered devices can be displayed on this web page. The status of the device is indicated. If the device is registered and active, a button is available to open the its web page and display the reported and published measurement to this cloud server.
The following python scripts are provided both for the device and the network to generate and handle NonIP Data Delivery to the cloud:
- Device C030-N211: /opt/nutaq/picolte/utilities/ue/ublox/n2xx/N211-Ubidots.py
-
- This python script configures the NB-IoT N211 modem into Non-IP mode, generates data and transmits them to the network. We use the AT command +CGDCONT to define the Packet Data Protocol context. Here is an example how to use this PDP AT command: AT+CGDCONT=1,”NONIP”,”nonip”.
-
-
- “NONIP” specifies the Non-IP PDP context
-
-
-
- “nonip” is the APN defined in the Non-IP PDN in the MME configuration file.
-
-
- We use the AT command “AT+CSODCP” to send the generated data. Sending Non-IP Data is managed by the “sendNIPData” function.
- Network:
-
- MO NonIP Data Delivery: /opt/nutaq/picolte/utilities/ue/ublox/n2xx/dl-nidd.py
-
-
- This script registers to non-ip events. As soon as Non-IP Data are available on the MME, we extract them from the message and we forward the data to the remote cloud server Ubidots.
-
-
- MT NonIP Data Delivery: /opt/nutaq/picolte/utilities/ue/ublox/n2xx/ul-nidd.py
-
-
- This script generates data and send them to the device using Non-IP mode. The Non-IP data are displayed on the device as soon as they received. This script will be updated to manage an end to end MT Non-IP Data. The Data will be basically send from a remote service on the cloud and this utility will forward them in Non-IP mode to the suitable device.
-