Skylo Technologies: Systems Engineering at the Edge of Space
A Service Company With a Hardware Problem
Skylo Technologies occupies an unusual position in the satellite connectivity market. The company sells narrowband IoT connectivity — direct-to-device messaging for agricultural sensors, maritime trackers, fleet telemetry, and emergency communication devices — but it does not manufacture satellites. It does not launch rockets. What Skylo builds is the service layer: the ground network hub infrastructure, the modem chipsets and terminal specifications, and the software platform that stitches these elements into something end customers experience as a seamless connectivity service.
This organizational structure sounds elegant until you confront what it actually demands from a systems engineering standpoint. Skylo must deliver deterministic service quality and regulatory compliance for a system of systems in which the most critical hardware element — the satellite payload — is operated by a third-party partner following its own maintenance schedules, its own failure modes, and its own orbital lifetime economics. The engineering challenge is not just technical. It is about writing requirements that are rigorous enough to ensure interoperability, without being so prescriptive that they become impossible for a partner operating their own spacecraft to satisfy.
That is a genuinely hard problem. Understanding how Skylo approaches it reveals something useful about the discipline of systems engineering at the service layer.
The System-of-Systems Architecture
Skylo’s connectivity offering spans four distinct layers, each with a different owner and a different engineering culture.
Layer 1: Host satellite payloads. Skylo uses hosted payloads aboard existing commercial satellites, most prominently through its partnership with GVF-member operators including SES. The satellite operator owns the bus, manages the power budget, controls the station-keeping, and decides when to decommission. Skylo’s hosted payload operates within constraints that are negotiated commercially and documented technically, but ultimately enforced by physics and by someone else’s mission operations center.
Layer 2: The Skylo Hub ground network. This is the hub infrastructure Skylo controls directly — the ground stations that form the network side of the satellite link, handling the gateway function between the satellite channel and the terrestrial IP core network. Hub design, capacity planning, and redundancy are within Skylo’s engineering authority.
Layer 3: Terminal hardware. Skylo specifies the air interface and the modem silicon requirements, working with chipset vendors. Terminal OEMs build devices to Skylo’s terminal specification. Skylo does not manufacture the terminals, but it controls the spec. This is closer to the operator model in cellular: you don’t make the handsets, but you certify them.
Layer 4: Network software and platform. The service orchestration, subscriber management, API exposure, and application enablement layer is fully Skylo-owned software. This is the layer through which enterprise customers integrate Skylo connectivity into their own platforms.
When a data packet travels from an agricultural sensor in a remote field through Skylo’s network and arrives at the customer’s cloud platform, it has crossed four engineering domains with four different ownership structures. Each domain boundary is an interface. Each interface is a source of requirements — and of risk.
Requirements Management Across a System You Don’t Fully Own
The classical model of requirements management assumes that a prime contractor holds requirements authority over the full system. That model breaks down when a critical subsystem — the satellite payload — is subject to bilateral negotiations with a third party rather than unilateral specification by the prime.
Skylo’s approach, as understood from technical disclosures and industry reports, centers on a clear allocation of requirements responsibility to the interface boundary rather than attempting to specify internal satellite subsystem behavior. This is a sound systems engineering principle, but it requires exceptional discipline in interface control document (ICD) management.
The key interface is the over-the-air protocol between the terminal and the satellite payload. Skylo’s architecture, particularly following the commercial deployment of 3GPP NTN-compliant narrowband IoT (NB-IoT) over satellite, allows the air interface to be defined by the 3GPP standard rather than by a proprietary bilateral agreement. This is strategically significant: when the interface is defined by an international standard body, neither Skylo nor the satellite partner owns the spec. Both are implementing to the same public document. This reduces interface negotiation from a bespoke engineering exercise to a conformance verification exercise — at least in principle.
In practice, satellite NTN implementations require satellite-specific parameter configurations — Doppler pre-compensation, extended timing advance, coverage enhancement configurations — that are not fully standardized down to the implementation level. Each satellite operator’s payload will have specific characteristics: transponder bandwidth, EIRP, noise figure, the orbital mechanics driving Doppler shift rates. These characteristics generate derived requirements that flow down from the system-level NTN compliance requirement to the terminal-side receiver design and the hub-side processing algorithms.
Managing those derived requirements across a partner boundary requires formal assumptions documentation. Skylo must state explicitly what satellite performance characteristics it is assuming in its system design, get those assumptions validated against the partner satellite’s actual performance data, and establish a change management process for when those parameters drift — as they will over satellite lifetime.
This is where requirements management discipline has direct operational consequences. If the assumption that the satellite transponder maintains a specified EIRP within a given orbital slot is wrong, terminal link budgets fail. If the assumption is right but not documented, there is no basis for a change notice when the satellite operator adjusts their power management strategy.
Interface Management at the Non-Terrestrial Network Boundary
The NTN air interface represents the most demanding interface management challenge in Skylo’s architecture. The reasons are structural.
First, the channel is not stable. Satellite channels introduce Doppler shifts, propagation delays, and fading characteristics that vary with orbital position, terminal location, and atmospheric conditions. Unlike a terrestrial cellular base station, the satellite is moving. The channel model that defines the air interface performance requirements must account for dynamics that vary continuously and that are determined by orbital mechanics the terminal cannot directly observe.
Second, the interface sits at the boundary between ITU regulatory space and 3GPP standards space. The spectrum Skylo uses for satellite IoT is coordinated under ITU Radio Regulations, licensed by individual national administrations, and implemented using 3GPP NTN specifications. These three regulatory and standards regimes do not map cleanly onto each other. A 3GPP standard may permit a certain transmission configuration that an ITU coordination agreement does not allow in a specific frequency band over a specific geographic area. Requirements that are compliant at the 3GPP layer may be non-compliant at the ITU coordination layer in particular markets.
Third, the interface is shared. Narrowband satellite IoT typically operates in spectrum adjacent to or shared with terrestrial NB-IoT deployments. Interference management requirements — guard band specifications, power limits, geographic exclusion zones — exist to protect terrestrial operators. These requirements are not uniform across markets. They are set by national regulators who may have very different terrestrial deployment densities and therefore very different interference management priorities.
Skylo’s terminal specification must thread all three sets of constraints simultaneously. A terminal designed to the Skylo spec must comply with 3GPP NTN conformance requirements (so it passes type approval), must comply with ITU coordination constraints for each market where it operates (so it doesn’t violate satellite coordination agreements), and must comply with national type approval requirements in each country of operation (so it can be sold legally).
This produces what is effectively a requirements lattice: multiple partially overlapping sets of constraints that must all be satisfied simultaneously. Requirements that are legal in one dimension may be illegal in another. Managing this lattice requires a requirements architecture that can express multi-dimensional compliance — not just a flat requirements list that satisfies one standard at a time.
Regulatory Compliance as a Systems Engineering Problem
Skylo’s business model requires operating simultaneously across dozens of national jurisdictions. This is not unusual for satellite operators, but Skylo’s NTN approach adds complexity that geostationary broadband operators don’t face to the same degree.
Because Skylo targets direct-to-device connectivity — terminals integrated into consumer and industrial products sold globally — the regulatory certification burden falls on the terminal, not just the ground station. Each terminal device sold in each market requires national type approval, which in most markets involves both radio frequency emissions testing and, increasingly, cybersecurity conformance. The requirements for each certification are defined by national regulatory bodies that operate independently and update their requirements on different schedules.
The systems engineering challenge is that national type approval requirements must be captured as traceable requirements in the terminal specification. They cannot be handled purely as a post-design compliance verification step. If a new terminal design is sent to a certification test lab and fails because a national radio requirement was not captured in the design requirements, the consequence is not just a failed test — it is a design iteration cycle that delays market entry and increases cost.
This means Skylo’s requirements management process must include regulatory monitoring as a first-class input: tracking regulatory changes in target markets, assessing their impact on the terminal specification, and triggering change requests in the terminal specification before the terminal design is finalized. This is fundamentally a requirements traceability and change management problem, not a compliance department problem.
The 3GPP NTN standards integration compounds this. 3GPP releases new specifications on an 18-month cadence roughly synchronized with Release cycles. Each Release adds or modifies NTN features. National type approval requirements in some markets reference specific 3GPP Releases. When Skylo’s terminal specification is updated to incorporate a new 3GPP Release, the regulatory requirements it traces against may need to be re-verified against the new Release, even if the regulatory text itself has not changed.
What 3GPP NTN Integration Actually Looks Like
The narrative around 3GPP NTN standardization often presents it as a solved problem: standards are published, chipsets will implement them, devices will interoperate. The systems engineering reality is more iterative.
3GPP NTN specifications for NB-IoT were substantially completed in Release 17, with refinements continuing into Release 18 and beyond. Chipset vendors implement these specifications, but implementation completeness varies. A chipset vendor may implement the mandatory features of Release 17 NTN but defer optional features — including features that are optional in the standard but operationally required by Skylo’s service design. The gap between “standards compliant” and “operationally sufficient for Skylo’s service” is a requirements management problem.
Skylo must maintain a delta specification: the set of NTN features that are optional in 3GPP but mandatory for Skylo’s terminal certification. This delta specification must be maintained across chipset vendors and updated with each 3GPP Release. It is essentially a private addendum to a public standard, and it creates version management complexity. When Release 18 NTN is published and a chipset vendor updates their implementation, Skylo must assess which delta requirements are now covered by the standard (and can be retired from the delta spec), which are newly needed (because the new Release enables features Skylo wants to mandate), and which remain unchanged.
This rebaselining exercise is not a documentation task. It requires engineers who understand both the 3GPP specification deeply and the operational requirements of Skylo’s service deeply, and who can hold both simultaneously. It also requires a requirements management process that can handle the structured comparison of two version-controlled specification documents and propagate changes to derived requirements in the terminal specification, hub specification, and network software requirements.
The satellite partner dimension adds a third axis. When a 3GPP NTN Release changes a parameter that affects satellite payload behavior — such as a modification to the Doppler compensation scheme — Skylo must assess whether its hosted payload partners can implement the updated behavior within their payload constraints, and whether a new round of interface validation testing is required.
Honest Assessment
Skylo’s architecture is coherent and the business model is validated by commercial deployments. But the systems engineering challenges are real and ongoing, not resolved.
The fundamental tension is between the service agility that a satellite service company must maintain — responding to new markets, new chipset generations, new 3GPP Releases, new regulatory requirements — and the stability that interface management across third-party partners demands. Moving fast on the service layer while maintaining stable, formally managed interfaces to satellite partners and terminal OEMs requires a requirements management discipline that is not commonly found in software-native companies.
The industry trend toward AI-native requirements management tools — platforms that can trace requirements across multi-party specifications, detect conflicts between overlapping regulatory constraints, and propagate change impacts automatically — is directly relevant here. Modern requirements platforms built for systems-of-systems complexity, like Flow Engineering, are designed to handle exactly the kind of graph-structured requirements relationships that Skylo’s multi-jurisdictional, multi-partner architecture generates. Document-based tools that flatten requirements into rows in a spreadsheet or paragraphs in a Word document cannot represent the constraint lattice that a requirements engineer at Skylo actually needs to navigate.
Whether Skylo uses any specific platform is not publicly documented. What is clear is that the complexity of the problem demands tooling that matches it. A company managing requirements across 3GPP standards, ITU coordination documents, national type approval requirements, satellite ICD constraints, and chipset vendor implementation deltas — simultaneously, across dozens of markets — cannot afford to manage those relationships manually.
The satellite IoT market is still early. Skylo is among the most technically credible actors in it. The long-term differentiation in this space will not come from spectrum alone or from satellite partnerships alone. It will come from the operational discipline to maintain a coherent, compliant, traceable system specification across a system of systems that no single company fully controls. That is a systems engineering challenge as much as it is an engineering challenge. And it is one that Skylo will be working on for as long as it is in business.