[riot-devel] CSMA MAC-layer, Open Issues

Jonas Remmert j.remmert at phytec.de
Fri Mar 20 18:02:15 CET 2015


Hi,

I updated the CSMA_MAC PR [1]. Some concepts have slightly changed; e.g. 
the CCA is now assumed to be suppored in HW, before TX. I tested this 
version with the Phytec board, by enabling TESTING_FUNCTIONS in the file 
ng_csma_mac.c. This function simply sets LEDs to observe the TX time of 
the nodes. I observed for the occurance of overlapping TX time of two 
nodes, which wasn´t the case when I used the CSMA/CA mechanism. However, 
this again is only a WIP PR for further discussion.

There popped up some questions about the interaction with a radio driver:

1. Both, the upper layer and the current implementations of the 
ng_netdev radio drivers use task messages to signalize an event (Packet 
to be sent or Packet to receive waiting). Both message mechanisms send 
their messages to the mac_pid and therefore use the same message queue. 
If the mac-layer and the transceiver is busy with sending a message out 
or waiting for an ACK it might wait for a signal from the driver 
(RX-ready, ACK-received...). In the same time there might also be 
messages from the upper layers that can not be handled until the 
previous packet is sent out.

- I handled this problem in using the drivers call-back function in 
combination with different task lock mechanisms for upper layer 
(msg_receive) and for driver events 2x(mutex_lock), which causes in 
TASK_BLOCKED state. That method worked very well, even if I fired the 
mac-layer continously with upper layer messages.

2. The drivers send function builds the IEEE 802.15.4 MAC header on its 
own. The alternative would be to let the MAC layer do this job. This 
would avoid code duplication and make it easier to implement new radio 
drivers. Is there any reason to do this in the driver implementation?

3. Introduction of PHY dependant constants: The constants (e.g. 
SYMBOL_LENGTH used in backoff intervall, MAX_BE, MIN_BE, 
TURNAROUND_TIME, MAC_ACK_WAIT_DURATION, MAX_RETRIES..). As these 
constants are different for each type of PHY (2,5 Ghz, subGhz and also 
Modulation specific) we could put them in a struct that would be linked 
to the device descriptor.

4. Generally, a successfull TX of a packet is not signalized to upper 
layers. But how do we handle a packet that could not be sent to the 
channel (e.g. channel busy)? Should upper layer be informed about the 
failure?

A WIP state of the ng_kw2xrf-driver that I used for testing can be found 
in my repo [2].

a nice Weekend,
Jonas


[1] - https://github.com/RIOT-OS/RIOT/pull/2467
[2] - https://github.com/jremmert-phytec-iot/RIOT/tree/wip%40kw2xrf_ng




More information about the devel mailing list