Development Overview

Last Updated on : 2020-09-10 09:55:42download

Background information

Narrow Band Internet of Things (NB-IoT) is built in a cellular mobile communication network to realize thing-to-thing communication and thing-to-person communication. NB-IoT focuses on the low-power wide-area (LPWA) Internet of Things (IoT) market, and is an emerging technology that can be widely used around the world.

NB-IoT network consumes only about 180 kHz bandwidth, and uses the license band. It can coexist with the existing network in three deployment modes, including in-band, protection band or independent carrier wave. NB-IoT network can be directly deployed in a GSM network, a UMTS network or an LTE network to reduce the deployment cost and realize a smooth upgrade.

NB-IoT features

  • Low power consumption

    The installation environment of IoT applications, such as intelligent meter reading, environmental monitoring, and intelligent agriculture, has no power supply and requires batteries. In order to meet the requirement of 5 to 10 years of battery life, the introduction of PSM and eDRX technology to NB-IoT network greatly reduces the terminal power consumption. The device is in extremely low power consumption status during most of the life cycle, thus ensuring the service life of the battery.

  • Low cost

    NB-IoT terminal adopts narrow-band technology with less complex baseband. It only uses single antenna, adopts half-duplex mode and low-cost RF modules. Most unnecessary functions, such as SRVCC, IMS, emergency call and other functions, can be cut. At the same time, the SoC built-in power amplifier (PA) is adopted, so that the requirements for the terminal flash storage space, terminal size, and terminal radio frequency are reduced. The terminal cost of the NB-IoT is greatly reduced.

  • Large connection

    NB-IoT has 50 to 100 times higher uplink capacity improvement (specific service model) than 2G, 3G and 4G. NB-IoT provides 50 to 100 times of access compared with existing wireless technology. A single community can support 50,000 users.

  • Broad signal coverage

    With 164 dB maximum coupling loss (MCL), NB-IoT improves 20 dB gain compared with GPRS. NB-IoT provides better coverage in underground garages, basements, underground pipelines and other places where signals are difficult to reach.

FeatureNB technical featureValue range
Small amount of dataLimited air interface resources (180 kHz), suitable for small data communication50 bytes to 200 bytes is appropriate, the smaller the better
Low frequency, long periodMost terminals should be in hibernation status for a long time, with low frequency of reporting dataReport on a daily basis, and 1 to 2 times a day is appropriate. High-frequency reporting (such as every 30 minutes) occupies a large amount of network capacity. The higher the reporting frequency, the greater the impact on network capacity.
Low power consumptionPSM mode of NB network has the lowest power consumptionThe first-choice for applications that are sensitive to power consumption
Low mobilityNB is suitable for slow movementMoving speed is less than 30 km/h
Deep coverageNB coverage capacity is relatively goodSupport scene coverage such as basement
Low rateThe theoretical upstream peak rate is 15.6 Kbit/s and the theoretical downstream peak rate is 21.25 Kbit/sLarge-rate bandwidth type service cannot be carried by NB

NB-IoT network architecture

Development Overview

NB-IoT network consists of NB-IoT terminal, NB-IoT base station, NB-IoT Packet Core Network, IoT connection management platform, and industry application server. The access network architecture of NB-IoT is the same as that of LTE.

NB-IoT power saving mode

The development of NB-IoT service scale is closely related to the carrier service model. Its applicable scene is the applications with "small traffic, mainly reporting, long-term hibernation, sensitiveness to power consumption and low mobility". In order to carry a large number of low-power devices in the NB-IoT network, the most important technologies are PSM and eDRX.

NB-IoT supports three power saving modes: PSM (power saving mode), DRX (discontinuous reception mode), and eDRX(extended discontinuous reception mode).

  • PSM mode

    The terminal is in the deep hibernation during non-service period and does not receive downstream data. Only when the terminal actively sends mobile original data (MO data), the downstream data cached by the IoT Console can be received.

    In this status, the radio frequency of the terminal is turned off, which is equivalent to a shutdown status. However, the core network side still retains the user context, and the user does not need to attach PDN establishment when entering the idle status or connected status.

    It is suitable for services without delay requirement on downstream data. A terminal device has low power consumption and adopts battery power supply mode, such as meter reading service.

    • Active: the module is active, all functions are normally available, and data can be sent and received. In this mode, the module can switch to idle mode or PSM mode.

    • Idle: the module is in the light sleep status and network connection status, and can receive paging messages. In this mode, the module can switch to active mode or PSM mode.

    • PSM: the module is in the deep sleep status, and only RTC works. The module is disconnected to the network, and cannot receive paging messages. When the timer times out, the module is woken up. The module can also be woken up by pulling down the PSM_EINT pin.

      Development Overview

  • eDRX mode

    The terminal device takes into account the services with low power consumption and certain delay requirements. In each eDRX cycle, the terminal can receive downstream data only in the set paging time window. The terminal is in the hibernation status for the rest of the time and does not receive downstream data. This mode can strike a balance between downstream traffic delay and power consumption, such as remotely shutting down gas supply.

    Development Overview

    In each eDRX period, there is a paging time window (PTW). The terminal monitors the paging channel according to the DRX cycle, in order to receive downstream data. DRX cycle time is short, and it can be considered that the terminal does not hibernate and can be reached all the time. The terminal is in a hibernation status for the rest of the time. In the eDRX mode, the terminal device is accessible at any time, but the delay is long depending on the eDRX cycle configuration. This mode can strike a balance between low power consumption and delay.

  • DRX mode

    It can be considered that the downstream service can reach the terminal device at any time. In each DRX cycle, the terminal detects whether the downstream service arrives. This mode is suitable for the service with high requirements for the delay. Terminal devices generally adopt power supply, such as street lamp service.

    Development Overview

    The DRX cycle is short, 1.28, 2.56, 5.12 or 10.24 seconds. The DRX cycle is determined by the operator's network settings — handling APN service with SIM card. It can be considered that the downstream service can be reached at any time with small delay. It is suitable for services with high requirements for the delay, but the power consumption is relatively high. The terminal device generally is powered by mains electricity.

