Full Text

Project partners

• JiHo Lee (jiholee@vt.edu)

• Chung Chan (cchan02@vt.edu)

• Diego Melendez-Maita (dmelendezmaita@vt.edu)

• Ken Ranson (kranson@vt.edu)

Project Description

Mobile radio application for an emergency services platform that has multiple capabilities such as compatibility with 5G networks, LTE networks, and Wi-Fi networks. The system would have to account for varying frequency bands and output powers, and towers that would act as a repeater/priority monitor (software controlled). The design will have several architectural styles. A layered architecture will be separated between networking, communication control, and user interface layers. A key feature of the proposed design is the software which can control repeater towers as signal control and monitors. The system is an even-driven architecture when a user pushes the push to talk button, and the embedded software will use a monolithic approach to control internal hardware decisions. 

We chose this system as it is similar to a member’s work project but adds other capabilities such as compatibility with 5G, LTE networks, and Wi-Fi. This project will take an existing technology and make it better by adding these additional features. Considering this similarity to the work project, it will have a similarity score around fifty percent as we are adding new features.

It meets the project requirements as it contains multiple architecture styles with different system components where the choice of architecture will be critical to the success of the system. The design will incorporate encryption and authentication mechanisms to maintain security and data integrity across all supported network types. The architectural decisions are important to meet system requirements because these new features would enhance emergency services capabilities and allow them alternate communications, low latency and fault tolerance. Choosing between architectural designs such as layered, event-driven, client-server models will directly affect the system’s maintainability. This justified our team’s selection of the system as the subject for Project 1.

Trunked radio system operations background

The system uses a central computer and a dedicated control channel to dynamically assign available frequencies from a shared pool of users which increases efficiency compared to conventional systems where frequencies are dedicated to specific groups. All radios listen on a control channel which has a dedicated frequency that is used as the central point of communication for setup and management. When a user presses their push to talk button, the radio sends a request to the control channel for a specific talk group. It is then dynamically assigned by the system’s controller which determines which frequency is communicated to all radios in the requested talk group, sometimes known as the voice channel. The radio’s frequency then switches to the assigned frequency and the user’s transmission begins. When the radio finishes the transmission, the radio then returns to the control channel frequency, and awaits the next call. An overview of how the system works is shown below.

The benefits of this system are the efficient use of channel frequencies so that a large number of users can share a smaller pool of frequencies. The automated assignment of frequencies by the controller is fast and minimizes delays that can occur when waiting for a channel to become available. It also supports an increase in capacity compared to conventional systems with the same number of available channel frequencies because it can support more users and groups. Most importantly, the system provides interoperability that allows for easier communication between different user groups, such as fire, police, and utilities, on the same system.

Added LTE and Wi-Fi capabilities

In order to complement the mission-critical communication paths, Wi-Fi and LTE/5G capabilities can be added to the system using interoperability gateways. The primary goal is to extend communications beyond conventional means, native range, and add broadband data services. The gateways connect to a broadband network, allowing standard mobile and portable radios to communicate with users Push-To-Talk (PTT) apps on smartphones, tablets, or PCs. This allows agencies to integrate existing radio communication systems with newer broadband technology, expands communication coverage to users outside the radio communication network, and provides a lower cost option for adding PTT services on existing smartphones, offloading non-critical traffic and freeing up capacity. 

The mobile radio application designed in this project is primarily intended for front-line emergency service personnel in government or public safety organizations, such as police officers, firefighters, paramedics, and personnel at disaster response centers. The secondary target users are system administrators and communication monitoring staff. The following sections describe the typical usage scenarios for both types of users.

Use Case 1

Alexa is a 32-year-old firefighter who often takes part in urban fire and disaster rescue missions. She uses a portable radio and helmet communication tools to stay connected with her captain and other team members. When she enters a fire scene, heavy smoke and building structures often make the signal unstable, but she has no time to adjust settings or reconnect manually.

She needs a system that can automatically maintain stable communication and ensure messages are delivered in real time, as even a few seconds of delay could affect her team’s safety. In emergencies, she hopes to send alerts quickly and clearly so that the command center and police units receive the warning at the same time and can respond immediately.

For Alexa, the most important qualities are real-time performance and reliability. No matter how harsh the environment is, communication must remain continuous so she can focus completely on saving lives.

Use Case 2

