On 27/03/14 20:10, Phoebe Buckheister wrote: >> Hi Phoebe, >> >> Thank you for the swift response it has given my a lot to think about. >> I remember the discussion and like you I was in favour of removing the >> slave list. But as chance would have it I think we may actually need it >> now or some other method of multiple WPANs per PHY. > In that case, the PHY driver should indicate how many concurrent WPAN > instances it can support, and the mac802154 layer should allow up to that > many WPAN instances, but no more. In current drivers, that limit is 1, and > the stack doesn't enforce it at all. As such, the slave list won't go > entirely - it's more likely to be split into a monitor list and a slave > dev, which might well become a slave dev list when you come up with a PHY > that supports that. > >> I need to have a >> think especially with regards to ACKs as this is something I haven't >> thought about. >> I don't suppose you can you expand on why bridging is impossible due to >> the ACK frames? > The -2011 version of the standard states in 5.1.6.4.2: "A frame > transmitted with the AR field set to request an acknowledgment, as defined > in 5.2.1.1.4, shall be acknowledged by the recipient. If the intended > recipient correctly receives the frame, it shall generate and send an > acknowledgment frame containing the same DSN from the data or MAC command > frame that is being acknowledged." > > In the case of bridging, the recipient will sit on some leg of the bridge > the sender doesn't sit on. The sender now transmits a frame and expects an > ACK frame to arrive within, usually, one SHR duration and six byte times. > If you send a packet to a WPAN with a slower PHY, you're out for obvious > reasons. If you send to a faster PHY, bridging becomes possible, but the > reverse path will be broken for obvious reasons, so only same-speed > bridging is possible at all. These can be alleviated by having the bridge > send ACKs on behalf of the actual recipient and do retransmission by > itself, but then the bridge may need arbitrarily long backlogs or drop > frames that could have been transmitted - the former assumes that the > bridge will eventually deliver the packet (which may not be true), whereas > the latter is not entirely unheard of. It is really bad in low-bandwidth > networks though. > > Now have a sender transmit a frame. Even if your bridge merely takes the > symbols from the air as they come in and transforms them perfectly with > not time delay, you'll have a round-trip delay of two symbols (since a > smybol can't be fully known until it's fully received), thus you miss your > latency target by some fractions of a byte, but by then the sender might > have started a retransmission or given the packet up entirely because it > doesn't retransmit at all. If it does retransmit, you can record the ACK > and send it after the retransmission is finished, but then you've incurred > a retransmission overhead for your bridge with an additional chance that a > packet might be incorrectly be assumed lost. > > So yes, it's not entirely impossible, but it does work well only under > special circumstances and cuts your bandwidth in half (or worse). If you > don't use link-layer ACKs anywhere, you'll be fine, but if you do, a > upper-layer protocol with, say, a four byte routing header for > dest-pan:dest-shortaddr becomes a much better option. > Thanks again for the detailed response. To give some context our powerline PHY isn't like any in the 802.15.4 spec and we are hoping to utilise just the MAC. I need to check with the system guys but I think we can only multiplex multiple WPANs in time not frequency. We would also need the ability to register potentially quite a lot of WPANs to a PHY (think a single floor from a block of flats). I can see that we are going to have to worry about bandwidth usage in this case but on the plus side we don't have to worry about meshing and all the protocol traffic that is associated with it as much :) Again thanks for the info, I have a lot to think about.
-Martin ------------------------------------------------------------------------------ _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
