WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2016-Mar-11 02:31:41

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

802.11 reference design as 'generic' radio

Hi Forum,

In the past, when starting a new study, I've always started with the OFDM reference design, and added my relaying/network-coding/etc. concept on it (i.e., new 'C' code).

I'm about to embark on a new (MAC-related) study now, but observed that the 802.11 reference design is substantially newer, and hence, presumably more robust, cleaner, and overall 'better' in general than the OFDM reference design from 2012.

The question then is would it be possible use this 802.11 design as a "generic" radio, a'la the OFDM design?

This would involve disabling the AP-STA architecture, potentially DCF and other 802.11 specific aspects, while still being able to enjoy the benefits of a 20MHz bandwidth on a cleaner design, using the W3 as an ethernet-radio bridge.

Has anyone done this before, and if so, is there a 'simple' way of doing this (e.g., #undef 802_11_MODE in some .h file somewhere would be nice :-)

--vick

Offline

 

#2 2016-Mar-12 11:34:39

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 4964

Re: 802.11 reference design as 'generic' radio

hi Vick- the simple answer is 'yes'- the Tx/Rx PHY cores in 802.11 Ref Design can be used for totally custom MAC designs.

One hard-coded 802.11 element is the PHY header in each waveform. The PHY header (SIGNAL field for 11a waveforms) carries the RATE & LENGTH parameters. The Tx PHY requires every waveform have a valid SIGNAL field, and the Rx PHY will only attempt decoding of waveforms with valid SIGNAL fields. All payload bytes after the PHY header are arbitrary- the MAC design can define whatever payload formats it needs.

That said, using the PHY cores to build a totally custom MAC would require writing custom applications for both CPUs in the ref design. This is certainly possible, but is a big undertaking. Instead I would suggest starting with the NoMAC project in CPU Low. This application disables all the DCF-specific MAC behaviors, but still uses standard 802.11 packet formats. You can pair NoMAC with the STA and AP projects in CPU High to build a simple network where every node implements a wireless-wired Ethernet bridge. These CPU High projects handle all the details of Ethernet encapsulation/de-encapsulation, queueing transmissions, etc., and will seamlessly support the wlan_exp experiments framework.

Offline

 

#3 2016-Mar-14 03:59:31

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Hi Patrick,

Great! Then I'll have a look at how I could possibly pair noMAC@CPU low with STA/AP@CPU high - thanks for the response.

If I could add a follow-up, more general question; would this (i.e., pairing of noMAC+STA for e.g.) be the "recommended" way to go if one plans to do some generic radio experimentation, e.g., build a decode-and-forward relay between a SRC and DST end-nodes? Or would it be "better" to stick to the simpler OFDM reference design for these type of implementations instead of the 802.11 reference, which may not have been designed/envisioned for non-802.11 type activity?

-vick

Offline

 

#4 2016-Mar-14 09:03:00

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1184

Re: 802.11 reference design as 'generic' radio

The NOMAC+AP/STA pairing with the 802.11 design is definitely the way to go if you want to do something custom. The 802.11 standard behaviors are just a sane default state for the design. Modifying the project to do custom stuff is much more straightforward than it was with the OFDM Reference Design. For some examples of non-standard behaviors that can be added to the design, check out our app notes on changing the design to support frequency hopping and getting rid of the DCF and replacing it with a simple scheduled token-passing MAC. Both of those projects radically changed the underlying behavior of the design and did so with some very modest C-only changes.

With very few exceptions, the 802.11 design can do anything the OFDM reference design can do and is far cleaner/easier to work with.

Offline

 

#5 2016-Mar-14 10:29:19

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

chunter wrote:

With very few exceptions, the 802.11 design can do anything the OFDM reference design can do and is far cleaner/easier to work with.

That was just the type of reassuring confirmation I was seeking! I'll now start looking more closely at the 802.11 reference for my next prototyping activity.

Thanks for the advice!
vick

Offline

 

#6 2016-Mar-14 12:04:45

Christian
Member
Registered: 2010-Feb-26
Posts: 124

Re: 802.11 reference design as 'generic' radio

As a follow up as we are also using the design this way: A PHY interface with a clean ability to interrupt/stop transmissions and receptions would be very welcome

Offline

 

#7 2018-Mar-09 10:44:21

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Hi Forum,

This is a follow-up to this almost 2-year old thread (which unfortunately got stalled then).

I'm looking to create ethernet-bridge type WARP v3 nodes, and hoping to base this on the 802.11 Reference Design, as inquired at the start of this thread.

There was a recommendation to use NoMAC for CPU_low with STA and AP for CPU_high. Would that be the cleanest way to go? Would a NoMAC + IBSS combination instead provide identical bridge devices which can then be peers?

Using a freshly downloaded v1.7.5 I was able to get a pair of PCs to communicate over the air via a pair of v3 boards, one running STA and one running AP, and both running NoMAC (or both running DCF) at CPU_low. Alternatively, I also managed to get the PCs communicating over the air with the boards both running IBSS+DCF.

However, I couldn't get the PCs to communicate with the boards both running IBSS+NoMAC.

The question (again) is: based on the available applications of AP, STA, IBSS (CPU_high) and DCF, NoMAC (CPU_low), what would be the cleanest way to create these generic WARP v3 ethernet bridge nodes?

--vick

Last edited by vick (2018-Mar-09 10:45:17)

Offline

 

#8 2018-Mar-09 11:18:28

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1184

Re: 802.11 reference design as 'generic' radio

Hi vick,

When our IBSS boots up, it has to figure out whether an existing IBSS node is out there that it should "join" or whether it should create its own IBSS network. We do this by having the IBSS perform an active scan for "MANGO-IBSS" for some amount of time. If it sees that network already existing, it adopts the BSSID of the network and effectively joins. If not, it unilaterally creates a "MANGO-IBSS" with its own BSSID.

I think what you are seeing is that your two IBSS nodes are actually creating parallel networks because they don't see each other. When you are using NOMAC, the IBSS nodes don't send any beacons since beacon transmission is a feature exclusive to the DCF project. As such, the scans have to rely completely on probe requests and probe responses. I'm not sure why that isn't enough -- I'll have to look into it. Regardless, you probably don't want to rely on over-the-air handshakes to set up the network for your experiment. If you use the configure_bss() wlan_exp method on both nodes and use the same BSSID for both, they will both be part of the same BSS and exchange packets with one another.

Offline

 

#9 2018-Mar-09 14:49:19

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Hi Chris,

So, if we take a step back, the more general question I had was what should I use as a starting point for creating a generic transparent ethernet bridge based on the 802.11 Ref Design. I simply want raw ethernet frames received on a wired interface to go out over the air, and vice-versa (i.e., no WARP MAC addresses, etc.), a'la the OFDM Ref Design.

I assume this would involve 'stripping down' either the AP, STA or IBSS implementation (CPU_high) and running it with NoMAC (CPU_low). Based on your response, should I assume that simplifying an IBSS implementation and paring it with NoMAC would be the most straightforward way to achieve this?

The fact that I couldn't get two IBSS nodes to communicate now isn't a problem since I'll eventually want them to be dumber nodes. I'm just trying to figure the quickest way to create these dumb nodes.

--vick

Offline

 

#10 2018-Mar-12 13:53:26

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1184

Re: 802.11 reference design as 'generic' radio

vick wrote:

So, if we take a step back, the more general question I had was what should I use as a starting point for creating a generic transparent ethernet bridge based on the 802.11 Ref Design. I simply want raw ethernet frames received on a wired interface to go out over the air, and vice-versa (i.e., no WARP MAC addresses, etc.), a'la the OFDM Ref Design.

I assume this would involve 'stripping down' either the AP, STA or IBSS implementation (CPU_high) and running it with NoMAC (CPU_low). Based on your response, should I assume that simplifying an IBSS implementation and paring it with NoMAC would be the most straightforward way to achieve this?

The 802.11 Reference Design does implement a layer 2 bridge; every Ethernet payload is transmitted byte-for-byte but the Ethernet headers are used for the construction of the outgoing MAC headers. The 802.11-2012 standard describes this process in Annex P, the confusingly-titled "Integration Function."

Maybe it's useful to summarize the different approaches we have taken across the designs. The OFDM Reference Design still had its own MAC addresses and DCF-like MAC behaviors (ACKs, random backoffs, etc). It was strictly designed for two nodes. Node A sent all Ethernet traffic to node B and vice versa. All Ethernet traffic was treated as as arbitrary payload; the MAC never needed to inspect anything in the packet. The major limitation to this approach is that it doesn't scale to anything larger than 2 nodes since there was no rule for how to address the outgoing packets to anything other than the one other node on the network.

The 802.11 Reference Design's Ethernet encapsulation is much more flexible at the cost of it being more complex. It inherently scales to an arbitrary number of wireless devices. But in order to do so, it can't simply treat all Ethernet receptions as arbitrary payloads; the behavior has to depend on the Ethernet headers it sees. Said another way, neither the AP, STA, nor IBSS high-level projects will perform the blind 2-node-only encapsulation like the OFDM Reference Design. At a high level, the encapsulation behaviors of the three projects are the following:

AP: All Ethernet receptions turn into wireless transmissions. The Ethernet destination address maps onto the wireless receiver address. Only multicast and unicast transmissions destined for associated nodes will be transmitted. All others will be dropped. There can be many different unique devices on an Ethernet switch plugged into the Ethernet port of the AP.

STA: All ethernet receptions turn into wireless transmissions and all are sent as a unicast message with an RA that is the AP on which the STA is associated As discussed here, the STA encapsulation overwrites the Ethernet source address with the wireless MAC address of the STA. This is to that everything upstream of the AP knows how to address packets to the STA. The implicit requirement of doing is that there can only be a single device on the Ethernet side of our STA node.

IBSS: This is a hybrid of the AP and STA. Like the AP, all ethernet receptions turn into wireless transmissions whose receiver addresses match the Ethernet destination addresses. Unlike the AP, these packets are not filtered according to any kind of list of current associations. All will be transmitted. Like the STA, the encapsulation procedure overwrites the Ethernet source address and makes the assumption that there is only ever a single device plugged in over Ethernet.

Do any of those behaviors sound appropriate for your application? If not, the blind 2-node-only encapsulation could be built as a new top-level project (or modification to the behavior of one of the other three). The question of how you want to do encapsulation is largely independent of the question of low-level MAC behavior (DCF or NoMAC or some custom scheme).

Offline

 

#11 2018-Mar-12 17:35:34

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Hi Chris,

Firstly, thanks very much for the detailed explanation (which perhaps should be included in the the 802.11 documentation as some sort of top-level description?). It pretty much confirms my understanding gained over the years of how things work, so that was refreshing!

I have spent an unreasonable amount of time peering at hexdumps of MAC addresses wondering how those six bytes magically get changed as packets travel between wired-wireless interfaces, and this is my main gripe with the AP, STA and IBSS designs. As you described, wired ethernet frames will have MAC addresses changed before transmission over the air (and vice-versa) - and this implies some sort of state being kept, e.g., STA-AP association, etc. With the current designs, no ethernet frames will go out over the air before the wireless nodes are all synced/associated/set-up.

I appreciate the need for this mechanism for many nodes to coexist but in my specific case(s) I typically want over-the-air communication between a mere 2-3 WARP nodes. Any filtering I require can usually be achieved in a more simple way, e.g., by adding a 4-bit/DIP-switch node ID at the start of my frames, etc.

chunter wrote:

Do any of those behaviors sound appropriate for your application? If not, the blind 2-node-only encapsulation could be built as a new top-level project (or modification to the behavior of one of the other three). The question of how you want to do encapsulation is largely independent of the question of low-level MAC behavior (DCF or NoMAC or some custom scheme).

I guess I'd like something close to a blind 2-node encapsulation. However, I would gladly have the nifty plumbing in place with the current 3 applications, like buffer-queueing, DL-lists, inter-CPU mailboxing, etc., and wouldn't want to have to re-invent that.

Hence, my preference would be to dumb-down one of the three such that ethernet frames from the wire are blindly sent out over the air, without the need of associations or lookup-tables, etc. From your description, I get the feeling that IBSS would contain the least amount of state and might be the easiest to modify to achieve this - would you agree?

--vick

Offline

 

#12 2018-Mar-12 23:39:38

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 4964

Re: 802.11 reference design as 'generic' radio

Hence, my preference would be to dumb-down one of the three such that ethernet frames from the wire are blindly sent out over the air, without the need of associations or lookup-tables, etc.

This is definitely possible but would require pretty broad code changes to effectively short-circuit the Ethernet Rx / encapsulation / enqueue process.

One question that would help narrow the scope of the required changes - in your experiment will each WARP node be connected to a single Ethernet device? Or will each be connected to a distinct Ethernet network, each with many Ethernet devices?

If you're ok with 1 Ethernet device per WARP node, the best option might be the IBSS application with hard-coded, identical association state at every node. Hard-coding association state in CPU High would be much easier than replacing the Ethernet encapsulation scheme. This approach would also work with either the DCF or NoMAC in CPU Low. In this setup the IBSS nodes would skip the association search/handshake and immediately begin bridging Ethernet/wireless at boot. However the IBSS application assumes a single Ethernet device connected to ETH A (whose MAC address is stored in CPU High so it can be overwritten/re-inserted for wireless Tx/Rx).

Offline

 

#13 2018-Mar-13 11:25:37

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

In our typical adventures with the WARP boards, we've always paired a single WARP board with a Unix PC. Together, the duo formed a wireless device, where the PC handled higher layer functionality while the boards performed as wired-wireless ethernet bridges. Medium access of the air was never an issue and if necessary, a rudimentary 4-bit DIP-switch based addressing scheme was implemented for boards to do first-level filtering of air-rxd packets.

murpho wrote:

One question that would help narrow the scope of the required changes - in your experiment will each WARP node be connected to a single Ethernet device? Or will each be connected to a distinct Ethernet network, each with many Ethernet devices?

For the short-term I definitely see us using only a single PC-WARPv3 combination.

I had already started considering dumbing down the IBSS implementation for this purpose. However, you mentioned:

murpho wrote:

Hard-coding association state in CPU High would be much easier than replacing the Ethernet encapsulation scheme. This approach would also work with either the DCF or NoMAC in CPU Low. In this setup the IBSS nodes would skip the association search/handshake and immediately begin bridging Ethernet/wireless at boot.

Do we still need ethernet encapsulation? I haven't dug into the IBSS code too deeply yet, but I assume ethernet received packets are held, have their MAC addresses looked up on some dynamic table, substituted, and then sent out over the air. I'd simply assumed we could skip the address lookup + substitution step, and simply just send whatever received over wire out the antenna. If that would be relatively trivial to implement then it'd be easier to manage and involve less maintenance than hard-coding associations I assume?

On a different note, if we're simply bridging wireless packets out the wire, does this mean our WARP antennae will pick up background live 802.11 traffic and push this out the wired interface to its host PC? This was never a problem before with the OFDM Reference Design since nothing generated that waveform over the air except our own boards. However, now that this is a general 802.11 waveform, I guess we run the risk of picking any arbitrary WiFi transmission on that channel up right?

--vick

Offline

 

#14 2018-Mar-13 14:37:23

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1184

Re: 802.11 reference design as 'generic' radio

vick wrote:

In our typical adventures with the WARP boards, we've always paired a single WARP board with a Unix PC. Together, the duo formed a wireless device, where the PC handled higher layer functionality while the boards performed as wired-wireless ethernet bridges. Medium access of the air was never an issue and if necessary, a rudimentary 4-bit DIP-switch based addressing scheme was implemented for boards to do first-level filtering of air-rxd packets.

murpho wrote:

One question that would help narrow the scope of the required changes - in your experiment will each WARP node be connected to a single Ethernet device? Or will each be connected to a distinct Ethernet network, each with many Ethernet devices?

For the short-term I definitely see us using only a single PC-WARPv3 combination.

I had already started considering dumbing down the IBSS implementation for this purpose. However, you mentioned:

murpho wrote:

Hard-coding association state in CPU High would be much easier than replacing the Ethernet encapsulation scheme. This approach would also work with either the DCF or NoMAC in CPU Low. In this setup the IBSS nodes would skip the association search/handshake and immediately begin bridging Ethernet/wireless at boot.

Do we still need ethernet encapsulation? I haven't dug into the IBSS code too deeply yet, but I assume ethernet received packets are held, have their MAC addresses looked up on some dynamic table, substituted, and then sent out over the air. I'd simply assumed we could skip the address lookup + substitution step, and simply just send whatever received over wire out the antenna. If that would be relatively trivial to implement then it'd be easier to manage and involve less maintenance than hard-coding associations I assume?

If you are comfortable with the limitation of only 1 Ethernet device per WARP kit, then I don't think you need to make any modifications to the way encapsulation works. Since you want to use NOMAC, the only modification you probably want to perform is to make sure that both IBSS nodes boot into the same BSS configuration and not rely on over-the-air handshakes. You can do this by:

1. Commenting out these lines to keep the node from active scanning at boot and looking for networks with the same SSID.
2. Commenting out these lines that create a locally_administered_addr based on MAC address of the device. You want both your nodes to boot up and simply know the same BSSID, so just set locally_administered_addr to whatever you want like:

Code:

locally_administered_addr[0] |= 0x00 | MAC_ADDR_MSB_MASK_LOCAL;
locally_administered_addr[1] |= 0x01;
locally_administered_addr[2] |= 0x02;
locally_administered_addr[3] |= 0x03;
locally_administered_addr[4] |= 0x04;
locally_administered_addr[5] |= 0x05;

The node will then boot like normal and be on a BSS whose BSSID is locally_administered_addr. Any other node that boots up onto the same BSS will then begin bridging Ethernet traffic with it. Note: this strategy leaves in place the behavior that the source address of all received Ethernet frames are overwritten with the wireless MAC address of the node, but this won't affect the behavior of your Ethernet devices in any meaningful way other than the fact that they will think the MAC address of the other Ethernet device is the Mango-supplied address. If you really want to disable this and not have addresses be overwritten, I guess you could comment out this code on the encapsulation side and this code on the de-encapsulation side, but the only effect of that change would be to prevent you from using the DCF in the future and forcing you to use NOMAC or your own custom low-level MAC. It doesn't buy you any additional flexibility. The DCF needs to know the wireless address of the node in order to know whether or not a received frame should be acknowledged.


vick wrote:

On a different note, if we're simply bridging wireless packets out the wire, does this mean our WARP antennae will pick up background live 802.11 traffic and push this out the wired interface to its host PC? This was never a problem before with the OFDM Reference Design since nothing generated that waveform over the air except our own boards. However, now that this is a general 802.11 waveform, I guess we run the risk of picking any arbitrary WiFi transmission on that channel up right?

They will be received by the low-level MAC and passed up to the upper-level MAC, but they won't turn into Ethernet transmissions unless they are on the same BSS (i.e. their BSSID matches the arbitrary locally_administered_addr you set earlier).

Offline

 

#15 2018-Mar-14 13:30:51

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Thanks again for the very detail and clear explanation! And, an even BIGGER thanks for the code modifications suggested in steps 1. and 2., which very elegantly brings all boards up to the same pre-defined BSS, and subsequently operate as wired-wireless ethernet bridges. I've now got wlan_mac_high_ibss + wlan_mac_low_nomac operating (seemingly) reliably.

It still feels extremely tedious to have to go through the ethernet encapsulation/de-encapsulation process for each frame, but I'm happy to look into that at a later stage once I've had more time to evaluate this current bridging performance.

Two minor questions on the code snippet provided:

chunter wrote:

You want both your nodes to boot up and simply know the same BSSID, so just set locally_administered_addr to whatever you want like:

Code:

locally_administered_addr[0] |= 0x00 | MAC_ADDR_MSB_MASK_LOCAL;
locally_administered_addr[1] |= 0x01;
locally_administered_addr[2] |= 0x02;
locally_administered_addr[3] |= 0x03;
locally_administered_addr[4] |= 0x04;
locally_administered_addr[5] |= 0x05;

Firstly, is there a reason why each of the 6 bytes are bitwise 'OR'd with the values instead of just being assigned (with '=')? And secondly, I guess the 1st byte MUST have MAC_ADDR_MSB_MASK_LOCAL explicitly set for this to work, since there's a check later on in the code for this bit (I initially set this byte to 0x00 and it didn't work then!).

