Updated packet format on USRP inband signaling

GNU Radio
21

On Tue, Feb 27, 2007 at 07:49:02AM -0500, Greg T. wrote:

I’m thinking layer 2 with a unique Ethernet packet type (probably use
some abandoned packet type). That said, there’s nothing stopping us
from doing UDP, except the additional bandwidth. I don’t see any need
to do TCP.

I think that it should be possible for an unprivileged user (on most
Free systems) to interact with a USRP over GigE. Actually this raises
the issue of authorization and confidentiality/integrity of the data,
probably taken care of by a dedicated ethernet port.

Under GNU/Linux they may need to be holding CAP_NET_RAW, since I
think the way to get the raw ethernet frames is with libpcap and/or
opening a raw socket using socket(PF_PACKET, SOCK_RAW, …)

Actually, according to man 7 packet, socket(PF_PACKET, SOCK_DGRAM,
hton(ETH_P_foo))
may work too. It’s been a while since I played with this stuff.

Any idea how we would get this done under *BSD?

I’m hoping on suitable machines to be able to run near wire-speed, so
that also argues for a dedicated ethernet port.

Also, absent some driver hacking to mux and demux commands and
responses, we may need a user space process to handle that stuff. In
that case, only that processes would need access to the magic socket,
and the rest of the user code would use some kind of IPC to talk to
that one.

USB is said to be reliable. Presumably you mean to have that same
property via pause frames.

Pause frames provide flow control. According to folks at Vanu
(who use Gigabit ethernet to implement their basestations), that’s
been sufficient, assuming any switches along the way aren’t brain
damaged.

If somebody wanted to ship samples a long way reliably, then some
higher-level protocol is probably in order.

Eric

22

On Wed, Feb 28, 2007 at 07:23:32PM -0500, Timothy Brown wrote:

I’m considering the case whereby users might want to attach a USRPng
to a network, then either L2/L3 to multiple processing frontends.

Thanks,
Tim

Good. Thanks.

Eric

23

I’m thinking layer 2 with a unique Ethernet packet type (probably use
some abandoned packet type). That said, there’s nothing stopping us
from doing UDP, except the additional bandwidth. I don’t see any need
to do TCP.

I think that it should be possible for an unprivileged user (on most
Free systems) to interact with a USRP over GigE. Actually this raises
the issue of authorization and confidentiality/integrity of the data,
probably taken care of by a dedicated ethernet port.

USB is said to be reliable. Presumably you mean to have that same
property via pause frames.

–
Greg T. [email protected]

24

This is a somewhat unrelated question, but i’m just curious if
multicast is part of the thought process here?

25

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

26

On Sun, Feb 25, 2007 at 08:33:23PM -0500, Brian P. wrote:

Would you prefer that both types of data occurred in the same packet?

Eric

Not at all - it makes much more sense to calculate when to bring up /
tear down the RF stuff on the host rather than inside the FPGA and
back calculate.

Is the timestamp details of the operations just going to happen one
after the other?

That was the plan.

It might be beneficial to bandwidth to have a NOP
command with the argument being number of ticks - that way you don’t
have to send 2 512-byte packets when you want things to occur slightly
offset in time.

That sounds good. Would you interpret it as a delta-t from the
timestamp in the header? I’m thinking about the case where there are
multiple DELAY ops in the payload.

Eric

27

On 2/25/07, Eric B. [email protected] wrote:

I guess I’m concerned that some of the OPS could take more than a
single tick. E.g., I2C or SPI ops. Thoses buses run at something
like 100kHz to 400kHz. If all execution delays are known, then
OP_DELAY seems fine (and easy).

I share the same concern over the I2C or SPI ops, but I would think it
is pretty easy for the host API for the daughterboard in question to
have the delays hardcoded and figured out. That would make it pretty
easy to calculate violations within a TDMA sequence or frequency
hopping scheme before it even gets down to the USRP.

Eric

Brian

28

On Sun, Feb 25, 2007 at 11:18:09PM -0500, Brian P. wrote:

