CC1310, CC1200 etc. This could be merely adding TSCH support for those radios.

If we have modular routing, it may be worth bringing back AODV (but for v6) or something else such as LOADng. This will allow mobility support.

The regression tests are mostly checking that the system behaves as expected for limited inputs and scenarios. A way to increase coverage and testing other aspects such as software security would be to involve more types of tests; e.g., unit testing, static analysis, and fuzzing. For the latter, the procedure takes a long time, so we may want to divide tests that are done for a PR and for a release. Perhaps it would also be interesting to involve well-defined testbed tests for releases.

Figure out if and how we should add complete application architectures in the Contiki file tree.

Refactor examples, core, apps, paltforms, regression tests, everything

Move rpl to ipv6?
Move ip to ipv6? (once ipv4 is removed)

• Recently merged PRs
• Selected pending PRs

There are multiple options how to adapt the channels. Here I'm thinking about an RSSI based approach, where the coordinator node only. I.e. the coordinator sniffs the background noise RSSI levels and accumulates the busy / not busy estimates in a TSCH local stats structure.

The core TSCH part is simple, once the TSCH stats patch is in place.

The actual selection process is more complex, but done in an application - periodically sort the channels by their qualities, replace the worst one if there is a significantly better one available etc.

After the hopping sequence is changed on the coordinator, it sends out the new one in a burst of EB packets.

We need to add an API for filling a buffer with random values as this is often a type of functions used for various encryption and security mechanisms.

Something like:

random_fill(uint8_t *buffer, size_t len);

Homogeneous API for things like SPI, I2C, sensors, so that most examples can run on multiple platforms merely through configuration, but without code modifications.

• GPIO: #257
• LEDS: #319
• Buttons: #169
• SPI: #264
• I2C: #185
• UART / Char I/O

Only platforms with network interface. Only 32-bit platforms, except for sky.

Make it possible to centrally configure debug levels on a per-module basis (similar to TSCH)

the platform is retired, according to Intel. Also, it's an Ethernet-only platform.

Setup a project for the new Contiki

