I can't understand why GPS reciever clock is very good (stratum 0). I know it's very accurate and pure within itself; but when it passes through a long distance wireless channel, then it has low power and much noise and jitter, so how it can be better than other clocks?
Electronic – gps performance for synchronization
First thing you need to recognize is that designing with a 16-bit ADC is not trivial. Even at 1 sample/s, you need to pay extreme attention to every aspect of the design to achieve 16-bit precision, or even more difficultly, 16-bit accuracy. At 130 MSa/s, everything is even more difficult.
The parts you need to do this kind of design simply won't be inexpensive. First, because of the extreme precision and careful testing needed to achieve the required performance. Second, because this kind of thing isn't done in mass-market products, so the parts aren't built in the kind of extremely high volumes that can bring the price down for everyone.
As Dave says in another answer, be sure you really need 16 bits before you go down this road. But maybe you really need 12-bit precision, and you know that if you use even a 14-bit ADC you're going to have a hard time achieving that, so you're designing with 16-bit ADC and optimize everything else as much as you can.
Another key is likely to be understanding exactly what specs you need to make your system work, and don't over-specify your clock jitter. In an SDR application, you're going to be doing math on the samples to extract specific frequency bands, etc, which will have an averaging effect over many cycles. So you might not care too much that absolutely every sample is timed perfectly, only that over your calculation interval, there isn't too much deviation from ideal timing. How much is too much, of course, depends on what kind of math you're doing and how small a signal you need to extract from how much noise.
CTS Valpey, for example, has XO's with rms jitter specs as low as 200 fs. But this spec is defined when the phase noise is integrated over a specific frequency band, 12 kHz to 20 MHz (relative to the carrier). If the total cycle-to-cycle jitter is considered, the spec jumps to 3-6 ps, depending on the center frequency.
Let me also address one comment you made in your question:
OCXO are extremely stable over time ( years ) and are usually used for that.
The "ovenized" part of that product mainly reduces the drift due to temperature change in the surrounding environment, which can be significant over time scales of minutes or seconds, not just years. It will also reduce wear on the part due to thermal cycling and improve the stability on a time scale of years.
For the < 100 fs jitter range you're looking for, you might actually need an OCXO to prevent small temperature changes affecting the performance during the time it takes to measure the jitter accurately enough to know you've achieved your spec.
Counting cycles between PPS pulses is not a good approach. Even using clocks with 10ppb stability, you still need to evaluate the skew between different units.
Using an integrated GPS Receiver with timestamping is a good approach. Note however that it will not be easy to get these 30ns RMS accuracy in real life conditions. 30ns translate to only 9m position accuracy. While most receivers reach this easily for kalman filtered position, you will see more disturbance to your timestamps (where the receiver cannot employ a hidden markov model) unless you also average over multiple events.
Multipath reception is your main adversary (for units some tens of km apart and events within fractions of a second). Multipath will be mitigated somehow by the receiver, but the best thing you can do is use a good antenna (choke ring or similar) and choose a good place. Putting it on a tripod can also help.
Group delay calibration will typically not be needed for 30ns if all your modules use a similar Setup (antenna cable length matters, also amplifiers or similar).
Far better accuracy can be reached if you are able to measure the event in band with the GPS Signals, that means trough the RF frontend of the reveiver. This will relate the timing directly to the received signals and offers the opportunity to cancel off several error sources. If you do not need the result in near real time, you may record GPS signals together with your trigger and postprocess them. This will give high accurary of relative position and time (differential GPS).
A GPS receiver creates a local replica of something called "GPS system time", which is a virtual timebase created from all of the clocks on the satellites and ground stations. This replica is integral to the process of coming up with a navigation solution, which is based on measuring the signal delay from each satellite to an accuracy on the order of nanoseconds.
The algorithm that keeps this replica synchronized guarantees that there is no long-term drift with respect to GPS system time. Furthermore, it is specifically designed to deal with the errors introduced by the radio channels, so there is minimal jitter as well.
It is relatively easy to provide outputs based on this replica timebase, typically in the form of 1 pps or 10 MHz logic-level signals. Usually, the biggest source of jitter in these outputs is due to the fact that the replica timebase is asynchronous with respect to the receiver's own physical clock.
Therefore, the peak-to-peak jitter of these outputs is usually equal to the local clock period1, the short-term stability is equal to the stability of the local oscillator2 and the long-term stability is equal to GPS system time, which is based on atomic clocks. A PLL can easily filter out the jitter if the application requires it.
1 Many receivers have 10.23-MHz local clocks, which is why you frequently see a specification of ±50 ns on the 1 pps output.
2 Quartz oscillators generally have very good short-term stability. In fact, the best laboratory-grade quartz oscillators have better short-term stability specs than cesium time standards.