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
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
