Topics

PHY Layer Protocols


dsp_stap@...
 

--- John Hays K7VE wrote:
>Raw TCP/IP packets will need some kind
> of synchronization training sequence at
> the beginning.

Right.  Each lower layer wraps the previous upper layer in its own header and trailer before sending.  The PHY layer's header is for synchronization and error correction.

> Right now we have two Amateur protocols
> that provide framing around TCP/IP and
> handle the synchronization as part of their frames.
>
> TCP/IP runs within a UI AX.25 frame.
> TCP/IP runs within Ethernet Frames inside of D-STAR frames.

> ... create more robust and efficient air protocols,
> e.g. forward error correction, header compression ...

Really? D-Star has no FEC??  I'm shocked!!  (And horrified!)  If it were possible, I would now have an even lower opinion of D-Star than I had in the past.

The ARETF needs to develop a PHY layer protocol, or perhaps even more than one.  We should look to 802.1x for ideas.

All PHY layer protocols should do FEC, and synchronization.  Perhaps we need a very simple PHY layer that does only that, for simple point-to-point links.

Then perhaps we need more complex PHY layers which handle media access (to minimize collisions and thus maximize throughput).

How fast will Xmit/Recv switching be?  Will it be fast enough for TDMA?

Finally, I'm thinking we want more complex LINK layer which would handle discovery, link establishment, ad-hoc networking, etc.

It is not clear to me how to handle frequency selection. It is clear to me that if we can solve the problem of using multiple chanels simultaneously in a network, it has the potential to increase aggregate network throughput. Frequency selection is part of the physical layer, but perhaps it should be controlled at the link layer.  On the other hand, how do you tell all nodes who might want to talk to node X that he has moved to channel Y?  What about the choice to QSY? Should that control be centralized?  That seems like a bad idea, but it is also not clear how to do it in a distributed fashion.  What happens when node Z didn't get the message, and continues to waste bandwidth on channel X, talking to node X, when node X has QSYed to channel Y?

I think there is possibly a Ph.D. thesis lurking in the problem of channel selection controlled at the link layer. I note that NOBODY has done it yet.  I've never read any academic papers on the subject.  And it is such an obvious solution; hams have been doing it on nets for passing traffic for almost 100 years -- maybe longer.

All of a sudden, ham radio is fun again.

73,
Ken N8KH


myyahoo@...
 

FEC is just overhead unless you really need it. On nearly loss-less channels (which is what we should expect on short haul 70 cm links), you lose more throughput than you gain with FEC. If we were talking about long haul lossy links (as on HF), then FEC can be a winner. This is a reason that D-Star does not use FEC (and no one is complaining about packet loss there), and I don't believe that we'll need it for most applicaitons either. Time will tell, and there's nothing stopping anyone from comparing FEC to non-FEC transmissions and measuring it in real life...

You ask some interesting questions about channel allocation and use - I doubt that we will settle this before the radio ships, it is something that I know that I will be experimenting with - and I know that others will be doing the same. The beauty of SDR is that the standard doesn't need to be cast in stone, and there may be reasons for more than one standard depending on the network topology (a few stations scattered along a long distance may need a different solution than a city full of adjacent stations). Even after the first standard(s) are in place, if experimentation comes up with a better scheme some time later - it's trivial to load new software and reinvent the entire network!

As to channel allocation, one suggestion is to use an ISDN-like approach, with a fixed, narrow control channel that does all (or most) of the channel assignments, and then the rest of the bandwidth can be sliced-and-diced as needed. Deciding how this is coordinated among stations that do not have complete connectivity with one another (a distributed mesh) is one of the issues that needs to be tackled - but there are some simple allocation schemes that can be used to start. I certainly don't want to see a master/slave approach, but more like 'cooperating masters', where every station is part of the control puzzle. Some heuristics can be built to map the network and determine how to best use the channels at any given time, and give appropriate QOS based on the type of traffic - e.g., audio traffic is much more sensitive to latency than email or SSH connections.

- Richard, VE7CVS


"John D. Hays" <john@...>
 



On Mon, Mar 2, 2015 at 5:26 PM, dsp_stap@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 
> ... create more robust and efficient air protocols,
> e.g. forward error correction, header compression ...

Really? D-Star has no FEC??  I'm shocked!!  (And horrified!)  If it were possible, I would now have an even lower opinion of D-Star than I had in the past.


D-STAR does use FEC in the AMBE sub-frames, but it was not specified for the entire packet or payload.  The D-STAR Data (DD) implementation simply wraps Ethernet frames and does not have FEC.

--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Marshall Denny <MarshallDenny@...>
 

Consider that we could have multiple levels of FEC including none with the receiver being able to decode any of the available options.

1. UI/UDP broadcast could use strong FEC
2. Initial connection modes could start with strong FEC and then switch to low FEC or no FEC based on conditions of the specific link.

In general, consider using "and" rather than "or" in these types of situations, we have the potential of a lot more flexibility today than in the past.  

The memory available in a  raspberry pi compared to a TNC of the past is the difference between night and day.




Respectfully,
Marshall Denny
Technical Architect, Contractor
AT&T
425 288 6443 office
206 842 9305 home
206 734 9242 cell

Politicians and diapers should be changed frequently and for the same reason.
-- unknown

On Tue, Mar 3, 2015 at 7:56 AM, myyahoo@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

