RPi Border Router

A significant advantage of an IP based wireless sensor network (WSN), particularly with IPV6, where every sensor can have its own IP address (or more than one), is that sensors can be directly accessed via the Internet without requiring any kind of intermediate translation software. This helps to keep the overall system simple and relatively straightforward to configure.

rpi_borderrouter_web_thumb

RPi Border Router

However, some kind of ‘edge router’ is in practice needed, to at least channel data to and from the wireless network to the internet. Furthermore, it is probably also going to be necessary to implement some security functionality at the edge, particularly to support the kind of functionality needed to exchange data between an untrusted network (the Internet) and a relatively trusted one (the WSN).  The resource limits of individual motes will almost certainly struggle to handle such functionality.A significant advantage of an IP based wireless sensor network (WSN), particularly with IPV6, where every sensor can have its own IP address (or more than one), is that sensors can be directly accessed via the Internet without requiring any kind of intermediate translation software. This helps to keep the overall system simple and relatively straightforward to configure.

Our solution is a border router, currently running on a Raspberry Pi (although it could be almost any mainstream Linux capable system), to implement a WSN to Ethernet bridge and also Internet to WSN security.

In addition the border router, which is also effectively a wireless base station, implements an http to CoAP translator, a proxy server that enables cloud based applications to make REST requests via IPV4 to WSN Motes that understand CoAP and IPV6 (6LoWPAN).

border router

Border Router Flow Schematic

The diagram shows a schematic of the border router software components.  We’ll walk through a sensor request to show how this works.

Assume that there is a Python application running on a PC attached to the Internet, which needs to return a lux level from a WSN mote with a light sensor.

def get_luxvalue():
    """ Get the current value of the lux sensor"""
    url = "https://armote.net:8085/proxy/coap://switch.armote.net/sensors/bh1750"
    token = get_tokenvalue()
    headers = {'Accept':'application/json', 'Cookie':token} 
    try:
        m=requests.get(url, headers=headers, verify='/home/ron/Downloads/SSLCerts/suretronic.ca.cert.pem')       
        if m.status_code != 200:
            print 'Error, Status Code: ',m.status_code
            print m.text
            return None
        r=eval(m.text)
        s = json.dumps(r)
        p = json.loads(s)
    except Exception as e:
        print 'Error, Code: ',e
        return None
    return (p['light']['lux'])

The ‘get_luxvalue()’ code snippet above sends an SSL secured https request to the border router at armote.net.  Notice that the url https://armote.net:8085/proxy/coap://switch.armote.net/sensors/bh1750 also indicates a CoAP request to the bh1750 (lux) sensor that is implemented by the mote at address switch.armote.net.   That domain name actually translates to the IPV6 address of the mote.  Notice also that it is an https request. So a certificate will be returned from the border router whose validity is checked using the suretronic.ca.cert.pem certificate authority certificate. The GET request that is sent includes a header that contains a ‘capability token‘ that is returned by the call to get_tokenvalue(). This is a signed token that was obtained out of band, which authorises ‘GET’ access to the bh1750 resource.

At the border router that https request is terminated by an NGINX server (high performance, load balancing web application server), which takes care of the digital certificate handshake, decrypting the message so that it becomes plain text http.  The NGINX server redirects the now unencrypted GET request to a Django (web framework), Python application, running in a uWSGI application server,  that validates the details of the request against the details indicated in the capability token.  If the validation succeeds the request is redirected back to a ‘request authenticated’ handler in the NGINX server.  Otherwise it is redirected to an ‘not authenticated’ handler that returns an (403) error message to the remote requesting application.

The ‘request authorised’ handler redirects the message to a Python reverse proxy service that implements an http to CoAP translator. The service strips out the CoAP part of the request i.e. coap://switch.armote.net/sensors/bh1750 and if it is a domain name translates this into an IPV6 numeric address e.g. coap://2001:4428:29a:0:280:e103:0:6e18/sensors/bh1750.  If the request presents an IPV6 numeric address then its syntax validity is checked.  The CoAP request is subsequently forwarded to the WSN mote itself via the 6lbr border router application.

The 6lbr application is a software router that manages the WSN network, with an internal lookup table with the latest routing information for each mote.   It injects the CoAP request into the WSN network via a (currently) special, serial attached mote that encrypts the message (using AeS) then sends out the request packets on its radio.

Each mote in the WSN implements a CoAP server that listens for and actions requests.

The reverse procedure enable the response to be returned to the requesting application (without capability token authentication).