Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4

[Daniel Krebs]

Hi Oleg again,

There's a third inside the OpenWSN stack using the TSCH (Time Slotted Channel Hopping) as specified in the IEEE 802.15.4e amendment. I'm currently spending some time to see how it could be used separately from the remaining OpenWSN stack, but don't expect any results before next month.

I'll have a look at it, thanks for the pointer.

As there is so much change in all over the network stack at the moment, it
would be nice to know which (for me relevant) parts of the stack I should
use that are not subject to change shortly.

The relevant parts for a MAC layer implementation are probably netdev [1]
describing the interface to the transceiver driver, currently implemented for
at86rf2xx and XBEE, and the netapi [2] describing the interface of any layer
in the network stack, including the MAC protocol. There's also a sketch of the
new architecture made by Hauke some time ago [3].

I don't think it's realistic to say that these APIs won't change any more, but
I guess they should be stable enough to start implementing against them.

Yesterday I had a look at all the APIs and also found [3] som etime ago on the mailing-list. This helped a lot, thanks Hauke! I summarized my findings in a diagram, now attached to this mail. I also inlcudes the MAC hardware-feature abstraction that Jonas mentioned yesterday.

  * No need to comply with IEEE 802.15.4 MAC schemes

Can you elaborate on this point?

As pointed out in my previous mail, I don't aim for compatibility with devices that strictly implement the specification, i.e. need a PAN coordinator. Reasons given in the other mail.

  * Do we need broadcasting?

Depends on your use case - for a generic implementation, definitely yes.
Remember that typical radio devices in this domain are omnidirectional, hence,
you cannot really distinguish between unicast and broadcast on the physical
layer.

The probem with duty-cycling is, that packets are not broadcast anymore per-se. You (the sender) need to make sure that every node has woken up at least one time while you have been sending your packet.

  * Add multi-hop / routing later? Is this even reasonable?

That's independent from the MAC layer. Can you elaborate on this?

When having multi-hop networks, you essentially have nodes outside the radio scope of each others. But you also have nodes in between that are in the reach of both. This can create a need for scheduling, imagine both nodes, that don't see each other, try to communicate at the same time with the node in between. But I didn't think this through all the way, I just wanted to state that I'm going to ignore this for now.

I really shouldn't have used the term "routing" here :P

  * Do we really need adaption to traffic load?

One of the main issues with contention based MAC protocols is that they are
heavily affected by the traffic load, so you should at least consider
different scenarios.

That's right. I can't really estimate my load at the moment apart from the fact that I'm not going to stream videos and that it will be more than one sensor value per node every 5 minutes :

  * LPEAS => Implicit synchronization
I wonder if you really want to go for synchronization for a simple contention
based protocol. Don't underestimate this challenge.

Did you have a look at the paper that expalins LPEAS? It's a really simple synchronization scheme.

Cheers,
Daniel

MAC_Overview.pdf
Description: Adobe PDF document

_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel