Implementación de IPv6 para Gateway 6LoWPAN con CIAA

Matías Julián Pecchia*, Mario Sebastián Tobar, Franco Matias Aguirre, Juan Carlos Taffernaberry, Ana Laura
Diedrichs

GridTICs – Grupo en Tecnologías de la Información y las Comunicaciones / Departamento

de Electrónica / Facultad Regional Mendoza / Universidad Tecnológica Nacional
Rodríguez 273 Capital M5502AJE – Mendoza, Argentina +54 261 5244563
{matias.pecchia, sebastian.tobar,matias.aguirre,carlos.taffernaberry,ana.diedrichs}@gridtics.frm.utn.edu.ar,

Resumen. En este trabajo se presentan las herramientas, metodología de desarrollo e integración de IPv6 en el firmware de la
CIAA-NXP (Computadora Industrial Abierta Argentina). Este software, el cual se basa en lwIP (lightweight IP), será parte de
un proyecto de implementación de un Gateway 6LoWPAN para aplicaciones del Internet de las Cosas, siendo el mismo un
aporte innovador para el proyecto CIAA.

Palabras Clave: IPV6 gateway, 6LoWPAN, IPv6, CIAA, ARM, OSEK, lwIP, Sistemas Embebidos

1 Introducción
El proyecto CIAA (Computadora Industrial Abierta Argentina) [1], es una arquitectura de hardware y software
abierta creada con fines de uso educativo e industrial. Entre las plataformas de hardware existentes del proyecto
CIAA se encuentra la CIAA-NXP, una computadora que consta de un microcontrolador NXP LPC4337 y varios
periféricos conectados tales como entradas optoacopladas, salidas con relés, salidas analógicas, comunicación
RS485, RS232 y Ethernet, como se puede ver en la Fig.1.
Considerando el crecimiento del Internet de las Cosas (IoT) [2], se espera un gran aumento del número de
dispositivos inteligentes conectados a Internet. Esta situación genera la necesidad de contar con un espacio de
direcciones de red más grande que el de IPv4, por lo que el protocolo IPv6 es el candidato ideal para cubrir esta
demanda.

Fig. 1. Placa CIAA-NXP utilizada en el desarrollo del gateway.

La actual tendencia en el IoT es la utilización de protocolos estandarizados, enfocando sus esfuerzos para la
utilización de versiones reducidas o adaptadas del protocolo IPv6 [3] en dispositivos embebidos. IPv6 para redes
WPAN de baja potencia (6LoWPAN) [4] es una propuesta del estándar que permite el uso de IPv6 sobre redes
inalámbricas como IEEE 802.15.4 [5] o sub-GHz. La capa de adaptación 6LoWPAN posibilita que nodos de, por
ejemplo, una red inalámbrica de sensores (WSN) se comuniquen con dispositivos ubicados fuera de su red
utilizando nativamente IPv6, sin la necesidad de desarrollar una aplicación de traducción de protocolos o proxy.
Un router de borde 6LoWPAN brinda conectividad IPv6 a los nodos que conforman la WSN, siendo responsable
de administrar el tráfico de red desde y hacia la interface Ethernet externa e IEEE 802.15.4 interna. Por lo tanto,
un router de borde cuenta tanto la pila de protocolos IPv6 como 6LoWPAN para poder así comunicar una WPAN
con redes externas IPv6. En la Fig 2 se puede observar un diagrama en bloques del dispositivo completo.
 Fig. 2. Diagrama completo del Gateway de 6loWPAN.

Este documento describe el proceso de implementación de IPv6 en CIAA-NXP como parte del desarrollo del
proyecto "GW-CIAA-IoT: Gateway con CIAA para red inalámbrica de IoT", aprobado y financiado por el
Ministerio de Ciencia, Tecnología e Innovación Productiva [6]. A continuación se indican las los recursos
utilizados (software y hardware de licencias libres), la metodología de integración y desarrollo para poder
configurar IPv6 sobre CIAA-NXP. Al momento de iniciar este proyecto, no existían implementaciones de IPv6
para la CIAA, siendo su desarrollo el principal aporte del presente trabajo.