Once again, thanks again everyone for the very clear explanations and elegant code-modifications suggested!

--vick

Offline

 

#16 2018-Mar-14 13:44:56

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1184

Re: 802.11 reference design as 'generic' radio

vick wrote:

Firstly, is there a reason why each of the 6 bytes are bitwise 'OR'd with the values instead of just being assigned (with '=')?

Oops, the "|=" was a typo that got magnified with some copy-paste. Those should all be straight "=" assignments.


vick wrote:

And secondly, I guess the 1st byte MUST have MAC_ADDR_MSB_MASK_LOCAL explicitly set for this to work, since there's a check later on in the code for this bit (I initially set this byte to 0x00 and it didn't work then!).

Yeah, the requirement that MAC_ADDR_MSB_MASK_LOCAL be asserted for an IBSS's BSSID is enforced here. Removing that chunk of code would let both of your nodes talk to each other with any 6 bytes of BSSID, but it would really confuse other Wi-Fi devices out there. 802.11 requires that ad hoc IBSS networks raise that bit that indicates they are locally administered. It's probably not relevant to your application, but if you wanted a commercial Wi-Fi device like your laptop to be on the same ad hoc network you'd need for that bit to be raised.

Offline

 

#17 2018-Mar-15 14:22:15

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Hi Chris,