Kevin is a 47-year-old senior police officer who has experienced the transition from traditional analog radios to modern digital communication systems. As a field commander, he is responsible for coordinating communication among multiple patrol units, managing talk groups during large-scale incidents, assigning channels, and executing priority channel switches in emergencies. 

Although Kevin is experienced and open to new technology, he still faces challenges when using complex or unfamiliar interfaces. In high-pressure or time-sensitive situations, he requires a system that minimizes manual setup, provides clear feedback, and remains highly reliable with low latency, even when the network is congested.

Therefore, he hopes the system can support intuitive operation, allowing him to learn it quickly and maintain his efficiency. He also expects strong safety measures so that even if a mistake occurs, communication will not be completely interrupted or lead to serious consequences. 

Use Case 3

Ryan is a 40-year-old commander at a regional medical center located in a remote area. Unlike large cities, this region has limited radio coverage, and specialized radio equipment is expensive; not every medical or logistics staff member can be assigned a device. This can lead to delays and difficulties in communication during emergencies.

Although complete communication failures have not yet occurred, Ryan’s experience makes him fully aware of how critical communication is to rescue operations. To prevent equipment shortages from affecting disaster response, he hopes that staff without radios can still join the communication in real time. This would ensure that everyone has sufficient ways to exchange or report information, avoiding situations where critical orders are delayed due to limited radio availability.

Therefore, he hopes the system will move beyond traditional radio-only communication and make use of modern network technologies. This would allow employees without radio devices to join the conversation, enabling fast coordination, maximizing communication efficiency.

Requirements

Functional Requirements

FR-1 The system must support a Push-to-Talk (PTT) function. When the user presses the talk button, the system must send a request to the control channel to join a specific talk group.

FR-2 The system must allow commanders to create, modify, and delete talk groups, and to assign specific channels to selected users.

FR-3 The system must automatically switch between available networks (Wi-Fi/5G/LTE/P25) and select the most stable connection to keep communication uninterrupted.

FR-4 The system must support an Emergency Alert function. Messages marked as emergency must be prioritized and sent immediately to the command center and other related units.

FR-5 The system must support real-time monitoring of multiple units, talk groups, users, or relay towers. The system must display their current status, such as online/offline state, number of users, channel usage, and signal condition. 

FR-6 The system must support the ability for multiple units or departments to share information by joining the same communication group and exchanging messages in real time. 

FR-7 The system must provide strict identity authentication that allows users to log in, verify, and receive authorization. This is to prevent hackers from impersonating users, disrupting communication, or stealing data. 

FR-8 The system must report any abnormal conditions and automatically switch to a backup communication path to avoid service interruption. 

FR-9 The system must record the time, channel, participating units, and users for each call and alert event for future investigation and analysis. 

Non-Functional Requirements

NFR-1 The system should maintain at least a 90% connection success rate even in environments with weak signals or interference. 

NFR-2 The system should establish a voice communication connection within no more than 50ms after the user presses the Push-to-Talk (PTT) button.

NFR-3 The system should be able to handle no fewer than 150 simultaneous voice connections. 

NFR-4 The system should maintain an average communication delay of less than 200ms even under high network load.

NFR-5 The system should provide 99.99% availability, with total annual downtime not exceeding 5 minutes. Automatic recovery within 10 seconds should not be counted as downtime.

NFR-6 The system should store communication records for at least one year. Each record must include the call ID, user list, timestamp, communication channel, and connection status.

NFR-7 The system must support consistent functionality across multiple platforms (Radio/ iOS/ Android/ Windows/ Mac).

NFR-8 The system should ensure that voice interruption does not exceed 1.5 s, when automatically switching between Wi-Fi/ 5G/ LTE networks.

System Overview

The Communications Control Software with Wi-Fi/LTE/5G is designed as hybrid communication network combining traditional radio with LTE/5G broadband and Wi-Fi channels. The hybrid system is chosen to guarantee the real-time and reliable communication for emergency response even under all conditions. The system is consising of five major components:

• Communications Controller

• Dispatch

• Tower Base Stations

• Radio Firmware

• Mobile Application (Android/iOS)

These modules are interacting with each other and form a two-path communication system with automatic resilent, dynamic frequency assignment, and real-time monitoring. The detailed module descriptions are in page Modules.

Modules

The  communications and control software with Wi-Fi/LTE/5G consists of five major modules: Radio Firmware, Mobile Application (Android/iOS), Tower Base Stations , Communications Controller, and Dispatch Center. They perform as a hybrid communication network that support both trunked radio and broadband technologies for emergency situations.

Radio Firmware

The radio firmware module is to handle main functionality of Push-to-Talk (PTT) radio communication through trunked control channels. It is used to send and receive voice transmissions to and from the tower and account for RF interference (RFI) , signal strength and determines the channel frequency to communicate on based on the control channel. It also has an emergency function that overrides the control channel to transmit emergencies immediately. The radio firmware mainly interact with Tower Base Stations for channel updates.

The radio firmware which is a monolithic style architecture coupled with event-driven. The event-driven sections of the software monitor the push to talk, emergency, and antenna for input such as button press events and the detection of an incoming message. Inside the Prioritizer, it monitors for PTT and emergency events,  and listens to the control channel for instructions about which channel it should broadcast on. The radio software should override all incoming and outgoing traffic in the event of an emergency button press, and to ensure the emergency broadcast cannot be used to disable the network, only allow a simple transmission to notify the dispatch that an emergency event has occurred with the radio identification. Location can be determined by triangulation methods based on signal strength between the user and nearby towers whether they are 5G, LTE, or radio communications towers.  The Prioritizer also determines when the microphone can be enabled and should be shut off when the PTT is not engaged. The multiplexer and mixer are hardware components that can be software controlled based on the radio model and would have minimal functionality. The Prioritizer must also account for RF interference, and have the capacity to add encryption to the messages if enabled in the firmware.  Finally, it also stores all groups and available frequencies, and can be updated from dispatch over the air using a transmit message to the radio.

Android/iOS App

The Android/iOS app is to provide smartphone users with same functionality of PTT and status as radio devices. It basically does the same as the radio, but uses the App's buttons to transmit messages. The function include initiate PTT calls over LTE/5G/Wi-Fi. This module mainly interact with Tower Base Stations which can connect to the controller and dispatcher for sync call logs and alerts. The advantage of the phone is its simplicity, and the ability to provide a low cost option that can be installed on any smartphone with the purchase of a valid license. It can transmit by connecting to a nearby radio via bluetooth, or can be used to transmit and receive messages via a Wi-Fi connection to the internet and thus the dispatch. All messages sent and received by the phone are encrypted. The architecture here is a combination of Model-View-Controller, and a layered architecture (presentation, domain, data) to handle business logic and network communications.

Tower Base Stations

The two tower base stations is to relay communications between radio and controller. It has RF repeaters for 5G/LTE and radio communication frequency channels that re-transmit received messages to the appropriate devices based on the settings loaded into the base station software. The base station, like the radios have to account for RFI, signal strength, and channel frequencies. In addition, the base stations must account for multi-path interface, call priority, and to delay non-emergency calls if an emergency signal is detected. It acts as a central hub that converts analog RF signals into digital data to be sent to the network. This module mainly interacts with communication controller for routing and frequency assignment, and dispatch to provide usage logs. 

The base stations consists of an antenna system, transceiver units, control equipment, power supply, RF repeaters, and a back-haul network. The antenna system,  power supply, and RF power modules are hardware only devices, providing power and receiving/transmitting modulated RF. The control equipment is what manages communications protocols like P25 between devices and ensures data is correctly routed. The back-haul network connects the base station to the rest of the network , through a wired connection like high-speed fiber. The main part of the system which is the control equipment, uses a software defined radio architecture that functions like a hardware radio to define functions like modulation and demodulation, a process control architecture to monitor power for outages so it can be rerouted to a backup generator, and a layered architecture for communications with the dispatch via fiber.

Communications Controller

The communications controller is the brains of the system, determining where to retransmit incomming messages and handles not only the 5G/LTE and radio frequency communications signals, but must also handle input from the internet for any calls made over W-iFi. That capability is important in situiations like a building that may have a working Wi-Fi system, but a call via RF or 5G/LTE cannot be made because of the building material that the building is constructed with, or the user is in a location such as a basement where the signals are too weak.  This module directly connected to Dispatch for monitoring and control. It communicates with Tower Base Stations to manage calls.

Dispatch

