Hi,
> Yes, it's really time for some "modern" packet radio modulation that
> uses dsp. Point-to-point links should use training sequences and
> select a modulation and pre-distortion that makes optimum use of the
> bandwidth for a given S/N. They could retrain once in a while to adapt
> to changing weather conditions or persisting qrm.
I think we ought to cleanly destinct between interlink and user access
channels. While bad conditions on interlink channels are comparativly
easy coped with (use large PA, better antennae with smaller opening
angle
and more gain,...) it is *really* time to act on the user access side.
Our requirements are as follows:
- self-configuring system on user side
- reasonable channel access
- real-time support (i.e. bandwith allocation/QoS and heavy coding)
- authentication
- hybrid-ARQ-II for bulk data transfers for optimum throughput
AX.25 on HDLC is *not* the ideal solution for wireless applications. We
need
to rethink Layer 1 and 2 completely. The result may look like a
combination
of the GSM system and ATM. AX.25 could be run "on top" of this in "bulk
data"
transfer mode if really neccessary. Phil Karn�s paper "Towards new link
layer
protocols" show some ideas going into the right direction.
> This would also work for uplinks, provided they use some organized access
> protocol, like dama.
The system I have in mind is a system where every user station is not
polled,
but knows when it is allowed (requested?) to send. That means it ought
to
be some sort of time slice operated system like GSM with one control
time
slot (BCCH), which is used to sync the user station�s timers. As soon as
a user logs in via a randon-access slot (reserved only for this purpose
-
log in) it gets assigned one "control slot" which it can use to
communicate
with the master station (digipeater) to - for example - request more
bandwith for the next cycle. The difference to the old "DAMA" system
would
be, that the stations need not to be polled, but *know* when they may
send
and when not. The "BCCH"-like channel also could be used to send
training
sequences or beacon data and things like this, which could in turn be
used
to auto-configure user stations (channel equilization etc.).
Two different requests for bandwith ought to be implemented: Request for
"realtime" bandwith (first class) and requests for bulk transfer.
Alternatively
every piece of bandwith not reserved for realtime traffic (voice, video
conference etc.) could be "filled" with bulk data. Bulk data here would
mean the complete range of modes commonly referred to today as "packet
radio" -
mail, news, www, ftp.
> That way, the modulation characteristics of the
> station sending next would be known in advance, so the master station
> could use the correct decoder and parameters.
I think the key word here is channel coding, in particular forward error
correction (FEC). Real time applications need heavy FEC, because there
is no time for retransmits, buld data should be transferred using
hybrid-
arq, thus meeting (at least getting in range of) the shannon-capacity of
the given channel.
> A station attempting to
> join the channel could use a very slow default modulation and then
> be prompted for a training sequence by the master. The master's signal
> could also contain clock information to make re-synchronization for
> each individual transmission unnecessary.
In fact the same modulation type could be used for all stations, as long
as clock recovery is guaranteed, only the coding rate had to be
adjusted.
> (Even mobile stations that have access to exact position information
> could remain in sync by computing the correct delay. Varying
> reflections might be a problem, though, so they would have to use
...training sequences or something...
Of cause, varying reflections will only occur when one of the station
is mobile. When standarizing a new protocol this should be taken into
account, but at first I think we could do without mobile support.
> Has anything like this been tried yet? I think it would be very
> interesting indeed.
See http://www.afthd.tu-darmstadt.de/~dl8aau for 2FSK-with-RS-FEC and
4FSK DSP modem designs. These ideas were presented during the 14.
International Packet Radio Symposium in Darmstadt, Germany. The idea
to modify Tom�s soundmodem driver in that way is pretty old, too. I
think
the only questions we have to ask ourselves is:
- Who designs the new protocols?
- Who needs/accepts them? Is this going to succeed?
-- Jens