Thanks for clarifying the typo.

I tested the setup some more with the code modifications you suggested about two postings before and things seem to work. I had two "WARP+PC" wireless entities, wired up just as the NoMac/Bridge picture shows. PC "A" on the left could ping PC "B" on the right, via the pair of WARP v3 boards running the wlan_mac_high_ibss code modified as per the suggestions mentioned. Programming/re-programming either board multiple time still resulted in them communicating, so the setup seems stable.

However, joy was short lived when I created a third "WARP+PC" entity and introduced it into the setup 'between' A and B. The intention was to use his intermediate node as some sort of relay but unfortunately this PC C never sees packets exchanged between A and B. However, it's possible for A (and B) to ping C but then B (or A) never sees this communication (A, B, and C are all on the same sub-net).

The reason for this is due to the mystical encapsulation/de-encapsulation mechanism in place of course. There is still too much 'state' with this design: the boards knows their own PC's MAC connected to it, understands the difference between broadcasts and unicast, etc. -- resulting in different treatment of packets.

Hence, a new question: is there a relatively simple way to remove this "intelligence" from the boards so ethernet frames are more blindly forwarded over the air, and vice-versa?

--vick

Offline

 

#18 2018-Mar-15 14:54:15

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 4964

Re: 802.11 reference design as 'generic' radio

