Aceleración de Radios Definidas Por Software
Aceleración de Radios Definidas Por Software
Aceleración de Radios Definidas Por Software
Instituto de Computación
Tutores
Autores
Pablo Ezzatti
Gonzalo Arcos
Eduardo Grampin
Rodrigo Ferreri
Matías Richart
Montevideo, Uruguay
Año 2016
Resumen
1. Introducción 1
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conceptos Teóricos 5
2.1. Comunicación analógica y digital . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Transmisión de señales . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Recuperar el reloj y los datos . . . . . . . . . . . . . . . . . . . 7
2.1.3. Codificación en línea . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Modelos para la comunicación sobre canales físicos . . . . . . . 8
2.1.5. Diagramas de constelación . . . . . . . . . . . . . . . . . . . . . 12
2.1.6. Tipos de modulación . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Códigos convolucionales . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1. Construcción de los códigos convolucionales . . . . . . . . . . . 14
2.2.2. Codificador convolucional . . . . . . . . . . . . . . . . . . . . . 16
2.2.3. Decodificación de los códigos convolucionales . . . . . . . . . . . 19
2.2.4. Puncturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3. Multiplexación por División de Frecuencias Ortogonales (OFDM) . . . 23
2.3.1. Transformada rápida de Fourier . . . . . . . . . . . . . . . . . . 26
2.3.2. Construcción de un símbolo OFDM . . . . . . . . . . . . . . . . 29
Índice general
4. Mejoras introducidas 51
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2. Implementación original . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.1. Implementación del receptor . . . . . . . . . . . . . . . . . . . . 52
4.2.2. Implementación del transmisor . . . . . . . . . . . . . . . . . . 57
4.2.3. Implementaciones adicionales . . . . . . . . . . . . . . . . . . . 59
4.3. Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.1. Profiling de alto nivel . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.2. Profiling de bajo nivel . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.3. Simulación: picos teóricos de transferencia . . . . . . . . . . . . 67
4.4. Mejoras realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.1. Estrategias evaluadas . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.2. Asignación de carriers . . . . . . . . . . . . . . . . . . . . . . . 74
4.4.3. Mejoras en el algoritmo de demodulación . . . . . . . . . . . . . 76
4.4.4. Mejoras en el algoritmo de decodificación convolucional . . . . . 77
Índice general
5. Evaluación experimental 81
5.1. Pruebas en software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.1.1. Pruebas individuales . . . . . . . . . . . . . . . . . . . . . . . . 82
5.1.2. Pruebas acumulativas . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.3. Pruebas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2. Pruebas en hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.2.1. Pruebas sobre el transmisor . . . . . . . . . . . . . . . . . . . . 92
5.2.2. Pruebas sobre el receptor . . . . . . . . . . . . . . . . . . . . . . 94
5.2.3. Pruebas con transmisor y receptor . . . . . . . . . . . . . . . . . 95
Bibliografía 103
C. Glosario 113
Capítulo 1
Introducción
1.1. Motivación
Las Radios Definidas por Software (Software Defined Radios, SDR) son un tipo
de sistema de radiocomunicación en donde todos o algunos de los componentes que
realizan el procesamiento de la señal han sido implementados mediante software que
ejecuta en un procesador de propósito general1 . Ejemplos convencionales de este tipo de
procesadores son los que se encuentran en las computadoras de escritorio o portátiles,
así como en dispositivos móviles.
Las SDR han sido motivo de interés, tanto para el ámbito académico como para el
sector de las telecomunicaciones, por más de veinte años. Cuando a principios de la
década de los 90 fuera inventado el término en [1], hubo una revolución importante en la
forma de pensar la ingeniería de radio que generó un nuevo abanico de posibilidades. Sin
embargo, no ha sido sino hasta recientemente que las SDR han empezado a convertirse
en una potente solución de uso amplio y accesible, y una importante alternativa a
considerar frente a las radios convencionales.
Esta evolución se ha debido a varios factores, entre los cuales se encuentran los
avances significativos en las tecnologías de procesamiento digital, conversores análogo-
digital y digital-análogo, herramientas de software y hardware de radio, así como a la
mejora en la tecnología de los microprocesadores.
Además de esto, que el procesamiento de la señal se realice a nivel de software y no
mediante hardware dedicado presenta un conjunto importante de ventajas que la radio
convencional no puede brindar. En primer lugar, permite un mayor nivel de abstracción
para el diseñador, lo que redunda en una tarea de diseño e implementación más sencilla
1
Se utilizará el acrónimo GPP (General Purpose Processor ) para referirse a los procesadores de
propósito general.
1
1.2. Objetivos 2
y que puede realizarse en menos tiempo. En segundo lugar, el mismo hardware (típica-
mente un GPP) puede reutilizarse con diferentes implementaciones de transceptores2 ,
siendo estos últimos sistemas capaces de transmitir y recibir información a través de
un canal de comunicación utilizando un protocolo de comunicación determinado. En
tercer lugar, el código puede ser modificado fácilmente, otorgando una gran flexibilidad
en tiempo real que permite, por ejemplo, realizar actualizaciones sobre una implemen-
tación existente. Por último, el código fuente puede ser compartido a gran escala entre
programadores, ingenieros e investigadores.
Las razones antes expuestas han motivado que las SDR se hayan vuelto, cada vez
en mayor medida, una herramienta importante tanto para la educación como para la
investigación y el desarrollo. En particular, destaca la capacidad de prototipado de
nuevos algoritmos y paradigmas.
Los últimos avances en las tecnologías de SDR han fomentado la aparición tanto de
plataformas de hardware SDR con suficiente poder computacional como para operar
en un rango amplio de frecuencias y anchos de banda, como de entornos de desarrollo
de software con funcionalidades de alto nivel sobre distintas plataformas, incluyendo
un amplio conjunto de módulos y algoritmos y una curva de aprendizaje razonable.
Estos avances hacen que la plataforma (en su conjunto) sea idónea para el desarrollo
de prototipos, pero aún están lejos de permitir su uso en implementaciones comerciales
de estándares modernos, como lo son Wi-Fi, 3G y LTE, principalmente por presentar un
rendimiento inferior al de una radio convencional implementada en hardware dedicado.
Esta realidad motiva el presente trabajo, en donde se intenta avanzar en el desempeño
de las implementaciones de SDR, de manera de acercar el uso comercial de dicha
tecnología.
1.2. Objetivos
En primer lugar, se planteó el objetivo de realizar un estudio de las bases teóricas que
permiten implementar comunicaciones inalámbricas a nivel físico. Dado que el proyecto
se enmarca en el ámbito de la carrera Ingeniería en Computación, en la cual dichos
temas no se estudian en profundidad, este objetivo cobró una importancia especial para
lograr un entendimiento completo del temario a tratar.
En segundo lugar, se planteó el objetivo de realizar un estudio del estado del arte
de las radios definidas por software, del estándar Wi-Fi3 y de OFDM4 . Esto incluyó
2
Un transceptor es un dispositivo capaz de realizar tanto la transmisión como la recepción de una
señal.
3
Estándar IEEE 802.11.
4
OFDM significa Orthogonal Frequency Division Multiplexing, Multiplexación por División de
Frecuencias Ortogonales, que es un tipo de modulación que codifica la información de una manera
especial. Dicho esquema de modulación se encuentra explicado con detalle en la Sección 2.3.
2
Capítulo 1. Introducción
3
1.3. Estructura del documento 4
Por último, el documento cuenta con tres anexos. El Anexo A explica cómo reali-
zar una instalación completa de GNU Radio junto con todos los módulos que fueron
utilizados para llevar a cabo este proyecto. En el Anexo B se explica cómo crear un
bloque en la herramienta GNU Radio. El Anexo C contiene el Glosario de términos de
uso común.
4
Capítulo 2
Conceptos Teóricos
2. Utilizar una abstracción digital permite procesar datos utilizando algoritmos so-
fisticados, que eventualmente pueden lograr mejorar la calidad y eficiencia de los
componentes de un sistema.
5
2.1. Comunicación analógica y digital 6
Cada señal individual se puede pensar como una onda con voltaje fijo mantenida
por algún período de tiempo. Por lo tanto, para enviar un bit 0 se transmitirá una señal
1
Existen muchas razones por las cuales la salida de un enlace difiere de su entrada, tales como
la tolerancia de sus componentes internos, factores del entorno (temperatura, voltaje suministrado) y
factores externos (interferencia de otros transmisores cercanos, etc.). Todas estas fuentes pueden ser
definidas de manera colectiva como ruido o distorsión.
2
El voltaje es una magnitud física que cuantifica la diferencia de potencial eléctrico entre dos
puntos.
3
Extraído de [4].
6
Capítulo 2. Conceptos Teóricos
con un voltaje constante de V0 por un cierto periodo de tiempo, y para enviar un bit
1 se hará lo mismo con V1 . Estas señales de tiempo continuo se representan utilizando
muestras discretas, en donde la tasa de muestreo se define como el número de muestras
por segundo que se utiliza en el sistema. Tanto el transmisor como el receptor deben
acordar la tasa de muestreo con anterioridad. El recíproco de la tasa de muestreo es el
intervalo de muestreo.
Sobre un enlace de comunicaciones, el transmisor y el receptor deben acordar la
tasa del reloj. De esta manera, eventos periódicos serán temporizados por un reloj.
Cada nuevo bit es enviado cuando ocurre una transición en el reloj, y por cada bit se
envían varias muestras, a una tasa regular. Por lo tanto, ¿cómo hace el receptor para
recuperar los datos enviados, siendo que el transmisor solamente envía las muestras sin
el reloj?
La idea es que el receptor infiera la presencia de un tic del reloj cada vez que hay una
transición en el valor de las muestras recibidas. Luego, puesto que existe una tasa de
muestreo acordada previamente, el receptor puede deducir la posición del resto de los
tics del reloj, obteniendo la primera y última muestra para cada bit. Para lograr mayor
robustez, es posible elegir la muestra del medio para determinar el bit del mensaje, o
promediar todas las muestras recibidas.
Para que este enfoque funcione, existen dos problemas que deben ser resueltos:
1. ¿Cómo lidiar con las diferencias entre las frecuencias de los relojes del transmisor
y del receptor?
2. ¿Cómo asegurar que existe una cantidad suficiente de transiciones entre 0s y 1s?
Tanto el transmisor como el receptor utilizan un reloj interno que corre a la tasa
de muestreo para determinar cuándo generar o adquirir la siguiente muestra. Además,
ambos guardan un índice de muestreo que contiene la posición de la muestra actual,
así como contadores para almacenar la cantidad de muestras que hay en cada bit.
El problema es que las frecuencias de los relojes utilizados por el transmisor y el
receptor podrían no ser exactamente iguales. Esta pequeña diferencia se acumula con
el tiempo, por lo que si el receptor utiliza una estrategia de muestreo estático como
la descrita anteriormente, eventualmente ocurrirá que se estará realizando el muestreo
exactamente en el punto de transición entre dos bits consecutivos. Además, la diferencia
entre las frecuencias de reloj suele cambiar con el tiempo.
La solución consiste en hacer que el receptor adapte su temporización en base a
las transiciones que detecta en las muestras recibidas. La transición debería ocurrir
exactamente a la mitad entre dos puntos de muestreo consecutivos, por lo que si el
7
2.1. Comunicación analógica y digital 8
receptor determina que no existe una transición en ese punto, debería ajustar su índice
de muestreo de forma apropiada.
Existen dos situaciones posibles:
8
Capítulo 2. Conceptos Teóricos
Por estas razones, se estila utilizar una nueva señal, llamada carrier (portadora). La
principal propiedad del carrier es que es una señal apta para ser transmitida a través
del canal de comunicación físico en cuestión. Se dice que se modula esta última señal,
cuando se perturban distintas propiedades de la misma con el objetivo de transmitir
la información codificada en la señal base. Las propiedades que pueden perturbarse
o modificarse son la amplitud, la frecuencia y la fase de la señal. Existen técnicas de
modulación que modifican cada una de estas propiedades e incluso las combinan para
lograr transmitir información en forma más rápida, pero a su vez, lo más robustamente
posible; esto es, que la modulación sea tolerante a errores en la transmisión producto
del ruido del entorno y demás factores.
Del lado del receptor, lo que se recibe es la señal carrier modulada, y se quiere recu-
perar la secuencia de bits original. Los pasos a seguir son los inversos a la transmisión,
por lo que primero se debe obtener la señal base a partir de la señal modulada para
luego decodificar cada bit. Al proceso de convertir la señal carrier modulada en la señal
base se le llama demodulación.
El escenario ideal sería que la señal base demodulada en el receptor fuera comple-
tamente idéntica a la señal que se moduló del lado del transmisor. Esto en la realidad
no se cumple por diversas razones, como por ejemplo el ruido sobre el canal de co-
municación, o por propiedades físicas inherentes al canal que no permiten hacer una
transición instantánea entre valores consecutivos que se estén modulando, resultando
en una señal más relajada que al demodular afecta la señal base demodulada. De esta
forma, la señal base se encuentra transformada en el receptor, y se puede abstraer
este fenómeno obviando algunos detalles de lo que sucede en la realidad y modelar la
transformación de la señal base de la forma que se describe en la Figura 2.1, donde:
9
2.1. Comunicación analógica y digital 10
X[n] es la señal base original que representa la secuencia de bits que se desea
transmitir.
En este modelo, la señal base sufre una transformación S al ser transmitida. Este
comportamiento que presentan los canales de transmisión se puede modelar de forma
bastante precisa utilizando modelos lineales e invariantes en el tiempo.
Figura 2.1: Transmisión de información del transmisor al receptor. Extraído de [4], Capítulo 10.
Que un sistema sea lineal significa que satisface el principio de superposición, que
engloba las propiedades de proporcionalidad o escalado y aditividad. Que sea propor-
cional significa que cuando la entrada de un sistema es multiplicada por un factor, su
salida también será multiplicada por el mismo factor. Por otro lado, que un sistema sea
aditivo significa que si la entrada es el resultado de la suma de dos entradas, la salida
será la resultante de la suma de las salidas que producirían cada una de esas entradas
individualmente.
Por su parte, un sistema se dice invariante en el tiempo si dada una señal x[t] cuya
respuesta es y[t], se puede mover esa señal en el tiempo hacia el futuro o hacia el pasado
(sumando o restando un entero a t), y la respuesta en el instante t movido sigue siendo
la misma que antes de realizar el desplazamiento.
A modo de resumen, muchas veces el canal de comunicación no soporta la transmi-
sión de la señal base como se tiene, o es inviable transmitir determinada señal base por
el tamaño de la antena que requeriría recibir esa señal, o también puede ser que no sea
posible transmitir determinada señal porque viola aspectos regulatorios del gobierno.
Por estas razones, hay que buscar otra forma de poder transmitir esa señal, a través
de un canal de comunicación dado.
Un concepto muy relacionado con la modulación de una señal es el de multiplexado
de frecuencias en un canal de comunicación. Esto significa hacer uso de un canal para
transmitir múltiples señales al mismo tiempo y lograr que las mismas no interfieran
unas con otras.
En el caso del aire, por ejemplo, en todo momento existen muchas señales compar-
tiendo el canal de comunicación. El receptor no recibe una única señal del transmisor,
sino una señal compuesta por señales generadas por distintos transmisores, entre ellos,
10
Capítulo 2. Conceptos Teóricos
el que al receptor le interesa. Las dos principales razones por las cuales funciona el
multiplexado de señales en un canal de comunicación como el aire son:
Esto está asegurado por la propiedad de linealidad, que garantiza que si una señal
está formada por una combinación de sinusoides, la señal recibida por el receptor será
también una combinación de sinusoides donde cada una es la señal recibida de cada
sinusoide que conforma la señal origen.
Para poder conceptualizar mejor el proceso de modulación es necesario entender el
espacio de señales. Así como en el plano uno puede describir cualquier vector como
una combinación lineal de los vectores (1, 0) y (0, 1), lo mismo sucede en el espacio de
señales. Este conjunto de elementos a partir del cual se puede construir todo el resto se
llama conjunto básico o conjunto elemental. La propiedad principal que deben cumplir
las funciones base para que puedan pertenecer a este conjunto es la de ortogonalidad
entre ellas, que se define formalmente de la siguiente manera:
Z+∞
1 i=j
φi (t)φj (t) dt = , (2.1)
6 j
0 i=
−∞
donde tanto φi como φj son funciones del conjunto elemental. En el caso del espacio
de señales, estas funciones son el seno y el coseno, que claramente cumplen el principio
de ortogonalidad.
De esta manera surge una nueva forma de representar una señal. Se definen las
señales I y Q, formadas a partir del conjunto elemental (el coseno y el seno respec-
tivamente) y que combinadas representan cualquier señal del espacio de señales. Esta
división no es solo conceptual. A nivel de hardware, las señales son generadas por se-
parado y combinadas más adelante. Esto presenta varias ventajas, como por ejemplo
un diseño de hardware simple. Tanto la energía de la señal como la fase se pueden
representar a partir de estas señales base.
11
2.1. Comunicación analógica y digital 12
Los diagramas de constelación son una herramienta útil para visualizar gráficamen-
te las componentes I y Q que forman la señal que se está analizando. El diagrama
representa la señal en el plano complejo, siendo I el eje horizontal y Q el eje vertical.
A medida que se muestrea la señal, se agrega un punto al diagrama por cada muestra,
por lo que eventualmente pueden haber puntos superpuestos. La Figura 2.2 muestra
un ejemplo de diagrama de constelación.
Los diagramas de constelación son siempre a nivel de señal base, o lo que es lo
mismo, cuando la frecuencia del carrier es 0.
Se presentan en esta sección los tipos de modulación más comunes que se utilizan
en la comunicación de datos. La información sobre modulaciones fue extraída de [3].
• Binary Phase Shift Keying (BPSK): Solo se puede representar un bit por
cada símbolo de la onda. Se modula utilizando como carrier únicamente al
coseno, es decir, la componente Q del carrier tiene amplitud nula. Por esto
mismo, su diagrama de constelación solo presentará puntos a lo largo del eje
X de un plano cartesiano.
• Quadrature Phase Shift Keying (QPSK): Se pueden representar dos bits
por símbolo. Es equivalente a BPSK, pero en este caso se utilizan ambas
componentes del carrier, tanto en I como en Q. La gran ventaja que tiene
sobre BPSK es que duplica la cantidad de información enviada por símbolo,
sin hacer que el algoritmo sea más vulnerable al ruido, ya que la diferencia
es que se utiliza una componente que es ortogonal a la primera, que estaba
12
Capítulo 2. Conceptos Teóricos
13
2.2. Códigos convolucionales 14
14
Capítulo 2. Conceptos Teóricos
en la Figura 2.3. Las operaciones de combinación utilizadas son sumas módulo 2 (es
decir, equivalentes al or-exclusivo). La ventana deslizante se mueve de a un bit, lo
que significa que distintas ventanas pueden superponerse. El tamaño de la ventana es
importante, y se denota con la letra K (mayúscula). Cuanto más grande es el tamaño de
la ventana, más son los bits de paridad influenciados por un bit de mensaje dado. Puesto
que los bits de paridad son los únicos enviados por el canal, un tamaño de ventana
grande generalmente implica una resistencia mayor a errores de bit. Sin embargo, un
tamaño de ventana mayor también implica un tiempo de decodificación mayor.
Un código convolucional que produzca r bits de paridad por ventana y que deslice
la misma hacia adelante un bit por vez tendrá una tasa efectiva de 1/r. Cuanto más
grande sea el valor de r, más resistencia a errores tendrá el código, pero también se
dedicará un mayor ancho de banda para enviar datos redundantes. En la práctica, se
intenta elegir valores de r y de tamaño de ventana lo más pequeño posibles, y que
mantengan baja la probabilidad de errores de bit.
El proceso final es simple. El transmisor puede ver hasta K bits en un momento
dado, y producir r bits de paridad según las funciones de cálculo, escogidas previamente,
que operan sobre subconjuntos de los K bits. La Figura 2.3 muestra un ejemplo en
donde K = 3 y r = 2 (la tasa del código es 1/r = 1/2). El transmisor genera r bits
y los envía de manera secuencial, desliza la ventana hacia la derecha un bit y luego
repite el proceso.
Figura 2.3: Ejemplo de un código convolucional con dos bits de paridad por cada bit de mensaje y
un tamaño de ventana de tres. Extraído de [4], Capítulo 7.
Xk−1
pi [n] = ( gi [j]x[n − j]) (2.2)
j=0
15
2.2. Códigos convolucionales 16
Existen dos formas de ver al codificador convolucional que son útiles a la hora
de implementar los procedimientos de codificación y decodificación. La primera es
en términos de registros de desplazamiento (shift), puesto que es posible construir
el mecanismo de codificación conectando distintos registros de desplazamiento. Esta
vista es útil para implementar codificadores a nivel de hardware. La segunda es en
términos de una máquina de estados, que se corresponde a la vista de un codificador
como un conjunto de estados con transiciones bien definidas entre ellos. Esta vista es
extremadamente útil para deducir cómo decodificar un conjunto de bits de paridad y
reconstruir el mensaje original.
La Figura 2.4 muestra el mismo codificador de la Figura 2.3 en la forma de diagrama
de bloques, utilizando registros de desplazamiento. Los valores x[n − 1] y x[n − 2]
componen el estado del codificador. El diagrama muestra cómo se toma un bit a la
vez (x[n]) y se generan dos bits de paridad de salida (p1 [n] y p2 [n]). El cálculo se
realiza utilizando tanto el bit de entrada como los que están guardados en el estado del
codificador. Luego de que se producen r bits, el estado del codificador se desplaza un
lugar a la derecha: x[n] toma el lugar de x[n − 1] y x[n − 1] el de x[n − 2]. Este diagrama
se puede implementar directamente en hardware con registros de desplazamiento.
Figura 2.4: Vista del proceso de codificación convolucional utilizando registros de desplazamiento.
Extraído de [4], Capítulo 7.
La otra forma útil de ver a los códigos convolucionales es como una máquina de
estados, tal como se muestra en la Figura 2.5 (que continúa con el ejemplo de la Figu-
ra 2.3). Es importante destacar que la máquina de estados para un código convolucional
es idéntica para todos los códigos que tengan un mismo tamaño de ventana K y que el
número de estados es siempre 2K−1 . Solamente las etiquetas pi cambian dependiendo
16
Capítulo 2. Conceptos Teóricos
del número de generadores polinomiales y de los valores de sus coeficientes. Cada esta-
do se etiqueta con x[n − 1]x[n − 2] . . . x[n − K + 1]. Por su parte, cada arco se etiqueta
con x[n]/p0 p1 . . ..
Figura 2.5: Vista del proceso de codificación convolucional mediante una máquina de estados. Ex-
traído de [4], Capítulo 7.
La vista de máquina de estados ofrece una forma elegante de explicar qué es lo que
hace el transmisor, y qué es lo que debe hacer el receptor para decodificar el mensaje.
El transmisor comienza en el estado inicial y procesa el mensaje un bit a la vez. Por
cada bit de mensaje, hace las transiciones de estado desde el estado actual al siguiente
dependiendo del valor del bit de la entrada, y envía los bits de paridad que se encuentran
en el arco correspondiente.
El receptor no tiene conocimiento directo de las transiciones de estado que llevó
a cabo el transmisor al enviar el mensaje, sino que solamente conoce la secuencia de
bits de paridad recibidos (posiblemente con errores). Su tarea es determinar la mejor
secuencia de estados posible que pudo haber producido la secuencia de bits de paridad
que recibió. Existen muchas formas de definir “mejor secuencia de estados posible”, pero
una que es especialmente atractiva es la de secuencia de estados con mayor probabilidad
de haber sido enviada por el transmisor. Un decodificador que sea capaz de realizar esta
tarea se llama decodificador de máxima verosimilitud (maximum-likelihood decoder ), o
decodificador ML, como se lo llamará de aquí en adelante.
Una propiedad muy útil que se cumple para todos los códigos convolucionales6 es
que el decodificador ML puede hallarse computando el código (válido) que tenga la
menor distancia de Hamming 7 con el código recibido, y devolviendo el mensaje que
6
Esta propiedad no solo se cumple para los códigos convolucionales, sino también para otra clase
de códigos llamada códigos de bloque, independientemente de que el código sea lineal o no.
7
La distancia de Hamming entre dos códigos se define como el número de posiciones de bit en que
dichos códigos difieren.
17
2.2. Códigos convolucionales 18
haya generado dicho código. Por lo tanto, la secuencia de bits de paridad con mayor
probabilidad de haber sido enviada debe ser aquella que guarde la menor distancia de
Hamming con la secuencia recibida.
Determinar el código válido más cercano a un código recibido es una tarea difícil
de realizar en la práctica (especialmente para códigos convolucionales), puesto que la
cantidad de códigos posibles es infinita (o al menos tan larga como se desee). Esto
significa que el procedimiento de recorrer la lista completa de posibles mensajes trans-
mitidos es intratable desde el punto de vista computacional, y hace necesario encontrar
un mecanismo que permita recorrer el espacio de posibilidades y encontrar el mensaje
válido (aquel con distancia de Hamming más pequeña) de manera rápida. La resolu-
ción de este problema, que es además el corazón del decodificador de Viterbi, utiliza
una estructura derivada de la máquina de estados llamada trellis, que se describe a
continuación.
La vista de máquina de estados permite conocer qué ocurre en cada instante de
tiempo cuando el transmisor tiene un bit de mensaje para procesar, pero no permite
conocer cómo el sistema evoluciona en el tiempo. La trellis es una estructura que hace
explícita esta evolución; un ejemplo se muestra en la Figura 2.6. Cada columna de
la trellis tiene el conjunto de estados; cada estado en una columna se conecta a dos
estados en la siguiente columna (los mismos dos estados conectados en la máquina de
estados). El arco superior de cada estado muestra qué se transmite si el bit actual es un
0, mientras que el arco inferior muestra qué se transmite ante un 1. La imagen muestra
el recorrido en la trellis para el mensaje 101100.
Figura 2.6: Recorrido en la trellis para el mensaje 101100. Extraído de [4], Capítulo 7.
Esta herramienta ofrece una nueva manera de pensar en la tarea del decodificador.
El mismo obtiene una secuencia de bits de paridad, y debe determinar el mejor camino
18
Capítulo 2. Conceptos Teóricos
19
2.2. Códigos convolucionales 20
Figura 2.7: La métrica de rama, BM. En este ejemplo, el receptor recibe los bits de paridad 00.
Extraído de [4], Capítulo 8.
Supóngase que el receptor tiene computadas las métricas de camino P M [s, i] para
cada estado s en el tiempo i. El valor de P M [s, i] es el número total de errores de
bit detectados al comparar los bits de paridad recibidos con el mensaje que tiene la
mayor probabilidad de haber sido transmitido (si se consideran todos los mensajes que
pudieron haber sido enviados por el transmisor hasta el tiempo i, empezando desde el
estado 00).
De entre todos los estados posibles en el tiempo i, el estado más probable es aquel
con la menor métrica de camino. Si hay más de un estado que cumpla esto, todos son
posibilidades igualmente buenas.
Si el transmisor se encuentra en el estado s en el tiempo i + 1, entonces necesaria-
mente debe haber estado en uno de dos estados posibles en el tiempo i. Estos dos estados
previos, etiquetados α y β, son siempre los mismos para un estado dado. De hecho,
solamente dependen de la longitud de ventana K (y no de las funciones de paridad).
La Figura 2.7 muestra los estados previos de cada estado. Por ejemplo, para el estado
00, α = 00 y β = 01, mientras que para el estado 01, α = 10 y β = 11.
Cualquier secuencia que deje al transmisor en el estado s en el tiempo i + 1 debe
haber dejado el transmisor en el estado α o β en el tiempo i. Por ejemplo, en la
20
Capítulo 2. Conceptos Teóricos
Figura 2.7, para llegar al estado 01 en el tiempo i + 1 debe cumplirse una de las dos
propiedades que se listan a continuación:
En resumen:
2. Comparar las sumas para los caminos que llegan al nuevo estado. Existen so-
lamente dos caminos posibles a comparar en cada nuevo estado debido a que
solamente hay dos aristas incidentes desde la columna previa.
21
2.2. Códigos convolucionales 22
Figura 2.8: Funcionamiento del decodificador de Viterbi, para cuatro momentos en el tiempo. La
última imagen muestra solamente los caminos sobrevivientes. Extraído de [4], Capítulo 8.
22
Capítulo 2. Conceptos Teóricos
tienen la misma métrica de camino. En este punto, cualquiera de estos cuatro estados
(con los caminos que llegan a ellos) son secuencias de bit con mayor probabilidad
de haber sido transmitidas, todas con una distancia de Hamming de 2. Un camino
sobreviviente es aquel con mayor probabilidad (un camino ML); hay muchos otros
caminos que pueden ser eliminados puesto que no hay forma de que sean caminos ML.
La razón por la cual el algoritmo de Viterbi es práctico es que el número de caminos
sobrevivientes es muchísimo más pequeño que el número total de caminos en la trellis.
Otro punto importante es que el conocimiento futuro permite romper cualquier tipo
de empate, causando que ciertos caminos, que habían sido considerados como de mayor
probabilidad, sean eliminados a la luz de la nueva información.
2.2.4. Puncturing
23
2.3. Multiplexación por División de Frecuencias Ortogonales (OFDM) 24
Tabla 2.1: Tasa de datos vs. tamaño del área en la cual no hay multipath. Extraído de [2].
24
Capítulo 2. Conceptos Teóricos
Figura 2.9: Multiplexado convencional de división de frecuencia para subcarriers. Extraído de [2].
ZT
n m
cos(2π[ ]t) cos(2π[ ]) dt = 0 para m 6= n (2.4)
T T
0
25
2.3. Multiplexación por División de Frecuencias Ortogonales (OFDM) 26
extensión cíclica del símbolo original. La porción de cada subcarrier que ocurre durante
el período de tiempo correspondiente al intervalo de guarda simplemente se repite al
final del intervalo base. Puesto que todos los subcarriers son periódicos en el tiempo
T , esto es el equivalente a realizar la misma operación sobre el símbolo final, que es la
suma de todos los subcarriers. El símbolo resultante preserva la ortogonalidad de sus
subcarriers sobre el intervalo T incluso si el inicio del intervalo se encuentra apenas
fuera de lugar, puesto que la porción que se quita del principio es agregada hacia el
final. Esto se ilustra en la Figura 2.10.
Figura 2.10: La extensión cíclica de un símbolo en OFDM hace que la integración no cambie, incluso
ante la existencia de pequeñas desviaciones de tiempo. Extraído de [2].
26
Capítulo 2. Conceptos Teóricos
Figura 2.11: Transformada discreta de Fourier de una señal muestreada en el tiempo. Extraído de
[2].
Es fácil ver por qué el número de frecuencias está limitado al número de muestras.
Un seno o un coseno con una frecuencia de N + 1 tiene los mismos valores en los puntos
de muestreo que uno con frecuencia δ : cos[2π(N +1)δτ ] = cos[ 2(NN+1)τ
τ
] = cos[ 2π(1+1)
N
]=
cos[2π + 2πδτ ] = cos(2πδτ ). Este fenómeno es conocido como aliasing. Por el mismo
argumento, los valores son los mismos en k = ± N2 .
En la Ecuación 2.5 se muestra el desarrollo básico para la transformada de Fourier.
La transformada de Fourier es aproximada mediante una suma, en donde el n-ésimo
punto de muestreo, f (n), está multiplicado por el valor de la exponencial para la
frecuencia de interés, k. Al sustituir el incremento de frecuencia, se deduce que la suma
es independiente tanto del incremento como del incremento de frecuencia δ, y está
determinado únicamente por el valor de N y f para un valor dado de k. La parte
entre paréntesis es llamada usualmente transformada discreta de Fourier, con el factor
τ añadido posteriormente para ajustar el tiempo y la escala de frecuencias.
X
F [kδ] = τ e−2πinkδτ f (n) = τ [f (0) + e−2πikδt f (1) + e−(2π)2ikδτ f (2) + . . .]
n
1 n
X X
=τ e−2πink( N τ )τ f (n) = τ e−2πik( N )f (n)
n n
1 2
−2πik( N ) −2πik( N )
= τ [f (0) + e f (1) + e f (2) + . . .] (2.5)
27
2.3. Multiplexación por División de Frecuencias Ortogonales (OFDM) 28
ningún cálculo, es importante notar que luego del reordenamiento los términos entre
paréntesis se ven como transformadas con N = 2.
Figura 2.13: Reagrupación de la suma por cada fila en la transformada. Extraído de [2].
28
Capítulo 2. Conceptos Teóricos
29
2.3. Multiplexación por División de Frecuencias Ortogonales (OFDM) 30
30
Capítulo 3
La Figura 3.1 muestra de forma gráfica los distintos campos y su disposición dentro
de una trama.
El orden del conjunto de campos mencionados es fijo. Sin embargo, no todas las
tramas tienen la misma cantidad o los mismos tipos de campos presentes. Los primeros
tres, Frame Control, Duration (duración) y Address 1 (dirección 1), y el último, Frame
Check Sequence, están presentes en todas las tramas, incluyendo a los tipos y subtipos
31
3.1. Estándar Wi-Fi 32
Figura 3.1: Representación gráfica del formato de trama de 802.11. Extraído de [8].
El campo Frame Control contiene, entre otros, la versión del protocolo, el tipo y
subtipo, información sobre fragmentación y protección de paquetes, y más campos de
control. Su formato se encuentra ilustrado en la Figura 3.2.
Figura 3.2: Representación gráfica del formato del campo Frame Control. Extraído de [8].
32
Capítulo 3. Estado del arte
distintos subtipos. A modo de ejemplo, dentro de las tramas de datos, hay algunas
que implementan QoS y otras que no1 .
Más datos (campo More Data): El campo More Data, de 1 bit de longitud, es
utilizado para indicarle a una estación que se encuentre en modo de bajo consumo
de energía de la recepción de nuevos paquetes6 para dicha estación por parte del
punto de acceso7 . El campo More Data solamente es válido para las tramas de
datos o gestión que sean direccionables de manera individual y transmitidas por
un punto de acceso a una estación en modo de bajo consumo de energía. Un
valor de 1 indica que hay presente al menos un nuevo paquete almacenado para
la misma estación.
1
Para ver la lista completa de los tipos de tramas definidos por estos campos, se puede consultar
el estándar Wi-Fi (ver [8, p. 383]).
2
DS, Distribution System, es el sistema utilizado para interconectar estaciones y redes de área
local.
3
MSDU, MAC Service Data Unit, es la información transmitida como una unidad entre dos puntos
de acceso.
4
MMPDU, MAC Management Protocol Data Unit, es la unidad de datos intercambiada entre dos
entidades para implementar el protocolo de gestión de MAC.
5
STA, Station, es una entidad lógica direccionable de manera única en el contexto de capas MAC
y física.
6
El estándar Wi-Fi se refiere a estos paquetes como Bufferable Units, que podría traducirse como
unidades almacenables.
7
AP, Access Point, es una entidad que provee acceso a los servicios de distribución para las
estaciones asociadas.
33
3.1. Estándar Wi-Fi 34
En tramas transmitidas por estaciones no-QoS y por los PC9 durante el CFP, el
campo Duration/ID se coloca con el valor fijo de 32768.
34
Capítulo 3. Estado del arte
Dirección de grupo: Es una dirección multidestino, que puede ser usada por
una o más estaciones de la red en forma simultánea. Dentro de esta categoría se
distinguen dos subcategorías:
Campo SA: El campo SA contiene una dirección MAC IEEE individual que
identifica la entidad MAC desde la cual la transferencia del MSDU (o del frag-
mento) o A-MSDU contenido en el cuerpo de la trama fue iniciada.
Campo RA: El campo RA contiene una dirección MAC IEEE individual que
identifica la siguiente estación inmediata que debe ser la receptora de la informa-
ción contenida en el cuerpo de la trama en el medio inalámbrico actual.
10
BSS, Basic Service Set, es el conjunto de estaciones que se han sincronizado de manera exitosa
utilizando las primitivas correspondientes definidas en el estándar IEEE 802.11.
11
A-MSDU, Aggregate MSDU, es una estructura que contiene múltiples MSDUs transportados en
una única trama de capa MAC.
35
3.1. Estándar Wi-Fi 36
Campo TA: El campo TA contiene una dirección MAC IEEE individual que
identifica la estación que ha transmitido al medio inalámbrico la MPDU12 conte-
nida en el cuerpo de la trama.
Este campo contiene un CRC de 32 bits, calculado a partir de todos los campos del
cabezal MAC y del campo Frame Body.
12
MPDU, MAC Protocol Data Unit, es la unidad de datos intercambiada entre dos entidades MAC
usando los servicios de la capa física. MPDU es el sinónimo de “trama” que utiliza el estándar Wi-Fi.
36
Capítulo 3. Estado del arte
Organización lógica
La capa física de 802.11 tiene dos funciones de protocolo bien diferenciadas, las
cuales pueden ser clasificadas como subcapas dentro de la primera. Estas son la Physical
Layer Convergence Procedure (PLCP) y la Physical Medium Dependent (PMD).
La capa de enlace se comunica directamente con la capa física a través de la PLCP,
utilizando un Service Access Point (SAP) para realizar dicha comunicación. Es res-
ponsabilidad de la capa de enlace (también llamada capa MAC) indicar a la PLCP
que debe preparar MPDUs para la transmisión. Asimismo, la capa PLCP entrega las
tramas recibidas por la PMD a la capa de enlace. De esta forma, es natural pensar en
la PLCP como el puente entre la capa MAC y las transmisiones de la señal en el aire.
La existencia de esta capa permite un desacoplamiento importante entre la capa MAC
y la PMD, permitiendo definir la capa de enlace de forma genérica independientemente
de cómo la capa física transmite la señal en el medio, pudiendo ser mediante OFDM,
transmisión de luz infrarroja, etcétera.
La PLCP agrega un preámbulo y cabezal a los MPDUs recibidos desde la capa
MAC, que dependen de la implementación de capa física que se esté utilizando. Este
cabezal y preámbulo contienen información que es imprescindible para los transmisores
y receptores de capa física, ya que, por ejemplo, distintos métodos de modulación
requieren de distintos preámbulos. A la trama resultante de agregar el preámbulo y
cabezal a un MPDU, el estándar Wi-Fi la denomina PLCP Protocol Data Unit (PPDU).
El MPDU, a su vez, también puede ser llamado como PLCP Service Data Unit (PSDU),
y es típicamente referido de esta forma cuando se referencian operaciones de capa física
en el estándar.
37
3.1. Estándar Wi-Fi 38
Figura 3.3: Representación gráfica de los componentes de las capas MAC y física. Se puede ver de
forma clara que la comunicación entre las capas es a través de SAPs. También es posible observar
la organización de las mismas, en donde la PLCP oficia de intermediaria entre la MAC y la PMD,
y las subcapas de gestión se encuentran en el mismo nivel jerárquico que las capas que administran,
mientras que la SME accede a todas las interfaces de gestión. Extraído de [8], Capítulo 4.
Operaciones principales
Las operaciones que realiza la capa física son muy similares en todas las implemen-
taciones de la misma, por lo que se pueden definir de forma general. El estándar 802.11
utiliza máquinas de estado para describir estas operaciones. Cada máquina de estado
realiza alguna de las siguientes funciones:
38
Capítulo 3. Estado del arte
Transmisión: Esta función se utiliza para enviar datos a través del medio. La
operación es invocada por el PLCP CS/CCA luego de que se recibe un pedido
desde la capa MAC de tipo PHY-TXSTART.request. La capa MAC utiliza el
protocolo CSMA/CA con la ayuda de la operación de CS/CCA de la PLCP
antes de indicar que se debe transmitir la trama.
Una vez que se decide enviar la trama, la capa MAC envía el número de bytes
de datos (que debe ser un valor entre 0 y 4095) y la tasa de transmisión. Luego,
la PMD envía el preámbulo de la trama a la antena para que sea transmitido.
La tasa de transferencia del preámbulo varía según la implementación de capa
física que se esté utilizando. Una vez enviado el preámbulo se envía el cabezal,
cuya tasa de transmisión también depende de la implementación de capa física
utilizada. En el caso de OFDM, tanto el preámbulo como el cabezal de capa física
se envían a una tasa de 6 Mbps.
Una vez envíado el cabezal, el transmisor cambia la tasa de transferencia por la
que se especifica en el cabezal del PSDU enviado. Una vez finalizada la transmi-
sión del PSDU, la PLCP utiliza la primitiva TXSTEND.confirm para notificar
a la capa MAC que la transmisión fue exitosa, y cambia el modo del PMD de
transmisión a recepción.
Recepción: Esta función se utiliza para recibir datos desde el medio. La opera-
39
3.1. Estándar Wi-Fi 40
ción también es invocada por el PLCP CS/CCA una vez que ésta última detecta
una porción del preámbulo de sincronización seguido de un cabezal PLCP válido.
De esta forma, lo que se recibe realmente, es decir, lo que procesa la operación de
recepción, es únicamente la trama MAC, y no el cabezal PLCP ni el preámbulo,
que son consumidos por la operación de CS/CCA.
La PMD indica que el medio está ocupado cuando detecta una señal con un poder
de transmisión de al menos -85 dBm.
Cuando la PLCP verifica que el cabezal PLCP no contiene errores, le envía un
mensaje a la capa MAC notificándole que se está recibiendo una nueva trama
mediante la primitiva PHY-RXSTART.indicate. Luego, la PLCP inicializa en
cero un contador encargado de controlar la cantidad de bytes de PSDUs recibidos,
y a medida que la PLCP recibe bytes del PSDU, los envía a la capa MAC mediante
la primitiva PHY-DATA.indicate. Una vez que el contador de bytes alcanza el
valor que tenía el campo length del cabezal PLCP (es decir, se recibieron todos
los bytes del PSDU), la PLCP utiliza la primitiva PHY-RXEND.indicate para
indicar a la capa MAC que se terminó de recibir la trama.
40
Capítulo 3. Estado del arte
Figura 3.4: Representación gráfica del formato de un PPDU de capa física OFDM IEEE 802.11.
Extraído de [16].
41
3.1. Estándar Wi-Fi 42
Preámbulo
Figura 3.5: Formato de un cabezal PPDU de capa física OFDM IEEE 802.11. Extraído de [16].
Como se puede ver en la Figura 3.4, el campo de datos es el último del PPDU, y
el único en tener largo variable. Además, el mismo está compuesto por el campo de
servicio (SERVICE ), el PSDU, y los campos de TAIL y PAD.
42
Capítulo 3. Estado del arte
43
3.2. Radios definidas por software 44
se ejecutará el programa. Esto significa que una misma SDR puede ejecutarse en
distintas arquitecturas. También existe el caso en que no se tienen distintas ar-
quitecturas sino una sola con un diseño lo suficientemente genérico, (por ejemplo,
con un GPP), que soporta la ejecución de un gran número de SDRs distintas.
Este último aspecto tiene claras aplicaciones comerciales, donde la producción
masiva de un mismo producto en general abarata costos de producción y de esta
forma permite obtener una mayor ganancia al fabricante.
Teniendo todas estas características a favor, es posible preguntarse por qué es que
las SDRs no han reemplazado totalmente al enfoque tradicional en la construcción de
radios. El problema es que las SDRs también tienen algunas desventajas si se comparan
con las radios tradicionales, a pesar de que en los últimos años se ha logrado un avance
considerable en los puntos mencionados a continuación:
44
Capítulo 3. Estado del arte
En el presente trabajo se decidió trabajar con GNU Radio debido a que, además de
ser un software de alta calidad y muy bien considerado en el ámbito académico, es el
entorno de desarrollo en el cual se creó la versión original del transceptor OFDM IEEE
802.11 utilizado como punto de partida, como se verá con más detalle en la Sección
4.2.
GNU Radio16 es un framework gratuito y de código libre (open source) que provee
bloques de procesamiento de señales para implementar radios definidas por software y
DSPs genericos. GNU Radio puede ser utilizado en conjunto con hardware de radio-
frecuencia con el fin de transmitir y recibir señales en el medio, o también puede ser
utilizado solamente en software, en un ambiente de simulación pura. Creado en el año
2001, GNU Radio es utilizado extensivamente en la actualidad en ámbitos académicos,
comerciales y en el de la radioafición.
15
DSP significa Digital Signal Processor, Procesador Digital de Señales, que es un sistema basado
en un procesador que dispone de software optimizado para aplicaciones que requieren operaciones
numéricas a muy alta velocidad.
16
Para más información, ver [12].
45
3.3. GNU Radio 46
Bloques
GNU Radio define el concepto de bloque como una unidad funcional capaz de realizar
una tarea determinada, y que posee puertos de entrada y salida para poder recibir y
comunicar datos con otros bloques, respectivamente. Por trazar una analogía, un bloque
de GNU Radio se asemeja a lo que es una clase en un lenguaje orientado a objetos.
Los bloques se pueden clasificar en dos categorías:
Módulos
Todos los programas creados para ejecutar en GNU Radio son grafos de flujo (Flow
Graphs) donde los nodos del grafo son bloques y las aristas representan comunicación
17
El GNU Radio Source Tree refiere a los distintos módulos y bloques que pertenecen a la distri-
bución oficial de GNU Radio. Para más información, ver [14].
46
Capítulo 3. Estado del arte
entre bloques, es decir, los datos fluyen de un bloque a otro si están conectados por
una arista. Asimismo, las aristas son dirigidas, lo que determina la dirección en la cual
fluyen los datos. Un grafo de flujo puede ser ejecutado por GNU Radio para simular un
sistema de procesamiento de señales, o puede ser utilizado para definir bloques nuevos,
generando así los bloques de tipo jerárquicos.
El concepto de VOLK se introdujo por primera vez como parte del framework de
GNU Radio en diciembre del 201018 . VOLK es una biblioteca que contiene múltiples
funciones que realizan cálculos de operaciones matemáticas y que han sido programadas
utilizando un enfoque Single Instruction Multiple Data (SIMD) por los desarrolladores
y colaboradores de GNU Radio, poniendo especial foco en la eficiencia de la función.
A estas funciones se las denomina kernels.
A su vez, para cada uno de estos kernels se tienen varias implementaciones que han
sido programadas para distintas arquitecturas y distintos conjuntos de instrucciones. A
estas implementaciones se les denomina proto-kernels. Generalmente, dentro de las im-
plementaciones disponibles para una función determinada existe una lo suficientemente
genérica como para ejecutar en cualquier máquina (por ejemplo, una programada en
C).
El objetivo final de VOLK es brindar implementaciones que sean lo más eficientes y
rápidas posibles para la arquitectura donde se esté ejecutando el programa, de una for-
ma sencilla. En general, los kernels VOLK que existen realizan el cálculo de operaciones
matemáticas que son recurrentes en el campo del procesamiento de señales.
Al crear un grafo de flujo que utilice algún bloque que tenga soporte VOLK, solo
hace falta ejecutar el comando volk_profile para que el sistema determine cual de
los proto-kernels disponibles es el más eficiente dada la arquitectura donde se está
ejecutando. Para esto, se ejecutan una serie de pruebas que evalúan el rendimiento de
cada proto-kernel en tiempo real. Una vez realizada esta etapa, GNU Radio salva en
un archivo de configuración qué proto-kernel es el más eficiente para un kernel dado,
en esa arquitectura específica.
Los Polymorphic Data Types (PMTs) son un tipo de dato opaco propio de GNU
Radio diseñado para oficiar de contenedores génericos sobre datos con un tipo espe-
cífico (por ejemplo, strings, longs, complejos, etc.), de forma que estos contenedores
18
Para más información, ver [13].
47
3.3. GNU Radio 48
puedan ser pasados de forma sencilla entre distintos bloques y threads de GNU Ra-
dio, y expongan una interfaz en común. Son utilizados extensivamente en la interfaz
para pasaje de mensajes que provee GNU Radio, así como para definir etiquetas de
flujo (Stream Tags), que también son parte fundamental de los bloques de tipo Tagged
Stream, conceptos que se presentan en la siguiente sección.
GNU Radio fue concebido originalmente como un sistema que manejaba un flujo
de datos en el cual los mismos fluían de bloque en bloque en una única dirección,
sin ningún otro mecanismo para la comunicación entre bloques. Este modelo es muy
bueno cuando se trabaja con muestras, señales analógicas y bits entre otros, pero genera
complicaciones al momento de trabajar con datos de control, y datos empaquetados.
El concepto de un paquete, con inicio y fin definido, no podía ser modelado con el
esquema original de GNU Radio. Para solucionar estos problemas, se introdujeron dos
nuevos modelos de comunicación entre bloques: Stream Tags y Message Passing.
48
Capítulo 3. Estado del arte
se le añade una etiqueta a un ítem del flujo de datos principal (de ahí el término tag),
GNU Radio se asegura que dicha etiqueta acompañará al ítem etiquetado a medida
que este se desplaza dentro del flujo de datos.
La etiqueta es un objeto de tipo PMT, que tiene una clave que indica qué semántica
tiene el valor almacenado en la etiqueta, y un valor, que es un objeto de tipo PMT, es
decir, permite almacenar cualquier tipo de información. Por ejemplo, se podría utilizar
un Stream Tag para indicar el inicio de un paquete, y que la clave fuera length y el
valor el largo en bytes del paquete. De esta forma, bloques del grafo de flujo podrían
realizar determinadas acciones sobre este paquete, como extraer el cabezal en caso que
hubiese, entre otros.
49
3.4. Hardware para transmisión y recepción de señales en una SDR 50
en una SDR.
Actualmente existen varios dispositivos en el mercado con el fin de permitir a una
SDR transmitir y recibir información. En un artículo publicado en Enero de 2016 en
la IEEE Communications Magazine19 , se mencionan las empresas y productos más
influyentes al día de hoy en este tema. Algunas de estas son Ettus Research, ZedBoard
y NooElec.
En los artículos publicados por el autor del transceptor IEEE 802.11 OFDM que se
estudia en el presente trabajo, se menciona que el hardware para realizar la comunica-
ción con el medio es de la compañía Ettus Research, dentro de la línea de los Universal
Software Radio Peripheral (USRP). Más concretamente, las pruebas realizadas por el
autor de la implementación original fueron hechas con un USRP N210. En el caso de
este trabajo, como se verá más adelante, se realizaron pruebas con un USRP B210,
dispositivo que funciona de manera similar.
Por esta razón, se describen brevemente las antenas del tipo USRP debido a su
relevancia en este trabajo.
Las USRP son una línea de plataformas de hardware desarrolladas con el fin de im-
plementar algunas de las tareas que realiza una radio definida por software, producidas
por la compañía Ettus Research.
Particularmente, los USRPs cuentan con antenas, y se encargan de transmitir y reci-
bir señales en el aire. Estos dispositivos se conectan a las computadoras convencionales
a través de una conexión de red Ethernet, o de tipo USB. Existen algunos tipos de
USRP que poseen FPGAs20 integradas en sus circuitos, que permiten realizar alguna
tarea de procesamiento de señal y no solo transmitir y recibir la señal en el medio.
A pesar de que tanto GNU Radio como los USRPs son concebidos como dos pro-
ductos independientes que pueden interoperar con otros productos alternativos que
presenten la misma funcionalidad, existe una extensa documentación y soporte que se
centra en cómo construir SDRs utilizando USRPs en GNU Radio.
Una de las razones de esto es que el fundador de Ettus Research, Matt Ettus, es
también uno de los managers y principales encargados del proyecto GNU Radio. Como
consecuencia, el uso de USRPs es uno de los más populares, sino el más popular, para
transmitir y recibir señales en una SDR desarrollada en GNU Radio, y tanto en la
implementación original del transceptor como en el presente proyecto se mantiene esta
tendencia.
19
Para más información, ver [9].
20
Field Programmable Gate Array (FPGA) es un tipo de circuito reconfigurable que permite
realizar distintos tipos de operaciones con una eficiencia similar a la de un circuito dedicado.
50
Capítulo 4
Mejoras introducidas
4.1. Introducción
En este capítulo se presentan con un alto nivel de detalle todas las decisiones que
fueron tomadas a nivel de análisis, diseño e implementación para la realización de un
prototipo final que estuviera alineado con los objetivos del presente proyecto.
En primer lugar, se hará un análisis de la implementación del transmisor/recep-
tor IEEE 802.11 OFDM que fue tomada como punto de partida para este trabajo,
incluyendo los motivos de su elección y su funcionamiento detallado. En segundo lu-
gar, se detallará el procedimiento utilizado para localizar los bloques y funciones de
dicha implementación con mayor carga de trabajo, realizando un profiling 1 del sistema
en distintos niveles. Por último, se expondrán en detalle las mejoras realizadas a la
implementación original.
Debido a la gran magnitud del trabajo a realizar, se tomó la decisión de reutilizar una
implementación previa y funcional de un transmisor y receptor IEEE 802.11 OFDM.
Dicha implementación forma parte de un trabajo reciente que puede encontrarse en [5].
El código del transmisor y receptor se encuentra disponible bajo la licencia GPL v3.
Al proyecto que enmarca esta implementación del estándar Wi-Fi en GNU Radio
se lo denomina con el nombre de gr-ieee802-11. A lo largo de esta sección se utiliza
este nombre para referirse a la implementación original. Esta implementación es un
1
El profiling tiene como objetivo realizar un análisis de un software en ejecución y obtener medidas
sobre distintos aspectos del mismo. Para más información, ver la Sección 4.3.
51
4.2. Implementación original 52
52
Capítulo 4. Mejoras introducidas
Figura 4.1: Grafo de flujo del receptor visualizado en GNU Radio Companion.
Nótese que en el comienzo del grafo de flujo hay un bloque llamado USRP Source.
Este bloque oficia de interfaz entre una antena USRP conectada al equipo y el grafo
de flujo definido en GNU Radio. Como el bloque que recibe la señal y la introduce en
el grafo de flujo está desacoplado del procesamiento de la señal propiamente dicho, es
muy simple reemplazar la fuente de la señal por otro bloque que genere una señal de
distinta forma (por ejemplo, leyendo de un archivo del sistema de archivos). En estos
casos, el receptor funciona de la misma forma.
En etapas tempranas del presente trabajo, se utilizó el enfoque de generar la señal a
partir de un archivo, de forma de poder prescindir del USRP para evaluar características
generales de la operación de recepción. Esto se explica con más detalle en el Capítulo 5.
Detección de la trama
53
4.2. Implementación original 54
X−1
Nwin
a[n] = s[n + k]s[n + k + 16], (4.1)
k=0
X−1
Nwin
p[n] = s[n + k]s[n + k], (4.2)
k=0
|a[n]|
c[n] = , (4.3)
p[n]
en donde |a[n]| es la magnitud de a[n].
La autocorrelación de la señal es particularmente alta durante la Short Training
Sequence, que a su vez se corresponde con el inicio de la trama. De esta forma, la
estrategia está en calcular la autocorrelación de la señal y compararla con un umbral
para determinar si se está recibiendo una trama o no. Para esto, se define el concepto
de Plateau, que significa que tres muestras consecutivas se encontraron por encima del
umbral elegido. De esta forma, detectar el inicio de la trama equivale a detectar los
Plateaus que se reciben en la señal.
El bloque Delay recibe la muestra actual de la señal y la retrasa de forma tal que
quede alineada con la dieciseisava muestra posterior. A esta muestra retrasada se le
calcula la conjugada compleja y se multiplica el resultado por el valor inicial de la
muestra (el valor antes de retrasarla). Esto completa el cálculo para cada paso de
la sumatoria. El resultado final (es decir, la suma de cada paso) lo hace el bloque
Moving Average, que permite parametrizar el tope de la sumatoria fácilmente (valor
correspondiente al tamaño de la ventana Nwin ).
Por su parte, el bloque Complex to Mag calcula la magnitud de la autocorrelación
desnormalizada a[n], valor que se divide para calcular la autocorrelación normalizada
de la señal. Los bloques que realizan el cálculo de c[n] se muestran en la Figura 4.2.
Luego de esto, el bloque OFDM Sync Short se encarga de detectar los Plateaus en la
señal de autocorrelación, y en base a eso determina si envía las muestras a los bloques
sucesivos en el grafo de flujo de recepción o si las descarta.
54
Capítulo 4. Mejoras introducidas
Decodificación de la trama
Como se explicó en la Sección 3.1, la primera tarea a realizar una vez que se detecta
la trama se conoce como Frequency Offset Correction. Esta corrección es necesaria ya
que las frecuencias de los osciladores del transmisor y el receptor pueden estar levemente
desfasadas. Para compensar (y en el mejor caso, corregir), la implementación utiliza
un algoritmo que fue propuesto por primera vez en [20] y que hace uso de la Short
Training Sequence para determinar el desfase entre el transmisor y el receptor.
La idea básica del algoritmo de corrección es la siguiente. En un caso ideal, luego de
la detección de la Short Training Sequence, las muestras s[n] y la s[n+16] son idénticas,
ya que cada 16 muestras se repite el valor enviado. Sin embargo, debido al ruido del
canal y el desfase en la frecuencia de los osciladores, las muestras no son exactamente
iguales, y como consecuencia, s[n]s[n + 16] no siempre da como resultado un número
real. Ignorando el ruido, el argumento del producto anterior corresponde a la rotación
introducida por el desfase de frecuencias entre muestras multiplicada por 16, ya que
se acumuló un desfase correspondiente a 16 muestras enviadas. De esta forma, para
estimar el valor final se utiliza la siguiente fórmula:
Nshort −1−16
1 X
df = arg( s[n]s[n + k]), (4.4)
16 n=0
Este paso es implementado por el bloque OFDM Sync Long. Este bloque también es
responsable de realizar la tarea de alinear símbolos (Symbol Alignment). El objetivo de
la alineación de símbolos es calcular exactamente dónde empieza un símbolo, y extraer
los datos para luego enviarlos como entrada a un bloque que computa la Transformada
Rápida de Fourier (FFT). Esta alineación se hace con la ayuda de la Long Training
55
4.2. Implementación original 56
Sequence, que está compuesta por un patrón de 64 muestras que se repite dos veces.
Esta etapa utiliza una técnica llamada matched filtering, ya que a pesar de que es
costoso, la alineación debe ser extremadamente precisa.
El resultado de este bloque está listo para ser enviado al bloque que computa la
FFT, con la salvedad de que el bloque FFT tiene como entrada un vector de complejos
y el OFDM Sync Long tiene como salida un flujo (stream) de complejos. Para esto se
utiliza un bloque intermedio a modo de adaptador que realiza la conversión de flujo a
vector, llamado Stream to Vector. Una vez que se tiene el vector de complejos, se pasa
la información al bloque FFT, quien convierte la señal, que se encuentra en el dominio
del tiempo, al dominio de la frecuencia.
El próximo paso en el grafo de flujo de la decodificación de la trama es corregir el
desfase en la fase. Debido a que los tiempos de muestreo en el transmisor y receptor
no están sincronizados y a que la alineación de símbolos no es perfecta, se introduce
un desfase en la fase. Este desfase es lineal con la frecuencia, y es corregido utilizando
los subcarriers piloto.
La siguiente etapa es la de estimación de canal. Además de la fase, la magnitud de
los carriers también debe ser corregida. Esto es especialmente importante cuando se
utiliza un esquema de modulación 16QAM o 64QAM, donde la amplitud de la señal
se usa para codificar información. Las tareas de estimación de canal y de corrección
de desfase en la fase son realizadas por un mismo bloque, el OFDM Equalize Symbols.
Este bloque también se encarga de eliminar los subcarriers de guarda y pilotos, por lo
que consume 64 símbolos y produce 48 por ejecución.
El próximo bloque en el grafo de flujo es el OFDM Decode Signal. En cada trama,
tanto la Short Training Sequence como la Long Training Sequence son sucedidas por
un campo denominado Signal Field. Este campo contiene información sobre la longitud
y la codificación de los símbolos. La codificación de este campo es BPSK 1/2. Para
decodificar el código convolucional, se recurre a la biblioteca IT++.
Si el campo es decodificado sin problemas, es decir, si el campo SIGNAL contiene
un valor válido para la tasa, y además el bit de paridad es correcto, entonces el bloque
OFDM Decode Signal se encarga de marcar con una etiqueta a la muestra. Dicha
etiqueta contiene una dupla con la codificación y la longitud de la trama. Esta etiqueta
es requerida por el bloque posterior en el grafo, y es la forma que tiene GNU Radio
para pasar metadatos asociados a una muestra.
El último paso consiste en decodificar los datos propiamente dichos, es decir, la
carga útil. El bloque encargado de realizar este trabajo es el OFDM Decode MAC. Este
último paso, que es especialmente importante, se divide en tareas bien definidas:
56
Capítulo 4. Mejoras introducidas
El primer bloque del transmisor, llamado OFDM Mapper, realiza los siguientes
pasos, que se detallan con precisión en el estándar Wi-Fi:
57
4.2. Implementación original 58
1. Calcular, del campo RATE del TXVECTOR, el número de bits de datos por
cada símbolo OFDM, la tasa de codificación, el número de bits que tendrá cada
subcarrier de OFDM y el número de bits codificados por cada símbolo OFDM.
3. Iniciar el scrambler con una semilla pseudo-aleatoria distinta de cero, generar una
secuencia de scrambling y realizar el XOR de la misma con la cadena extendida
del punto anterior.
4. Reemplazar los seis bits de ceros que fueron mezclados en el paso anterior con
seis bits de ceros sin mezclar. Dichos bits devolverán al codificador convolucional
al estado inicial y son denominados bits de cola (tail bits).
6. Dividir la cadena de bits codificada en grupos de bits según el número de bits co-
dificados por cada símbolo OFDM. Dentro de cada grupo, realizar el interleaving
de los bits según alguna regla que dependa del RATE deseado.
Un campo de cabezal PLCP, que se genera rellenando los campos de bits apro-
piados a partir de los campos RATE, LENGTH y SERVICE del TXVECTOR.
Los campos RATE y LENGTH del cabezal PLCP se codifican mediante un có-
digo convolucional a una tasa de R = 1/2, y son subsecuentemente mapeados a
un único símbolo OFDM codificado mediante BPSK, y denotado SIGNAL. Para
2
El puncturing se encuentra explicado en la Sección 2.2.4.
58
Capítulo 4. Mejoras introducidas
facilitar una detección confiable y precisa de los campos RATE y LENGTH, seis
bits de ceros se insertan al final del cabezal PLCP. La codificación del campo
SIGNAL en un símbolo OFDM sigue los mismos pasos para la codificación con-
volucional, interleaving, modulación BPSK, inserción de piloto y transformación
de Fourier que se utilizan para la transmisión de datos con la versión BPSK de
OFDM a una tasa de codificación de 1/2, salvando el hecho de que no se realiza
el scrambling del contenido del campo SIGNAL. Esta tarea es realizada por el
bloque Chunks to Symbols superior.
Para cada grupo de subcarriers desde el -26 al 26, se realiza su conversión desde el
dominio de frecuencias al dominio del tiempo mediante el uso de la transformada de
Fourier inversa. Esta tarea es realizada por el bloque FFT. A la onda final resultante de
realizar la transformada de Fourier se le antepone una extensión circular de sí misma, y
se trunca la onda final (que es periódica) a la longitud de un símbolo OFDM aplicando
una técnica conocida como Time Domain Windowing, siendo esta tarea final realizada
por el bloque OFDM Cyclic Prefixer.
Además de los grafos de flujo del transmisor y el receptor que se encuentran adap-
tados para ser usados con un USRP, la implementación contiene un grafo de flujo de
un transceptor (un transmisor y un receptor en el mismo grafo) y otro grafo de flujo
que conecta la salida de un transmisor con la entrada de un receptor, simulando un
canal de loopback 3 entre ellos. Este grafo fue utilizado extensivamente al realizar las
pruebas sin antena.
3
Se denomina canal de loopback a aquel que contiene un transmisor y receptor conectados de
manera secuencial. Dicho canal se utiliza principalmente para realizar pruebas.
59
4.3. Profiling 60
4.3. Profiling
Tal como se describió en la sección anterior, la implementación original (particu-
larmente la del receptor) cuenta con ciertos defectos que hacen que su funcionalidad
sea limitada. En particular, la incapacidad de decodificar tramas en el tiempo exigido
por el estándar hace que sea imposible su utilización a la par de las implementaciones
comerciales, que pueden alcanzar tasas de transferencia máxima de 54 Mbps en el caso
que se esté utilizando un esquema de modulación 64QAM con tasa de codificación 3/4.
El profiling, palabra que podría traducirse como “perfilaje”, consiste en analizar el
rendimiento de un software para determinar el tiempo que fue empleado en la ejecu-
ción de las distintas partes del mismo. Se suele utilizar como forma de identificar los
puntos que consumen mayor tiempo de procesamiento, para luego poder centrarse en
su implementación y lograr mejoras de rendimiento a nivel global.
En las siguientes secciones se describen las técnicas de profiling utilizadas para
detectar las etapas de la implementación original con mayor peso en el tiempo de
ejecución final. En primer lugar, se presenta una perspectiva de alto nivel, que trabaja a
nivel de los grafos de flujo de GNU Radio. En segundo lugar, se describe una perspectiva
diferente, de bajo nivel, que trabaja a nivel del código C++ que implementa los bloques
de mayor consumo e identifica las funciones más demandantes, con el objetivo posterior
de optimizarlas.
En esta etapa de profiling existen dos métricas fundamentales que son representati-
vas del rendimiento alcanzado por el programa: el tiempo de ejecución de cada bloque
y la tasa de transferencia del programa.
GNU Radio dispone de una herramienta para realizar profiling de los grafos de flujo
llamada GNU Radio Performance Monitor. Esta herramienta, cuyo funcionamiento fue
introducido en la Sección 3.3.5 y cuya instalación se describe en el Anexo A, realiza la
medición del tiempo de ejecución de todos los bloques del grafo de flujo que se encuentra
en ejecución, permitiendo determinar comparativamente los bloques de mayor peso
porcentual.
Haciendo uso de esta herramienta, se realizó el profiling del grafo de loopback4 .
El mismo fue configurado para transmitir un archivo de tamaño arbitrario a través
de un canal simulado como canal perfecto. La Tabla 4.1 muestra los porcentajes de
ejecución de los diez bloques que más tiempo demandaron para todas las modulaciones
4
Ver Sección 4.2.3.
60
Capítulo 4. Mejoras introducidas
Tabla 4.1: Porcentaje de tiempo de ejecución según bloque de GNU Radio para los esquemas de
modulación BPSK, QPSK, 16QAM y 64QAM, con tasa de codificación de 1/2 (2/3 para 64QAM) y
PDU de tamaño 1500.
disponibles y con una tasa de codificación de 1/2 (2/3 para 64QAM), para el caso en
el cual cada trama MAC tiene 1500 bytes de datos. La Tabla 4.2 muestra la misma
información pero para el caso en el cual la trama enviada contiene un PDU de tamaño
50 bytes.
Tabla 4.2: Porcentaje de tiempo de ejecución según bloque de GNU Radio para los esquemas de
modulación BPSK, QPSK, 16QAM y 64QAM, con tasa de codificación de 1/2 (2/3 para 64QAM) y
PDU de tamaño 50.
61
4.3. Profiling 62
MAC y OFDM Carrier Allocator. En el caso de la Tabla 4.1, el bloque OFDM Decode
MAC es quien tiene un consumo mayor, mientras que el OFDM Carrier Allocator se
encuentra en segundo lugar. En el caso de la Tabla 4.2, el orden es el opuesto. Este
comportamiento se podrá apreciar numerosas veces a lo largo del presente trabajo, y
se debe principalmente a que un paquete de tamaño grande lleva una tarea de decodi-
ficación más compleja que uno más pequeño.
También cabe destacar que a medida que el esquema de modulación se hace más
complejo, el porcentaje del bloque OFDM Decode MAC se hace más grande aún. Esto
es razonable si se considera que dicho bloque es el encargado de demodular la señal
recibida, y que demodular un esquema con más puntos en la constelación siempre
llevará más tiempo que demodular un esquema simple como BPSK. El bloque OFDM
Carrier Allocator, por su parte, disminuye su consumo gradualmente al incrementar el
esquema de modulación, debido a que el peso relativo del bloque OFDM Decode MAC
aumenta en mayor medida que el de él.
Profiling en el transmisor
Tabla 4.3: Porcentaje de tiempo de ejecución de los bloques más costosos del transmisor gr-ieee802-11.
Se presentan los valores obtenidos para los distintos esquemas de modulación BPSK, QPSK, 16QAM
y 64QAM, con tasa de codificación de 1/2 (2/3 para 64QAM) y PDU de tamaño 1500.
Se observa que en la Tabla 4.3 el consumo del bloque OFDM Carrier Allocator es
el mayor por un margen muy amplio, y aumenta a medida que se elige un esquema
62
Capítulo 4. Mejoras introducidas
de modulación más complejo. Podría parecer que esta tendencia se contradice con la
observada en la Sección 4.3.1, en donde este bloque decrece su consumo porcentual
a medida que se opta por un esquema de modulación más complejo. Lo que sucede
en realidad es que, si bien el costo del bloque OFDM Carrier Allocator es mayor al
aumentar el esquema de modulación, también lo es el de otros bloques como OFDM
Decode MAC (y con un factor de aumento más grande), lo que provoca un consumo
porcentual menor.
También es posible observar bloques que no se encontraban en la Sección 4.3.1,
debido a que al evaluar transmisor y receptor juntos, su costo resultaba demasiado
pequeño. Esto es coherente con lo observado en esta tabla, ya que la diferencia entre
el primer y el segundo bloque más costoso del transmisor es muy importante.
Tabla 4.4: Porcentaje de tiempo de ejecución de los bloques más costosos del transmisor gr-ieee802-
11. Se presentan los valores obtenidos para los esquemas de modulación BPSK, QPSK, 16QAM y
64QAM, con tasa de codificación de 1/2 (2/3 para 64QAM) y PDU de tamaño 50.
La Tabla 4.4 muestra claramente cómo el consumo del bloque OFDM Carrier Allo-
cator depende del tamaño de PDU con el cual se están creando las tramas. En este
caso, el bloque alcanza un consumo superior al 94 % del tiempo total de procesamiento
del transmisor en el sistema. Esto es coherente con lo observado en la Sección 4.3.1, en
donde el bloque OFDM Carrier Allocator representaba un porcentaje importante del
consumo total del sistema al utilizar un tamaño de PDU más pequeño.
Profiling en el receptor
Para poder realizar profiling del receptor de forma exclusiva, se generó una traza
de una señal con el transmisor y se almacenó en un archivo en el disco duro. Luego se
modificó el grafo de flujo del receptor para tomar la señal a partir del archivo. En la
Tabla 4.5 se presentan los datos recabados.
En este caso, sí es posible identificar varios bloques que también se encuentran
presentes en las tablas de la Sección 4.3.1. Esto establece la pauta de que el receptor
como componente del sistema es mucho más costoso que el transmisor, posicionando
varios de sus bloques por delante de todos los bloques del transmisor (con excepción
del bloque OFDM Carrier Allocator).
63
4.3. Profiling 64
Tabla 4.5: Porcentaje de tiempo de ejecución según bloque de GNU Radio para los esquemas de
modulación BPSK, QPSK, 16QAM y 64QAM, con tasa de codificación de 1/2 (2/3 para 64QAM) y
PDU de tamaño 1500, ejecutando exclusivamente el receptor.
En esta tabla también es posible observar que el costo del bloque OFDM Decode
MAC aumenta al complejizar el esquema de modulación utilizado. Esto es razonable
debido a que la demodulación es más costosa en estos casos, y la misma se realiza dentro
del bloque OFDM Decode MAC. Este resultado coincide con el de la Sección 4.3.1.
Si bien no se incluyó una tabla para la tasa de codificación 3/4, vale la pena aclarar
que el costo del bloque OFDM Decode MAC incrementa al usar esta tasa de codificación
por sobre 1/2 para un esquema de modulación dado. Esto también es coherente, debido
a que en una codificación 3/4, donde se tiene menos información de redundancia en el
mensaje transmitido, es necesario que el decodificador convolucional realice un trabajo
mayor en la trellis.
Profilers descartados
Debido a que la arquitectura híbrida de GNU Radio define a los bloques como
clases de C++ a bajo nivel e implementa wrappers en Python sobre estos bloques, es
razonable realizar el profiling de los grafos tanto a nivel de las clases de C++ como
de estos wrappers. Por esta razón, además de GNU Radio Performance Monitor, se
consideraron otros dos profilers para determinar las secciones de código con mayor
demanda de poder de cómputo. A continuación se hace un resumen de las capacidades
de dichos profilers:
profile (profiler nativo de Python): Debido a que los bloques de GNU Radio
están implementados como wrappers en Python (que ejecutan código C++), es
posible utilizar el profiler nativo de Python para medir su tiempo de ejecución.
64
Capítulo 4. Mejoras introducidas
Este profiler, de uso muy sencillo, permite ejecutar un programa Python, retor-
nando una tabla que detalla el tiempo de ejecución que tomó cada función del
programa original.
En última instancia, se resolvió por no utilizar estos profilers en esta etapa. Una
de las principales razones fue que en varias referencias se mencionaba que este tipo de
profilers era muy intrusivo para realizar el profiling de una aplicación en GNU Radio,
y que por esta razón la información generada en las trazas resultantes no resultaba
confiable.
Además del profiling de alto nivel descrito en la sección anterior, se realizó un profi-
ling más detallado sobre los bloques que fueron identificados como los más demandantes
(OFDM Carrier Allocator y OFDM Decode MAC). Este segundo profiling fue realizado
sobre las implementaciones en C++ de dichos bloques con el objetivo de lograr ubicar
las secciones y/o funciones con mayor demanda de tiempo de ejecución.
Para la realización de estas mediciones, se optó por desarrollar una herramienta
muy sencilla que brinda la capacidad de medir el tiempo de ejecución de una sección
arbitraria de código. Si bien se podría haber hecho uso de los profilers descartados
mencionados en la Sección 4.3.1, la opción no fue tomada en cuenta por la extrema
simplicidad y flexibilidad de la herramienta desarrollada.
Nuevamente, al igual que en el profiling de alto nivel, las mediciones fueron realiza-
das sobre el grafo de loopback.
Para el bloque OFDM Decode MAC, las funcionalidades analizadas fueron cuatro:
demodulate, deinterleave, decode_conv y descramble. Dichas funcionalidades se corres-
ponden con los pasos del mismo nombre detallados en la Sección 4.2.1 para el bloque
OFDM Decode MAC. La Tabla 4.6 muestra los porcentajes de ejecución de cada sec-
ción luego de transmitir un archivo de tamaño arbitrario por el canal, además del
porcentaje correspondiente al resto del código, para cada modulación disponible y con
una tasa de codificación de 3/4. Esta tasa de codificación se eligió para forzar al bloque
a resolver el puncturing5 , que no existe en una codificación de 1/2.
En base a la Tabla 4.6, resulta claro que la inmensa mayoría del trabajo realizado
por el bloque OFDM Decode MAC se corresponde con los pasos de demodulación y
decodificación convolucional, siendo el segundo el más demandante de los dos.
5
Para más información, ver la Sección 2.2.4.
65
4.3. Profiling 66
En las tablas 4.7 y 4.8 se presentan los resultados obtenidos en la etapa de profiling
para este bloque. La implementación de este bloque realiza un memset sobre todo el
arreglo de salida cada vez que es invocado para su ejecución (antes de asignar datos
al arreglo de salida). El valor asignado por el memset es 0x00, ya que la finalidad de
ejecutar esta instrucción es limpiar el arreglo de posibles valores inválidos. Posterior-
mente a la ejecución de esta instrucción, se asignan a cada uno de los 48 carriers de
datos los símbolos a ser transmitidos. También se asignan los carriers piloto. Todo esto
se realiza escribiendo sobre el arreglo de salida.
Es a este memset inicial que hace referencia la primera fila de las tablas 4.7, y 4.8.
Esta sentencia es muy costosa debido al tamaño del arreglo de salida sobre el cual
ejecuta la sentencia, que es de aproximadamente 23 MB.
Se puede concluir a partir de las tablas 4.7 y 4.8 que la ejecución del memset
sobre el arreglo de salida del bloque representa el costo más grande en la ejecución del
mismo de forma contundente, independientemente del tamaño del PDU y el esquema
de modulación utilizado.
Además, se observa que el peso del memset incrementa a medida que disminuye
el PDU enviado en cada trama MAC. También incrementa a medida que aumenta la
complejidad del esquema de modulación utilizado. Si bien la tasa de codificación utili-
zada para completar ambas tablas fue la más simple para cada esquema de modulación
66
Capítulo 4. Mejoras introducidas
(1/2 para todos excepto 64QAM, en el cual se hizo con 2/3), los porcentajes de ejecu-
ción para una codificación del tipo 3/4 son prácticamente idénticos en base a pruebas
realizadas con estas tasas de codificación.
En la sección 4.4.2 se explica con más detalle la razón por la cual el arreglo de salida
tiene este tamaño, y por qué es que al disminuir el tamaño del PDU el peso porcentual
del memset en la ejecución aumenta, entre otros detalles de la implementación del
bloque.
Además, se presenta la estrategia tomada para eliminar la ejecución de este memset
y de esta forma reducir el costo del bloque. Por esta razón, en esta sección solamente
se presentan los resultados del profiling sobre el bloque.
67
4.3. Profiling 68
puede aspirar. Esta cota superior es una tasa que en la realidad es imposible
de alcanzar, ya que implicaría que el bloque no realice trabajo alguno. Esto
no puede suceder nunca en un escenario real debido a que, para producir una
salida correcta, el bloque debe realizar operaciones sobre los datos. Esto implica
un tiempo de ejecución mayor a cero, sin importar que tan optimizada sea la
ejecución de dichas operaciones.
De todas maneras, es un dato útil para tener una idea aproximada de cómo
influye la ejecución de cada bloque en la tasa de transferencia final que presenta
el programa, ya que la misma no solo es afectada por la ejecución de los bloques,
sino por GNU Radio en sí mismo (el scheduler), la velocidad de lectura/escritura
en disco duro, entre otros factores.
Simular un costo de ejecución nulo para un bloque no es algo trivial, ni alcanza con
comentar todo el código que ejecuta el mismo. Los bloques deben generar una salida
coherente para que bloques subsiguientes en el grafo de flujo tengan datos correctos
en sus buffers de entrada con los cuales puedan trabajar. De no respetar esta regla,
el grafo de flujo deja de funcionar y no hay ningún tipo de información valiosa que se
pueda extraer en estos casos.
La estrategia diseñada para lograr que los bloques tengan un tiempo de procesa-
miento cercano a cero mientras siguen produciendo datos correctos en sus buffers de
salida consistió en aprovecharse de que el pipeline de bloques se invoca periódicamente
para cada trama que se desea transmitir.
Aquí se explica la estrategia aplicada a un bloque en particular, el OFDM Decode
MAC, pero la misma idea es extensible a los otros bloques pertenecientes al conjunto
de bloques más costosos (los cuales son OFDM Carrier Allocator, OFDM Mapper,
OFDM Sync Short y OFDM Sync Long, entre otros).
Supóngase que mientras se está ejecutando gr-ieee802-11 no hay modificación en
los parámetros de la ejecución mismo (como pueden ser el tamaño de los datos a ser
enviados por trama MAC, o el esquema de modulación utilizado). Por ejemplo, se asume
que son 1500 bytes de datos para todas las tramas transmitidas durante esa ejecución
específica de gr-ieee802-11. En este caso, cada vez que se invoque al bloque OFDM
Decode MAC para decodificar una trama recibida, se tendrá en su buffer de entrada
una secuencia de símbolos desde los cuales, después de que se realice el procesamiento
correspondiente, se obtienen los datos de la trama MAC original, equivalentes a 1500
bytes de datos.
Si luego de la primera llamada al bloque OFDM Decode MAC, y por consiguiente,
luego de la decodificación de la primera trama, se almacenara el resultado de la mis-
ma en un buffer miembro de la clase del bloque, entonces sería posible, para llamadas
subsiguientes en las cuales se deba decodificar tramas nuevas, devolver directamente
el buffer almacenado. Claro está, estos datos almacenados corresponderían a la de-
codificación de la trama inicial, que no necesariamente es idéntica a la trama que se
68
Capítulo 4. Mejoras introducidas
quiere decodificar en una llamada posterior, por lo que el resultado sería incorrecto.
Sin embargo, esto no es relevante a los efectos de medir la capacidad de transferencia
del programa, debido a que ambas tramas tienen un tamaño de datos de 1500 bytes.
Además, como el resultado devuelto es una decodificación válida de una trama an-
terior, los bloques posteriores al OFDM Decode MAC deberían funcionar con absoluta
normalidad, debido a que no tienen forma de conocer que el valor decodificado no co-
rresponde a los símbolos recibidos por el OFDM Decode MAC. El archivo resultante
del lado del receptor tendrá el mismo tamaño que el archivo enviado por el transmisor,
que también será idéntico al que tendría si se hubiera decodificado de forma normal,
con la única salvedad que el contenido del archivo será una secuencia repetitiva de los
1500 bytes decodificados de la trama inicial.
Aplicando esta estrategia, solo se incurre en el costo de procesamiento para la pri-
mera trama de la transferencia. Las N tramas subsiguientes tienen un costo nulo, o
muy pequeño (debido a que aún debe copiarse a la salida el buffer miembro de la clase).
Por lo tanto, si se realiza la transferencia de un archivo con un tamaño tal que se ne-
cesite un número grande de tramas, el promedio de la tasa de transferencia observado
sobre un período largo de tiempo tenderá a representar la tasa de transferencia que se
obtiene cuando el bloque en cuestión no consume tiempo de procesamiento.
Esta fue la estrategia utilizada para los distintos bloques, experimentando con dichos
cambios sobre cada bloque de forma individual en primera instancia, para luego hacer
pruebas que involucran varios bloques con este comportamiento.
Resultados obtenidos
69
4.4. Mejoras realizadas 70
mente se logra un salto muy grande en las tasas de transferencia. Esto no es casualidad
ya que como se vio en la sección anterior, estos son los dos bloques más costosos de
todo el programa. La mejora en la tasa conseguida luego de reducir a cero el trabajo
de los otros bloques más costosos (OFDM Sync Long, OFDM Sync Short y OFDM
Mapper) es menor si se la compara con la obtenida por estos dos bloques, lo que otorga
la pauta de que el mayor incremento de rendimiento que se puede alcanzar es a través
de la optimización de dichos bloques, tal como se había determinado en la etapa de
profiling.
70
Capítulo 4. Mejoras introducidas
71
4.4. Mejoras realizadas 72
72
Capítulo 4. Mejoras introducidas
codificación convolucional y descrambling, que son las más costosas del bloque, podrían
ser ejecutadas en GPU.
Un análisis de esta estrategia dejó en evidencia algunos problemas importantes. Por
ejemplo, sería necesario invocar un CUDA Kernel 7 por cada trama a decodificar. Esto
implicaría una transferencia de datos entre la memoria principal y la GPU, la ejecución
del algoritmo propiamente dicha, y finalmente otra transferencia desde la GPU hacia
la memoria principal para obtener los datos decodificados. La operación de copiar de la
memoria de un dispositivo a otro es costosa, y este costo de transferencia podría opacar
las mejoras en el tiempo de procesamiento. Esta es una de las principales razones por
las cuales muchos algoritmos logran menos desempeño al ser ejecutados en GPU.
En este caso, la invocación se realizaría para cada trama recibida, lo que sugiere
que el costo de la transferencia podría degradar el rendimiento de forma significativa,
teniendo en cuenta que en una conexión Wi-Fi normal, la cantidad de tramas reci-
bidas por segundo es muy alta. Además, generalmente los algoritmos que muestran
una aceleración considerable en GPU trabajan sobre un conjunto grande de datos, y
realizan múltiples cálculos. En el caso de la decodificación de una trama MAC, si bien
las operaciones son costosas, el tamaño de los datos sobre los que se trabaja puede
considerarse pequeño para ser abordado siguiendo una estrategia de GPU, debido a
que el tamaño máximo del PDU es de 1500 bytes por trama. En el caso de paquetes
más pequeños, el costo de realizar el procesamiento en GPU resulta aún mayor.
Por esta razón, se decidió acelerar la ejecución utilizando la CPU en primera instan-
cia, y en caso de no alcanzar una mejora significativa, volver a evaluar la posibilidad
de utilizar la GPU.
Vale la pena aclarar que podría ser atractiva la posibilidad de utilizar la GPU para
realizar la decodificación batch de múltiples tramas. Una aplicación de esto podría ser la
recepción de un archivo, ya que en este caso este último solo es útil cuando es recibido en
su totalidad. Por esta razón, en este escenario es posible decodificar todas las tramas
en conjunto al finalizar la transferencia, ya que solo interesa el momento en que se
decodifican todas las tramas y el archivo es recibido de forma íntegra. Sin embargo,
para otros casos de uso, como por ejemplo un chat, la estrategia de procesamiento batch
no tiene sentido. Por esta razón, para no perder generalidad en la solución, se evitó
esta estrategia.
Open Multi-Processing (OpenMP) es una API utilizada para crear de forma sencilla
programas multi-threading que aprovechen los recursos de cómputo en una arquitectura
multiprocesador.
7
Los CUDA Kernels son las unidades de ejecución de código en GPU que brinda la biblioteca
CUDA, que es la plataforma de procesamiento paralelo en GPU de la empresa NVIDIA para sus
GPUs.
73
4.4. Mejoras realizadas 74
El equipo utilizado en el presente trabajo posee una CPU Intel Core i5 2400 de 4
núcleos, por lo que el uso de OpenMP debería, a priori, incrementar el rendimiento.
Se realizaron modificaciones para utilizar OpenMP en varias secciones del código que
contenían operaciones sobre vectores y que además se podían aplicar concurrentemente.
Sin embargo, los resultados obtenidos a partir de las pruebas de rendimiento luego
de los cambios no mostraron ningún beneficio con respecto al rendimiento original.
Esto se debe principalmente a que GNU Radio define un thread por cada bloque
del grafo de flujo, por lo que es extremadamente difícil que durante la ejecución del
grafo de flujo existan núcleos del microprocesador en estado ocioso. Debido a esto, no
se logra ningún beneficio al definir threads separados para este tipo de operaciones
vectoriales. De hecho, el pequeño costo extra agregado por la creación de los distintos
threads es, en este caso, contraproducente.
Sin embargo, es posible que existan situaciones en las cuales utilizar OpenMP mejore
el rendimiento de un grafo de flujo creado en GNU Radio. Por ejemplo, en el caso que
un bloque sea costoso y se encuentre cerca del principio del pipeline de bloques del grafo
de flujo, puede suceder que no sea capaz de producir datos lo suficientemente rápido
como para que los bloques posteriores del pipeline siempre tengan datos disponibles
en sus buffers de entrada. En este caso, utilizar OpenMP en el bloque costoso puede
acelerar el rendimiento debido a que se disminuye el tiempo en el cual se encuentran
bloques en estado ocioso por no tener datos suficientes en sus buffers de entrada.
Además, se cumple que cuanto más pequeño es el tamaño de la trama y más simple el
esquema de modulación, más grande es el costo relativo de este bloque en comparación
con el resto. Esta observación es razonable debido a que un tamaño de trama más
pequeño implica la necesidad de enviar un mayor número de tramas para transmitir
una misma cantidad de datos. Esto no solo significa que el costo relativo del cabezal de
la trama es mayor, sino que también, al haber un mayor número de tramas, se realizan
más invocaciones al bloque OFDM Carrier Allocator, incrementando su consumo.
74
Capítulo 4. Mejoras introducidas
En el caso de que solo se cambie el algoritmo de modulación por uno más simple,
también es lógico observar un incremento en el consumo de este bloque8 . Al simplificar
la modulación, y consecuentemente, la demodulación, se logra que los bloques OFDM
Mapper y OFDM Decode MAC, responsables de estas tareas, disminuyan su consumo,
por lo que el peso relativo del bloque OFDM Carrier Allocator aumenta. Adicional-
mente, al tener un esquema de modulación más simple, la cantidad posible de bits
codificables por símbolo es menor, lo que obliga a un mayor número de símbolos a ser
asignados en el bloque OFDM Carrier Allocator para un mismo conjunto de datos.
En la Sección 4.3.2 se comprobó que el consumo del bloque OFDM Carrier Allocator
se debe principalmente a la ejecución de un memset que asigna el valor 0x00 sobre el
buffer de datos de salida del bloque, que tiene un tamaño de aproximadamente 23 MB.
Evitando la ejecución de esta sentencia, el costo del bloque decrece en forma general en
un 90 %. De esta manera, optimizar el rendimiento de este bloque se traduce en lograr
optimizar el rendimiento del memset.
La ejecución del memset se produce cada vez que el scheduler de GNU Radio invo-
ca a la función work() del bloque, lo que quiere decir que se ejecuta una vez por cada
trama a ser transmitida. Es posible observar que el tamaño del buffer de salida es exce-
sivamente grande para los datos que luego se escriben en el mismo y que son utilizados
por el bloque siguiente (la FFT), habiendo muchas posiciones de memoria que no son
utilizadas. Asimismo, el tamaño del buffer siempre es el mismo, independientemente
de la cantidad de símbolos que estén disponibles en el buffer de entrada.
Esto se debe a que en la definición del grafo de flujo en el archivo Python corres-
pondiente, el bloque OFDM Carrier Allocator tiene asignado explícitamente un valor
mínimo para el buffer de salida, que acota inferiormente su tamaño. De no existir esta
asignación explícita, GNU Radio utiliza el tamaño de buffer de salida por defecto, que
es 64 KB, lo que equivale a 8192 valores de tipo gr_complex y no es suficiente para
casos de tramas grandes. Por esta razón, en la implementación original se asigna un
valor lo suficientemente grande como para cubrir el escenario en el cual se transmite
una trama con 1500 bytes de datos. En el caso de este bloque, asignar un buffer de
salida excesivamente grande penaliza la performance en los casos en que no se utilizan
bloques con 1500 bytes de datos, debido a que en el código de ejecución se hace un
memset de este buffer.
La mejora que se hizo con respecto a este bloque fue eliminar por completo la
ejecución del memset al comienzo de la función work(). La utilidad de este memset es
dejar en un estado consistente el contenido del buffer de salida del bloque (con el valor
0), que es administrado por el scheduler de GNU Radio y que potencialmente puede
tener valores inválidos en celdas del mismo al momento de la ejecución de work(). Sin
embargo, el hacer memset del arreglo entero, además de ser costoso, es innecesario,
debido a que la gran mayoría de los valores de las celdas del arreglo son reasignados
antes de que termine la ejecución del bloque.
8
Esto se refiere al caso del grafo de loopback.
75
4.4. Mejoras realizadas 76
76
Capítulo 4. Mejoras introducidas
77
4.4. Mejoras realizadas 78
Fragmentar el bloque OFDM Decode MAC en tres bloques, uno que realice la
demodulación y el deinterleaving de la señal, un segundo bloque que realice la de-
9
Para más información, ver [17] y [18].
10
Butterfly, que significa mariposa en inglés, es el nombre que se le dio a la macro debido a la
apariencia que generan en el grafo de trellis las operaciones de ACS. Para más información, ver [17].
78
Capítulo 4. Mejoras introducidas
Separar la lógica del bloque de GNU Radio del decodificador de Viterbi propia-
mente dicho, de forma de poder utilizar el decodificador desde cualquier programa
en C++, y consecuentemente, desde la implementación del bloque OFDM Decode
MAC.
Se evita el costo extra que se genera al agregar dos nuevos bloques al grafo de
flujo en el Scheduler de GNU Radio.
Tanto el tipo de datos como los valores que representan a los bits y la forma de
representar los bits omitidos (en el caso de que se esté utilizando puncturing) son dis-
tintos para el decodificador de Viterbi de IT++ y el de gr-dvbt. Esto implicó que fuera
necesario modificar las funciones de deinterleaving y descrambling del bloque OFDM
Decode MAC, ya que la primera genera los datos de entrada para el decodificador, y
la última realiza el descrambling a partir de la salida generada por el decodificador,
por lo que fue necesario adaptar estas funciones para que utilicen los nuevos tipos de
datos.
También hubo que modificar la forma en la que se invocaba al algoritmo de decodifi-
cación con respecto a como lo hacía el bloque GNU Radio de gr-dbvt. En la implemen-
tación de este último, las tramas se recibían como un flujo de bits codificados, lo que
significaba que para la decodificación del código convolucional, de los primeros bits de
una trama se estaban utilizando los últimos bits de la trama inmediatamente anterior.
Esto no tiene sentido en IEEE 802.11 ya que la codificación del código convolucional
de una trama es totalmente independiente de la codificación de otras. Por lo tanto,
esto debía verse reflejado del lado del receptor al realizar la decodificación.
El cambio realizado en el decodificador convolucional presentó mejoras sustancia-
les de manera inmediata tanto al evaluar el porcentaje de tiempo de procesamiento
consumido por el bloque como al evaluar la tasa de transferencia neta lograda por el
programa gr-ieee802-11. En el Capítulo 5 se describen con detalle las mejoras logradas.
79
Capítulo 5
Evaluación experimental
Este capítulo describe las pruebas realizadas sobre la versión original del programa
gr-ieee802-11, y sobre una versión modificada que contiene las mejoras detalladas en el
Capítulo 4. En primer lugar, se presentan las pruebas realizadas en grafos de GNU Ra-
dio funcionando completamente en software. En segundo lugar, se incluyen las pruebas
de concepto realizadas en hardware USRP Ettus B210.
81
5.1. Pruebas en software 82
por defecto de los buffers de cada bloque, de forma de evitar que existan datos que
puedan llegar a ser descartados.
En cualquier caso, por más de que no existan muestras descartadas, muchas de ellas
serán encoladas en buffers de entrada de bloques, y procesadas a una velocidad menor
en la versión original con respecto a la versión optimizada. Esto es esperable y es lo que
permite que un archivo sea transmitido de forma correcta por ambas implementaciones,
pero con un tiempo total de transmisión variable de una versión del programa a la otra.
Las pruebas fueron realizadas sobre una computadora de escritorio con un proce-
sador Intel Core i5 2400 funcionando a 2.4 GHz, con 8 GB de memoria RAM DDR
3 disponibles y operando en un sistema operativo Ubuntu 14.04.3 LTS. La versión de
GNU Radio utilizada fue la 3.7.8. Las mediciones fueron tomadas mediante una uti-
lidad de creación propia. Dicha utilidad permite medir la tasa de transferencia desde
que se introducen los datos en el transmisor hasta que son recibidos correctamente en
el receptor.
Para comprender de mejor manera las tasas obtenidas en las pruebas presentadas
en este capítulo, es importante tener en claro la tasa de transferencia teórica máxima
que tiene cada esquema de modulación y codificación posible. Dicha información puede
encontrarse en la Sección 3.1.3, en la Tabla 3.1.
Tabla 5.1: Tasas de transferencia obtenidas al utilizar el grafo de loopback para transmitir un PDU
de 50 bytes de información y aplicando cada una de las mejoras realizadas por separado.
La Tabla 5.1 presenta las tasas de transferencia resultantes de aplicar las mejoras
propuestas de manera individual con un PDU de 50 bytes. La Mejora 1 es la mejora
realizada sobre el bloque OFDM Carrier Allocator, la Mejora 2 sobre la sección demo-
dulate_bits del bloque OFDM Decode MAC, y la Mejora 3 la realizada sobre la función
82
Capítulo 5. Evaluación experimental
decode_conv del mismo bloque. Las tasas de transferencia son calculadas para cada
esquema de modulación disponible, con tasa de codificación 1/2 para BPSK, QPSK y
16QAM y 2/3 para 64QAM.
Es interesante observar que la única de estas mejoras que logra un incremento de
desempeño significativo es la Mejora 1. Este comportamiento coincide con el esperado,
ya que como fue presentado en las tablas 4.2 y 4.8, ante paquetes pequeños, el bloque
OFDM Carrier Allocator representa más del 80 % del consumo total de CPU, despla-
zando completamente al bloque OFDM Decode MAC que predomina en paquetes más
grandes.
En otras palabras, ante paquetes pequeños, el cuello de botella del sistema es el
transmisor y no el receptor. Esto tiene sentido ya que si un paquete es pequeño, el
receptor debe realizar menos trabajo para decodificarlo.
Tabla 5.2: Tasas de transferencia obtenidas al utilizar el grafo de loopback para transmitir un PDU
de tamaño 1500, aplicando cada una de las mejoras realizadas por separado. Las mejoras son las
mismas de la Tabla 5.1, al igual que las modulaciones utilizadas.
Por otra parte, la Tabla 5.2, que describe el comportamiento de cada mejora con
PDUs de tamaño 1500, también coincide con los resultados previstos en las tablas 4.1
y 4.6. En este caso, el cuello de botella del sistema es el receptor, y la explicación
es análoga a la que se dio anteriormente. Cuando el paquete es grande, el transmisor
tiene más bytes para enviar, pero debido a que su costo más grande es una sentencia
que es ejecutada independientemente del tamaño del paquete, el trabajo realizado por
el transmisor no es mucho mayor al que realiza cuando envía paquetes pequeños. Sin
embargo, el receptor tiene mucho más costo, ya que su trabajo sí es proporcional al
tamaño del paquete. Por ende, la Mejora 1 no representa ningún cambio en las tasas de
transferencia; pero las mejoras 2 y 3, que en su conjunto aumentan el rendimiento del
bloque OFDM Decode MAC, permiten aumentar las tasas de transferencias finales.
Resulta interesante observar que, en todos los casos, utilizar un esquema de mo-
dulación más complejo no produce grandes mejoras. En particular, el esquema de
modulación 64QAM es significativamente más lento que 16QAM y que QPSK. Este
comportamiento, que es el mismo que se puede observar en la implementación original,
ocurre debido a que las secciones no optimizadas actúan como cuello de botella del
sistema, impidiendo a este beneficiarse de la utilización de un esquema de modulación
83
5.1. Pruebas en software 84
más complejo (y que requiere mayor cantidad de cálculos). Esto sugiere que las mejoras
deben ser aplicadas de manera simultánea para conseguir los mejores resultados.
A pesar de que los números de la Sección 5.1.1 muestran que se obtienen mejoras de
desempeño importantes al aplicar las modificaciones propuestas en la Sección 4.4, es
razonable que el mejor resultado se obtenga cuando todas las mejoras son aplicadas de
manera simultánea. Para demostrar esto, en esta sección se presentan dos tablas con
las mediciones obtenidas al aplicar de manera acumulativa las tres mejoras propuestas.
Tabla 5.3: Tasas de transferencia obtenidas al utilizar el grafo de loopback para transmitir PDUs de
50 bytes, aplicando cada una de las mejoras realizadas de manera acumulativa. Las mejoras son las
mismas de la Tabla 5.1, al igual que las modulaciones utilizadas.
La Tabla 5.3 muestra las tasas de transferencia obtenidas al aplicar las mejoras
de manera acumulativa con PDUs de 50 bytes. Cabe destacar que luego de aplicar la
Mejora 1, el peso total del bloque OFDM Carrier Allocator disminuye notoriamente,
propiciando el aumento porcentual del peso del bloque OFDM Decode MAC. Es por
esto que, a diferencia del caso presentado en la Tabla 5.1, las mejoras 2 y 3 sí producen
incrementos en el desempeño, aunque estos son menores.
También puede apreciarse que al aplicar las tres mejoras de manera simultánea, el
sistema adquiere la capacidad de decodificar los esquemas de modulación más pesados
de manera más rápida. Como efecto de esto, la decodificación de 64QAM, el esquema
más pesado y costoso, puede realizarse en el tiempo necesario para dejar de ser el cuello
de botella del sistema, lo que hace que por primera vez su tasa de transferencia supere
a la de 16QAM.
La Tabla 5.4 muestra el mismo resultado pero al utilizar PDUs de tamaño 1500 by-
tes. En este caso se puede observar que es necesario aplicar mejoras en el receptor para
conseguir un aumento en el desempeño, lo cual coincide con el argumento presentado
en la Sección 5.1.1 de que ante paquetes grandes, el cuello de botella del sistema es el
receptor.
Además de esto, también puede observarse que al aplicar las tres mejoras de manera
simultánea el sistema adquiere la capacidad de decodificar los esquemas de modulación
84
Capítulo 5. Evaluación experimental
Tabla 5.4: Tasas de transferencia obtenidas al utilizar el grafo de loopback para transmitir PDUs de
1500 bytes, aplicando cada una de las mejoras realizadas de manera acumulativa. Las mejoras son las
mismas de la Tabla 5.1, al igual que las modulaciones utilizadas.
más pesados de manera más rápida, comportamiento similar al descrito para PDUs de
50 bytes. Esto permite que utilizar esquemas más grandes redunden en una tasa de
transferencia mucho mayor.
Por otra parte, es interesante observar que independientemente del esquema de
modulación elegido, las tasas de transferencia obtenidas con PDUs de 1500 bytes son
mucho mayores que las que pueden obtenerse con PDUs de 50 bytes. Esto tiene sentido
si se considera que al enviar un paquete más grande (y siempre y cuando el receptor
pueda decodificar paquetes en el tiempo necesario), se está enviando más información
útil por cada cabezal MAC, lo que redunda en un menor trabajo para el sistema en
general, que debe detectar y decodificar menos paquetes.
Para concluir las pruebas sobre software, esta sección presenta una serie de medi-
ciones realizadas para comparar directamente la implementación original con la final.
En ese sentido, estas pruebas pueden ser entendidas como pruebas de caja negra, con
el único propósito de determinar el incremento de desempeño producido por las modi-
ficaciones introducidas.
Las tablas contienen los datos de tasas de transferencia promedio, máxima y mínima,
calculados a partir de mediciones por intervalos de un segundo para una misma ejecu-
ción. También se calcula la aceleración (también conocida como speed-up) dividiendo
la transferencia promedio de la versión modificada entre la transferencia promedio de
la versión original.
Tanto en la Tabla 5.5 como en las tablas 5.6 y 5.7 se pueden apreciar los siguientes
resultados:
85
5.1. Pruebas en software 86
86
Capítulo 5. Evaluación experimental
Por otra parte, existe cierta fluctuación producto de que la máquina utilizada
nunca está completamente dedicada a la ejecución de GNU Radio, por lo que no
acapara completamente el procesador.
Aunque utilizar una tasa de codificación más alta generalmente implica un au-
mento en la tasa de transferencia (porque a más tasa de codificación, menos
información redundante enviada), la implementación original no se veía benefi-
ciada por esto. Como fue mencionado en las Sección 5.1.1, la decodificación de
paquetes realizada por el receptor es el cuello de botella cuando se envían pa-
quetes de gran tamaño. Una mayor tasa de codificación significaba la existencia
de puncturing, lo que sobrecargaba aún más al receptor, que debía realizar más
cálculos que los que realizaba al no haber puncturing (tasa de codificación de
1/2). Al realizar las modificaciones propuestas, el receptor consigue decodificar
los paquetes de manera mucho más rápida, por lo que esto ya no es un cuello de
botella y la tasa de transferencia se ve beneficiada.
Las figuras 5.1 y 5.2 contienen la misma información que se encuentra en las tablas
anteriores pero representada en forma de gráfico de barras. Las barras azules repre-
sentan la tasa de transferencia obtenida por la versión original de la implementación,
mientras que las barras rojas representan el incremento alcanzado por la implementa-
ción que contiene las modificaciones propuestas.
La Figura 5.1 contiene las mediciones para los esquemas BPSK 1/2, QPSK 1/2,
BPSK 3/4 y QPSK 3/4, mientras que la Figura 5.2 contiene las mediciones de 16QAM
1/2, 16QAM 3/4, 64QAM 2/3 y 64QAM 3/4. Para cada esquema, la barra de más a
la izquierda se corresponde con la medición con PDUs de 500 bytes, la barra del medio
con PDUs de 1000 bytes y la de la derecha con PDUs de 1500 bytes
87
5.1. Pruebas en software 88
800
600
400
200
Figura 5.1: Tasas de transferencia promedio de la implementación original (en azul) y de la modificada
(rojo más azul) para los esquemas de modulación BPSK 1/2, BPSK 3/4, QPSK 1/2 y QPSK 3/4.
Para cada esquema de modulación, se encuentran las mediciones con PDUs de 500, 1000 y 1500 bytes
respectivamente (de izquierda a derecha).
Original Modificado
Tasa de transferencia (KB/s)
1,400
1,200
1,000
800
600
400
200
88
Capítulo 5. Evaluación experimental
Para finalizar con las mediciones realizadas en software, se presenta una comparación
del resultado de la ejecución de la herramienta GNU Radio Performance Monitor tanto
sobre la implementación original como sobre la modificada. La Tabla 5.8 contiene
el porcentaje del tiempo de ejecución total que representan los bloques que habían
sido identificados como los más demandantes, OFDM Decode MAC y OFDM Carrier
Allocator, para todos los esquemas de modulación disponibles, con un PDU de 50 bytes.
Por su parte, la Tabla 5.9 contiene los mismos datos pero al utilizarse PDUs de 1500
bytes.
La primera observación que puede hacerse es que en todos los casos, las modificacio-
nes propuestas logran reducir el porcentaje de ejecución de los bloques identificados.
Para PDUs de 50 bytes, la reducción más grande se encuentra en el bloque OFDM
Carrier Allocator, lo que coincide con el comportamiento esperado y descrito detalla-
damente en la Sección 5.1.1. Por otra parte, para PDUs de 1500 bytes se producen
reducciones significativas tanto en el bloque OFDM Decode MAC como en OFDM
Carrier Allocator.
Versión original Versión modificada
OFDM Decode OFDM Carrier OFDM Decode OFDM Carrier
Modulación
MAC ( %) Allocator ( %) MAC ( %) Allocator ( %)
BPSK 1/2 7,9 78,4 7,0 1,7
BPSK 3/4 8,8 78,1 9,2 1,5
QPSK 1/2 7,8 80,2 9,4 1,6
QPSK 3/4 8,5 79,9 13,4 1,45
16QAM 1/2 8,4 80,2 12,9 1,5
16QAM 3/4 16,5 72,8 17,0 1,4
64QAM 2/3 19,9 70,0 19,0 1,4
64QAM 3/4 17,3 72,3 17,0 1,2
Tabla 5.8: Porcentaje de tiempo de ejecución de los bloques OFDM Decode MAC y OFDM Carrier
Allocator para todos los esquemas de modulación disponibles, con un PDU de tamaño 50.
En segundo lugar, es importante destacar que para el caso de PDUs de 1500 bytes, la
reducción en el bloque OFDM Decode MAC es menor para los esquemas de modulación
más complejos (16QAM y 64QAM) que para los más simples (BPSK y QPSK). Esto
se debe en gran medida al costo de demodular dichos esquemas, que es mayor si el
esquema es más complejo. En esos casos, tanto la demodulación como la decodificación
del código convolucional siguen representando un porcentaje importante del tiempo de
ejecución, incluso con las mejoras aplicadas.
Por último, es importante aclarar que debido a la disminución del costo de los
bloques OFDM Decode Mac y OFDM Carrier Allocator en la versión mejorada, otros
bloques que antes tenían un consumo marginal pasaron a tener un porcentaje de tiempo
de ejecución a la par de los dos primeros, y en muchos casos los superaron. En particular,
89
5.1. Pruebas en software 90
Tabla 5.9: Porcentaje de tiempo de ejecución de los bloques OFDM Decode MAC y OFDM Carrier
Allocator para todos los esquemas de modulación disponibles, con un PDU de tamaño 1500.
se destacan los bloques OFDM Mapper y OFDM Sync Short, que pasaron a consumir
en promedio el 10 % y 12 % respectivamente en el caso de utilizar un PDU de 1500
bytes, superando a los bloques OFDM Decode Mac y OFDM Carrier Allocator en caso
de utilizar esquemas de modulación simples (BPSK y QPSK).
Al trabajar con un PDU de tamaño chico como 50 bytes, los bloques que más se
destacan luego de aplicadas las mejoras son el OFDM Sync Short y el OFDM Sync
Long, ambos manteniéndose arriba del 10 % para todas las modulaciones y tipos de
codificación disponibles. El OFDM Mapper se mantiene con un promedio de 5 %, el
cual es superior en todos los casos al costo del OFDM Carrier Allocator.
Resampler 12 % 13 %
Decode MAC Decode MAC
9% 13 %
12 %
Allocator 77 % 10 %
11 % Equalize
43 %
Resto
Resto
Figura 5.3: Porcentaje de tiempo de ejecución según bloque para un PDU de 50 bytes, versión
original (izquierda) y modificada (derecha).
90
Capítulo 5. Evaluación experimental
Mapper
Decode MAC
Allocator
Sync Short 10 %
22 % 27 %
12 %
62 %
10 %
Decode MAC 16 % Equalize
4% 37 %
Resto
Allocator
Resto
Figura 5.4: Porcentaje de tiempo de ejecución según bloque para un PDU de 1500 bytes, versión
original (izquierda) y modificada (derecha).
91
5.2. Pruebas en hardware 92
La primera serie de pruebas fue realizada sobre una antena configurada para utilizar
el grafo de un transmisor, con la capacidad de enviar paquetes de tamaño configurable a
una tasa también configurable. Se utilizó una computadora portátil configurada en mo-
do monitor para poder capturar los paquetes enviados por el transmisor sin necesidad
de asociarse con el mismo mediante Wi-Fi.
Para realizar las mediciones, se utilizaron los esquemas de modulación BPSK con
tasa de codificación de 1/2 y 64QAM con tasa 3/4. Se eligieron dos tamaños de paquete,
50 bytes y 1500 bytes, midiéndose la cantidad de paquetes recibidos correctamente por
92
Capítulo 5. Evaluación experimental
Tabla 5.10: Resultados obtenidos al realizar las pruebas sobre el transmisor. Las columnas contie-
nen, de izquierda a derecha: el esquema de modulación utilizado, el tamaño del paquete enviado, la
tasa de transferencia a la cual se inyectaron paquetes en el transmisor, la tasa obtenida por la imple-
mentación original, el porcentaje de esta tasa sobre la ideal, la tasa de transferencia obtenida por la
implementación modificada, el porcentaje de esta tasa sobre la ideal, y la aceleración obtenida por la
implementación modificada sobre la original.
La Tabla 5.10 presenta los resultados obtenidos. La columna Ideal contiene la tasa
a la cual se inyectaron los paquetes en el canal. Para cada esquema de modulación y
tamaño de paquete elegido, se eligieron tres tasas ideales. La más grande es la tasa
máxima soportada por dicho esquema3 , mientras que las otras dos son valores más
pequeños elegidos para probar el comportamiento del transmisor ante un canal no
saturado.
Las columnas Original y Mod. contienen las tasas de transferencia obtenidas por la
implementación original y la modificada respectivamente, mientras que las columnas %
sobre ideal contienen el porcentaje que representa la tasa de la implementación corres-
pondiente sobre la tasa ideal. Por último, la columna Acel. contiene la aceleración del
transmisor modificado frente al original.
En base a los resultados obtenidos, resulta claro que la implementación propuesta
obtiene mejoras sobre el transmisor en casi todos los casos, especialmente cuando la tasa
ideal se encuentra en valores cercanos al límite para la modulación actual. Esto se debe
a que al acercarse a la tasa ideal, la implementación original es incapaz de mantener
el ritmo impuesto por la tasa de paquetes inyectados, algo que la implementación
modificada es capaz de hacer hasta cierto punto. Además de esto, si se observan los
3
Esto es, 6 Mbps (768 KB/s) para BPSK 1/2 y 54 Mbps (6912 KB/s) para 64QAM 3/4.
93
5.2. Pruebas en hardware 94
En segundo lugar, se realizaron pruebas sobre una antena configurada para utilizar el
grafo del receptor. Se utilizó una computadora portátil configurada en modo monitor,
pero esta vez tomando el rol del transmisor. Para realizar el envío de paquetes, se
hizo uso del programa packetspammer incluido en gr-ieee-802-11. Este programa fue
configurado para enviar paquetes de tamaño configurable a una tasa configurable, y
según el esquema de modulación y tasa de codificación deseados.
94
Capítulo 5. Evaluación experimental
Tabla 5.11: Resultados obtenidos al realizar las pruebas sobre el receptor. Las columnas contienen
la misma información que en la Tabla 5.10, teniendo en cuenta que la tasa ideal es la tasa efectiva
enviada por el transmisor.
La Tabla 5.11 presenta los resultados obtenidos. Es importante observar que las
aceleraciones obtenidas son mucho menores que las obtenidas en la sección anterior.
Sin embargo, se mantiene el resultado de que cuanto más cerca de la tasa ideal, mejor se
comporta el receptor modificado frente a la versión original. Esto es especialmente cierto
en el caso de 64QAM 3/4 para paquetes de tamaño 1500 bytes, en donde se obtiene
una aceleración pico de 5,88 cuando el transmisor opera a una tasa ideal de 6884, 77
KB/s (correspondiente a 54 Mbps). El receptor modificado es capaz de decodificar los
paquetes en mucho menos tiempo, lo que resulta en una tasa de transferencia final
mayor a la original.
Además, cuanto más complejo es el esquema de modulación y mayor el tamaño
del paquete, más verdadera resulta la afirmación anterior, puesto que el receptor debe
realizar mucho más trabajo para decodificar un paquete.
Para realizar esta serie de pruebas, se utilizó una única máquina4 con las especifica-
ciones detalladas al comienzo de la sección. Se utilizaron dos USRP B210 conectados
a dicha máquina para oficiar de transmisor y receptor de la señal. Existe una cierta
similitud entre esta prueba y las realizadas en la Sección 5.1.3 debido a que ambos
4
No se utilizaron dos máquinas independientes para el transmisor y receptor debido a que los
USRP B210 requieren de una conexión USB 3.0 y solo se contaba con un equipo que soportara esta
característica.
95
5.2. Pruebas en hardware 96
Figura 5.7: Esquema de la prueba realizada con transmisor y receptor de gr-ieee802-11 operando de
forma simultánea en una misma máquina. En el esquema se puede apreciar que la computadora de
escritorio se encuentra conectada a dos USRP B210, uno que oficia de transmisor y otro de receptor.
La computadora principal ejecuta los grafos de flujo de GNU Radio para el transmisor y receptor y
se comunica con cada USRP a través de un puerto USB 3.0 independiente. El transmisor inyecta los
paquetes en el aire y el receptor decodifica los paquetes detectados en el medio.
96
Capítulo 5. Evaluación experimental
Tabla 5.12: Resultados obtenidos al realizar las mediciones de las pruebas de loopback en el aire.
Las columnas contienen la misma información que en la Tabla 5.10.
Las columnas Original y Mod. contienen las tasas de transferencia obtenidas por la
implementación original y la modificada respectivamente, mientras que las columnas %
sobre ideal contienen el porcentaje que representa la tasa de la implementación corres-
pondiente sobre la tasa ideal. Por último, la columna Acel. contiene la aceleración del
transmisor modificado frente al original.
La primera observación que puede hacerse respecto de las tasas de transferencia es
que son mucho menores a las tasas obtenidas en las pruebas en software, tanto para la
implementación original como para la mejorada. Esto tiene sentido debido a que, como
se explicó anteriormente, al estar transmitiendo en el aire existe una gran cantidad de
paquetes que se pierden, mientras que las pruebas de software, que simulaban un canal
perfecto, no tenían pérdidas.
En segundo lugar, se puede apreciar que la aceleración más grande es alcanzada en
paquetes de tamaño 50 bytes, y con tasas ideales altas, es decir, con un alto número
de paquetes por segundo inyectados en el medio. Esto es razonable, y es coherente con
todas las observaciones realizadas hasta el momento, tanto en la etapa de pruebas como
en la de profiling. Como se vio en secciones anteriores, es en los paquetes de tamaño
pequeño en donde más costo tiene el bloque OFDM Carrier Allocator, y consecuen-
temente, donde mayor es la mejora lograda al realizar modificaciones sobre el mismo.
Por esta razón, es lógico que paquetes de tamaño pequeño muestren una mejora más
grande en la tasa de transferencia que paquetes de mayor tamaño, debido a que los
primeros eran los más afectados por la ineficiencia del OFDM Carrier Allocator.
De la misma manera, también es razonable que la aceleración sea más grande a
medida que se transmiten más paquetes por segundo, debido a que luego de las mejoras
realizadas, el receptor es significativamente más veloz para realizar la decodificación de
97
5.2. Pruebas en hardware 98
la tramas, lo que permite que para una tasa de transmisión alta el receptor mejorado
pueda realizar más decodificaciones que el de la implementación original.
Además, también es importante observar que la aceleración más grande es lograda
al transmitir usando un esquema de modulación 64QAM con codificación 3/4, para
una tasa ideal alta y un paquete pequeño. Es razonable que esta configuración pre-
sente la mayor aceleración debido a que en la misma se combina un paquete pequeño,
lo cual explota de mejor manera la mejora realizada sobre el bloque OFDM Carrier
Allocator, con un esquema de modulación complejo y tasa de codificación alta, lo cual
explota de mejor manera las mejoras realizadas sobre el algoritmo de demodulación y
decodificación convolucional dentro del bloque OFDM Decode MAC.
En cuanto a los datos de las columnas % sobre ideal, se puede concluir que la imple-
mentación propuesta mejora ampliamente el porcentaje de cumplimiento de la tasa a
la cual se intentó transmitir, lo cual está relacionado con las columnas de aceleración y
tasa de transferencia ya analizadas. A partir de las columnas de % sobre ideal, también
es posible concluir que, si bien las mejoras logradas son muy significativas al comparar
con la implementación original, las tasas alcanzadas por la versión mejorada no son lo
suficientemente grandes como para poder competir con una implementación del están-
dar en hardware dedicado, al menos cuando se está ejecutando la SDR en una máquina
similar a la utilizada en estas pruebas, cuyas características fueron especificadas en la
Sección 5.1.
98
Capítulo 6
99
100
a cabo. Por último, se realizó la comparación del desempeño alcanzado tanto por la
implementación original como por la implementación con las mejoras propuestas, y se
realizaron pruebas de concepto sobre hardware SDR real.
Se valora como muy positivo el haber adquirido conocimientos de comunicaciones
inalámbricas, códigos convolucionales, OFDM, estándar Wi-Fi, Radios Definidas por
Software y de las ventajas que estas brindan a la hora de entender cómo funcionan
tanto las comunicaciones como Wi-Fi a bajo nivel, además de herramientas y librerías
comúnmente utilizadas como lo son GNU Radio, IT++ y BLAS.
Es común que para lograr grandes mejoras en el rendimiento de un grafo de flujo
de GNU Radio sea necesario unir varios bloques distintos en uno solo, de forma de
reducir el costo producto de la división. Esto es algo que se intenta evitar debido a
que atenta contra la modularidad del programa, ya que tiende a convertir a la SDR
en una aplicación monolítica. Por esta razón, se destaca que las mejoras realizadas se
lograron respetando el diseño original del programa; dicho de otra forma, manteniendo
la misma modularidad que existía originalmente.
En cuanto a las tasas finales alcanzadas, son muy buenas tanto al comparar con las
tasas logradas por la implementación original (las cuales eran entre dos y diez veces
más lentas) como al evaluar la tasa neta alcanzada, ya que por ejemplo, en 64QAM se
alcanza una transferencia de 10.8 Mbits por segundo en software.
A su vez, este rendimiento fue alcanzado en una computadora obsoleta para la
tecnología disponible hoy en día. Si bien no se evaluó en un equipo con un procesador
más potente (como por ejemplo, un Intel Core i7) o con una memoria RAM de mayor
frecuencia, se puede estimar con bastante certeza que las mejoras realizadas lograrían
tasas de transferencia aún mayores en un equipo con estas características.
Por otra parte, se destaca la excelente disposición que mostraron Bastian Bloessl
y Bogdan Diaconescu al ser contactados por algunas consultas y dudas acerca de la
implementación original de gr-ieee802-11 y del decodificador de Viterbi de gr-dvbt, res-
pectivamente. En el caso del primero, el autor se mostró muy interesado por el presente
trabajo, solicitando la posibilidad de que una vez que el mismo estuviese finalizado, se
le enviaran las modificaciones realizadas. Actualmente, el trabajo realizado se encuen-
tra publicado en el sitio de GitHub, creado como un fork de la versión original, y es
posible obtenerlo en [29]. Al momento de escribir este documento, las modificaciones
realizadas han sido enviadas a Bastian Bloessl para su evaluación y verificación.
También se destaca la muy buena disposición que hubo por parte de la comunidad
de GNU Radio para contestar dudas enviadas a la GNU Radio Mailing List, que fue
principalmente utilizada cuando la documentación disponible era insuficiente o incom-
pleta.
Para finalizar, existen muchas líneas de investigación como trabajo a futuro. Se
podría evaluar el diseñar e implementar una versión alternativa que cumpla con el
estándar y que utilice tanto el CPU como la GPU para realizar el procesamiento de la
100
Capítulo 6. Conclusiones y trabajo futuro
señal. Sin embargo, parece muy difícil que esto logre una mejora si se sigue trabajando
con la implementación de gr-ieee802-11 y se intenta aplicar a bloques por separado,
sin fusionar varios bloques en uno sólo primero.
También sería interesante estudiar posibles aplicaciones sobre los nuevos estándares
de Wi-Fi, 802.11n y 802.11ac. Estos estándares permiten alcanzar tasas de transferencia
mucho mayores, utilizando tecnologías como MIMO (Multiple-Input Multiple-Output),
que hacen uso de múltiples antenas transmisoras y receptoras funcionando en paralelo
para mejorar el desempeño del sistema. Los nuevos estándares también permiten rea-
lizar agrupación de tramas (aggregation), es decir, enviar hasta 64 KB de tramas sin
necesidad de esperar por un ACK. Podría ser interesante utilizar una arquitectura con
GPUs para realizar la decodificación de este gran número de tramas en paralelo.
Otra línea de investigación abierta sería evaluar la posibilidad de mover parte del
procesamiento de la señal que hoy se hace en CPU a la FPGA del USRP. Esto aumen-
taría la disponibilidad del CPU para aquellos bloques que continuasen su ejecución en
software en GNU Radio, mientras que para las tareas delegadas a la FPGA, se lograría
obtener un rendimiento equivalente al de un hardware dedicado tradicional.
101
Bibliografía
[1] J. Mitola, Software Radio Architecture, IEEE Commun. Mag., vol. 33, no. 5, May
1995, pp. 26–38
[2] Daniel M. Dobkin, RF Engineering for Wireless Networks: Hardware, Antennas
and Propagation, Newnes, Elsevier, London, 2005.
[3] Charan Langton, Intuitive Guide to Principles of Communication: All About Mo-
dulation - Part I, 2002.
[4] Hari Balakrishnan, Christopher Terman, y George Verghese, Bits, Signals, and
Packets: An Introduction to Digital Communications and Networks, M.I.T. De-
partment of EECS, 2012.
[5] B. Bloessl, M. Segata, C. Sommer y F. Dressler, An IEEE 802.11 a/g/p OFDM
Receiver for GNU Radio, ACM SIGCOMM 2013, Segundo Taller del ACM SIG-
COMM Software Radio Implementation Forum (SRIF 2013), páginas 9–16, Hong
Kong, China, Agosto 2013. ACM.
[6] Prof. Brad Osgood, Lecture Notes for EE 261: The Fourier Transform and its
Applications, Electrical Engineering Department, Standford University, 2012.
[7] A.J. Viterbi, Error bounds for convolutional codes and an asymptotically optimum
decoding algorithm, IEEE Trans. Inform. Theory, volumen IT-13, páginas 260-269,
Abril 1967.
[8] IEEE Computer Society, Wireless LAN Medium Access Control (MAC) and Phy-
sical Layer (PHY) Specifications, IEEE, 3 Park Avenue New York, March 2012.
103
Bibliografía 104
[11] Matthew E. Gast. 802.11 Wireless Networks: The definitive guide, O’Reilly
[17] Convolutional Decoders for Amateur Packet Radio Phil Karn, KA9Q, http://
www.ka9q.net/papers/cnc_coding.html (Obtenido 14/01/2016)
[19] L. Chia-Horng. On the design of OFDM signal detection algorithms for hardware
implementation. In IEEE GLOBECOM 2003, pages 596–599, San Francisco, CA,
December 2003. IEEE.
104
Bibliografía
[28] PyGraphviz, a Python interface to the Graphviz graph layout and visualization
package, https://pygraphviz.github.io/ (Obtenido 21/09/2015)
105
Anexo A
2. Instalar los prerrequisitos de GNU Radio. Esto puede hacerse mediante el uso del
script build-gnuradio, que puede encontrarse en Internet:
wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
./build-gnuradio && ./build-gnuradio -m -v prereqs
1
Para más información del proyecto, ver [25].
2
Es necesario disponer de permisos de administrador para realizar el procedimiento.
3
Para más información, ver [21].
107
108
108
Anexo A. Instalación de GNU Radio
10. Abrir GNU Radio Companion, la utilidad que se utiliza para editar y visualizar
los gráficos de flujo de GNU Radio. A continuación, localizar el archivo wi-
fi_phy_hier.grc que se encuentra en la carpeta examples, dentro del proyecto
gr-ieee802-11, y generarlo para que esté disponible como bloque.
11. Instalar Matplotlib8 , una biblioteca que permite producir figuras y gráficos 2D con
calidad de publicación en una variedad de formatos y plataformas. Es utilizada
por GNU Radio Performance Monitor para realizar todo tipo de gráficas:
sudo apt-get install python-matplotlib
109
110
13. Instalar PyGraphviz10 , una interfaz Python para el paquete Graphviz, utilizado
para visualizar gráficos. Nuevamente, una dependencia de GNU Radio Perfor-
mance Monitor:
sudo apt-get install python-pygraphviz
10
Para más información, ver [28].
110
Anexo B
La referencia [14] posee un enlace al tutorial oficial de GNU Radio, que describe
con detalle cómo crear módulos y bloques personalizables desde cero, por lo que no
se replica esa información en este anexo. Sin embargo, aquí se explican los pasos que
fueron necesarios para crear el bloque OFDM Carrier Allocator IEEE 802.11 dentro del
módulo IEEE 802.11. Los pasos seguidos no fueron exactamente los que se describen
en el tutorial oficial debido a que el módulo al cual el nuevo bloque debía pertenecer
ya existía, y la implementación del bloque y su estructura también ya existía (dentro
de la distribución oficial de GNU Radio).
Las rutas de archivos que se indican a continuación son relativas a la carpeta que
contiene los fuentes de GNU Radio, o a la que contiene los fuentes de gr-ieee802-11
según corresponda. De esta forma, los pasos seguidos fueron:
1. Copiar los fuentes de la implementación original del bloque OFDM Carrier Allo-
cator desde la distribución oficial de GNU Radio hacia la carpeta de instalación
del proyecto gr-ieee802-11.
Para esto, se deben copiar los archivos con nombre ofdm_carrier_allocator_impl
y con extensión .cc y .h, que se encuentran dentro de la carpeta de insta-
lación de GNU Radio en la ruta gnuradio/gr-digital/lib, hacia la carpeta
lib de la instalación de gr-ieee802-11. Además, es necesario copiar el fuente
ofdm_carrier_allocator_cvc.h que se encuentra en gnuradio/gr-digital/lib
hacia la carpeta include/ieee802-11 dentro de la carpeta de instalación de
gr-ieee802-11.
También es necesario copiar el fuente digital_ofdm_carrier_allocator_cvc.xml
ubicado en la carpeta gnuradio/gr-digital/lib a la carpeta grc/ de la instala-
ción de gr-ieee802-11. Este archivo es el que se encarga de definir la visualización
y propiedades del bloque que luego son mostradas en la herramienta GNU Radio
Companion.
111
112
2. Modificar los fuentes para cambiar el nombre del nuevo bloque de forma que
no conflictue con el ya existente OFDM Carrier Allocator, y que pertenezca al
módulo IEEE 802.11. Para esto, es necesario realizar cambios en el nombre de
los fuentes, el nombre de la clase que define el bloque, el namespace de la clase y
directivas de preprocesamiento, entre otros.
112
Anexo C
Glosario
113
114
MSDU (MAC Service Data Unit), Unidad de Datos del Servicio MAC:
Información transmitida como una unidad entre puntos de acceso.
114
Anexo C. Glosario
115
116
116
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: