Re: [riot-devel] CSMA MAC-layer, Open Issues
Hi Jonas, On 20.03.2015 18:02, Jonas Remmert wrote: 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. Though this probably works fine, this is not quite how the concept was meant. The problem is of course there: when the MAC layer is getting spammed by upper layer messages, the reaction time for device driver messages might be not as fast... Though the messages should not be los (as they are queued...). The concept is based on the assumption, that the time needed for handling incoming messages in the MAC layer is very short. Also so far we basically assumed, that the MAC layer has a higher priority then the upper layers. This way, the MAC layer will always finish processing all it's queued messages before the upper layers get scheduled again. 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? I don't really understand the code duplication issue here... The MAC layer should actually not know anything about the radio frame format or the like, as the idea behing the MAC layer in the current form is to make them interchangable and usable with different network devices (not only 802.15.4 devices)... So to answer your question: yes! 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. Actually, these constants should not be constants :-) The way I would implement them is by naming these defines something like xx_DEFAULT_MAX_BE, xx_DEFAULT_TURNAROUND_TIME, etc. The you include fields in your device descriptor for these values and initialize them with these values. This way you can change them during runtime and define different values if you run more then 1 device concurrently... 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? So far the packets are just silently dropped. The plain netapi_send() does not support feedback to upper layers on the success of the send process - this we did to avoid deadlock scenarios and synchronization issues... Cheers, Hauke 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 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] CSMA MAC-layer, Open Issues
Hi Jonas, 2015-03-20 18:02 GMT+01:00 Jonas Remmert : > Hi, > > […] > > 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? > Yes, the MAC layers should be as independent from the drivers as possible (with protocols like TSCH for IEEE 802.15.4e this is obviously not possible, but your CSMA implementation might also be used with a cc1100 or other radios). As for avoiding code duplication with IEEE 802.15.4 header building, there is the `ieee802154` [1] module for that. There is also an older PR by Hauke [2], that hopefully will be updated to the new network stack scheme soon ;-). > […] > > 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? > No, it just will be dropped (or the MAC must queue it). > […] a nice Weekend, > Jonas > Have a nice weekend too, Martine [1] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/include/ieee802154_frame.h [2] https://github.com/RIOT-OS/RIOT/pull/2355 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] CSMA MAC-layer, Open Issues
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 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
