SDN-WISE: diseño, creación de prototipos y experimentación de una solución de SDN con

estado para redes de sensores inalámbricos

A principios de la década de 2000, los sistemas microelectromecánicos (MEMS), las

comunicaciones inalámbricas y la electrónica digital alcanzaron el nivel de madurez necesario
para desarrollar nodos de sensores inalámbricos de bajo consumo y bajo costo capaces de
comunicarse de forma inalámbrica entre sí sin una infraestructura desplegada previamente, es
decir, para formar lo que comúnmente se conoce como redes de sensores inalámbricos (WSN)
s [8]. Impulsado por la promesa de que las WSN habrían producido un impacto radical en varios
escenarios de aplicación, en la última década la comunidad de investigación de redes ha
dedicado un inmenso esfuerzo al estudio de WSN y la definición de soluciones apropiadas para
ellos. Si bien tal esfuerzo ha resultado en una comprensión profunda de la materia relacionada
con WSN, la implementación a gran escala esperada de WSN no ha sucedido completamente
hasta hoy.

Las razones del lento despegue comercial de WSN son múltiples. Sin embargo, en la misma base
hay una razón técnica: los WSN se caracterizan por requisitos profundamente diferentes según
la aplicación específica y el escenario de despliegue. En consecuencia, como ampliamente
reconocido [8], no hay algo así como una solución única para WSN. En cambio, hay una gran
cantidad de soluciones verticales específicas de la aplicación que han resultado en un contexto
y mercado extremadamente fragmentado.

El problema anterior puede superarse haciendo que las WSN sean programables y, por lo tanto,
se han realizado importantes esfuerzos de investigación para diseñar WSN programables [9] -
[11]. Sin embargo, en la mayoría de las implementaciones actuales de WSN en el mundo real, la
programación suele estar estrechamente relacionada con el sistema operativo, lo que requiere
que los desarrolladores de la aplicación se centren en detalles intensivos de bajo nivel en lugar
de en la lógica de la aplicación.

El paradigma de redes definidas por software (SDN) y OpenFlow [3], que actualmente es la
instancia más popular de SDN, se han propuesto recientemente para resolver problemas
análogos en el dominio con cable [1]. En OpenFlow, los nodos de red manejan los paquetes
entrantes como se especifica en la llamada Tabla de Flujo. Cada entrada de la tabla de flujo está
relacionada con un flujo y está compuesta por tres secciones: (i) una regla de coincidencia que
especifica los valores del campo de encabezado que deben encontrarse en los paquetes que
pertenecen al flujo; (ii) la acción que debe ejecutarse en los paquetes del flujo (por ejemplo,
soltar, reenviar a, etc.); y (iii) cierta información estadística sobre el flujo. Si la Tabla de flujo no
contiene ninguna entrada que especifique cómo tratar un determinado paquete, el nodo envía
una solicitud a una entidad de software llamada Controlador que tiene una abstracción de alto
nivel de los elementos de red. El controlador se puede ejecutar en un servidor remoto de una
manera (lógicamente) centralizada. El controlador responde con la información requerida para
completar una nueva entrada de tabla de flujo para manejar el paquete.

De esta forma, OpenFlow separa claramente (incluso físicamente) el plano de datos del plano
de control y entrega una red

• que es fácil de configurar y administrar,

• que puede evolucionar porque, en principio, los nuevos servicios y políticas de gestión pueden
introducirse en la red de la misma manera que lo es instalar un nuevo software en una PC [1],
[2],
• en el que un nodo de red dado puede ser reemplazado por otro producido por cualquier
proveedor, liberando así al operador del bloqueo de proveedor y permitiendo el uso de
hardware básico.

Como resultado, raramente el interés en un nuevo paradigma de redes ha aumentado a un ritmo

