TL;DR: RTK corrections have historically been a uniform, one-way data stream — every device gets the same thing regardless of its hardware, state, or operational context. Point One’s Software Defined Corrections Network (SDCN) separates the control plane from the execution plane, letting you define how your correction network looks and behaves down to the device level, in real time, through a single API. Dynamic data rates, signal configuration, fleet-wide profile management, and intelligent network switching are all available today.
History Doesn’t Repeat Itself. It Rhymes.
Recently I sat down with Aaron Nathan, Point One’s founder and CEO, to introduce something we’ve been building for the better part of two years. Before getting into the product, we drew parallels to a similar industry — cellular — that has gone through the same transition we believe corrections networks are about to make.
In the 1G and 2G era, a cellular network had one job: connect a call. The network was static. If you wanted different behavior, you configured the hardware. Then the use cases exploded — broadband, IoT, autonomous systems, public safety, gaming — each one placing radically different demands on the same physical infrastructure. A gas meter on 3G needs tiny, infrequent packets and long battery life. A video stream needs sustained throughput. A first responder needs guaranteed, pre-empted access.
The cellular industry’s response was to stop making the hardware responsible for expressing these differences and start making the network responsible. The result was software-defined networking — and specifically, the separation of the control plane from the data plane.
Control Plane vs. Execution Plane
In a traditional network, decisions about how data should flow and the actual flowing of data are intertwined in the hardware. Software-defined networking separates them.
The control plane defines the rules — which devices get which services, at what rate, with what priority, under what conditions. The execution plane delivers the service. It takes instructions from the control plane and executes them in real time, without making decisions of its own. Change the rules in software, and the behavior of every device on the network changes immediately — without a hardware reconfiguration, device reboot, or field visit.
Three design principles from this architecture directly informed how we designed SDCN:
- Granular control — the system should be arbitrarily precise. At the extreme, every device can have its own configuration.
- API-first — all of it programmable in code, easy to maintain, and changeable without touching hardware.
- Real time — a change in the control plane should be reflected in the physical world immediately.
The cellular industry also used this architecture to enable private networks. Enterprises can create isolated network endpoints — private APNs (Access Point Names) — where their devices connect to a software-defined layer separated from the public cloud, with full privacy, observability, and compliance guarantees. This matters even more for corrections.
The Corrections World Today
NTRIP — the dominant corrections protocol — is similar to ShoutCast, a streaming protocol from the late 1990s. It was designed to push a correction stream to a device. Every device on the network gets the same stream.
But corrections are now critical to more use cases — consumer robotic mowers, industrial inspection platforms, autonomous delivery vehicles, precision agricultural equipment, and L4 trucks. These devices have different receiver capabilities, accuracy requirements, cost constraints, and operational states.
A high-end survey receiver can use every frequency and satellite constellation available. A cost-optimized IoT device might support only two frequencies — and sending it corrections for signals it can’t even receive is a waste.
At scale, this diversity makes the static corrections model an engineering problem for our customers, who are asking:
- Can I ensure only the signals my receiver supports are delivered?
- Can I reduce data rate when my device is idle?
- Can I automatically switch correction types based on baseline distance?
These are the natural result of use case proliferation meeting infrastructure that was never designed to be programmed.
What We Built
Point One’s Software Defined Corrections Network (SDCN) applies the same architectural shift to RTK corrections that transformed cellular a decade ago. The control plane is fully programmable via our GraphQL API. The execution plane preserves the existing standard — NTRIP still works, existing devices are unaffected, and the control plane is entirely optional.
The core building block is what we call device profiles. A profile is a software-defined specification of what a given receiver should receive in a given state — not just based on what hardware it has, but based on what state the system is currently in and what environment it’s operating in. That distinction matters enormously in practice.
The robotic mower docked on its charger doesn’t need centimeter accuracy, corrections at full rate, or every signal its receiver can handle. Setting the profile to idle drops it to one-tenth the normal data rate with a reduced signal set — saving cellular cost and battery without losing position awareness.
When the mower goes active, the profile shifts to full rate, full signal, centimeter accuracy. That shift happens server-side, in real time. Nothing is reconfigured or rebooted on the device. The network just behaves differently.
The real-time, “just works” quality is delivered by the complexity moving to the server, where it can be managed through the control plane at scale.
What You Can Configure Today
Here are some initial capabilities of SDCN. Each of these is expressed both in our API and our web app (see Mike’s demo below). Today, using profiles you can quickly implement:
Dynamic data rates
Control message frequency per device or per fleet, from 1 to 30 seconds between messages, via API. Applied instantly on the server — no reconnection, no device update. Our data shows that a 5x reduction in correction rate has effectively zero impact on accuracy. In applications where some degradation is acceptable, 10x is achievable.
Flexible signal and constellation configuration
Deliver only the signals each receiver can actually use. No wasted data, no wasted bandwidth, or corrections for satellite constellations the receiver can’t see. You can filter signals. For example, if your receiver heavily depends on B2A, SDCN will only associate that device with stations that carry it. That preference is now a configuration.
Intelligent network switching
Set a per-device baseline threshold. When a device wanders beyond that distance from the nearest single-baseline station, SDCN automatically switches it to Point One’s Virtual RTK service. When it comes back within range, it switches back. This is adaptive network behavior that previously required custom engineering.
Device profile management
Define a profile once, apply it to any number of devices with a single API call. Change the profile definition, and every device assigned to it updates immediately. Manage definitions separately from associations, at any scale.
Private RTK
When a device connects to an RTK corrections service, it shares its position — that’s how the service determines which corrections to deliver. Precise location data is among the most sensitive data many of our customers generate, with significant privacy implications across automotive, defense, and enterprise robotics applications.
Point One supports a private RTK model in which the correction data terminus — what we call the edge — is hosted within the customer’s own cloud infrastructure rather than Point One’s. The customer gets the full benefit of Point One’s correction network and control plane, but position data never leaves their environment. This architecture has been in production with a major automotive OEM for over two years.
What’s Next
The control plane is designed to grow. Every capability that currently requires manual hardware configuration is a candidate for a future profile setting.
Future capabilities will include station pinning — tying a specific device to a specific base station for use cases that require it — and auto-provisioning, where a device powers on and joins the network without credentials. (Think eSIM in cellular.) The architecture makes that kind of zero-touch deployment tractable in a way that a static corrections pipe cannot.
The deeper point is: corrections have been treated as a utility for many years — a static feed you tap into and accept as-is. But the use cases we’re seeing now don’t fit that model. Fleets of robots, consumer devices on cellular plans, autonomous vehicles with safety requirements, industrial systems with hard cost constraints — all need a corrections network that adapts to them, not one they have to work around.
SDCN is the first RTK corrections network you can program. Every corrections provider gives you a network. Point One gives you one that does what you tell it.
Define how it looks and behaves — down to the device, in real time, through a single API.