[riot-devel] IEEE802.15.4 discovery

Jonas Remmert j.remmert at phytec.de
Wed May 20 11:38:23 CEST 2015


Hi,

Yes, that was the intention. However, I had some issues and didnĀ“t 
really made huge progress. Will hopefully come to a clean solution for a 
csma_mac-layer that we need as a basis for further MAC layer. This will 
include message dispatching mechanisms, cca-mechanisms (backoff-time 
implementation when needed) and acknowledge handling (when needed).

As it seems, there are many people that would need an IEEE 802.15.4 
MAC-layer. Had also a discussion with Johann; we think an "IEEE 
802.15.4-MAC layer task force" might be a good idea. As a first step we 
could make a todo list, like [2] and a Wiki-page for further for further 
explanations.

What do you think of the idea of an "IEEE 802.15.4-MAC layer task 
force"? Maybe we can discuss that later in the bi-weekly meeting?

-------------------------------------------------------
Some of my current considerations, for those who are interested.

# Message dispatching problem:
When a node will be associated to an PAN-coordinator, the transmitting 
and receiving time is guided on the superframe architecture. That means 
there will be timespans, where the node can not send messages. 
Nevertheless, there will be incoming task-messages from upper-layer to 
the MAC layer task.
1. Messages from upper layer              (Low-prio)
2. Messages from driver (isr-events)    (High-prio)
3. Messages from timer                        (High-prio)
There must be a mechanism that (i) keeps the message queue empty. (ii) 
Takes care of the current MAC-layer state (just try to send a new packet 
when the MAC layer handled the previous one).

# Storing state variables for the MAC-layer state machine.
1. Static variables: Problem when we have more than one MAC-layer
2. Store them in the device-descriptor: The same device-descriptor may 
be used in different MAC-layer. How to choose the fitting variable set 
(at compile time)?
3. ?

# When these problems are solved, the discovering and associating 
mechanism will include the following tasks.

1. The handling of the incoming and outgoing packets has to be handled 
in the mac layer (currently this is done in each driver implementation). 
This should not be a big thing, as this is already prepared by hauke.

2. Some missing parts in ng_ieee802154. MAC layer settings that describe 
the device "capability information field" [1, section 5.3.1.2] 
(battery/stationary powered; Receiver on when Idle; security capability).

3. Introduce a new statemachine for current association state. The 
statemachine in the csma_mac-layer will be nested into this.

[1] - IEEE 802.15.4 Standard
[2] - https://github.com/RIOT-OS/RIOT/issues/2278

Best
Jonas


On 20.05.2015 10:28, Hauke Petersen wrote:
> Hi,
>
> @Jonas, is your 802.15.4 MAC layer implementation planned to cope with 
> this?
>
> Cheers,
> Hauke
>
>
> On 19.05.2015 20:18, Kaspar Schleiser wrote:
>> Hey,
>>
>> is anybody working on or are there plans for support for discovering
>> 802.15.4 PANs?
>>
>> Kaspar
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel


More information about the devel mailing list