.svg)
NTN services are live, delivering video calls, VoLTE and more, representing a new chapter and growth opportunity in mobile connectivity. The tech is ready, but the OSS that has powered telecom networks wasn’t built for this. Rakuten Symphony Head of OSS Sales Anshul Bhatt explains what actually changes when satellites become part of a mobile network’s operating model and how OSS needs to adapt.
For decades, fixed mobile networks have served moving users. Roaming, handoffs, in-door, Wi-Fi—every aspect of the equation has been iteratively optimized to maximize experience for subscribers on the go.
Non-terrestrial networks (NTNs) flip this dynamic. Users are essentially stationary while antennas (i.e., satellites) move at upwards of 36,000 km/h. A satellite may pass through multiple countries, operators and regulatory environments in one orbit.
Traditional OSS is not ready to support an operating model defined by global, continuous motion.
That’s a problem, because the buzz around progress turning up NTN services coming out of MWC Barcelona indicates opportunities are here now, demanding support at scale.
Attempts have been made to apply existing OSS inventory models to NTN environments. “Cell” gets swapped for “satellite” and so on.
This won’t work.
From our experience in Japan and early work with NTN providers globally, the OSS data model must be rebuilt from scratch to create a completely new topology. One defined by satellites, feeder links, aggregators, earth station farms and the critical connection between MNOs and the NTN provider core.
Case in point: we ultimately had to build a dedicated NTN data model on a graph database, defining new attributes and relationships that can’t be accurately captured in relational models.
Also, given satellite environments lack an established ODA framework, the overall operational playbook is still being written, starting with service assurance.
OSS has typically monitored static networks in 15-minute intervals. This doesn’t work for NTN because the network is in constant motion and service only exists when a satellite is overhead. So, everything has to be anchored to pass windows.
This means incident priorities become dynamic. If an eNodeB is down at an earth station, it’s not a priority 1 issue if no satellite pass is scheduled for that region. As the next pass approaches, however, the priority level changes.
Traditional anomaly detection also breaks as it has always been trained on continuous historical data. In NTN environments, coverage isn’t continuous and data gaps aren’t necessarily anomalies. This means models need to be retrained to learn the difference.
Even the concept of “busy hours” disappears.
For a satellite orbiting earth, it’s always busy hour somewhere so the typical thinking around capacity planning, staffing and SLA windows no longer applies. Instead, planning assumptions built around regional peak hours break down in a global, always-on coverage model.
Terrestrial networks planning is mostly a one-time activity. In NTN, it is continuous and event-driven.
NTNs introduce geographical cells (i.e. logical coverage constructs) that span up to 50 km areas and are mapped dynamically to eNodeBs at earth stations based on capacity and spectrum availability.
These cells are driven by events like a hurricane response, new satellite going on air or extension of remote coverage, which would all trigger approval-based provisioning workflows that must be automated. These workflows map geo cells to logical eNodeB cells and the correct feeder links for satellites scheduled to pass overhead.
When a new satellite goes on air, it gets incorporated into scheduling and geographical cell planning as configuration management is coupled tightly with satellite scheduling.
Operators incorporating NTN into coverage want to manage NTNs as an extension of their terrestrial domain, requiring NTN providers to expose multi-tenant portals that let each partner operator view and manage their own slice.
NTN commercial models are inherently global, as providers partner with operators across continents. This introduces data sovereignty considerations for operators that want to keep data in-region. Regional regulatory requirements like GDPR also come into play.
The architecture being adopted to address these needs sees data stored locally at regional earth stations that can be accessed globally by NOC operators. The data never needs to leave its home region.
In our work with NTN providers, multi-tenant architectures hold this data, with each operator having its own portal and view, and the global NTN operator getting a unified NOC with data localization enforced by design.
Complexity increases as architectures evolve. If the baseband or data center moves into the sky, data sovereignty suddenly becomes complex because satellite doesn’t respect borders.
This reality needs to be addressed before more advanced NTN architectures can scale commercially.
Operators have drive testing down to a science. Though it all goes out the window with NTN. It’s not always easy to simply send an engineer with a laptop to the middle of the ocean or a remote national park. Yet, these are the very use cases NTN is designed to serve.
In NTN environments, testing must become remote and continuous. Solar-powered UE probe boxes are serving this need, being deployed in remote locations that automatically run tests during satellite pass windows. It is early days though as this emerging discipline finds its footing.
As NTN providers continue to focus on making sure the tech works, operational testing and measurement will need to become hardened.
Purpose-built NTN OSS is live today, supporting commercial requirements. Critical requirements like dedicated data models, service-aware assurance, dynamic provisioning and multi-tenant architectures all provide an important foundation. Next comes the hard work of scaling and hardening as NTN commercial momentum builds.
It is happening quickly.