FEC is just overhead unless you really need it. On nearly loss-less channels (which is what we should expect on short haul 70 cm links), you lose more throughput than you gain with FEC. If we were talking about long haul lossy links (as on HF), then FEC can be a winner. This is a reason that D-Star does not use FEC (and no one is complaining about packet loss there), and I don't believe that we'll need it for most applicaitons either. Time will tell, and there's nothing stopping anyone from comparing FEC to non-FEC transmissions and measuring it in real life...

You ask some interesting questions about channel allocation and use - I doubt that we will settle this before the radio ships, it is something that I know that I will be experimenting with - and I know that others will be doing the same. The beauty of SDR is that the standard doesn't need to be cast in stone, and there may be reasons for more than one standard depending on the network topology (a few stations scattered along a long distance may need a different solution than a city full of adjacent stations). Even after the first standard(s) are in place, if experimentation comes up with a better scheme some time later - it's trivial to load new software and reinvent the entire network!

As to channel allocation, one suggestion is to use an ISDN-like approach, with a fixed, narrow control channel that does all (or most) of the channel assignments, and then the rest of the bandwidth can be sliced-and-diced as needed. Deciding how this is coordinated among stations that do not have complete connectivity with one another (a distributed mesh) is one of the issues that needs to be tackled - but there are some simple allocation schemes that can be used to start. I certainly don't want to see a master/slave approach, but more like 'cooperating masters', where every station is part of the control puzzle. Some heuristics can be built to map the network and determine how to best use the channels at any given time, and give appropriate QOS based on the type of traffic - e.g., audio traffic is much more sensitive to latency than email or SSH connections.

- Richard, VE7CVS



Jim Alles <kb3tbx@...>
 

I am just lurking in this group, but consider this:

Wireless HART is a channel-hopping mesh network, and utilizes a network manager. It does not fit the use-case, but there might be some interesting ideas.

I have additional PDFs if anyone is interested.

Jim Alles, KB3TBX
Penn State Univ. DDC technician


"Michael E Fox \(N6MEF\)" <n6mef@...>
 

True.  But the problem is, many (most?) “real world” channels in a metro area (<25 miles) are NOT “nearly loss-less”.   On many (most?) real-world channels, you will get single bit errors, causing the whole packet to be retransmitted.  Longer packets = greater probability of error.  Shorter packets = more header overhead.  End result is still lower throughput (often much lower) than with FEC.  It’s not a hard test to duplicate with 9600 baud packet.  It’s also not hard to duplicate with commercial digital radios although it does require a rather expensive analyzer to see the data.  That’s why the commercial digital radio world uses FEC.  The whole rest of the world is not wrong.

 

So, yes, it’s overhead and yes, we need it. 

 

Michael

N6MEF

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...]
Sent: Tuesday, March 03, 2015 7:56 AM
To: UniversalDigitalRadio@...
Subject: [UniversalDigitalRadio] Re: PHY Layer Protocols

 

 

FEC is just overhead unless you really need it. On nearly loss-less channels (which is what we should expect on short haul 70 cm links), you lose more throughput than you gain with FEC.


Bill Vodall <wa7nwp@...>
 

On many (most?) real-world channels, you will get single bit errors, causing the whole packet to be retransmitted.
Since we have the source, it should be possible to add the bad-bit
correction that's been successfully implemented in both UZ7HO and DIRE
WOLF software modems.

Also there's the FX25 project adding FEC to AX25 that could be looked at...

http://www.stensat.org/docs/FX-25_01_06.pdf

Bill


Michael E Fox - N6MEF <n6mef@...>
 

Yup.  And according to what I've read about FX.25, it's evidently backwards compatible with AX.25.  So while a more sophisticated, dynamic approach would be nice, it seems like something simple like FX.25 would allow us to deploy.

M



Sent from my Verizon Wireless 4G LTE smartphone


-------- Original message --------
From: "Bill Vodall wa7nwp@... [UniversalDigitalRadio]"
Date:03/03/2015 3:42 PM (GMT-08:00)
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Re: PHY Layer Protocols

 

> On many (most?) real-world channels, you will get single bit errors, causing the whole packet to be retransmitted.

Since we have the source, it should be possible to add the bad-bit
correction that's been successfully implemented in both UZ7HO and DIRE
WOLF software modems.

Also there's the FX25 project adding FEC to AX25 that could be looked at...

http://www.stensat.org/docs/FX-25_01_06.pdf

Bill


myyahoo@...
 

Not all services will need FEC, some are more fault tolerant than others. I would say that FEC at the lowest level should be optional - at best, and than it could certainly be incorporated at a higher level for applications least tolerant to packet loss. Fixed-to-fixed services are much less likely to benefit from FEC, while I can see that mobile apps may benefit from it.

At these speeds, interference is likely to impact more that the occasional single bit, which is why FEC overhead may not be worth the trouble.

I can say that from previous experience at 56 kbps on 70 cm (both fixed and mobile), packet loss was very low, and giving up even 10% to FEC would have been wasteful - for typical terminal sessions. Encoding voice in a more resilient way, including either FEC or other tricks (silence/replication for lost segments) could provide a better experience.

But I wouldn't make FEC at the packet level a mandatory requirement until shown to be necessary after real world testing. Leaving it to the higher levels would also mean that the most appropriate form of FEC could be tailored to each application.

High speed/high tolerance for error (e.g., compressed video?) may suffer more from FEC than would be gained, where slower speed/low tolerance for error applications would cause little extra channel overhead while using FEC. Each application could get the FEC that it needs (or doesn't need).

From the earlier desciption, that's basically the D-Star approach.
 
- Richard, VE7CVS