Jens:
Thanks for your very informative message. I'm just getting into
packet and I'm trying to learn all I can about the current state
of packet (at least mainstream packet use), which is why I
inquired about your feelings about HDLC. I see your point now-
given the current scenario, we could greatly benefit by moving
towards a more sophisticated approach such as that what you have
described. The coding scheme you've described here is very
interesting. Thanks for the information.
Chris Ruffin
--
Chris Ruffin <[EMAIL PROTECTED]>
http://www.ece.msstate.edu/~ruff/
On Thu, Oct 28, 1999 at 06:59:51PM +0200, Jens David wrote:
> Hi Chris,
>
> > Jens:
> >
> > Isn't the current link layer protocol high-level data link
> > control? That is a widely used data link layer, and I don't
> > understand why you think it should be changed, altough I'd like
> > to hear your thoughts.
>
> I don�t think that HDLC should be changed - I just stated that its
> use in the amateur radio domain is not apropriate.
> You use the shannon formula for channel capacity, insert 15 dB S/N
> and 25 KHz bandwith. This gives you a theoretical maximum capacity
> of about 125 Kbps. You you know of any amateur radio equipment which
> is able to achieve this? The answer is for sure no. The truth is,
> this capacity is vitally unreachable. However, by means of high
> efficient channel coding (e.g. turbo codes) you can reach that
> limit by about 0.5 dB (S/N). At our current setup, if you receive
> one error in a frame, the complete frame is lost. By means of redundant
> channel coding, you can add redundancy to a packet - which - if done
> right will increase the effective throughput. There is a technique
> called "Hybrid FEC/ARQ II", sometimes also referred to as "Memory ARQ
> type II" which allows you to get the outmost of a link if some
> requirements to the equipment in use are met. Another requirement -
> and this is of importance here - is, that the link layer protocol
> is very closely intervened with L1. That is, instead of saying "please
> transmit this frame again" you say "I need so-and-so-much more
> redundancy
> in order to decode your frame X". That is, you start with transmitting
> the least redundancy possible, if it can be decoded at the receiver it�s
> fine, if not the receiver will request more redundancy for that block.
> The repeated information will be merged with the data received first
> which gives you two times the security you had when receiving it the
> first time. Note that with our current functionality it is quiete
> likely that the second try contains a bad bit again and again the
> frame must be dropped. With the ARQ-FEC II scheme it is in fact
> _very_very_
> unlikely that the frame cannot be decoded now. To make a long story
> short,
> we can use the channel more efficiently for bulk data transfer. This is
> especially important on user access channels.
> The other thing is, here in Germany we are quiete close to being
> able to do real-time voice and video conferencing over our packet
> radio network. In my opinion we need real-time support on the link
> layer protocol in use on these user entrances. There must be some
> means of allocating bandwith on a channel. In addition to this,
> you do not have the time to repeat any frames. Thus, real-time
> traffic needs to be encoded with little coding rate (i.e. a lot
> of redundancy). To configure this all, there must be some (logical)
> control channel between the user and the master node on the channel.
> The resulting protocol could be some mixture between GSM and wireless
> ATM.
> Moreover the user stations at logon to the net should be auto-aligned.
> This includes adjusting the internal timers, channel access parameters
> as well as physical (electrical) parameters such as deviation and mean
> frequency, modulation type in use, power emission. S/N could be measured
> to determine the standart coding rate and so on.
> While we are at it we could implement some sort of authentication
> sub-protocol to keep CB-guys out.
> The list of possibilities is endless, so is the fun of implementing it,
> we�d just need to do some standarization.
> Please take a look at Phil Karn�s homepage
> (http://people.qualcomm.com/pkarn
> or something). See "Towards new link layer protocols" - although this is
> slighly outdated it�s still current until we get this one fixed.
>
> Copy for the linux-ham list for discussion. Hope you don�t mind.
>
> -- Jens