The dispatch is where scenario-based usability engineering would be extremely useful. The dispatch is composed of monitors, receivers from the communications controller, and a Push To Talk microphone for direct communications within all groups. They also have the ability to change the channel frequencies, groups, and add or remove groups. These changes are then sent to the towers so they can also implement any changes. Dispatchers can override and cancel any call.  This module mainly interact with Communications Controller to receive all data and control messages and Tower Base Stations (Software System as Repeater) for sending new configuration or frequency assignments.

The figure below is the sequence diagram of dispatch. When there is a message received and the dispatcher initiate the communication. The dispatcher send controlMessage to communications controller to determines which communication protocol that user use (e.g., RF, LTE/Wi-Fi). The controller receive this message and determine routing or priority level and may respond with updated settings (e.g., new frequency allocations). Dispatch updates the new configuration to maintain the communication. The dispatcher may send overides or cancel message to communications controller to manage and interrupt for preventing unpredicted conditions and human-sight flexibility. The controller immediately stops the ongoing connection when it receive overrideCall and update the setting. The controller pushes configuration changes to all connected tower stations. These changes ensure network synchronization between RF and broadband gateways. When tower receives the acknowledgeUpdate message towers confirm receipt and successfull application of new settings. The  communications controller sends an acknowledgement or error message back to dispatch with statusUpdate message. The dispatch uses a layered architecture for network communications, an event-driven architecture for transmitting and sending messages, and a fault tolerant architecture for maintaining constant availability and switching to alternate consoles when necessary.

Design Rationale

The Communications Control Software with Wi-Fi/5G/LTE is a complex system composed of physical input, data processing, and network/physical output components. In this design, we analyze the architecture based on the functions triggered when a user makes a communication request: 1) processing the communication request after the user submits it, 2) distributing channels, 3) maintaining continuous service during calls, including automatic switching and fault recovery, and 4) recording detailed communication data for monitoring and auditing purposes. In addition, the architecture must effectively support both automatic and manual operation modes. The automatic mode focuses on low-latency connection establishment, dynamic routing, and automatic fault switching (FR-1, FR-3, FR-8; NFR-2, NFR-4, NFR-5), while the manual mode allows the Dispatch to override and make decisions under abnormal or unexpected conditions (FR-2, FR-4, FR-5, FR-7).

The aforementioned functions align as subsets of the five modules above and as combinations of the various Functional and Nonfunctional Requirements. Module 1 (Radio Firmware) contains the lowest-level Push-to-Talk function (press -> connect immediately -> talk -> transmit). Module 2 (Android/iOS App) provides the mobile version, allowing users to join radio channels and communicate through Wi-Fi, 5G, or LTE. Module 3 (Tower Base Stations) handles signal forwarding and management. It receives voice data from the Radio or App and, according to the Controller’s settings, sends the signal to the correct channel or group while monitoring signal quality and interference. Module 4 (Communication Controller) determines which communication channel each user is assigned to and selects the most stable connection. When an abnormal condition occurs, it automatically switches to a backup route to prevent disconnection. Module 5 (Dispatch) acts as the command center, where operators can view all communication statuses, user states, and channel loads, as well as manually intervene when necessary (for example, force channel switching, end calls, or broadcast messages). Because this system is a cross-platform, distributed emergency communication system, the architecture must ensure real-time responsiveness and low latency while maintaining high availability and fault tolerance across multiple network environments. Therefore, in our design approach, we prioritize an architectural style that balances responsiveness and stability rather than one that focuses solely on extensibility.

Architecture Style

[Module 1] Radio Firmware: Event-driven and monolithic style

In this module, an event-driven and monolithic style is used because it operates at the lowest level, where timing and response speed are critical. It does not need to communicate with multiple services, but must respond immediately to button inputs and emergency events. Therefore, an event-driven approach is chosen to handle input events quickly, while a monolithic structure keeps all logic within a single program, avoiding external delays and hardware limitations.

[Module 2] Android/ iOS App

In this module, a layered and event-driven architecture is used because a mobile app typically includes three layers: presentation (buttons, channels, notifications), logic (PTT state, user authorization), and network communication (Wi-Fi/5G/LTE). The layered architecture clearly separates these responsibilities, making the system easier to maintain and expand in the future. At the same time, the event-driven approach allows the system to respond instantly to user actions (such as pressing the PTT button) and system events (such as network switching), ensuring low latency and high responsiveness. By combining both architectures, each layer can focus on its own event-handling tasks, giving the system strong maintainability, flexibility, and responsiveness.