2. Metodología

En el presente apartado se detalla la forma de trabajo y las etapas que fueron utilizadas para cumplir el objetivo
principal del trabajo.

2.1 Análisis del estado de avance

Debido a que la aplicación GW-CIAA-IoT debe trabajar con situaciones en las que no es posible predecir cuándo
se iniciarán interrupciones de los periféricos ni tampoco se puede asegurar el sincronismo de ellas con el reloj
del microcontrolador, se decidió usar un sistema operativo para manejar estas situaciones. El sistema operativo
FreeOSEK fue escogido para el presente proyecto como CIAA-Firmware por ser, al momento de la elección, el
firmware oficial del proyecto CIAA. FreeOSEK [7] es un sistema operativo de tiempo real (RTOS) basado en
OSEK-VDX [8], de licencia libre y de acceso gratuito. En adelante la expresión CIAA-Firmware hace referencia
a la implementación de FreeOSEK realizada para la plataforma CIAA-NXP.
Se realizó el desarrollo utilizando lwIP [9] por ser una biblioteca que utiliza pocos recursos, extensamente
usada, multiplataforma y también presente en CIAA-Firmware, lo que facilitó proponer aportes al mismo. lwIP
es una biblioteca creada para implementar una pila de protocolos TCP/IP orientada a sistemas embebidos y
utilizada por varios fabricantes de hardware. lwIP se encontraba implementada solo con soporte IPv4 en CIAA-
Firmware [10] para diseños en LPC4337.

2.2 Herramientas

Se usó VirtualBox para crear una máquina virtual en la que fue instalado Ubuntu Linux de 32 bits. Luego, ,sobre
ella, fue instalado el software necesario para desarrollo, de acuerdo a los instructivos de instalación del proyecto
CIAA [11] como GNU ARM Embedded Toolchain [12], Openocd [13], Eclipse [14], git [15]. Esta estrategia
permitió trabajar desde un conjunto de herramientas único en cualquier PC, agilizando el desarrollo en el equipo
de trabajo humano.
Por otra parte, se trabajó versionando con git, lo que permitió poder retroceder en la evolución del código para
descartar o atribuir nuevos errores a parches propios. Git también ayudó a recoger parches que exportamos como
propuesta de cambios en el repositorio oficial de CIAA-Firmware alojado en la plataforma GitHub[16].

2.3 Ensayos

Se consideró esencial tener certeza de cada intervención realizada con fin de aportar a una funcionalidad. A
pesar de trabajar con un sistema operativo, el desarrollo no quedaba exento de incertezas o errores de
programación.
 Se desglosaron las funcionalidades del proyecto en etapas de desarrollo, y estas a su vez en objetivos
funcionales. Para dar por cumplido cada objetivo, se validó el requisito funcional ensayándolo durante al menos
72 horas contínuas de funcionamiento bajo condiciones de estrés. Como ejemplo se puede detallar que para
validar el acceso a la red local se enviaron mensajes de ping [17] cada 10 ms con tamaño de mensaje al límite del
MTU de ethernet.

2.4 Desarrollo

