diseno~ de un gateway de nido por software para...
TRANSCRIPT
Diseno de un Gateway Definido porSoftware para Aplicaciones en Redes
Inalambricas de Corto Alcance
Cristian David Rodrıguez Rodrıguez
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenerıa, Ingenierıa Electronica
Bogota, Colombia
2017
Diseno De Un Gateway Definido PorSoftware Para Aplicaciones En Redes
Inalambricas De Corto Alcance
Cristian David Rodrıguez Rodrıguez
Tesis presentada como requisito para optar al tıtulo de:
Ingeniero Electronico
Director:
PhD Gustavo Adolfo Puerto Leguizamon
Lınea de Investigacion:
Radio Definida por Software
Grupo de Investigacion:
GRECO
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenierıa, Ingenierıa Electronica
Bogota, Colombia
2017
(Dedicatoria)
A Dios y mis padres por su infinito apoyo.
Contenido
1 Introduccion 1
1.1 Contenido del libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Objetivos 4
2.1 Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Planteamiento del problema 5
3.1 Definicion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Alcances y limitaciones 7
4.1 Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Marco de referencia 8
5.1 Radio definida por software . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1 Concepto de Radio definida por software . . . . . . . . . . . . . . . . 8
5.1.2 Ventajas de SDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.3 Retos de SDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.4 Antecedentes y surgimiento . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.5 Ambito de aplicaciones para tecnologıas SDR . . . . . . . . . . . . . 11
5.2 Sistemas de inferencia difusa . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1 Concepto de un sistema de inferencia difusa . . . . . . . . . . . . . . 12
5.2.2 Ventajas de la logica difusa . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.3 Optimizacion por medio de computacion evolutiva . . . . . . . . . . . 14
5.3 Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.1 GNU Radio Companion 3.7 . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.2 Plataforma hardware para desarrollo de radios definidos por software 16
6 Estado del arte 19
6.1 Radio definida por software . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1 Trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2 IEEE 802.11 en GnuRadio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
viii Contenido
6.3 IEEE 802.15.4 en GnuRadio . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4 Sistemas de inferencia difusa en SDR . . . . . . . . . . . . . . . . . . . . . . 21
7 Analisis de protocolos 23
7.1 Determinacion del estandar inalambrico de corto alcance . . . . . . . . . . . 24
7.1.1 WirlessHART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1.3 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2 IEEE 802.11a/g/p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2.1 Transceptor implementado en GNU Radio . . . . . . . . . . . . . . . 27
7.3 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3.1 Transceptor implementado en GNU Radio . . . . . . . . . . . . . . . 30
7.4 Equivalencias entre IEEE 802.11a/g/p e IEEE 802.15.4 . . . . . . . . . . . . 33
8 Modificacion de umbral de procesamiento a partir de logica difusa 36
8.1 Descripcion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1.1 Umbral de procesamiento en IEEE 802.11 . . . . . . . . . . . . . . . 36
8.2 Sistema de inferencia difusa propuesto . . . . . . . . . . . . . . . . . . . . . 38
8.2.1 Salida y Entradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2.2 Funciones de pertenencias propuestas . . . . . . . . . . . . . . . . . . 44
8.2.3 Reglas propuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.2.4 Conformacion del sistema de inferencia difuso . . . . . . . . . . . . . 54
8.2.5 Evaluacion del sistema de inferencia difuso . . . . . . . . . . . . . . . 57
8.3 Algoritmo genetico para ajuste de conjuntos de pertenencia . . . . . . . . . . 59
8.3.1 Modelo propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.3.2 Construccion del genoma . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.3.3 Funcion objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9 Implementacion del gateway 62
9.1 Integracion sistema difuso para modificacion del umbral en el receptor de
IEEE802.11a/g/p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.1.1 Bloque WiFi Sync Short . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.1.2 Bloque WiFi Threshold Generator . . . . . . . . . . . . . . . . . . . . 66
9.2 integracion IEEE 802.11 e IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . 69
9.2.1 Bloque WiFi Message Handler . . . . . . . . . . . . . . . . . . . . . . 71
9.2.2 Bloque Zigbee Message Handler . . . . . . . . . . . . . . . . . . . . . 74
9.2.3 Bloque WiFi USRP Control . . . . . . . . . . . . . . . . . . . . . . . 75
9.2.4 Bloque WiFi Tx Switch . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.2.5 Bloque WiFi Rx Switch . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.2.6 Modificaciones a los transceptores de IEEE 802.11a/g/p y 802.15.4 . 80
Contenido ix
10 Experimentos y resultados 82
10.1 Sistema difuso generado por el algoritmo de evolucion diferencial . . . . . . . 82
10.1.1 Construccion de la base de datos de entrenamiento y validacion . . . 82
10.1.2 Determinacion de parametros iniciales del algoritmo . . . . . . . . . . 83
10.1.3 Analisis de resultados de entrenamiento y validacion . . . . . . . . . . 83
10.1.4 Ajuste de las funciones de pertenencia . . . . . . . . . . . . . . . . . 84
10.2 Integracion del sistema difuso en el receptor de IEEE802.11a/g/p . . . . . . 88
10.2.1 Bloque WiFi Sync Short . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.2.2 Implementacion en GNURadio . . . . . . . . . . . . . . . . . . . . . . 89
10.3 Implementacion y experimentos para el gateway . . . . . . . . . . . . . . . . 95
10.3.1 Flujograma del gateway en GNU Radio . . . . . . . . . . . . . . . . . 95
10.3.2 Nodos de comunicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 98
10.3.3 Validacion del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 101
11 Conclusiones y analisis de resultados 105
11.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
11.2 Aportes originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
11.3 Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
12 Anexos 110
12.1 Anexo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
12.2 Anexo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
12.3 Anexo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Lista de Figuras
5-1. Estructura en bloques de un modulo SDR . . . . . . . . . . . . . . . . . . 8
5-2. Estructura de un sistema de inferencia difusa . . . . . . . . . . . . . . . . 12
5-3. Representacion de los conjuntos difusos . . . . . . . . . . . . . . . . . . . 14
5-4. Plataformas de desarrollo USRP N210 y B210. . . . . . . . . . . . . . . . 16
7-1. Esquema organizacional de las redes inalambricas segun su cobertura . . . 23
7-2. Stack del protocolo WirelessHART . . . . . . . . . . . . . . . . . . . . . . 24
7-3. Flujograma del transceptor para IEEE 802.11 a/g/p . . . . . . . . . . . . 28
7-4. Flujograma del transceptor para IEEE 802.15.4 [31] . . . . . . . . . . . . 31
7-5. Flujograma del transceptor para IEEE 802.15.4 modificado [2]. . . . . . . 32
7-6. Trama WiFi producida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7-7. Cabecera PLCP para IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . 34
7-8. Trama MAC para IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 34
7-9. Campo control de trama para IEEE 802.11 . . . . . . . . . . . . . . . . . 34
7-10. Campo secuencia de trama para IEEE 802.11 . . . . . . . . . . . . . . . . 35
8-1. Flujograma para recepcion de IEEE 802.11a/g/p para analizar el compor-
tamiento de las cuatro variables: Este flujograma se implementa en la USRP
B210. SNR, proviene del bloque WiFi Message Handler, FER, proviene del
bloque WiFi Parse MAC, Potencia de la senal, proviene del bloque Moving
Average y Threshold, es configurado a partir del bloque Message Strobe.
Ademas, se agrega un conector a Wireshark donde se puede evidenciar el
formato de cada trama que arriba. . . . . . . . . . . . . . . . . . . . . . . 38
8-2. Flujograma para transmision de IEEE 802.11a/g/p usado en el analisis del
comportamiento de las cuatro variables: Este flujograma se implementa en
la USRP N210. Por medio de este se generan 10 mensajes por segundo con
la palabra “tes”. Se introduce un parametro para la variacion de la potencia
de transmision, a partir de la cual se modifican los parametros en recepcion. 39
8-3. Resultados para la proporcion de tramas recibidas al variar el parametro
threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8-4. Efecto de un SNR arriba de los 25 dB sobre la constelacion. . . . . . . . . 40
8-5. Efecto de un SNR alrededor de los 16 dB sobre la constelacion. . . . . . . 41
8-6. Efecto de un SNR por debajo de los 10 dB sobre la constelacion. . . . . . 41
Lista de Figuras xi
8-7. Resultados para la proporcion de tramas recibidas al variar el parametro
SNR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8-8. Resultados para el Frame Error Rate FER al variar el parametro threshold. 42
8-9. Relacion entre la potencia media y la ganancia de recepcion normalizada. 44
8-10. Funciones de pertenencia estimadas para la variable de salida threshold. . 46
8-11. Funciones de pertenencia estimadas para la variable de entrada SNR. . . . 47
8-12. Funciones de pertenencia estimadas para la variable de entrada FER. . . . 48
8-13. Funciones de pertenencia estimadas para la variable de entrada ganancia
de recepcion normalizada. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8-14. Funciones de pertenencia estimadas para la variable de entrada potencia
media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8-15. Funciones de pertenencia estimadas modificadas para la variable de entrada
SNR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8-16. Funciones de pertenencia estimadas modificadas para la variable de entrada
potencia media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8-17. Modelo de inferencia con fusificador y defusificador. . . . . . . . . . . . . 54
8-18. Proceso de fusificacion para funcion de pertenencia de salida con soporte
ubicado hacia los valores altos del universo. . . . . . . . . . . . . . . . . . 56
8-19. Proceso de fusificacion para funcion de pertenencia de salida con soporte
distribuido a lo largo del universo. . . . . . . . . . . . . . . . . . . . . . . 56
8-20. Proceso de fusificacion con niveles bajos de disparo en la mayorıa de las
funciones de pertenencia de salida. . . . . . . . . . . . . . . . . . . . . . . 57
8-21. Comparacion entre las salidas producidas por el sistema difuso y la esperada. 58
8-22. Modelo de evolucion diferencial propuesto. . . . . . . . . . . . . . . . . . . 60
9-1. Bloque WiFi Sync Short modificado . . . . . . . . . . . . . . . . . . . . . 62
9-2. Bloque WiFi Sync Short modificado. . . . . . . . . . . . . . . . . . . . . . 63
9-3. Bloque WiFi Threshold Generator: En este bloque se introduce el sistema
de inferencia difuso disenado. . . . . . . . . . . . . . . . . . . . . . . . . . 66
9-4. Diagrama general para el gateway . . . . . . . . . . . . . . . . . . . . . . 69
9-5. Diagrama para el gateway con bloques de control . . . . . . . . . . . . . . 71
9-6. Bloque Wifi Message Handler: Se encarga de administrar los mensajes ge-
nerados por la subcapa MAC de IEEE 802.11a/g/p . . . . . . . . . . . . . 72
9-7. Bloque Zigbee Message Handler: Se encarga de administrar los mensajes
generados por la capa de aplicacion de Zigbee . . . . . . . . . . . . . . . . 74
9-8. Bloque USRP Control: Se encarga de enviar los comandos de configuracion
a las interfaces de la USRP N210. . . . . . . . . . . . . . . . . . . . . . . 75
9-9. Bloque Tx Switch: Se encarga de entregar al transmisor de la USRP N210
la salida correspondiente al estandar con el que esta configurado el nodo
de destino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
xii Lista de Figuras
9-10. Bloque Rx Switch: Se encarga de entregar la salida del receptor de la USRP
N210 a la entrada del estandar con el que esta configurado el nodo que envio
el mensaje. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9-11. Modificaciones a bloques del transceptor IEEE802.11a/g/p. . . . . . . . . 80
9-12. Modificaciones al flujograma de IEEE802.15.4: El bloque Rx Xbee es un
bloque jerarquico que contiene la capa fısica, de enlace, de red y de aplica-
cion para recepcion de IEEE 802.15.4/Zigbee 2006. Equivalentemente Tx
Xbee para transmision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10-1. Funciones de pertenencia ajustadas para el threshold. . . . . . . . . . . . 84
10-2. Funciones de pertenencia ajustadas para el threshold. . . . . . . . . . . . 85
10-3. Funciones de pertenencia ajustadas para el SNR. . . . . . . . . . . . . . . 86
10-4. Funciones de pertenencia ajustadas para el FER. . . . . . . . . . . . . . . 87
10-5. Funciones de pertenencia ajustadas para la potencia media. . . . . . . . . 87
10-6. Funciones de pertenencia ajustadas para la ganancia de recepcion norma-
lizada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10-7. Modificacion al flujograma . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10-8. Salida en la consola de GNURadio . . . . . . . . . . . . . . . . . . . . . . 89
10-9. Flujograma disenado para implementar el cambio del umbral de procesa-
miento en recepcion de IEEE802.11a/g/p. . . . . . . . . . . . . . . . . . . 90
10-10. Modificacion del threshold para las pruebas realizadas con la implementa-
cion del sistema de inferencia difuso. . . . . . . . . . . . . . . . . . . . . . 93
10-11. Modificacion del threshold al variar unicamente el SNR: Las demas entra-
das se establecen en valores iniciales alrededor de 0.75 para la ganancia
normalizada y -55dB para la potencia media. . . . . . . . . . . . . . . . . 94
10-12. Modificacion del threshold al variar unicamente la potencia media que per-
cibe el transmisor: Las demas entradas se establecen en valores iniciales
alrededor de 20dB para el SNR y 0.75 para la ganancia normalizada. . . . 94
10-13. Modificacion del threshold al variar unicamente la ganancia normalizada:
Las demas entradas se establecen en valores iniciales alrededor de 20dB
para el SNR y -55dB para la potencia media. . . . . . . . . . . . . . . . . 95
10-14. Flujograma implementado sobre GNU Radio para la construccion del ga-
teway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
10-15. Interfaz grafica disenada para el gateway. . . . . . . . . . . . . . . . . . . 97
10-16. Configuracion hardware de la USRP N210 para implementar los bloques
funcionales del gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
10-17. Flujograma disenado para el nodo IEEE 802.11a/g/p. . . . . . . . . . . . 99
10-18. Interfaz grafica para el nodo IEEE 802.11a/g/p. . . . . . . . . . . . . . . 100
10-19. Configuracion hardware de la USRP B210 para implementar el nodo IEEE
802.11a/g/p. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Lista de Figuras xiii
10-20. Nodo para IEEE 802.15.4 a partir de un modulo Xbee S2, sensor de tem-
peratura y LCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
10-21. Montaje para comprobar el funcionamiento del gateway. . . . . . . . . . . 102
10-22. Trama IEEE 802.11a/g/p del mensaje enviado. . . . . . . . . . . . . . . . 102
10-23. Trama IEEE 802.15.4 del mensaje recibido. . . . . . . . . . . . . . . . . . 103
10-24. Trama IEEE 802.15.4 del mensaje enviado. . . . . . . . . . . . . . . . . . 103
10-25. Trama IEEE 802.11a/g/p del mensaje recibido. . . . . . . . . . . . . . . . 104
Lista de Tablas
5-1. Caracterısticas principales de las plataformas de desarrollo USRP B210 y
N210 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7-1. Principales caracterıstica de IEEE 802.11a/g/p . . . . . . . . . . . . . . . 26
7-2. Equivalencias necesarias para permitir comunicacion entre IEEE 802.15.4
e IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8-1. Intervalos para entradas y salida del sistema difuso . . . . . . . . . . . . . 44
8-2. Reglas Si-entonces para el sistema de inferencia difuso . . . . . . . . . . . 53
10-1. Parametros para inicializar el algoritmo de evolucion diferencial . . . . . . 83
10-2. Resultados del algoritmo de evolucion diferencial . . . . . . . . . . . . . . 84
10-3. Variables inicializadas en el inicio de la aplicacion . . . . . . . . . . . . . . 91
10-4. Operaciones realizadas para generar un valor del threshold . . . . . . . . . 92
10-5. Parametros iniciales en el flujograma del gateway . . . . . . . . . . . . . . 97
1 Introduccion
La rapida evolucion de los sistemas de comunicacion requiere una insercion transparente de
las nuevas tecnologıas garantizando compatibilidad entre los dispositivos actualizados y los
dispositivos heredados. Radio definida por software, SDR por sus siglas en ingles, se presenta
como una tecnologıa que permite anadir nuevas funcionalidades sin generar cambios en el
hardware incluso durante una actualizacion tecnologica.
El principal campo de aplicacion de SDR, y, concepto de su fundamentacion misma, se enfoca
en el diseno de un dispositivo capaz de comunicarse con cualquier estandar de comunica-
cion [1]. El presente proyecto pretende aportar al camino hacia la construccion de dicho
dispositivo por medio del establecimiento de un concentrador capaz de interactuar con dos
protocolos de comunicacion diferentes, implementados sobre un transceptor inmerso en una
tarjeta de desarrollo con capacidades de configuracion de parametros por software.
El trabajo propuesto se encuentra en el marco del proyecto de investigacion en tecnologıas
SDR impulsado por el grupo GRECO. Por tal razon se considera una continuacion del desa-
rrollo previo en el area [2], pretendiendo ası, la unificacion de los aportes alcanzados y los
desarrollos propuestos en el documento. De esta manera, se atacaran dos grandes proble-
mas dentro del flujo de tareas. En primer lugar la implementacion de un protocolo de redes
de corto alcance, siendo este previamente abordado en trabajos de SDR, posibilitando la
descripcion de particularidades de su comportamiento por medio de bloques funcionales de
comunicacion. Y posteriormente la unificacion de esta contribucion con el desarrollo previo
por medio de la construccion de un dispositivo de comunicaciones con funcionalidades de
concentrador. Ası pues, el enfoque del trabajo se limita a la implementacion de este dispo-
sitivo, requiriendose el estudio sobre un protocolo adicional al de [2] para su diseno.
1.1. Contenido del libro
La propuesta e implementacion de un dispositivo con capacidades de concentrador (ga-
teway) definido por software, es presentado a lo largo del libro. El gateway disenado es
capaz de permitir la comunicacion entre nodos que soportan el estandar IEEE802.11a/g/p
o IEEE802.15.4, como aporte al estado del arte en la convergencia de estandares de co-
municacion, representando un reto mayormente tecnico. Ademas, se propone un sistema
2 1 Introduccion
difuso para modificar automaticamente el umbral de procesamiento en la capa fısica de
IEEE802.11a/g/p, como aporte al conocimiento tecnico implementado en las areas de radio
definida por software e inteligencia computacional, representando un reto mayormente con-
ceptual. De esta manera se presenta un propuesta con caracter interdisciplinar e innovador
que aporta al estado del arte implementado. El libro se divide en tres grandes grupos, estos
son contextualizacion, diseno, y, presentacion y analisis de resultados.
Contextualizacion: En los siguientes tres capıtulos se exponen las generalidades del problema
abordado y los objetivos trazados para su solucion. Posteriormente, debido a la interdiscipli-
naridad del trabajo, se incluye un breve marco de referencia para facilitar la interpretacion
de las afirmaciones realizadas en los capıtulos posteriores, donde se describen los dos grandes
campos del conocimiento abordados, radio definida por software e inteligencia computacio-
nal. Equivalentemente, se incluye un estado del arte para contextualizar el desarrollo en el
campo de radio definida por software, haciendo enfasis en los estandares de comunicacion
inalambrica de corto alcance de interes.
Diseno: En primer lugar, se realiza un estudio extenso de las implementaciones existentes
para protocolos de comunicacion inalambrica de corto alcance, explorando sus limitacio-
nes y oportunidades de desarrollo. A partir de esto, se justifica la seleccion del estandar
IEEE802.11a/g/p para integrarse, a traves del gateway, con IEEE802.15.4. Los flujogramas
existentes, implementados sobre GNURadio, y su correspondiente configuracion, se expone
para ambos casos. A continuacion, a partir del estudio de las oportunidades de desarrollo pa-
ra IEEE802.11a/g/p, se propone un sistema de inferencia difuso para modificar el umbral de
procesamiento en la capa fısica. El desarrollo incluye, un analisis de las variables relacionadas
al umbral de procesamiento, la construccion de funciones de pertenencia y reglas si-entonces
para modelar la relacion no lineal entre las variables estudiadas y el umbral, el desarrollo
matematico del sistema de inferencia difuso, y, un algoritmo de evolucion diferencial para
optimizar las funciones de pertenencia y reglas propuestas inicialmente. Posteriormente, se
describe la implementacion del gateway sobre GNURadio, donde se expone el bloque fun-
cional para la implementacion del sistema difuso, el modelo de operacion del gateway y los
bloques funcionales que lo componen, las modificaciones realizadas a los flujogramas de cada
estandar, y, la construccion de los nodos de comunicacion.
Presentacion y analisis de resultados: Siguiendo el flujo propuesto en el diseno, en primer
lugar, se presenta la implementacion del algoritmo de evolucion diferencial, enfatizando en
los experimentos realizados para definir la base de datos (entrenamiento y validacion) y
sus parametros iniciales, los resultados de dichos experimentos, y, el ajuste generado en las
funciones de pertenencia. Posteriormente, se exponen los experimentos y resultados, para la
integracion del sistema difuso en el capa fısica del receptor de IEEE802.11a/g/p, ası como
la comprobacion del funcionamiento de los transceptores para cada estandar. Finalmente se
1.1 Contenido del libro 3
presentan los resultados de la implementacion del gateway a traves de experimentos con los
nodos de comunicacion. De esta manera, es posible introducir conclusiones, analisis de los
aportes, una perspectiva de los retos y problematicos del desarrollo, y, trabajos futuros.
2 Objetivos
2.1. Objetivo General
Disenar e implementar un modulo de comunicacion con funcionalidades de concen-
trador bajo el paradigma de SDR como aporte a la convergencia entre protocolos
inalambricos en redes de corto alcance.
2.2. Objetivos especıficos
Identificar los estandares en redes inalambricas de corto alcance abordados por medio
de conceptos SDR.
Identificar las limitaciones de la plataforma hardware USRP B210 en relacion con las
necesidades de los estandares identificados.
Implementar bloques digitales de comunicacion capaces de replicar particularidades
del comportamiento de uno de los protocolos reconocidos.
Establecer el flujo comportamental del concentrador incorporando bloques funcionales
de comunicacion.
Evaluar la funcionalidad del sistema desarrollado en un entorno de comunicacion de
corto alcance.
3 Planteamiento del problema
3.1. Definicion del problema
Las redes de comunicacion inalambricas de corto alcance han evolucionado en torno a nece-
sidades particulares como la tasa de transmision, el numero de canales o nodos, la distancia
entre dispositivos, el ruido en el entorno o la autonomıa energetica. De este desarrollo han
surgido estandares que requieren la implementacion de un hardware especıfico que carece de
flexibilidad y escalabilidad ante variaciones de los requerimientos establecidos [1].
En aplicaciones tales como redes hospitalarias, domesticas, de seguridad, industriales o
agrıcolas, entre otras; la interoperabilidad entre protocolos, modificacion de topologıas o
variacion de nodos constituyen una necesidad en el mediano y largo plazo generando una
inversion significativa en tiempo y dinero para redisenar la red, de manera que se adecue a
las nuevas exigencias [3].
La radio definida por software se presenta como una solucion que permite la convergencia,
adaptabilidad y robustez para redes de comunicacion inalambrica de corto alcance acercan-
do el codigo lo maximo posible a la antena, convirtiendo ası un problema hardware en un
problema software. De esta manera modificaciones en la configuracion de la red o inclusion
de nodos direccionados por diferentes protocolos minimizaran los requerimientos de inter-
vencion hardware limitandose a la reconfiguracion de bloques funcionales [4].
En este contexto, el proyecto pretende aportar en la construccion de un dispositivo central
que sea capaz de comunicarse con sistemas que difieran en sus protocolos, caracterısticas o
aplicaciones. Se hace necesario establecer la idoneidad y limitaciones de los dispositivos SDR
disponibles para abstraer dicho comportamiento, caracterizando las necesidades tecnologicas
en la implementacion de diferentes protocolos.
6 3 Planteamiento del problema
3.2. Justificacion
Los sistemas basados en SDR son considerados la red de acceso a radio de la siguiente gene-
racion, transversal a todo tipo de sistemas de comunicaciones inalambricas. Su uso no esta
limitado al extremo final del radio sino a la operacion de la red en general. Los avances en
SDR han permitido nuevas aplicaciones consideradas irrealizables solo una decada atras [ [5]].
Las redes inalambricas de corto alcance requieren la interaccion de diferentes estandares de
comunicacion en un mismo entorno. Conceptos SDR estan siendo motivo de estudio en el
diseno de un sistema que permita la convergencia de dichos estandares. Un unico ente capaz
de interpretar la informacion provista por cada dispositivo vinculado a la red sin importar el
estandar en el que transmita [4]. En este contexto el desarrollo propuesto se presenta como
un aporte a este campo de estudio, en el marco de la lınea de investigacion en tecnologıas
SDR impulsada por el grupo de investigacion GRECO, de la cual se encuentra como princi-
pal antecedente y punto de partida a [2].
El uso de tecnologıas SDR provee a un sistema de comunicaciones inalambrico ventajas como
la flexibilidad del diseno, confiablidad, estabilidad de parametros, capacidad de actualiza-
cion, reusabilidad, capacidad de reconfiguracion, mejoras en la funcionalidad y reduccion
en costos, causadas por la digitalizacion de los elementos de radio. Resumiendose esto en
robustez para el sistema ante variaciones en el entorno o en sı mismo.
SDR representa un sinfın de retos causando una lenta evolucion en comparacion a como
habıa sido previsto [6]. Trabajos que aporten al estado del arte permitiran la aceleracion del
desarrollo del area, contribuyendo a la convergencia de dicha tecnologıa. Como resultado de
esto, se veran disminuidos los costos de produccion relacionados, generando la comercializa-
cion social de dicho conocimiento. En [7] se presenta un estudio que expone la urgencia en la
inclusion de SDR en la lınea de aprendizaje e investigacion en ingenierıas afines a electronica
y sistemas.
4 Alcances y limitaciones
4.1. Alcances
En el desarrollo del proyecto presentado se pretende realizar un aporte en la construccion
de sistemas transparentes al protocolo de comunicacion utilizado, basados en el paradigma
de radio definida por software. Se Presenta como una base de conocimiento para futuras
investigaciones.
El proyecto pretende unificar los avances previos en el marco del proyecto de investigacion y
los propuestos en el documento por medio de un dispositivo con funcionalidades de concen-
trador. Dicho dispositivo debera permitir una comunicacion en cualquiera de los dos sentidos
entre el y nodos configurados con los dos protocolos de estudio. Para validar las capacidades
de reconfiguracion, baluarte del paradigma de radio definida por software, se debe proveera
la posibilidad de variar parametros en tiempo real, caracterısticos de los sistemas involucra-
dos.
Las funcionalidades que puedan llegar a ser agregadas a los protocolos para poderlos im-
plementar en un mismo flujo de maquina seran tomados como valor agregado al proyecto,
teniendo en cuenta que el mismo se limita a la construccion del dispositivo concentrador.
4.2. Limitaciones
Desde su fundamentacion misma, el trabajo es concebido como un proyecto de investigacion,
por lo cual el enfoque principal tiene mayor proyeccion en aportar al estado del arte de
dispositivos unificadores en radio definida por software que en desarrollar un modulo de co-
municaciones. Por tal razon la implementacion del mismo tendra unicamente como objetivo
la comprobacion del diseno realizado y de ninguna manera supondra en sı misma un estudio.
5 Marco de referencia
5.1. Radio definida por software
5.1.1. Concepto de Radio definida por software
El termino “software radio” (SR) fue acunado por primera vez en 1991 por J. Mitola, alu-
diendo a un radio con capacidades de reconfiguracion [1]. El SR ideal propone el control
completo por software de un sistema, de tal manera que la unica conversion de digital a
analogo que se presente sea en la antena, lo cual, debido a limitaciones tecnologicas aun es
imposible de implementar.
Figura 5-1: Estructura en bloques de un modulo SDR
Radio definida por software (SDR) es la version pragmatica del ideal SR. La definicion
de mayor aceptacion establecida por el grupo IEEE P1900.1 ubica a SDR como un radio
en el cual alguna o todas las funciones de la capa fısica son definidas por software. La
arquitectura canonica de un sistema SDR consiste de tres etapas diferenciables, seccion de
radio frecuencia (RF), seccion de frecuencia intermedia (IF) y seccion de banda base. La
primera es responsable de la transmision y recepcion de las senales hacia y desde la antena.
En el caso de transmision debe amplificar y modular las senales provenientes de la etapa de
IF y en recepcion debe transportar la senal a frecuencia intermedia. En la etapa de IF se
realiza el procesamiento digital de la senal segun se requiera [8]. En la figura 1 se expone un
diagrama de bloques para este proceso.
5.1.2. Ventajas de SDR
SDR tiene un atractivo especial dentro del mercado comercial de comunicaciones por su
capacidad de proveer gran cantidad de variantes en multiples dominios. Esto es factible,
5.1 Radio definida por software 9
principalmente, debido a la habilidad de adaptacion mediante software sobre cualquier pla-
taforma de hardware [9]. Sus principales ventajas suponen:
Portabilidad: Capacidad de trasladar un sistema de una plataforma a otra con varia-
ciones mınimas o no existentes en sus componentes, sin que esto signifique reescribir la
aplicacion entera. Uno de los retos en cuestiones de portabilidad es la compatibilidad
entre lenguajes de programacion o descripcion de circuitos.
Reconfigurabilidad: Esta caracterıstica se relaciona con la portabilidad, pero en un sen-
tido estricto hace referencia a la capacidad para modificar la configuracion del sistema
dinamicamente, es decir, variar parametros directores del comportamiento del sistema
en tiempo real sin que el usuario final pueda percatarse de esto.
Seamless Mobility: Anglicismo que denota integracion total o perfecta. El equivalente
de esta caracterıstica en ingenierıa de radio tradicional es el enfoque de multiples
transceptores analogicos, en el cual, varios transmisores y receptores comparten parte
de la circuiterıa. Concepto inmerso en la arquitectura de SDR como se mostro en la
figura 1.
Interoperabilidad: La interoperabilidad siempre ha sido un reto en la ingenierıa de
comunicaciones. Se refiere a una plataforma que es capaz de soportar las diferentes
arquitecturas y estandares de radio, permitiendo una comunicacion autonoma entre
ellos.
Escalabilidad: Se refiere a la capacidad de actualizacion. Debido al reemplazo de dispo-
sitivos hardware por software, ante variaciones en las necesidades del sistema o actua-
lizaciones tecnologicas se encuentran reducciones significativas en tiempos y costos de
implementacion. De esta manera donde antes era necesario reemplazar un componente
ahora con SDR solo se requiere actualizar el bloque funcional por software.
Reusabilidad: Los bloques funcionales de comunicacion construidos en el diseno de una
determinada arquitectura pueden ser facilmente reutilizados con el fin de desarrollar
nuevos dispositivos. Ventaja intrınseca en implementaciones software.
5.1.3. Retos de SDR
Por otro lado, hay numerosos retos que necesitan ser abordados en el proceso de aportar a la
viabilidad integral de proyectos sobre SDR. Dentro de los principales, que son propiamente
objeto de estudio en la actualidad, se destacan:
Diseno de plataformas SDR: La curva de aprendizaje de las interfaces de desarrollo
y el mecanismo propio de diseno en SDR es considerablemente lenta. Esta inmersion
10 5 Marco de referencia
en tematicas SDR puede tomar un tiempo de magnitud desmedida en comparacion a
lo requerido para un diseno sobre hardware. A esto se agrega, la poca documentacion
que se encuentra disponible para software de desarrollo como el caso de GNU RADIO
u OSSIE, y, lo tedioso de su interfaces. En este sentido, disenar es el reto que mayor
limitacion ha opuesto al desarrollo de la radio definida por software. Los proyectos
de investigacion que han abierto la brecha en SDR se han enfocado principalmente
en migrar tecnologıas de radio convencional a bloques funcionales implementados por
software, lo cual es tambien el enfoque del proyecto presentado en este documento.
Capacidad computacional: Se debe buscar procesar una aplicacion de multiples blo-
ques de comunicacion con un uso razonable de recursos computacionales. La mala
administracion de dichos recursos afecta directamente el paralelismo, en terminos de
la cantidad de aplicaciones que es posible implementar sobre una misma plataforma, a
la autonomıa energetica, provocando incluso incomodidades de sobrecalentamiento en
el usuario final, y, al presupuesto de adquisicion para modulos de desarrollo SDR.
5.1.4. Antecedentes y surgimiento
SDR aparece como solucion tecnologica a necesidades militares estadounidenses. En 1991
se presenta DARPA’s SPEAKeasy [10]. Consistıa en un radio que implementaba los com-
ponentes de su capa fısica en software con el objetivo de soportar diez diferentes protoco-
los de comunicacion militares. En su momento fue considerado como una aproximacion al
computador del mundo de la radio pero no serıa conocido como radio por software hasta
1992 cuando Joseph Mitola publica en IEEE National Telesystems Conference un artıculo
titulado “Software Radio: Survey, Critical Analysis and Future Directions”. Mas tarde en
1996 se crea la primera asociacion de industrias dedicadas al desarrollo de SDR nombra-
da “The Modular Multifunction Information Transfer System (MMITS) Forum.”, quien se
convertirıa en SDR Forum en 1998 y posteriormente the Wireless Innovation Forum en 2010.
En 1997 se da inicio al programa Joint Tactical Radio System (JTRS) creado por el depar-
tamento de defensa de Estados Unidos con el objetivo de incrementar la interoperabilidad y
portabilidad en sistemas de radiocomunicaciones a traves de la definicion y estandarizacion
de la abstraccion de capas e interfaces por software, conocida como la Software Communi-
cation Architecture (SCA). Fue cancelado en 2001 debido a las dificultades generadas en el
progreso. Sin embargo impulso considerablemente el desarrollo en el area por mas de una
decada siendo el punto de partida del programa European Secure Software Defined Radio
(ESSOR) de la union europea.
En el cambio de siglo surgen avances como la creacion de la primera interfaz para generar
archivos de configuracion para DSPs de Texas Instruments y FPGAs de Xilinx, y, el naci-
miento de GNU-RADIO, software libre para desarrollo de sistemas SDR. Pero serıa posible
5.1 Radio definida por software 11
solo hasta 2004 promover comercialmente a SDR.
En 2006 TI y Xilinx unen fuerzas para crear la primera plataforma unificada para el desa-
rrollo de SDR que serıa la base para la construccion del Universal Software Radio Peripheral
(USRP) por parte de GNU RADIO [11].
Llegados a este punto se han reunido las necesidades basicas (Ente regulador y unificador,
e, interfaz y plataforma de desarrollo integradas) para impulsar un desarrollo adecuado de
sistemas SDR.
5.1.5. Ambito de aplicaciones para tecnologıas SDR
La manipulacion de dispositivos SDR desde un ordenador permite explorar un sinfın de so-
luciones a todo tipo de planteamientos. Las clasicas aplicaciones de SDR giran en torno al
concepto de plataforma unificadora y resolucion de problemas de redes en tiempo real. Sin
embargo, SDR esta siendo abordado desde multiples campos de accion. A continuacion se
nombran algunas de las aplicaciones mas relevantes y significativas en la ultima decada.
Debido a la creciente demanda del espectro electromagnetico se ha hecho necesario investigar
en tecnologıas que permitan evitar una subutilizacion y por ende saturacion del recurso na-
tural. Radio cognitiva es el paradigma directamente involucrado en los desarrollos en torno
al acceso dinamico al espectro. Por medio de estas redes se pretende sensar el medio para
transmitir informacion por bandas que no estan siendo utilizadas [12].
La Reconfigurabilidad es uno de los principales aspectos de SDR que estan acelerando su
inclusion en los ambientes de vida asistidos. En este contexto se pretende por medio de una
arquitectura definida por software tener control de las dos tecnologıas de comunicacion pre-
dominantes, ZigBee y Z-Wave de tal manera que se facilite la comunicacion con los multiples
nodos de sensado disponibles. Ademas de facilitar el proceso de mantenimiento y actualiza-
cion [13].
La reciente necesidad de interconectar todos los dispositivos posibles a una misma red se
ha plasmado en el concepto “internet of things” (IoT), que hace referencia a la conexion de
objetos fısicos compuestos por hardware digital, software o sensores a internet. Su desarrollo
pragmatico se ha ligado ıntimamente a plataformas SDR por la necesidad de soportar dife-
rentes protocolos de comunicacion estandarizados y no estandarizados, permitiendo remover
los recolectores de datos de cada nodo, realizar unaadministracion remota y automatizar el
flujo de informacion entre dispositivos. Estas arquitecturas son denominadas IoT SDR. La
importancia de SDR recae en proveer un escenario multi estandar anadiendo ventajas como
el hecho de ser compatible con el concepto “Over the air programming”, el cual supone que
12 5 Marco de referencia
cualquier actualizacion puede ser lograda enviandola inalambricamente al dispositivo. De
esta manera una implementacion ideal de IoT no es viable sin la presencia de SDR [14].
No se debe perder de vista que la radio definida por software es un concepto de gran atractivo
para la comunidad academica (docencia en investigacion) debido a la diversidad de aplicacio-
nes que se pueden desarrollar en diferentes campos. Es tambien una tecnologıa que involucra
conceptos en el area de telecomunicaciones, comunicaciones digitales, programacion, procesa-
miento digital de senales, telematica y uso de herramientas libres como las basadas en Linux.
Por tal motivo, trabajar con estos sistemas brinda la posibilidad de reforzar muchas de las
tematicas que se dictan en las aulas universitarias. Su utilizacion dentro de la academia, es
sin duda, una oportunidad para estudiantes y profesores de llevar a la practica los conceptos
teoricos vistos en clase.
Adicionalmente, es posible encontrar a SDR inmerso en proyectos tales como comunicacion
entre vehıculos [15], recepcion de senales GPS [16], mediciones para el movimiento de sateli-
tes [17] o comunicacion inalambrica 5G [18].
5.2. Sistemas de inferencia difusa
5.2.1. Concepto de un sistema de inferencia difusa
Un sistema de inferencia difusa (FIS, por sus siglas en ingles), o sistema experto, es un
metodo aplicado para la interpretacion de valoraciones subjetivas a partir de declaraciones
Si-Entonces, abstraıdas del conocimiento de uno o varios sujetos que tienen una amplia ex-
periencia en un tema determinado y por tanto son considerados expertos. Esto tambien es
posible realizarlo a partir de reglas encontradas por diferentes metodos de reconocimiento
de patrones como la computacion evolutiva [19]. Un sistema difuso esta compuesto por: un
fusificador para los datos de entrada, una base de reglas, un motor de inferencia difusa, y
un defusificador para los datos de salida. La estructura de este tipo de sistemas difusos se
encuentra en la figura 5.
Figura 5-2: Estructura de un sistema de inferencia difusa
La informacion proveniente de las bases de datos para ingresar al sistema difuso es pun-
5.2 Sistemas de inferencia difusa 13
tual. Por lo tanto, se requiere el fusificador para convertirlas en funciones de pertenencia
que puedan interactuar con las funciones de pertenencia de las reglas difusas. Ayudando
a simplificar la computacion en el motor de inferencia. El fusificador tiene como objetivo
colaborar a la reduccion de ruido teniendo presente una incertidumbre en la toma de datos.
Las reglas difusas toman el papel del conocimiento linguıstico de los expertos transformado
en funciones de pertenencia. Estas reglas relacionan las variables de entradas por medio de
las declaraciones (Si-Entonces) ya predeterminadas, y el encargado de relacionar y combinar
las reglas de la manera adecuada serıa el motor de inferencia difusa. Este motor de inferen-
cia obtiene un mapeo sobre la interaccion de los conjuntos difusos de entrada y salida. Por
ultimo, se obtiene un sistema difuso de salida que debe ser interpretado como una salida
puntual. Para esto se introduce el concepto de defisuficacion que lleva a cabo el proceso
inverso al fusificador y de una salida difusa obtiene un dato puntual [20].
5.2.2. Ventajas de la logica difusa
Como se ha mencionado anteriormente, es recomendable usar los sistemas difusos en aquellos
problemas muy complejos donde no existe un modelo matematico simple asociado o, en
procesos que obedecen a un comportamiento no lineal. En la figura 5-3 se expone la diferencia
entre un sistema difuso y un sistema clasico. Ese grado de pertenencia que se le puede atribuir
a un elemento, es el constituyente primario de dicha logica. La solucion difusa require que el
conocimiento experto sea expresado linguısticamente, requisito que es normalmente facil de
obtener. Ademas, la solucion difusa plantea grandes ventajas. A continuacion se enumeran
algunas de las mas relevantes.
Conjuntos difusos: En la caracterizacion de sistemas, muchas veces se requiere que para
una misma entrada haya diferentes salidas, dependiendo de condiciones particulares.
Los conjuntos difusos permiten asignarle a los elementos un grado de membresıa, de
tal manera que un elemento puede pertenecer parcialmente a uno o mas conjuntos.
El razonamiento aproximado: Cualquier sistema logico puede ser representado por
medio de un sistema difuso. Mediante logica difusa se puede formular el conocimiento
humano de una forma sistematica, y puede ser facilmente incluido en sistemas de
ingenierıa. De esta manera, no es necesario desgastar en abstraer un modelo matematico
preciso, sino es suficiente, con tener el conocimiento de la dinamica del fenomeno y
representarlo por medio de reglas si-entonces.
Modelo del fenomeno: El conocimiento se interpreta como una coleccion de restriccio-
nes difusas sobre una coleccion de variables. Los sistemas difusos son especialmente
interesantes para la definicion de sistemas cuyo modelo exacto es difıcil de obtener (es
necesario introducir una aproximacion).
14 5 Marco de referencia
Decisiones a partir de informacion incierta: Se utiliza ampliamente en sistemas de
ayuda a la decision. La logica difusa permite obtener decisiones con valores incompletos
o informacion incierta. Ası, especialmente en sistemas que se construyen a partir de la
tabulacion de parametros de entrada y salida que tienen un error inherente, es posible
generar un sistema que tenga presente ese error en sus decisiones.
Figura 5-3: Representacion de los conjuntos difusos
5.2.3. Optimizacion por medio de computacion evolutiva
La computacion evolutiva es una rama de la inteligencia artificial que involucra problemas
de optimizacion combinatoria. Se inspira en los mecanismos de la evolucion biologica. La
inteligencia computacional ha tomado a la evolucion natural como inspiracion para la crea-
cion de nuevos algoritmos que impliquen metodos innovadores para problemas complejos
donde se busque una optimizacion poblacional [21]. Estos algoritmos simulan la respuesta de
individuos de una poblacion a un ambiente donde el comportamiento mas apropiado para
el ambiente sera el seleccionado para las siguientes generaciones. Este comportamiento no
es pasado a generaciones intacto sino que tambien entra en juego una mutacion aleatoria,
similar a la reproduccion en la naturaleza. La evolucion optimiza los comportamientos de la
poblacion, donde la poblacion se representa como las posibles soluciones que puede tener el
problema [22].
La computacion evolutiva, a traves de sus diferentes exponentes, procura seguir un conjunto
general de premisas. A continuacion se nombran las principales.
Inicializacion de la poblacion: La poblacion debe incializarse para comenzar el proceso
de evolucion. Esta poblacion puede ser inicializada aleatoria o determinısticamente. En
caso de ser deterministica puede ser a traves de un algoritmo especializado, heurıstica
o metaheurıstica.
Evaluacion de los individuos: Se debe analizar el desempeno de cada solucion al pro-
blema (Individuo de la poblacion) por medio de funciones objetivo. Esta funcion se
denomina funcion fitness y se construye a partir de diferentes estadısticos.
5.3 Herramientas de desarrollo 15
Recombinacion: Dos soluciones escogidas al azar se recombinan para crear una nueva
generacion de soluciones que sera evaluada en la siguiente iteracion. Hay multiples
maneras de realizar esta combinacion. La efectividad de una u otra depende de las
caracterısticas del problema y del genoma construido.
Mutaciones: Esta nueva generacion puede tener mutaciones, manteniendo una diver-
sidad en la poblacion para favorecer el proceso de busqueda, a traves de una mayor
exploracion poblacional. Las mutaciones consisten en cambiar pequenas partes del ge-
noma de algunos individuos. La mutacion en la poblacion es determinada por una
probabilidad asignada al inicio del proceso.
Seleccion de la siguiente generacion: Al final de cada generacion se deben seleccionar,
los individuos que conformaran la siguiente poblacion. Para esto, existen dos princi-
pales variantes: la ruleta y el elitismo. En la ruleta, a partir de los resultados de cada
individuo en la funcion fitness, se le asigna una probabilidad de aparecer en la siguiente
generacion. De esta manera, el mejor individuo tendra una probabilidad mayor que el
peor, pero aun ası, el peor podra aparecer en la siguiente generacion. Por otro lado, el
elitismo, hace que solo los mejores individuos puedan pasar a la siguiente generacion.
A partir de los individuos seleccionados, con cualquiera de las dos variantes, se genera
una nueva poblacion por medio de cruce.
5.3. Herramientas de desarrollo
5.3.1. GNU Radio Companion 3.7
GNU Radio Companion (GRC), mejor conocido como GNU Radio, es una interfaz de desa-
rrollo de software libre y codigo abierto (GNU General Public License - GPL) que propor-
ciona bloques de procesamiento de senal para implementar radios definidos por software.
Es ampliamente utilizado por la academia e industria para apoyar la investigacion en el
campo de las comunicaciones inalambricas [23]. Los disenos se realizan a partir de la cons-
truccion de flujogramas compuestos por bloques funcionales que se encuentran programados
en python 2.7 o C++, y, descritos en lenguaje xml. En muchos casos puede ocurrir que un
mismo bloque integre los dos lenguajes, siendo esto es posible gracias a la librerıa Swig. El
ejecutable es un archivo de python, que genera la herramienta a partir del flujograma, donde
se define la dinamica para lanzar las funciones de cada uno de los bloques y sus interacciones.
GNU Radio representa una revolucion en el procesamiento digital, no solo por la conver-
gencia de los dos lenguajes de programacion mas populares, sino por el tratamiento que
recibe la senal dentro del flujograma. Sus mayores beneficios son el paralelismo, dado que
cada bloque representa un hilo de procesamiento, los buffers circulares, puesto que facilita
el proceso de lectura y escritura, la implementancion de los tipos de dato polimorficos, que
16 5 Marco de referencia
se presentan como un tipo de contenedor donde pueden viajar diferentes tipos de datos y
etiquetas, y, el flujo de datos entre los bloques, que no se efectua con muestras individuales
sino con grupos de estas [24]. Sin embargo, dado que es una plataforma libre y abierta, y,
que su desarrollo proviene de los aportes de la comunidad, su soporte y documentacion se
encuentran ampliamente limitados, por lo que, para usuarios iniciales, la curva de aprendi-
zaje se torna excesivamente lenta, suponiendo una inversion de tiempo muy distante a la
implementada para introducirse en herramientas de desarrollo similares.
Expuesto lo anterior, GNU Radio es la plataforma escogida para desarrollar el gateway pues-
to que los transceptores que se usan como base, se encuentran disenados allı, por otro lado,
si esta pre-condicion no se presentase, de igual manera serıa la mejor opcion para realizar
la implementacion. Sin embargo, el estudio e inmersion en GNU Radio debe ser una ta-
rea a la que se le reconozca la importancia adecuada, de tal manera que los tiempos de
aprendizaje no interfieran con los de desarrollo. Posterior a esa inmersion, para el diseno de
bloques funcionales, se presentan tutoriales interesantes, aunque meramente introductorios,
para python [25] y C++ [26]. El procedimiento sugerido para la instalacion, es depurar un
Script en el que se ejecutan las instrucciones para instalar todos los requerimientos necesa-
rios para lanzar la interfaz de GNU Radio e implementaciones sobre plataformas hardware.
Instrucciones detalladas estan disponibles en [27].
5.3.2. Plataforma hardware para desarrollo de radios definidos por
software
Las implementaciones en radio definida por software requieren de hardware especializado. En
el desarrollo descrito en el documento se utilizan dispositivos de Ettus Research, division de
National Instruments, comercialmente distribuidos como USRP (Universal Software Radio
Peripheral). El gateway es construido sobre la version N210 y, uno de los nodos, sobre B210,
Figura 5-4.
Figura 5-4: Plataformas de desarrollo USRP N210 y B210.
5.3 Herramientas de desarrollo 17
El funcionamiento general de la USRP, mantiene el modelo descrito en el diagrama de la pri-
mera seccion del capıtulo, figura 5-1. A continuacion se describen particularidades, a partir
del diagrama, de los modulos de desarrollo, en cada una de las etapas. Una revision de las
principales caracterısticas de los dos dispositivos es expuesta en la tabla 5-1.
La seccion de radio frecuencia, esta conformada por la antena y el modulo RF Front-end.
Las antenas deben ser adquiridas por separado, al igual que los conectores SMA. En el caso
de la USRP B210 se encuentran 4 puertos disponibles y en la N210, 2. El modulo RF Front-
end denaminado Daugther Board, esta compuesto por un filtro para reducir el ruido y una
etapa de amplificacion de la potencia de la senal. Se encarga de transportar la senal, de su
frecuencia original a una frecuencia intermedia, asociada al ancho de banda de la USRP. En
el caso de la USRP B210, se encuentran 2 RF Front-end incluidos en el dispositivo, mientras
que en la USRP N210, el modulo es un accesorio y debe ser adquirido por separado, lo cual
representa un incremento en costo pero la ventaja de adaptarse a las necesidades de desa-
rrollo, ademas, en la construccion del modulo sobre la misma placa del resto de la tarjeta de
la USRP B210, se tiene como consecuencia la insercion de niveles de ruido e interferencia no
deseados.
La seccion de IF o frecuencia intermedia, esta compuesta por dos grupos de bloques, uno pa-
ra recepcion (ADC y DDC ) y otro para transmision (DAC y DUC ).En recepcion el modulo
ADC se encarga de digitalizar la senal analoga, a partir de la cantidad de bits y la tasa
maxima de muestreo del dispositivo. Notese que para la USRP B210, la tasa de muestreo
disminuye si se utilizan los dos RF Front-end. La senal digitalizada pasa por los bloques
DDC (Conversion Digital hacia abajo), donde la senal es transportada a banda base, para
permitir su procesamiento. El proceso inverso es ejecutado para transmision.
Finalmente, se ejecuta la etapa de procesamiento en banda base. Este proceso se puede
realizar en una FPGA, en un DSP o en un equipo de computo, segun la configuracion y
limitaciones del dispositivo. En el caso de las implementaciones propuestas en el libro, el
procesamiento se lleva a cabo en un equipo de computo, a partir de la capacidad de la USRP
para generar comunicacion desde y hacia la tarjeta, por medio de un firmware, denominado
UHD, encargado de establecer la configuracion de la FPGA para direccionar el flujo de datos
entre los modulos ADC, DDC, DAC y DUC, hacia la interfaz disponible, en este caso USB3.0
o Gigabit Ethernet. De esta manera, el procesamiento se ejecuta en el equipo de computo y la
FPGA solo se encarga de conectar caminos. Es importante mencionar que si el procesamiento
se ejecutara en la FPGA, se aumentan los recursos para procesamiento, dado que es posible
alcanzar mayores frecuencias de muestreo y ejecutar tareas en paralelo. Esta opcion requiere
conocimientos avanzados en lenguajes como VHDL, ademas, se debe modificar el firmware
base de la FPGA. Por esta razon la mayorıa de implementaciones sobre USRP se realizan
con procesamiento desde equipos de computo.
18 5 Marco de referencia
Tabla 5-1: Caracterısticas principales de las plataformas de desarrollo USRP B210 y N210
CaracterısticaPlataforma de desarrollo
USRP B210 [28] USRP N210 [29]
Ancho de banda [MHz] 56 (1x1) o 30.72 (2x2) 50
Frecuencia de operacion [MHz] 70 - 6000 0-6000
Interfaz USB 3.0 Gbit Ethernet
MIMO (Half o Full Duplex) 2 Rx - 2 Tx 1 Rx - 1 Tx
FPGA Spartan 6 XC6SLX150 Spartan 3A-DSP 3400
Power Supply USB/External External
Max. f. de muestreo en ADC [MS/s] 61.44 100
Resolucion del ADC [bits] 12 14
Max. f. de muestreo en DAC [MS/s] 61.44 400
Resolucion del DAC [bits] 12 16
6 Estado del arte
6.1. Radio definida por software
6.1.1. Trabajos relacionados
La definicion por software de protocolos de comunicacion en redes inalambricas de corto
alcance es prioridad actualmente en el campo de estudio de SDR en el marco de la construc-
cion de sistemas transparentes. La interfaz de desarrollo dominante es sin duda alguna GNU
RADIO y aunque existen implementaciones independientes, la plataforma de desarrollo que
se posiciona como predilecta es la USRP, especialmente en trabajos de investigacion. A con-
tinuacion se exponen brevemente los avances mas significativos, afines al proyecto propuesto
en el presente documento.
Dominic Spill y Michael Ossmann implementan parte de la capa fısica de bluetooth sobre
GNU RADIO v.3.7. Este proyecto se limita a ser un experimento para fines demostrativos
dentro de la academia pero nunca llega a ser funcional.
A partir de estos trabajos, ha aparecido el desarrollo de multiples trabajos de grado de
posgrado y maestrıa en diferentes lugares del mundo. En el Instituto de tecnologıas de
comunicacion de Ulm en Alemania [30], se utiliza el software OpenBTS para disponer de
una BTS (Base Transceiver Station) de telefonıa celular operando en la tarjeta de desarrollo
USRP1 y USRP2 en las bandas GSM de 800/900 MHz y 1800/1900 MHz. Con el objeto de
utilizar una sola antena y de disponer de una conexion con un analizador de espectro externo
que permita monitorear la frecuencia de la senal de salida del dispositivo USRP, se disena
un circulador en RF que se integra con la tarjeta de desarrollo.
6.2. IEEE 802.11 en GnuRadio
En el ano 2009, Marwanto [31] dirigio un proyecto que buscaba implementar un sistema
OFDM a partir del software GNURadio y la plataforma de desarrollo USRP. El sistema
OFDM en [31] estaba constituido por dos USRP. La distancia entre los dos dispositivos en la
implementacion del sistema era de 66 cm en un ambiente cerrado, trabajando a una frecuen-
cia central de 2.5 GHz y con esquemas de modulacion BPSK y QPSK (Quaternary Phase
20 6 Estado del arte
Shift Keying) con 256 y 512 portadoras. El objetivo del sistema fue determinar la relacion en-
tre la tasa de paquetes recibidos o PRR (Packet Received Ratio) y la potencia de transmision.
Un ano mas tarde, Gutierrez Agullo [32] implemento el stack correspondiente a la subcapa
MAC (MediaAccess Control) del estandar IEEE 802.11 en lenguaje python para ser usada
bajo la plataforma USRP. Las funciones de la capa de control de acceso al medio fueron
implementadas en base a una maquina de estados. Este sistema era capaz de producir los
mensajes de transmision de la subcapa de control de acceso al medio, tales como, RTS (Re-
quest to Send), CTS (Clear to Send), ACK (Acknowledgement) y beacons. En cuanto a la
parte de recepcion, la capa MAC fue desarrollada de igual forma, aunque el enlace inalambri-
co no fue puesto a prueba debido a que no se tenıa desarrollada la capa PHY en la recepcion.
Actualmente, la universidad de Paderborn, Alemania, y Trento, Italia, han desarrollado con-
juntamente el proyecto WiME (experimentacion y medicion en redes inalambricas basadas
en SDR), dirigido por el profesor Falko Dressler. La principal lınea de investigacion, a cargo
de Bastian Bloessl, gira en torno a la implementacion del estandar IEEE 802.11a/g/p en
GNU RADIO v.3.7 y USRP. En primera instancia construyeron un receptor por medio de
la implementacion de la capa fısica del estandar. Posteriormente se mejora hacia el diseno
de un transceptor y se producen avances en la implementacion del stack. En este punto son
capaces de enviar y recibir datos a partir de una tarjeta Ettus USRP N210. Con estas bases
asentadas les fue posible estudiar factores como el acceso al canal, robustez en la capa fısica
para proveer seguridad, control de potencia en la antena y aplicar algunos de estos progresos
a redes inalambricas vehiculares [33], [34] y [35].
6.3. IEEE 802.15.4 en GnuRadio
Zigbee, otro de los protocolos con mayor campo de aplicacion en SDR, fue abordado por
primera vez por Thomas Schmid, investigador asociado de la UCLA, quien implemento la
capa fısica del estandar 802.15.4 en una tarjeta USRP2 sobre GNU RADIO. . El trabajo se
realizo de manera que pudiera comunicar una estacion central con GNURadio v3.6 con los
nodos Telos B mote que utilizan el radio de Texas Instruments CC2420 que implementa capa
fısica y capa de enlace. Este desarrollo inicial sirvio de referencia a muchos otros trabajos
que buscaban mejorar los resultados obtenidos o extender el desarrollo a otros esquemas de
comunicaciones.
Posteriormente, en la Universidad de Innsbruck, Austria, se han actualizado las librerıas del
esquema 802.15.4 a la version de GNURadio 3.7 y han mejorado el aspecto grafico en la pro-
gramacion, de manera que tienen bloques funcionales para las capas fısicas O-QPSK PHY
y CSS PHY y para la capa de enlace 802.15.4. Cada bloque implementa las funcionalidades
de transmision y recepcion. Adicionalmente la informacion se puede almacenar en formato
6.4 Sistemas de inferencia difusa en SDR 21
PCAP para poder analizarse desde la aplicacion Wireshark [36]. El trabajo desarrollado al
igual que el de Tomas Schmit, es compatible con los nodos Telos B mote, los cuales fueron
programados a partir del sistema operativo Contiki que es compatible con los microcontro-
ladores MSP430 de los dispositivos. Hay que senalar que uno de los autores B. Bloessl, es el
encarcado de administrar la librerıa gr-ieee802.15.4 para GNU Radio, y es un usuario muy
activo en los foros de soporte.
En el Instituto Politecnico de Virginia, en Estados Unidos [37], se realiza una compara-
cion entre la implementacion de la capa fısica de 802.15.4 en la FPGA Spartan3-A de la
USRPN210 y un receptor multicanal 802.15.4 en una FPGA externa Virtex 5. Para este
trabajo, se utilizaron herramientas como GNU Radio, Matlab, y Xilinx ISE, de manera que
fue posible comprobar la cantidad de recursos que se utilizaban en la FPGA al programar
la tarjeta con Xlinx ISE y con GNURadio, siendo mucho mas eficiente la primera de estas.
Finalmente, fue abordado Por Miguel Sastoque y Claudia Segura en su trabajo de grado [2].
En su desarrollo, se organizaron en bloques funcionales para GNURadio, a partir del modelo
de capas OSI, las capas fısica, de enlace y de red de IEEE802.15.4. Ademas, se adapto la
trama producida por el transceptor para poder establecer comunicacion bidireccional con el
modulo xbee S2, lo cual supuso un reto tecnico mas alla de un reto conceptual.
6.4. Sistemas de inferencia difusa en SDR
Los sistemas de inferencia difusa han sido de gran utilidad en campos del conocimiento en
los que la logica puntual limita la construccion de modelos matematicos precisos. Su ma-
yor aplicacion se enmarca en soluciones a problemas del campo de la ingenierıa. Es posible
encontrar un sin numero de trabajos que aplican dicha logica como un metodo alternativo
de analisis. A continuacion se enuncian algunos referentes a radio definida por software y el
protocolo IEEE 802.11 .
Nikhil Marriwala propone un ecualizador difuso aplicado en radio definida por software. Por
medio de este se presento una solucion al problema de la interferencia inter-simbolica. Se to-
ma ventaja de la reconfiguracion que permite SDR para cambiar parametros en la recepcion
a partir de reglas difusas. En este problema especificamente, es muy difıcil establecer equi-
valencias lineales entre los parametros de un filtro adaptativo y las condiciones del entorno.
Es por esto que un sistema de inferencia difusa fue la mejor opcion [38].
Vijaya Kumar, realizo un estudio experimental a partir de algoritmos geneticos en la adap-
tacion de enlaces para aplicaciones de radio cognitiva. Para realizar la adaptacion del enlace
se sensa el espectro electromagnetico creando una base de conocimiento para decidir en que
frecuencia y con que potencia se debe operar. Los algoritmos geneticos fueron usados para
22 6 Estado del arte
establecer un sistema difuso que representara estas relaciones no lineales [39].
7 Analisis de protocolos
En el cronograma de actividades para el presente proyecto, se propone ejecutar una revision
de los principales estandares de comunicacion inalambrica de corto alcance, estudiados pre-
viamente a traves de conceptos de radio definida por software. En esta seccion se exponen los
tres protocolos mas relevantes en dicho estudio y el analisis ejecutado para el seleccionado,
haciendo enfasis en las particularidades del stack y del protocolo, implementaciones exis-
tentes, limitaciones y oportunidades de desarrollo. Dichos protocolos estan inmersos en los
grupos de trabajo IEEE que se organizan de acuerdo a caracterısticas de cobertura, ancho
de banda y funcionalidades especıficas de las redes de comunicaciones, haciendo un recorrido
desde las Redes de area personal (WPAN), pasando por las redes locales (WLAN) y las de
area ancha (WWAN) hasta las regionales (WRAN), como se muestra en la Figura 7-1. Este
estudio solamente incluye los protocolos que abarcan hasta WLAN, enmarcados dentro de
las redes inalambricas de corto alcance.
Figura 7-1: Esquema organizacional de las redes inalambricas segun su cobertura
Adicionalmente, se presentan los bloques funcionales y generalidades en GNURadio, ası
como la correspondiente configuracion a partir de Ubuntu 16.04, en los dos protocolos que
seran abordados por el documento. Uno correspondiente al desarrollo previo [2], y, otro
correspondiente a la implementacion a presentar.
24 7 Analisis de protocolos
7.1. Determinacion del estandar inalambrico de corto
alcance
7.1.1. WirlessHART
WirelessHART es un estandar industrial, desarrollado para los requisitos especiales de la
comunicacion inalambrica en el nivel de campo de la industria de procesos. Fue concebido a
partir de un conjunto de requerimientos fundamentales: debıa ser simple (facil de usar y desa-
rrollar), auto-organizado, flexible (soportar diferentes aplicaciones), escalable (Capacidad de
uso en plantas grandes y pequenas), seguro y uno de los puntos mas importantes, soporte
y compatibilidad en configuracion, con el ya existente y predominante en el area, HART [40].
WirelessHART es un protocolo elaborado por el consorcio privado HART, por lo que de su
stack solo es posible conocer la configuracion de su capa fısica y algunas generalidades de
capas superiores, sin pagar la licencia. En la figura 7-2 se expone el protocolo a la luz del
modelo de capas OSI. Como es posible observar, en su capa fısica implementa las especifica-
ciones de IEEE 802.15.4 (Zigbee) pero para la capa de enlace introduce cambios con respecto
a esta. Ademas, no hay especificaciones para las capas de presentacion y sesion.
Figura 7-2: Stack del protocolo WirelessHART
A partir de la compatibilidad con Zigbee, dado que comparten la capa fısica, se puede hablar
de un desarrollo en GNURadio. Pero en las demas capas, no se ha introducido aun algun
bloque. En general, a la luz de GNURadio, todo lo que se puede considerar como un aporte a
WirelessHART es lo que se ha realizado en Zigbee, por lo que habrıa que introducir de ceros
lo correspondiente a las demas capas. La transparencia del protocolo facilitarıa un poco esta
7.1 Determinacion del estandar inalambrico de corto alcance 25
labor. Las tasas de transmision no son altas por lo que no abrıan retos computacionales.
La limitante en este caso se encuentra en el acceso a la informacion del protocolo. Debido
a su caracter privativo, hay muy poca investigacion en torno a este, por lo que el estado
del arte, especıfico en WirelessHART, serıa engorroso de establecer. Ademas, del costo que
se deberıa asumir para acceder a la pila del protocolo (US$100), se debe adquirir un par
de dispositivos que se comuniquen a traves de WirelessHART (alrededor de US$1200). Por
lo anterior, no se considera viable implementar WirelessHART como el segundo protocolo
del presente desarrollo, debido a la poca investigacion en sus implementaciones para radio
definida por software y los altos costos que este representa.
7.1.2. Bluetooth
Bluetooth es una tecnologıa para Redes Inalambricas de Area Personal (WPAN, por sus
siglas en ingles). Empieza a concebirse en Ericsson Mobile Communications AB (Suecia)
en 1994 como el efecto colateral de un proyecto sobre enlaces de comunicadores multiples
conectados a la red celular mediante telefonos. Posteriormente, aparece el grupo de interes
en la tecnologıa Bluetooth SIG (Special Interest Group) en el que actualmente se encuentran
mas de 200 empresas promotoras de la tecnologıa.
Bluetooth opera bajo la especificacion IEEE 802.15.1, donde se definen la capa fısica y la
capa de enlace. De igual manera cuenta con una pila que cubre las 5 capas restantes y es
abierta a la comunidad academica. Dentro de sus principales caracterısticas, en comparacion
a la tecnologıa Zigbee, se puede resaltar su tasa de transmision, que es aproximadamente el
triple de la de Zigbee, su consumo energetico y distancia de operacion, que son ampliamente
mayores a Zigbee y su operacion en la banda de los 2.4GHz. Por lo anterior, a diferencia de
WirelessHART, Bluetooth tiene un abanico de aplicaciones diferentes a las de Zigbee. Visto
desde este punto representa una opcion viable de integracion.
Ahora bien, en radio definida por software, como se menciono en el estado del arte, se pre-
sentan importantes avances en la implementacion de la capa fısica. Sin embargo, esta no es
del todo funcional y se presenta como un trabajo experimental, pensado para practicas de
laboratorio de formacion academica. Ademas, la plataforma USRP presenta serias limita-
ciones en la implementacion de la capa fısica, puesto que Bluetooth utiliza una tecnica de
modulacion basada en Espectro ensanchado con salto de frecuencia (FHHS, por sus siglas en
ingles) que consiste en modular la senal que se va a transmitir con una portadora que salta
de frecuencia en frecuencia, dentro del ancho de banda asignado, en funcion del tiempo. Ası
pues, la configuracion para el procesamiento debe ser cargada sobre la FPGA. Por lo que se
requerirıa disenar la configuracion de la FPGA, lo cual significa un reto de diseno elevado,
puesto que el conocimiento tecnico disponible para estas implementaciones es relativamente
poco y reciente.
26 7 Analisis de protocolos
A partir de lo expuesto anteriormente, y teniendo en cuenta que el objetivo es encontrar
un protocolo que, por lo menos, ya este disenado sobre GNURadio, se decide descartar la
opcion de Bluetooth.
7.1.3. WiFi
IEEE 802.11 representa una familia de estandares, diferenciados cada uno, por una letra en
minuscula, ası, se puede encontrar IEEE 802.11a/b/g/n/p, entre otros. A traves del docu-
mento se ha hablado de IEEE 802.11 como un unico protocolo para facilidad de nomenclatu-
ra, pero se debe tener en cuenta que representa todo un grupo. IEEE 802.11 se apoya en la
especificacion de la capa de acceso al medio comun a las tecnologıas LAN, es decir, al control
de enlace logico (LLC), incluyendo ademas la capa MAC y dos capas fısicas, una con la tecni-
ca de modulacion de salto en frecuencia (Frequency-Hopping Spread-Spectrum FHSS) y otra
con la de esparcimiento en secuencia directa (Direct-Sequence Spread-Spectrum DSSS). Esta
tecnologıa ha evolucionado con respecto a la necesidad de aumentar la tasa de transmision
y necesidades a aplicaciones especıficas, como el caso de 802.11p. La tabla 7-1 expone los
estandares de la familia que se encuentran disponibles para implementar sobre GNURadio.
Tabla 7-1: Principales caracterıstica de IEEE 802.11a/g/p
Estandar Banda de operacion [GHz] Ancho de banda [Mbps] Tecnica de difusion
802.11a 5.150 - 5.825 6, 9, 12, 18, 24, 36, 48, 54 OFDM
802.11g 2.412 - 2.489 20-54 RF DSSS y OFDM
802.11p 5.86 - 5.93 10 OFDM
La implementacion disponible para GNURadio ejecuta para capa fısica un receptor y trans-
misor OFDM. Funciona variando la frecuencia de muestreo entre 5, 10 o 20 MHz y la fre-
cuencia de operacion. De esta manera es posible transmitir o recibir una senal que cumple
con alguno de los tres estandares descritos en la tabla 7-1. La implementacion es funcional,
es decir, es posible comunicarse con dispositivos que cuenten con la tecnologıa WiFi, incluso
aunque los bloques funcionales no replican la pila del protocolo sino unicamente sus dos
capas inferiores. Desde este punto de vista, hay un amplio horizonte de mejora en la intro-
duccion del stack puesto que en este punto, la implementacion no es capaz, por ejemplo, de
difundir una SSID, o de asociarse a una, no existe proceso de emparejamiento, por lo que no
se intercambian semillas con el dispositivo al que se quiera comunicar.
Por supuesto, esto supone varios retos para las implementaciones, puesto que la configura-
cion debe ser tal, que la tarjeta WiFi con la que se esta comunicando sea enganada para creer
que esta en una red AD-HOC con el dispositivo de radio definida por software donde esta
implementado el flujograma. La comunicacion es posible gracias a que el flujograma trabaja
7.2 IEEE 802.11a/g/p 27
en modo promiscuo, lo cual a su vez, representa otro reto, esta vez en el procesamiento de las
senales debido a la exagerada ocupacion del espectro, al menos para 802.11g. A diferencia de
los otros protocolos analizados, en 802.11g es altamente probable que el canal por el que se
quiera comunicar se encuentre ocupado por multiples dispositivos. Pero el reto en sı mismo
no es la cantidad de muestras que el computador debe operar sino la frecuencia a la cual las
muestrea, que es de 20MHz para 802.11g y de 10MHz para 802.11p, que ademas, son senales
complejas, es decir se debe muestrear Q e I a dichas frecuencias.
Ası pues, aunque la implementacion sea funcional, la cantidad de parametros y configura-
ciones que deben ser propuestas para las necesidades de cada ambiente de implementacion,
hacen del transceptor para IEEE 802.11a/g/p un reto tecnico por encima de uno conceptual.
De esta manera, replicar los resultados expuestos por los disenadores de los bloques no es
una tarea trivial y debe prestarse especial atencion a esta. Lo anterior es evidenciable en la
cantidad de comentarios y entradas en el foro de GNURadio para el transceptor de IEEE
802.11a/g/p haciendo alusion a problemas en la implementacion tales como, hardware, con-
figuracion en el sistema operativo, configuracion en los bloques funcionales o librerıas.
A pesar del reto que supone la implementacion de este transceptor, se escoge a IEEE
802.11a/g/p como el segundo protocolo para implementar el gateway propuesto en el do-
cumento, debido a que cuenta con bloques funcionales para la capa fısica y de enlace en
recepcion y transmision, a diferencia de Bluetooth, WirelessHART y los demas protocolos
estudiados.
7.2. IEEE 802.11a/g/p
7.2.1. Transceptor implementado en GNU Radio
La libreria gr-ieee802-11 fue disenada e implementada por Bastian Bloessl a partir de traba-
jos previos en el procesamiento para la capa fısica (receptores OFDM) y la subcapa MAC,
se encuentra disponible en https://github.com/bastibl/gr-ieee802-11. El principal logro de su
trabajo fue implementar comandos de la librerıa VolkProfile para configurar los bloques fun-
cionales de IEEE 802.11 y poder establecer una frecuencia de muestreo de 20MHz, que es
requerida para operar en la banda de los 2.4 GHz, que es donde se encuentran los dispositi-
vos comerciales. A partir de esto, elaboro el transceptor que se implementara en el presente
trabajo. En las siguientes lineas se exponen las generalidades del flujograma y los pasos para
su configuracion.
El flujograma del transceptor se puede evidenciar en la figura 7-3. Los bloques no estan
divididos en transmision y recepcion sino por funciones, de esta manera, se encuentra un
bloque para la subcapa MAC y otro para la capa fısica. Como se puede observar el flujogra-
28 7 Analisis de protocolos
ma esta muy bien condensado, y sus tareas se pueden resumir en cuatro bloques funcionales.
El bloque WiFi PHY Hier no es definido por codigo, sino representa a un flujograma je-
rarquizado. Este es el equivalente a la capa fısica. Dentro de el se realiza todo el proceso
de reconocimiento de preambulo, alineacion de sımbolos y decodificacion, y, el inverso para
transmision. El bloque WiFi MAC se encuentra construido en C++, en recepcion se encarga
de tomar la trama que envıa la capa fısica y des-encapsular el mensaje, en transmision de
incorporar el mensaje. Los bloques TUNTAP PDU y Ethernet Encapsulation se encargan de
modificar la trama para que pueda ser reconocida por el sistema operativo a traves de una
red virtual. Los demas bloques cumplen funciones de visualizacion y adquisicion de datos.
Figura 7-3: Flujograma del transceptor para IEEE 802.11 a/g/p
Configuracion
En estas lineas se expone la configuracion necesaria para ejecutar los bloques funcionales
expuestos anteriormente.
En primer lugar se debe garantizar que las dependencias necesarias para el funcionamiento
de los bloques esten instaladas. A continuacion, se listan dichas dependencias, su utilidad
para la implementacion de los bloques funcionales sobre GNURadio y las instrucciones de
instalacion.
Swig: Swig es una interfaz compiladora que conecta programas escritos en C y C++
con otro lenguajes tales como Perl, Python, RUby y Tcl. Su funcionamiento se ba-
sa en tomar las declaraciones encontradas en los archivos de las cabeceras C/C++
7.2 IEEE 802.11a/g/p 29
y a partir de estos generar el codigo necesario para direccionar las declaraciones en
los demas lenguajes hacia estas. Adicionalmente, Swig provee una variedad de carac-
terısticas configurables que permiten al programador editar el proceso de direccionar
las declaraciones de acuerdo a las necesidades particulares de su aplicacion. En el caso
del transceptor para IEEE 802.11 a/g/p, Swig es necesario porque una parte de los
bloques estan escritos en lenguaje Python y otros en C++. Por supuesto esto no fue
planeado u organizado, sino fue emergiendo a partir de las habilidades propias de cada
programador que aporto a la construccion del transceptor. Por lo que gracias a Swig
es posible implementar los dos lenguajes en un solo ambiente. En Ubuntu se instala
con la siguiente linea en la terminal:
sudo apt-get install swig
Log4cpp: Log4cpp es una librerıa de C++ que anade la funcionalidad de crear archivos
de registro para programas, syslog, IDS u otras aplicaciones, de una manera flexible.
Esta modelado a partir de la librerıa Log4 de Java, tratando de ser lo mas parecida
posible. Esta librerıa no viene por defecto instalada en GNURadio y su integracion
no es obligatoria. En caso de que no se instale, se usara la opcion para esta tarea por
defecto. Para el caso del transceptor se requiere porque es usada en los codigos de C++
para algunos bloques. En Ubuntu se instala con la siguiente linea en la terminal:
sudo apt-get install liblog4cpp5-dev
gr-foo: gr-foo es un proyecto disenado por Bastian Bloessl donde se encuentra un
compilado de bloques funcionales disponibles para usar en diferentes aplicaciones. Entre
los principales bloques se encuentran Wireshark Connector, Packet Pad, Burst Tagger,
Packet Dropper y Periodic Msg Source. En Ubuntu se instala con las siguientes lineas
en la terminal:
git clone https://github.com/bastibl/gr-foo.git
cd gr-foo
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig
Posteriormente, se procede a la instalacion de los bloques para IEEE 802.11 a/g/p. Para
esto se sigue un procedimiento similar al expuesto para gr-foo. Se ejecutan los siguientes
comandos.
git clone git://github.com/bastibl/gr-ieee802-11.git
cd gr-ieee802-11
30 7 Analisis de protocolos
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig
Al tener lista la instalacion se debe ejecutar el archivo /examples/wifi phy hier.grc y depu-
rar el flujograma con GNURadio. Lo anterior debido a que este flujograma contiene la capa
fısica de IEEE 802.11 a/g/p que es usado por las aplicaciones para transmision, recepcion y
el transceptor. Estos bloques a diferencia de los demas en la misma carpeta, no generan el
archivo de python en la misma ruta, sino que lo produce en /.grc gnuradio/, en caso de que
sea necesario comprobarlo.
Finalmente, se recomienda que se ajuste el tamano maximo de memoria compartida para
mejorar el rendimiento del transmisor. Esto debido a que los bloques del transmisor usan el
bloque Tagged Stream, que a su vez usa la memoria compartida, para almacenar una trama
completa en el buffer antes de procesarla. En la mayoria de sistemas Linux la cantidad
por defecto no es suficiente para generar un funcionamiento adecuado, por lo que si no se
modifica, se pueden presentar perdidas en los paquetes antes de ser enviados. Esto se realiza
a traves de la siguiente linea en la terminal. Por supuesto, este valor debe ser menor al de la
memoria RAM en el equipo.
sudo sysctl -w kernel.shmmax= Cantidad de memoria
7.3. IEEE 802.15.4
7.3.1. Transceptor implementado en GNU Radio
Para este caso se encuentran dos librerıas diferentes, gr-ieee802-15-4 y gr-WSN. La prime-
ra tambien fue disenada por Bastian Bloessl y es compatible con la capa de aplicacion del
sensor TelosB. La segunda fue construida por Miguel Sastoque y Claudia Segura y esta di-
senada para comunicarse con los modulos Xbee S2 y Xbee pro. Notese que IEEE 802.15.4
no define la capa de aplicacion, por lo que esta debe ser disenada de acuerdo a las especifi-
caciones del fabricante, por esa razon es que las dos implementaciones diferentes tienen lugar.
En la figura 7-4 se expone el flujograma para la primera de las implementaciones. Como
se puede observar, la construccion guarda ciertas similitudes con la de IEEE 802.11a/g/p,
puesto que son del mismo autor. En este caso se divide en la capa fısica, bloque IEEE 805.4
CSS PHY, la subcapa MAC, bloque IEEE 802.15.4 MAC y el stack del protocolo para el
7.3 IEEE 802.15.4 31
dispositivo mencionado, bloque RIME Stack. En el flujograma se ha expuesto una de las dos
modulaciones que se encuentran disponibles.
Figura 7-4: Flujograma del transceptor para IEEE 802.15.4 [31]
De igual manera, en la figura 7-5 se exponen los bloques funcionales para la segunda im-
plementacion. Este desarrollo guarda importantes diferencias con el expuesto anteriormente,
entre las mas notables se encuentra que, los bloques son disenados en Python mientras que
los anteriores se encuentran en C++, ademas, como se puede observar, el flujograma divide
las tareas claramente segun el modelo OSI para recepcion y transmision. El stack imple-
mentado en este caso es el de la compania Digi. Este flujograma es el que se implementa
en el desarrollo del gateway, en el marco de las tareas propuestas en el presente proyecto.
Notese que en este caso se ha implementado el segundo tipo de modulacion definida por
IEEE802.15.4, esto se realiza debido a que el radio de los Xbee S2 utiliza dicha modulacion
en la capa fısica.
Configuracion
Como se expuso anteriormente, existen dos implementaciones de bloques funcionales para
IEEE 802.14.5, estando la primera basada en la segunda. A partir de esta premisa se de-
be ejecutar una configuracion de los repositorios que incluya las dos implementaciones. El
proceso descrito para verificar las dependencias en la seccion de configuracion para el inciso
de IEEE 802.11 es extendible al de IEEE 802.15.4. De esta manera, el primer paso debe
32 7 Analisis de protocolos
Figura 7-5: Flujograma del transceptor para IEEE 802.15.4 modificado [2].
ser instalar las librerıas desarrolladas por Bastian Bloessl. Esto se realiza con las siguientes
lineas en la terminal, para Ubuntu.
git clone https://github.com/bastibl/gr-ieee802-15-4
cd gr-ieee802-15-4
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig
Posteriormente, se instalan las librerıas descritas para gr-WSN Para este caso, luego de
clonar la librerıa, se debe ingresar a la carpeta en la ruta /gr-WSN/ y el eliminar la sub-
carpeta build, para volverla a construir y que se agreguen los registros correspondientes a la
raız de GNURadio. El proceso de clonado es igual al anterior pero con referencia a la pagina
https://github.com/EsperanzaSegura/gr-WSN y la carpeta mencionada anteriormente.
7.4 Equivalencias entre IEEE 802.11a/g/p e IEEE 802.15.4 33
Finalmente, en la raız de la librerıa se encuentra una carpeta llamada examples donde estan
almacenados los flujogramas que crean los bloques jerarquicos para el transceptor. Dichos
flujogramas se deben ejecutar previamente para que los bloques puedan ser reconocidos y
ası se pueda depurar el transceptor. A diferencia de IEEE 802.11, en este caso no hay un uso
de recursos de maquina tan alto como para modificar o anadir librerıas para cambiar valores
predeterminados de la distribucion de recursos por parte de Ubuntu, esto debido a las tasas
de muestreo.
7.4. Equivalencias entre IEEE 802.11a/g/p e IEEE
802.15.4
El estandar IEEE 802.11 define las dos capas mas bajas del modelo OSI, capa fısica y capa de
enlace. Adicionalmente, la capa de enlace se divide en dos capas, denominadas MAC (Con-
trol de Acceso al Medio) y LLC (Control Logico de Enlace), donde la primera representa
la parte inferior y la segunda la parte superior de la capa de enlace. En la implementacion
de IEEE 802.11a/g/p, solamente se incluye la capa fısica y la subcapa MAC, por lo que el
analisis presentado en las siguientes lıneas, excluye la subcapa LLC. Ademas, el stack no
se encuentra implementado, por lo que no es posible realizar el proceso de asociacion entre
nodos o procesar senales del tipo de CTS (Clear to send), RTS (Request to send) o ACK
(Asentimiento), de esta manera, el modulo definido por software debe ejecutarse en modo
promiscuo y los dispositivos IEEE 802.11a/g/p con los que se quiera comunicar, deben ser
modificados para evadir el proceso de asociacion.
Los bloques definidos por software son compatibles con las versiones a, g y p de IEEE 802.11.
Esto sucede porque las tres son disenadas a partir de la tecnica de modulacion OFDM (Ort-
hogonal Frequency Division Multiplexing). La primera en aparecer es IEEE 802.11a, la cual
anade como modificacion la operacion en la banda de 5GHz y el uso de 52 subportadoras
para aumentar la tasa de transmision. Posteriormente 802.11g, se propone como una me-
jora a 802.11b, puesto que este ultimo no era compatible con la version a. En este caso la
operacion se mantiene en la banda de 2.4GHz pero la tasa de transmision se eleva a una
similar a la de 802.11a. Finalmente, aparece 802.11p como una adaptacion de 802.11 a redes
vehiculares, en el cual se reduce la complejidad del proceso de asociacion entre nodos y el
ancho de banda se modifica a 10MHz, ademas, opera en la banda de 5GHz. Estos proto-
colos producen tramas similares en las capas mencionadas. Un modelo general de la trama
que produce la implementacion sobre GNU Radio, es presentado en la figura 7-6, donde se
muestra el preambulo, la cabecera PLCP y la trama proveniente de la subcapa MAC.
34 7 Analisis de protocolos
PreámbuloCampo PLCP Header MPDU
Figura 7-6: Trama WiFi producida
La cabecera PLCP de la capa fısica que se produce en la implementacion, se presenta en la
figura 7-7, sin embargo, puesto que esta contiene campos caracterısticos del radio utilizado
y tecnica de transmision, para los dos estandares no es necesario realizar equivalencias para
los campos, es decir, al enviar o recibir tramas IEEE 802.11 e IEEE 802.15.4 se produce la
trama de capa fısica de acuerdo a sus respectivas implementaciones. De los cinco campos
presentados, los tres primeros son valores de referencia para el radio, el cuarto, el espacio de
banderas presentes, indica que parametros de la transmision se envıan en la trama, entre los
cuales se encuentran, por ejemplo, la tasa de muestreo, el canal de transmision o la potencia
de la senal y ruido en la antena. Estos valores se insertan en un orden preestablecido en el
campo de valores de banderas, solamente si anteriormente se indico que se incluirıa.
Revisión
cabeceraCampo
Revisión
PAD
Tamaño
Cabecera
Banderas
Presentes
1 1 2 4 nBytes
Valores
Banderas
Figura 7-7: Cabecera PLCP para IEEE 802.11
La trama producida por la subcapa MAC se presenta en la figura 7-8. Esta trama es de
especial interes porque es donde se aplican las equivalencias para proponer una convergencia
entre 802.11 y 802.15.4.
Control de
TramaCampo
Duración
IDDA (1) SA (2) RA (3)
Control de
SecuenciaTA (4)
Cuerpo
de tramaFCS
2 2 6 6 6 2 6 0-2312 4Bytes
Figura 7-8: Trama MAC para IEEE 802.11
El campo de control de trama se presenta en la figura 7-9, como se puede observar, la
mayorıa de los campos son caracterısticos de la operacion en la tecnologıa WiFi, por lo que
al igual que los campos de la capa fısica, se puede dificultar la obtencion de equivalencias
con 802.15.4.
Versión
protocoloCampo TIpo Subtipo
Para
DSFragmento
Re-
intento
Política
Energía
Datos
adicionales
0-1 2-3 4-7 8 9 10 11 12 13Bit
Encriptar
WEPOrden
14 15
De
DS
Figura 7-9: Campo control de trama para IEEE 802.11
El control de secuencia para la trama producida por la subcapa MAC se presenta en la
figura 7-10, donde se puede evidenciar que no solo hay un control para la enumeracion
7.4 Equivalencias entre IEEE 802.11a/g/p e IEEE 802.15.4 35
de tramas, sino de fragmentos, generados a partir del parametro MTU, que para el caso
de la implementacion de IEEE 802.11a/g/p se establece en 440, debido a la capacidad de
procesamiento disponible.
Número
fragmentoCampo
Número
secuencia
0-3 4-15Bit
Figura 7-10: Campo secuencia de trama para IEEE 802.11
Equivalentemente, para IEEE 802.15.4 y mas especıficamente, para las especificaciones in-
troducidas en el dispositivo comercial Xbee S2, un extenso analisis es expuesto en el capıtulo
6 de [2], el cual en su momento, represento una importante tarea de documentacion, puesto
que fue el primer analisis tecnico estricto, a partir del modelo OSI, que se realizo sobre esta
tecnologıa. De esta manera, los formatos y campos de las tramas deben ser consultados allı,
para proseguir con la lectura del libro.
Ası, a partir del formato de trama visto desde la subcapa MAC para IEEE 802.11a/g/p,
presentado aquı, y, el de IEEE 802.15.4, presentado en [2], se proponen las equivalencias
necesarias entre los dos estandares, para permitir la interoperabilidad a traves del dispositivo
definido por software con capacidades de concentrador. Dichas equivalencias se presentan en
la tabla 7-2. Es de aclarar, que no se pretende ahondar en la construccion de una pila de
compatibilidad, puesto que eso requiere un trabajo mucho mas extenso que el presentado aca,
por el contrario, el objetivo es disenar los bloques funcionales que permitan la construccion de
dicha pila en posteriores desarrollos, tal y como se expone en la seccion de trabajos futuros
del capıtulo de conclusiones. En ese orden de ideas, las equivalencias presentadas son las
suficientes para permitir la comunicacion.
Tabla 7-2: Equivalencias necesarias para permitir comunicacion entre IEEE 802.15.4 e IEEE
802.11
Parametro IEEE 802.11 IEEE 802.15.4
Identificador unico MAC Direccion 64 bits
Direccion de Red Primeros 24 bits de IP Pan ID
Direccion del nodo Ultimos 8 bits de IP Direccion 16 bits
Transmision Broadcast Utimos 8 bits de IP .255 Direccion 16 bits 0xFFFF
Numero de secuencia Numero de secuencia Numero de secuencia
8 Modificacion de umbral de
procesamiento a partir de logica difusa
8.1. Descripcion del problema
La definicion de la capa fısica del receptor IEEE 802.11a/g/p [41] incluye un bloque, deno-
minado WiFi Sync Short, que es responsable de aceptar o rechazar las muestras que llegan
mediante la busqueda de preambulos de la trama IEEE802.11a/g/p. Ademas, en el caso de
encontrar un preambulo, su autocorrelacion normalizada tiene que cumplir ciertas condicio-
nes. La propuesta presentada en este capıtulo se basa en uno de los parametros involucrados
en la asignacion relacionada. En esta seccion se expone el analisis y justificacion del desarrollo
propuesto.
8.1.1. Umbral de procesamiento en IEEE 802.11
Cada trama de IEEE 802.11a/g/p inicia con una secuencia corta de preambulo, la cual esta
conformada por un patron que se extiende por 16 muestras y se repite 10 veces. El algoritmo
para ejecutar la deteccion de trama consiste en calcular la correlacion entre s[k] y s[k + 16],
ası, idealmente, cuando la correlacion sea maxima durante 10 repeticiones, se estara en el
preambulo de una trama, en la implementacion suele establecerse por debajo de 3. Este
proceso generalizado se muestra en (8-1).
a[n] =N−1∑k=0
s[n+ k]s[n+ k + 16] (8-1)
Donde, N es la ventana configurable de muestras sobre las cuales se calcula la correlacion y
s representa el conjugado de s.
Ademas, para que el calculo sea independiente del nivel absoluto de las muestras recibidas,
se normaliza la correlacion por medio del termino descrito en (8-2).
p[n] =N−1∑k=0
s[n+ k]s[n+ k] (8-2)
Finalmente, el coeficiente que sera tenido en cuenta para determinar el inicio de la trama se
expone en (8-3).
8.1 Descripcion del problema 37
c[n] =|a[n]|p[n]
(8-3)
Este receptor OFDM, integrado en la implementacion de gr-ieee-802-11, reconoce una nueva
trama si y solo si la correlacion en la ventana configurable de muestras, denominado Plateau,
esta sobre un umbral. Este umbral es el que se pretende modificar por medio del sistema
difuso.
Sin embargo, este enfoque teorico no se puede implementar en dispositivos IEEE802.11, debi-
do al ruido introducido por el entorno en la transmision. Ası, en el receptor IEEE 802.11a/g/p
integrado en la aplicacion del gr-ieee-802-11 [41], una nueva trama se reconoce si la corre-
lacion para el preambulo, en una ventana configurable de muestras en el intervalo discreto
[ 1,10], es, al menos, otro valor configurable, pero en el intervalo continuo [0,1]. De esta
manera, dos parametros deciden si el preambulo debe considerarse como una nueva trama.
El primero se denomina plateau, es el equivalente a N en la descripcion teorica y su valor se
fija comunmente alrededor de 3 para no rechazar tramas que podrıan estar completas pero
con una relacion senal/ruido (SNR) baja en la mayor parte de las muestras del preambulo.
El segundo se denomina threshold, que representa el valor esperado de la autocorrelacion en
el preambulo, su magnitud ideal es 1, pero como se expone anteriormente, no es posible,
por lo tanto, un valor inferior se determina con el fin de admitir muestras de preambulo con
una menor autocorrelacion. El valor comunmente implementado es de alrededor de 0.6, pero,
dado que su modificacion es posible a partir del grafico de flujo en GNU Radio, dependiendo
de las caracterısticas de implementacion, su valor se modifica. Por lo tanto, en la mayorıa
de las implementaciones, los valores de plateau y threshold se establecen lo mas bajo posible
para no perder tramas. Sin embargo, esta no es una solucion adecuada, porque las tramas
danadas, pueden todavıa ser entregadas a la subcapa MAC, causando procesamiento inne-
cesario de senal en el receptor. De esta manera, una solucion adaptada a las necesidades,
serıa configurar un valor de plateau alto, cerca de 10, al comienzo de la implementacion, y
modificar el threshold en tiempo real de acuerdo con las condiciones del medio de transmision.
En ese orden de ideas, se pretende modificar el valor del threshold por medio de un sistema
difuso, ya que un valor que se introduce al inicio de la aplicacion no es modificable en
tiempo real. El objetivo es que esta variable pueda ser modificada automaticamente durante
la simulacion desde los parametros caracterısticos de la red inalambrica encontrados en
la implementacion. La operacion debe estar orientada a entregar a la subcapa MAC solo
muestras en perfectas condiciones por medio de valores de umbral elevados para evitar un
procesamiento innecesario. Ademas, en caso de perdidas por ciertas condiciones del entorno
como ruido o alto trafico en el canal de transmision, el valor debe reconfigurarse para permitir
una mayor flexibilidad en la admision de tramas. En este sentido, la logica difusa representa
la oportunidad de una implementacion ajustada a las necesidades, ya que como es sabido
38 8 Modificacion de umbral de procesamiento a partir de logica difusa
su uso es sugerido para abordar problemas de alto grado de complejidad, no lineales, que
generalmente no tienen modelos matematicos precisos que los representan [42].
8.2. Sistema de inferencia difusa propuesto
8.2.1. Salida y Entradas
El primer paso para disenar el sistema difuso es definir apropiadamente las entradas y salida,
de acuerdo a las necesidades del problema y realizar una caracterizacion exhaustiva, para
poder establecer sus universos. En las siguientes lıneas se presenta un analisis sobre la variable
de salida, umbral, y las tres variables de entrada escogidas, SNR, FER y potencia de la senal
de entrada, a traves de experimentos basados en los flujogramas para recepcion y transmision
de IEEE 802.11a/g/p, presentados en las figuras 8-1 y 8-2.
Figura 8-1: Flujograma para recepcion de IEEE 802.11a/g/p para analizar el comporta-
miento de las cuatro variables: Este flujograma se implementa en la USRP
B210. SNR, proviene del bloque WiFi Message Handler, FER, proviene del
bloque WiFi Parse MAC, Potencia de la senal, proviene del bloque Moving Ave-
rage y Threshold, es configurado a partir del bloque Message Strobe. Ademas,
se agrega un conector a Wireshark donde se puede evidenciar el formato de
cada trama que arriba.
8.2 Sistema de inferencia difusa propuesto 39
Figura 8-2: Flujograma para transmision de IEEE 802.11a/g/p usado en el analisis del
comportamiento de las cuatro variables: Este flujograma se implementa en la
USRP N210. Por medio de este se generan 10 mensajes por segundo con la
palabra “tes”. Se introduce un parametro para la variacion de la potencia de
transmision, a partir de la cual se modifican los parametros en recepcion.
La salida del sistema difuso es el parametro threshold asociado al bloque WiFi Sync Short.
Los valores que puede tomar dicha variable se encuentran en el intervalo [0, 1], pero de este
intervalo, no todos los valores representan una posibilidad en la aplicacion, ası por ejemplo,
si se utiliza un valor cercano a 0 no se puede reconocer el inicio de trama, porque cualquier
parte de este pasarıa como inicio, y, con un valor cercano a 1 puede que nada sea reconocido
como inicio de trama debido a las perdidas en el canal. Para determinar el intervalo real en
el que se puede sintonizar la variable, se formulan los siguientes experimentos. El resultado
se puede evidenciar en la figura 8-3.
Experimento 1: En el nodo de transmision se ajusta la potencia de transmision hasta
lograr un SNR en el cual la parte de la constelacion de los cuadrantes 1 y 4 sea
totalmente diferenciable de la de 2 y 3, de tal manera se concentren en un sector estricto
del plano, lo cual representa un SNR por encima de 25 dB, el maximo aconsejable en la
USRP no debe superar los 30dB, figura 8-4. A partir de esto, se varia el umbral en el
intervalo de 0 a 1, en pasos de 0.05 si no hay cambios bruscos y 0.01 en caso contrario,
cada 1000 tramas enviadas y se calcula la proporcion de tramas recibidas para cada
valor del umbral.
Experimento 2: En el nodo de transmision se ajusta la potencia de transmision hasta
lograr un SNR en el cual la parte de la constelacion de los cuadrantes 1 y 4 se mezcle
con la de 2 y 3, pero se permira distinguir parte de las componentes de la constelacion,
lo cual representa un SNR alrededor de 18 dB, figura 8-5. A partir de esto, se repite
el procedimiento anterior.
Experimento 3: En el nodo de transmision se ajusta la potencia de transmision hasta
lograr un SNR en el cual la parte de la constelacion de los cuadrantes 1 y 4 se mezcle
40 8 Modificacion de umbral de procesamiento a partir de logica difusa
con la de 2 y 3, de tal manera que no sean distinguibles, lo cual representa un SNR
por debajo de 10 dB, figura 8-6. Se repite la recoleccion de datos anterior.
Figura 8-3: Resultados para la proporcion de tramas recibidas al variar el parametro
threshold.
A partir de los anteriores resultados se puede concluir que el intervalo en el que se debe
variar el umbral de procesamiento es V = [0.45, 0.745] ∈ R.
La primera entrada en analizar, a razon de su uso en la caracterizacion de la salida, es el
SNR. De las tres variables de entrada es la que mas informacion aporta. Se presenta como
una posibilidad de cuantificacion del distanciamiento de los puntos en la constelacion, lo cual
influye directamente sobre el umbral de procesamiento, puesto que si estan muy cercanos, el
umbral puede ser altamente exigente, pero a medida que se distancian se debe introducir un
umbral cada vez mas bajo. Esta variable se calcula dentro del bloque WiFi Frame Equalizer
en la funcion correspondiente a la estimacion de canal seleccionada (LS, LMS, STA o Linear
Comb), a traves de la siguiente ecuacion. Su magnitud esta dada en decibelios.
SNR = 10 ∗ log10
(signal
noise
)(8-4)
Al variar el SNR que percibe el receptor, se producen los efectos sobre la constelacion eviden-
ciados en las figuras 8-4, 8-5 y 8-6. Claramente, su comportamiento no es lineal, ademas,
para el caso en el que el SNR esta por debajo de 5 dB a pesar de la modificacion del umbral
de procesamiento, la perdida de datos en el mejor de los casos es cercana al 60 %.
Figura 8-4: Efecto de un SNR arriba de los 25 dB sobre la constelacion.
8.2 Sistema de inferencia difusa propuesto 41
Figura 8-5: Efecto de un SNR alrededor de los 16 dB sobre la constelacion.
Figura 8-6: Efecto de un SNR por debajo de los 10 dB sobre la constelacion.
Al igual que en la caracterizacion del umbral de procesamiento, se propone una serie de
experimentos para determinar la relacion entre el SNR y la salida, y, el universo de la
variable. El resultado se puede evidenciar en la figura 8-7.
Experimento 1: En el nodo de recepcion se establece el umbral de procesamiento en
un valor fijo de 0.75. En el nodo de transmision se varia la potencia de transmision
en el intervalo descendiente de 0.75 a 0.15, en pasos de 0.05 si no se notan cambios
bruscos y en pasos de 0.01 en caso contrario, cada 1000 tramas enviadas. A partir de
los datos producidos por el nodo de recepcion se registra el SNR promedio y se calcula
la proporcion de tramas recibidas para cada variacion de la potencia de transmision.
Experimento 2: Se repite el mismo mecanismo del experimento anterior para un valor
fijo del umbral de procesamiento de 0.7.
Experimento 3: Esta vez para un valor en el umbral de procesamiento de 0.65.
Figura 8-7: Resultados para la proporcion de tramas recibidas al variar el parametro SNR.
42 8 Modificacion de umbral de procesamiento a partir de logica difusa
A partir de los anteriores resultados se puede concluir que el universo en el que se debe
evaluar el SNR es Ux1 = [0, 30] ∈ R. Para umbrales de procesamiento menores a 0.65 los
cambios en la proporcion de paquetes recibidos solo son notorios para valores muy bajos
del SNR por lo que no se considera de mayor provecho su inclusion en el documento, sin
embargo, dicha afirmacion se utiliza, posteriormente, para la construccion de las reglas.
La siguiente entrada en ser analizada es el FER. Esta variable esta relacionada con la cantidad
de tramas perdidas, lo cual representa un parametro imprescindible en la determinacion del
umbral, puesto que finalmente el objetivo es establecer el umbral de procesamiento mas alto
en el cual no se pierden tramas. Se calcula dentro del bloque WiFi Parse MAC a traves de
la siguiente ecuacion. Su magnitud es adimensional.
FER = 100 ∗ lostframes
lostframes + 1(8-5)
Donde lostframes es calculado como la resta entre el numero de secuencia de la trama actual
y la ultima trama en arribar.
El intervalo de esta variable es Ux2 = [0, 100] ∈ R como lo indica la ecuacion 8-4. Los expe-
rimentos para definir su comportamiento y universo pueden ser extendidos de los realizados
para caracterizar el umbral de procesamiento. Los resultados se presentan en la figura 8-8.
Figura 8-8: Resultados para el Frame Error Rate FER al variar el parametro threshold.
La ultima variable en ser analizada y con la que se debe tener especial cuidado es la potencia
media de la senal de entrada. Esta variable tiene una dependencia no lineal de la ganancia
de recepcion en la interfaz de la USRP. La caracterizacion se realiza inicialmente para una
ganancia de la senal de entrada de 0.75, posteriormente se introduce una posibilidad de ex-
tension para representar la variacion del universo de estudio dependiendo de la otra variable.
La potencia media se calcula re-usando los bloques funcionales Complex to Mag2 y Moving
8.2 Sistema de inferencia difusa propuesto 43
Average del calculo de la auto-correlacion en la capa fısica para recepcion, esto se hace con
el fin de reducir procesamiento de senal. Su calculo teorico se expone en la ecuacion 8-6.
P = limn→∞1
2N + 1
N∑n=−N
|s[n]|2 (8-6)
Debido a que lo anterior no es posible en la practica y a que se requiere tener un valor de
esta variable en intervalos de tiempo cortos, se introduce la siguiente expresion, la cual se
calcula sobre un intervalo cerrado y movil, es decir, el primer valor que arroja la funcion es
calculado para s[n] entre n = 0 y n = 45, el segundo entre n = 1 y n = 46, el i-esimo entre,
n = i− 1 y n = i+ 45.
P =1
N1
N1∑n=0
|s[n]|2 (8-7)
Donde N1 representa el tamano de la ventana del bloque Moving Average usado en la capa
fısica, su valor de es 64.
Los experimentos para determinar el intervalo efectivo de la potencia de entrada se exponen
a continuacion, en este caso el objetivo no es evaluar el porcentaje de tramas recibidas sino
la potencia que ve la antena en la entrada.
Experimento 1: Se ubican los dos nodos en un canal que no tiene trafico, en este caso
se escoge el canal 178. En el nodo de transmision se envıan tramas cada 10ms. En el
nodo de recepcion se varia la ganancia de recepcion normalizada en el intervalo de 0.5
a 1, en pasos de 0.02, cada 1000 tramas recibidas. Para cada valor de la ganancia, se
capturan los datos generados por la ecuacion 8-8 calculando y registrando el promedio
de estos.
Experimento 2: Se utiliza unicamente el nodo de recepcion. Se ubica en un canal usual-
mente congestionado y se varia la ganancia de recepcion normalizada en el intervalo
de 0.5 a 1, en pasos de 0.02, cada 10s. Se calcula y registra el promedio de la potencia
media percibida en la antena.
Experimento 3: Es una variante del experimento 2 en la cual se ubica la frecuencia
de recepcion en el canal 6, banda de 2, 4GHz. Allı se ubica un router y un nodo,
computador portatil, desde el cual se descarga un archivo a razon de 1.2Mb/s y se
ubica al router a la distancia suficiente para que la USRP perciba la carga transmitida.
En el nodo de recepcion se varia la ganancia de recepcion normalizada en el intervalo
de 0.5 a 1, en pasos de 0.02, cada 10s. Se calcula y registra el promedio de la potencia
media percibida en la antena.
44 8 Modificacion de umbral de procesamiento a partir de logica difusa
Debido al gran intervalo en el que se extendieron los valores [0.0000003, 1.9783], la repre-
sentacion de este universo se realiza en decibelios. Ası pues, la ecuacion que determina la
potencia media se modifica como sigue:
P = 10 ∗ log10
(1
46
45∑n=0
|s[n]|2)
(8-8)
La grafica 8-9 presenta los resultados. A partir de estos es posible determinar que el universo
para la potencia media debe ser Ux3 = [−70, 10][dB] ∈ R. Ademas, como se puede eviden-
ciar, el valor de la ganancia de recepcion normalizada tiene un efecto considerable sobre el
comportamiento de la potencia media, por lo que se considera adecuado incluirla como una
entrada mas al sistema difuso, para esta el universo definido esUx4 = [0.5, 1] ∈ R.
Figura 8-9: Relacion entre la potencia media y la ganancia de recepcion normalizada.
8.2.2. Funciones de pertenencias propuestas
En el inciso anterior se definieron las entradas y los universos asociados a estas y a la salida.
Estos se resumen en la siguiente tabla.
Tabla 8-1: Intervalos para entradas y salida del sistema difuso
VariableIntervalo
Inicio Fin
Threshold 0,45 0,75
SNR 0 30
FER 0 100
Potencia media -70 10
Ganancia Rx 0,5 1
8.2 Sistema de inferencia difusa propuesto 45
Ahora, se deben definir las funciones de pertenencia para cada entrada. Esto se hace a
partir de los experimentos con los cuales se definieron los universos y el comportamiento
evidenciado en las implementaciones del receptor de IEEE 802.11a/g/p. Ası pues, se buscan
patrones que permitan definir intervalos de convergencia entre los datos para conformar una
funcion de pertenencia. En todos los casos las funciones de la pertenencia de los extremos se
definen como se indica en la ecuacion 8-9 y las demas como 8-10 . Solo se usan estos dos tipos
de funciones de pertenencia porque su dominio se encuentra en los reales y solo se requieren
dos parametros para determinar su comportamiento, uno relacionado a su centro Mp y otro
a la extension que alcanzan sobre el universo Dp.
f(x) =1
1 + eDp(x−Mp)(8-9)
f(x) = e−0.5(x−Mp)
2
D2p (8-10)
De esta manera, la definicion formal para las funciones de pertenencia de las entradas se
enuncia a continuacion:
µAk =
1
1 + eDk,i(xi−Mk,i)si k = 1 o k = pi
e
−0.5(xi −Mk,i)2
D2k,i otros casos
(8-11)
Donde, pi es el numero de funciones de pertenencia para la entrada i, Ak es el k-esimo
conjunto difuso de la entrada i y µAki
es su funcion de pertenencia. Dk,i y Mk,i son los dos
parametros para definir la funcion de pertenencia relacionada.
Al igual que en el inciso anterior, se considera primero la variable de salida. Para intentar
segmentar su comportamiento en intervalos, se realizan las siguientes afirmaciones:
A partir de la grafica 8-3, un trheshold cercano al lımite superior del intervalo se
considera altamente exigente: De los resultados ninguno logro tener una proporcion de
tramas recibidas de 1 para un valor superior a 0.74. Con respecto al threshold en los
tres experimentos se puede afirmar que
• Para un SNR¡10dB: Luego de 0.62 comienza a perder muestras.
• Para un SNR=18dB: Luego de 0.65 comienza a perder muestras.
• Para un SNR¿25dB: Luego de 0.74 comienza a perder muestras.
A partir de la grafica 8-3, se puede afirmar que un threshold cercano a 0.45 es excesi-
vamente permisivo en las tramas que se reciben.
46 8 Modificacion de umbral de procesamiento a partir de logica difusa
A partir de la grafica 8-7, se evidencia que a medida que el SNR desciende hay perdidas
para un threshold de 0.7 y 0.65. Pruebas realizadas posteriormente muestran como
si el SNR es crıtico, es decir, por debajo de 5dB para un threshold de 0.55 ya se
encuentran perdidas, por lo que se debe descender hasta un valor cercano a 0.45 para
evitar perdidas.
A partir de estas afirmaciones se definen los siguientes cinco intervalos, en los que se aproxima
el soporte esperado para cada funcion de pertenencia.
[0.45, 0.48], [0.48, 0.55], [0.55, 0.65], [0.65, 0.72], [0.72, 0.745] (8-12)
Los dos intervalos de los extremos representan los casos en lo que se requiera ser extremada-
mente permisivos o exigentes con los paquetes que se reciben, por lo que tienen la extension
mas corta. El intervalo [0.65, 0.72] se construye iniciando en el valor con el que se pierde para
el SNR=18dB y termina en el comienzo del intervalo superior. Analogamente se construye
el intervalo [0.48, 0.55] y finalmente se agrega un intervalo en el medio. De esta manera, se
construyen las funciones de pertenencia expuestas en la figura 8-10, procurando ocupar los
intervalos mencionados. Se le asocian variables linguısticas relacionadas a la variable.
Figura 8-10: Funciones de pertenencia estimadas para la variable de salida threshold.
Ahora, para el SNR, se realizan las siguientes afimaciones:
A partir de la grafica 8-7:
• Para un Threshold superior a 0.7 el SNR debe ser relativamente alto, mayor a
20dB para evitar perder tramas.
• Para un threshold de 0.7 si el SNR es menor a 17dB se pierden tramas. Ademas
si es menor a 12 dB pasan de perderse el 2 % a perderse alrededor del 20 % en
11.65dB y 51 % en 11.4dB.
• Para un threshold de 0.65 si el SNR es menor a 10dB se pierden tramas.
8.2 Sistema de inferencia difusa propuesto 47
Como se menciono en la construccion de las funciones de pertenencia para el threshold,
cuando el SNR es menor a 5dB se debe tomar un efecto especial en el threshold.
A partir de estas afirmaciones se definen los siguientes seis intervalos. Al igual que en los
anteriores, representan una aproximacion al soporte en el que estaran las funciones de per-
tenencia.
[0, 5], [5, 10], [10, 12], [12, 17], [17, 20][20, 30] (8-13)
El intervalo [0, 5] se incluye pensando en los casos en los que se debe disminuir el threshold
a valores cercanos a 0.45, [5, 10] para agrupar los casos en los que el threshold esta alrededor
de 0.65 y se presentan perdidas, analogamente 12, 17 y 17, 20, y, 20, 30 para los datos que
representan un threshold alto. Las funciones de pertenencia se exponen en la figura 8-11.
Figura 8-11: Funciones de pertenencia estimadas para la variable de entrada SNR.
Para la entrada FER, las funciones de pertenencia se definen de una manera mas intuitiva.
Este proceso se expone a continuacion.
El mejor caso es cuando no se tienen perdidas, es decir, FER = 0, pero el siguiente
caso, cuando se pierde una muestra, se encuentra en FER = 0.5, por lo que solo en
pasar de perder 0 a 1 muestra ya se ha ocupado la mitad del universo. Por esta razon
se decide introducir una funcion de pertenencia que cobije unicamente estos dos casos.
Luego de perder 1 muestra, la siguiente consideracion es 2, es decir, FER = 0.66. En
la pruebas expuestas en la figura 8-8, para valores del threshold entre 0.45 y 0.75, el
FER se encuentra entre 0 y 0.9, por lo que el siguiente grupo se conforma con los datos
que generan un FER mayor a 0.5 y menor a 0.9.
Finalmente, puesto que un FER de 0.9 ya representa una tasa de perdidas alta, se
define el ultimo grupo desde este valor hasta 1.
48 8 Modificacion de umbral de procesamiento a partir de logica difusa
A partir de lo anterior, se construye una aproximacion al soporte en el que estaran las tres
funciones de pertenencia.
[0, 0.5], [0.5, 0.9], [0.9, 1] (8-14)
Ademas, para facilitar la interpretabilidad de los valores del FER, este se entrega en unidades
porcentuales, es decir, se multiplica por 100 para evaluarse. Las funciones de pertenencia se
exponen en la figura 8-12.
Figura 8-12: Funciones de pertenencia estimadas para la variable de entrada FER.
El analisis para las dos ultimas entradas se realiza en paralelo, puesto que desde su con-
cepcion, estan pensadas como la representacion de un unico fenomeno, donde la ganancia
normalizada es un modificador de la potencia media.
A partir de la grafica 8-9 se definen las siguientes agrupaciones.
Para la ganancia de recepcion normalizada se plantean tres agrupaciones. La primera
alrededor de 0.75 que representa el valor de uso habitual para el receptor IEEE802.11a/g/p.
La segunda en la parte baja del universo, es decir, hacia 0.5 y la tercera en la parte
alta, es decir, hacia 1.
Por parte de la potencia media se evidencia el siguiente comportamiento.
• Cuando se realizo la prueba en el canal 6 de la banda de 2.4GHz, el mınimo valor
de potencia media no fue superior a -10dB, pero la mayorıa de datos estuvieron
sobre 0dB.
• En la prueba del canal congestionado, la mayorıa de valores se encontraron entre
-30dB y -50dB.
• En la prueba del canal de la banda de 5GHz el maximo valor no supero a -40dB.
8.2 Sistema de inferencia difusa propuesto 49
De acuerdo a lo expuesto anteriormente, para la ganancia se formulan los siguientes interva-
los.
[0.5, 0.7], [0.7, 0.8], [0.8, 1] (8-15)
Las funciones de pertenencia construidas se presentan en la figura 8-13.
Figura 8-13: Funciones de pertenencia estimadas para la variable de entrada ganancia de
recepcion normalizada.
Analogamente, para la potencia media se construyen los siguientes intervalos de decision.
[−70,−40], [−40,−20], [−20,−10], [−10, 0], [0, 10] (8-16)
El intervalo [−70,−40] representa la agrupacion de las potencia percibidas en canales en los
que no hay trafico habitualmente, [0, 10] en las que hay congestion y [-40,-20] en los que
hay trafico habitual. Los otros dos intervalos se introducen para cubrir cambios entre los
anteriores. Las funciones de pertenencia se introducen en la figura 8-14.
Figura 8-14: Funciones de pertenencia estimadas para la variable de entrada potencia
media.
50 8 Modificacion de umbral de procesamiento a partir de logica difusa
8.2.3. Reglas propuestas
Con los universos discursos de las entradas y salida definidos, y, las funciones de pertenencia
asociadas, el siguiente paso consiste en la formulacion de las reglas si-entonces del sistema
difuso. Para esto se analizan las relaciones existentes entre los conjuntos difusos definidos por
las funciones de pertenencia con el fin de construir generalizaciones que puedan ser usadas
para determinar el comportamiento del threshold.Uno de los grandes retos de la construc-
cion de las reglas es generar el menor numero de estas. En total, la combinacion entre las
funciones de pertenencia es 5 ∗ 6 ∗ 3 ∗ 5 que representan 450 posibles reglas. Desde el co-
mienzo, intentar establecer un numero de reglas abajo de 50 para esa cantidad de entradas
y funciones de pertenencia es una tarea casi imposible. Ademas, si se lograra, se entenderıa
que hay funciones de pertenencia que sobran, puesto que, no se usarıa mas del 10 % de re-
glas disponibles. Por esta razon se re-consideran las funciones de pertenencia asociadas a las
variables de entrada SNR y potencia media.
Para el SNR, se pasa de seis a tres funciones de pertenencia. Para esto se unen “Muy
bajo” y “bajo” en “bajo” ,y, “Medio bajo”, “Medio alto” y “alto” en “Medio”. La union
de las tres funciones de pertenencia que genera “Medio” no presenta mayor problema de
interpretabilidad puesto que es un intervalo en el cual no se requiere que el threshold cambie
mucho, pero, para las dos asociadas a “bajo”, se tiene precaucion en establecer un nivel de
pertenencia de 1 a valores menores a 3dB y uno superior a 0.9 para valores entre 3dB y 5dB,
ası de esta manera lo que antes era el conjunto “muy bajo” se traslada a “bajo” con niveles
de pertenencia altos. El resultado se presenta en la figura 8-15.
Figura 8-15: Funciones de pertenencia estimadas modificadas para la variable de entrada
SNR.
Analogamente, para la potencia media se pasa de 5 a 3 funciones de pertenencia. En este
caso se combinan “Baja” y “Media” en “Media”, y, “Alta” y “Muy alta” en “Alta”. Estos
tres intervalos son construidos para integrar las pruebas realizadas en cada uno de los tres
8.2 Sistema de inferencia difusa propuesto 51
experimentos de la caracterizacion de la variable. El resultado se expone en 8-16.
Figura 8-16: Funciones de pertenencia estimadas modificadas para la variable de entrada
potencia media.
Con la modificacion introducida, la cantidad posible de reglas se modifica a 3 ∗ 3 ∗ 3 ∗ 3
que representan 81 posibles reglas, una disminucion en mas de 10 veces del valor presentado
anteriormente. Teniendo en cuenta que 81 es un numero de combinaciones reducido, se
evaluan las 81 posibles combinaciones descartando los casos que se considera que no se pueden
presentar, por ejemplo una potencia media “alta” y una ganancia de recepcion normalizada
“baja”, y, suprimiendo las reglas en las cuales para todas las funciones de pertenencia de
una misma entrada, se obtenga la misma salida, por ejemplo, si el SNR es “bajo”, el FER es
“alto” y la potencia media es “baja”, no importa el valor que tenga la ganancia de recepcion
normalizada, se debe introducir un threshold “bajo” para que se reciban todas las tramas
que arriben. La tabla 8-2 presenta las reglas construidas, su definicion se enuncia en () y su
asignacion se realiza como se describe en (8-18).
Reglal : Si x1 es Ak y ... y xnesAj, entonces y es Br (8-17)
µAl1
= µAk , ..., µAln
= µAj y µBl = µBr (8-18)
Donde Ali y Bl son los conjuntos difusos definidos en Ui y V , respectivamente, y relacionados
con la regla, l. El numero de reglas se define como M . k, j y r son el consecutivo de la
funcion de pertenencia dentro de la respectiva variable de entrada/salida (por ejemplo, en
SNR “bajo” es 1, “medio” es 2 y “alto” es 3), y, simbolizan que una regla puede tomar las
funciones de pertenencia que prefiera (por ejemplo, todas las funciones de pertenencia 1 de
cada entrada no tienen que estar relacionadas en una regla). Observe que la notacion µAk
se refiere a las funciones de pertenencia en cada universo de entrada y µAl1
a la funcion de
pertenencia relacionada, por entrada i, con la regla l.
A continuacion se enuncian algunos ejemplos del razonamiento empleado.
52 8 Modificacion de umbral de procesamiento a partir de logica difusa
Regla 1: Si el SNR es “Bajo” y la potencia media es “Baja” entonces el threshold debe
ser “Muy flexible”: Si hay un SNR bajo significa que por alguna razon los puntos de
la constelacion no se encuentran separados en su respectivo cuadrante y no se puede
recuperar ciertas partes de la trama, sı ademas, la potencia media es baja, significa que
se esta en un ambiente donde hay poca interferencia de otras fuentes y el SNR bajo
se puede deber a poca potencia en el transmisor o una gran distancia de separacion.
Por lo anterior, se debe configurar el threshold en un valor muy cercano a 0.45 para
obligar al receptor a recibir todas las tramas que le lleguen. En este caso no importan
las entradas FER y ganancia, puesto que a pesar de sus valores, se debe tomar esta
decision para el threshold.
Regla 10: Si el SNR es “Medio”, el FER es “Bajo”, la potencia media es “Baja” y
la ganancia es “Baja“ entonces el threshold debe ser “Moderado”: El primer gran
razonamiento que compone esta regla es que siempre que haya una ganancia “Baja”
el threshold no puede ser “Exigente” o “Muy exigente” puesto que la ganancia va a
afectar notablemente el valor de la correlacion calculado en el receptor, por lo que
podrıa no ser suficiente para satisfacer un threshold perteneciente a estos conjuntos.
Teniendo en cuenta lo anterior, el threshold se puede ubicar en cualquiera de los tres
conjuntos inferiores, para esto se decide a partir de las otras tres entrada. Exceptuando
la ganancia, las entradas representan un caso en el que se puede establecer un threshold
alto, pero debido a la ganancia, se estable el threshold, en el conjunto difuso con valores
mas altos posibles, este es “Moderado”.
Reglas 28: Si el SNR es “Alto”, el FER es “Medio” y la ganancia es “Alta” entonces
el threshold debe ser “Muy exigente”: En el caso en que la ganancia y el threshold
son altos significa que la constelacion esta llegando adecuadamente al receptor. Puede
haber dos razones para que el FER sea “Medio”. La primera es que el transmisor este
fallando de alguna manera, factor que no se puede corregir en el receptor y, la segunda
es que este llegando una cantidad de tramas que el receptor no es capaz de procesar
cuando se presenta otra fuente transmitiendo. Para esto, la solucion es establecer un
threshold “Muy exigente” para que solo se reciban las tramas que no tengan errores.
8.2 Sistema de inferencia difusa propuesto 53
Tabla 8-2: Reglas Si-entonces para el sistema de inferencia difuso
Regla SNR FER Potencia Media Ganancia Rx Threshold
1 Bajo Bajo Muy flexible
2 Bajo Bajo Medio Flexible
3 Bajo Alto Bajo Moderado
4 Bajo Alto Medio Exigente
5 Bajo Alto Alto Muy exigente
6 Bajo Medio Medio Moderado
7 Bajo Medio Alto Moderado
8 Bajo Alto Medio Flexible
9 Bajo Alto Alto Moderado
10 Medio Bajo Bajo Bajo Moderado
11 Medio Bajo Bajo Alto Exigente
12 Medio Bajo Alto Medio Exigente
13 Medio Medio Bajo Bajo Flexible
14 Medio Medio Bajo Medio Flexible
15 Medio Medio Medio Moderado
16 Medio Medio Alto Bajo Moderado
17 Medio Medio Alto Medio Moderado
18 Medio Medio Alto Alto Exigente
19 Medio Alto Bajo Muy flexible
20 Medio Alto Medio Flexible
21 Medio Alto Alto Moderado
22 Alto Bajo Bajo Moderado
23 Alto Bajo Bajo Moderado
24 Alto Bajo Medio Exigente
25 Alto Bajo Alto Muy exigente
26 Alto Medio Bajo Moderado
27 Alto Medio Medio Exigente
28 Alto Medio Alto Muy exigente
29 Alto Alto Bajo Moderado
30 Alto Alto Alto Moderado
54 8 Modificacion de umbral de procesamiento a partir de logica difusa
8.2.4. Conformacion del sistema de inferencia difuso
La construccion del sistema de inferencia difuso se muestra en la figura 8-17. Las entradas
representadas con x, la salida representada con y y la base de reglas ya han sido presentadas.
Los elementos restantes se describen a continuacion.
Figura 8-17: Modelo de inferencia con fusificador y defusificador.
El fusificador es de tipo Singleton. En terminos computacionales es el fusificador mas
sencillo de todos. Se escogio debido a la limitada cantidad de recursos de procesamiento
para la implementacion en tiempo real en el receptor IEEE802.11a/g/p. El fusificador
mapea un valor puntual xi en un conjunto difuso sobre el universo x. Por ejemplo
cuando la entrada en el FER es 95, este valor se mapea sobre el conjunto difuso
“Alto”, devolviendo el valor de pertenencia de dicho valor. Por lo que el soporte del
nuevo conjunto difuso serıa xi, para este caso 95, y, su pertenencia 1.
µA′(xi) =
{1 si x = xi′
0 otros casos(8-19)
Donde, µA′ es la funcion de pertenencia de xi yx′ es el vector de valores de entrada.
El motor de inferencia realiza el calculo de una regla difusa haciendo uso del fusificador
Singleton. Como primera medida, calcula el antecedente a partir de la busqueda del
mınimo entre cada pareja µAli, µA′(xi), y, posteriormente el mınimo entre todos los
resultantes de las parejas, se computa de la siguiente manera:
µRule(l)(x1, .., xn, y) = mini∈[1,n]∩Z
(min
(µAl
i, µAl(xi)
))(8-20)
En el calculo del antecedente, que representa el nivel de activacion de la regla. La Tnormescogida es el mınimo, como se puede observar en (8-20).
A continuacion, como se indica en (8-21), la implicacion Mamdami para cada regla se
calcula a partir del mınimo dado por (8-20) y la funcion de pertenencia del conjunto
difuso al que esa regla le esta apuntando.
µB′l(y) = min (µBl , µRule(l)(x1, .., xn, y)) (8-21)
8.2 Sistema de inferencia difusa propuesto 55
Cuando el resultado de todas las reglas ha sido arrojado por el motor de inferencia, se
aplica una Snorm para calcular el maximo, punto a punto del universo de salida, entre
estas. Su computo se muestra a continuacion.
µB′(y) = maxl∈[1,M ]∩Z(µB′l(y)) (8-22)
En este caso, la Snorm escogida es el maximo.
El defusificador que se aplica es un promedio ponderado. Se utiliza para encontrar el
centroide del conjunto difuso de salida. Su funcion es realizar un mapeo del conjunto
difuso de salida a un valor puntual. Su calculo se realiza como sigue:
y′ =
∑hi=1 µB′(yi) ∗ yi∑Ni=1 µB′(yi))
(8-23)
Donde, y′ es el centroide, que sera entregado como la salida puntual, h es el tamano
de puntos discretos del universo, yi es cada punto en el universo y µB′(yi) es el valor
de pertenencia al conjunto difuso de yi.
A partir del modelo presentado y con las funciones de pertenencia y reglas expuestas pre-
viamente, se realizan los siguientes ejemplos del funcionamiento del sistema de inferencia
difuso.
Ejemplo 1: Se configuran las entradas puntuales en los siguientes valores:
• SNR = 25 [dB]
• FER = 0
• Potencia media = -10 [dB]
• Ganancia = 0.75
El resultado de la combinacion de las reglas se muestra a la izquierda de la figura 8-18.
En esta se puede observar que solo hubo un conjunto que se disparo casi por completo
en la salida, el conjunto “Exigente”. En la derecha de la figura 8-18 se puede visualizar
la ubicacion del centroide. De esta manera, el valor que el sistema de inferencia difuso
entregarıa a la salida es de 0.6782.
56 8 Modificacion de umbral de procesamiento a partir de logica difusa
Figura 8-18: Proceso de fusificacion para funcion de pertenencia de salida con soporte ubi-
cado hacia los valores altos del universo.
Ejemplo 2: Se configuran las entradas puntuales en los siguientes valores:
• SNR = 20 [dB]
• FER = 50
• Potencia media = -20 [dB]
• Ganancia = 0.7
El resultado de la combinacion de las reglas se muestra a la izquierda de la figura 8-19.
En esta se puede observar que se dispararon dos conjuntos de la salida, “Moderado” y
“Exigente”. “Exigente” se disparo en un valor mas alto, pero el soporte de “Moderado“
es de mayor extension, por lo que el centroide debe estar aproximadamente en la mitad
de estos, como se puede comprobar en la derecha de la figura 8-18. De esta manera,
el valor que el sistema de inferencia difuso entregarıa a la salida es de 0.6602.
Figura 8-19: Proceso de fusificacion para funcion de pertenencia de salida con soporte dis-
tribuido a lo largo del universo.
8.2 Sistema de inferencia difusa propuesto 57
Ejemplo 3: Se configuran las entradas puntuales en los siguientes valores:
• SNR = 20 [dB]
• FER = 80
• Potencia media = -60 [dB]
• Ganancia = 0.85
El resultado de la combinacion de las reglas se muestra a la izquierda de la figura 8-18.
Para este caso se dispararon cuatro conjuntos de la salida, lo cual no es usual, pero
teniendo en cuenta los valores ingresados se considera una respuesta acertada. De estos
cuatro conjuntos el que se dispara en un valor mas alto es “Muy exigente”, pero es el
de soporte mas pequeno, por lo que se espera que esto afecte la ubicacion del centroide,
tal y como se puede comprobar a la derecha de la figura. De esta manera, el valor que
el sistema de inferencia difuso entregarıa a la salida es de 0.6723.
Figura 8-20: Proceso de fusificacion con niveles bajos de disparo en la mayorıa de las fun-
ciones de pertenencia de salida.
8.2.5. Evaluacion del sistema de inferencia difuso
En el pasado inciso se presentaron algunos ejemplos de la salida producida por el sistema
difuso para ciertas combinaciones de entradas. Ahora, se extiende este experimento para
un numero considerable de combinaciones de entradas. Para esto, a partir del receptor de
IEEE802.11 se genera un base de datos en la que se registra el valor de las cuatro entradas
para diferentes entornos y variantes. La base de datos se compone de 800 registros, de los
cuales, cada 10 registros son tomados para condiciones experimentales similares, lo que sig-
nifica que, en total, se exploran 40 diferentes ambientes de prueba. Ademas, de estos 40, la
mitad son realizados para un canal usualmente sin congestion (en la banda de 5GHz) y la
otra mitad para un canal usualmente congestionada (en la banda de 2.4GHz). Para compo-
ner la base de datos se avaluaron mas de 10000 registros, de los cuales se conservaron solo
58 8 Modificacion de umbral de procesamiento a partir de logica difusa
los que representaban una fuente de informacion para el sistema. Los ambientes de prueba
fueron generados cambiando la potencia del nodo de transmisor y receptor, disminuyendo la
calidad del SNR por medio de un bloque funcional en el flujograma del receptor y aumen-
tando el threshold para generar perdidas de paquetes. Para cada combinacion de entradas se
asigna un valor alrededor del maximo, en el cual se puede establecer el threshold sin generar
perdidas, el cual se registra en la base de datos. Ası pues, la informacion recolectada se
representa como una matriz de 800 columnas y 5 filas.
Las 800 combinaciones de entradas recolectadas en la base de datos son introducidas una a
una en el sistema de inferencia difuso. La comparacion entre los valores entregados por el
sistema difuso y los registrados en la base de datos, para el threshold, es presentada en la
figura 8-21.
Figura 8-21: Comparacion entre las salidas producidas por el sistema difuso y la esperada.
Los primeros 400 valores en la figura 8-21 son producidos para los datos del canal de la
banda de 5GHz y los otros 400 para el de 2.4GHz. Como se puede evidenciar, especialmente
para los primeros datos, la salida del sistema de inferencia difuso se aleja considerablemen-
te del maximo valor conveniente para el threshold. Esto, aunque en la practica no es una
problematica, representa un desperdicio de la extension del universo del threshold, especial-
mente cuando no se aprovecha la parte del universo cercana al lımite superior, puesto que
como se propuso en la descripcion del problema, el objetivo del sistema difuso es establecer
un threshold alto cada vez que sea posible y no simplemente tener un valor fijo muy bajo
que permita pasar todas las tramas que lleguen, sin importar su estado.
Por lo anterior, en la siguiente seccion se presenta una propuesta para ajustar las funciones
de pertenencia de tal manera que permitan aprovechar mayormente la extension del universo
para el threshold.
8.3 Algoritmo genetico para ajuste de conjuntos de pertenencia 59
8.3. Algoritmo genetico para ajuste de conjuntos de
pertenencia
Dado que se uso un criterio visual para determinar los parametros Mp y Dp para construir
las funciones de pertenencia para cada variable del sistema, dentro de los intervalos de
soporte propuestos, los datos obtenidos difieren, para algunas combinaciones de entradas,
a los esperados, como se puede comprobar en la figura 8-21. En esta, cuando se evalua el
sistema de inferencia difuso anterior, los valores de salida no cubren el intervalo de salida
como se espera (por ejemplo, un umbral esperado alrededor de 7,4 se fija en 6,8 o uno
esperado alrededor de 0,48 en 0,52). De la afirmacion anterior, deber ser claro que no hay un
valor umbral optimo para una combinacion de entradas determinada, sino un intervalo en
el cual podrıa ser optimo. De esta manera, la preocupacion debe estar orientada a utilizar
la mayor extension posible del intervalo de salida, especialmente en los valores altos. Por
lo tanto, un algoritmo evolutivo se propone con el fin de mejorar el intervalo efectivo de
salida. Este tipo de algoritmo se elige porque no necesita que el espacio de optimizacion sea
diferenciable, es posible definir una funcion objetivo a partir de las necesidades del problema
y se sugiere comunmente para funciones multidimensionales de parametros reales.
8.3.1. Modelo propuesto
El flujo del algoritmo implementado se muestra en la figura 8-22. Sus principales compo-
nentes son: Inicializacion, tanto para el algoritmo como para la poblacion, funcion objetivo,
mutacion y recombinacion. En el proceso, el algoritmo produce una poblacion inicial de in-
dividuos j′, con un genoma que contiene los parametros para construir el sistema difuso,
que evoluciona un k′ numero de generaciones. En cada generacion, el individuo que obtiene
el resultado mınimo de una funcion objetivo se selecciona para ser el padre de la siguiente
generacion. A partir de este, su genoma es mutado y recombinado para generar una nueva
poblacion propuesta, con un ruido muy pequeno introducido por la poblacion real. Uno por
uno, la nueva propuesta y los individuos reales se comparan, solo los mejores van a la nueva
poblacion. Cuando se alcanza la poblacion final, se evalua con un conjunto de datos diferente,
esta etapa es llamada validacion. El proceso de evolucion se repite alrededor de 1000 veces.
Entre los individuos finales, el que logra el mınimo resultado para el conjunto de datos de
validacion, se selecciona como el mejor.
60 8 Modificacion de umbral de procesamiento a partir de logica difusa
Initialize
algorithm
Initialize
population
Objective
Function
k=Generations
amount?
Select
the best
Objective
FunctionRecombination
j=Individuals
amount?
Save
population k
Select
the best
New
Population
Select
individual j
Save New
individual
Begin
Objective
Validation
Function
End
Random
Mutation
j=1
j++
Yes No
Yes No
Figura 8-22: Modelo de evolucion diferencial propuesto.
8.3.2. Construccion del genoma
Cada individuo, candidato solucion, debe estar representado por un cromosoma (genoma),
que contiene los parametros (genes) que van a ser optimizados a traves del algoritmo evolutivo
diferencial. Este genoma se construye a partir de los dos parametros de cada funcion de
pertenencia para las entradas y la salida, como se indica a continuacion:
G = [D1,1,M1,1, ..., D3,4,M3,4, ..., D5,y,M5,y] (8-24)
Por lo tanto, el tamano del genoma corresponde a 34, conformado por dos parametros pa-
ra, tres funciones de pertenencia en cada una de las cuatro entradas y cinco funciones de
pertenencia en la salida. En cada iteracion, el algoritmo toma el genoma de cada individuo,
construye el sistema difuso y, a partir de una base de datos de entrenamiento, produce la sa-
lida. Posteriormente, la diferencia entre esta salida y la de la base de datos de entrenamiento,
es cuantificada a traves de la funcion objetivo.
8.3.3. Funcion objetivo
En este tipo de algoritmos, es mas usual llamar a la funcion objetivo como funcion fitness, ff .
Es necesario ejecutar el algoritmo una gran cantidad de veces para determinar una funcion
fitness que sea apropiada para el problema. Su importancia en el proceso es inestimable, si
la funcion fitness no es apropiada, el algoritmo nunca va a encontrar una buena solucion. De
esta manera, la funcion propuesta se ha construido a partir del comportamiento del problema
para un numero muy extenso de experimentos, se presenta como una definicion a-posteriori.
La medida utilizada es el RMSE expuesta en 8-25. Se consideran varias otras medidas, pero
se elige RMSE porque el objetivo no es mejorar la dinamica en el tiempo del threshold, sino
8.3 Algoritmo genetico para ajuste de conjuntos de pertenencia 61
el valor que este toma punto a punto, de hecho, no hay dependencia en el tiempo en este
problema (el valor umbral anterior no tiene efecto en el siguiente).
RMSE =
√∑Ni=1 (y′i − yi)
N(8-25)
Donde, N es el numero de valores de salida, y′ es la salida del sistema difuso y y la salida
en la base de datos.
Se agregan dos penalidades al RMSE en la funcion fitness. En primer lugar (8-26), para
asegurar que se mantenga la coherencia con el universo de resultados propuesto, de tal
manera que cada valor producido del threshold se encuentre en dicho universo, ası, el RMSE
se escala en un factor de 2 por cada valor que no cumple la restriccion. Segundo (8-27), para
mantener la interpretabilidad de las funciones de pertenencia de cada variable (por ejemplo,
”bajo.esta siempre a la izquierda de ”medio”), el parametro Dk debe ser menor que el Dk+1,
si no ocurre en las entradas, El RMSE se escala en un factor de 2 y, en las salidas, en un
factor de 8. El factor de escala es mayor en el umbral porque, como tiene mas funciones de
pertenencia, una gran cantidad de individuos presento este problema.
ff =
{RMSE si, 0.45 < y′ < 0.745
RMSE ∗ 2t otros(8-26)
Donde t es el numero de veces que la condicion relacionada es violada.
ff =
{RMSE si,Mi,1 < ... < Mpi,i
RMSE ∗ 2r otros(8-27)
Donde r es la cantidad de entradas donde se ha violado la condicion relacionada. En el caso
de salida, 2 se cambia por 8 y los parametros evaluados son Dk,y.
9 Implementacion del gateway
9.1. Integracion sistema difuso para modificacion del
umbral en el receptor de IEEE802.11a/g/p
En la implementacion, la tarea asociada al umbral de procesamiento se realiza en la capa
fısica, es decir el flujograma WiFi PHY hier. Dentro de dicho flujograma, el bloque que se
encarga de la deteccion de la trama es WiFi Sync Short. El primer paso para la integracion
del sistema difuso, es adecuar el bloque Wifi Sync Short para que reciba el umbral por una
nueva entrada y, agregar una salida para verificar que este ha sido modificado. Posteriormente
se debe construir un bloque adicional para que envıe las entradas necesarias al bloque del
sistema difuso. Finalmente, se debe crear el bloque para el sistema difuso con las entradas
provenientes de los anterior bloques y la salida conectada a el bloque Wifi Sync Short.
9.1.1. Bloque WiFi Sync Short
El bloque WiFi Sync Short se muestra en la figura 9-1. Este cuenta con 3 entradas, dos de
tipo complejo y una de tipo float, y, una salida de tipo complejo. Su funcion se resume a la
de un grifo. Transporta la entrada a la salida solo cuando considera que ha comenzado una
trama IEEE 802.11a/g/p.
Figura 9-1: Bloque WiFi Sync Short modificado
Se ha decidido transportar el umbral por medio del tipo de dato PMT, por lo que en primer
lugar, se agrega al caparazon del bloque una entrada y una salida del tipo de dato men-
cionado. Para esto, se debe modificar el archivo xml asociado (ieee802 11 sync shortxml)
agregando un item a sink (entrada) y otro a source (salida). Para poder realizar pruebas
antes de construir todo el flujograma necesario, se asignan las dos entradas como conexiones
opcionales de tipo mensaje.
9.1 Integracion sistema difuso para modificacion del umbral en el receptor deIEEE802.11a/g/p 63
<sink>// Entrada
<name>in_threshold</name>
<type>message</type>//Tipo PMT
<optional>1</optional>
</sink>
<source>// Sa l ida
<name>out_threshold</name>
<type>message</type>//Tipo PMT
<optional>1</optional>
</source>
De esta manera, el bloque se modifica al mostrado en la figura 9-2.
Figura 9-2: Bloque WiFi Sync Short modificado.
En el bloque mostrado en la figura 9-2, el umbral esta definido como un parametro, es decir,
este debe ser establecido previamente en la configuracion del bloque. Ahora, el umbral es una
entrada, por lo que se debe quitar el parametro de la definicion en la clase sync short. Por
consiguiente, se debe modificar el constructor y todas las declaraciones y funciones asociadas.
De igual manera eliminarlo en el archivo xml. A continuacion se muestra la nueva declaracion
ingresada para la clase sync short.
c l a s s IEEE802_11_API sync_short : v i r t u a l pub l i c block
{pub l i c :
s t a t i c sptr make ( unsigned i n t min_plateau , bool log = f a l s e , bool debug = f a l s e ) ;
} ;
Con lo anterior realizado, ya se cuenta con la pre-configuracion necesaria para introducir la
logica en el bloque. Las entradas y salidas de tipo PMT, no son declaradas en la definicion
del bloque heredada por el constructor como los demas tipos de entradas. Para estas, se
debe registrar un puerto de mensaje de entrada o de salida. Esto se debe realizar dentro
del constructor de la clase. A cada puerto se le asigna un indicador que tambien es de tipo
PMT. Adicionalmente, Para el puerto de entrada se debe declarar una funcion que se encarga
de manejar los requerimientos de mensajes que otros bloques pongan en la entrada. Dicha
funcion se ejecuta cada vez que al bloque WiFi sync short le llega un mensaje a la entrada
in threshold. Esto se expone en las siguientes lineas de codigo.
64 9 Implementacion del gateway
message_port_register_out ( pmt : : mp ( ” ou t th r e sho ld ” ) ) ; //Se con f i gu ra una s a l i d a t ipo PMT
message_port_register_in ( pmt : : mp ( ” i n t h r e s h o l d ” ) ) ; //Se con f i gu ra una entrada t ipo PMT
set_msg_handler ( pmt : : mp ( ” i n t h r e s h o l d ” ) , boost : : bind(&sync_short_impl : : set_msg , th i s , _1 ) )←↩; //Se d e f i n e l a o func in r e sponsab l e de manejar l o s r eque r im iento s en l a entrada .
Como se menciono en el principio del inciso, el tipo de dato para la entrada y la salida, es
decir, en el que se transporta el umbral de un bloque a otro es PMT. Pero el tipo de dato
que se transporta, es decir del umbral, es double. Ası, a la variable local threshold de tipo
double se le debe asociar la variable double extraıda de la pareja que contiene el mensaje
tipo PMT (car y cdr). En este caso se toma con pmt::cdr(msg) el segundo elemento de dicha
pareja, que corresponde al umbral. Ademas, se debe validar que dicho dato sea un numero
real positivo. Todo esto se realiza en las siguientes lineas de codigo, que son introducidas
como un metodo publico en la clase sync short.
void set_msg ( pmt : : pmt_t msg ) {
d_msg= pmt : : cdr ( msg ) ; //Se toma e l segundo elemento de l a pare ja .
dout << ”Nueva l e c t u r a : ” << d_msg << ” ninput : ” << std : : endl ; //Se n o t i f i c a l a ←↩l l e g a d a de un mensaje
i f ( pmt : : is_integer ( d_msg ) ) {d_threshold =(double ) pmt : : to_long ( d_msg ) ; //Se va l i da que sea entero .
} e l s e i f ( pmt : : is_real ( d_msg ) ) {\Si no es entero , se valida que sea real
d_threshold = pmt : : to_double ( d_msg ) ;
} e l s e {// S i no , se lanza un e r r o r
std : : runtime_error ( ” expected a r e a l in double format ! ” ) ;
}
Adicionalmente, se anade una funcionalidad al bloque a partir de la posibilidad de que ocurra
el siguiente caso: Supongase que las variables de entrada presentan un entorno propicio para
que el sistema difuso establezca un valor del conjunto “Muy exigente”. Si de repente el SNR,
por alguna razon que se sale del control de la implementacion, varia bruscamente de un valor
en el conjunto “Alto” a uno en el conjunto “Bajo”, la siguiente trama a la ultima recibida,
probablemente no arribara porque el threshold es demasiado alto para las nuevas condiciones
del entorno. Sin embargo, el sistema difuso no sera capaz de modificar el threshold al nuevo
valor requerido, porque como el cambio fue tan brusco, no hubo una trama que arribase en
un valor de SNR mas bajo que el ulltimo calculado, por lo que para el sistema difuso el
SNR actual sigue siendo el de la ultima trama que recibio y de esta manera no se recibiran
tramas hasta que el SNR no vuelva a un valor al menos del conjunto “Medio”. Lo anterior es
producto de la problematica de que el calculo del SNR se realiza solo para tramas recibidas,
por lo que si en algun punto se dejan de recibir tramas el sistema difuso no tiene la capacidad
de decidir. Para solucionar esto se consideran dos opciones. La primera es calcular el SNR en
el dominio del tiempo a la salida del bloque USRP Source, pero dadas las caracterısticas de
la senal, al implementar un bloque para realizarlo, el SNR no representa una relacion de la
calidad de la constelacion sino de la potencia de recepcion, lo cual no aporta informacion al
9.1 Integracion sistema difuso para modificacion del umbral en el receptor deIEEE802.11a/g/p 65
sistema. De esta manera, se debe ejecutar la segunda opcion, que se implementa a traves de
las siguientes lıneas de codigo dentro del caso Search de la funcion general work del bloque
descrito en este inciso.
f o r ( i = 0 ; i < ninput ; i++) {// Muestras r e c i b i d a s
i f ( in_cor [ i ] > d_threshold ) {// Muestras que superan e l th r e sho ld
i f ( d_plateau < MIN_PLATEAU ) {// Contador muestras con s e cu t i va s que superan ←↩th r e sho ld
d_plateau++;
} e l s e {//Se completa e l ımnimo que superan e l th r e sho ld
reject=0;\\Se asigna muestras rechazadas consecutivas en cero .
d_state = COPY ;
. . .
break ;
}} e l s e {// Muestras que no superan e l th r e sho ld
i f ( in_cor [ i ] > 0 . 5 ) {\\Se cuentan cuantas consecutivas superaban a 0 .5
reject++;
}d_plateau = 0 ;
}i f ( reject>10∗MIN_PLATEAU ) {\\Si se rechaza el inicio de 10 tramas
d_threshold =0.5; //Se e s t a b l e c e un th re sho ld bajo para que pase una trama
}}
La modificacion introducida a la funcion general work gira entorno a la variable reject. Esta
variable tiene como objetivo contar cuantas muestras consecutivas son rechazadas por el
actual threshold, que hubieran sido aceptadas por uno mas bajo. De esta manera cuando
esta cantidad llegue a 10 veces la requerida para aceptar una trama, se modifica el valor del
threshold para que se permita el paso de la siguiente trama en arribar. Ası, a partir de la
trama que se permite pasar, los valores de SNR y FER son actualizados en el sistema difuso
y este puede decidir un valor del threshold que satisfaga las nuevas condiciones. Ademas,
para evitar que simplemente se deje pasar 1 de cada 10 tramas que no supera el threshold
actual, lo cual irıa en contra del objetivo de la implementacion del sistema difuso, se anade
la siguiente condicion que hacen esta funcionalidad estrictamente selectiva. Esta consiste en
que las 10*MIN PLATEAU muestras deben ser consecutivas, es decir que si por ejemplo
la cuenta esta cercana a 8*MIN PLATEAU y el bloque acepta una muestra, no una trama
sino una muestra de las MIN PLATEAU requeridas, la cuenta se reinicia. Puesto que si el
deterioro de la senal es causa de un SNR bajo no es usual que unas tramas lleguen bien y
otras mal.
Finalmente, se agrega la linea para reproducir el mensaje a la salida out threshold del bloque.
Esta salida tiene como finalidad comprobar que efectivamente le haya llegado al bloque el
umbral y este lo haya procesado. Esta declaracion se ingresa en el metodo set msg. Ası, el
bloque recibe el nuevo valor, lo asigna y luego notifica el valor con el que ha realizado la
accion. El mensaje a la salida esta compuesto por una pareja de tipo MPT, esto se realiza
66 9 Implementacion del gateway
con pmt::cons(x,y), donde el primer parametro es una etiqueta vacıa, aunque se podrıa poner
un nombre sin problema y el segundo es el valor del umbral.
message_port_pub ( pmt : : mp ( ” ou t th r e sho ld ” ) , pmt : : cons ( pmt : : PMT_NIL , pmt : : from_double (←↩d_threshold ) ) ) ;
9.1.2. Bloque WiFi Threshold Generator
El bloque WiFi Threshold Generator representa el cerebro de la implementacion. En este se
incluye la ejecucion computacional del sistema difuso. Se puede evidenciar en la figura 9-3.
Cuenta con tres entradas, dos de tipo PMT y una de tipo float, y, una salida de tipo PMT.
En las entradas, SNR in proviene del bloque WiFi Message Handler donde se produce una
valor del SNR cada vez que arriba una trama, FER in proviene del bloque Parse MAC que
al igual que la anterior, produce un valor cuando arriba una trama, y, Power in que proviene
del bloque WiFi Rx PHY y se encarga de entregar la potencia promedio. Por parte de las
salidas, threshold out se dirige al bloque WiFi Sync Short y transporta los valores de las
cuatro variables de entrada al sistema difuso y del threshold.
Figura 9-3: Bloque WiFi Threshold Generator: En este bloque se introduce el sistema de
inferencia difuso disenado.
Este bloque, a diferencia de todos los demas presentados en el libro, se desarrolla en lenguaje
Python debido a las funciones que se requieren para implementar el sistema difuso. Como
se puede evidenciar en la figura 9-3, el bloque cuenta con tres parametros de entrada. El
primero, Threshold, corresponde al valor inicial que se configura para el threshold, el segun-
do permite visualizar en consola generalidades de la implementacion y el tercero, Rx gain
representa la cuarta entrada del sistema de inferencia difuso. Como esta variable se modi-
fica mediante un QT GUI Range, es decir, es una variable del flujograma, no se considera
apropiado incluirla como una entrada, puesto que se deberıa agregar a un bloque generador
de constantes, sino como un parametro.
En el bloque, ademas del constructor, se incluyen cuatro metodos. El primero se encarga de
ejecutar el call back de la funcion para cambiar el valor local de la variable Rx gain cada
vez que se modifique en la interfaz grafica. Este metodo debe ir asociado a una declaracion
en el fichero .xml del bloque. El segundo corresponde a la funcion work, que en Python es el
equivalente a general work de C++, encargada de tomar los valores de la entrada Power in
9.1 Integracion sistema difuso para modificacion del umbral en el receptor deIEEE802.11a/g/p 67
y almacenarlos en la variable local d pot. Analogamente a lo descrito en los bloques creados
en C++, en Python tambien es necesario habilitar un metodo para que se encargue de las
solicitudes de mensajes en cada una de las entradas PMT. Para la primera entrada PMT,
FER in, la funcion se encarga de recuperar la variable tipo float almacenada en el cdr del
mensaje y asignarla a la variable local d FER. En el cuarto y ultimo metodo, encargado de
capturar la variable tipo float almacenada en el cdr del mensaje y asignarla a la variable local
d SNR, es ademas, donde se incluye la implementacion computacional del sistema difuso.
En las siguientes lıneas se estudia detalladamente dicha implementacion.
En primer lugar se debe instalar la librerıa pylab de la cual se usaran varias funciones en la
implementacion. Posterior a la declaracion de librerıas se introducen las variables globales.
Una muestra de estas lineas de codigo se expone a continuacion.
# Var iab l e s Globa les
y =pl . linspace ( 0 . 4 5 , 0 . 745 , num=296)
f0=pl . linspace (0 , 0 , num=296)
aux=pl . linspace (0 , 0 , num=296)
# aParmetros de l a s func i one s de pe r t enenc i a
mp1=[8.3035 , 16 .6461 , 23 . 2129 ]
dp1=[1.4856 , 3 .5105 , 1 . 2 7 8 8 ]
. . .
mp4=[0.6279 , 0 .6568 , 0 . 6 9 4 2 ]
dp4=[80.2454 , 0 .0236 , 146 . 9829 ]
mpy=[0.4854 , 0 .5020 , 0 .6185 , 0 .6861 , 0 . 7 1 2 7 ]
dpy=[183.1682 , 0 .0036 , 0 .0026 , 0 .0079 , 369 .56954 ]
Como se menciono en el capıtulo anterior, se cuenta con cuatro entradas y una salida, cu-
yas funciones de pertenencia se construyen a partir de los dos parametros, Mp y Dp. Estos
parametros estan almacenados en los arreglos mpi y dpi, donde i representa el numero de la
entrada. Para el caso de la salida, los vectores son mpy y dpy. Ası, por ejemplo para construir
la funcion de pertenencia “Medio” de la entrada SNR se utilizan los valores almacenados en
la segunda posicion de los arreglos mp1 y dp1. Ademas, se incluyen tres arreglos adicionales.
y representa el universo de salida, requerido en el calculo de la implicacion y la defusificacion,
f0 es el areglo donde se almacena el conjunto difuso de salida y aux se utiliza en el calculo
del centroide.
Dentro de la funcion, el primer paso en la implementacion del sistema difuso es recuperar los
valores de entrada en las variables correspondientes a la evidencia. La asignacion se realiza
a variables de tipo float64. Se debe recordar que la potencia media se decidio visualizar en
dB, por lo que se debe incluir el calculo en la asignacion, ademas, se divide en el numero
de muestras para las que se calculo la variable, puesto que el bloque de Moving Average no
realiza esta division. Esto se muestra en las siguientes lıneas de codigo.
# ev idenc i a
68 9 Implementacion del gateway
xp1 = self . d_SNR
xp2 = self . d_FER
xp3 = 10∗np . log10 ( self . d_pot/ 46) ;
xp4 = self . d_grx
A continuacion se debe realizar el proceso de fusificacion. Se expone como ejemplo el proceso
para la entrada SNR y la salida.
# fusificacion entrada SNR
u11=1./(1+pl . exp ( dp1 [ 0 ] ∗ ( xp1−mp1 [ 0 ] ) ) )
u12=pl . exp ((−0.5∗( xp1−mp1 [ 1 ] ) ∗∗2) / ( ( dp1 [ 1 ] ) ∗∗2) )
u13=1./(1+pl . exp ( dp1 [ 2 ] ∗ ( mp1 [2]− xp1 ) ) )
# oFusificacin salida , le pega el universo
uC1=1./(1+pl . exp ( dpy [ 0 ] ∗ ( y−mpy [ 0 ] ) ) )
uC2=pl . exp ((−0.5∗(y−mpy [ 1 ] ) ∗∗2) / ( ( dpy [ 1 ] ) ∗∗2) )
uC3=pl . exp ((−0.5∗(y−mpy [ 2 ] ) ∗∗2) / ( ( dpy [ 2 ] ) ∗∗2) )
uC4=pl . exp ((−0.5∗(y−mpy [ 3 ] ) ∗∗2) / ( ( dpy [ 3 ] ) ∗∗2) )
uC5=1./(1+pl . exp ( dpy [ 4 ] ∗ ( mpy [4]−y ) ) )
En este punto se debe tener especial cuidado en diferenciar el resultado de la fusificacion para
las entradas y para la salida. El resultado de la fusificacion para las entradas, por ejemplo
u11, es un valor puntual, un escalar, mientras que el resultado para la salida, por ejemplo
UC1 es un arreglo que tiene el mismo tamano del arreglo que define el universo de salida,
y. Lo anterior sucede porque en las entradas se mapea los escalares correspondientes a la
evidencia, mientras que en la salida se mapea el universo.
Despues de realizar la fusificacion se calculan los antecedentes y consecuentes. Para el caso
de los antecedentes se realiza a partir de la norma T, mınimo. El resultado se almacena en
los escalares Ari, donde i es el numero de la regla, segun lo expuesto en el capıtulo anterior.
# aClcu lo de l o s antecedentes de l a s r e g l a s T−Norma ımnimo
A1=[u11 , u31 ]#1X1X
Ar1 = min ( A1 )
A2= [ u11 , u21 , u32 ]#112X
Ar2 = min ( A2 )
. . .
A30 =[u13 , u23 , u33 ]#333X
Ar30 = min ( A30 )
Por parte de los consecuentes, el proceso es diferente, puesto que se hace a partir de los con-
juntos difusos de salida, que como se indico anteriormente, son arreglos. En el caso compu-
tacional general, los consecuentes se representan por arreglos del tamano del universo de
salida y luego se construye el conjunto difuso de salida encontrando el maximo, punto a
punto, entre dichos arreglos, generando un arreglo del mismo tamano. Para reducir costo
computacional los consecuentes se almacenan punto a punto en el escalar ri, donde i repre-
senta el numero de la regla, y, se calcula a partir de estos escalares, el punto correspondiente
al conjunto difuso de salida. Este proceso se incluye en una rutina for para evaluar todos los
9.2 integracion IEEE 802.11 e IEEE 802.15.4 69
puntos del universo de salida.
# aClculo de la oimplicacin Mamdani para todas las reglas
f o r i in range (296) :
r1 = min ( Ar1 , uC1 [ i ] )
r2 = min ( Ar2 , uC2 [ i ] )
. . .
r30= min ( Ar30 , uC3 [ i ] )
# oConstruccin del conjunto difuso de salida f0 .
f0 [ i ]=max ( r1 , r2 , . . . , r30 )
aux [ i ]=y [ i ]∗ f0 [ i ]
Finalmente, con el conjunto difuso de salida construido, se debe implementar la defusifica-
cion, que consiste en la busqueda del centroide del conjunto Esto se realiza a partir de las,
previamente expuestas, variables aux y f0. EL resultado se encuentra en formato float64
por lo que se convierte a float antes de asignarlo a la variable threshold.
aux2=sum ( aux ) /sum ( f0 )
9.2. integracion IEEE 802.11 e IEEE 802.15.4
El gateway definido por software tiene el objetivo de lograr la interoperabilidad entre IEEE
802.11a/g/p y IEEE802.15.4/Zigbee 2006. De esta manera, un mensaje enviado desde un
nodo configurado con el primer estandar, debe arribar en el segundo, configurado con el
segundo estandar, y, viceversa. Para la implementacion de dicho dispositivo, el primer paso
es integrar los transceptores expuestos en el capıtulo 7, en un unico flujograma. En este caso,
el siguiente diagrama de bloques explica el producto esperado.
Figura 9-4: Diagrama general para el gateway
70 9 Implementacion del gateway
Como se muestra en la figura 9-4, existen dos flujos de informacion. Uno que provine del
transmisor del nodo IEEE802.11a/g/p y finaliza en el receptor del nodo IEEE802.15.4/Zigbee
2006 , y, otro que proviene del transmisor del segundo y arriba en el receptor del primero. De
esta manera, se logran comunicar dos nodos configurados con diferentes protocolos a traves
de un Gateway definido por software. Para realizar la implementacion sobre GNURadio al
diagrama anterior se le deben agregar bloques o funcionalidades que permitan ejercer control
o tomar decisiones sobre los siguientes aspectos:
Control de parametros para la interfaz de entrada y salida de la USRP N210: Puesto
que los dos protocolos operan con diferentes frecuencias de muestreo y canales de
comunicacion, es necesario que un bloque se encargue de configurar la USRP N210
para transmitir o recibir bajo los parametros de determinado protocolo. Ası pues, se
debe incluir una logica que permita determinar, cuando se escucha a un nodo u otro.
De esta manera, los parametros de configuracion deberan ingresarse por el puerto de
comandos de los bloques USRP Sink y USRP Source.
Conflicto de recursos en el transmisor de la USRP N210: Debido a la construccion del
bloque USRP Sink, no es posible conectar dos fuentes a su entrada. Ası pues, se debe
construir un bloque al cual se conecten los transmisores de los dos transceptores y que
dependiendo de un parametro que establezca el nodo de destino del mensaje, transporte
a su salida alguna de las dos entradas. Ademas, teniendo en cuenta, que la frecuencia
de operacion y frecuencia de muestreo asociadas a cada nodo son diferentes, se deben
modificar estas variables en el bloque, a disposicion del parametro mencionado.
Conflicto de recursos en el receptor de la USRP N210: En el caso del receptor, si es
posible conectar dos sumideros a su salida, por lo que el problema se resume a modificar
la frecuencia de operacion y frecuencia de muestreo asociadas a cada nodo. Es de tener
en cuenta, que siempre estos parametros seran diferentes para los bloques USRP Sink
y USRP Source puesto que en los dos flujos de informacion, un estandar es asignado a
recepcion y el otro a transmision.
Administrador de mensajes enviados desde el transmisor de IEEE802.11a/g/p hacia
el receptor IEEE802.15.4/Zigbee 2006: El bloque WiFi MAC que entrega el mensaje
recibido por el transceptor, no lo entrega en un formato que sea admitido por la entrada
del bloque Tx App Xbee, por lo que se debe leer el mensaje, almacenado en una variable
tipo BLOB y transportado en el cdr de un tipo de dato PMT y entregarselo al bloque Tx
App Xbee en el mismo tipo de dato PMT, pero sin contener una pareja, sino unicamente
una variable tipo STRING con el mensaje requerido. Ademas, desde este bloque se
pueden agregar funcionalidades para realizar acciones dependiendo el mensaje que sea
procesado, tales como cambiar de canal, aumentar frecuencia de muestreo, entre otros.
Administrador de mensajes enviados desde el transmisor de IEEE802.15.4/Zigbee 2006
hacia el receptor IEEE802.11a/g/p: De igual manera ocurre en el caso del segundo flujo
9.2 integracion IEEE 802.11 e IEEE 802.15.4 71
de informacion. Al igual que el bloque Tx App Xbee, la entrada del mensaje en WiFi
MAC solo admite una variable tipo STRING dentro del tipo de dato PMT, por lo que
se debe realizar una modificacion similar, teniendo en cuenta las particularidades del
mensaje entregado por Rx App Xbee, que difiere en formato y presentacion al entregado
por WiFi MAC, por lo que es util construir dos bloques diferentes y no solo usar el
mismo codigo. De igual manera, en este bloque se pueden agregar las funcionalidades
mencionadas para el anterior, pero asociadas a las necesidades de Zigbee.
A partir de lo expuesto anteriormente, se propone el diagrama del transceptor de la figura
9-5. En este solamente se incluye el posicionamiento representativo de los bloques que se
deben agregar. Por lo tanto, las conexiones que estos conllevan y configuracion, se trataran
en una seccion destinada a esto.
Figura 9-5: Diagrama para el gateway con bloques de control
9.2.1. Bloque WiFi Message Handler
El primer bloque que se agrega es el administrador de mensajes para realizar el paso de el
receptor WiFi al transmisor Zigbee. Se puede evidenciar en la figura 9-6. Cuenta con una
entrada y tres salidas, todas de tipo PMT. La entrada app in proviene de la subcapa MAC
del receptor WiFi, la salida message out se dirige a la capa de aplicacion del estandar Zigbee,
control out se dirige al bloque de control de la USRP y SNR out esta conectada a la entrada
del bloque para modificar el umbral en el bloque WiFi Sync Short.
Este bloque se incluye en la clase IEEE802 11 API. Se le agregan dos parametros de tipo
boolean. El primero, log, permite que se active el reconocimiento de palabras reservadas para
anadir funcionalidades al gateway, el segundo, debug activa los mensajes en consola por parte
de las funciones asociadas al bloque. La declaracion del bloque se muestra a continuacion.
c l a s s IEEE802_11_API message_handler : v i r t u a l pub l i c block{pub l i c :
72 9 Implementacion del gateway
Figura 9-6: Bloque Wifi Message Handler: Se encarga de administrar los mensajes genera-
dos por la subcapa MAC de IEEE 802.11a/g/p
typede f boost : : shared_ptr<message_handler> sptr ;
s t a t i c sptr make ( bool log = f a l s e , bool debug = f a l s e ) ;
} ;
Para disenar la logica que se encarga del procesamiento del mensaje en el puerto de entrada,
se debe analizar el formato y contenido del mensaje que entrega el bloque WiFi MAC. Al
consultar la documentacion del bloque y los ficheros en C++ donde se declara la clase y
sus funciones, no es claro el formato del mensaje puesto que solo se evidencia el recorte de
una parte de este, por lo que se propone una prueba a partir de un flujograma en el que se
genera un mensaje de prueba y se conecta un bloque Message Debug a dicha salida, para
ver el mensaje que es esta enviando en consola y a partir de este, interpretar el codigo del
bloque. El resultado obtenido es:
( ( ( dlt . 1 0 5 ) ( freqofs .−0.0015) ( nomfreq . 5 . 8 9 e+09) ( snr . 1 4 4 . 9 8 5 ) ( encoding . 0 ) ) . #[PRUEBA ] )
Es claro que el formato en el que se transporta el mensaje es PMT por el color del puerto del
bloque. A partir de la salida expuesta anteriormente, se puede evidenciar que el PMT es una
pareja, es decir, cuenta con car y cdr, pero la construccion de las parejas no es la usual, en la
que se crea un diccionario y se agregan todas las parejas. Ademas, en la salida no solamente
se entrega el mensaje, sino parametros caracterısticos de la comunicacion. Para este caso
cada parametro esta compuesto por una pareja, el cdr corresponde al nombre y el car al
valor, y, estos a su vez, se agrupan en un diccionario que viaja en el car del dato PMT. El
mensaje viaja en el cdr del dato PMT. A partir del codigo del bloque se puede comprobar
que los caracteres #[] indican que el mensaje es de tipo BLOB. De esta manera, en lo que
concierne a la recuperacion del mensaje, se debe tomar el cdr del dato PMT, extraer la in-
formacion, realizar la conversion a formato String, que corresponde al formato que reconoce
la entrada de la capa de aplicacion del transmisor de Zigbee y publicar en el puerto de salida.
El primer paso corresponde a la verificacion del formato de entrada. Debido a que la logica
se construye para tratar un mensaje de las caracterısticas mencionadas anteriormente, se
debe realizar dicha confirmacion. Las siguientes lıneas exponen este proceso. En caso de que
el formato no se cumpla, se lanza un error y se detiene la aplicacion.
i f ( pmt : : is_pair ( msg ) ) {// Debe s e r una pare ja
9.2 integracion IEEE 802.11 e IEEE 802.15.4 73
i f ( ! pmt : : is_blob ( pmt : : cdr ( msg ) ) ) {// El cdr de l a pare ja debe s e r BLOB
throw std : : runtime_error ( ”PMT must be blob ” ) ;
} e l s e {std : : cout << ”The cdr i s BLOB” << std : : endl ;
}} e l s e {//Se lanza e l e r r o r
throw std : : invalid_argument ( ” I t expect s a pa i r ” ) ;
r e turn ;
}
Realizada la verificacion del formato del dato PMT, es momento de realizar las acciones
propuestas. El primer contratiempo se presenta a causa de que la conversion de un dato
de tipo BLOB a uno de tipo String no es posible porque los datos no son compatibles,
no existe una funcion para realizarlo. Para solucionarlo se debe proceder a realizar una
re-interpretacion del dato de BLOB a char y luego de char a String. En este proceso se
toman los caracteres vistos a traves del bloque Message Debug en el experimento propuesto
anteriormente, por supuesto no es evitable, pero al finalizar la tarea es posible anadir una
excepcion para que sean eliminados dichos caracteres a partir del tamano en bytes del dato
en tipo BLOB. De esta manera es posible obtener el mensaje en una variable de tipo String.
Las siguientes lıneas exponen dicho proceso.
unsigned char buf [ 100 ]={0} ; //Crea buf , donde l o s bytes van a s e r almacenados .
//Toma e l ntamao en bytes de l mensaje t i po BLOB. Este se encuentra en e l cdr .
size_t cont=pmt : : blob_length ( pmt : : cdr ( msg ) ) ;
// Rea l i za l a o r e i n t e r p r e t a c i n
std : : memcpy ( buf , pmt : : blob_data ( pmt : : cdr ( msg ) ) , cont ) ;
std : : string aux2 ( r e i n t e r p r e t c a s t <char∗>(buf ) ) ;
// S i por causa de l a o convers in , aparecen ams datos , e s t o s son borrados .
i f ( aux2 . size ( )>cont ) {aux2 . erase ( cont , 2 ) ; }
Por otro lado, en la construccion del sistema difuso para la modificacion del umbral, se pro-
pone utilizar como entrada a la relacion senal a ruido (SNR). Puesto que dicha variable esta
incluida dentro de los parametros que entrega el bloque WiFi MAC, se considera apropiado
procesar el dato dentro del bloque WiFi Message Handler y enviarlo al bloque en el que
se implementa el sistema difuso. Para esto se debe rescatar el diccionario almacenado en el
car y obtener el valor asociado a la etiqueta snr, tal como se evidencio en el experimento
propuesto anteriormente. Esta tarea se realiza con las siguientes lıneas de codigo.
//ıEnva SNR, e l cua l a e s t en e l d i c c i o n a r i o almacenado en e l car .
pmt : : pmt_t snrf =pmt : : dict_ref ( pmt : : car ( msg ) , pmt : : mp ( ” snr ” ) , pmt : : from_double (10)←↩) ;
message_port_pub ( pmt : : mp ( ”SNR out ” ) , snrf ) ;
Finalmente, se anade dentro de la funcion encargada de transportar el mensaje, condiciones
para tratar mensajes de control, a partir de frases reservadas para la configuracion del gate-
way. En este caso, como solo se esta usando una interfaz para recibir y otra para transmitir,
es necesario determinar el estandar en el que se desea recibir y enviar el mensaje. Sobre
74 9 Implementacion del gateway
esto se profundizara en una sub-seccion separada, por el momento es importante resaltar
que como solo se puede escuchar a uno de los dos nodos al tiempo, cuando este nodo ya no
quiera ser escuchado debe enviar el mensaje ”fin” y de esta manera, se escuchara al otro
nodo. De esta manera, cuando el mensaje sea una palabra reservada, no se publica en la
salida message out sino en control out. Esto se realiza con las siguientes lıneas de codigo.
i f ( aux2==” f i n ” ) {//The PMT message i s pub l i shed .
message_port_pub ( pmt : : mp ( ” c o n t r o l out ” ) , snrf2 ) ;
} e l s e {//The PMT message i s pub l i shed .
message_port_pub ( pmt : : mp ( ”message out ” ) , snrf2 ) ;
}
9.2.2. Bloque Zigbee Message Handler
Este bloque es ampliamente similar al expuesto anteriormente. En este caso, corresponde al
administrador de mensajes para realizar el paso de el receptor Zigbee al transmisor WiFi.
Se puede evidenciar en la figura 9-7. Cuenta con una entrada y dos salidas, todas de tipo
PMT. La entrada app in proviene de la capa de aplicacion del receptor Zigbee, la salida
message out se dirige a la subcapa MAC del estandar WiFi y control out se dirige al bloque
de control de la USRP.
Figura 9-7: Bloque Zigbee Message Handler: Se encarga de administrar los mensajes gene-
rados por la capa de aplicacion de Zigbee
Al igual que el anterior, se incluye en la clase IEEE802 11 API con los dos mismos parame-
tros, asociados a un par de tareas iguales, por lo que en la declaracion solo varia el nombre del
bloque. La necesidad de su construccion se remonta a la diferencia del mensaje de entrada,
por lo que no se puede simplemente usar el mismo bloque para administrar los mensajes de
ambos estandares, y si se hiciera, deberıa tener el doble de entradas y salidas, por lo que se
considera mas conveniente construirlos por separado.
A diferencia de la salida del bloque WiFi MAC, la del bloque Rx App Xbee, solo transporta
el mensaje, y lo transporta en el cdr del dato PMT, por lo que lo unico que difiere con el
proceso del bloque anterior es la obtencion de la variable de tipo BLOB. De igual manera,
los mensajes reservados para acciones de control son iguales que los expuestos en el bloque
anterior.
9.2 integracion IEEE 802.11 e IEEE 802.15.4 75
9.2.3. Bloque WiFi USRP Control
Este bloque es el responsable de configurar los parametros en USRP Sink y USRP Source, a
partir de los mensajes de configuracion que envıen WiFi Message Handler y Zigbee Message
Handler y, controlar el comportamiento de Tx Switch y Rx Switch. Se puede evidenciar en
la figura 9-8. Cuenta con dos entradas y tres salidas, todas de tipo PMT. La entrada from
WiFi Handler proviene de la salida de mensajes de comandos del bloque WiFi Message
Handler, from Zigbee Handler de la misma salida pero del bloque Zigbee Message Handler.
Por parte de las salidas, To Rx USRP se dirige al puerto de configuracion por mensajes de
USRP Source, To Tx USRP se dirige al puerto de configuracion por mensajes de USRP Sink
y To Switch esta conectada a la los bloques Tx Switch y Rx Switch.
Figura 9-8: Bloque USRP Control: Se encarga de enviar los comandos de configuracion a
las interfaces de la USRP N210.
Este bloque se incluye en la clase IEEE802 11 API. Se le agregan los dos parametros de
tipo boolean, para realizar las mismas tareas descritas en los dos bloques anteriores. Ademas
se agregan cuatro parametros de tipo double. Puesto que este bloque es quien reconfigura
la USRP, se le debe informar las frecuencias centrales y tasas de muestreo a las que se
configuran los nodos WiFi y Zigbee, accion realizada a traves de estos cuatro parametros.
La declaracion del bloque se muestra a continuacion.
c l a s s IEEE802_11_API USRP_control : v i r t u a l pub l i c block{pub l i c :
typede f boost : : shared_ptr<USRP_control> sptr ;
s t a t i c sptr make ( bool log , bool debug , double wfreq , double zfreq , double wrate , ←↩double zrate ) ;
} ;
Las dos entradas, por ser de tipo PMT, deben contar con una funcion encargada de manejar
los requerimientos de mensajes en el puerto. Por lo tanto, como cada entrada proviene de
uno de los dos receptores (WiFi o Zigbee), cada funcion es responsable de administrar los
mensajes de un receptor, es decir, si se invoca la primera funcion, solo se tratan ordenes aso-
ciadas a Zigbee y en el caso contrario, solo asociadas a WiFi. El contenido de las funciones
se expone a continuacion.
La funcion para tratar los mensajes de control provenientes del bloque Wifi Message Handler
se denomina from wifi. En caso de que esta se active y el mensaje de control enviado por el
76 9 Implementacion del gateway
bloques sea “fin” debe realizar tres acciones basicas. La primera es configurar el receptor para
escuchar al nodo Zigbee, puesto que el nodo WiFi ha declarado que no enviara mas mensajes
y puede ceder la interfaz. La segunda es configurar el transmisor para enviar mensajes al nodo
WiFi, puesto que ahora este sera el nodo que receptor. Para realizar las dos primeras tareas
se envıa un mensaje comando al bloque USRP Source. Este mensaje debe ser estrictamente
una pareja en la cual el car es la palabra reservada para el parametro que se desea modificar
y el cdr el valor de este parametro en el tipo de dato de la variable a modificar. En el
caso de la primera tarea, la frecuencia deseada para el estandar Zigbee ha sido almacenada
en la variable d zfreq y equivalentemente la tasa de muestreo en d zrate entonces como
se desea configurar el receptor de la USRP para recibir datos del nodo Zigbee, se envıan
dichos parametros a la salida To Rx USRP. De igual manera ocurre en la configuracion del
transmisor, pero esta vez con los valores asociados a WiFi y hacia la salida To Tx USRP. La
tercera tarea, esta asociada al cambio del camino que sigue la senal que envıa USRP Source
y la eleccion de la senal que se entrega a USRP Sink. Para facilitar la tarea, se opera a traves
de una variable de tipo boolean, donde, un valor True indica que el receptor es WiFi y el
transmisor Zigbee, y, un valor False el caso contrario. Las principales declaraciones de esta
funcion se evidencian a continuacion.
//Rx : Zigbee
message_port_pub ( pmt : : mp ( ”To Rx USRP” ) , pmt : : cons ( pmt : : intern ( ” f r e q ” ) , pmt : :←↩from_double ( d_zfreq ) ) ) ; // Frequency to 1 .4 GHz
message_port_pub ( pmt : : mp ( ”To Rx USRP” ) , pmt : : cons ( pmt : : intern ( ” ra t e ” ) , pmt : :←↩from_double ( d_zrate ) ) ) ; //Sample ra t e to 4 MHz
//Tx : WiFi
message_port_pub ( pmt : : mp ( ”To Tx USRP” ) , pmt : : cons ( pmt : : intern ( ” f r e q ” ) , pmt : :←↩from_double ( d_wfreq ) ) ) ; // Frequency to 2 .472 GHz
message_port_pub ( pmt : : mp ( ”To Tx USRP” ) , pmt : : cons ( pmt : : intern ( ” ra t e ” ) , pmt : :←↩from_double ( d_wrate ) ) ) ; //Sample ra t e to 4 MHz
// Switch input and output from USRP
message_port_pub ( pmt : : mp ( ”To Switch ” ) , pmt : : PMT_F ) ;
La misma logica se extiende para tratar el comando ”fin” proveniente del bloque Zigbee
Message Handler a traves de la funcion from zigbee. En este caso al receptor se le asigna
WiFi y al transmisor Zigbee.
9.2.4. Bloque WiFi Tx Switch
La funcion de este bloque es elegir cual de la senales, provenientes de los transmisores de
Zigbee y WiFi, debe ser entregada al transmisor de la USRP. Se puede evidenciar en la figura
9-9. Cuenta con tres entradas, dos de tipo complejo y una de tipo PMT ,y, una salida de
tipo complejo. En las entradas, in switch proviene de la salida to switch del bloque USRP
Control, from wifi proviene de la salida de la capa fısica de WiFi y from zigbee de la salida
de la capa fısica de Zigbee se dirige a la capa de aplicacion del estandar Zigbee. Por parte
de las salidas, to USRP se dirige al bloque USRP Sink.
9.2 integracion IEEE 802.11 e IEEE 802.15.4 77
Figura 9-9: Bloque Tx Switch: Se encarga de entregar al transmisor de la USRP N210
la salida correspondiente al estandar con el que esta configurado el nodo de
destino.
Este bloque se incluye en la clase IEEE802 11 API. Se le agrega un parametro de tipo
int que permite seleccionar el estandar que es escuchado al comenzar la comunicacion. La
declaracion del bloque se muestra a continuacion.
c l a s s IEEE802_11_API tx_switch : v i r t u a l pub l i c block{pub l i c :
typede f boost : : shared_ptr<tx_switch> sptr ;
s t a t i c sptr make ( i n t ini_st ) ;
} ;
La logica del manejo de las entradas que no son de tipo PMT difiere notablemente a la
expuesta en los bloques anteriores. Si se realiza una revision hacia atras, es el primer bloque
en el que es incluyen entradas que no son de tipo PMT.
En primer lugar, hay una unica funcion para manejar todas las entradas, que no son de
tipo PMT, denominada work o general work. Esta funcion se invoca cada vez que hay un
numero determinado de muestras en los buffers de entrada. Con lo anterior hay dos aspectos
importantes que deben ser tenidos en cuenta. El primero es que la funcion no se invoca cada
vez que arriba una muestra, sino que lo hace luego de recolectar una cantidad n de muestras
en el buffer, ası que cada vez que es invocada, esta le informa al bloque cuantas muestras
hay en cada entrada y cuanto espacio tiene disponible en el buffer de salida para entregar
muestras. Ası pues, el procesamiento funciona por bloques de informacion y no muestra a
muestra. En segundo lugar, los buffer en GNURadio son circulares, es decir que por ejemplo
en un buffer de tamano 1000, si por alguna razon se escribe la posicion 1001, se estara
reescribiendo la posicion 1, perdiendo la muestra que estaba originalmente almacenada ahı.
Debido a lo anterior, nunca se deben escribir mas muestras de las que se le indica al bloque
que puede escribir. Para ilustrar lo anterior se enuncia a continuacion la declaracion de la
funcion general work
i n t general_work ( i n t noutput_items , gr_vector_int& ninput_items ,
gr_vector_const_void_star& input_items ,
gr_vector_void_star& output_items ) {\\ procesamiento de nseal
consume_each ( i ) ; // Se l e d i c e a l runtime cuantas muestras de l a s entradas se ←↩consumieron .
re turn i ; // Se l e d i c e a l runtime cuantas muestras se pus i e ron en l a s s a l i d a s .
78 9 Implementacion del gateway
}
La funcion mostrada tiene el argumento de entrada noutput items de tipo entero, que in-
dica cuantos espacios tiene el buffer de salida disponibles para inyectar muestras. Tiene el
vector de enteros ninput items que indica por entrada, cuantos espacios del buffer contienen
una muestra que no ha sido procesada, donde, el valor para la entrada 1 es ninput items[0]
y para la 2 ninput items[1]. El tercer argumento es un vector de vectores, es decir, una
matriz, donde se ingresan las muestras que tiene cada buffer de entrada. De esta manera,
las muestras de la entrada 1 estan en el vector input items[0] y las de la entrada 2 en el
vector input items[1]. El ultimo argumento es similar al anterior pero para los buffers de
salida. ademas de la conformacion de la funcion, es importante tener claro los argumen-
tos que esta debe retornar, estos son, consume each() en el que se indica cuantas muestras
se consumieron de la entrada y return que indica cuantas muestras se escribieron en la salida.
Ahora bien, con el contexto introducido, se expone la logica introducida en la funcion gene-
ral work. El primer paso es convertir los argumentos de entrada a variables locales. Este pro-
ceso es recomendado y estandarizado por la comunidad academica de GNURadio. Para esto
se debe seguir el siguiente formato: const Tipo dato *variable destino = (const Tipo dato*)
variable fuente;. Este proceso se realiza para las dos entradas y la salida, de tipo complejo,
como se muestra en las siguientes lıneas de codigo.
const gr_complex ∗in_wifi = ( const gr_complex ∗) input_items [ 0 ] ;
const gr_complex ∗in_zigbee = ( const gr_complex ∗) input_items [ 1 ] ;
gr_complex ∗out = ( gr_complex ∗) output_items [ 0 ] ;
La decision acerca de la entrada que debe pasar a la salida, se toma a partir del valor de
la variable d st, que se inicializa con el argumento ingresado al bloque desde el flujograma
en GNURadio. Ademas, la funcion asignada para administrar los mensajes que arriban al
puerto in switch, cambia el valor de d st dependiendo del valor de la variable tipo boolean
que transporta el dato PMT, como se muestra en las siguientes lıneas de codigo. Se debe
tener en cuenta que la variable que llega es tipo boolean, pero la variable con la que se toma
la decision es de tipo int.
i f ( standard==true )
{//Tx Zigbee , i f standard i s t rue
d_st_aux=0;
} e l s e {//Tx WiFi
d_st_aux=1;
}
Ahora, se define la variable n dependiendo del valor que tenga d st, que corresponde al
numero de muestras a procesar. Esta se calcula como el mınimo entre las disponibles en la
entrada que se vaya a transportar y las disponibles en la salida. Luego de determinar el valor
9.2 integracion IEEE 802.11 e IEEE 802.15.4 79
de n se realiza la copia de las muestras de la entrada seleccionada a la salida. Los dos casos
posibles se muestran a continuacion.
i f ( d_st==0){n= std : : min ( ninput_items [ 1 ] , noutput_items ) ;
whi l e ( i < n ) {// Copy
out [ i ] = in_zigbee [ i ] ;
i++;
}} e l s e {
n= std : : min ( ninput_items [ 0 ] , noutput_items ) ;
whi l e ( i < n ) {// Copy
out [ i ] = in_wifi [ i ] ;
i++;
}}
9.2.5. Bloque WiFi Rx Switch
Este bloque es ampliamente similar al expuesto anteriormente. En este caso, su responsabili-
dad es elegir hacia que receptor, WiFi o Zigbee, se envıa la senal proveniente del receptor de
la USRP. Se puede evidenciar en la figura 9-10. Cuenta con una entrada de tipo PMT y otra
de tipo complejo, y, con dos salidas de tipo complejo. En las entradas, in switch proviene de
la salida to switch del bloque USRP Control y from USRP proviene de la salida del bloque
USRP Source. Por parte de las salidas, to wifi se conecta a la entrada de la capa fısica de
recepcion de WiFi y to zigbee a la capa fısica de recepcion de Zigbee.
Figura 9-10: Bloque Rx Switch: Se encarga de entregar la salida del receptor de la USRP
N210 a la entrada del estandar con el que esta configurado el nodo que envio
el mensaje.
Al igual que el anterior, se incluye en la clase IEEE802 11 API con el mismo parametro
asociado a la misma tarea, por lo que en la declaracion solo varia el nombre del bloque. En
general su constitucion es similar a la del anterior bloque, solo difieren en el contenido de la
funcion general work. En este caso, se debe copiar una entrada a alguna de las dos salidas
y a la otra se enviar el complejo 0+0i para evitar errores. Ademas, la variable n ya no se
define dentro de cada caso, sino que se asigna al principio puesto que noutput items tiene un
unico valor para los dos buffers de salida. Este procedimiento se muestra en las siguientes
lıneas de codigo.
80 9 Implementacion del gateway
i n t n= std : : min ( ninput_items [ 0 ] , noutput_items ) ;
i f ( d_st==0){whi le ( i < n ) {
// Copy
out_wifi [ i ] = in [ i ] ;
out_zigbee [ i ] = gr_complex (0 , 0) ;
i++;
}} e l s e {
whi le ( i < n ) {// Copy
out_zigbee [ i ] = in [ i ] ;
out_wifi [ i ] = gr_complex (0 , 0) ;
i++;
}}
9.2.6. Modificaciones a los transceptores de IEEE 802.11a/g/p y
802.15.4
Para anadir interpretabilidad y orden al flujograma correspondiente al gateway, se considera
adecuado modificar los bloques funcionales de IEEE 802.11a/g/p para separarlos en recep-
cion y transmision. El bloque WiFi Rx PHY es una modificacion del bloque jerarquico WiFi
PHY, el flujograma en el que se declara su contenido contiene la capa fısica de IEEE 802.11a/-
g/p para recepcion, equivalentemente WiFi Tx PHY en transmision. De igual manera los
bloques WiFi Rx MAC y WiFi Tx MAC para la capa MAC en recepcion y transmision. El
resultado de los 4 bloques se puede evidenciar en la figura 9-11.
Figura 9-11: Modificaciones a bloques del transceptor IEEE802.11a/g/p.
De igual manera se realiza para IEEE 802.15.4, la diferencia es que, dado que estos ya se
encuentran divididos en recepcion y transmision, se crean flujogramas jerarquicos para el
proceso de transmision y recepcion. Los bloques asociados se describen en la figura 9-12
9.2 integracion IEEE 802.11 e IEEE 802.15.4 81
Figura 9-12: Modificaciones al flujograma de IEEE802.15.4: El bloque Rx Xbee es un blo-
que jerarquico que contiene la capa fısica, de enlace, de red y de aplicacion
para recepcion de IEEE 802.15.4/Zigbee 2006. Equivalentemente Tx Xbee
para transmision.
10 Experimentos y resultados
10.1. Sistema difuso generado por el algoritmo de
evolucion diferencial
En esta seccion se presentan los resultados correspondientes a la implementacion del algorit-
mo de evolucion diferencial para ajustar las funciones de pertenencia del sistema de inferencia
difuso. En primer lugar se introduce la metodologıa para decidir las variables con las que
ejecuta la simulacion, a continuacion, se exponen los resultados alcanzados en validacion y
entrenamiento y finalmente se presentan las funciones de pertenencia ajustadas.
10.1.1. Construccion de la base de datos de entrenamiento y
validacion
La base de datos para ejecutar el algoritmo de evolucion esta compuesta por 800 muestras
para las cuatro entradas y un valor umbral estimado. Las cuatro entradas se toman del re-
ceptor implementado para IEEE 802.11a/g/p, la mitad en un canal de congestion media y la
otra mitad en uno de congestion baja. Para estas 400 muestras, en cada caso, 40 escenarios
son considerados variando los parametros caracterısticos de la implementacion, tal y como
se hizo en la caracterizacion de las entradas. De esta manera, se recolectan 10 muestras por
escenario.
Por otro lado, para decidir el valor umbral, se consideran las siguientes dos fuentes de in-
formacion. En primer lugar, la base de datos se introduce en el sistema difuso con el primer
conjunto de funciones de pertenencia y para cada valor generado, si es posible, se propone
un valor mas cercano a los extremos del intervalo. En segundo lugar, a partir del comporta-
miento propuesto en el conjunto de reglas, los valores anteriores se ajustan a los intervalos
esperados, si no estan allı. De esta manera, el primer paso desplaza los valores y el segundo
verifica que no esten fuera del rango propuesto por medio de las reglas. Con el fin de intro-
ducir esta base de datos en el algoritmo, los datos se dividen en entrenamiento, el 75 %, y
validacion, el 25 % restante.
10.1 Sistema difuso generado por el algoritmo de evolucion diferencial 83
10.1.2. Determinacion de parametros iniciales del algoritmo
Como se menciono anteriormente, el algoritmo tiene parametros caracterısticos que deben
ser inicializados para satisfacer las necesidades caracterısticas del problema a ser evaluado.
Dichos parametros son el numero de generaciones, el tamano de la poblacion, la probabilidad
de mutacion y la probabilidad de recombinacion. Para determinar un conjunto de valores
que permita al algoritmo encontrar las mejores soluciones, se ejecuta un proceso de evolucion
para la combinacion de cada uno de los parametros mencionados en la tabla 10-1. Los valores
seleccionados se exponen en la tabla 10-1, de igual manera. El numero de generaciones y el
tamano de la poblacion se escogen como los valores maximos en los que el resultado de la
funcion fitness para el mejor individuo en la generacion k+1 es menor que el de la generacion
k, en al menos 0.1 %. Las probabilidades de mutacion y recombinacion se seleccionan a partir
de los individuos que obtuvieron los mejores resultados en la generacion final.
Tabla 10-1: Parametros para inicializar el algoritmo de evolucion diferencial
Parametro Rango Paso Valor seleccionado
Numero de generaciones 50-500 50 250
Tamano de poblacion 10-50 10 20
Probabilidad de mutacion 0.1-0.9 0.1 0.5
Probabilidad de recombinacion 0.1-0.9 0.1 0.9
Ademas, se establece la poblacion inicial, tratando de obtener funciones de pertenencia
interpretables desde el principio. De esta manera, solo se proponen individuos interpretables,
definiendo un intervalo posible donde cada parametro es elegido al azar.
10.1.3. Analisis de resultados de entrenamiento y validacion
La tabla 10-2 expone los 3 primeros de los 1000 individuos obtenidos en la generacion final
de cada experimento. Como se indico anteriormente, el criterio de seleccion es el resultado
de la funcion fitness en validacion, lo cual se propone para evaluar el sistema difuso con
datos con los que nunca ha interactuado, evitando escoger un individuo sobre-optimizado
para el conjunto de datos de entrenamiento. Dado que las dos bases de datos se seleccionan
uniformemente a traves de los diferentes escenarios, se puede evidenciar una cercanıa intere-
sante en los resultados de entrenamiento y validacion, ademas, es una razon para pensar en
el desempeno del sistema difuso como bueno. En cuanto a la magnitud de los valores, no
deben interpretarse como un RMSE porque varias penalidades se introdujeron en la funcion
fitness, por lo tanto, se puede dar el caso en que un individuo con un RMSE menor que
los expuestos (por ejemplo 0,01), haya violado las restricciones Varias veces convirtiendose
en un individuo con mal desempeno. De esta manera, los individuos superiores no solo tie-
nen los mejores resultados de validacion, sino que tambien tienen funciones de pertenencia
84 10 Experimentos y resultados
interpretables y la salida generada esta en el universo umbral.
Tabla 10-2: Resultados del algoritmo de evolucion diferencial
RankingResultado de la funcion fitness
Validacion Entrenamiento
1 0.1426 0.1225
2 0.1514 0.1188
3 0.1578 0.1361
La salida esperada en comparacion con las producidas por el sistema difuso antes y despues
del algoritmo de evolucion diferencial, se exponen en la figura 10-1. Como se puede observar,
el intervalo efectivo del umbral se ha extendido en la salida ajustada, especialmente en los
valores cercanos a los extremos del intervalo, que tienen un interes especial. De esta manera,
se ha logrado el objetivo de ajustar las funciones de pertenencia, ya que se ha ampliado el
intervalo efectivo del umbral en la mayorıa de los escenarios propuestos. Como se ha indicado,
la salida esperada es una estimacion, entonces si los valores de salida no son exactamente los
introducidos en la base de datos, no es un asunto relevante.
Figura 10-1: Funciones de pertenencia ajustadas para el threshold.
10.1.4. Ajuste de las funciones de pertenencia
Como se menciono, el objetivo del algoritmo de evolucion diferencial es ajustar las funciones
de pertenencia de las entradas y la salida, para responder a los valores de threshold esperados,
10.1 Sistema difuso generado por el algoritmo de evolucion diferencial 85
para cada una de las condiciones evidenciadas en la concepcion de las reglas, con un mayor
grado de precision, teniendo en cuenta que el objetivo principal es extender el intervalo de
uso del threshold. De esta manera, las modificaciones funciones de pertenencia se presentan
a continuacion. La primera precision que se debe realizar es que gracias a las penalidades
introducidas en la funcion fitness, las nuevas funciones de pertenencia son totalmente inter-
pretables, lo cual supone un exito para la implementacion del algoritmo. Ademas, si se suman
los niveles de pertenencia de cada punto del universo en los diferentes conjuntos difusos, no
suman mas de 1, lo cual es una caracterıstica de funciones de pertenencia apropiadamente
construidas.
Las funciones de pertenencia ajustadas para la salida, threshold, se exponen en la figura
10-2. Al comparar las nuevas funciones de pertenencia con las propuestas en el capıtulo 8,
se puede comprobar que el cambio con mayor efecto visual es en el threshold, donde los
soportes de“Flexible”, “Moderado” y “Exigente” se han reducido en mas de dos veces de los
anteriores, y, las funciones de pertenencia de los extremos, “Muy flexible” y “Muy exigente”,
han extendido ligeramente la parte de su soporte que tiene nivel de pertenencia 1 y la caıda
de la funcion al valor 0, ocasionando una extension sobre el universo.
Figura 10-2: Funciones de pertenencia ajustadas para el threshold.
Las funciones de pertenencia modificas para el SNR se exponen en la figura 10-3. Para es-
te caso, aunque el cambio no es tan notorio como en el caso del threshold, si se han dado
importantes variaciones. En primer lugar, la funcion de pertenencia “Bajo”, para la que ante-
riormente el valor 10dB tenıa una pertenencia cercana a 0.5, ha movido su soporte hasta dar
a este, una pertenencia al rededor de 0.05. Esto sucede porque la funcion de pertenencia ha
recortado su soporte original ubicandose hacia los valores inferiores del universo, y, ademas,
ha acelerado su caıda exponencial. Un efecto similar se nota en la funcion de pertenencia
“Alto” donde se ha reducido tambien el soporte, pero este se ha movido hacia los valores
altos del intervalo. El movimiento de las mencionadas funciones de pertenencia, tiene como
86 10 Experimentos y resultados
objetivo aumentar la selectividad en los valores que hacen al threshold “Muy flexible” o
“Muy exigente”, de esta manera, el sistema difuso tiene mayor control sobre cuando debe
configurarse hacia estos valores. Notese ademas, que el centro de la funcion de pertenencia
de tipo gausiana implementada para “Medio” se ha movido de 15 a alrededor de 17, lo cual
varıa la interpretabilidad de los valores de dicho conjunto, levemente.
Figura 10-3: Funciones de pertenencia ajustadas para el SNR.
Para el caso del FER, Las funciones de pertenencia modificadas se presentan en la figura
10-4. El cambio mas interesante de resaltar es que se ha ejecutado una exclusion esperada
de FER = 50 del conjunto difuso “Bajo”, por lo que ahora unicamente un FER = 0 es
considerado como “Bajo”, lo cual se ajusta en mayor medida a la realidad, que la funcion de
pertenencia propuesta inicialmente, puesto que si se estan perdiendo la mitad de las tramas,
que es el caso de FER = 50, no se puede considerar como “Bajo”. En el otro extremo, la
funcion de pertenencia “Alto” tambien ha recortado su soporte, de por sı, si se observa con
detalle, el intervalo de su soporte en el que la pertenencia es cercana a 1, es casi inexistente.
El que se ha visto beneficiado con una extension del universo en su soporte es “Medio” que
ha adoptado los puntos que los otros dos han dejado al desplazarse. De esta manera, ahora,
la mayorıa de valores del FER van a pertenencer a “Medio” y solo los que son perfectos,
FER = 0, a “Bajo”, o en los que hay una cantidad bastante elevada de perdidas a “Alto”.
Las funciones de pertenencia modificadas para la potencia media se presentan en la figura
10-5. Se puede evidenciar como las dos funciones de los extremos no han sufrido mayores
cambios, pero la funcion de pertenencia “Media”, contrario a los casos evidenciados ante-
riormente, ha desplazado el centro de su funcion alrededor de 5dB, lo cual representa una
mejora considerable y necesaria en la interpretacion del problema, puesto que en el intervalo
del universo del que se ha movido “Media”, no es usual encontrar valores de potencia media,
caso contrario al que sucede con el intervalo en el que se elevo el nivel de pertenencia del
conjunto difuso “Media”.
10.1 Sistema difuso generado por el algoritmo de evolucion diferencial 87
Figura 10-4: Funciones de pertenencia ajustadas para el FER.
Figura 10-5: Funciones de pertenencia ajustadas para la potencia media.
Para la ganancia de recepcion normalizada, se presentan las funciones de pertenencia mo-
dificadas en la figura 10-6. El cambio mas notorio es la extension del soporte de “Alta”,
que se ha ampliado reduciendo el de “Media” y el de “Baja”, lo que representa un cambio
importante teniendo en cuenta que los valores cercanos a 0.75 se consideran ahora como una
alta ganancia.
88 10 Experimentos y resultados
Figura 10-6: Funciones de pertenencia ajustadas para la ganancia de recepcion
normalizada.
10.2. Integracion del sistema difuso en el receptor de
IEEE802.11a/g/p
10.2.1. Bloque WiFi Sync Short
Para validar el funcionamiento de las modificaciones realizadas al bloque WiFi Sync Short,
descritas en el capıtulo anterior, se modifica el flujograma wifi loopback.grc a partir del bloque
modificado y un sink, Message Debug, como se puede evidenciar en la figura 10-7. En este
experimento se conecta la entrada in threshold con la salida out threshold, se modifica al
codigo del bloque la asignacion del nuevo valor de la variable d threshold ad threshold =1-
(double) pmt::to long(d msg) y se inicia el valor del umbral en 0.3, de tal manera que si el
bloque esta leyendo y enviando correctamente el valor del umbral debe oscilar entre 0.3 y
0.7.
10.2 Integracion del sistema difuso en el receptor de IEEE802.11a/g/p 89
Figura 10-7: Modificacion al flujograma
De esta manera, se ejecuta una simulacion con el flujograma wifi loopback.grc. El bloque
Message Debug, se conecto de tal manera que el valor del umbral sea mostrado en consola.
La figura 10-8 expone el resultado. Como se puede observar, la salida es la esperada, por lo
que se considera que el bloque WiFi Sync Short esta correctamente adecuado para modificar
el valor del umbral a partir de la salida del sistema difuso.
Figura 10-8: Salida en la consola de GNURadio
10.2.2. Implementacion en GNURadio
El flujograma implementado para comprobar el funcionamiento del sistema de inferencia
difuso para la modificacion del umbral de procesamiento se expone en la figura 10-9. En el
flujograma se puede observar como el bloque WiFi Threshold Generator ha sido incluido y
asignado con la tarea de establecer el umbral utilizada en la capa fısica para recepcion. Notese
de igual manera, que los bloques correspondientes a la capa fısica y subcapa MAC, son lo
que se modificaron para el gateway. El flujo seguido por la senal hasta modificar un valor del
threshold es: 1) la senal es capturada por el bloque USRP Source. Esta, en formato complejo,
viaja hacia la capa fısica, donde se encuentra el bloque WiFi Sync Short, para hacer todo
el proceso de reconocimiento de trama y alineacion de sımbolos. 2) Dentro de la capa fısica,
90 10 Experimentos y resultados
dos de los bloques utilizados en el calculo de la autocorrelacion, son usados para calcular la
potencia media que se transporta inmediatamente al bloque WiFi threshold Generator, sin
embargo, este bloque no actualiza su valor interno, hasta que no llegue un mensaje. 3) A
continuacion, la capa fısica entrega el mensaje recibido a la MAC, donde por medio del bloque
WiFi Parse MAC se genera el FER y posteriormente, a traves del bloque WiFi Message
Handler, se desempaqueta el SNR, ambas medidas son entregadas el bloque WiFi threshold
Generator. 4) A partir de las tres entradas y el parametro global de la ganancia de recepcion
normalizada, se decide un nuevo valor de threshold, que es transportado hacia la capa fısica,
donde se ingresa por una entrada al bloque WiFi Syn Short y este, actualiza su valor. De esta
manera, cada vez que arriba un mensaje se reconfigura el valor del threshold, ademas, como
se menciono en la etapa de diseno, si debido a un valor muy alto del threshold, no es posible
permitir el paso de una trama para conocer las nuevas condiciones del ambiente, puesto que
los valores de SNR, FER y potencia media solo se actualizan con una nueva trama, se anade
una excepcion, adecuadamente restringida, para permitir el paso de una trama que permita
re-evaluar el valor del threshold.
Figura 10-9: Flujograma disenado para implementar el cambio del umbral de procesamiento
en recepcion de IEEE802.11a/g/p.
Ahora, teniendo en cuenta la limitada cantidad de recursos de los que se puede disponer, de-
bido a la exigencia de la frecuencia de muestreo para la implementacion de IEEE802.11a/g/p,
el coste computacional de la inclusion del bloque WiFi Threshold Generator se expone y se
10.2 Integracion del sistema difuso en el receptor de IEEE802.11a/g/p 91
analiza a continuacion.
Todas las operaciones se realizan para las variables tipo Numpy, float 32. El modelo ma-
tematico se simplifico uniendo operaciones por medio de ciclos for, sin afectar el resultado.
Las operaciones con el mayor coste computacional estan relacionadas con la definicion para
el universo del threshold. El numero de puntos de este universo, α, es configurable a traves
de la relacion propuesta en (10-1).
α = round
(0.745− 0.45
s0
+ 1
)(10-1)
Donde s0 es el paso requerido en los valores del universo.
Al inicio de la aplicacion, cuando GNU Radio esta compilando el flujograma y lanzando la
interfaz grafica, se ejecutan las declaraciones incluidas en la cabecera del archivo python.
Estas variables representan un coste computacional fijo en el sistema de memoria, en este
caso la RAM, a traves de la implementacion. Se presentan en la tabla 10-3. Como se puede
observar, solo se incluyen los parametros de las funciones de pertenencia, en lugar de declarar
los universos de entrada y las expresiones matematicas (que representan una mayor cantidad
de memoria). Ademas, como se ha indicado, el universo del threshold se puede modificar en
funcion de los recursos disponibles.
Tabla 10-3: Variables inicializadas en el inicio de la aplicacion
Asignacion Variable Cantidad
Universo del threshold Vector Float32 de α posiciones 1
Funciones de pertenencia
de entrada
Vector Mk de 17 posiciones 1
Vector Dk de 17 posiciones 1
Por otro lado, durante la implementacion, se realiza un conjunto de operaciones, como se
muestra en la tabla 10-4 . Como se puede observar, las operaciones son muy simples, de
hecho la mas compleja es un exponente de Euler, y, solo se ejecutan cuando llega una trama.
Ası, por ejemplo, si se reciben 1000 tramas por segundo, lo cual es una gran cantidad, se
ejecutara una cantidad de operaciones de 51000+3000α. En el valor implementado α = 256,
se ejecutarıan 819000 operaciones, que comparadas con la ejecucion de un bloque simple
en el flujograma, como la multiplicacion, que ejecuta un numero de operaciones igual a la
frecuencia de muestreo (5, 10 o 20 MHz), es muy baja. Ademas, si se requiere que la cantidad
sea menor, un valor de α = 31 es suficiente para obtener valores para el threshold con dıgitos
de precision decimal, por lo que se ejecutarıan 144.000 operaciones.
92 10 Experimentos y resultados
Tabla 10-4: Operaciones realizadas para generar un valor del threshold
Elemento del sistema difuso Operacion Cantidad
Fuzificador
Exponenciacion con base Euler 12
Multiplicacion 12
Suma 12
Division 12
Sistema de inferenciaMınimo α
Maximo α
Defuzificador
Multiplicacion de dos elementos α
Suma de α elementos 2
Division 2
Total 51+3α
Con un analisis de los resultados de la implementacion del bloque y el flujograma utili-
zado, resta evaluar el diseno del sistema de inferencia difuso. El flujograma del receptor
IEEE802.11a/g/p se implementa sobre una USRP B210 y, por otro lado, con un flujograma
similar al expuesto en la caracterizacion de las entradas, se ejecuta un transmisor en un se-
gundo USRP, en este caso la N210. Por lo tanto, las tramas IEEE802.11 se envıan de un lado
a otro, a traves de diferentes canales y bajo una gran cantidad de condiciones de ambiente
diferentes. Los resultados se exponen y analizan a continuacion, senalando la importancia
de utilizar todo el intervalo efectivo del threshold en la reconfiguracion en tiempo real.
Como se ha enfatizado a traves del documento, el uso del intervalo efectivo del threshold
es un asunto esencial en la implementacion. La figura 10-10 expone el ajuste del threshold
generado por el bloque WiFi Threshold Generator cuando se varıan las variables SNR,
potencia media y recepcion normalizada. Los valores mınimos y maximos alcanzados son
0, 4757 y 0, 7375 respectivamente. Ademas, a pesar de los valores muy bajos introducidos
para el SNR y la ganancia, la capa fısica no pierde tramas debido a la configuracion del
threshold, por lo que se considera un exito la inclusion del sistema difuso.
10.2 Integracion del sistema difuso en el receptor de IEEE802.11a/g/p 93
Figura 10-10: Modificacion del threshold para las pruebas realizadas con la implementacion
del sistema de inferencia difuso.
Ademas de verificar el uso del intervalo efectivo del threshold, es necesario comprobar que la
relacion entre las entradas del sistema de inferencia difuso y el umbral se ajuste a las reglas
disenadas. Para llevar a cabo el analisis, se lanzan varios experimentos para proponer hasta
100 escenarios de implementacion a traves de la variacion de los parametros caracterısticos
relacionados, como se realizo para la caracterizacion de las entradas. De esta manera, para la
evaluacion de cada entrada, se procura no modificar las demas, aunque, por supuesto, varıan
en un pequeno intervalo debido a las variaciones en las condiciones del medio de transmision.
Los resultados para el SNR son expuestos en la figura 10-11, donde los tres conjuntos difusos
se pueden distinguir facilmente. Como se puede observar, esta variable es la unica que mueve
el threshold en casi el universo. Ademas, pone una gran cantidad de puntos en el intervalo
[0.52.0.6], donde no hay un conjunto difuso para el threshold. Esto sucede porque diferentes
reglas apuntan a diferentes conjuntos difusos de la salida, por lo tanto, cuando se ejecuta el
defuzificador, las reglas que cambian su funcion de pertenencia en funcion del valor SNR, se
mueven y aparecen estos valores.
94 10 Experimentos y resultados
Figura 10-11: Modificacion del threshold al variar unicamente el SNR: Las demas entradas
se establecen en valores iniciales alrededor de 0.75 para la ganancia norma-
lizada y -55dB para la potencia media.
Para el caso de la potencia media, cuyos resultados son expuestos en la figura 10-12 , los
conjuntos difusos ”Media 2.Alta”se mezclan aislando a ”Baja”. Lo anterio sucede porque es
muy difıcil obtener valores para la potencia media en el intervalo [-50, -40] dB, hecho que
se analiza en el diseno del sistema difuso. Es importante agregar que esta variable cambia
el threshold en un intervalo menor que el SNR. En este caso, el intervalo es [0.68.0.73]
porque el SNR es alrededor de 20dB y la ganancia 0.75, si esos valores son modificados, el
intervalo va a ser movido, por ejemplo, para un SNR alrededor de 10dB y la ganancia en
0.6, se establecerıa el Valor del threshold, al variar la potencia media, en la parte inferior del
universo del threshold.
Figura 10-12: Modificacion del threshold al variar unicamente la potencia media que per-
cibe el transmisor: Las demas entradas se establecen en valores iniciales al-
rededor de 20dB para el SNR y 0.75 para la ganancia normalizada.
Finalmente, para la ganancia de recepcion normalizada, como sucede con el SNR, los tres
10.3 Implementacion y experimentos para el gateway 95
conjuntos difusos son muy claros. Se logra modificar el threshold en un intervalo mayor
que la potencia media, y, como esta variable, el intervalo en el que se establece el umbral
modificando la ganancia, se puede cambiar si se modifican las otras variables. En este caso,
el SNR esta de alrededor de 20dB y la potencia media en torno a -50dB. Los resultados se
exponen en 10-13.
Figura 10-13: Modificacion del threshold al variar unicamente la ganancia normalizada:
Las demas entradas se establecen en valores iniciales alrededor de 20dB para
el SNR y -55dB para la potencia media.
10.3. Implementacion y experimentos para el gateway
En esta seccion se presentan los resultados de la implementacion de los bloques funcionales
descritos en el capıtulo 9. Para esto se propone un escenario de experimentacion compuesto
por el gateway y dos nodos, uno con cada estandar. Para el gateway se utiliza una USRP
N210 con una antena Log periodica directiva para transmision y una vertical omnidireccio-
nal para recepcion. El nodo IEEE 802.11a/g/p se implementa como un radio definido por
software sobre la USRP B210. Se elige utilizar un nodo definido por software debido a la
posibilidad de realizar los experimentos en canales de WiFi sin congestion. En el caso del
nodo IEEE 802.15.4, dado el bajo trafico en los canales disponibles, es posible implementar
un nodo comercial, el escogido es el Xbee S2, que se integra a un sistema compuesto por un
microcontrolador, un sensor de temperatura y una LCD. A continuacion, se describen las
caracterısticas de los tres actores y una prueba de validacion de la comunicacion.
10.3.1. Flujograma del gateway en GNU Radio
EL flujograma disenado para implementar el gateway se expone en la figura 10-14. EL flujo-
grama esta compuesto por versiones compactas de los bloques de los transceptores de IEEE
802.11a/g/p e IEEE 802.15.4, y, los bloques propuestos en el capıtulo 9. En ese sentido se
96 10 Experimentos y resultados
puede diferenciar claramente los dos posibles caminos que puede seguir una senal depen-
diendo del nodo de transmision y de recepcion, ası como el uso de un solo Fron End para
transmision y recepcion, por medio de la reconfiguracion en tiempo real de los parametros
de los bloques USRP Sink y USRP Source, que como se introdujo en su diseno, se realiza
cuando alguno de los dos nodos envıa la palabra reservada ”fin” indicando que no desea
transmitir mas datos y puede ceder la palabra al otro nodo.
Figura 10-14: Flujograma implementado sobre GNU Radio para la construccion del
gateway.
El flujograma expuesto anteriormente, cuenta con bloques de configuracion que no son in-
cluidos en el grafico (pueden ser comprobados en los anexos), pero que tienen una importante
funcion, como lo es, inicializar las variables del flujograma. Un resumen de las principales
variables se presenta en la tabla 10-5. Allı, se dividen las variables en tres grupos, las que
definen los parametros del gateway para IEEE 802.11 y para IEEE 802.15.4, y, las que con-
figuran directamente al gateway. En el caso de 802.11, se define el canal 14 a una tasa de
muestreo de 10MHz, el formato de direccion IP que debe ser asociado a los nodos de la red
y la direccion MAC del gateway. Para 802.15.4 se define el canal 22 a una tasa de muestreo
de 4MHz, el Pan ID de la red Xbee, y, las direcciones de 16 y 64 bits del gateway. En el
gateway se fijan las ganancias de transmision y recepcion, en las cuales se debe tener en
cuenta que la USRP N210 tiene niveles de potencia diferentes a los de la USRP B210, dado
que su alimentacion le entrega hasta 3A, por lo que, al ser estos valores normalizados, se
deben variar dependiendo del dispositivo, ademas, puesto que solo un nodo es escuchado a
la vez, se establece el estandar que iniciara con esta facultad.
10.3 Implementacion y experimentos para el gateway 97
Tabla 10-5: Parametros iniciales en el flujograma del gateway
Tipo Parametro Valor
IEEE 802.15.4
Frecuencia central 2.46 [GHz]
Tasa de muestreo 4 [MHz]
Pan ID red Zigbee 0x23E3
Direccion IEEE 64 bits gateway 0x1234564200A21300
Direccion 16 bits gateway 0x5678
IEEE 802.11
Frecuencia central 2.484 [GHz]
Tasa de muestreo 10 [MHz]
MAC gateway 0xFFFFFFFFFFFF
IP red 192.168.123.x/24
Gateway
Estandar inicial “IEEE 802.11”
Potencia de transmision 0.4
Potencia de recepcion 0.75
Adicionalmente, para anadir interpretabilidad al diseno, se agrega una interfaz grafica que
permite modificar parametros en tiempo real, el envıo y comprobacion de la recepcion de
mensajes, y, la forma de senal que se esta procesando. Esta interfaz es disenada con la
herramienta grafica QT de GNU Radio. Se puede evidenciar en la figura 10-15.
Figura 10-15: Interfaz grafica disenada para el gateway.
Finalmente, se presenta la configuracion hardware del gateway. Como se menciono anterior-
mente, esta compuesto por la USRP N210, una antena direccional y otra omnidireccional.
La USRP N210 se encuentra alimentada externamente y la interfaz de comunicacion con
el equipo de computo es Gigabit Ethernet. La antena Log periodica cuenta con 9 dipolos,
por lo que en la frecuencia de trabajo el direccionamiento es extremadamente alto, por esta
98 10 Experimentos y resultados
razon, el desplazar unos cuantos centımetros su foco, causa la perdida total de los datos
transmitidos.
Figura 10-16: Configuracion hardware de la USRP N210 para implementar los bloques
funcionales del gateway.
10.3.2. Nodos de comunicacion
Para comprobar el funcionamiento del gateway se implementan dos nodos de comunicacion,
cada uno configurado con uno de los estandares. A continuacion se introduce las caracterısti-
cas de cada uno.
Nodo IEEE 802.11a/g/p
El nodo para 802.11 se ejecuta a partir del presentado en [41] y las modificaciones propuestas
en el capıtulo 9. EL flujograma implementado se puede evidenciar en la figura 10-17. Los
parametros de inicializacion son similares a los expuestos para el diseno en [41], configurando
la frecuencia central y tasa de muestreo en los mismos valores que el gateway. Se anaden
conectores Wireshark para verificar el formato de las tramas enviadas y recibidas, ası como
un bloque Mesagge debug para visualizar el mensaje recibido. La implementacion de estos
bloques sobre USRP N210 tiene la facultad de rechazar en la antena de recepcion, las tra-
mas que envıa por la de transmision, en este caso, sobre USRP B210, la excepcion debe ser
anadida por codigo, esto se realiza en la capa fısica.
10.3 Implementacion y experimentos para el gateway 99
Figura 10-17: Flujograma disenado para el nodo IEEE 802.11a/g/p.
Al igual que en los bloques implementados para el gateway, se anade una interfaz grafica
para interactuar con el nodo, presentada en la figura 10-18. Las dos primeras filas permiten
la modificacion de los parametros del nodo. La tercera fila cuenta con tres campos, en el
primero se ingresa el mensaje que se desea enviar, en el segundo, se evidencia el mensaje
que se esta recibiendo del nodo 802.15.4, y, el tercero es un pulsador que da por finalizado
el proceso de transmision del nodo, cediendo la transmision al Xbee. En la parte inferior
se presenta la constelacion que se transmite o recibe. Al igual que la anterior, esta interfaz
grafica es disenada con la librerıa QT de GNU Radio.
100 10 Experimentos y resultados
Figura 10-18: Interfaz grafica para el nodo IEEE 802.11a/g/p.
La implementacion sobre la USRP B210 se expone en la figura 10-19. Se repite la configu-
racion de antenas del gateway, pero en este caso, la alimentacion y transferencia de datos se
realiza via USB 3.0.
Figura 10-19: Configuracion hardware de la USRP B210 para implementar el nodo IEEE
802.11a/g/p.
Nodo Xbee s2
La implementacion del nodo para IEEE 802.15.4 es tomada de [2], tal y como se indico en la
fundamentacion del proyecto, se puede evidenciar en la figura 10-20. En esta, el modulo de
comunicacion es un Xbee S2 que es compatible con las especificaciones Zigbee 2006 y Zigbe
10.3 Implementacion y experimentos para el gateway 101
Pro. Se introduce en un circuito impreso junto a un sistema de medicion de temperatura,
un periferico grafico y un pulsador, ademas, cuenta con autonomıa energetica. El flujo de
operacion se ejecuta como sigue: (1) el nodo esta constantemente midiendo la temperatura
del ambiente por medio de un sensor LM35, (2) el microcontrolador MSP430g2553 por medio
de uno de sus pines analogos mide esta temperatura y la entrega en grados Celsius, y, (3)
Cada n milisegundos, el microcontrolador ejecuta una rutina para enviar la temperatura a la
LCD y, a traves del puerto de comunicacion UART, al xbee S2. En caso de que se encuentre
oprimido el pulsador, se envıa la palabra reservada “fin”. El periferico de salida usado, es
una LCD de 2 filas. En la primera fila se evidencian las mediciones de temperatura que son
enviadas y en la segunda el dato que se recibe del nodo 802.11. En este sentido, cada fila es
actualiza independientemente, segun se disponga del dato para ser mostrado.
Figura 10-20: Nodo para IEEE 802.15.4 a partir de un modulo Xbee S2, sensor de tempe-
ratura y LCD.
10.3.3. Validacion del sistema
Para validar el funcionamiento del sistema, se propone un experimento en el cual se envıa
un mensaje en un sentido, se reconfiguran los parametros del gateway y se envıa nuevamente
un mensaje, pero en el sentido opuesto. Para esto se ubican los nodos y el gateway en la
disposicion presentada en la figura 10-21. Se ubican los dos nodos en la misma posicion
debido a la direccionalidad de la antena, sin embargo, en pruebas realizadas con antenas
menos directivas es posible posicionarlos hacıa cualquier direccion. Se debe tener en cuenta
que el proposito del diseno aca presentado, no es corroborar que los modulos definidos por
software funcionan y en que medida o bajo que parametros lo hacen, puesto que esto ya
ha sido realizado en [2] y [41], sino probar que es posible transmitir un mensaje entre dos
nodos diferentes a partir de un concentrador definido por software. En este orden de ideas, se
considera un exito el diseno, si se logra transmitir mensajes en ambos sentidos y en ningun
caso, un mensaje que arribo al gateway no es entregado. Ası pues, medidas como el PER
(Packet error ratio), el PDR (Packet delivery ratio) o el FER (Frame Error Rate), no son
de interes para la validacion del sistema, puesto que ya han sido apropiadamente estudiadas
102 10 Experimentos y resultados
en [2] y [41]. La anterior afirmacion es valida puesto que el gateway, a groso modo, opera
los dos flujogramas disenados previamente con los nodos que fueron utilizados para analizar
el desempeno de los modulos definidos por software en los disenos previos, es decir, las
condiciones fundamentales, no han sido variadas. Sin embargo, aunque no supone un cambio
en las bases de la implementacion IEEE 802.11a/g/p, sino un riesgo en el uso de recursos
computacionales, se ha introducido un estudio del desempeno del sistema con la modificacion
del umbral de procesamiento, y como se comprobo en la anterior seccion, no se introducen
perdidas de tramas por la inclusion del sistema difuso.
Figura 10-21: Montaje para comprobar el funcionamiento del gateway.
Para ejecutar la implementacion se asigna al nodo 802.11 la direccion IP 192.168.123.2
asociada a la direccion MAC 0xBA0987654321 y al nodo xbee 192.168.123.1 asociada a
0x1234567890AB, ademas, al nodo 802.11 la direccion de 16 bits 0x1234 y al nodo xbee
0x0000 (puesto que es el coordinador de la red).
Mensaje de IEEE 802.11a/g/p a IEEE 802.15.4
El estandar al que se le permite transmitir a traves del gateway al inicio de la implementacion
es 802.11. La palabra UDistrital” es introducida en el espacio indicado en la interfaz grafica
y por medio de la tecla Entrar, se envıa hacıa el gateway. La trama resultante se presenta
en 10-22. En esta se puede ver como el mensaje parte de la MAC asociada al nodo 802.11
hacia la MAC asociada al nodo Xbee. Ademas, el mensaje es UDistrital”.
Figura 10-22: Trama IEEE 802.11a/g/p del mensaje enviado.
10.3 Implementacion y experimentos para el gateway 103
La trama que llega al Xbee S2, se expone en la figura 10-23. En este caso, la direccion de
16 bits del transmisor, corresponde a la asociada al nodo 802.11 (evidenciada en los bytes 8
y 9), y la de destino a 0xFFFF puesto que se transmite en Broadcast. La transmision en
Broadcast representa una facilidad ante la configuracion del Xbee S2 en la interfaz XCTU, sin
embargo, se podrıa transmitir tambien a la direccion 0x0000 que corresponde al coordinador.
Ademas, se puede evidenciar que el mensaje entregado es el mismo, UDistrital, a partir de
la comparacion entre los bytes 33-42 de la trama 802.15.4 con los del mensaje enviado en la
trama 802.11.
Figura 10-23: Trama IEEE 802.15.4 del mensaje recibido.
Mensaje de IEEE 802.15.4 a IEEE 802.11a/g/p
Posterior a la recepcion, por parte del Xbee, se pulsa el boton Stop Sending de la interfaz del
nodo 802.11, induciendo la reconfiguracion de los parametros de la USRP N210, para ceder
la transmision al nodo 802.15.4. De esta manera, el nodo 802.11 recibe ahora, las mediciones
de temperatura realizadas por el LM35. La trama enviada por el Xbee se expone en la figura
10-24. En esta se puede evidenciar el envıo del valor 27, 3 ası como la direccion de destino
Broadcast y la del coordinador 0x0000.
Figura 10-24: Trama IEEE 802.15.4 del mensaje enviado.
Esta trama es recibida en el nodo 802.11 como se muestra en la figura 10-25. En este caso el
valor del mensaje es diferente puesto que la actualizacion es muy rapida y las medidas suelen
variar de una a otra, el valor recibido es 26, 7. Ademas, la direccion fuente es la asociada al
nodo Xbee y la de destino la del nodo 802.11. Es importante resaltar que, como se puede
evidenciar en la grafica, el flujograma de recepcion tambien procesa las tramas que el nodo
802.11 envıa, razon por la que se implemento un filtro por codigo en el nodo IEEE 802.11,
como se expuso anteriormente.
104 10 Experimentos y resultados
Figura 10-25: Trama IEEE 802.11a/g/p del mensaje recibido.
11 Conclusiones y analisis de resultados
11.1. Conclusiones
Se ha presentado un dispositivo definido por software con capacidades de concentrator que
representa un punto de convergencia entre los estandares IEEE802.11 e IEEE802.15.4. Este
dispositivo es capaz de permitir comunicacion bidireccional entre nodos construidos con al-
guno de los dos protocolos, a partir de la reconfiguracion en tiempo real de parametros como
la tasa de muestreo, la frecuencia central, el ancho de banda y la potencia de transmision o
recepcion, representando una aplicacion practica del concepto baluarte de radio definida por
software. De esta manera, es posible utilizar un unico front end para recepcion y otro para
transmision, estableciendo los parametros de cada uno, segun los estandares del nodo que
transmite y del que recibe, ası, se reduce a la mitad los recursos hardware, en comparacion al
necesario en dos implementaciones por separado que simplemente compartan el mensaje (por
ejemplo, si el concentrador estuviese compuesto por un nodo wifi y uno zigbee, configurados
para recibir, compartir el mensaje y transmitir, segun los nodos implicados).
Adicionalmente, se ha presentado un sistema de inferencia difuso para el ajuste automatico
del umbral de procesamiento. El desarrollo es completamente autonomo y libre de errores.
A traves del sistema de inferencia se pudo obtener un valor para el umbral en el intervalo
efectivo de [0,475, 0,732], para las diferentes condiciones ambientales descritas por las cuatro
variables, SNR, FER, potencia media y ganancia de recepcion normalizada, en una imple-
mentacion sobre la USRP B210. Dada la descripcion muy especıfica del diseno, este novedoso
desarrollo no solo representa una solucion adecuada para el ajuste del valor del umbral, sino
tambien una oportunidad para fomentar la inclusion de sistemas difusos en el campo SDR,
especıficamente para aplicaciones en IEEE 802.11.
Como se explico en la seccion de resultados, no se evidenciaron tramas perdidas, causa-
das por la inclusion del sistema de inferencia difuso. De esta manera, la implementacion
demuestra un rendimiento adecuado del sistema difuso para la configuracion del umbral y
una adecuada toma de decision para las diferentes condiciones del entorno. En cuanto al
coste computacional, el sistema difuso introducido representa un diseno muy bien adaptado
a los recursos disponibles en la implementacion. Ademas, la posibilidad de reducir el coste
computacional cambiando la cantidad de puntos en el universo del umbral, representa una
buena opcion de adaptacion en caso de escasos recursos disponibles. Como se muestra en la
106 11 Conclusiones y analisis de resultados
seccion de resultados, los recursos necesarios a traves de la implementacion son comparables
a los de un bloque de multiplicacion implementado en el diagrama de flujo, que es uno de
los mas simples en GNU Radio, y el mas utilizado en el receptor IEEE 802.11a/g/p.
El diseno propuesto reune conceptos de los campos del conocimiento en telematica, comunica-
ciones digitales, inteligencia computacional, procesamiento digital de senales y programacion
orientada a objetos. Se exploran los lenguajes Python, C++, matlab y C. Ademas, se ahonda
en la interfaz de desarrollo GNU Radio y los dispositivos USRP, que representan la actualidad
del estado del arte en radio definida por software, que a su vez, es la tecnologıa que se preve
domine el desarrollo en comunicaciones inalambricas en los anos venideros. Fundamentado
en lo anterior, es posible afirmar que la tematica abordada a lo largo del libro, ha producido
una extensa interdisciplinariedad aplicada en un aporte al estado del arte implementado. De
esta manera, las propuestas presentadas en el documento, se consideran un exito, no solo
por su caracter funcional, sino por la gran cantidad de campos del conocimiento que se han
hecho converger.
11.2. Aportes originales
El gateway definido por software ha sido construıdo a partir de bloques funcionales di-
senados sobre la interfaz de desarrollo GNU Radio. Al ser esta, una plataforma libre y de
codigo abierto, los bloques funcionales creados, descritos a lo largo del documento, repre-
sentan un producto intelectual registrado a nombre del grupo de investigacion GRECO y
distribuido bajo la licencia GNU (General Public License) V3. De esta manera, los disenos
aquı presentados, son distribuidos a la comunidad cientıfica vinculada al campo de radio
definida por software, a traves, de las plataformas disponibles para dicha finalidad, repre-
sentando un aporte al estado del arte implementado, teniendo en cuenta la novedad de la
propuesta. Es importante anotar, que estos codigos no son unicamente libres sino abiertos,
por lo que posteriormente, cualquier miembro de la comunidad podrıa tomarlos,modificarlos
y distribuirlos nuevamente. De esta manera, a continuacion se nombran los productos inte-
lectuales que se generan como resultado del proyecto y se relaciona la plataforma de difusion.
Implementacion de un modulo definido por software para la convergencia entre los
estandares IEEE 802.11a/g/p e IEEE 802.15.4: Este producto ha sido construido a
partir de los modulos desarrollados en [2] y [41], registrados bajo la licencia GNU
(General Public License) V3 (Anexo 1).
• Flujogramas
◦ Gateway 802 11 802 15 4.grc.
11.2 Aportes originales 107
• Bloques funcionales
◦ WiFi Message Handler.
◦ Zigbee Message Handler.
◦ USRP Control.
◦ Tx Switch.
◦ Rx Switch.
Implementacion de un sistema de inferencia difuso para modificar el umbral de proce-
samiento en la capa fısica de IEEE 802.11a/g/p (Anexo 2).
• Flujogramas
◦ WiFi Mote.grc.
• Bloques funcionales
◦ WiFi Threshold Generator.
Como se menciono en la introduccion del documento, el diseno del gateway representa un
reto mayormente tecnico, por lo que los aportes estan orientados a lograr funcionalidades
sobre la plataforma definida por software. En la construccion del estado del arte, no se
encontro un dispositivo de este tipo, mayormente ocasionado porque los disenos utilizados
datan de 2014 y 2016, por lo que es posible afirmar que el desarrollo presentado, es el primer
intento funcional por generar interoperabilidad entre nodos que distan en el estandar de
comunicacion, a partir de un gateway definido por software. De esta manera, se presenta
un aporte al estado del arte implementado en convergencia de protocolos de comunicacion.
De ninguna manera, se considera el producto expuesto, como uno final, en cambio, se recal-
ca en la necesidad de mejorar el diseno, tal y como se expone en la seccion de trabajos futuros.
De igual manera, se indico el reto conceptual que suponıa introducir un sistema difuso para
modificar el umbral de procesamiento. En este caso, se debio realizar una extensa caracte-
rizacion de las variables que podrıan ser tomadas como entradas y del comportamiento que
estas debıan producir en la salida, ademas, de la propuesta y posterior ajuste, de las funcio-
nes de pertenencia y reglas del sistema, y, su implementacion en un bloque funcional. En este
sentido, cada una de las etapas supuso proponer una solucion adecuada para el problema
atacado, a traves de la evaluacion de los conceptos involucrados en el desarrollo. Ası, la pro-
puesta del sistema de inferencia difuso, representa una aplicacion altamente novedosa, que
presenta una propuesta original para resolver un problema en radio definida por software,
pudiendose considerar como un aporte al estado del arte implementado en radio definida por
software.
108 11 Conclusiones y analisis de resultados
11.3. Trabajos futuros
El diseno propuesto en el documento, representa un primer paso hacia un dispositivo que
permite la convergencia de nodos con diferentes protocolos, por medio de la equivalencia
entre algunos de los principales campos de sus tramas, pero no llega hasta la construccion
de una pila para la compatibilidad entre 802.11 y 802.15.4, por lo que un desarrollo intere-
sante serıa construir la pila de equivalencias, es decir, tomar cada uno de los campos de
cada trama y en la medida de lo posible, relacionarlos bajo algun criterio con los de la otra.
De esta manera, todos los parametros de las tramas serıan enteramente decididos por cada
nodo y el gateway no tendrıa que decidir campos de las tramas, como se hace en la actual
implementacion, donde en el gateway debe ingresar la mayorıa de campos de las tramas sin
tener en cuenta los que estan llegando de los nodos.
Los bloques funcionales propuestos para implementar el gateway han sido realizados ente-
ramente en GNU Radio, por lo que el procesamiento se carga directamente a un equipo de
computo. Una mejora inmediata al desarrollo propuesto serıa tomar este diseno y establecer
su equivalente en bloques funcionales o lenguaje VHDL sobre la FPGA. De esta manera,
el proceso se podrıa cargar tambien sobre este dispositivo, aumentando las prestaciones del
gateway, e incluso, se podrıa pensar en tener un nodo independiente de un equipo de compu-
to. Para esto, como se menciono a lo largo del libro, se requieren amplios conocimiento en
procesamiento de senales y disenos sobre FPGA.
Con respecto a los dos transceptores implementados, se puede pensar en incluir varias mejo-
ras a sus bloques funcionales. Por ejemplo, en ninguno de los dos, se encuentra implementada
la pila del protocolo para emparejar los nodos. En el caso de IEEE 802.11 es un poco mas
complejo, puesto que la asociacion requiere cambiar la frecuencia central, del canal de senali-
zacion al de comunicacion, intercambiar semillas, introducir una clave, y asignar direcciones
IP, como mınimo. Para el caso de IEEE 802.15.4 parece un poco mas viable en la medida en
que el proceso de asociacion es mas sencillo y bastarıa con solicitar y recibir una direccion
del coordinador. Por otra parte, se podrıa anadir funcionalidades a las capas implementadas,
en las cuales no se ha ahondado con mayor profundidad, por ejemplo, en la trama de 802.11
la duracion nunca es calculada sino se pone 0x00 o en 802.15.4, las direcciones nunca son
registradas sino se transmite en Broadcast.
Adicionalmente, con respecto a la convergencia de protocolos, el diseno presentado solo cubre
802.11 y 802.15.4, pero hay otros estandares que se podrıan incluir, tales como bluetooth
o Lora. De esta manera, en un futuro, tal vez un poco mas lejano, se podrıa proponer un
dispositivo que permita la convergencia de mas de dos estandares, y de nuevo, se presentarıa
el reto de establecer una pila de compatibilidad, que a medida que crecen los actores impli-
cados su complejidad se eleva exponencialmente.
11.3 Trabajos futuros 109
Por otro lado, a partir de la propuesta del sistema difuso para modificar el umbral de proce-
samiento, se aporta a un campo poco explorado, como lo es la inteligencia computacional en
radio definida por software. Dado que se comprobo la posibilidad de introducir un sistema
de inferencia difuso con un bajo costo computacional, se pueden proponer varias aplicacio-
nes nuevas, tales como ecualizadores difusos o sistemas de inferencia difusa para modificar
parametros como ganancia de recepcion o transmision, lo que es posible si las inclusiones
no representan una tarea computacional exigente. Ası pues, no solo para 802.11, sino para
las necesidades particulares de cada estandar en su implementacion por software, el diseno
expuesto, se propone como una base para permitir nuevos desarrollos, en la medida en que,
ha sido detalladamente explicado y su codigo se encuentra disponible para la comunidad.
12 Anexos
12.1. Anexo 1
Bloques funcionales para la construccion de un gateway definido por software como aporte
a la convergencia entre IEEE 802.11a/g/p e IEEE 802.15.4.
Disponible en: https://github.com/CrisRodriguez/Gateway IEEE 802 11 15 4
12.2. Anexo 2
Bloques funcionales para la construccion de un sistema de inferencia difuso para modificar
automaticamente el umbral de procesamiento en la capa fısica de IEEE 802.11a/g/p.
Disponible en: https://github.com/CrisRodriguez/Threshold generator IEEE 802 11
12.3. Anexo 3
Compendio de las dos implementaciones y codigos utilizados para el diseno del sistema difuso
e implementacion del nodo IEEE 802.15.4.
Disponible en: https://github.com/CrisRodriguez/gr-IEEE-802-11-802-15-4
Bibliografıa
[1] J Mitola, ”The Software Radio”. IEEE National Telesystems Conference, 1992 - Digital
Object Identifier 10.1109/NTC.1992.267870.
[2] Miguel Angel Sastoque Caro; Claudia Esperanza Segura Cano. Diseno de un concen-
trador para aplicaciones de redes de sensores con capacidades de reconfiguracion de
parametros por software (tesis de pregrado). Universidad Distrital Francisco Jose de
Caldas, Bogota, Colombia, 2016.
[3] L. Mainetti, L. Patrono, and A. Vilei, .Evolution of wireless sensor networks to-
waSDR the internet of things: A survey”. Software, Telecommunications and Computer
Networks (SoftCOM), 2011 19th International Conference on, September, 2011, pp. 1-6.
[4] P. Ferrari, A. Flammini, and E. Sisinni, “New Architecture for a Wireless Smart
Sensor Based on a Software-Defined Radio”. Instrumentation and Measurement, IEEE
Transactions on, vol. 60, no. 6, Junio, 2011, pp. 2133 – 2141.
[5] R. G. Machado; A. M. Wyglinski, “Software-Defined Radio: Bridging the Analog–Digital
Divide”, Proceedings of the IEEE, vol. 103, no. 3, Marzo, 2015, pp. 409 – 423.
[6] T. Ulversoy, “Software defined radio: Challenges and opportunities,” IEEE Commun.
Surveys Tutorials, vol. 12, no. 4, June, 2010 pp. 531–550.
[7] S. Bilen et al., “Software-defined radio: A new paradigm for integrated curriculum
delivery”, IEEE Commun. Mag., vol. 52, no. 5, May, 2014, pp. 184–193.
[8] Aguilar, Navarro, Radio cognitiva – Estado del arte”. Universidad Icesi. Revista
Sistemas y Telematica, Vol.9. No.16, Agosto, 2011, pp. 31-53.
112 Bibliografıa
[9] Muhammad Imran TAJ, “Network on chip based Multiprocessor System on Chip for
Wireless Software Defined and Cognitive Radios”, Doctorate thesis, Laboratoire LIGM,
Ecole Doctorale Maths, Universite Paris-Est, ESIEE Paris, Paris, France, 2011.
[10] J. Zhao, H. Zheng and G. Yang, “Spectrum Sharing through Distributed Coordination
in Dynamic Spectrum Access Networks”. Wiley Wireless Communications and Mobile
Computing Journal, Vol.7, No.9, November, 2007, pp. 1061-1075.
[11] Machado F. Jose R., “Software Defined Radio: Basic Principles and Applications”.
Revista Facultad de Ingenierıa, Vol. 24, No. 38, Noviembre, 2014, pp. 79 – 96.
[12] G. S. Uyanik, O Cepheli, G. K. Kurt and S. Oktug, “Implementation and performance
evaluation of dynamic spectrum access using software defined radios”. Communications
and Networking (BlackSeaCom), 2013 First International Black Sea Conference on,
Jule, 2013, pp. 157 – 161.
[13] I. Vitas, D. Simunic and P. Knezevic, “Evaluation of Software Defined Radio systems
for smart home environments”. Electronics and Microelectronics (MIPRO), 2015 38th
International Convention on, May, 2015, pp. 562 – 565.
[14] Y. Chen, S. Lu, H. S. Kim, D. Blaauw, R. G. Dreslinski, T. Mudge, “A low power
software-defined-radio baseband processor for the Internet of Things”. IEEE Interna-
tional Symposium on High Performance Computer Architecture (HPCA), March, 2016,
pp. 40 – 51.
[15] M. Maschlanka, T. Eichner, M. Meuleners, C. Degen, “Alamouti space-time co-
ding in car-to-car communications - SDR-based implementation and measurement”.
9th European Conference on Antennas and Propagation (EuCAP), June, 2015, pp. 1 – 5.
[16] A. Gaber, S. Prcanovic, A. Omar, “High-resolution indoor positioning system using
SDR modules”. IEEE Radio and Wireless Symposium (RWS), January, 2015, pp. 209
– 211.
[17] I. Lucresi, A. D. Carlofelice, P. Tognolatti, I. Lucresi, A. D. Carlofelice, P. Tognolatti,
“SDR-based system for satellite ranging measurements”. IEEE Aerospace and Electro-
Bibliografıa 113
nic Systems Magazine, January, 2016, pp 8 -13.
[18] A. Prata, A. S. R. Oliveira, N. B. Carvalho, “An Agile and Wideband All-Digital
SDR Receiver for 5G Wireless Communications”. Digital System Design (DSD), 2015
Euromicro Conference on, August, 2015, pp. 146 – 151.
[19] C. A. Pena and M. Sipper, ”Fuzzy CoCo: A Cooperative-Coevolutionary Approach to
Fuzzy Modeling”vol. 9, no. 5, pp. 727–737, 2001.
[20] C. Murcia, G. Bonilla, M. Melgarejo, and S. Member, “Fuzzy Classifiers Tuning
Through an Adaptive Memetic Algorithm,” vol. 12, no. 2, pp. 197–204, 2014.
[21] D. H. Wolpert and W. G. Macready, “No free lunch theorems for optimization,” IEEE
Trans. Evol. Comput., vol. 1, no. 1, pp. 67–82, 1997.
[22] W. J. Ewens, “An introduction to evolutionary genetics,” Am. J. Hum. Genet., vol.
34, no. 1, pp. 149–150, 1982.
[23] G. R. Companion, ”GNU Radio Companion,”2015, [En linea] Disponible:
http://www.gnuradio.org.
[24] M. Muller, ”Behind the Veil: A Peek at GNU Radio’s Buffer Architecture,”2014, [En
linea] Disponible: https://www.gnuradio.org/blog/buffers/
[25] G. R. Companion, ”Guided Tutorial GNU Radio in Python”2014, [En linea] Disponible:
https://wiki.gnuradio.org/index.php/Guided Tutorial GNU Radio in Python.
[26] G. R. Companion, ”Guided Tutorial GNU Radio in C++,”2014, [En linea] Disponible:
https://wiki.gnuradio.org/index.php/Guided Tutorial GNU Radio in C %2B %2B
[27] G. R. Companion, InstallingGR,”2011, [En linea] Disponible:
https://wiki.gnuradio.org/index.php/InstallingGR
[28] Ettus Research, USRP B210,”2017, [En lınea] Disponible:
https://www.ettus.com/product/details/UB210-KIT
[29] Ettus Research, USRP N210,”2017, [En lınea] Disponible:
https://www.ettus.com/product/details/UN210-KIT
114 Bibliografıa
[30] Bastian Bloessl, Christoph Leitner, Falko Dressler and Christoph Sommer, .A GNU
Radio-based IEEE 802.15.4 Testbed”. GI/ITG KuVS Fachgesprach Drahtlose Sensor-
netze, September, 2013, pp. 37-40.
[31] A. Marwanto; M. A. Sarijari, N. Fisal, S. Yusof, A. Rashid, “Experimental Study
of OFDM Implementation Utilizing GNU Radio and USRP-SDR”, 9th Malaysia
International Conference on Communications, IEEE, 2009.
[32] J. R. Gutierrez-Agullo, B. Coll-Perales and J. Gozalvez, “An IEEE 802.11 MAC
Software Defined Radio Implementation for Experimental Wireless Communications
and Networking Research”, Wireless Days, IEEE, 2010.
[33] Bastian Bloessl, Michele Segata, Christoph Sommer and Falko Dressler, .A GNURadio
Based Receiver Toolkit for IEEE 802.11a/g/p,”. Proceedings of 19th ACM Internatio-
nal Conference on Mobile Computing and Networking, 5th Wireless of the Students,
by the Students, for the Students Workshop, October, 2013.
[34] Bastian Bloessl, Michele Segata, Christoph Sommer and Falko Dressler, ”TowaSDR
an Open Source IEEE 802.11p Stack: A Full SDR-based Transceiver in GNURadio,”.
Proceedings of 5th IEEE Vehicular Networking Conference, December, 2013, pp.
143-149.
[35] Bastian Bloessl, Christoph Sommer, Falko Dressler and David Eckhoff, ”The Scrambler
Attack: A Robust Physical Layer Attack on Location Privacy in Vehicular Networks”.
Proceedings of 4th IEEE International Conference on Computing, Networking and
Communications, CNC Workshop, February, 2015, pp. 395-400.
[36] B. Bloessl, C. Leitner, F. Dressler, and C. Sommer, “A GNU Radio-based IEEE 802.15.
4 Testbed,” 12. GI/ITG FACHGESPRACH SENSORNETZE, pp. 37, 2013.
[37] J.-O. Jeong, “Hybrid FPGA and GPP Implementation of IEEE 802.15. 4 Physical
Layer,” Virginia Polytechnic Institute and State University, 2012.
[38] N. Marriwala and S. Kapoor, ”Performance of Fuzzy Equalizers in software defined
radio,”2012 World Congress on Information and Communication Technologies, Trivan-
Bibliografıa 115
drum, 2012, pp. 491-494.
[39] P. V. Kumar and S. Malarvizhi, .Experimental study of genetic algorithm based link
adaptation for MIMO cognitive radio application,”2015 2nd International Conference
on Electronics and Communication Systems (ICECS), Coimbatore, 2015, pp. 1354-1359.
[40] T. Lennvall, S. Svensson and F. Hekland, .A comparison of WirelessHART and ZigBee for
industrial applications,”2008 IEEE International Workshop on Factory Communication
Systems, Dresden, 2008, pp. 85-88.
[41] Bastian Bloessl, Michele Segata, Christoph Sommer and Falko Dressler, .An IEEE
802.11a/g/p OFDM Receiver for GNU Radio,”Proceedings of ACM SIGCOMM 2013,
2nd ACM SIGCOMM Workshop of Software Radio Implementation Forum, Hong Kong,
China, August 2013, pp. 9-16.
[42] S. S. Logvinov, .Applications of the theory of fuzzy sets in complex control systems,”XX
IEEE International Conference on Soft Computing and Measurements, Saint Peters-
burg, Russia, 2017, pp. 887-889.