The other node is (very likely) receiving the packet, but is choosing not to forward it to Ethernet because the destination MAC address didn't match its own MAC address. For the IBSS application this decision is implemented in mpdu_rx_process(). That highlighted block is how the IBSS handles received QOSDATA/DATA packets. Notice that it's inside an "if(unicast_to_me || to_multicast)" clause. I think if you short-circuit that "if(1)", the IBSS node will forward all received data packets to Ethernet.

Offline

 

#19 2018-Mar-16 10:54:37

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Thanks Patrick. As per your suggestion, short-circuiting the "if(unicast_to_me || to_multicast)" enabled my third PC "C" to overhear the traffic between A and B.

However, a new issue has now cropped up. I noticed that C was only seeing some of the A-B traffic. Examining closer, I noticed that there were quite a few packet losses, even between A and B. Suspecting that there might be a rogue WiFi device in the vicinity, I simplified the setup significantly, reducing the test to only PC+WARP A and PC+WARP B, where the two WARP boards were connected via a coaxial cable with attenuators.

I programmed the boards with either [high_bridge+low_nomac] or [high_bridge+low_dcf], where high_bridge is high_ibss with (only) the modifications suggested in this thread. I ran a UDP traffic generator program on the PCs sending a 10000 packet stream from A to B, each packet being 100-bytes (IP-length) and with an inter-departure-time of 2ms.

