Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4
Hi Daniel! Is this not a requirement of the routing? Did you have a look at the IEEE 802.15.4 specification? It's assumed to have a so called PAN coordinator that forces the network to a star topology. It's extendable to a tree of stars, but still you need a PAN coordinator in every region. This node is the mentioned single point of failure and additionally has increased energy consumption. This is exactly what I don't want. PAN coordinators are only required for the beacon enabled mode in IEEE 802.15.4. 6LoWPAN, for instance, does not require this mode (I'm not even sure if it is supported by the spec) and thus, there is no need for a PAN coordinator or star topology. Cheers, Oleg -- I'm working on a bittorrent joke, but I only have about 30% and nobody's seeding! pgp6YOpTbl3Hh.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF - Naming the stack
Hi, I just stumbled across ng_netconf - we should rename this to avoid confusion with RFC 6241 [1]. If the stack would have a name, we could simply call it NAME_conf... Cheers, Oleg [1] https://tools.ietf.org/html/rfc6241 -- panic(Alas, I survived.\n); linux-2.6.6/arch/ppc64/kernel/rtas.c pgpWdghPARJI1.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF - Naming the stack
Hi, Martine and me had the same discussion yesterday. Until we have a name, NG_NETOPT would be the natural choice I guess... Cheers, Hauke On 12.05.2015 09:54, Oleg Hahm wrote: Hi, I just stumbled across ng_netconf - we should rename this to avoid confusion with RFC 6241 [1]. If the stack would have a name, we could simply call it NAME_conf... Cheers, Oleg [1] https://tools.ietf.org/html/rfc6241 ___ devel mailing list devel@riot-os.org https://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] Implementing a new MAC protocol for IEEE 802.15.4
On May 11, 2015 3:12 PM, Daniel Krebs m...@daniel-krebs.net wrote: Hi Joakim, +1 We use mostly Contiki-based applications presently and it would be a big improvement if it was possible to get ContikiMAC duty cycling working in RIOT as well. Who is we if I may ask? Just curious. Sorry about that, I should have started with At Eistec, we use mostly contiki... BR, Joakim # Requirements * Mesh topology = no single-point-of-failure Is this not a requirement of the routing? Did you have a look at the IEEE 802.15.4 specification? It's assumed to have a so called PAN coordinator that forces the network to a star topology. It's extendable to a tree of stars, but still you need a PAN coordinator in every region. This node is the mentioned single point of failure and additionally has increased energy consumption. This is exactly what I don't want. # Ideas / Questions * Do we need broadcasting? Routing protocols might need it. RPL sends solicitation messages to ask for routing information. There are broadcasting schemes for the implementation I aim for, but they don't come for free in terms of energy consumption, like e.g. on a network bus. I'll elaborate about this later if you want. * Add multi-hop / routing later? Is this even reasonable? Some kind of routing will be necessary for any useful applications, at least some kind of hardware address to IPv6 address mapping must exist to fill the neighbor cache. (e.g. RPL, NDP) Sure. Hardware addresses are needed anyway to get your data delivered to the destination node. Best regards, Daniel Krebs ___ devel mailing list devel@riot-os.org https://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] Implementing a new MAC protocol for IEEE 802.15.4
Hi Daniel! As it seems that there are only 2 MAC implementations for now [1,2], both not what I'm searching for and also not merged, I decided to try this on my own. There's a third inside the OpenWSN stack using the TSCH (Time Slotted Channel Hopping) as specified in the IEEE 802.15.4e amendment. I'm currently spending some time to see how it could be used separately from the remaining OpenWSN stack, but don't expect any results before next month. While I want to start implementing a basic and simple protocol first, I wonder if it could be nice for RIOT to have some ContikiMAC-compatible MAC layer later. One downside of ContikiMAC is that is not standardized, but that's not necessarily a problem in many use cases. I think the protocol is quite widely deployed and familiar to most people working with WSNs, so I guess it would be really nice to have a compatible implementation. A similar scheme to ContikiMAC was implemented in RIOT, but only for the CC110x transceiver and not adapted to the new interfaces [0]. As there is so much change in all over the network stack at the moment, it would be nice to know which (for me relevant) parts of the stack I should use that are not subject to change shortly. The relevant parts for a MAC layer implementation are probably netdev [1] describing the interface to the transceiver driver, currently implemented for at86rf2xx and XBEE, and the netapi [2] describing the interface of any layer in the network stack, including the MAC protocol. There's also a sketch of the new architecture made by Hauke some time ago [3]. I don't think it's realistic to say that these APIs won't change any more, but I guess they should be stable enough to start implementing against them. * No need to comply with IEEE 802.15.4 MAC schemes Can you elaborate on this point? * Do we need broadcasting? Depends on your use case - for a generic implementation, definitely yes. Remember that typical radio devices in this domain are omnidirectional, hence, you cannot really distinguish between unicast and broadcast on the physical layer. * Add multi-hop / routing later? Is this even reasonable? That's independent from the MAC layer. Can you elaborate on this? * Do we really need adaption to traffic load? One of the main issues with contention based MAC protocols is that they are heavily affected by the traffic load, so you should at least consider different scenarios. * Find out which APIs to use in RIOT to have a modular MAC protocol that might work with multiple transceivers See above, netdev should be your friend. # Observations * Requirements seem to match ContikiMAC, so maybe aim for compatibility? That would be awesome. * LPEAS = Implicit synchronization I wonder if you really want to go for synchronization for a simple contention based protocol. Don't underestimate this challenge. * Use 802.15.4 features, so this might only work with 802.15.4 networks I think you should make the requirements on the transceiver somewhere explicit. Cheers, Oleg [0] https://github.com/RIOT-OS/RIOT/tree/master/drivers/cc110x_legacy_csma [1] https://github.com/RIOT-OS/RIOT/blob/master/sys/include/net/ng_netdev.h [2] https://github.com/RIOT-OS/RIOT/blob/master/sys/include/net/ng_netapi.h [3] http://riot-os.org/files/nstf-overview.pdf -- printk(VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...\n); linux-2.3.99-pre8/fs/super.c pgpw7BPSADwc9.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF - Naming the stack
Hey, what about `ipc_stack` due to its utilization of the former? But still: I'm still not convinced of the reason to give it a name. All operating systems have a default stack but no one is bound to use it and can use their `ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is mainly historic, since it started out as a seperate project. As far as I know TinyOS' stack has no name either. Cheers, Martine 2015-05-12 13:02 GMT+02:00 Kaspar Schleiser kas...@schleiser.de: Hey, On 05/12/2015 09:54 AM, Oleg Hahm wrote: I just stumbled across ng_netconf - we should rename this to avoid confusion with RFC 6241 [1]. If the stack would have a name, we could simply call it NAME_conf... If nameless sticks, we could just replace all ng_ with nl_ ... Until we port libnl, of course. Kaspar ___ devel mailing list devel@riot-os.org https://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] NSTF - Naming the stack
Hi! what about `ipc_stack` due to its utilization of the former? But still: I'm still not convinced of the reason to give it a name. All operating systems have a default stack but no one is bound to use it and can use their `ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is mainly historic, since it started out as a seperate project. As far as I know TinyOS' stack has no name either. Contiki has uIP and RIME, TinyOS has BLIP if I remember correctly. We have ccn-lite, OpenWSN, and this one. I think we cannot compare to Linux, BSD, and the like here. They can afford to make different modules somehow interoperable at cost of memory, we cannot. Won't repeat the arguments for naming. Cheers, Oleg -- panic(huh?\n); linux-2.2.16/arch/i386/kernel/smp.c pgpu7qjcHC363.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4
On May 12, 2015, at 11:00 AM 5/12/15, Martine Lenders authmille...@gmail.com wrote: Hi, Am 12.05.2015 08:08 schrieb Oleg Hahm oliver.h...@inria.fr: Hi Daniel! Is this not a requirement of the routing? Did you have a look at the IEEE 802.15.4 specification? It's assumed to have a so called PAN coordinator that forces the network to a star topology. It's extendable to a tree of stars, but still you need a PAN coordinator in every region. This node is the mentioned single point of failure and additionally has increased energy consumption. This is exactly what I don't want. PAN coordinators are only required for the beacon enabled mode in IEEE 802.15.4. 6LoWPAN, for instance, does not require this mode (I'm not even sure if it is supported by the spec) and thus, there is no need for a PAN coordinator or star topology. I'm not 100% sure, since I'm not THAT knowledgeable in terms of IEEE 802.15.4, but isn't that what 6LoWPAN's mesh-under mode [1] is for? All we need to do to support this mode is to implement support for 6LoWPAN's Mesh [2] and Broadcast [3] headers. 6LoWPAN can be used in a route-over mesh using just IP, as well, for example using RPL as a routing protocol. This mode is of operation is incorporated into the ZigBee-IP specification [1]. - Ralph [1] http://www.zigbee.org/zigbee-for-developers/network-specifications/zigbeeip/#learnmore; the ZigBee-IP specification document is available for free but requires registration. Cheers, Martine [1] https://tools.ietf.org/html/rfc4944#section-11 [2] https://tools.ietf.org/html/rfc4944#section-5.2 [3] https://tools.ietf.org/html/rfc4944#section-11.1 ___ devel mailing list devel@riot-os.org https://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] Implementing a new MAC protocol for IEEE 802.15.4
Hi Emmanuel, One question: do you expect that network membership is rather dynamic, or rather static? (i.e. do nodes come and go due to mobility for example, or due to really long sleeping periods). Depending on the answer to this question, some mechanisms may be more applicable than others... The network will be kind of static, that is my nodes won't be moving around. But I expect to have nodes joining and leaving from time to time, i.e. nodes going offline for a short amount of time, and completely new nodes joining the network. I would be really happy for any advice you could give :) Best regards, Daniel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4
Hi Oleg, PAN coordinators are only required for the beacon enabled mode in IEEE 802.15.4. 6LoWPAN, for instance, does not require this mode (I'm not even sure if it is supported by the spec) and thus, there is no need for a PAN coordinator or star topology. That's unfortunately not the case. Please refer to the specs [1] at Section 5.3, especially the second paragraph. According to the specification a PAN coordinator is always required, even in Mesh topology where it may get dynamically elected. It get's even better (5.5.2.3 Peer-to-peer data transfers): In a peer-to-peer PAN, every device may communicate with every other device in its radio sphere of influence. In order to do this effectively, the devices wishing to communicate will need to either receive constantly or synchronize with each other. In the former case, the device can simply transmit its data using unslotted CSMA-CA. In the latter case, other measures need to be taken in order to achieve synchronization. Such measures are beyond the scope of this standard. As receiving all the time is no option because of energy consumption you need some kind of synchronization. but that's [...] beyond the scope of this standard. Thank you IEEE. That's why I don't aim to be compatible with IEEE 802.15.4-2006 in terms of the MAC-layer. Either I have a PAN coordinator or it advises me to do what I want. Best regards, Daniel Krebs [1] https://openwsn.atlassian.net/wiki/download/attachments/688143/ieee802154-2006.pdf ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4
Hi Daniel! PAN coordinators are only required for the beacon enabled mode in IEEE 802.15.4. 6LoWPAN, for instance, does not require this mode (I'm not even sure if it is supported by the spec) and thus, there is no need for a PAN coordinator or star topology. That's unfortunately not the case. Please refer to the specs [1] at Section 5.3, especially the second paragraph. According to the specification a PAN coordinator is always required, even in Mesh topology where it may get dynamically elected. Ok, I was imprecise here. You still have a pan coordinator but it has another role and it's not really important for the MAC protocol any more (if I'm not completely mistaken). At least, it is not a single point of failure any more, so I fail to see how this is a problem. It get's even better (5.5.2.3 Peer-to-peer data transfers): In a peer-to-peer PAN, every device may communicate with every other device in its radio sphere of influence. In order to do this effectively, the devices wishing to communicate will need to either receive constantly or synchronize with each other. In the former case, the device can simply transmit its data using unslotted CSMA-CA. In the latter case, other measures need to be taken in order to achieve synchronization. Such measures are beyond the scope of this standard. As receiving all the time is no option because of energy consumption you need some kind of synchronization. but that's [...] beyond the scope of this standard. Thank you IEEE. That's why I don't aim to be compatible with IEEE 802.15.4-2006 in terms of the MAC-layer. Either I have a PAN coordinator or it advises me to do what I want. Well, if the spec tells you to do what you want (inside the boundaries of this spec), then you can to what you want and be still 802.15.4 compliant. Cheers, Oleg -- Unix is user friendly... its just selective about who its friends are. pgpn_Ew5ADdl1.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4
Hi Oleg again, There's a third inside the OpenWSN stack using the TSCH (Time Slotted Channel Hopping) as specified in the IEEE 802.15.4e amendment. I'm currently spending some time to see how it could be used separately from the remaining OpenWSN stack, but don't expect any results before next month. I'll have a look at it, thanks for the pointer. As there is so much change in all over the network stack at the moment, it would be nice to know which (for me relevant) parts of the stack I should use that are not subject to change shortly. The relevant parts for a MAC layer implementation are probably netdev [1] describing the interface to the transceiver driver, currently implemented for at86rf2xx and XBEE, and the netapi [2] describing the interface of any layer in the network stack, including the MAC protocol. There's also a sketch of the new architecture made by Hauke some time ago [3]. I don't think it's realistic to say that these APIs won't change any more, but I guess they should be stable enough to start implementing against them. Yesterday I had a look at all the APIs and also found [3] som etime ago on the mailing-list. This helped a lot, thanks Hauke! I summarized my findings in a diagram, now attached to this mail. I also inlcudes the MAC hardware-feature abstraction that Jonas mentioned yesterday. * No need to comply with IEEE 802.15.4 MAC schemes Can you elaborate on this point? As pointed out in my previous mail, I don't aim for compatibility with devices that strictly implement the specification, i.e. need a PAN coordinator. Reasons given in the other mail. * Do we need broadcasting? Depends on your use case - for a generic implementation, definitely yes. Remember that typical radio devices in this domain are omnidirectional, hence, you cannot really distinguish between unicast and broadcast on the physical layer. The probem with duty-cycling is, that packets are not broadcast anymore per-se. You (the sender) need to make sure that every node has woken up at least one time while you have been sending your packet. * Add multi-hop / routing later? Is this even reasonable? That's independent from the MAC layer. Can you elaborate on this? When having multi-hop networks, you essentially have nodes outside the radio scope of each others. But you also have nodes in between that are in the reach of both. This can create a need for scheduling, imagine both nodes, that don't see each other, try to communicate at the same time with the node in between. But I didn't think this through all the way, I just wanted to state that I'm going to ignore this for now. I really shouldn't have used the term routing here :P * Do we really need adaption to traffic load? One of the main issues with contention based MAC protocols is that they are heavily affected by the traffic load, so you should at least consider different scenarios. That's right. I can't really estimate my load at the moment apart from the fact that I'm not going to stream videos and that it will be more than one sensor value per node every 5 minutes : * LPEAS = Implicit synchronization I wonder if you really want to go for synchronization for a simple contention based protocol. Don't underestimate this challenge. Did you have a look at the paper that expalins LPEAS? It's a really simple synchronization scheme. Cheers, Daniel MAC_Overview.pdf Description: Adobe PDF document ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF - Naming the stack
Hey, On 05/12/2015 09:54 AM, Oleg Hahm wrote: I just stumbled across ng_netconf - we should rename this to avoid confusion with RFC 6241 [1]. If the stack would have a name, we could simply call it NAME_conf... If nameless sticks, we could just replace all ng_ with nl_ ... Until we port libnl, of course. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF - Naming the stack
Hi, Am 12. Mai 2015 20:26:58 MESZ, schrieb Oleg Hahm oliver.h...@inria.fr: Hi! what about `ipc_stack` due to its utilization of the former? But still: I'm still not convinced of the reason to give it a name. All operating systems have a default stack but no one is bound to use it and can use their `ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is mainly historic, since it started out as a seperate project. As far as I know TinyOS' stack has no name either. Contiki has uIP and RIME, TinyOS has BLIP if I remember correctly. We have ccn-lite, OpenWSN, and this one. Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if I'm wrong) of the old stack and should be upgraded to use the lower layer(s) of the new stack? (What about OpenWSN?) Or are those layers not considered part of the stack? I think we cannot compare to Linux, BSD, and the like here. They can afford to make different modules somehow interoperable at cost of memory, we cannot. As far as I remember, the modularization of the new stack had exactly this as a goal. Cheers, Ludwig ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] NSTF - Naming the stack
Hi Ludwig! Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if I'm wrong) of the old stack and should be upgraded to use the lower layer(s) of the new stack? (What about OpenWSN?) Or are those layers not considered part of the stack? Yes, you're right, ccn-lite can run directly on top of Link Layer (and actually more or less any other layer) and should be upgraded. OpenWSN provides a full network stack from Link to Application Layer. I think we cannot compare to Linux, BSD, and the like here. They can afford to make different modules somehow interoperable at cost of memory, we cannot. As far as I remember, the modularization of the new stack had exactly this as a goal. Yes, that's correct. However, there will - as Kaspar pointed out - still exist other stack implementations. Actually, this might be another reason for a name: if one implements a new module for this stack, one should indicate that it is compatible to stack XYZ. Cheers, Oleg -- panic(This never returns); linux-2.6.6/kernel/power/swsusp.c pgpUF9jUp9uHw.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