NB-IoT delay

First network access delay: after NB terminal is powered on, the terminal and the network have lots of message interactions, including authentication, channel establishment, and IP address allocation. It takes 6 to 8 seconds to complete the network access, and obtain the IP address for later data transmission.

Data reporting and receiving delay: after the NB terminal is successfully accessed, when the terminal has data transmission, the terminal will actively establish a wireless connection with the base station. At this time, authentication, IP address allocation and other processes are no longer required. After the wireless link is successfully established, the data will be sent immediately. The delay of data reporting by the terminal is closely related to the status of the terminal and the wireless network coverage.

Terminal reports data Platform sends data (PSM) Platform sends data (DRX) Platform sends data (eDRX)
Air interface delay + delay between private network and client server Air interface delay + delay between private network and platform + maximum PSM hibernation cycle (maximum 310 hours) Air interface delay (750 ms) + DRX paging cycle (maximum 10.24 seconds, minimum 1.28 seconds) Air interface delay (750 ms) + eDRX paging cycle (maximum 2.92 hours, minimum 5.12 seconds)
Second level (3 seconds to 30 seconds) Hour/day level, depending on terminal reporting cycle Second level, depending on DRX paging cycle Second to hour level depending on the eDRX paging cycle

Key parameters of NB-IoT service acceptance

From the above, it can be seen that the low-power consumption mechanism of NB application is inseparable from the configuration of SIM card operators. Therefore, when purchasing a SIM card, make clear the APN service you handle. Different APNs are suitable for different application scenes.

Consult Tuya staff when you do not know how to choose APN service.

NB-IoT power consumption

Terminal statusPower consumptionMeasured results of an environment
PSM status3 uA2.7 uA
eDRX idle statusxxuA to 2 mA1 mA
DRX idle status1 to 4 mA1 mA
Connection statusSends 200 mA, and receives 65 mASends 189 mA, and receives 161 mA

Introduction to MCU general connection solution

When the product functions are complex or the SoC solution cannot meet the requirements, you can choose the MCU connection solution.

In this solution, Tuya module is only used as a data transmission channel. MCU connection solution is often used for large and small household appliances, security sensor, and other categories of products.

Development Overview

Benefits: compared with the common AT instruction development mode of NB-IoT modules on the market, Tuya NB-IoT general connection serial port protocol mode is more beneficial. The development threshold of customers is lower, the maintenance is simple, and new products can be connected more easily.

Firmware type selection

  • PSM general firmware — monitoring reporting service scene
  • DRX general firmware — sending control service scene
  • Other custom firmware — general custom service scene

Tuya now has NB modules that connect MCU, including PSM general module and DRX general module. eDRX general module has not been developed yet. In case of special needs, such as protocol customization and function customization, you can consult Tuya staff to confirm the feasibility of the solution.

Development process

The whole development process consists of product creation, hardware debugging, software development, and function debugging.

Step 1: Create products

  1. Log in to the IoT console and create a product. Select the desired product, select NB-IoT for net pairing mode, and select power consumption type according to the product features.

    • Select PSM for products with battery power supply and monitoring reporting service.
    • Select DRX for products that are insensitive to power consumption and have the sending control services. Note that power consumption selection will be related to the sample sending and production of subsequent modules.
  2. After finishing creation, select the functions, panel, module, and firmware based on your product, and download the MCU development documents accordingly.

    You can find the specific description of creating products in MCU connection solution. See Product creation.

    Development Overview

Common module

The platform recommends the common module models when you create a product. Here is an example of the NM1 module, which is most used in the NB-IoT general solution.

After selecting the module model, you can purchase the module sample online. The hardware engineer will proceed with the board layout design. See the documentation related to hardware development in the documentation center.

Datasheet: NB-IoT Module Datasheet

Hardware design guide: NM1 hardware design

PCB documentation: Common module package library

Note: the peak working electric current of NB-IoT common modules is more than 300 mA. Reserve the electric allowance during power design.

Establish the minimum system of hardware