I observe that [high_bridge+low_dcf] results in zero packet losses at B on almost every run. However, [high_bridge+low_nomac] almost constantly results in ~10 packet losses. When I replace the coax with antennae then the packet losses are almost-zero vs. almost-200 (out of 10000 transmitted). The boards are approximately a metre apart and I'm fairly certain there no other transmissions on this channel.

Would you have any idea why this could be the case? Since the high application is the same in both cases I conclude that that couldn't be contributing to this. Are there any differences between wlan_mac_low_dcf and wlan_mac_low_nomac, e.g., in terms of coding and modulation? Frame formats? Timings?

--vick

Offline

 

#20 2018-Mar-19 09:38:04

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

vick wrote:

Would you have any idea why this could be the case? Since the high application is the same in both cases I conclude that that couldn't be contributing to this. Are there any differences between wlan_mac_low_dcf and wlan_mac_low_nomac, e.g., in terms of coding and modulation? Frame formats? Timings?

Answering my hastily-posted question, I guess wlan_mac_low_dcf includes an ACK/retransmission scheme as well, which would explain it's near-lossless performance compared to single-shot-transmissions from wlan_mac_low_nomac. Would this be the case?

--vick

Offline

 

#21 2018-Mar-19 09:46:40

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1184

Re: 802.11 reference design as 'generic' radio

