Simple duty cycling 802.15.4 MAC protocol #3730

daniel-k · 2015-08-27T16:16:07Z

I have developed a (not so) simple (anymore) duty cycling MAC protocol focused for IEEE 802.15.4 transceiver. It has the working title "LwMAC" which stands for "lightweight MAC", I really didn't have a better idea. This is still work-in-progress but has reached a point where maybe someone else might want to try it or comment on it's future development.

In the current state it behaves like the ~~LPEA~~ LPEAS protocol described in this paper (sorry, there doesn't seem to be a free source). This is quite similiar to ContikiMAC, but doesn't provide compatibility (yet). ~~Later it's planned to add implicit synchronization with neighbor nodes, i.e. extent to LPEAS.~~ Done

I created a quick overview of the overall structure. Maybe this helps to better understand all the moving parts. Yet there is no overview over the RX or TX state machines.

It still has bugs and TODOs, so I want to use this PR as my TODO list.

Currently this depends on ~~#3138~~ ~~#3619~~ ~~#3729~~ ~~#4078~~ ~~#3867~~ ~~#4081~~ ~~#2309~~
Incorporates, but not critical: ~~#3993~~ ~~#3868~~ ~~#3887~~ ~~#4015~~ #4058 ~~#3954~~

TODOs

~~use gnrc pktqueue~~
~~implement broadcast~~
~~verify duty cycling~~
~~implement implicit sync~~
use xtimer instead of RTT peripheral when low power timer source is implemented (xtimer: Add support for arbitrary frequency hardware timers (32768 Hz support) #3990 et al.)
update documentation, make clear what's supposed to be changed by the user
rework error logging
integrate properly and implement selection of mac layer
review and address inline TODOs
major cleanup

How to test

Currently you should use the samr21-xpro board to test this, because certain features (see depending PRs) are only available on that platform. And it's the only I can test :-)

Flash to board with the at86rf2xx driver test:

$ cd tests/driver_at86rf2xx
$ BOARD=samr21-xpro make flash term

Then manually send packet from one board to the other via interactive shell(note: baudrate is 921600)

txtsnd 4 xx:xx Helloxx

or even as broadcast:

txtsnd 4 bcast aReallyBroadCast

You can use a packet sniffer to verify the communication or just check if packets arrive at the destination by flashing the same test.

OlegHahm · 2015-08-29T10:43:53Z

Wooohooo, I'm excited and eager to test!

OlegHahm · 2015-08-29T11:21:02Z

boards/samr21-xpro/Makefile.dep

@@ -1,4 +1,4 @@
 ifneq (,$(filter gnrc_netif_default,$(USEMODULE)))
  USEMODULE += at86rf233
-  USEMODULE += gnrc_nomac
+  USEMODULE += gnrc_lwmac


IMO we should discuss on the mailing list or in the next meeting what we want to configure as the default MAC.

This is not meant to be merged as-is. There is intentionally a separate commit that replaces nomac and eases testing. Since there has only been one MAC layer, I didn't know how to integrate it properly, so I just replaced it.

OlegHahm · 2015-08-29T11:23:37Z

Can we make this independent from gnrc?

OlegHahm · 2015-08-29T11:28:36Z

sys/net/gnrc/link_layer/lwmac/lwmac.c

+
+    netif_hdr = _gnrc_pktbuf_find(pkt, GNRC_NETTYPE_NETIF);
+    if(netif_hdr == NULL) {
+        LOG_WARNING("Reject packet: no NETIF header\n");


I think you should sort out debugging messages from logging messages here.

And in the rest of the PR.

Off course. I don't like that I made my own logging/debugging macros either. All debug messages will need a review when this is ready to be merged. For the time being these will stay as-is.

Okay, makes sense.

daniel-k · 2015-08-29T17:14:04Z

Can we make this independent from gnrc?

I do think so. It only relies on netdev, netapi, netconf and timer interfaces and uses gnrc_pktnsnip_t which doesn't really need to be tied to gnrc imo.

Lwmac for update

miri64 · 2016-10-31T14:30:35Z

Feature freeze and still WIP -> postponed (but I hope to have it in soonish).

zhuoshuguo · 2017-01-05T09:34:19Z

Hi, @daniel-k, could you please rebase Lw-MAC on the new master branch? I have recently built and merged a gnrc_mac module which contains some key MAC functionalities and parameters. Actually, gnrc_mac modularized the key components (like neighbor-list, tx-queue and rx-queue) that were extracted from Lw-MAC.

After rebasing on master, I will help to apply those new features to Lw-MAC, by pushing adaptation PRs to Lw-MAC. :-)

daniel-k · 2017-01-09T11:13:47Z

Hi @zhuoshuguo, will do but it may still take some days, depending on how extensive the rebasing will be. Thanks for already merging some parts :)

zhuoshuguo · 2017-01-09T13:11:59Z

@daniel-k Thanks!
By the way, there is another request from my side: could you also split some parts of this PR that are not direct components of Lw-MAC, like your revisions (or new contributions) of lpm, wireshark into other PRs?
My another personal consideration is that, as the assignee of this PR, I am not familiar with them ;-/, sorry about that. By splitting them into other individual small PRs, other peoples who are more familiar with them can better review and ACK them. What do you think of this proposal? @emmanuelsearch @OlegHahm @miri64 :-)

