RIOT GPRS
Note: This document updates this one:
Allow a 6LowPAN network to connect to Internet using only a RIOT node with GPRS access as a border router.
For Internet of Things is expected that every node of a network could reach Internet. This is done with packets forwarding among nodes. At some point data will reach a border router, which is in charge of forwarding packets to and from the Internet. Thus end to end communication is possible. For the case, the border router is a RIOT node.
The next picture shows the operation of this kind of RIOT based IoT:
The goal is to implement this GPRS internet access in RIOT, and configure it in a way that permits end to end IPv6 communication for each node.
- Atmel SAMR21 Xplained Pro. (Datasheet)
- SIMCOM SIM900 GSM modem (Datasheet, AT commands)
A board kit for SIM900 was bought for easy development. It comes bundled with the modem.
It’s required the implementation of a SIM900 driver. In a GSM network all data is carried using a PPP protocol, so the driver requires a PPP stack (named GNRC PPP) for internet access. The PPP stack is described in RFC 1661 (Point to Point protocol), RFC 1662 (PPP in HDLC-like framing) and RFC 1332 (Internet Protocol Control Protocol for IPv4). There's a PPP stack implementation in Contiki OS available at Contiki's github.
Unfortunately there are no mobile operators that work with IPv6. Nevertheless is possible to use some mechanism like 6in4 that makes possible to forward IPv6 packets over an IPv4 tunnel. Check IPv6 over IPv4 tunneling section for further details.
On RIOT side, this involved the development of a pppdev interface (see Technical stuff)
Check the [Technical stuff](Technical stuff) section for further information about the implementation.
For the PPP stack:
- PPP stack is working, but needs some minor things (mostly in API functions and config options). It has the full implementation of Link Control Protocol and IPCP (for IPv4), and it's highly configurable and extensible.
- LCP has Async Control Character Map and Maximum Received Unit options implemented. The second one is implemented but being ignored by driver for the moment.
- IPCP has implemented the IP Address option, that is mandatory for this kind of networks
For the SIM900 driver:
- AT command send/reception working.
- Correct handling of ppp packets. This involves FCS calculation.
- Unfortunately the board kit doesn't have access to hardware flow control pins, but a software flow control could be used. It's still not implemented though.
- Current implementation is completely independent of PPP.
For 6in4, there are only implementations of IPv4 headers and ICMP. There might be some issues for implementing 6in4 if the mobile operator doesn't know how to handle this packets. Research is being done.
- GNRC needs better API and deep testing. This is supposed to be done before May 12.
- Driver needs better handling of disconnections. In case of internet disconnection, this is handled automatically by the LCP protocol. If the modem suffers from a power loss, it looses the data mode and LCP stops working. This case needs to be handled (deadline May 10).
- As most modems operate in the same way (generic AT commands + data mode), there's a discussion about implementing a generic AT based device driver.
- Implementation of 6in4 or equivalent. There are some other alternatives like Teredo that has tunnel brokers like TREX