vick wrote:

I programmed the boards with either [high_bridge+low_nomac] or [high_bridge+low_dcf], where high_bridge is high_ibss with (only) the modifications suggested in this thread. I ran a UDP traffic generator program on the PCs sending a 10000 packet stream from A to B, each packet being 100-bytes (IP-length) and with an inter-departure-time of 2ms.

I observe that [high_bridge+low_dcf] results in zero packet losses at B on almost every run. However, [high_bridge+low_nomac] almost constantly results in ~10 packet losses. When I replace the coax with antennae then the packet losses are almost-zero vs. almost-200 (out of 10000 transmitted). The boards are approximately a metre apart and I'm fairly certain there no other transmissions on this channel.

Would you have any idea why this could be the case? Since the high application is the same in both cases I conclude that that couldn't be contributing to this. Are there any differences between wlan_mac_low_dcf and wlan_mac_low_nomac, e.g., in terms of coding and modulation? Frame formats? Timings?

The underlying rate of the waveform is the same regardless of which low-level MAC you use, but the channel access timing is radically different. The DCF implements the full distributed coordination function from 802.11 (with retransmissions for failures, exponential backoffs, and clear channel assessment (CCA)). It's not surprising that it's much more reliable than NOMAC, which arbitrarily transmits a packet with zero regard for background interference.