[Module 3] Tower Base Stations

In this module, a layered and distributed architecture is used because the tower works as a relay that passes signals between multiple channels and devices while connecting with the Controller, Radio, and App modules. The layered design separates the radio layer, communication layer, and monitoring layer to avoid interference and make management easier. The distributed design lets each tower run on its own, so even if one node fails, the others can keep working and prevent communication from being interrupted.

[Module 4] Communications Controller: Layered and Event-driven

In this module, a layered and event-driven architecture is used because the Controller acts as the brain of the entire system. It manages channel assignment, load balancing, and fault switching, while continuously monitoring events such as emergency calls and system status changes for real-time response. The layered design separates the message handling layer, decision layer, and data access layer to improve maintainability. The event-driven design allows the Controller to trigger actions based on status changes, such as switching channels or sending notifications to users.

[Module 5] Dispatch: Layered, Event-driven, and Fault-tolerant

In this module, a layered, event-driven, and fault-tolerant architecture is used because the Dispatch module serves as the system’s command and monitoring center. It must display all users, channels, and system statuses in real time while handling multiple types of events, such as alerts from the Controller, emergency calls from users, and operator commands. The layered design separates the interface layer (UI), control layer, and data layer to improve maintainability. The event-driven design enables quick responses to changing events, such as tower failures or emergency alerts. The fault-tolerant mechanism ensures that even if the Controller or some towers fail, the Dispatch can manually or automatically connect to backup systems and continue monitoring operations.

Justification / Rationale

• D-1. Uses a trunked control channel that assigns voice paths as needed, which raises channel efficiency and supports more simultaneous users than fixed channels; the shared pool lets talk groups obtain a path quickly during busy periods, reducing wait time when many users press push to talk.

• D-2. Integrates LTE or 5G and Wi-Fi through gateways so coverage extends beyond the radio footprint and broadband data becomes available; the gateways bridge talk groups so users on phones and tablets can hear and speak with radio users indoors, in large buildings, and at the edge of RF coverage.

• D-3. Provides an emergency priority override that guarantees real-time communication when timing is critical; a one-touch emergency elevates the call, preempts lower-priority traffic if needed, and alerts dispatch with clear indicators and recorded events.

• D-4. Uses a Central Communications Controller to make management easier by coordinating legacy RF and modern IP communications; one place handles group setup, channel assignment, routing, health status, and logging, which keeps configuration consistent and simplifies operations

• D-5. Keeps human control during critical incidents with a command interface that automates routine actions yet allows manual decisions when conditions are unpredictable; operators can pause automation, reassign channels, and issue systemwide instructions as the situation evolves.

• D-6. Extends Push-to-Talk to smartphones and tablets for non-radio users, which improves interoperability and accessibility; agencies can add temporary users or partner organizations without issuing new radios, while still using familiar talk-group workflows.

• D-7. Maintains service when parts fail or signals are disrupted by providing dual paths across RF and IP with automatic switchover; if a tower, link, or controller instance is lost, traffic continues on the remaining path and users can keep talking.

• D-8. Enables post-incident analysis and supports documentation standards by keeping detailed logs for at least one year; records include calls, alerts, group changes, and faults with timestamps so investigators can reconstruct events and teams can improve procedures.

Assumptions and constraints

• Licensed RF spectrum is available, with coverage from the planned sites.

• Public cellular networks may be congested during incidents, so RF remains the primary voice path.

• Dispatch has trained operators on duty and a tested playbook.

• Mobile devices are managed with MDM and authenticated with SSO.

• Sites have backed-up power for at least 24 hours and periodic fuel resupply.

• Privacy and retention rules allow one year of operational logging.

Operational scenarios

• Routine operations: Most traffic stays on trunked RF. Phones and tablets join talk groups as needed, and the controller keeps groups, routing, and logs consistent.

• Large building fire: Indoors, some radios fall back to Wi-Fi or LTE through the gateways, while command and attack groups remain on RF outside. Emergency overrides preempt noncritical calls and alert dispatch.

• Rural search and rescue: Coverage gaps are bridged by LTE or deployable Wi-Fi. The controller keeps the team on one talk group, and logs capture movements, alerts, and failures for later review.

Failure modes and mitigations

