Steve Allen wrote on 2003-12-23 19:46 UTC:
> Of course no agreement can stop some entity from flying a jamming
> rig for both systems over particular theatres of interest.
Robustness against U.S. "navigation warfare" was one of the main funding
rationales for Galileo. The U.S. are unlikely to jam easily their own
military (M-code) navigation signal. As I understood it, the original
plan for Galileo was to put its own Public Regulated Signal (PRS) into
the spectrum in a way such that the U.S. cannot jam it without jamming
their own M-code as well. This improves robustness against adverse US
DoD capabilities and also simplifies tremendously the design of
receivers that can listen to both GPS and Galileo (which I expect will
be all new receivers as soon as Galileo is up and running).
Status of Galileo Frequency and Signal Design:
http://europa.eu.int/comm/dgs/energy_transport/galileo/doc/galileo_stf_ion2002.pdf
http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=61244
Status of new GPS M-code design:
http://www.mitre.org/work/tech_papers/tech_papers_00/ betz_overview/betz_overview.pdf
DoD versus EU battle:
http://www.globalsecurity.org/org/news/2002/020514-gps.htm
>From a recent local press review:
-------------------------------------------------------------------------
EU and US fail to agree on interoperability of satellite navigation systems
Discussions between the European Union and the US in Washington
concerning the interoperability of the EU's proposed Galileo satellite
navigation system and America's existing GPS service have ended without
agreement, according to reports in the New Scientist.
The sticking point is said to be the standard signal that the EU would
like to use for Galileo. Europe's preferred option, known as binary
offset carrier (BOC) 1.5, 1.5, would give users of Galileo the most
accurate information possible, but the US argues that this would
interfere with the GPS system's proposed new encrypted military signal.
The US intends to introduce the new signal, known as the M-code, in
2012. During a military conflict, the US would attempt to jam all
civilian satellite systems so as not to allow enemies to use satellite
navigation. But jamming Galileo's BOC 1.5, 1.5 signal, argue US
officials, would also disrupt its own M-code.
The US proposes that Galileo uses an alternative signal, such as BOC
1.1, which does not overlap the M-code signal, but the EU is concerned
that this will result in a less accurate system for commercial users of
Galileo.
Officials from the EU and the US will meet later in February to try to
resolve the issue.
For further information on Galileo, please consult the following web
address:
http://europa.eu.int/comm/dgs/energy_transport/galileo/index_en.htm
-------------------------------------------------------------------------
The use of the word "interoperability" for the feature that the operator
of one system can jam the other one without affecting its own has a neat
Orwellian ring to it.
>From what I hear behind the scenes, plans for Galileo are now to make
the transmitter and receiver designs highly flexible, such that code
rates, spreading sequences, BOC offsets, and perhaps even carrier center
frequencies can be reprogrammed smoothly on-the-fly while the system is
in operation, to be able to adapt to adverse actions and the current
political climate. Apart from moving the center frequency around
significantly (which clearly affects the design of the RF hardware very
much on each end), most of the remaining DSP and PLL parameters can
today quite easily be made reconfigurable in software at little extra
cost.
We may consider our deliberations on leap second rather abstract and
academic here, but outside the ivory tower, the reliable distribution of
nanosecond-accuracy timing signals has meanwhile become not only a
military concern, but also the topic of a serious turf fight between the
Pentagon and the EU Commission.
Is seems the Temporal Cold War has begun ...
Markus
--
Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
Received on Thu Feb 05 2004 - 04:56:28 PST