How certain are you that there is no other activity on the channel? For your over-the-air experiment, 200/10000 packets for the DCF is quite low. Does that number improve if you lower the duty cycle? Depending on the length and MCS chosen, a fresh packet every 2ms occupies nearly all of the medium. Any CCA deferrals or retransmissions will slow down the dequeue rate of your transmitter. My guess is that many of the packet losses are due to the queue getting full and not necessarily due to a high PER. The wlan_exp event log is a powerful tool that could help you figure out where your losses are coming from. For example, queue_occupancy field from TX_HIGH entries would answer whether you are dropping packets at the queue. If you plot those over time you will probably see it raise up to a maximum value and then stick there once the queue is full. If that isn't the case, you can still use the log to compare RX_OFDM events TX_LOW events to try to narrow down sources of error.

Offline

 

#22 2018-Mar-20 07:52:01

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Hi there,

I was probably unclear in my description of the losses in the earlier posting. I meant to state I observed zero (coax) then almost-zero (1 metre air) losses with wlan_mac_low_dcf. With wlan_mac_low_nomac this was ~10 and ~200 respectively.

Historically, earlier DBG_HDR latency measurements with the OFDM design showed ~440us latencies for transmission of 100-byte IP packets with BPSK and 1/2 coding - which led to my choice of 2000us inter-packet time for this experiment.

