WARP Project Forums - Wireless Open-Access Research Platform

Thanks a lot for your reply.

The challenge here is that you want to be able to have the AP--->STA1 and the AP--->STA2 flows active at the same time. So, even though every frame transmitted by the AP should have an addr1 (RA) of the STA1 MAC address, something in the packet needs to indicate whether or not the packet terminates at the STA1 node or whether it should be passed along to STA2. It would be easier to build a fully hardcoded relay at STA1 that simply passes every packet on to STA2 without having to do any deeper inspection.

I believe the behaviors you are describing would be achievable in an implementation of the 802.11s mesh amendment. Building that full amendment is an enormous undertaking, however. If it were me, I would implement something non-standard to achieve the multihop relaying recognizing that each node in the experiment is a WARP node that is capable of the same non-standard behavior.

I'm not totally sure how this implementation would look, but here are some rough ideas that come to mind.

1) You'll want to formalize a kind of routing table at each node. You can skip the process having nodes learn this routing table or adapt it based on changes in network topology. In this table there needs to be a "next hop" address for each receiver address (RA).

At the AP, the table would contain:

|         RA        |      Next Hop      |
------------------------------------------
|   STA1 MAC Addr   |   STA1 MAC Addr    |
|   STA2 MAC Addr   |   STA1 MAC Addr    |

At STA1, the table would contain:

|         RA        |      Next Hop      |
------------------------------------------
|   AP   MAC Addr   |   AP   MAC Addr    |
|   STA2 MAC Addr   |   STA2 MAC Addr    |

And finally, at STA2, the table would contain:

|         RA        |      Next Hop      |
------------------------------------------
|   STA1 MAC Addr   |   STA1 MAC Addr    |
|   AP   MAC Addr   |   STA1 MAC Addr    |

2) The idea behind the implementation of the routing table should be that any time the standard design was about to produce a frame for an RA address, you would instead look into the table and replace that addr1/RA field with the "Next hop." However, you can't simply throw away the existing RA, as that is really where the packet needs to end up. Whoever is next in the hop still needs to know who the original RA was. The easiest way to do this is to probably customize the definition of the 802.11 MAC Header to include a 4th address. Notice that an "address_4" is already present in that definition but just commented out. You'll want to comment that back in and use it to store the original RA. We don't use a 4th address for any standard 802.11 behaviors in the Reference Design, but it is used for relaying in some standard contexts.

3) The STA code needs to be modified in at least two ways. First, the STA needs to be able to accept data frames from other STAs. Currently, a STA is only allowed to receive and process a frame if is_associated is 1, which only happens if the addr2/TA matches the AP. Your scenario will have STA2 receiving frames from STA1, so this isn't going to work. Second, you'll need to be able to teach the STA how to transmit wirelessly to another STA. Currently, a STA only ever transmits to a single AP. You'll want to look at the AP and IBSS code to figure out how they are able to transmit to more than one wireless device. Furthermore, the AP code should be used as reference to see how some wireless transmissions are created to forward wireless receptions. This is the scenario previously discussed where an AP can forward a packet to an associated STA on behalf of another associated STA.