UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Diseño e implementación de un sistemade comunicación VoIP usando una

plataforma ARM Cortex M7

Autor:Ing. Ericson Joseph Estupiñan Pineda

Director:Esp. Ing. Alejandro Celery

Jurados:Esp. Ing. Sergio Renato de Jesús Meleán (FIUBA)

Esp. Ing. Guillermo Evangelista (FIUBA)Esp. Ing. Marcelo E. Romeo (UNSAM, UTN-FRBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre enerode 2018 y diciembre de 2018.

III

Resumen

En esta memoria se presenta el diseño e implementación de un sistemaembebido de comunicación VoIP. Este sistema es un emprendimiento personalque además se espera que pueda servir para otros trabajos en el área. Se buscalograr una comunicación de voz full-duplex entre un teléfono inteligente y el

sistema embebido desarrollado.

Para el desarrollo del proyecto resultó necesario aplicar conocimientos deprotocolos de red RTP y RTCP, programación de sockets, diseño de máquinas de

estados, arquitectura disparada por eventos, control de versiones y diseño dePCB.

V

Agradecimientos

Quiero expresar mi gratitud a mis padres, mis amigos y mis tutores que de una yotra forma han ayudado que esté sueño se haga realidad.

VII

Índice general

Resumen III

1. Introducción General 11.1. Descripción del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2. Proyecto realizado . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Objetivo y Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introducción Específica 52.1. Diagrama general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2. Servidor de conmutación . . . . . . . . . . . . . . . . . . . . 62.1.3. Flujo de funcionamiento . . . . . . . . . . . . . . . . . . . . . 6

2.2. Tecnologías VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1. Protocolos RTP y RTCP . . . . . . . . . . . . . . . . . . . . . 72.2.2. Codificación G711 . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1. Asociados al sistema (RQ1XX) . . . . . . . . . . . . . . . . . 72.3.2. Asociados a la terminal embebido (RQ2XX) . . . . . . . . . . 82.3.3. Asociados a la terminal Android (RQ3XX) . . . . . . . . . . 82.3.4. Asociados a el Servidor de conmutación (RQ4XX) . . . . . . 9

2.4. Diagrama de planificación . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Diseño e Implementación 133.1. Sistema embebido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1. Plataforma ARM Cortex M7 . . . . . . . . . . . . . . . . . . . 133.1.2. Módulo Audio Codec WM8731 . . . . . . . . . . . . . . . . . 133.1.3. Codificación de audio G711 . . . . . . . . . . . . . . . . . . . 163.1.4. Protocolo RTP y RTCP . . . . . . . . . . . . . . . . . . . . . . 163.1.5. Módulo WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2. Aplicación Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3. Servidor conmutador de voz . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.1. Registro de terminales . . . . . . . . . . . . . . . . . . . . . . 203.3.2. Tabla de enrutamiento . . . . . . . . . . . . . . . . . . . . . . 203.3.3. Proceso de conmutación . . . . . . . . . . . . . . . . . . . . . 21

4. Ensayos y Resultados 234.1. Escenario para ensayos y resultados . . . . . . . . . . . . . . . . . . 23

4.1.1. Resultados servidor de conmutación . . . . . . . . . . . . . . 234.1.2. Resultados protocolo RTP y RTPC . . . . . . . . . . . . . . . 244.1.3. Resultados codificación G711 . . . . . . . . . . . . . . . . . . 274.1.4. Resultado diseño PCB . . . . . . . . . . . . . . . . . . . . . . 27

VIII

4.2. Códigos Fuente y diseños del proyecto . . . . . . . . . . . . . . . . . 27

5. Conclusiones 295.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Bibliografía 31

IX

Índice de figuras

1.1. Ilustración del sistema embebido, vista lateral. . . . . . . . . . . . . 31.2. Ilustración del sistema embebido, vista superior. . . . . . . . . . . . 31.3. Ilustración de la aplicación para terminal móvil Android. . . . . . . 4

2.1. Diagrama general del proyecto. . . . . . . . . . . . . . . . . . . . . . 52.2. Desglose de tareas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3. Diagrama AON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1. Modulo Audio Codec WM9731. . . . . . . . . . . . . . . . . . . . . . 143.2. Estructura de la biblioteca para WM8731. . . . . . . . . . . . . . . . 143.3. WM8731 Modo de funcionamiento Right Justified Mode. . . . . . . . 153.4. Archivos RTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5. Módulo NodeMCU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.6. Flujo de datos, módulo NudeMCU. . . . . . . . . . . . . . . . . . . . 183.7. Vista ingreso de identificación. . . . . . . . . . . . . . . . . . . . . . 183.8. Vista de funcionamiento PTT. . . . . . . . . . . . . . . . . . . . . . . 193.9. Vista de configuración. . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1. Escenario para ensayos y toma de resultados. . . . . . . . . . . . . . 234.2. Servidor de conmutación en ejecución. . . . . . . . . . . . . . . . . . 244.3. Tramas RTCP de estado. . . . . . . . . . . . . . . . . . . . . . . . . . 254.4. Tramas de voz RTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5. Diseño PCB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

XI

Índice de Tablas

3.1. Descripción de señales WM8731. . . . . . . . . . . . . . . . . . . . . 16

1

Capítulo 1

Introducción General

Este capítulo busca contextualizar al lector en el área del presente trabajo y ofreceruna descripción del funcionamiento esperado del proyecto.

1.1. Descripción del proyecto

1.1.1. Contexto

Los sistemas de comunicaciones y la Internet han abierto el paso a nuevas tec-nologías y paradigmas como lo es el Internet de las Cosas o IoT (Internet ofThings). De la mano con los sistemas embebidos se desarrollan nuevas aplica-ciones en diferentes áreas industriales y de consumo doméstico. En el área delas comunicaciones, las aplicaciones de VoIP (voice over IP, voz sobre IP) tomanmás importancia en el día a día de las personas, por esta razón el desarrollo deprocesamiento de voz y transporte en sistemas embebidos es fundamental.

A diferencia de la telefonía convencional que transmite la voz de forma análoga ypor medio de una red PSTN (Public Switched Telephone Network, red telefónicapública conmutada) para comunicar dos usuarios, el sistema VoIP se centra en ladigitalización de la señal de voz y su transporte por paquetes de datos sobre elprotocolo IP en la red de Internet. Este nuevo concepto ha dado paso a innumer-ables aplicaciones y a la forma en como se comunican hoy las personas; recibir alinstante la llamada de un familiar al otro lado del mundo ahora es algo normal.

Los sistemas de VoIP son un conjunto de diferentes tecnologías y recursos quehacen posible que la señal de voz viaje a través de la red de Internet [8], estas sondefiniciones importantes que se deben tener presente:

Terminal: determina el dispositivo que el usuario usa para comunicarse conotro usuario.

Señal de voz: hace referencia a las ondas eléctricas producidas por un sensorde voz.

Digitalización de señal de voz: proceso en el cual la señal de voz es trans-formada en datos binarios.

Codificación de voz: proceso por el cual la señal de voz digitalizada esprocesada por algoritmos para reducir el tamaño de la información.

Transporte: proceso en el cual la señal de voz codificada es transportada porla red de internet.

2 Capítulo 1. Introducción General

Servidor de conmutación: elemento de red encargado de recibir y redirigirlos datos de voz entre dos usuario.

Canal de voz: relación a nivel de red entre un receptor y un emisor, el servi-dor de conmutación crea este canal.

1.1.2. Proyecto realizado

El proyecto aquí documentado es un sistema de VoIP que permite la comuni-cación de un sistema embebido y una terminal móvil de sistema operativo An-droid. Para este fin, se diseñó e implementó un sistema embebido basado en laplataforma de desarrollo STM32 NUCLEO-F767ZI que integra un microproce-sador ARM Cortex M7, una aplicación Android y un servidor de conmutación.Con estos elementos en conjunto se logra que dos usuarios, uno con la terminalmóvil y otro con la terminal embebida establezcan una comunicación de voz.

El sistema embebido fue diseñado e implementado pensando en elegir los com-ponentes y tecnologías que lo hagan escalable; el sistema embebido se componede la plataforma como unidad de procesamiento central para la codificación devoz, el módulo de audio WM8731 para la digitalización de la señal de voz y asítambién su reproducción, el módulo NodeMCU ESP12E para la conexión a Inter-net por medio inalámbrico y el transporte de la señal de voz codificada.

La aplicación Android es un desarrollo nativo que permite la captura y repro-ducción de voz en formato digital, codificación de voz y transmisión en la red deInternet.

El servidor de conmutación es un programa que se aloja en un servidor permi-tiendo recibir y redirigir los datos de voz entre dos usuario. Es desarrollado enlenguaje C aplicando conocimientos adquiridos en la carrera de especializaciónen sistemas embebidos.

El funcionamiento del sistema en conjunto usa el método PTT (push to talk, pulsapara hablar) con un canal de voz preestablecido entre dos terminales con identi-ficador único. Así, de esta forma tanto el usuario A con la terminal móvil y elusuario B con la terminal embebida cuentan con un botón que al mantenerlo pul-sado abre el canal de voz; si ambos usuarios mantienen pulsado el botón se con-sigue una comunicación full-duplex. En la figura 1.1 y 1.2 se ilustra el resultadodel sistema embebido y en la figura 1.3 la aplicación para terminal Android.

1.2. Motivación

Los sistemas de VoIP actualmente están presentes en multitudes de ámbitos domés-ticos e industriales; desde la facilidad de una llamada internacional hasta sistemasde altavoz en zonas industriales. En vista de este auge de las comunicaciones devoz y las diferentes posibilidades que ofrece Internet se plantea el desarrollo deeste proyecto como un emprendimiento personal que sirva de precedente a fu-turos trabajos que puedan ser comercializados.

1.2. Motivación 3

FIGURA 1.1: Ilustración del sistema embebido, vista lateral.

FIGURA 1.2: Ilustración del sistema embebido, vista superior.

4 Capítulo 1. Introducción General

FIGURA 1.3: Ilustración de la aplicación para terminal móvil An-droid.

1.3. Objetivo y Alcance

El objetivo del proyecto es : diseñar e implementar un sistema de comunicaciónVoIP usando una plataforma ARM Cortex M7.

El proyecto que se presenta en este documento pretende ser una base conceptualy práctica para futuros proyectos. Por esta razón el alcance se limita a la siguientelista:

Captura de voz con el sistema embebido.

Reproducción de voz con el sistema embebidos.

Codificación y decodificación de voz.

Envío y recepción de paquetes RTP (Real-time Transport Protocol) sobreprotocolo TCP/IP.

Envío periódico de paquetes RTCP (Real Time Control Protocol) con identi-ficador de la terminal.

Implementación de un servidor de comunicación de voz utilizando el pro-tocolo RTP.

Desarrollo de una aplicación para teléfono inteligente Android que se inte-gre al sistema.

5

Capítulo 2

Introducción Específica

En este capítulo el lector encontrará una descripción más detallada y técnica delproyecto, además, de la planificación y organización del mismo.

2.1. Diagrama general

Empezar con un vista global del proyecto descrito es una buena ayuda para com-prender lo que se pretende lograr y los retos que se solucionaron. En la figu-ra 2.1 se ilustra el diagrama general del proyecto. En este diagrama se puedenidentificar las partes fundamentales del proyecto: terminales, sistema embebidoy servidor de conmutación.

FIGURA 2.1: Diagrama general del proyecto.

A continuación, de forma más específica se expone el funcionamiento técnico delproyecto describiendo cada elementos de red y su funcionamiento.

6 Capítulo 2. Introducción Específica

2.1.1. Terminal

Es un dispositivo con identificador único que se puede asociar al usuario, en esteproyecto el identificador tiene el formato URI (Uniform Resource Identifier) porejemplo: 4567@voipprovider.example.net. La terminal cuenta con conexión a In-ternet, captura de voz, reproducción de voz, codificación de voz, decodificaciónde voz y pulsador PTT para abrir el canal de voz. A continuación se listan especi-ficaciones técnicas de la terminal:

Digitalización de voz en formato PCM ( Pulse Code Modulation, modu-lación por impulsos codificados) de 16 bits a 8000 Hz.

Conexión WIFI.

Recepción y transmisión de voz bajo el protocolo RTP.

Transmisión periódica de paquetes de estado (o Keep-Alive) bajo el proto-colo RTCP con identificador único.

Codificación y decodificación de voz en formato G711 (PCMA o A-law).

Botón o pulsador PTT para establecer la comunicación de voz.

Es importante mencionar que las terminales deben transmitir en un período menora 60 segundos un paquete de estado al servidor de conmutación, reportando quese encuentran activas. Para la demostración de funcionamiento del proyecto seutilizan dos terminales, una terminal móvil con sistema operativo Android y unaterminal embebida, como anteriormente se ha expuesto en la sección 1.1.2.

2.1.2. Servidor de conmutación

Programa desarrollado para ser alojado en un servidor que tiene como princi-pal función conmutar los paquetes RTP entre las terminales. Las información dered de las terminales como: identificador único, dirección IP y puerto son reg-istrados con los paquetes de estado enviado por la misma terminal. Para la con-mutación de paquetes se usa un archivo como tabla de enrutamiento para es-tablecer previamente el canal de voz. Las siguientes líneas pertenecen al archivorouter_list.txt:

1001@ericsonj.net 1005@ericsonj.net1005@ericsonj.net 1001@ericsonj.net

En este archivo se listan los identificadores de las terminales, siendo el primerelemento de la fila el emisor y el segundo el receptor. En el ejemplo anterior elservidor de conmutación recibe los paquetes de voz de la terminal 1001@eric-sonj.net y los envía a la terminal 1005@ericsonj.net, de acuerdo a la primera línea;en la segunda línea, los paquetes recibidos de la terminal 1005@ericsonj.net sonenviados a la terminal 1001@ericsonj.net. Con este método se crea un canal de vozentre las dos terminales.

2.1.3. Flujo de funcionamiento

Describiendo el funcionamiento global del proyecto, las terminales al ser acti-vadas envían un paquetes RTCP con su identificador CNAME, el servidor de

2.2. Tecnologías VoIP 7

conmutación registra su información red y procede a conmutar los paquetes devoz de acuerdo al archivo de enrutamiento. Las terminales sólo envían paquetesde voz al oprimir el pulsador PTT.

2.2. Tecnologías VoIP

A continuación se exponen conceptos relacionados con VoIP. Éstos son necesariosen el diseño e implementación del proyecto y se aplican en el capitulo 3.

2.2.1. Protocolos RTP y RTCP

RTP (Real-Time Transport, protocolo de transporte en tiempo real) es un proto-colo de nivel de aplicación que proporciona una comunicación de extremo a ex-tremo para datos con características de tiempo real, tales como audio y/o vídeointeractivo. Este protocolo incluye encabezados de tipo de carga útil, secuencia depaquetes, marca de tiempo e identificadores. Las aplicaciones normalmente usanRTP sobre UDP.

RTCP (RTP Control Protocol, protocolo de control RTP) es un protocolo de nivelde aplicación que cuya principal función es proporcionar información sobre lacalidad de la distribución de los datos en RTP. SDES (Source Description RTCPPacket) es un tipo de paquete RTCP que lleva un identificador de nivel de trans-porte normalmente llamado CNAME (canonical name, nombre canónico). Parauna descripción oficial y detallada del protocolo ver [4].

2.2.2. Codificación G711

G711 es un codec de voz estándar de la ITU (International TelecommunicationsUnion) usado en la telefonía digital moderna. Cuenta con dos versiones A-law yU-law, PCMA y PCMU respectivamente. U-law es originaria del estándar T1 enNorteamérica y Japon; mientras que, A-law es originaria del estándar E1 usadoen el resto del mundo. G711 hace uso de un ancho de banda de 86 Kbps y escompatible con la mayoría de los proveedores de VoIP [7].

2.3. Requerimientos

Para la realización de este proyecto se debieron cumplir una serie de requerim-ientos, algunos de estos requerimientos fueron modificados o no alcanzados perosin cambiar la funcionalidad principal.

2.3.1. Asociados al sistema (RQ1XX)

RQ101: el sistema debe establecer un canal de comunicación de voz entredos terminales, una plataforma embebida y un celular inteligente Android.

8 Capítulo 2. Introducción Específica

2.3.2. Asociados a la terminal embebido (RQ2XX)

RQ201: la terminal debe ser compatible con la plataforma EDU-CIAA-NXPusando los puertos digitales, analógicos, SPI y I2C que sean necesarios.

Este requerimiento fue modificado en el desarrollo del proyecto, la platafor-ma EDU-CIAA-NXP fue cambiada por la plataforma NUCLEO-F767ZI. Conestá ultima se tenia mas experiencia y un trabajo previo.

RQ202: la terminal debe permitir la captura y reproducción de audio digitalPCM 16 bits a 8000Hz.

RQ203: la terminal debe permitir la codificación y decodificación de audioen el estándar G711.

RQ204: la terminal debe enviar y recibir datagramas RTP sobre el proto-colo de transporte UDP haciendo uso de algún módulo electrónico que lepermita una conexión a Internet.

RQ205: La terminal desarrollada debe permitir la conexión de salida y en-trada de audio estándar (Jack 3.5mm).

RQ206: las terminales deben contar con un ID único y reportarse periódica-mente al servidor de enrutamiento, que permita su identificación en la reddel sistema.

RQ207: Los terminales o dispositivos finales deben poder silenciar el micró-fono.

2.3.3. Asociados a la terminal Android (RQ3XX)

RQ301: se debe desarrollar una aplicación para teléfonos inteligentes An-droid programada en lenguaje JAVA y hacer uso del framework JNI paraimplementación de funciones en C de ser necesario.

Para cumplir con este requerimiento no fue necesario la implementación defunciones en C.

RQ302: la aplicación android debe implementar el protocolo RTP.

RQ303: la aplicación android debe enviar y recibir datagramas RTP sobre elprotocolo de transporte UDP.

RQ304: La aplicación android debe permitir la codificación y decodificaciónde audio en el estándar G711.

RQ305: la aplicación Android debe permitir la reproducción y captura deaudio.

RQ306: las aplicación deben contar con un identificador único y reportarseperiódicamente al servidor de conmutación y permitir su identificación enla red del sistema.

2.4. Diagrama de planificación 9

2.3.4. Asociados a el Servidor de conmutación (RQ4XX)

RQ401: se debe desarrollar un servidor de conmutación que permita la con-mutación de paquetes de voz entre dos terminales.

RQ402: el servidor de conmutación debe identificar las terminales o dispos-itivos finales conectados al sistema.

RQ403: el sistema debe permitir la creación y destrucción de canales de vozentre dos terminales desde el servidor de conmutación.

Este requerimiento fue cumplido de forma parcial, los canales de voz soncreador de forma previa y no pueden ser destruidos en tiempo de ejecucióndel programa de conmutación.

RQ404: el servidor debe redirigir los paquetes de voz y permitir la comuni-cación de dos terminales.

RQ405: El servidor de conmutación debe poder listar las terminales en elinstante.

2.4. Diagrama de planificación

Para el seguimiento del proyecto se utilizó el diagrama Gantt que ayudó a lamedición de tiempo y orden de las tareas a realizar. La figura 2.2 desglosa lastareas y la figura 2.3 ilustra el diagrama AON (Activity on node) donde los nodosmarcados en color rojo resaltan el camino critico del proyecto.

10 Capítulo 2. Introducción Específica

FIGURA 2.2: Desglose de tareas.

2.4. Diagrama de planificación 11

FIG

UR

A2.

3:D

iagr

ama

AO

N.

13

Capítulo 3

Diseño e Implementación

En el presente capítulo se presenta el diseño e implementación del proyecto de-sarrollado que se divide en tres partes: sistema embebido, aplicación Android yprograma conmutador de voz.

3.1. Sistema embebido

En esta sección se describen las partes que componen el sistema embebido.

3.1.1. Plataforma ARM Cortex M7

Para el desarrollo del sistema embebido se eligió la plataforma NUCLEO-F767ZIde la empresa STMicroelectronics. Cuenta con un microcontrolador STM32F767ZIde arquitectura ARM Cortex M7 a una velocidad de 216 MHz a un costo de $25dolares americanos aproximadamente [5].

De la plataforma de desarrollo se hace uso de dos (2) interfaces SPI y una (1) in-terfaz I2C. Las interfaces SPI se implementaron con DMA (direct memory access,acceso directo a memoria) para la conexión con el módulo de audio y de conexiónWiFi. En las subsección 3.1.2 y 3.1.5 se detalla la implementación respectivamente.

El procesador se encarga de la codificación G711, construcción de paquetes devoz RTP y paquetes periódicos de estado RTCP. No fue necesario el uso de unsistema operativo como FreeRTOS.

3.1.2. Módulo Audio Codec WM8731

Para la captura y digitalización de voz se utilizó el módulo AUDIO CODEC Board- PROTO de la empresa MikroElektronika [3]. En la figura 3.1 se ilustra el módulo,que se controla por una interfaz I2C y una interfaz SPI.

Este módulo se basa en el microcircuito WM8731 de la empresa Cirrus Logic, nospermite procesar muestras de audio desde 16 a 32 bits a una frecuencia de 8 KHza 96 KHz, salida estéreo y entrada de micrófono de un sólo canal (monofónico).Para este proyecto se eligió procesar muestras de audio PCM de 16 bits a 8 KHz,formato necesario para poder ser codificado en G711.

Según la hoja de datos del microcircuito descrita en [9] y las recomendacionesel módulo, la configuración de funcionamiento del módulo se realiza por una

14 Capítulo 3. Diseño e Implementación

FIGURA 3.1: Modulo Audio Codec WM9731.

interfaz I2C. Siguiendo estos lineamientos se programó una biblioteca para talconfiguración, en la figura 3.2 se ilustra su estructura.

FIGURA 3.2: Estructura de la biblioteca para WM8731.

Descripción de los archivos necesarios para usar la biblioteca:

main.c: código que utiliza las funciones de la biblioteca descritas enwm8731_drive.h.

HAL_I2C_imp.c: describe las funciones de bajo nivel que deben ser imple-mentadas según la plataforma.

En el algoritmo 3.1 se expone el código del archivo wm8731_drive.c.1 # include < s t d i n t . h>2 # include " wm8731_drive . h"3 # include "wm8731_imp . h"4

5 void WM8731_Init ( ) {6 HAL_init ( ) ;7 HAL_delayms ( 2 0 0 ) ;8 }9

10 void WM8731_CMD( u i n t 8 _ t address , u i n t 1 6 _ t cmd) {11 u i n t 8 _ t addr = address ;12 addr = addr << 1 ;13 u i n t 8 _ t cmd_upper = ( u i n t 8 _ t ) (cmd >> 8) ;14 addr = addr | cmd_upper ;15 u i n t 8 _ t data [ 2 ] = { addr , ( u i n t 8 _ t ) cmd } ;16 HAL_I2C_transmit (WM8731_ADDRESS, data , s i z e o f ( data ) ) ;17 HAL_delayms ( 2 0 ) ;18 }

ALGORITMO 3.1: wm8731_drive.c

El archivo wm8731_conf.h define variables de configuración del módulo, veralgoritmo 3.2.

3.1. Sistema embebido 15

1 # def ine _WM8731_left_l ineIn 0 x0180 // Mic s e t t i n g s2 # def ine _WM8731_Right_lineIn 0 x0180 // Mic s e t t i n g s3 # def ine _WM8731_Left_hp 0x00F2 // Headphone s e t t i n g s : −9dB

output4 # def ine _WM8731_Right_hp 0x00F2 // Headphone s e t t i n g s : −9dB

output5 # def ine _WM8731_AnalogAudio 0x14 // DAC S e l e c t6 # def ine _WM8731_DigitalAudio 0x067 # def ine _WM8731_power 0x00 // Disable Power down8 # def ine _WM8731_DAIF 0x40 // Enable Master Mode and 16 b i t data9 # def ine _WM8731_Sampling 0x0C // 8000Hz

10 # def ine _WM8731_Activate 0x01 // Module i s ON11 # def ine _WM8731_Deactivate 0x00 // Module i s OFF12 # def ine _WM8731_Reset 0x00 // Reset value

ALGORITMO 3.2: wm8731_conf.h

En el algoritmo 3.3 se muestra un ejemplo de configuración para captura y repro-ducir de audio en formato PCM 16 Bits a 8 KHz.

1 WM8731_Init ( ) ;2

3 HAL_Delay ( 1 0 0 ) ;4

5 WM8731_CMD(WM8731_REG_RESET , _WM8731_Reset ) ;6 WM8731_CMD(WM8731_REG_LLINE_IN , _WM8731_left_l ineIn ) ;7 WM8731_CMD(WM8731_REG_RLINE_IN , _WM8731_Right_lineIn ) ;8 WM8731_CMD(WM8731_REG_LHPHONE_OUT, _WM8731_Left_hp ) ;9 WM8731_CMD(WM8731_REG_RHPHONE_OUT, _WM8731_Right_hp ) ;

10 WM8731_CMD(WM8731_REG_ANALOG_PATH, _WM8731_AnalogAudio ) ;11 WM8731_CMD(WM8731_REG_DIGITAL_PATH, _WM8731_DigitalAudio ) ;12 WM8731_CMD(WM8731_REG_PDOWN_CTRL, _WM8731_power ) ;13 WM8731_CMD( WM8731_REG_DIGITAL_IF , _WM8731_DAIF) ;14 WM8731_CMD(WM8731_REG_SAMPLING_CTRL, _WM8731_Sampling ) ;

ALGORITMO 3.3: main.c

La captura de audio se realiza por medio de una interfaz SPI con diferentes for-mas de funcionamiento especificadas en la hoja de datos. En este proyecto seeligió el funcionamiento Right Justified Mode ilustrado en la figura 3.3 tomada de[9].

FIGURA 3.3: WM8731 Modo de funcionamiento Right JustifiedMode.

La figura 3.3 ilustra 5 señales para la captura y reproducción de audio, estas sondescritas en la tabla 3.1. Es importante mencionar que la captura y reproduc-ción de audio es monofónico, por esta razón las muestras de audio capturadas serepiten para el canal izquierdo y derecho.

16 Capítulo 3. Diseño e Implementación

TABLA 3.1: Descripción de señales WM8731.

Señal Descripción

DACLRC Señal de selección de canal para reproducción de audio.ADCLRC Señal de selección de canal para captura de audio.SCLK Reloj de sincronizaciónDACDAT Datos para reproducción de audio.ADCDAT Datos de captura de audio.

A nivel de la plataforma NUCLEO-F767ZI se usó una interfaz SPI con recepción ytransmisión de datos por DMA, buffer circular e interrupciones; se procesan 160muestras de audio de 16 bits cada 20 milisegundos.

3.1.3. Codificación de audio G711

El algoritmo de codificación G711 fue tomador de [6] y fue adaptado para ser us-ado en la plataforma embebida y reescrito en lenguaje JAVA para implementarseen la aplicación Android.

En el algoritmo 3.4 se exponen las funciones principales para la codificación ydecodificación de muestras de voz.

1 // Muestra PCM 16 b i t s a A−LAW2 u i n t 8 _ t l inear2a law ( u i n t 1 6 _ t pcm_val )3 // Muestra A−LAW a PCM 16 b i t s4 u i n t 1 6 _ t a law2l inear ( u i n t 8 _ t a_val )5

6 // Muestra PCM 16 b i t s a U−LAW7 u i n t 8 _ t l inear2ulaw ( u i n t 1 6 _ t pcm_val )8 // Muestra U−LAW a PCM 16 b i t s9 u i n t 1 6 _ t ulaw2l inear ( u i n t 8 _ t u_val )

10

11 // Muestra A−LAW a U−LAW12 i n t alaw2ulaw ( i n t aval )13

14 // Muestra U−LAW a A−LAW15 i n t ulaw2alaw ( i n t uval )

ALGORITMO 3.4: Funciones g711.c

Es importante mencionar que se utilizó las funciones relacionadas con A-LAWpara codificación y decodificación de voz.

3.1.4. Protocolo RTP y RTCP

Para la implementación de los protocolos RTP y RTCP se realizo un biblioteca yuna función respectivamente. RTP básicamente agrega un encabezado de 12 bytesa los 160 bytes de la voz codificada, para cada paquete incrementa un contador(sequence number) y la marca de tiempo (timestamp). Del protocolo RTCP sólo seimplementaron los paquetes de tipo SDES con el ítem CNAME, por esta razón essólo una función que construye este paquete. Es importante mencionar que se usael protocolo RTCP para enviar los paquetes de estado al servidor de conmutación.

3.1. Sistema embebido 17

En la figura 3.4 se ilustra los archivos de la biblioteca RTP. El archivo main.cutiliza las funciones definidas en el archivo rtp.h.

FIGURA 3.4: Archivos RTP.

En el algoritmo 3.5 se expone la definición de las funciones de la biblioteca.

1 // I n i c i o de v a r i a b l e s RTP .2 void RTP_Init ( void ) ;3

4 // Agregar encabezados a l paquete ( array de bytes ) .5 void RTP_AddHeader ( u i n t 8 _ t ∗ frame ) ;6

7 // Agregar encabezados a l primer paquete ( array de bytes ) .8 void RTP_AddHeaderMark ( u i n t 8 _ t ∗ frame ) ;9

10 // Agregar encabezado calculando s i g u i e n t e valor de v a r i a b l e s11 // Usar cada vez que se envie un paquete .12 void RTP_AddVarHeader ( u i n t 8 _ t ∗ frame ) ;

ALGORITMO 3.5: Archivo rtp.h

Para más información y código fuente remitirse a [2].

3.1.5. Módulo WiFi

La conexión a Internet se realizó por medio WiFi usando el módulo NodeMCUque integra a su vez el ESP12E. En la figura 3.5 se ilustra este.

FIGURA 3.5: Módulo NodeMCU.

De este módulo se usó la interfaz HSPI en modo maestro que recibe y trans-mite paquetes en protocolo UDP. Básicamente funciona como un puente entrelos datos recibidos por HSPI a paquetes UDP y viceversa. Ademas, ya que tiene

18 Capítulo 3. Diseño e Implementación

un consumo alto de corriente se hizo uso de una fuente externa de alimentación,ver figura 1.2.

Los datos recibidos por la interfaz HSPI deben tener un encabezado de inicio y delongitud que son usados para construir el paquete UDP y enviarlo a el servidorde conmutación; para los paquetes recibidos, estos se transmiten por la interfazHSPI con sus respectivos encabezados de inicio y longitud.

FIGURA 3.6: Flujo de datos, módulo NudeMCU.

Para la programación del NodeMCU se usó el IDE Arduino y sus bibliotecas. Elcódigo fuente puede ser encontrado en [1].

3.2. Aplicación Android

Aplicación para teléfonos inteligentes con sistema operativo Android. Se desar-rolló para ser un apoyo en la demostración del funcionamiento del proyecto, loque permitió tener una comunicación de voz con el sistema embebido.

La aplicación se diseñó para ser sencilla y fácil de usar, se tienen tres vistas: vistade ingreso de identificador único, funcionamiento PTT y configuraciones. En lafigura 3.7 se ilustra la vista de ingreso de identificador. El usuario debe ingresarun número y un nombre de usuario que son usados para construir el paquete deregistro RTCP.

FIGURA 3.7: Vista ingreso de identificación.

La figura 3.8 ilustra la vista de funcionamiento PTT, el usuario debe oprimir elbotón verde para abrir el canal de voz, para cerrarlo debe oprimir el mismo botón,ahora de color rojo. Para activar o desactivar el altavoz oprimir el botón inferior

3.3. Servidor conmutador de voz 19

con el ícono de parlante. La figura 3.9 ilustra la vista de configuración donde sedebe ingresar dirección IP y puerto del servidor conmutado.

FIGURA 3.8: Vista de funcionamiento PTT.

FIGURA 3.9: Vista de configuración.

3.3. Servidor conmutador de voz

Se ha diseñado para conmutar paquetes de voz sobre protocolo RTP y registrarlas terminales por medio de paquetes RTCP. Con el objetivo de ser un progra-ma sencillo y aplicar los conocimientos adquiridos, se eligió C como lenguaje deprogramación con uso de sockets y un método fácil de especificar las rutas en-tre terminales. El programa fue diseñado para ejecutarse en un sistema operativoGNU/Linux.

20 Capítulo 3. Diseño e Implementación

3.3.1. Registro de terminales

Las terminales son registradas en el servidor cada vez que se recibe un paqueteRTCP de tipo SDES, para información más detallada de este tipo de paquete verla sección 6.5 en [4].

El registro de las terminales se realiza en un mapa donde el CNAME es el identi-ficador único y la información de red el valor. Cada vez que se recibe un paquetede registro, el mapa de terminales es actualizado; si la terminal ya existe, su infor-mación de red es actualizada, si no existe esta es creada. Las terminales que dejande enviar paquetes RTCP como Keep-Alive en un tiempo superior a 60 segundosson eliminadas del mapa y se consideran desconectadas. Ver algoritmo 3.6.

1 # def ine PACKET_SIZE 2562

3 u i n t 8 _ t packect [ PACKET_SIZE ] ;4

5 while (TRUE) {6 recvfrom ( socket , packet , sockaddr ) ;7 i f ( isRTCP_SDES ( packet ) ) {8 MAP_outdate ( ) ; // Eliminar termina les desconectadas .9 char cname [ 3 2 ] ;

10 readCNAME( cname , packet ) ;11 i f ( MAP_exist ( cname ) ) {12 MAP_put( cname , sockaddr ) ; // Agregar a mapa .13 } e l s e {14 MAP_touch ( cname , sockaddr ) ; // Actua l izar mapa .15 }16 }17 }

ALGORITMO 3.6: Registro de terminales.

3.3.2. Tabla de enrutamiento

Para establecer las rutas de comunicación (canales de voz) se hizo uso de un archi-vo de tipo .txt que es leído al iniciar el servidor de conmutación (o programade conmutación), por cada línea se describe una ruta siguiendo el formato: iden-tificador de la terminal de origen seguido de espacio y luego de identificador dedestino. A continuación un ejemplo del archivo router_list.txt:

Linea 1: 1001@ericsonj.net 1005@ericsonj.netLinea 2: 1005@ericsonj.net 1001@ericsonj.net

El servidor de conmutación lee este archivo y guarda las rutas en un tabla de doscolumnas, CNAME de origen y CNAME destino. La tabla a nivel de código es unarray de una estructura de con dos campos. Ver algoritmo 3.7.

1 s t r u c t {2 char cname_src [KEY_LENGTH ] ;3 char cname_des [KEY_LENGTH ] ;4 } r t p _ r o u t e _ t ;5

6 r t p _ r o u t e _ t routeTable [NUM_ROUTES] ; // Tabla de enrutamiento7

8 f i l e = fopen ( " r o u t e r _ l i s t . t x t " , " r " ) ;9

10 while ( ( read = g e t l i n e (& l i n e , f i l e ) ) != −1) {

3.3. Servidor conmutador de voz 21

11 s s c a n f ( l i n e , " % s % s " , routeTable [ i ] . cname_src , routeTable [ i ] .cname_des ) ;

12 }

ALGORITMO 3.7: Lectura de archivo de enrutamienot.

Esta tabla de enrutamiento define la terminal de origen y la terminal destino parala conmutación de los paquete de voz RTP.

3.3.3. Proceso de conmutación

Proceso por el cual el servidor de conmutación recibe y transmite los paquetesde voz RTP bajo determinadas reglas. Las reglas están definidas por la tabla deenrutamiento.

Para asociar los paquetes RTP recibidos con su respectiva terminal se hace usodel mapa de terminales, creado en el registro, comparando la información de red(dirección IP y puerto de origen). De esta forma se asocia el identificador único ycon este se busca en la tabla de enrutamiento para encontrar el identificador dedestino.

Con el identificador de destino se obtiene la información de red del mapa de ter-minales; finalmente el paquete de voz RTP es transmitido a la terminal de destino.Ver algoritmo 3.8.

1 # def ine PACKET_SIZE 2562

3 u i n t 8 _ t packect [ PACKET_SIZE ] ;4

5 while (TRUE) {6 recvfrom ( socket , packet , sockaddr ) ;7 i f ( isRTP ( packet ) ) {8 device_src = MAP_getDevice ( packet ) ;9 cname_des = ROUTER_TABLE_getDes ( dev ice_src . cname ) ;

10 device_des = MAP_get ( cname_des ) ;11 sento ( socket , packet , device ) des . sockaddr ) ;12 }13 }

ALGORITMO 3.8: Proceso de conmutación

23

Capítulo 4

Ensayos y Resultados

En este capítulo se exponen los ensayos y resultados obtenidos al finalizar elproyecto; además, se presenta una sección que recopila todos los diseños y códi-gos fuente del proyecto.

4.1. Escenario para ensayos y resultados

Para el proceso de ensayos y recopilación de resultados se instaló el escenarioilustrado en la figura 4.1.

Enrutador WIFI: punto de conexión a la red local 192.168.88.0/24.

Servidor de conmutación: alojado en un computador de escritorio conecta-do a la red local con la dirección IP 192.168.88.64.

Teléfono inteligente Android: terminal con la aplicación desarrollada y conec-tado a la red local con la dirección IP 192.168.88.72.

Terminal embebida: sistema implementado conectado a la red local con ladirección IP 192.168.88.70.

FIGURA 4.1: Escenario para ensayos y toma de resultados.

4.1.1. Resultados servidor de conmutación

Bajo el escenario planteado, el servidor de conmutación registra las terminales.En la figura 4.2 se evidencia el archivo de enrutamiento y la recepción de las

24 Capítulo 4. Ensayos y Resultados

tramas de estado enviadas por las terminales. De esta forma se cumple con losrequerimientos RQ101, RQ401 a RQ405 descritos en el sección 2.3.

FIGURA 4.2: Servidor de conmutación en ejecución.

4.1.2. Resultados protocolo RTP y RTPC

Para las evidencias a nivel del protocolo de red se hizo uso del programa Wire-shark; este programa se ejecuto en la computadora de escritorio donde se alojoel servidor de conmutación, capturando de esta forma las diferentes tramas deinterés.

En la figura 4.3 se evidencia la recepción de paquetes de estado enviados por lasterminales en protocolo RTCP, se puede observar los paquetes de tipo SDES consu respectivo campo CNAME como identificador único de cada terminal.

En la figura 4.4 se evidencia la conmutación de paquetes de voz en protocolo RTP,se puede observar las direcciones IP de origen y destino, estructura del paqueteRTP y tipo de carga útil.

Con lo anterior expuesto se evidencia los requerimientos RQ204, RQ206, RQ303y RQ306 descritos en la sección 2.3.

4.1. Escenario para ensayos y resultados 25

FIG

UR

A4.

3:Tr

amas

RTC

Pde

esta

do.

26 Capítulo 4. Ensayos y Resultados

FIG

UR

A4.

4:Tr

amas

devo

zR

TP.

4.2. Códigos Fuente y diseños del proyecto 27

4.1.3. Resultados codificación G711

En la figura 4.4 se evidencia la conmutación de paquetes de voz codificados enG711 PCMA entre las terminales, se puede observar en la estructura del paqueteRTP en el campo de tipo de carga útil. De esta forma se evidencia los requerim-ientos RQ203 y RQ304 que se describen en la sección 2.3.

4.1.4. Resultado diseño PCB

Aunque en los alcances del proyecto no se especificó el diseño de una placa im-presa, está se diseñó para conectar y organizar la plataforma de desarrollo y losmódulos utilizados en el sistema embebido, ver la figura 4.5. El diseño fue real-izado en KiCad.

FIGURA 4.5: Diseño PCB.

4.2. Códigos Fuente y diseños del proyecto

En la presente sección se encuentran recopilados códigos fuente y diseños delproyecto.

Firmware plataforma ARM Cortex M7 NUCLEO-F767ZI.Repositorio: https://github.com/ericsonj/Firmware-VoIP-NUCLEO-F767ZI.Lenguaje de programación: C.Editor: OpenSTM32.

Firmware NodeMCU hspi2udp.Repositorio: https://github.com/ericsonj/Firmware-NodeMCU-hspi2udpLenguaje de programación: C++.Editor: Arduino IDE.

Programa conmutador de voz (RTPServer).Repositorio: https://github.com/ericsonj/RTPServerLenguaje de programación: C.Editor: Emacs.

Aplicación Android AppRTP.Repositorio: https://github.com/ericsonj/AppRTPLenguaje de programación: JAVAEditor: Android Studio.

28 Capítulo 4. Ensayos y Resultados

Diseño de PCB.Repositorio: https://github.com/ericsonj/CESE2018-PCB-TPPrograma de diseño: KiCad.

29

Capítulo 5

Conclusiones

5.1. Conclusiones generales

El proyecto logró ser una referencia en lo personal en los sistemas VoIP; se dise-ñó e implementó un sistema embebido que puede establecer una comunicarsede voz con un teléfono inteligente. Para una mejora en la calidad de la comu-nicación y los recursos de red, la codificación de voz debe ser modificada paraque comprima más la información de voz. A continuación se listan los logros delproyecto:

Comunicación full-duplex entre una terminal móvil Android y una termi-nal embebida ARM Cortex M7.

Se desarrolló una aplicación Android para terminal móvil que permite lademostración del funcionamiento del sistema embebido

Se implementó un programa conmutador de VoIP alojado en un servidorque crea un canal de voz entre las dos terminales.

Es importante resaltar que de los requerimientos planteados inicialmente uno deestos no se logro cumplir, sin embargo no afecta el objetivo principal del proyec-to. Se proyectó usar la plataforma EDU-CIAA-NXP que fue cambiada a razón deinexperiencia y falta en los tiempos de desarrollo, este cambio no afectó el fun-cionamiento final del proyecto.

5.2. Próximos pasos

En esta sección se listan los próximos pasos a partir del proyecto:

Implementación de protocolo SIP incorporando el concepto de llamada. Deesta forma el sistema embebido puede integrarse con centrales de telefonía,por ejemplo Asterisk, y estar en capacidad de realizar llamadas a PBX oteléfonos fijos y/o móviles.

Codificadores de voz que mejoren en compresión, iLBC, G726, G729 etc.Un mejor nivel de compresión reduce el ancho de banda de red utilizadoaunque tenga un efecto en la latencia de la comunicación.

Algoritmos de cancelación de eco para mejorar la experiencia del usuarioen una comunicación full-dupex con altavoces.

30 Capítulo 5. Conclusiones

Algoritmos de detección de voz para la reducción de ruido ambiente en unacomunicación.

31

Bibliografía

[1] Ericson J. Estupiñan. Firmware NodeMCU hspi2udp. Disponible: 2018-11.2018. URL: https://github.com/ericsonj/Firmware-NodeMCU-hspi2udp.

[2] Ericson J. Estupiñan. Firmware VoIP NUCLEO-F767ZI. Disponible: 2018-11.2018. URL: https://github.com/ericsonj/Firmware-VoIP-NUCLEO-F767ZI.

[3] MikroElektronika. Audio Codec Board - PROTO. Disponible: 2018-02. 2018.URL: https://www.mikroe.com/audio-codec-proto-board.

[4] H. Schulzrinne. RTP: A Transport Protocol for Real-Time Applications. RFC3550. Jul. de 2003. DOI: 10.17487/rfc3550. URL:https://tools.ietf.org/rfc/rfc3550.txt.

[5] st.com. STM32F767ZI. Disponible: 2018-02. 2018. URL:https://www.st.com/en/microcontrollers/stm32f767zi.html.

[6] Sun Microsystems, Inc. g711.c. Disponible: 2018-02. 2018. URL:https://www.google.com/url?q=http://web.mit.edu/audio/src/build/i386_linux2/sox-11gamma-cb/g711.c&sa=U&ved=0ahUKEwil2srt0ODeAhWSrFMKHR7WDDEQFggEMAA&client=internal-uds-cse&cx=004136013456600655141:f3vpxqumfku&usg=AOvVaw2A8qPIBVFFdlN1wKN28W5I.

[7] Voip-info.org. ITU G.711. Disponible: 2003-07. 2018. URL:https://www.voip-info.org/itu-g711.

[8] Voip-info.org. What is VOIP. Disponible: 2003-07. 2018. URL:https://www.voip-info.org/what-is-voip.

[9] Wolfson microelectronics. Portable Internet Audio CODEC with HeadphoneDriver and Programmable Sample Rates. Disponible: 2018-02. 2018. URL:https://statics.cirrus.com/pubs/proDatasheet/WM8731_v4.9.pdf.