[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Physical layer for packet-based communication

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Physical layer for packet-based communication
Date: Fri, 4 Feb 2005 09:04:39 -0800
User-agent: Mutt/1.5.6i

On Fri, Feb 04, 2005 at 10:21:06AM -0500, Rahul Dhar wrote:
> On Thu, Feb 03, 2005 at 08:49:37AM -0800, Eric Blossom wrote:
> > Continuing on the packet comms thread, I'm investigating reasonable
> > ways to get packets in and out of GNU Radio.  A couple of variations
> > come to mind.  We could provide a fake ethernet or IP interface and
> > allow external apps to push packets through that (similar to the click
> > modular router).  The packets could be decorated with key/value pairs
> > to provide attributes to the MAC or PHY layer, or we could pass
> > undecorated packets, and then use some other out-of-band means
> > (socket?) to control attributes in the lower layers.
> > 
> > Thoughts or comments?  What would you like to see?
> Ideally, I'd like to see a physical layer API so I can write my own MAC
> layer.

There are a lot of differences in physical layers.  I'm not sure that
a single API is possible, but it's worth striving towards.

> Can GNU Radio handle 802.11 a/b/g?

(1) The data rate is pretty high for us to do all on the host, but then I
guess it depends on the host.  

(2) The other challenge with 802.11b is the tight timing requirement on
the order of 10us for the RTS/CTS (?) turn around.  We may be able to
work around this by precomputing the header of the response and just
start blasting it out.  This would have to be done in the FPGA.

(3) Nobody has written it.

This may be one of the cases where it's worth putting a good chunk of
the PHY in the FPGA, and moving the remainder of the PHY and MAC to
the host.

See next message re USRP back-of-the-envelope latency calculations.

> What I'd like to do is have
> a MAC layer smart enough to detect when the MAC protocol it's using
> isn't optimal given network conditions, and then switch to a protocol
> better suited to the traffic characteristics.  For examle, 802.11 has
> DCF and PCF modes.  For smaller networks, DCF (based on CSMA/CA) is
> normally fine, but when you reach a certain number of nodes, or start
> having nodes that are sending large amounts of data, PCF can be better
> suited because of its contention-free period.

Sounds good.

> I'm not sure how feasible that would be, but I'd like to start by
> implementing simple DCF and PCF schemes and eventually work towards an
> 802.11 implementation.

This would be great to have.

> A fake network device would be nice, though.  If nothing more, it
> lets applications take advantage of the radio in a standard way.

Yep, and it let's the networking guys play at a layer of abstraction
that they're familiar with.

> -- 
> Rahul Dhar
> address@hidden
> Actually, my goal is to have a sandwich named after me.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]