Most GNSS receivers process signals serially. This is natural for tracking loops based on PLLs and DLLs, as they have a feedback structure. If signals are recorded and stored, however, another viewpoint might be more flexible.
Let's regard the recorded waveform as a series of chunks of length, say, 5 minutes. All these chunks can be processed in parallel, though at the cost of ambiguities in whole cycles of carrier phase for each chunk. (Let's assume that acquisition or aiding has already allowed each chunk processor to start with good estimates of code phase and doppler, and that suitable guard intervals allow the tracking loops to converge somewhat in advance of the start of each chunk, so that effectively the chunks overlap a little.) Once all chunks are processed, whole cycles of carrier phase are simply cumulatively summed. This reduces the ambiguity set to the normal case of just a single ambiguity for the whole interval of the satellite pass (assuming no cycle slips or loss of lock).
So an attractive GNSS processing scenario might be:
- deposit all waveforms in a central place, such as one of the cloud computation environments like Amazon's S3 and EC2
- do all processing of interest in parallel, by allocating as many processors as needed; place intermediate results as annotations on a common scoreboard
- coalesce the results, obtain observables, and post-process
By having the entire waveform accessible at once to a common pool of processors, a kind of annotation-based processing becomes possible. First, acquisition might be performed at fixed intervals, possibly aided by a location estimate and orbit estimates from IGS. Once the file has been annotated with acquisition results, each chunk can be tracked as outlined above. Vector tracking, differencing at the correlator level, quality monitoring, etc. can all be included as additional workflow options.