• Control channel lost: Radios switch to the secondary control channel, and the controller fails over to the standby instance.

• Site power or backhaul failure: Traffic reroutes to surviving sites or to IP paths; hold-down timers prevent flapping until stability returns.

• Carrier outage or heavy congestion: Phones fall back to RF where possible or to managed Wi-Fi; critical groups are pinned to RF.

• Gateway fault: Health checks remove the faulty gateway from service, and alarms notify dispatch.

• Authentication outage: Radios continue on cached credentials; phone access is restricted to pre-enrolled devices until the IdP recovers.

Network selection policy

Prefer RF for push-to-talk when signal margins are good, since RF provides the lowest delay. If RF quality drops below agreed thresholds or the control channel is saturated, move that user to LTE, 5G, or Wi-Fi through the gateways. When RF quality recovers for several checks in a row, return the user to RF. The controller applies the same policy for group calls so a talk group remains coherent.

Targets and verification

• Call setup time: At least 95 percent of calls begin within 350 ms.

• Mouth-to-ear delay: At least 95 percent of radio-to-radio talk bursts deliver audio in 250 ms or less; radio-to-phone in 350 ms or less.

• Availability: Monthly service availability is at least 99.95 percent, with no single maintenance window longer than 15 minutes.

• Emergency handling: At least 95 percent of emergency calls preempt within 1 second and alert dispatch immediately.

• Logging: Retain at least 365 days; at least 95 percent of queries over the last 24 hours return in 2 seconds or less; zero data-loss objective.

Security and privacy

Use role-based access for dispatch and admin functions, enforce MFA for administrators and supervisors, secure gateways and apps with mutual TLS and certificate pinning, encrypt logs at rest, and restrict access to audit data based on duty role.

Glossary

• Trunking: A shared pool of channels assigned on demand by a controller.

• Push-to-Talk: Half-duplex voice where users press a button to transmit.

• Talk group: A logical group of users who hear each other’s calls.

• Emergency override: A privileged call that preempts other traffic.

• Gateway: A device or service that bridges RF with LTE, 5G, or Wi-Fi.

Potential future work

Indoor location for mayday events, deployable cells for incident scenes, over-the-air configuration for radios and apps, automated post-incident reports that summarize calls, alerts, and failures.

Design rational summary

This design keeps real-time voice reliable by combining a trunked RF layer that assigns channels on demand with a Central Communications Controller that coordinates talk groups, routing, status, and logging, while the dispatch interface automates routine actions yet permits manual decisions when conditions change quickly. Trunking raises spectral efficiency and limits wait time during busy periods, so push to talk remains low latency in normal and degraded conditions. Emergency priority and preemption guarantee that urgent calls obtain a path immediately, and the console surfaces clear alarms while recording events for later review. Configuration and policy remain consistent because the controller is the single point for group setup, channel assignment, and telemetry, which simplifies operations without removing human oversight.

Coverage and accessibility expand because LTE, 5G, and Wi-Fi are bridged through gateways that carry talk-group audio to smartphones and tablets, thereby keeping procedures unchanged for radio users while allowing partner agencies to participate without new radios. Resilience comes from dual paths across RF and IP, together with a network selection policy that moves users when quality thresholds or saturation are exceeded and returns them after stability is confirmed, while health checks and hold-down timers prevent oscillation during partial failures. Uniform policies for admission, priority, and path choice apply across the system, and comprehensive logs of calls, alerts, configuration changes, and faults are retained for at least a year to enable investigations and compliance. Security controls, including role-based access, multi-factor authentication for administrators, mutual TLS for gateways and mobile apps, and encryption of audit data, protect the system without adding friction to field users, which makes the combined architecture dependable for daily work and for large-scale incidents.

Conclusion

The proposed system, Communications Control Software with Wi-Fi/LTE/5G, combines traditional trunked radio communication system with LTE, 5G and Wi-Fi to build a reliable, real-time networks for emergency scenarios. With the hybrid design, it ensures continuous Push-to-Talk operation, automatic network switching via dispatcher. Each module consisting of radio, mobile app, towers, controller, and dispatch interact together to provide reliable, secure, and scalable (mobile/radio) communication. This hybrid design improves reliability and scalability compared to traditional systems while remaining flexible design for future component integration such as cloud control or AI-based optimizations for software systems of tower base stations.