miri64 · 2017-01-09T13:19:20Z

Splitting PRs by functionality is always a good idea, so 👍

daniel-k · 2017-01-09T14:18:16Z

Those things were never meant to be merged together with LwMAC, that's for example why there's an explicit merge commit.

Let's go through them one by one:

lpm: not my code and marked as a dependency in the description. Has been merged into master some time ago, so will go away after rebasing anyway
gdb: part of lpm merge commit, only there for convenience during work, has it's own PR, will not be merged
wireshark: I consider the Wireshark dissector part of this protocol and as such belongs into this PR. Merging it without LwMAC makes no sense
samr21-xpro code (11aa1cd): This commit is also temporary to test LwMAC with such boards, shouldn't be merged either

So in the end, there's nothing that should be splitted out of the PR. Any comments?

miri64 · 2017-01-09T14:34:04Z

wireshark: I consider the Wireshark dissector part of this protocol and as such belongs into this PR. Merging it without LwMAC makes no sense

but it could be merged as a follow-up.

zhuoshuguo · 2017-01-09T15:39:00Z

@daniel-k Thanks, much more clear to me now. :-)

OlegHahm · 2017-01-15T10:25:09Z

So, what exactly is missing?

daniel-k · 2017-01-15T12:58:18Z

I just tried rebasing this onto the current master branch, but it looks like power management has sufficiently changed over time and seems incompatible to my current approach now ☹️

Any hints what has happened to lpm_prevent_sleep and if there's a replacement?

OlegHahm · 2017-01-15T13:00:04Z

@haukepetersen, @kaspar030, can you take a look?

zhuoshuguo · 2017-01-24T12:05:32Z

Ping~

miri64 · 2017-01-24T15:01:56Z