Tomando como base el programa de ejemplo blinking_lwip de uso de Ethernet para la plataforma se realizaron
adaptaciones para darle soporte a IPv6. El funcionamiento del programa es el de un servidor de eco TCP [18].
La implementación de lwIP requiere de controladores para interactuar con el sistema operativo y para el
manejo específico de periféricos. Las aplicaciones interactúan con lwIP invocando algunas de las interfaces de
programación de aplicación (API) que ofrece: una llamada de bajo nivel o "raw", otra de más alto nivel llamada
secuencial similar a BSD sockets, y una tercera compatible con sockets. Las dos últimas requieren que la
aplicación y lwIP se ejecuten en distintos contextos (hilos) y existan por parte del sistema operativo semáforos
para proteger zonas críticas de memoria, mientras que las funciones en modo raw no necesitan acceso
concurrente a memoria. Para el caso del CIAA-Firmware, que no soporta semáforos, se utilizó la API de bajo
nivel en nuestra implementación.
El código de lwIP disponible en CIAA-Firmware al momento de iniciar este proyecto era versión 1.4.1 y tenía
como origen la biblioteca LPCOpen versión 2.16 para LPC4337, contenía los controladores de NXP para
LPC4337 y SMSC 87x0 [19]. Dicho código contaba con parches para adecuar la implementación de LPCOpen
en modo raw en FreeOSEK, debido a que, como se detalló anteriormente, lwIP no usaba multitarea, y CIAA-
Firmware tampoco admitía una implementación compatible con semáforos. Considerando que se esperaba en
poco tiempo una versión de lwIP estable 2.0.0, utilizamos la versión previa a estable número 2 (2.0.0-Release
Candidate 2) que además nativamente admite pilas simultáneas de protocolos IPv6 e IPv4 (Dual Stack).
La implementación de lwIP en CIAA-Firmware utilizaba IPv4 con una dirección IP estática sin posibilidad de
ser modificada en tiempo de ejecución, lo cual constituía una dificultad al momento de desplegar una aplicación
ya que para cada vez que fuera necesario cambiar la dirección IP de la CIAA-NXP era necesario recompilar el
firmware. A lo largo del desarrollo se logró implementar el cliente DHCP de lwIP.
Adicionalmente, se consideró adecuado usar la salida de depuración de lwIP al momento de desarrollar la
implementación para poder conocer causas de errores sin recurrir al depurador, por ello fue necesario compilar
usando el las bibliotecas del toolchain de ARM [12].
La interface IEEE802.15.4 del border router se resolvió usando un nodo de WSN conectado vía UART con la
CIAA, por ello resultó esencial tener funcionales las dos UARTs disponibles. Esta necesidad llevó a encontrar
dos bugs superpuestos relacionados con las rutinas de interrupción del planificador, interrupción de UART, y al
cambio de contexto en rutinas de interrupción [20]. La solución de compromiso que se encontró, sin incurrir en
demoras, fue configurar al planificador del sistema operativo como cooperativo e indicar a las tareas cuándo
liberar el procesador, invocando al planificador periódicamente.
Se realizaron cambios en el manejo de memoria de lwIP para evitar algunos inconvenientes adicionales: se
configuró lwIP para utilizar palabras de 4 bytes y se evitó el uso de ciaaPOSIX_malloc(), en su lugar el sistema
ocupó el manejo propio de lwIP ya que de otra manera su comportamiento era impredecible.

3. Resultados: aportes al proyecto CIAA

Se resume a continuación los aportes [21] a CIAA-Firmware y documentación de CIAA:

● Documentación de origen y reubicación de controladores para lwIP (commit 01870b8): se dejó un

documento indica de dónde llegan los drivers para lwIP. También se reubicaron los fuentes para que se
limiten a ser compilados únicamente con la arquitectura correspondiente a NXP4337 ya que CIAA-
Firmware está pensado para ser usado con otras arquitecturas también.
● Documentación de los parches aplicados a lwIP y los drivers de NXP (commit 543654a): quedaron en
formato parche los cambios a aplicados a los fuentes de drivers NXP.
● Script de descarga automática de LPCOpen y aplicación de parches(commit 543654a).
● lwIP como submódulo git (commit 8a8e48f): para poder hacer uso de versiones posteriores de lwIP.
● Archivo de configuración para lwIP documentado detalladamente (commit e215dd8): lwipopts.h tiene
todas las opciones con los comentarios que se indican en opts.h de lwIP para poder asistir al
desarrollador al momento de elegir opciones.
4. Conclusiones
Se realizaron aportes en cuanto a la conectividad IP para el proyecto CIAA relativos a ordenamiento del código
de los drivers. Se añadió la funcionalidad DHCP para IPV4, permitiendo a la aplicación obtener una dirección IP
de forma dinámica. Se configuró para mantener una pila de protocolos doble: IPV4 e IPV6.
Desarrollar usando git permitió compartir parches con CIAA-Firmware. Por otro lado, el hecho de que el
repositorio de CIAA-Firmware esté en GitHub adicionalmente agilizó el aporte de los parches.
Como trabajo futuro se planea:

