OSR to SSR: What Changes When PPP-RTK Corrections Stop Looking Like a Base
On this page
TL;DR
Observation Space Representation (OSR) delivers reference observations to an RTK receiver; State Space Representation (SSR) delivers separate correction states for a capable Rover to apply. PPP shares satellite orbit and clock products globally, PPP-AR adds phase biases for integer fixing, and regional PPP-RTK adds atmospheric corrections to shorten convergence where coverage supports it.
RTK Goes Networked ended with gridded corrections: a network estimates regional errors and shares correction output among multiple Rovers.
The network already has separate estimates for satellite, signal, and atmospheric errors. Why rebuild a Base-shaped observation stream instead of sending those estimates to the Rover?
The two answers are Observation Space Representation (OSR) and State Space Representation (SSR). The interface choice sets receiver requirements. The correction content behind it then determines convergence, regional station needs, and how widely the service can broadcast.
OSR vs SSR: Does the Rover Receive Measurements or Apply a Model?
A GNSS observation mixes several things into one measured value: receiver-to-satellite geometry, satellite orbit and clock error, atmosphere, hardware bias, carrier-phase ambiguity, and local effects such as multipath and receiver noise. A reference network knows its station coordinates and observes continuously, so it can estimate the satellite, signal, and regional atmospheric parts that other users can reuse. Those separately estimated parts are correction states.
What Is Observation Space Representation (OSR)?
OSR delivers reference observations and coordinates. A physical Base can send measurements it actually made; a network can apply its model at a Virtual Reference Station (VRS) position and generate Base-shaped observations. In either case, the Rover combines the reference data with its own measurements for a differential RTK solution.
Existing RTK receivers can use this stream, and a well-supported regional RTK or VRS network can often reach Fixed in seconds. Sustaining that experience across a service area takes continuously operating reference stations (CORS), quality checks, and compatible reference streams throughout the coverage area.
What Is State Space Representation (SSR)?
With SSR, the service sends the model components themselves: precise satellite orbit and clock, signal biases, and, where available, regional ionospheric and tropospheric information. The Rover applies the relevant states to its own measurements, using their timestamps, validity limits, and available quality indicators.
The same network estimates can feed two Rover interfaces; the handoff changes where the model is applied:
| Question | OSR | SSR |
|---|---|---|
| What does the service send? | Physical-Base or modeled-VRS observations and reference coordinates | Separate satellite and signal states; regional atmosphere when supplied |
| Where is the model applied? | A physical Base supplies its own observations; VRS modeling happens before delivery | At the Rover's position in its positioning engine |
| What does the Rover do? | Differential RTK with its own observations | Corrects its observations, then estimates the remaining unknowns |
| What must the receiver support? | A compatible RTK or VRS stream | The specific states, signals, bias conventions, and validity rules |
| What drives service design? | Regional CORS coverage and reference-output quality | Global satellite products; regional atmosphere when fast PPP-RTK is required |
PPP in GNSS: One Satellite Model, Many Rovers
Precise Point Positioning (PPP) combines a Rover's own code and carrier-phase observations with precise satellite orbit and clock products. Those satellite products describe the satellites, not an individual Rover, so the same set can serve receivers across a wide area.
From the 1990s onward, continuous global reference stations and precise orbit-and-clock processing made that approach practical. The network estimates satellite products; each Rover then estimates its own position, receiver clock, tropospheric delay, and carrier-phase ambiguities.
At its 2013 launch, the IGS Real-Time Service used data from about 150 globally distributed real-time stations to produce orbit-and-clock streams. Stations spread around the globe can support shared satellite products without placing a Base near each Rover.
The same satellite products can reach many users, including by broadcast. Each Rover still estimates its local atmosphere and ambiguities.
PPP vs PPP-AR vs PPP-RTK: How Long Does Convergence Take?
The practical difference between RTK and standard PPP is often time to the required accuracy: a regional RTK network can fix integer ambiguities in seconds, while conventional PPP may take tens of minutes to converge.
PPP-AR adds consistent phase-bias products to precise orbit and clock, allowing the Rover to resolve integer carrier-phase ambiguities. The RTK Trick explains why that fixed integer matters. PPP-RTK also supplies regional ionospheric and tropospheric corrections, so the Rover spends less time estimating the atmosphere alone.
As the service supplies more of the missing information, the Rover generally reaches its target accuracy sooner:
| Route | Service adds | Rover still estimates | Typical experience |
|---|---|---|---|
| Network RTK / VRS | Regional model evaluated as reference observations | Baseline ambiguities and local effects | Seconds, often near-instant |
| Standard PPP | Precise satellite orbit and clock | Atmosphere and float ambiguities | Tens of minutes |
| PPP-AR | Orbit, clock, and consistent phase biases | Much of the local atmosphere | About 1–3 minutes in advanced services |
| PPP-RTK | Satellite states, phase biases, and regional atmosphere | Local effects and model applicability | About 10 seconds to a few minutes |
u-blox lists 1–2 minutes to <10 cm for PointPerfect Global PPP-AR and 10–30 seconds for regional PointPerfect Flex under its own test conditions. Compare services at the same accuracy threshold and with the receiver, sky view, and re-fix behavior your project will use.
If a static or periodic task can wait minutes, PPP or PPP-AR may be enough. Dynamic farm machines, outdoor robots, and systems that must recover quickly after blockage have a stronger case for regional PPP-RTK. SSR describes the correction interface; it does not guarantee PPP-RTK content. An orbit-and-clock-only SSR stream supports PPP, not full PPP-RTK.
Regional Atmospheric Corrections: Why Faster Convergence Brings Geography Back
Orbit and clock states describe satellites and can be reused globally. Ionospheric and tropospheric delay occur along the signal path to the Rover; they change with location, time, satellite elevation, weather, and ionospheric activity. To approach RTK's seconds-level fix, PPP-RTK needs regional atmospheric corrections relevant to the Rover's location.
How Dense Does a PPP-RTK Network Have to Be?
PPP-RTK has no fixed station-spacing rule. Network RTK stations are often about 50–70 km apart. Fast PPP-RTK also needs regional observations, so providers can reuse existing CORS infrastructure.
A minute-level target may allow wider spacing in calm conditions. Seconds-level fixing, fast recovery after an outage, or active ionospheric conditions call for closer stations, well-covered network edges, and tighter quality control. Test spacing against the required convergence and continuity in the actual service area.
The Rover also needs to know whether an atmospheric state is still usable: its age, valid area, uncertainty, and integrity matter along with the correction value itself. Outside the valid area, a fast Fixed solution can still be wrong.
SSR2OSR: One Model, Two Rover Interfaces
A state-capable Rover can receive SSR and apply each state at its own position. With SSR2OSR, the service instead chooses a reference position, evaluates the states there, and generates Base-shaped observations for a conventional RTK Rover. Choosing the position and synthesizing observations makes this a model calculation, not a lossless byte conversion.
That RTK-facing output can keep a deployed receiver fleet working with regional corrections. Native SSR lets a supported receiver apply satellite and regional states at its own position, provided its positioning engine understands the service's states, signals, and bias conventions.
Engineer's Note: Check the Receiver Interface
For an installed RTK fleet, test SSR2OSR or VRS before replacing hardware. For a new design, check native SSR support. Either way, measure time to the required accuracy and recovery on the intended service. If the output is OSR, verify its RTCM messages and station metadata against the firmware's supported input.
Internet or Satellite: Transport Is Not the Correction Model
A correction service makes four separate decisions, and transport is only one of them:
| Layer | Question it answers | Examples |
|---|---|---|
| Positioning architecture | How does the Rover solve? | RTK, PPP, PPP-AR, PPP-RTK |
| Correction representation | Reference observations or separate states? | OSR, SSR |
| Message and encoding | How is the information packaged? | RTCM, SPARTN, proprietary formats |
| Transport | How does it reach the receiver? | Radio, NTRIP/IP, L-band, GEO or GNSS signal |
NTRIP carries corrections over IP; a satellite link broadcasts them from space. Neither path decides whether the payload is OSR or SSR. Ground stations and processors still produce the corrections before an uplink distributes them.
Satellite orbit, clock, and bias states can serve every Rover in their valid area, making SSR a good fit for one-to-many delivery over navigation signals, L-band, or GEO links. Shared state delivery can use less capacity than per-user VRS; actual bandwidth still depends on satellite and signal count, update rate, atmospheric-grid detail, and encoding. Gridded VRS shows that OSR can also share a stream.
Galileo HAS delivers orbit, clock, and code-bias corrections through E6-B and the internet. BeiDou PPP-B2b broadcasts orbit, clock, and code-bias information via GEO. Both show state-based wide-area delivery; neither broadcast alone supplies every regional atmospheric and phase-bias product needed for fast PPP-RTK.
Conclusion: Choose by Convergence, Coverage, and Receiver Capability
When evaluating a correction service, ask four questions:
- How quickly must the Rover reach the required accuracy? Are tens of minutes acceptable, or must recovery happen in seconds?
- Which states are supplied? Is it orbit and clock only, or are phase biases, regional atmosphere, and quality included?
- How local and current is the atmospheric model? Check station coverage, valid area, age, uncertainty, and behavior at the edge.
- What can the receiver actually apply? Does it expect OSR/VRS observations or support this service's SSR states?
Neither interface removes multipath, blocked signals, interference, antenna problems, or receiver noise at the Rover. Even a Fixed result still needs the right coordinate frame, epoch, and datum.
The Engineering Takeaway
The Base did not disappear. It stopped being the correction interface every Rover had to receive.
Frequently Asked Questions
What is the difference between OSR and SSR?
Observation Space Representation (OSR) delivers observations from a physical Base or a modeled Virtual Reference Station. State Space Representation (SSR) delivers separate satellite and signal corrections, plus regional atmosphere when available, for the Rover to apply. A reference network can produce either output. OSR suits compatible RTK receivers; SSR requires an engine that understands the supplied states.
Is SSR the same as PPP-RTK?
No. SSR describes how a service represents corrections; PPP-RTK is a positioning approach that needs precise orbit and clock, consistent phase biases, and regional atmospheric corrections for fast fixing. An SSR stream carrying orbit and clock alone supports standard PPP. Adding phase biases can support PPP-AR, while fast PPP-RTK also depends on a usable regional atmospheric model and receiver support.
What is the difference between PPP and PPP-RTK?
PPP-RTK adds phase biases and regional atmospheric corrections to the globally reusable satellite orbit and clock products used by standard PPP. With orbit and clock alone, the Rover still estimates much of its local atmosphere and carrier-phase ambiguities, which can take tens of minutes. PPP-RTK can shorten that wait to minutes or seconds inside a region where those additional corrections are available.
How long do PPP, PPP-AR and PPP-RTK take to converge?
Standard PPP often takes tens of minutes, advanced PPP-AR about 1–3 minutes, and regional PPP-RTK about 10 seconds to several minutes. Those are indicative service experiences, not fixed properties of OSR or SSR. Compare results at the same accuracy threshold and with the receiver, sky view, and regional coverage your project will use; test both first fix and re-fix after signal loss.
Does PPP-RTK need the same reference-station density as Network RTK?
Not always. Network RTK stations are often about 50–70 km apart, and fast PPP-RTK services can reuse those CORS sites to model regional atmosphere. A minute-level target may permit wider spacing in some areas. Seconds-level fixing and difficult atmospheric conditions call for more regional observations; near the network edge, fast fixing also needs adequate station coverage and continuous quality control.
Can a traditional RTK receiver use a PPP-RTK backend?
Yes, if the provider offers a compatible SSR2OSR output. The service evaluates its state model at a reference position and generates Base or VRS observations, usually in RTCM, for the RTK receiver to process. This preserves an installed receiver fleet when the output matches its supported messages. Direct SSR instead needs an engine that supports the provider's states, signals, and bias conventions.
Continue exploring
GNSS Errors Mapped
See which errors a correction service can model and which remain local to the Rover.
LateralRTK Accuracy Trap
Translate a fast Fixed solution into a defensible field-performance test.
ApplyRTK GPS for Robotics
Bring correction continuity and re-fix behavior into outdoor robot navigation.