tal como está sucediendo para SDN. La mayoría de los operadores de red están ejecutando
experimentos piloto de redes OpenFlow, los fabricantes están produciendo equipos de red
compatibles con OpenFlow, y la comunidad de investigación (tanto académica como industrial)
está involucrada en una gran cantidad de actividades de I + D relacionadas con SDN. Una rápida
ojeada a la lista de miembros de Open Networking Foundation, una organización que promueve
el desarrollo de estándares relacionados con SDN, es suficiente para entender que este hype se
ha extendido también al dominio inalámbrico.

Recientemente han aparecido algunos trabajos destinados a extender los conceptos de SDN a
redes inalámbricas de sensores (WSN) y otras redes inalámbricas de área personal [4], [5]. Los
artículos anteriores representan contribuciones importantes a la literatura SDN ya que
proporcionan motivaciones convincentes para la extensión del paradigma SDN a los dominios
WSN y W-PAN y ofrecen una perspectiva nueva e interesante del paradigma SDN, pero tienen
algunas deficiencias:

• los detalles del protocolo, que son fundamentales para las operaciones correctas de la red, no
se proporcionan;

• no se han llevado a cabo evaluaciones de desempeño de las soluciones propuestas.

En este documento, superamos las deficiencias anteriores y vamos más allá de la literatura de
vanguardia al definir una solución de SDN con estado para redes inalámbricas de sensores1 en
línea con una propuesta reciente de Bianchi et al. [6]. Llamamos a esta solución Solución de
redes definidas por software para redes inalámbricas WInsless (SDN-WISE).

El resto de este documento está organizado de la siguiente manera. En la Sección II

proporcionamos una encuesta del trabajo relacionado. En la Sección III se proporciona una
descripción general de SDN-WISE. Los detalles de las principales características de la solución
propuesta se explican en la Sección IV, mientras que en la Sección V describimos el prototipo
SDN-WISE que hemos desarrollado. El rendimiento de SDN-WISE se evalúa experimentalmente
en la Sección VI. Finalmente, las conclusiones se dibujan en la Sección VII.

II. TRABAJO RELACIONADO

Recientemente, se han propuesto soluciones que amplían el enfoque de OpenFlow al dominio

de redes de sensores inalámbricos. En [4] se identifican los desafíos técnicos que se deben
enfrentar para extender el enfoque de OpenFlow a WSN y luego se propone la solución Sensor
OpenFlow. A diferencia del OpenFlow tradicional, Sensor OpenFlow admite el procesamiento
de paquetes dentro de la red y varios tipos de direccionamiento definidos para WSN. En [12], el
enfoque Sensor OpenFlow se integra con otras técnicas de programación de WSN. En [5], se
introduce la red inalámbrica definida por software (SDWN). Cuando se compara con Sensor
OpenFlow, SDWN ofrece una especificación más flexible de las reglas para clasificar paquetes,
es decir, la coincidencia de flujo puede considerar cualquier parte del paquete, y admite el uso
del ciclo de trabajo para lograr la eficiencia energética en WSN.

Al presentar SDN-WISE vamos más allá de los trabajos anteriores de la siguiente manera.
Definimos una arquitectura completa que permite a los desarrolladores de software
implementar sus Controladores utilizando cualquier lenguaje de programación de su elección.
Además, SDNWISE presenta una capa de software que permite que varias redes virtuales se
ejecuten en el mismo sensor inalámbrico físico o red WPAN, de forma similar a lo que hace
FlowVisor en redes OpenFlow. Además, SDN-WISE proporciona herramientas para ejecutar un
controlador real en una red simulada OMNeT ++, análogamente a Mininet [7].

Además, como se propone en [6] para el dominio con cable, SDN-WISE define mecanismos
simples para la definición y el manejo de la tabla de flujo que hacen que SDN-WISE sea estable
en comparación con el OpenFlow tradicional que no tiene estado. De esta forma, los nodos WSN
se pueden programar como máquinas de estado finito, que pueden ser útiles para reducir la
señalización entre nodos y el controlador, y permiten implementar políticas que no se pueden
admitir de forma apátrida.