@haukepetersen @kaspar030 ping? But also due to feature freeze we need to postpone :(.

haukepetersen · 2017-01-25T08:25:39Z

I can't really say much about the MAC layer stuff, but this PR seems to contain some unrelated items:

openocd fixes should be factored out
lpm does not exist anymore

daniel-k · 2017-01-25T10:37:27Z

@haukepetersen

I can't really say much about the MAC layer stuff, but this PR seems to contain some unrelated items:

openocd fixes should be factored out

lpm does not exist anymore

No doubt and already discussed. The ping was more into the direction of:

Any hints what has happened to lpm_prevent_sleep and if there's a replacement?

@haukepetersen, @kaspar030, can you take a look?

If the power management has changed as much as it looked like on the first sight, I won't have the time to adapt the PR in the near future. Sorry, much to busy times at the moment :(

zhuoshuguo · 2017-01-31T14:29:55Z

Hi, @daniel-k, to push Lw-MAC forward immediately, do you mind that I totally take over it?
I mean, if you don't mind, by utilizing and adapting your codes here, I will create a new PR (or several) that realizes the functionalities of Lw-MAC, and this PR here will be replaced and closed?

daniel-k · 2017-01-31T16:57:20Z

Hi @zhuoshuguo, that would be totally fine! Sorry that I cannot spend time on this currently. Feel free to take it over, I thought that I would have proposed this already.

miri64 · 2017-02-17T14:08:05Z

Closed in favor for #6554.

LudwigKnuepfer added 3 commits January 15, 2015 15:02

cpu/samd21: implement low power modes

d272aad

FIXUP: address comments

572f085

FIXUP: add email address

4cf9261

OlegHahm reviewed Aug 29, 2015
View reviewed changes

OlegHahm modified the milestone: Release NEXT MAJOR Sep 2, 2015

miri64 assigned OlegHahm Sep 12, 2015

daniel-k force-pushed the mac_gnrc branch 7 times, most recently from e25303f to 430761b Compare September 24, 2015 14:47

daniel-k mentioned this pull request Sep 25, 2015

cpu/samd21: implement low power modes #2309

Merged

daniel-k force-pushed the mac_gnrc branch 5 times, most recently from 9e03c4c to 7a7862c Compare October 1, 2015 09:51

zhuoshuguo and others added 6 commits October 27, 2016 14:14

Revise l2_add_t bug.

2921daa

Don't queue Null-pkt.

016569f

Add phase into WA and calculate receiver phase based on WA.

55a4785

Extend WR duration to 2 cycles, and enlarge wr-before-phase time.

3327c94

Add random before each WR

25ec6a5

Merge pull request #5 from zhuoshuguo/lwmac_for_update

dc86e20

Lwmac for update

miri64 modified the milestones: Release 2017.01, Release 2016.10 Oct 31, 2016

miri64 modified the milestones: Release 2017.04, Release 2017.01 Jan 24, 2017

zhuoshuguo mentioned this pull request Feb 5, 2017

LWMAC: A simple duty cycling 802.15.4 MAC protocol (2nd try). #6554

Merged

miri64 closed this Feb 17, 2017

Simple duty cycling 802.15.4 MAC protocol #3730

Simple duty cycling 802.15.4 MAC protocol #3730

Uh oh!

Conversation

daniel-k commented Aug 27, 2015 • edited by PeterKietzmann Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TODOs

How to test

Uh oh!

OlegHahm commented Aug 29, 2015

Uh oh!

OlegHahm Aug 29, 2015

Choose a reason for hiding this comment

Uh oh!

daniel-k Aug 29, 2015

Choose a reason for hiding this comment

Uh oh!

OlegHahm commented Aug 29, 2015

Uh oh!

OlegHahm Aug 29, 2015

Choose a reason for hiding this comment

Uh oh!

OlegHahm Aug 29, 2015

Choose a reason for hiding this comment

Uh oh!

daniel-k Aug 29, 2015

Choose a reason for hiding this comment

Uh oh!

OlegHahm Aug 30, 2015

Choose a reason for hiding this comment

Uh oh!

daniel-k commented Aug 29, 2015

Uh oh!

miri64 commented Oct 31, 2016

Uh oh!

zhuoshuguo commented Jan 5, 2017

Uh oh!

daniel-k commented Jan 9, 2017

Uh oh!

zhuoshuguo commented Jan 9, 2017

Uh oh!

miri64 commented Jan 9, 2017

Uh oh!

daniel-k commented Jan 9, 2017

Uh oh!

miri64 commented Jan 9, 2017

Uh oh!

zhuoshuguo commented Jan 9, 2017

Uh oh!

OlegHahm commented Jan 15, 2017

Uh oh!

daniel-k commented Jan 15, 2017

Uh oh!

OlegHahm commented Jan 15, 2017

Uh oh!

zhuoshuguo commented Jan 24, 2017

Uh oh!

miri64 commented Jan 24, 2017

Uh oh!

haukepetersen commented Jan 25, 2017

Uh oh!

daniel-k commented Jan 25, 2017

Uh oh!

zhuoshuguo commented Jan 31, 2017

Uh oh!

daniel-k commented Jan 31, 2017

Uh oh!

miri64 commented Feb 17, 2017

Uh oh!

Uh oh!

daniel-k commented Aug 27, 2015 •

edited by PeterKietzmann

Loading