> 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. ------------------------------------------------------------------------------ _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