The current plan for RPL-lite (#8) is to support only non-storing mode, because storing it is basically complex and broken. Complex because of stateful route maintenance (registration and de-registration that must be done for every single child and at every node on the path to the root). Broken because it is unable to maintain the routing state consistent. As the goal of RPL-lite is to bring simplicity and reliability, I believe trashing storing mode is the way forward.

Is anybody going to miss storing mode?
If so, how do we handle this?
Do we keep the old RPL as an alternative to RPL-lite?
Or to we have to include storing in RPL-lite? (I would really like to avoid this)

At least I am confused, as this also contains cc13xx.
Any way to make things clearer? And easier to type?

Something similar to nRF52

Similar to the former platform minimal-net, via tun/tap. Enabled testing of network-layer and above protocols locally, e.g. run a Contiki node as process and CoAP request it from the Linux host.

At startup, the first line printed is typically the CONTIKI_VERSION_STRING value set in Makefile.include, which looks like "Contiki-3.x-3638-gc1a917a". Should we change it to "Contiki-NG-3638-g1a917a", "Contiki-NG-1.x-3638-g1a917a", or something else?

csma+nullrdc becomes csma
tsch+nordc becomes tsch
nullmac+nordc becomes nullmac
no other MAC nor RDC left!

This might have some open challenges? Not sure. No specific milestone for this yet.

Avoid code duplication.

Common main (George: Perhaps one that allows platform-specific hooks)

Common examples (now we have the same examples copied 10 times). George: See what I’ve done with sensniff in order to be able to provide a more-or-less-but-not-quite platform independent example. Design could perhaps be improved, but we should be able to have BRs and Slip Radios using similar design.

CC13xx cannot work with TSCH at the moment. We need to provide a layer 2 that works with this platform, till TSCH has been ported over to support it.

This does not necessarily need to keep the original MAC/RDC separation.

We're lagging behind, this is required for standard-compliant RPL

Points for discussion:

• have a stats structure for a single timesource node only, or for each TSCH neighbor? (currently implemented for single only; previous version for each neighbor, but had to drop that because of RAM limitations)
• enabled by default? (currently not)

Link-layer security is not a layer. Should be done as part of the MAC, like in TSCH.

Define routing drivers, and make RPL replaceable with e.g. RIP-NG, LoadNG or anything

uip_conns ends up declared with two different sizes in two different modules, there is a link-time clash:

when parsing examples/ipv6/rpl-udp/udp-server.c:

[kernel] user error: Incompatible declaration for uip_conns:
                     different array sizes
                     First declaration was at /contiki/core/net/ipv6/uip6.c:250
                     Current declaration is at /contiki/core/net/ip/uip.h:1370

Add a uipbuf module with uip attributes and functions for handling packets (such as uint8_t * get_next_protocol_header(uint8_t *p), get_final_protocol_header(*p) etc).

Figure out how to add an significantly improved border router to Contiki and where it should be.

make it a flag of platform cooja rather than a platform of its own

Significant improvement over the current implementation with more of the LWM2M 1.0 features implemented and less memory consumption

Setup process that auto-compiled doxygen and uploads it to some web. Clean-slate restart of the /doc directory

For IP-less testing, a network layer that does essentially nothing

New, streamlined implementation of RPL. Focus on non-storing mode, single instance/dodag, everything simpler and more robust.

Some of the APIs have blocking functions that can take hundreds of milliseconds. "xmem", and possibly some other APIs, should be redesigned a bit so that they do not start busy-looping on a call. This would also require the CFS API to change.

Hey guys

In netstack.h

/* MAC layer configuration. The MAC layer is configured through the Makefile,
   via the flag MAKE_MAC */
#ifdef NETSTACK_CONF_MAC
#define NETSTACK_MAC NETSTACK_CONF_MAC
#else /* NETSTACK_CONF_MAC */
#if MAC_CONF_WITH_NULLMAC
#define NETSTACK_MAC     nullmac_driver
#elif MAC_CONF_WITH_CSMA
#define NETSTACK_MAC     csma_driver
#elif MAC_CONF_WITH_TSCH
#define NETSTACK_MAC     tschmac_driver
#else
#error Unknown MAC configuration
#endif
#endif /* NETSTACK_CONF_MAC */

Unless I've mistaken something here, if Makefiles and the various -conf.h files disagree, the latter win. Is this the intention? Certainly not how I interpret the comment at the start?

Ditto for the network layer.

Move generic services to core
Move example apps to examples
Remove useless stuff

See the discussion here: contiki-os/contiki#2089

I can adapt it for Contiki-NG (some work required) and resubmit here.

The one thing remaining to discuss here: do you have objections against it being enabled by default?
As I stated in the "old" Contiki PR discussion, I believe it would be much more useful if enabled. "Release" builds can always explicitly remove it, by simply adding a compilation flag.

Enables QoS classes at the network stack & application level. For example, monitoring traffic could be given fewer retransmissions that data collection traffic.

This is to discuss how to handle configuration of layers. A problem with the current solution, where we set directly the driver, is that there is no way to know from a pre-processor macro which layer is being used. For instance, if you enable TSCH, then you'd like your platform-conf to figure this out and configure the radio accordingly. But instead we always need workarounds, e.g., "set the MAC layer, but don't forget to also set XYZ for platform X".

Suggestions?

Maybe something such as this in mac.h:

#define CONTIKI_MAC_CSMA 0
#define CONTIKI_MAC_TSCH 1

and in config files:

#define CONTIKI_NETSTACK_MAC CONTIKI_MAC_TSCH

and then the driver is set somewhere else by some contiki h file, but not by the config file.

Are there nicer approaches?

We need to have a full layering in Contiki. At Yanzi we have added a upper layer in form of an IP_LAYER which means that any lower layer would rather do IP_LAYER.input() rather than tcpip_input() or similar. The same goes for upper layer that will send IP in a similar way. This way it is possible to do very advanced IP packet filters by indirection (have your own proxy-IP-LAYER in between) - and in the long run replace the current IP implementation if that would be interesting (e.g. open-thread or similar in Contiki).