Skip to content

Initial import of csma_mac protocol #2467

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 7 commits into from
Closed

Initial import of csma_mac protocol #2467

wants to merge 7 commits into from

Conversation

jonas-rem
Copy link
Contributor

This PR adds an approach to a simple CSMA MAC layer (simplemac).
It is partly pseudo-code and not a testable implementation yet.

There is also a state-chart diagram that describes the course architecture. You can find it here:
https://github.com/jremmert-phytec-iot/Pictures_Phytec_IOT/blob/master/CSMA_MAC.pdf

I made some assumptions that should be discussed.

  1. Actions on the radio are interrupt driven (perform CCA, successfull ACK receive).
    -> That enables a statemachine driven approach without context switching.
  2. Statemachine <_mac_send_statechart()> will be accessed in irq context (e.g. if CCA-ready Int occured, cb-function if timer expires).
  3. The time in the ISRs will be short, as each state only pokes the next action and returns from the statechart immediately.

@jfischer-no jfischer-no added Type: new feature The issue requests / The PR implemements a new feature for RIOT NSTF State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Feb 18, 2015
@LudwigKnuepfer
Copy link
Member

Can't see a thing at the site you linked to.

thomaseichinger
thomaseichinger reviewed Feb 18, 2015
View reviewed changes
sys/include/net/ng_simplemac.h
/**
* @brief The physical timer that is used for the MAC-layer, (periph/timer - IF).
*/
#define MAC_TIMER TIMER_0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be better defined by the board. TIMER_0 is often used for hwtimer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, ok.
The long term solution would be to use the timer modules of the radio-transceiver. Nearly all transceivers support their own hw-timer. I think, especially it comes to beacon-enabled network it makes more sense to use these timer as they can also trigger automatic actions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this sounds good to me, AFAIK none of our by now supported transceivers provides this functionality or at least don't provide an external API.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought most radios would support this, but I was wrong. I did not found this functionality e.g. in the AT86RF233. The KW2x internal radio supports this and also the event trigger in combination with the timer.
But as it seems to be the only one, the CPU internal timer will fit better.

@thomaseichinger thomaseichinger added the Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR label Feb 18, 2015
@miri64
Copy link
Member

miri64 commented Feb 18, 2015

Why did you decided to call it simplemac instead of e.g. csma_mac?

miri64
miri64 reviewed Feb 18, 2015
View reviewed changes
sys/include/net/ng_simplemac.h
* will attempt before declaring a channel access failure.
* The IEEE 802.15.4 Standard allows values from 0-5.
*/
#define MAX_CSMA_BACKOFFS 4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and all macros below should be prefixed NG_SIMPLEMAC_.

@jonas-rem
Copy link
Contributor Author

I decided to call it simplemac because it is just an CSMA algorithm and not an officially (IEEE 802.15.4) defined MAC layer procedure (only a part of it). In the IEEE 802.15.4 standard describes at least an Beacon synchronized MAC protocol. So this mac protocol should only be a first step to a IEEE 802.15.4 compatible MAC layer.

But csma_mac is also fine, if it is not that important to fully comply with the IEEE standard in this approach.

@miri64
Copy link
Member

miri64 commented Feb 18, 2015

I asked because there can be other simple MAC protocols possible, not utilizing e.g. CSMA but other medium access methods IMHO. Additionally if it is just for IEEE 802.15.4 this should be clear by the name too I think to avoid confusion, since we support more than just IEEE 802.15.4.

@jonas-rem
Copy link
Contributor Author

Ok, you are right. Then I would call it csma_mac and reserve the name IEEE802.15.4_mac or so for a mac layer that fully complies with the standard.

@jonas-rem jonas-rem changed the title Initial import of simplemac-protocol Initial import of csma_mac protocol Feb 18, 2015
@OlegHahm OlegHahm self-assigned this Feb 18, 2015
@OlegHahm
Copy link
Member

Ok, you are right. Then I would call it csma_mac and reserve the name IEEE802.15.4_mac or so for a mac layer that fully complies with the standard.

👍

@jonas-rem jonas-rem force-pushed the wip@simplemac branch 2 times, most recently from ffa0695 to 3aad504 Compare March 20, 2015 16:41
@OlegHahm OlegHahm force-pushed the master branch 3 times, most recently from 9f184dd to 45554bf Compare March 31, 2015 13:01
@OlegHahm OlegHahm modified the milestone: Release 2015.06 Apr 29, 2015
@jonas-rem jonas-rem mentioned this pull request May 20, 2015
Closed
3 tasks
@jonas-rem jonas-rem mentioned this pull request Jul 1, 2015
Merged
@OlegHahm
Copy link
Member

@jremmert-phytec-iot, any news?

@jonas-rem
Copy link
Contributor Author

@OlegHahm No news, sorry. Will hopefully have time to work on this and finish it in the second week of september. If you or anybody else want to take this over, please do.

@OlegHahm OlegHahm modified the milestones: Release 2015.08, Release NEXT MAJOR Sep 2, 2015
@jonas-rem
Copy link
Contributor Author

Won't come to it in the near future -> If there is nobody that wants to take this over, shall we close this for now? Needs adaption to #3730.

@OlegHahm
Copy link
Member

OlegHahm commented Nov 7, 2015

Yes, let's close as a memo then.

@OlegHahm OlegHahm closed this Nov 7, 2015
@OlegHahm OlegHahm added the State: archived State: The PR has been archived for possible future re-adaptation label Nov 7, 2015
@miri64 miri64 added the Area: network Area: Networking label Sep 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@OlegHahm OlegHahm

Labels
Area: network Area: Networking Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR State: archived State: The PR has been archived for possible future re-adaptation State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Milestone
Release 2015.12
Development

Successfully merging this pull request may close these issues.
6 participants
@jonas-rem @LudwigKnuepfer @miri64 @OlegHahm @thomaseichinger @jfischer-no