Based on the above two, I don't believe that what I'm observing are queuing losses (even though I admit this is more of a gut-feel and could be better verified via wlan_exp).

However, testing further with cable and over-the-air in isolation, I now believe the discrepancy I earlier observed between wlan_mac_high_dcf and wlan_mac_high_nomac is simply from the retransmissions provided by DCF which are lacking in NOMAC.

Thanks for all the support,
vick

Offline

 

#23 2018-Mar-20 10:14:56

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 4964

Re: 802.11 reference design as 'generic' radio

A few notes:
-The 802.11 ref design has similar debug header signals - see the user guide. Pins 0 and 1 will show Tx/Rx PHY activity.
-The 802.11 PHY operates with 20MHz bandwidth vs 10MHz for the OFDM ref design, so the 802.11 waveform duration will be roughly half as long for a given payload / modulation / coding.
-Even when cabled together the WARP nodes will detect energy from nearby transmitters (there's enough leakage in the RF circuits without an enclosure). It's definitely possible that the DCF is successfully avoiding "collisions" with these other transmitters, improving the PER between the nodes.

Offline

 

#24 2018-Mar-21 10:18:41

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Thanks for the tip on the debug header pins for 802.11, I wasn't aware there were built-in wirings and was about to do this myself! Thanks also for the heads-up on possible RF circuitry pickup.

--vick

Offline

 

#25 2018-Apr-06 09:58:00

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: 802.11 reference design as 'generic' radio

Hi Forum,

I've been trying to build a simple ethernet bridge application running on the 802.11 Reference Design, but am finding this continuously challenging.

From the hints provided in this thread so far I've managed to modify wlan_mac_high_ibss to work with wlan_mac_low_nomac to create [WARP + PC] nodes working in an almost bridge-like fashion. Nodes can communicate with each other, with intermediary node pairs picking up ongoing transmissions.

Unfortunately this communication is still taking place with 802.11-type frames and I'm finding the ethernet encapsulation magic converting 802.3 and 802.11 headers particularly challenging. In short, bi-directional communication must be possible for any packets to be exchanged. It is impossible for PC A to send an IP packet to PC B over the air (even with static ARP entries) because the 802.11-ness of the system needs to learn the MAC addresses involved.

The code in CPU high seems very hard coded for these 802.11 features, i.e., header formats, FCS, etc. Is there an easy way to remove this behaviour so bytes received on the ethernet interface are sent verbatim out the radio? Alternatively, is there an "easy" way to create a bridge_mac_high application from scratch/template?

--vick

Offline

 

Board footer