● Incorporar una pila 6LowPAN para IEEE 802.15.4, colaborando con el proyecto CIAA para futuras
aplicaciones relativas al IoT.
● Actualizar el submódulo de lwIP del repositorio a versión estable 2.0.0 que se lanzó mientras nosotros
trabajamos en 2.0.0 release candidate 2. Hacer las pruebas y eventuales correcciones necesarias en esa
versión.
● Remover el submódulo y dejar a lwIP como un directorio que llegue de un tarball, a descargar desde la
web oficial de lwIP.
● Remover el código solo compatible con 1.4.1 y las evaluaciones de versión de lwIP.
● Limpiar y documentar el código para que tenga un formato más prolijo.

El proyecto CIAA tiene un largo camino por delante, tanto en materia de conectividad como en el ámbito de
sistemas operativos para embebidos, si bien en este esfuerzo utilizamos el sistema oficial FreeOSEK este no es el
único disponible y se deben realizar esfuerzos para caracterizar y comparar otros como, por ejemplo, nuttx,
FreeRTOS, mbed OS, Contiki.

9. Referencias
1. Página web oficial del proyecto CIAA, http://www.proyecto-ciaa.com.ar/
2. Yaqoob et al., "Internet of Things Architecture: Recent Advances, Taxonomy, Requirements, and Open Challenges," in
IEEE Wireless Communications, vol. 24, no. 3, pp. 10-16, (2017).
3. Internet Protocol, Version 6 (IPv6) Specification, https://tools.ietf.org/html/rfc8200
4. Transmission of IPv6 Packets over IEEE 802.15.4 Networks, https://tools.ietf.org/html/rfc4944
5. “IEEE Std 802.15.4-2003: Wireless Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs),” IEEE Standard, 2003.
6. MINCYT en resolución 613/2015
, http://www.mincyt.gob.ar/adjuntos/archivos/000/042/0000042058.pdf
7. FreeOSEK, http://opensek.sourceforge.net/
8. OSEK-VDX OSEK/VDX, Operating System Specification 2.2.3, 2005.
9. LwIP, https://savannah.nongnu.org/projects/lwip/
10. LwIP en CIAA Firmware, https://github.com/ciaa/Firmware/tree/master/externals/lwip
11. Rodríguez, J., Vecchio, J.: Proyecto CIAA: Primeros pasos en Ubuntu / Linux [Online]. Disponible:
http://www.proyecto-ciaa.com.ar/
12. GNU Arm Embedded Toolchain, https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/
13. Open On-Chip Debugger, http://openocd.org/
14. Eclipse IDE, https://eclipse.org/users/
15. Git distributed version control system, https://git-scm.com/
16. GitHub, https://github.com/
17.Internet Control Message Protocol. J. Postel.,1981, https://tools.ietf.org/html/rfc792
18. Postel, J., "Echo Protocol", STD 20, RFC 862, 1983,https://tools.ietf.org/html/rfc862
19. Microchip Technology Inc,Small Footprint RMII 10/100 Ethernet Transceiver with HP Auto-MDIX
Support,, http://ww1.microchip.com/downloads/en/DeviceDoc/00002165B.pdf
20. Repositorio CIAA-Firmware: Reporte de bug, SetEvent desde ISR2 y WaitEvent desde tareas apropiativas
detienen al sistema (en inglés) https://github.com/ciaa/Firmware/issues/457 - visitada el 2017-09-12
21.Repositorio CIAA-Firmware: historial cambios (commits)
https://github.com/ciaa/Firmware/commits/master - visitada el 2017-09-12