Enhancing 5G Relay Systems with Expert Team Extension

Core Objectives

The primary objective was to develop a robust mechanism for downloading firmware updates from the cloud, unpacking these updates, and distributing them to various system modules. Given the system’s architecture, which included a central module communicating with the tower and multiple service modules for consumer connections, the update process had to be planned to maintain system integrity and continuity.

Software Update Module

Multi-Module Compatibility
The system comprised a central module linked to the tower and up to four consumer-facing antennas, necessitating a firmware distribution strategy that accounted for various hardware configurations. The update mechanism was engineered to first apply updates to the central module, which then orchestrated the distribution to service modules.

Firmware Unpacking and Distribution
After downloading the firmware image from the cloud, the central module unpacked the image. This process had to be carefully managed to guarantee that the unpacked firmware could be efficiently distributed to the appropriate modules, considering the system’s maximum configuration of one tower-facing module and four consumer-facing modules.

Dedicated Communication Channel
The entire telemetry and control of the device, including firmware updates, were managed over a dedicated LTE channel. The system employed an LTE Cat-M modem for an independent communication link, ensuring that the telemetry and control functions were separate from the primary 5G network traffic, thus maintaining reliable and uninterrupted management capabilities.

Update Process Across Diverse Operating Systems
The relay’s hardware modules operated on Linux, whereas the satellite modules controlling the antennas ran on FreeRTOS. This diversity required a sophisticated update process where the main module not only updated its Linux OS but also ensured the Rx and Tx boards received the correct firmware updates.

Device Identification and Update Customization
The update solution was designed to intelligently identify the type of device it was being applied to upon initiation. This capability allowed the firmware to adjust its installation procedure based on the specific hardware configuration, ensuring that the update process was both effective and error-free.

Operational Continuity
Critical to the solution was the ability to maintain operational continuity during the update process. This required a careful balance between applying necessary updates and avoiding disruptions to the 5G relay’s functionality, especially given its role in dual-directional communication between the tower and consumers.

To reach these goals, our team developed a solution for downloading, unpacking, and distributing firmware updates from the cloud to multiple system modules of a 5G relay, which was the main software module we created during our collaboration process.

Participation in additional modules development

Event Manager 

This module was the key to tackling the complex task of keeping track of and lining up events from various devices in the 5G relay setup. This setup wasn’t simple, with its diverse hardware and the dynamic way it operated needing constant watch and coordination:

Gathering Event
The Event Manager’s first job was to pull together events from every part of the 5G relay system. Since the system was set up with a central module for talking to the tower and several service modules for connecting with users, each part was creating its own events. The Event Manager needed to bring these events together into one clear log, helping those managing and engineering the system to keep an eye on its health and how well it was working.

Aligning Events Across Devices
A big hurdle was making sure events recorded by different modules matched up time-wise. Each event was marked with its own time based on when the module thought it happened, which could differ slightly between modules. The Event Manager had to line up these times correctly, which was crucial for fixing problems and understanding what happened and when.

Creating a Single Log for Analysis
After putting events together and getting their times to match, the Event Manager puts all this information into one log to keep track of the system’s activities clearly, letting administrators quickly spot trends, oddities, or problems needing a look.

Helping With Diagnostics and Fixes
Having a detailed log where events lined up made it easier to figure out what went wrong or where the system could do better. This not only helped keep the system running smoothly but also improved how it worked, as steps could be taken based on what the log showed.

Ready for Growth and Changes
The module was built to handle growth, meaning it could easily include new parts as the system got bigger. This adaptability made sure it would continue to be a strong tool for overseeing the system, no matter how much it changed or expanded.

SNMP Manager

The primary goal was to enable the system to support SNMP, allowing for the reading and modifying of network device variables. This capability is crucial for effective network management, providing administrators with the most common tool to adjust settings and monitor device status remotely:

Accessing and Changing Variables
To add SNMP, the system had to let us get device info and change settings safely. We had to figure out a secure method to let SNMP requests access device variables and make sure any changes were correct and didn’t mess up how the device worked.

Working with Different Modules
The design of the 5G relay, with its main hardware module and various service modules, made SNMP integration complex. Each part of the system had its own settings and info that needed to be available through SNMP. 

Thinking About Security
We used SNMPv3 for its enhanced security to manage system access and prevent unauthorized changes. Strict controls were put in place to authenticate SNMPv3 requests and secure critical variables, allowing only authorized users to modify the system.

Diagnostics Module 

A module for collecting metrics, analyzing data, and generating diagnostic reports to maintain system integrity.

LTE Modem Manager

Our team developed an LTE modem management module for IoT connectivity. This module handled the modem’s operations, including its own firmware updates, distinct from other system components due to the modem’s pre-integration into our project. The management module initiated the modem, loaded required telecom operator configurations, and managed firmware updates for effective IoT communication.

IPCC Module

This module managed communication with RF (Radio Frequency) boards that boosted signals and controlled antennas. It linked the Linux systems of devices with the antenna control boards running on RTOS. Essentially, this was a driver for the RF devices, making them recognizable to the operating system running on the control device.

System Manager

This module was responsible for provisioning the system. Upon the operating system’s startup, it recognized the specific type of hardware each software module was operating on.  Its role included initiating communication among all the system modules. This meant that as the system booted up, all the System Managers of the various modules would communicate with each other, exchanging version information and configurations. This process was important for the proof of compatibility with new firmware versions before their installation. The module was tasked with preventing potential compatibility issues, such as discrepancies between the Linux version running on the main control device and those on the consumer-facing modules.

This was achieved through a low-level data exchange protocol that remained constant, unaffected by changes in firmware versions or software modules. Additionally, the System Manager monitored the system’s overall health, ensuring all devices operated correctly. For instance, if a connection to one of the service modules, which faces the consumer, were lost, the System Manager would send an alert to the central IoT manager log in the cloud.

Message Manager

Our team also played a role in fine-tuning this module and fully integrating it into the new system for updates and interactions. This module was responsible for communication with all the hardware modules within the system. It operated using zero nq, a framework that allowed devices to exchange data with each other either over the network or through inter-process communication.