Development Overview

  • Serial communication circuit: electrical level 1.8V, level conversion required.

    • UART0 (optional): module firmware burning pin, which is generally not used in the solution connection process. This I/O pin can be led out to the test point for easy debugging. Baud is 115200.
    • UART1 (required): universal connection pin, used for serial communication between the module and the user chip. Baud is 115200 or 9600.
    • UART2 (optional): log printing pin. If problems are found in the connection process, this pin is used for collaborative judgment by obtaining the log. This I/O pin can be led out to the test point for easy debugging. Baud is 921600.

Development Overview

  • Module wake-up circuit:

    • Power-on wake-up pin: PWRKEY

    • Low power wake-up pin: PSM_EINT

  • SIM card circuit: before design, determine the need for SIM card packaging, USIM or eSIM. Purchase the SIM card of relevant services according to the product features.

  • Power supply circuit: the peak power consumption of the module is about 300 mA, so the power supply circuit shall be properly designed.

  • Antenna circuit: for the antenna radio frequency circuit, see the hardware design manual. The antenna needs to be matched by the antenna manufacturer.

Step 2. Binding verification

When receiving the module, it is suggested that, before you start coding, you run the provided module debugging assistant to check if the module can work properly. In MCU simulation mode, connect the module and configure the network for practice. Meanwhile, you can get familiar with the protocol interaction process, which will help you to proceed with development debugging.

Development Overview

In MCU simulation mode, the debugging assistant simulates the MCU to automatically respond to the module with the correct protocol data. After you bind the module through the app, you can test DP data reporting and sending. The procedure of operating the assistant and module network configuration is as follows. Before operation, you need to learn about the operation instruction of Tuya module debugging assistant. For beginners, see Module Debugging Assistant Instruction.

  • According to the schematic diagram of minimum system, build the peripheral circuit of the module, make sure that the power supply is stable, the antenna complies with the standard, signal strength is good, and the NB special IoT SIM card is plugged in.

  • Open the debugging assistant in the development documents, and import the debugging file. Select the NB-IoT general protocol and MCU simulation mode.

  • Connect the module serial port to the computer through USB-to-TTL adapter, and select the corresponding serial port and Baud in the assistant. After you open the serial port and click Start, you will see the initial protocol interaction between the module and the host.

Note: after power on, NB-IoT module will constantly send commands to query the product information. When receiving the correct response, it will proceed with the initial protocol interaction. If the module does not send data after power on, check if the peripheral circuit of the module is correct.

Development Overview

Scan QR code with the app and bind the module

  • Register: after NB-IoT module is authorized by Tuya, Tuya Cloud will pull module information and register the module on the telecom IoT platform.

  • Activation: after the NB-IoT module is powered on for the first time and the initialization is completed, it can be connected to the telecom IoT platform for activation, subject to the network status issued by the module.

  • Use: only modules that have been activated and are not bound by other accounts can be successfully bound by the app.

Development Overview

Development Overview

Note: NB-IoT QR code needs to be generated by Tuya production printing tools. For more information, contact Tuya staff.

Step 3: Software development

During hardware debugging, you will see a sequence of serial port protocol interaction data between the module and MCU. To understand this data, refer to the protocol documentation in the development documents. The protocol consists of basic protocol and function protocol. The basic protocol is product neutral and shared by the modules. It consists of module initial command and certain extension function command. The function protocol works to report and send commands based on the basic protocol, and specifies the DP data format. The basic protocol is updated in real time in the documentation center. See Universal Serial Port Protocol of NB-IoT Module.

There are two methods to connect the MCU to Tuya module protocol, migrating MCU SDK or connecting the protocol by yourself.

Connect the protocol by yourself

If the MCU resource is limited, or migrating MCU SDK is inapplicable, you can connect the protocol by yourself.

Migrate MCU SDK

If the MCU resource is sufficient, it is recommended to directly migrate MCU SDK, which facilitates the development process. MCU SDK in the development documents is the protocol application code in C language, and it can be directly imported to the MCU project. MCU SDK requirements for MCU hardware resources: 4 KB Flash, about 100 bytes of RAM. RAM is related to DP data length. 9-level nested function is adopted. If the resource is limited, you can connect the protocol by yourself. The functions in the SDK package can act as references.

MCU SDK migration tutorial: MCU SDK Migration

Step 4: Protocol verification

After migrating MCU SDK, you can use the module debugging assistant in module simulation mode to verify the code. The operation is similar with MCU simulation mode. In the module simulation mode, the assistant automatically sends the initial interaction process to verify whether the MCU response is correct. Prompts will be sent in case of data error. After the initialization interaction is passed, you can manually click other extension function for testing. After function verification is completed, you can connect the actual module to configure network and carry out joint debugging.

Note: the module simulation mode only verifies the MCU serial port protocol, and does not support networking.

Development Overview

Development Overview

Step 5: Joint debugging

After the assistant verifies the code, connect the MCU to the module and configure network on the app. You will enter function joint debugging. Joint debugging is used to test whether the DPs reporting and sending works properly. The links of useful tools adopted in the debugging are as follows:

Query the background log: log in to the IoT Console and enter Operation center to query device background log.

Online support center: Tuya provides online support services. If the documentation cannot solve your problems, raise your questions online and our technical team will help you troubleshoot problems.

FAQ: learn about the frequently asked questions during development.

Click for services and help