Finalmente, hemos implementado un prototipo completo de SDN-WISE que hemos probado

ampliamente en nuestros laboratorios y hemos hecho que el código fuente esté disponible
públicamente en http://www.diit.unict.it/users/gmorabi/sdn-wise/.

Hasta donde tenemos conocimiento, esta es la primera implementación real de una solución
tipo OpenFlow para WSN.

III. VISIÓN GENERAL DE SDN-WISE

En esta sección proporcionamos una descripción general de la solución SDN-WISE. Más

específicamente, primero daremos brevemente los requisitos para estar satisfechos en el diseño
SDN-WISE; luego proporcionaremos una descripción general del enfoque técnico de SDN-WISE.

A. REQUISITOS

Los requisitos para extender el paradigma SDN a WSN ya se han analizado en [4] y [5]. Dichos
requisitos son la consecuencia obvia de las características de los WSN que son significativamente
diferentes de las de las redes cableadas. De hecho, las WSN se caracterizan por sus bajas
capacidades en términos de memoria, procesamiento y disponibilidad de energía. Además, las
aplicaciones de WSN generalmente no son exigentes en términos de tasa de datos. Por lo tanto,
SDN-WISE debe ser eficiente en el uso de los recursos del sensor, incluso si tal eficiencia dará
como resultado una tasa de datos más baja.

Para ahorrar energía, SDN-WISE admite el ciclo de trabajo [13], es decir, la posibilidad de apagar
periódicamente la interfaz de radio de un nodo sensor y la agregación de datos [14]. Estas
características fueron descuidadas en los escenarios con cable de OpenFlow.

Además, las interacciones entre los nodos del sensor y los Controladores deben reducirse tanto
como sea posible para lograr la eficiencia del sistema. En este contexto, cierto nivel de lógica de
control programable en los nodos de sensor puede permitirles tomar decisiones sin interactuar
con el controlador cuando solo se necesita información local. Sin embargo, esto requiere la
introducción de un estado, mientras que la instancia estándar de SDN de OpenFlow es sin estado
[6].

Además, dado que las WSN están intrínsecamente centradas en los datos, se han propuesto
varias soluciones que hacen que los protocolos de red conozcan el contenido del paquete [15].
En consecuencia, los nodos SDN-WISE pueden manejar paquetes basados en el contenido
almacenado en su encabezado y carga. Además, en OpenFlow los paquetes se clasifican en
función de la igualdad entre un determinado campo en el encabezado del paquete y una cadena
dada de bytes; a diferencia de eso, en SDN-WISE dicha clasificación se puede hacer en base a
otros operadores relacionales más complejos, por ejemplo, más altos, más bajos que, diferentes
de, etc. Finalmente, la naturaleza centrada en los datos de WSN implica otra diferencia
significativa entre los comportamiento esperado de SDN-WISE y OpenFlow. De hecho, en
OpenFlow, los recursos de la red se dividen por el FlowVisor en sectores, cada uno asignado a
un Controlador, y un paquete puede pertenecer solo a un segmento. En WSN, en cambio, la
misma información puede ser de interés para varias aplicaciones que utilizan diferentes
controladores. Por lo tanto, en SDN-WISE un paquete no está necesariamente vinculado con un
Controlador, es decir, diferentes Controladores pueden especificar reglas diferentes para el
mismo paquete.

B. ENFOQUE SDN-WISE

El comportamiento de los Nodos de sensores SDN-WISE está completamente codificado en tres

estructuras de datos, a saber: la matriz de estados WISE, la matriz de identificadores aceptados
y la tabla de flujo WISE. Al igual que en la mayoría de los enfoques SDN, tales estructuras se
llenan con la información proveniente de los Controladores, que se ejecuta en servidores
apropiados. De esta forma, los Controladores definen las políticas de red que implementarán
los Nodos de Sensor.

En cualquier momento, los nodos SDN-WISE se caracterizan por un estado actual para cada
controlador activo. Un estado es una cadena de bits "sState". WISE States Array es la estructura
de datos que contiene los valores de los estados actuales.