Sorry, I retract my previous statement. Sending 2 packets is
obviously the thing to do. One with the control sequence with the
beginning timestamp and the second with the beginning of the I/Q data.

Sorry! Late night error.

Brian

No problem :wink:

Eric

29

Looking at it again, maybe there should be an OP_START to either start
the RX or TX depending on it either being an IN or OUT packet?
Otherwise, how would you know when to actually begin performing the
desired action?

What do you think?

Brian

30

Eric B. [email protected] writes:

Sure. It’s a common operation now. We often run an fft in one
process and some kind of transmitter in another. Somebody’s got to
handle the dumuxing of command replies. Using your UDP example, we’d
have the source port of the request to route the reply. That still
leaves the flags such as Overrun, Underrun, etc., which I was thinking
were only going to get reported once, and then cleared. (I didn’t see
a good reason for forcing the host to explicitly clear the flag.)

I envision some number of data streams to/from the USRP, each with
it’s own destination on the host. They then could each have
over/underrun flags.

If it’s mainly about tx vs rx, or separate data streams, then that’s
something that could be muxed on udp port.

This likely requires a lot more thought.

On Tue, Feb 27, 2007 at 11:28:26AM -0500, Greg T. wrote:

It may make sense to define a TCP or SCTP method, but then again it
may not - this is perhipheral attachment.

I’d hate to try to stuff either of those in an inexpensive FPGA. Of
course if somebody wanted those, they could stick some kind of single
board computer next to the USRPng and have it run TCP or SCTP or
whatever.

Sure - I was thinking the same thing. The requirements document
probably should say “local bus attachment”.

31

On Tue, Feb 27, 2007 at 11:28:26AM -0500, Greg T. wrote:

Free systems) to interact with a USRP over GigE. Actually this raises

use bpf. This requires r/w access to /dev/bpf, but that also
enables reading and writing other traffic. Presumably CAP_NET_RAW
on Linux does too, and that’s overly broad.

write a protocol family driver for the USRP ethertype (hard)

OK.

To me, this all argues for IP/UDP (at the cost of 28 bytes) being the
standard approach, with raw being an optimization if needed. It
handles the privilege issues, and gives you multiplexing hooks (which
we may not usually need).

OK.

I’m hoping on suitable machines to be able to run near wire-speed, so
that also argues for a dedicated ethernet port.

Sure, but speed should be an orthogonal design issue from security and
multiplexing.

OK.

Also, absent some driver hacking to mux and demux commands and
responses, we may need a user space process to handle that stuff. In
that case, only that processes would need access to the magic socket,
and the rest of the user code would use some kind of IPC to talk to
that one.

OK, but that’s likely to be somewhat slower. But I don’t understand
the mux/demux need, beyond connecting a USRP to a user process. Do
you envision two programs each accessing some part of the resources on
a single GigE connected USRPng?

Sure. It’s a common operation now. We often run an fft in one
process and some kind of transmitter in another. Somebody’s got to
handle the dumuxing of command replies. Using your UDP example, we’d
have the source port of the request to route the reply. That still
leaves the flags such as Overrun, Underrun, etc., which I was thinking
were only going to get reported once, and then cleared. (I didn’t see
a good reason for forcing the host to explicitly clear the flag.)

It may make sense to define a TCP or SCTP method, but then again it
may not - this is perhipheral attachment.

I’d hate to try to stuff either of those in an inexpensive FPGA. Of
course if somebody wanted those, they could stick some kind of single
board computer next to the USRPng and have it run TCP or SCTP or
whatever.

Eric

32

On Wed, Feb 28, 2007 at 09:44:30AM -0500, Timothy Brown wrote:

This is a somewhat unrelated question, but i’m just curious if
multicast is part of the thought process here?

I hadn’t given it much thought, one way or the other.

Eric

33

On Sun, Feb 25, 2007 at 09:12:23PM -0500, Brian P. wrote:

hopping scheme before it even gets down to the USRP.

Brian

OK. Sounds good to me. I’ll add OP_DELAY

Eric