> 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

Reply via email to