Dada la naturaleza de transmisión del medio inalámbrico, los nodos sensores también recibirán
paquetes que no están destinados a ellos (ni siquiera para el reenvío). La matriz de ID aceptadas
permite que cada nodo sensor seleccione solo los paquetes que debe procesar. De hecho, el
encabezado de los paquetes contiene un campo en el que se especifica una ID aceptada.

Un nodo, al recibir un paquete, controla si la ID contenida en dicho campo se enumera en su

matriz de ID aceptados. Si este es el caso, el nodo procesará adicionalmente el paquete; de lo
contrario, lo dejará caer.

En el caso de que el paquete deba procesarse, el nodo del sensor examinará las entradas de su
Tabla de flujo WISE. Cada entrada de la tabla de flujo de WISE contiene una sección de Reglas
de coincidencia que especifica las condiciones bajo las cuales se aplica la entrada.

En SDN-WISE, las Reglas de coincidencia pueden considerar cualquier parte del paquete actual,
así como cualquier parte del estado actual. Si se cumplen las Reglas de coincidencia, entonces
el nodo del sensor realizará una acción especificada en la sección restante de la entrada WISE
Flow Table. Tenga en cuenta que dicha acción puede referirse a cómo manejar el paquete y
cómo modificar el estado actual.

Si no se enumera ninguna entrada en la tabla de flujo de WISE cuyas reglas de coincidencia se

aplican al paquete / estado actual, se envía una solicitud a los controladores.

Para contactar a los Controladores, un nodo necesita tener una entrada WISE Flow Table que
indique su mejor próximo salto hacia uno de los sumideros. Esta entrada es diferente de las
otras porque no está configurada por un Controlador, sino que cada nodo la descubre de forma
distribuida.
A tal efecto, un protocolo apropiado es ejecutado por la capa Topology Discovery (TD) como se
describirá en la capa, que se basa en el intercambio y procesamiento de paquetes apropiados
llamados paquetes TD. Dichos paquetes contienen información sobre el nivel de la batería y la
distancia desde el fregadero (más cercano) en términos de número de saltos. Cada vez que un
nodo recibe uno de esos paquetes, compara el mejor próximo salto actual con la información
que acaba de adquirir, luego elige el mejor próximo salto dando prioridad al número de saltos,
luego el valor RSSI recibido con el mensaje y finalmente la batería residual nivel. Esta
información también se usa para completar una lista de WISE Neighbors. Esta lista contiene las
direcciones de los nodos vecinos, sus RSSI y sus niveles de batería. Esta tabla se envía
periódicamente a la capa Topology Management (TM), como se detalla a continuación, para
construir una representación gráfica de la red. Después de eso, la tabla se borra por completo y
se reconstruye con los paquetes TD entrantes para tener siempre una vista actualizada de la
topología local.

Uno de los Controladores actúa como un proxy entre la red física y los otros Controladores. Esto
se llama WISE-Visor y es el análogo de FlowVisor en las redes OpenFlow tradicionales.

Los controladores especifican las políticas de administración de red que debe implementar la
WSN y pueden ser dependientes de la aplicación. En consecuencia, los controladores pueden
interactuar con la aplicación.

Tenga en cuenta que los nodos de sensor tienen capacidades limitadas en términos de memoria,
por lo tanto, la selección del tamaño de las diferentes estructuras de datos es muy importante2.
La elección óptima de dicho tamaño depende de varias características específicas de
implementación establecidas por WISE-Visor durante la fase de inicialización.

C. Arquitectura de protocolo SDN-WISE

