The objective of this wiki is to explain the current state of NB-IoT in OAI.
Main Branches
- This is the main branch for NB-IoT development.
- It is designed to run on Ubuntu 16.04 and serves as the base for all subsequent branches.
- This branch is derived from
develop-nb-iotand has been updated to run on Ubuntu 24.04. - It includes updated packages and various modifications to ensure compatibility with newer systems.
Despite these improvements, several issues inherited from the original branch remain unresolved. One of the main problems affects the uplink processing, as explained in detail in the develop-nb-iot documentation. A patch was applied in that version to allow decoding of only specific, preselected uplink messages.
To disable this patch, you can deactivate the flag NB-IoT CRC revovery in the following file: cmake_targets/CMakeLists.txt
Known Issues
Even with the patch, the code still shows inconsistencies. Under the same setup, sometimes the eNB fails to decode the Authentication Response, while in other runs it proceeds but fails to decode the Security Mode Command.
-
To address this, Dr. Fedor Zhukov proposed a solution consisting of:
- Replacing the Turbo Decoder SSE with a Turbo Decoder Scalar, and
- Changing the LLR input type from int16 to int32.
This approach was tested in the branch nb-iot-llr-int32-w-conflicts, but it did not resolve the issue. The main reason is that the proposed solution does not clearly explain the motivation for changing the LLR type from int16 to int32, leaving uncertainty about whether the implementation approach was correct.
Further Analysis
After confirming that this modification did not improve the uplink decoding process, a detailed analysis of the PHY uplink chain was performed using the develop-nb-iot branch with the NB-IoT CRC revovery flag disabled.
- It was observed that:
- Before receiving the RRC Connection Setup Complete, the raw RF data captured at the eNB had a magnitude around 10⁸.
- After sending the Authentication Request, while waiting for the Authentication Response, the received data dropped to a magnitude around 10⁵.
- At this point, the decoded LLRs took only values of -1 or 0, which does not occur before this stage.
These results suggest that the eNB is not receiving the Authentication Response in the expected subframe, pointing to a possible synchronization issue originating from the MAC layer.
Potential Cause: MAC Layer Synchronization
The issue appears to be related to hardcoded parameters in the MAC layer, specifically in the Subcarrier Spacing Configuration and PHY–MAC Parameter Passing features.
- Both of these are implemented in the output_handler() function and are closely related:
- The Subcarrier Spacing Configuration is hardcoded to 15 kHz,
- Prevents the PHY–MAC Parameter Passing mechanism from executing and transmitting the correct configuration to the PHY layer.
As a result, the PHY layer never receives the subcarrier spacing configuration, which can lead to synchronization mismatches during uplink processing.
Compliance of NB-IoT Functions with 3GPP Specifications
The following section lists a series of functions that have been identified in the develop-nb-iot branch and verified against the 3GPP NB-IoT specifications. These functions are categorized according to their layer and whether they are compliant or non-compliant with the standard.
| Function | Layer | Compliance |
|---|---|---|
| get_UL_N_ru_NB_IoT() | PHY | Compliant |
| get_UL_slots_per_RU_NB_IoT() | PHY | Compliant |
| get_UL_N_rep_NB_IoT() | PHY | Compliant |
| get_UL_sc_ACK_NB_IoT() | PHY | Compliant |
| get_UL_sc_index_start_NB_IoT() | PHY | Compliant |
| get_Qm_UL_NB_IoT() | PHY | Compliant |
| get_pilots_position() | PHY | Compliant |
| ulsch_extract_rbs_single_NB_IoT() | PHY | Compliant |
| decode_NPUSCH_msg_NB_IoT() | PHY | Compliant |
| fill_DCI_N0() | MAC | Compliant |
| fill_DCI_N1() | MAC | Compliant |
| get_TBS_UL_NB_IoT() | MAC | Compliant |
| rrc_eNB_generate_RRCConnectionSetup() | RRC | Compliant |
| rrc_eNB_process_RRCConnectionSetupComplete_NB_IoT() | RRC | Compliant |
| ul_chest_tmp_NB_IoT() | PHY | Non-Compliant |
| rotate_channel_sc_tmp_NB_IoT() | PHY | Non-Compliant |
| get_llr_per_sf_NB_IoT() | PHY | Non-Compliant |
| descrambling_NPUSCH_data_NB_IoT() | PHY | Non-Compliant |
| output_handler() | MAC | Non-Compliant |
| schedule_response_NB_IoT() | MAC | Non-Compliant |
Table: Compliance evaluation of NB-IoT system functions by layer (develop-nb-iot branch).
Additional Information
- For more details, refer to the nb-iot-llr-int32-w-conflicts documentation, where you can find:
- UE logs obtained with BC95-G + Amarisoft setup,
- A comparison with the develop-nb-iot setup (using Quectel BC95-G + LTEBox),
- Extracted eNB logs showing raw RF data and LLRs during the process,
- Diagrams that help to better understand the uplink process.