En las redes SDN-WISE, se pueden distinguir los nodos de sensor y uno (o varios) sumidero (s).
Los sumideros son las puertas de enlace entre los Nodos de sensores que ejecutan el plano de
datos y los elementos que implementan el plano de control. La pila de protocolos del plano
Datos, principalmente ejecutada por Nodos de sensores, se muestra en el lado izquierdo de la
Figura 1. La pila de protocolos del Disordenador y los otros elementos que implementan el Plano
de control se describen en el lado derecho de la Figura 1. Nodos de sensores incluye un
transceptor IEEE 802.15.4 y una unidad de microcontrol (MCU). Por encima de la pila de
protocolos IEEE 802.15.4, la capa de reenvío se ejecuta en la MCU que maneja los paquetes que
llegan como se especifica en una tabla de flujo WISE3. Esta tabla se actualiza continuamente
mediante la capa Reenvío según los comandos de configuración enviados por los Controladores.

La capa de Procesamiento de paquetes dentro de la red (INPP) se ejecuta en la parte superior

de la capa Reenvío. Esto es responsable de operaciones como la agregación de datos u otro
procesamiento dentro de la red. En la implementación actual de SDN-WISE, la capa de INPP
concatena pequeños paquetes que deben enviarse a lo largo de rutas similares. Esto reduciría
la sobrecarga de la red. Además, estamos desarrollando soluciones que permiten al INPP realizar
una codificación de red que es muy eficiente en varios escenarios de WSN [16], [17].

La capa Topology Discovery (TD), en cambio, puede acceder a todas las capas de la pila de
protocolos mediante las API apropiadas. Por lo tanto, puede recopilar información local de los
nodos y controlar su comportamiento en todas las capas, de acuerdo con las indicaciones
proporcionadas por los Controladores. La capa TD también proporciona una API a la capa de
aplicación, que amplía las API IEEE 802. Esto garantiza el legado con las aplicaciones existentes.
En el plano de control, las lógicas de gestión de red están dictadas por uno o varios
controladores, uno de los cuales es WISE-Visor. WISE-Visor incluye una capa Topology
Management (TM) que abstrae los recursos de red para que diferentes redes lógicas, con
diferentes políticas de administración establecidas por diferentes controladores, puedan
ejecutarse sobre el mismo conjunto de dispositivos físicos. La capa TM tiene acceso a las API que
ofrecen todas las capas de protocolo. Tales API permiten controlar el comportamiento de todas
las capas de protocolo y, por lo tanto, implementar operaciones de capa cruzada. El uso de la
capa TM está impulsado por dos requisitos: i) recopilar información local de los nodos y enviarlos
a los Controladores en forma de un gráfico de la red (información de informes relacionada con
la topología, nivel de energía residual, SNR) en los enlaces, etc.) ii) controlar todas las capas de
pila de protocolo según lo especificado por el (los) Controlador (es). Para ello, entre el dispositivo
receptor (caracterizado por la misma pila de protocolos de Nodos de sensores) y el Visor WISE,
está la capa de Adaptación que se encarga de formatear los mensajes recibidos desde el
Fregadero de forma que puedan ser manejados por el WISE-Visor y viceversa.

Los controladores pueden ejecutarse en el mismo nodo que aloja la capa TM o en servidores
remotos. Como consecuencia, las interacciones entre los Controladores y la capa TM pueden
ocurrir de varias maneras, como se muestra en la parte central de la Figura 1. De hecho, en el
caso de que los Controladores se ejecuten en el mismo nodo que aloja la capa TM, se producirán
interacciones. a través de los métodos de Java ofrecidos por la capa TM. Alternativamente, las
interacciones pueden ocurrir a través de la invocación de método remoto de Java (RMI) o el
Protocolo de acceso de objeto simple (SOAP). De esta forma, los programadores pueden
implementar Controladores en Java o en algunos lenguajes de programación web.

Finalmente, tenga en cuenta que la pila del protocolo SDN-WISE también incluye una capa de
Adaptación específica que puede interactuar con un receptor simulado (no un receptor real). De
esta forma, el plano de control puede establecer las políticas de red de una red simulada. En
otras palabras, SDN-WISE ofrece una herramienta que es muy similar a Mininet [7].
IV. DETALLES DEL PROTOCOLO SDN-WISE