proyecto de fin de máster -...
TRANSCRIPT
Proyecto de Fin de Máster
Máster en electrónica, tratamiento de señal y comunicaciones
Orientación Teórico – Experimental
“SISTEMA DE INFORMACIÓN Y ORIENTACIÓN PARA
DISCAPACITADOS VISUALES BASADO EN ENLACES BLUETOOTH”
Autor: Ing. Luis Esteban Marsal Pederzani.
Tutor: Dr. Federico José Barrero García.
Universidad de Sevilla,
Escuela Superior de Ingenieros,
Departamento de Ingeniería Electrónica.
Diciembre – 2010
i
Quisiera expresar profundo agradecimiento a todas las personas que han colaborado
en todos estos años a mi formación personal, académica y profesional. Fruto de tantos
consejos y apoyo, es este Proyecto de Fin de Máster que espero sea útil a muchas
personas.
A mi familia que está siempre presente, que me brinda su incansable su apoyo y sostén.
A Federico Barrero y Sergio Toral, que me han recibido de brazos abiertos, por sus
consejos, sus orientaciones y sus oportunos tirones de oreja (esos son de Fede).
A Enrique Vargas, por brindarme una excelente formación durante la carrera y
haberme dado la oportunidad de viajar hasta aquí para realizar este trabajo.
A David Ismajovich, Alfredo Steinmann, Padre Silvio Suárez y Rigoberto Pérez, por sus
consejos, su confianza y sus incesantes palabras y muestras de apoyo.
A Joel Prieto, José Riveros y Blas Bogado, por su amistad, su apoyo y por hacerme sentir
no tan lejos de nuestra Patria.
A José María Hinojo, Francisco Cortés Martínez, Porfirio Miguel, Diego Medina y Derlis
Orlando Gregor, amigos y compañeros de trabajo de Sevilla, con quienes tengo el
placer de compartir el día a día, por todo lo que me han enseñado.
A todos mis amigos, que me han demostrado que el tiempo y la distancia no son
obstáculos para los sentimientos profundos y que están siempre presentes.
A todos los profesores de la Universidad Católica “Nuestra Señora de la Asunción” y de
la Universidad de Sevilla, quienes me han ofrecido una excelente formación.
ii
Índice
1. CAPÍTULO 1 INTRODUCCIÓN .................................................................................................. 1
1.1. ANTECEDENTES Y JUSTIFICACIÓN ...................................................................................... 1
1.2. OBJETIVOS DEL TRABAJO ................................................................................................... 3
1.2.1. OBJETIVOS GENERALES .................................................................................................... 3
1.2.2. OBJETIVOS ESPECÍFICOS ................................................................................................... 3
2. REVISIÓN DEL ESTADO DEL ARTE ........................................................................................... 4
2.1. INTRODUCCIÓN .................................................................................................................. 4
2.2. TECNOLOGÍA PARA DISCAPACITADOS VISUALES ............................................................... 4
2.3. TECNOLOGÍA INALÁMBRICA PARA LA TRANSMISIÓN DE DATOS ..................................... 10
2.3.1. BLUETOOTH ................................................................................................................ 10
2.3.2. ZIGBEE ....................................................................................................................... 11
2.3.3. RFID ......................................................................................................................... 12
2.3.4. ULTRA WIDE BAND ....................................................................................................... 14
2.3.5. WI-FI ......................................................................................................................... 15
2.3.5.1. 802.11a ................................................................................................................ 15
2.3.5.2. 802.11b ............................................................................................................... 16
2.3.5.3. 802.11g ................................................................................................................ 16
2.3.5.4. 802.11n ............................................................................................................... 17
2.3.6. WIMAX ..................................................................................................................... 18
2.4. COMPARATIVA ................................................................................................................. 19
2.5. ELECCIÓN TECNOLÓGICA ................................................................................................. 23
3. BLUETOOTH COMO TECNOLOGÍA INALÁMBRICA ................................................................. 25
3.1. INTRODUCCIÓN ................................................................................................................ 24
iii
3.2. DESCRIPCIÓN GENERAL .................................................................................................... 24
3.3. ARQUITECTURA BLUETOOTH ........................................................................................... 27
3.3.1. RADIO ........................................................................................................................ 28
3.3.2. BANDA BASE ............................................................................................................... 29
3.3.2.1. Canales físicos ..................................................................................................... 30
3.3.2.2. Enlaces físicos ...................................................................................................... 33
3.3.2.3. Transportes lógico ............................................................................................... 34
3.3.2.4. Enlaces lógicos..................................................................................................... 35
3.4. CÓDIGO DE ACCESO ......................................................................................................... 36
3.5. OPERACIÓN DEL CONTROLADOR DE ENLACES ................................................................. 38
3.6. LMP .................................................................................................................................. 46
3.7. MODOS DE OPERACIÓN ................................................................................................... 48
3.8. HCI .................................................................................................................................... 50
3.8.1. COMANDOS HCI .......................................................................................................... 51
3.9. L2CAP ............................................................................................................................... 52
3.9.1. MODO DE OPERACIÓN DE L2CAP .................................................................................... 55
3.10. PERFILES ........................................................................................................................... 57
3.11. RFCOMM .......................................................................................................................... 59
3.11.1. SEÑALES DE CONTROL .................................................................................................... 61
3.11.2. EMULACIÓN MÓDEM-NULL ........................................................................................... 61
3.11.3. PUERTO SERIE EMULADO ................................................................................................ 61
4. DESCRIPCIÓN DEL SISTEMA ................................................................................................... 64
4.1. INTRODUCCIÓN ................................................................................................................ 63
4.2. SERVICIOS ......................................................................................................................... 63
4.2.1. SERVICIO DE INFORMACIÓN ............................................................................................ 64
iv
4.2.2. SERVICIO DE ORIENTACIÓN ............................................................................................. 64
4.2.3. SERVICIO DE LOCALIZACIÓN ............................................................................................. 65
4.2.4. SERVICIO DE ALERTA ...................................................................................................... 65
4.3. HARDWARE DEL SISTEMA ................................................................................................ 66
4.4. SOFTWARE DEL SISTEMA ................................................................................................. 66
4.5. PARTICULARIDADES DEL SISTEMA PROPUESTO ............................................................... 68
5. HARDWARE DEL SISTEMA ..................................................................................................... 73
5.1. INTRODUCCIÓN ................................................................................................................ 72
5.2. BALIZA PRINCIPAL ............................................................................................................ 72
5.2.1. BEAGLE BOARD ............................................................................................................ 73
5.2.2. MOPS-PM ................................................................................................................ 73
5.2.3. PM-LX Y PM-GX ........................................................................................................ 74
5.3. COMPARACIÓN ENTRE ALTERNATIVAS DE ELEMENTOS FIJOS ........................................ 75
5.4. BALIZA DE LOCALIZACIÓN ................................................................................................ 75
5.4.1. MICROCONTROLADOR ATMEGA 8 ................................................................................. 76
5.4.2. MÓDULO BLUETOOTH BLUEGIGA WT12 .......................................................................... 78
5.4.3. CONFIGURACIÓN DEL MÓDULO ........................................................................................ 80
5.5. HARDWARE DEL MÓVIL.................................................................................................... 82
5.5.1. OPENMOKO ................................................................................................................ 82
5.5.2. NANOLIAB ................................................................................................................... 83
5.5.3. LIMESTONE ................................................................................................................. 84
5.6. COMPARACIÓN ENTRE ALTERNATIVAS DE MÓVILES ....................................................... 85
5.7. LA PLATAFORMA OPENMOKO ......................................................................................... 85
5.8. HARDWARE DESARROLLADO ........................................................................................... 87
6. SOFTWARE DEL SISTEMA ...................................................................................................... 90
6.1. INTRODUCCIÓN ................................................................................................................ 89
v
6.2. SISTEMA OPERATIVO ........................................................................................................ 89
6.3. DISTRIBUCIONES LINUX .................................................................................................... 90
6.3.1. DEBIAN ...................................................................................................................... 91
6.3.2. UBUNTU ..................................................................................................................... 91
6.3.3. FEDORA ...................................................................................................................... 92
6.3.4. GENTOO ..................................................................................................................... 92
6.3.5. DAMN SMALL LINUX ..................................................................................................... 93
6.3.6. LFS (LINUX FROM SCRATCH) .......................................................................................... 93
6.4. DISTRIBUCIÓN DE LA BALIZA PRINCIPAL .......................................................................... 94
6.5. DISTRIBUCIÓN DEL CLIENTE ............................................................................................. 95
6.5.1. DISTRIBUCIONES COMUNITARIAS ..................................................................................... 95
6.5.2. DISTRIBUCIONES NO OFICIALES ........................................................................................ 95
6.6. APLICACIONES DE LA BALIZA PRINCIPAL .......................................................................... 96
6.6.1. APLICACIÓN PRINCIPAL .................................................................................................. 97
6.6.2. BUSCA_CLIENTES .......................................................................................................... 98
6.6.3. PASARELA ................................................................................................................... 99
6.6.4. SERVIDOR WEB ........................................................................................................... 100
6.6.5. MANEJO DE LISTAS...................................................................................................... 101
6.7. APLICACIONES DEL ELEMENTO MÓVIL .......................................................................... 101
6.7.1. APLICACIÓN PRINCIPAL ................................................................................................ 102
6.7.2. HTML_GET ................................................................................................................ 103
6.7.3. ESCRITORIO SONORO .................................................................................................. 103
6.7.4. ANALIZADOR XML (PARSER) ......................................................................................... 103
6.7.5. REPRODUCTOR DE AUDIO ............................................................................................. 104
6.8. COMUNICACIÓN CON EL OPENMOKO ........................................................................... 105
6.9. HERRAMIENTAS DE COMPATIBILIDAD (TOOLCHAINS) ................................................... 105
vi
6.10. SÍNTESIS DE VOZ HUMANA ............................................................................................ 106
6.10.1. ESPEAK ..................................................................................................................... 107
6.10.2. FESTIVAL ................................................................................................................... 107
6.10.3. FLITE ........................................................................................................................ 108
6.11. PROGRAMACIÓN PARALELA........................................................................................... 108
6.11.1 TÉCNICAS MULTITHREAD .............................................................................................. 109
7. PRUEBAS Y APORTACIONES ................................................................................................ 115
7.1. NTRODUCCIÓN ............................................................................................................... 114
7.2. PRUEBAS CON LOS DISPOSITIVOS BLUETOOTH ............................................................. 114
7.2.1. Modos de detección de dispositivos .................................................................... 114
7.2.2. TIEMPOS DE BÚSQUEDA DEL CICLO INQUIRY ..................................................................... 116
7.3. PRUEBAS DE FUNCIONAMIENTO DEL SISTEMA ............................................................. 116
7.4. APORTACIONES .............................................................................................................. 119
8. CONCLUSIONES ................................................................................................................... 122
8.1. INTRODUCCIÓN .............................................................................................................. 120
8.2. CONCLUSIONES .............................................................................................................. 120
8.3. FUTUROS TRABAJOS ....................................................................................................... 123
A1. PUBLICACIONES Y APORTES ................................................................................................. 122
REFERENCIAS ............................................................................................................................. 156
1
1.
1.1. Antecedentes y justificación
La visión es uno de los sentidos más importantes que poseemos, ya que gran parte de
los mecanismos de enseñanza se basan en este sentido. Entre el 80 y el 90% de la
información necesaria para nuestra vida cotidiana implica el órgano de la visión [1].
Esto implica que la visión juega un papel predominante en la adquisición de nuestras
habilidades, conocimientos y en las actividades que desarrollamos a lo largo de
nuestra vida, adquiriendo un rol central en la autonomía y desenvolvimiento de las
personas desde muy temprana edad.
El término discapacidad visual se refiere a la carencia, disminución o defectos en la
visión, englobando a las personas que padecen tanto de ceguera como de cualquier
deficiencia visual. Indiscutiblemente la discapacidad visual se refleja en todos los
campos de la vida y son muchos los problemas que encuentran las personas con
discapacidad visual para realizar procesos que podríamos considerar sencillos y
rutinarios [2], tales como salir a la calle o realizar las tareas domésticas. Tampoco
podemos olvidarnos de la necesidad de desplazarnos, acción que es una parte integral
de nuestra vida diaria y en la que la visión juega un rol crítico, ya que además de poder
procesar rápidamente la gran cantidad de información que recibe, nos ofrece
información sobre la distancia. Cuando hablamos de desplazamiento, la distancia es
sinónimo de anticipación, de capacidad de analizar previamente la trayectoria del
recorrido, lo que proporciona al individuo la capacidad de ser proactivo a través de la
prevención de obstáculos o identificar el borde de las aceras o las escaleras antes de
llegar a ellas. El discapacitado visual debe obtener esta información de los otros
sentidos, principalmente de la audición y del tacto. La audición ayuda a los
discapacitados visuales a obtener información sobre el ambiente y provee información
acerca de objetos con los cuales no tienen contacto directo. Por ejemplo, una persona
2
que entra en una habitación, puede determinar si ésta es grande o pequeña usando el
sonido reflejado, o también puede darse cuenta que ha llegado al cruce de dos pasillos
por la ausencia del sonido reflejado en la unión entre ambos. Los sonidos también
ayudan a localizar sitios, tales como plazas, escuelas o, más concretamente, sitios
seguros donde atravesar una calle. El tacto, por su parte, ayuda a diferenciar
superficies; la grava de la hierba, la inclinación o declinación de un camino.
Aunque las personas con discapacidad visual pueden tener menos volumen de
información disponible, con respecto a la velocidad y la distancia, en general, la
información auditiva y táctil disponible, es suficiente para un viaje seguro e
independiente. No obstante, según estudios realizados por la Organización Mundial de
la Salud (OMS) en 2009, en el mundo hay 314 millones de personas con discapacidad
visual, de las cuales 45 millones con ciegas [3] y el 75% de ellas han declarado que
necesitan asistencia diaria para desplazarse [4]. Cuando se trata de desplazamientos, la
dependencia puede ser muy crítica [2] y es aquí donde entran a desempeñar un papel
importante la ayuda de bastones, los perros guías o los dispositivos electrónicos. Los
discapacitados visuales, por lo general, pueden recordar el camino a un número
limitado de lugares, pero el miedo a lugares desconocidos reduce drásticamente su
movilidad. La situación se torna más crítica en el caso de ir a destinos desconocidos o
muy concurridos, tanto de personas como de automóviles, y es aquí donde las
limitaciones de los elementos de ayuda tradicionales se tornan evidentes. Por ejemplo,
el bastón sólo puede alertar sobre obstáculos que están a pocos metros de distancia y
por debajo de la cintura.
Los discapacitados visuales deben salvar dos grandes retos para realizar un
desplazamiento seguro e independiente, que son el acceso a la información impresa y
los factores de estrés, relacionados con una navegación segura y eficiente [5]. Estas
limitaciones se tornan más evidentes cuando hablamos de la necesidad de utilizar el
transporte público [6], ya que la información no está disponible desde el inicio del
viaje. Por lo tanto, una persona con discapacidad visual no puede saber, a priori, qué
autobús puede acercarlo a un sitio en concreto, ni puede planificar de antemano su
recorrido [7]. Si a todo esto le sumamos la poca información contextual sobre el viaje
que realiza, se torna más difícil su orientación y su posicionamiento dentro del
recorrido que está realizando. En este ámbito, se han hecho numerosos esfuerzos y se
han diseñado muchas soluciones para cubrir las necesidades de las personas con
discapacidad visual, tanto para metros [8] como para buses urbanos [7], soluciones
que se pueden extrapolar a otros medios de transporte público.
En el presente trabajo se aborda el diseño y la puesta en marcha de un sistema de
información y orientación para discapacitados visuales. El sistema desarrollado amplía
la plataforma electrónica de accesibilidad que se presentó como proyecto de fin de
3
carrera, para la obtención del título de grado en Ingeniería Electrónica en la
Universidad Católica “Nuestra Señora de la Asunción” de la República del Paraguay. En
este trabajo se han incluido nuevos servicios, además de loas meramente informativas
ya descritas en mi proyecto de fin de carrera, como la orientación hacia lugares de
interés y un sistema de aviso, que denominamos localización, que emite sonidos no
verbales para indicar a los usuarios que ha llegado a un destino preestablecido. El
incorpora mensajes para avisar a los usuarios sobre posibles peligros como zanjas,
escaleras, pisos mojados, etc., e incorpora prestaciones para guiar de manera sencilla
al discapacitado.
El sistema que se presenta se ha desarrollado dentro de un proyecto de investigación
financiado por el Gobierno de España. El proyecto, titulado “Fénix: I+D de pulsera de
localización permanente y plataformas TIC para proteger a las mujeres maltratadas” se
trata de un proyecto concedido en 2008 por la Secretaría de Estado de
Telecomunicaciones y para la Sociedad de la Información del Ministerio de Industria,
Turismo y Comercio (referencia TSI-020302-2008-21), con una duración estimada de
18 meses.
1.2. Objetivos del trabajo
1.2.1. Objetivos generales
Proveer a los discapacitados visuales la información que no pueden obtener.
Aumentar la independencia y autonomía de la personas con discapacidad
visual.
Analizar las distintas tecnologías referentes a la ayuda a discapacitados
visuales.
1.2.2. Objetivos específicos
Desarrollar un nuevo hardware necesario para el sistema.
Desarrollar el nuevo software para los elementos del sistema.
Modificar el software de los elementos del sistema.
Incorporar el servicio de localización.
Incorporar el servicio de orientación.
4
2.
2.1. Introducción
El auge de las tecnologías de la información y las comunicaciones (TIC) ha propiciado
un cambio sustancial a la hora de producir, gestionar y acceder a la información para
discapacitados visuales. Desde el bastón blanco y los perros guías hasta el uso de
wearable computers, numerosas y variadas pesquisas se han hecho para desarrollar
nuevas y mejores herramientas de ayuda para los discapacitados visuales. Por otra
parte, el progreso de las tecnologías inalámbricas ha desempeñado un papel
importante, brindando nuevas formas de transmisión de datos a tasas y precios
razonables. Por todo esto, en este capítulo se presenta una revisión de los dispositivos
actuales de ayuda para discapacitados, así como de las comunicaciones inalámbricas,
para conocer el estado del arte en este tipo de sistemas.
2.2. Tecnología para discapacitados visuales
A lo largo del tiempo se han realizado numerosos esfuerzos para facilitar el acceso a la
información a los discapacitados visuales. Dídimo de Alejandría (311 - 358), apodado el
ciego por razones obvias, desarrolló un procedimiento de lectura y escritura basado en
un conjunto de piezas de marfil con letras en relieve que fue ampliamente utilizado
por los invidentes para formar palabras y frases. El primer gran hito en la lecto-
escritura para discapacitados visuales llega con Louis Braille, conocido por el sistema
que lleva su nombre y que consiste en el desarrollo de un sistema que representa un
carácter empleando una serie de puntos en relieve. Si bien él no inventó el sistema, ya
que se basa en un sistema ideado con fines militares por Charles Barbier de la Serre y
5
publicado en 1822. Louis Braille a los 16 años (1825) reduce el complejo sistema de
Barbier de 12 a 6 puntos, ordenándolos en dos columnas y tres filas, lo que permitió
representar todas las letras del alfabeto, signos de ortografía, numeración y caracteres
aritméticos. En 1878 se reconoce oficialmente el braille como método universal por su
probada utilidad didáctica [9].
Desde el punto de vista de la informática, también se han realizado nuevos y variados
dispositivos con el fin de adaptar los ordenadores a las necesidades de los usuarios con
discapacidad visual, para hacer más accesible la información y mitigar las barreras que
silenciosamente se han ido levantando para el colectivo de discapacitados visuales
conforme ha ido evolucionando la tecnología. Son muchos los dispositivos que se han
ido adaptando a los discapacitados visuales para interactuar con el ordenador, tanto
software como hardware. A continuación mostraremos algunos [10].
Anotador braille o portátil. Los datos son introducidos al ordenador mediante
el sistema braille de 8 puntos (adaptado al sistema ASCII), que abarca mayor
número de caracteres que el braille estándar. El propio ordenador se encarga
de traducir esta información a código ASCII. La información almacenada en el
dispositivo puede ser leída posteriormente mediante dispositivos de salida
como la línea braille, impresora braille, sintetizadores de voz o un programa de
amplificación de pantalla. Ejemplos: Braille’n speak y PAC Mate BX400.
Display braille. Proporcionan una salida táctil de la información representada
en la pantalla del ordenador. Estos aparatos transmiten la información
reflejada en la pantalla al usuario, usando caracteres braille situados en una
línea de veinte hasta ochenta ocurrencias según el modelo y cuentan con un
teclado propio para interaccionar con el operador, mediante el cual se pueden
realizar tanto lectura, como la identificación de contenidos de la visualización.
Impresoras braille. Generan documentos en formato braille para su lectura
mediante el tacto. La impresión se realiza directamente sin tener que cambiar
el formato del documento escrito, debido a que existen programas que
traducen los textos del formato estándar ASCII a braille. Ejemplos: Braille
Everest, Braille Blazer, PortaThiel y VersaPoint Duo.
Lectores de pantalla. Se utilizan para verbalizar o hablar, leen todo lo que se
encuentre en la pantalla, incluyendo nombres y las descripciones de los
botones, menús, textos, signos de puntuación, etc. Ejemplos: Hal para
Windows en español, Windows-Eyes, Open Book y JAWS para Windows.
Libros hablados digitales. Otro método de lectura para las personas invidentes
son los libros grabados en lenguaje SMIL o DAISY, que combinan texto
propiamente dicho (accesible mediante ampliación de imagen, voz sintética e
incluso Braille) sonido, videos, gráficos e incluso el texto grabado con voz
humana. Ejemplo: PLexTalk.
6
Línea braille. El sistema traduce en códigos táctiles los contenidos de los textos
y proporciona a la persona invidente un renglón escrito en braille por medio del
cual es posible la lectura táctil, puesto que es reproducida en relieve braille, de
lo que un ordenador emite y que va apareciendo en la pantalla. Ejemplos: Línea
ECO-BRAILLE 80, Focus 40-80 Braille Display y PowerBraille Display.
Magnificadores de pantalla. Ayudan a las personas con graves deficiencias en la
visión, puesto que actúan como una lente de aumento. Pueden agrandar una
parte de la pantalla ampliando la legibilidad. Algunos permiten realizar
aumentos y decrementos de zoom. Ejemplos: BigShot, Lupe, ZoomText y
Magic.
Navegadores de Internet. Existen navegadores de Internet especializados que,
normalmente, combinan voz y ampliación de imagen, y que facilitan la lectura
de los textos, la búsqueda rápida de enlaces y otros elementos en una misma
página, el uso del correo electrónico y la lectura de las descripciones de los
gráficos, en caso de que hayan sido introducidas por el diseñador de la página.
Ejemplos: WebSpeak, Opera, IBM Home Page Reader y Lynx.
Procesadores de texto. Aquí se pueden encontrar procesadores de texto
parlantes, que emplean sintetizadores de voz para repasar el texto escrito, o
bien procesadores de texto con grandes tamaños de fuente
(independientemente de los ampliadores de pantalla).
Sintetizadores de voz. Reciben la información dirigida a la pantalla en forma de
secuencia de caracteres y la reproducen imitando una voz. Este proceso se
llama linearización de la información. Ejemplos: PcVoz, SodelsCot, ELOQUENCE,
ORPHEUS, CIBER232P y Apollo2.
Sistemas de reconocimiento de voz (software). Permiten al usuario dar órdenes
e introducir datos utilizando la voz en lugar del teclado y el ratón. Ejemplos:
Naturally y Speaking.
También desde el punto de vista electrónico se han estudiado nuevas formas y
sistemas de ayuda para este colectivo de personas. Desde la adopción del bastón
blanco en 1940 [11], infinidad de dispositivos electrónicos han sido creados para
complementar o reemplazar el bastón blanco con dispositivos electrónicos para ayudar
a evitar obstáculos. Los primeros dispositivos electrónicos desarrollados para
discapacitados visuales se desarrollaron después de la Segunda Guerra Mundial y más
que nada eran detectores de obstáculos. Utilizaban ondas para detectar obstáculos y
alertar al usuario sobre obstáculos cercanos (radar y ultrasonidos) [12] [13].
Posteriormente, se ha seguido esta línea empleando otros métodos de detección, tales
como el láser [14].
Más recientemente se ha investigado más profundamente en las necesidades de
movilidad de los discapacitados visuales, ya que la simple detección de obstáculos no
7
es suficiente para su correcto desplazamiento. Aparece un nuevo paradigma en el
abanico de equipos tiflotecnológicos que es el de la navegación, que engloba la
orientación y localización [15] [16]. Una propuesta reciente en esta línea fue la de
incorporar identificadores de ubicación a lo largo de lugares de concurrencia de
discapacitados visuales. Los sistemas Talking Sings y Verbal Landmark son ejemplos de
este paradigma.
Con el advenimiento del GPS, numerosos diseños tiflotecnológicos se han desarrollado
[17] [18] [19] a partir de la alta precisión posicional, cobertura extensa de la señal y su
disponibilidad inmediata y gratuita que ofrece la tecnología GPS. El Sistema de
Posicionamiento Global (GPS) y su equivalente ruso (GLONASS) son ampliamente
utilizados para aplicaciones de posicionamiento, incluyendo la navegación.
Luego aparecen los dispositivos que implementan visión artificial, realidad aumentada
y modelos virtuales en 3D, algunos ejemplo se pueden ver en [20] [21]. Uno de los
problemas aún presente este tipo de sistemas es que funcionan bajo determinadas
condiciones ambientales, sobre todo de luminosidad.
En la Tabla 2.1 se resumen las principales características de algunos dispositivos
diseñados para la orientación y navegación para discapacitados visuales.
8
Dispositivo Transductor de
entrada Tipo de salida
generada Información transmitida
Ubicación / Tipo de dispositivo
Requerimiento de infraestructura
especial
Ambiente de operación
Desarrollador
BAT ‘K’ Sonar Cane Sonar Acústico Presencia de obstáculos
Montado en el bastón
No Interiores y exteriores
Bay Advanced Technologies
Kaspa Sonar Acústico Imágenes acústicas de objetos (hasta 5
m)
Montado en la cabeza del usuario
No Mayormente
exteriores Bay Advanced Technologies
Sonic Path-finder Sonar Acústico 8 tonos diferentes de acuerdo con la distancia al objeto
Montado en la cabeza del usuario
No Mayormente
exteriores Perceptual
Alternatives
Mini-guide Sonar Acústico y táctico Distancia a objetos
(0,5 a 8 m) Dispositivo de mano No
Mayormente exteriores
GDP Research [Miniguide]
UltraCane Sonar Acústico y táctico Distancia a objetos
(1 a 4 m) Montado en el
bastón No
Interiores y exteriores
Sound Foresight
Nurion Laser Cane Láser Acústico y táctico Distancia de los
objetos (hasta 4 m) Montado en el
bastón No
Interiores y exteriores
Nurion-Raycal
vOICE Cámara Acústico y táctico Imagen sonora de múltiples objetos
Dispositivo de mano o montado en la
cabeza del usuario No
Interiores y exteriores
Peter Meijer [peter]
BrailleNote GPS Acústico y Braille
Dirección y distancia a los puntos de
interés, planificación de rutas y modo de navegación virtual
PDA con GPS Presencia de señal
GPS Exteriores SenderoGroup
Personal Guidande System (PGS)
GPS Acústico Dirección y distancia a objetos, rutas de
navegación
Receptor GPS, brújula y notebook
Presencia de señal GPS
Exteriores UCSB Personal
Guidance System
Talking Signs Infrarrojos Acústico Dirección y
localización de marcas
Dispositivo de mano Transmisores Talking-Sign
Interiores y exteriores
Talking Signs
Digital Sign System (DSS)
Infrarrojos Acústico Localización y
puntos de interés cercanos
Dispositivo de mano Marcas Interiores Tjan et al.
NOPPA GPS, GPRS Bluetooth
Acústico (voz) Horarios de transportes,
direcciones, noticias
Dispositivo de mano, receptor GPS
Balizas Bluetooth, señal GPS, servicio de telefonía (GPRS)
Interiores y exteriores
Ministerio de transporte y
comunicaciones (Finlandia)
Drishti GPS, ultrasonido,
Wi-Fi Acústico (voz)
Localización, guiado e información
contextual
Ordenador, receptor GPS, head set
Emisor ultrasonidos, red Wi-Fi, señal GPS
Interiores y exteriores
Universidad de Florida
9
Tabla 2.1. Principales características de algunos dispositivos diseñados para la orientación y navegación para discapacitados visuales.
Dispositivo Transductor de
entrada Tipo de salida
generada Información transmitida
Modo de operación Requerimiento de
infraestructura especial
Ambiente de operación
Desarrollador
Sypole Cámara Acústico (voz)
Descripción de objetos, de colores,
de billetes. Calendario,
calculadora y otros
Procesamiento de imágenes en un
móvil o PDA Ninguna
Interiores y exteriores
Facultad Politécnica de Mons (Bélgica)
Perseus Cámaras y GPS Acústico (voz) Información sobre
obstáculos Indicaciones de un operador remoto
Wi-Fi, operador remoto
Mayormente interiores
Universidad Técnica de República Checa
en Praga
Radio Virgilio Sesamonet
RFID Acústico (voz) Orientación
absoluta y relativa
Información almacenada en la SD
del teléfono
Lector de Tags RFID, Base de datos
Interiores y exteriores
Universidad Sapienza e ISPRA
(Italia)
TUGS Cámaras y GPS Vibraciones Dirección de movimiento
Prenda de vestir con 5 vibradores que
indican las direcciones
Operador remoto Interiores y exteriores
Universidad de Brunel
MoBIC GPS, brújula Acústico (voz) Navegación, rutas
planeadas
Asistente de navegación le va
indicando la ruta a seguir
Señal GPS Interiores y exteriores
Consorcio MoBIC
RAMPE Comandos de voz
(sintetizador) Acústico (voz)
Horario del transporte público
Mediante la red Wi-Fi se alerta al
usuario de las paradas
Wi-Fi Exteriores
EISEE, Universidad de París V René
Descartes y LUMIPLAN
Transantiago Interfaz de usuario Acústico (voz) Información de
contexto dentro del viaje por bus
El usuario avanza manualmente por
las estaciones y recibe información
de contexto
Ninguna Exteriores Universidad de Chile
10
2.3. Tecnología inalámbrica para la transmisión de datos
En la actualidad, el número de tecnologías inalámbricas utilizadas en los sistemas de
localización para discapacitados visuales es muy elevado. Los sistemas pensados para
exteriores se diferencian de los interiores. En los primeros, el sistema de
posicionamiento global, conocido por sus siglas en inglés GPS (Global Positioning
System), se ha establecido como el estándar de referencia debido a la precisión que es
capaz de conseguir cuando el receptor tiene visión directa con varios satélites de
forma simultánea.
No obstante, para localización y posicionamiento en interiores, la señal GPS carece de
utilidad; puesto que el techo de los edificios así como las paredes consiguen apantallar
la señal y, por tanto, el receptor no es capaz de sincronizarse con la red de satélites y
brindar una lectura fiable de la posición.
A la hora de transmitir datos, se ha recurrido a muchas tecnologías inalámbricas como
puede ser ZigBee, Bluetooth o Wi-Fi. Cada una de ellas presenta una serie de ventajas
e inconvenientes que las hacen tener mayor o menor validez. En consecuencia, la
elección tecnológica deberá depender de los requisitos de la aplicación en concreto, es
decir, se debe hallar una relación de compromiso entre el precio, el consumo de
energía y el ancho de banda que es capaz de brindar.
A continuación veremos brevemente las diferentes tecnologías implicadas en varios
proyectos a fin de estimar y justificar el uso de una de ellas.
2.3.1. Bluetooth
Se corresponde con un estándar de comunicaciones inalámbricas basado en
radiofrecuencia, de bajo coste y bajo consumo energético [22]. Originariamente, en
1994, Ericsson lo desarrolló como un mecanismo alternativo que permitiese sustituir
paulatinamente los enlaces cableados de diversos periféricos. No obstante, las
características y versatilidad que presenta Bluetooth han hecho que se pueda utilizar
en una gran cantidad de situaciones diferentes, como pueden ser el establecimiento
de conexiones entre dos terminales móviles inteligentes como puedan ser una PDA o
un teléfono móvil, conexionado de periféricos o dispositivos de audio.
Como se ha mencionado anteriormente, Bluetooth nace de la mano de Ericsson en
1994 junto con otras grandes compañías del sector tecnológico como son Intel, IBM,
Nokia y Toshiba. Este conjunto de multinacionales constituyeron en 1998 el Bluetooth
Special Interest Group, organismo que se encarga de gestionar y desarrollar las
distintas versiones del núcleo de Bluetooth. Más tarde, en 1999, se unirían empresas
de la talla de Microsoft, 3Com o Agilent. El trabajo conjunto de los diferentes
11
miembros del Bluetooth SIG permitió una rápida aceptación por parte de los
fabricantes; así como la compatibilidad entre dispositivos de los diferentes fabricantes.
Este hecho, provocó que las redes Wireless Personal Area Network (WPAN) basadas en
Bluetooth estuviesen reguladas por el IEEE bajo la denominación 802.15.
Las principales características de esta forma de comunicación son:
Opera en la banda libre de los 2,4 GHz por lo que no necesitamos adquirir
ninguna licencia de emisión.
Tiene una capacidad máxima de transmisión de hasta 3 Mbps.
Implementa diversos mecanismos de ahorro energético de forma que el
dispositivo no siempre va a consumir la misma potencia con el consiguiente
ahorro energético en la batería del dispositivo.
Posee un precio económico que permite implementarlo en casi cualquier
dispositivo sin encarecerlo desmesuradamente. Un sistema Bluetooth
empotrado tiene un precio cercano a 20€ la unidad.
Alcance de hasta 100 metros en función de la potencia de emisión que posea el
transmisor Bluetooth.
No obstante, se corresponde con protocolo de comunicaciones cuyo uso queda
restringido para enlaces punto a punto, puesto que el sistema de
establecimiento de conexiones hace difícil poder realizar redes punto-
multipunto. Esto se debe a que en un principio estaba destinado para sustituir
a los enlaces establecidos mediante un cable físico.
2.3.2. ZigBee
ZigBee se corresponde con una especificación global creada por un consorcio de
múltiples marcas destinas a la venta de sistemas de control inalámbrico denominados
ZigBee Alliance [23]. Dicha especificación se basa en el estándar 802.15.4 definido por
el IEEE donde se especifica la capa física y de enlace del protocolo. En cuanto a los
niveles superiores, la ZigBee Alliance se encarga de establecer el conjunto de reglas
que deben cumplir las capas de red, aplicación, el framework de aplicación, los perfiles
y los mecanismos de seguridad.
La idea principal sobre la que se ha desarrollado ZigBee ha sido la facilidad a la hora de
implementarlo en un sistema de control, o lo que es lo mismo, se busca que de una
manera sencilla y rápida se pueda desarrollar un sistema robusto y duradero
12
fácilmente integrable en una red inalámbrica destinada a la supervisión y el control.
Por este motivo, ZigBee pretende cumplir los siguientes requisitos:
Alta fiabilidad.
Bajo coste.
Muy bajo consumo.
Altamente seguro.
Estándar abierto.
En consecuencia, para poder satisfacer todos estos puntos, ZigBee se va a caracterizar
por las siguientes características:
Baja capacidad de transmisión, en torno a 250 Kbps, que nos permitirá
desarrollar sistemas de muy bajo coste.
Protocolo sencillo, pudiendo ser implementado sin ningún tipo de limitación en
sistemas microcontroladores de 8 bits.
Muy bajo consumo energético permitiendo que la fuente de alimentación del
sistema pueda durar años.
Como gran desventaja, podemos mencionar la baja capacidad de transmisión
adoptada lo que restringe el uso de esta especificación para usos muy concretos y
actividades que requieran poco intercambio de datos, como accionar un interruptor de
la luz o monitorizar un sensor de temperatura o luminosidad.
2.3.3. RFID
La tecnología RFID (Radio Frequency Identification) corresponde con un método de
almacenamiento y recuperación remota de información, basado en el empleo de
etiquetas (en adelante se referenciarán como tags o transpondedores) en las que se
almacenan los datos [24]. De forma que cuando dichos transpondedores entran en el
área de cobertura de un lector RFID, éste envía una señal para que la etiqueta le
transmita la información almacenada en su memoria. Por tanto, una de las principales
características de esta tecnología es la posibilidad de recibir información de las
etiquetas dispersas por el entorno a través de radiofrecuencia y sin necesidad de que
exista contacto físico entre el dispositivo lector y el transpondedor. No obstante, la
distancia no podrá superar un cierto valor máximo impuesto por la potencia de
transmisión máxima y la potencia de recepción mínima detectable.
13
El rango típico de las señales de radiofrecuencia empleadas en RFID son típicamente
125 KHz., 13,56 MHz., 433-860-960 MHz. y 2,45 GHz.
Por su parte, los sistemas de identificación por radiofrecuencia están compuestos por
cuatro elementos principalmente:
Una etiqueta RFID: se denomina también tag o transpondedor, puesto que
combina en un mismo dispositivo el transmisor y el receptor. La etiqueta se
utilizaría para ser distribuida por el entorno donde el objetivo a localizar se
vaya a desplazar. Se compone de tres elementos: chip, antena y sustrato. El
chip y la antena están contenidos en el substrato que puede ser un material
rígido (por ejemplo el sustrato de fibra de vidrio FR4 de los circuitos impresos)
o flexible (película de poliamida Dupont’s Kapton). En cuanto a la realización de
la antena, se realiza de un material metálico como el cobre; mientras que el
integrado se realiza sobre silicio que se une eléctricamente a la antena. Se
distinguen dos tipos de tags:
o Pasivos: no poseen ninguna fuente de alimentación, ésta la reciben
directamente del lector. Por este motivo, tan sólo podrán transmitir
información cuando son activados por el lector.
o Activos: contienen una fuente de alimentación que les suministra la
energía necesaria como para poder transmitir la señal de información.
Un lector: es el encargado de transmitir la energía suficiente a la etiqueta para
que ésta le pueda enviar la información que contiene almacenada. Consta de
un módulo de radiofrecuencia (transmisor y receptor), una unidad de control y
una antena para interrogar los tags vía radiofrecuencia. Para el intercambio de
información, los lectores suelen incorporar algún tipo de protocolo específico,
como puede ser NFC, que permita enviar los datos recibidos de la etiqueta a un
sistema de procesamiento de datos.
Un dispositivo controlador: se corresponderá con un dispositivo móvil o un
ordenador que ejecute la aplicación encargada de procesar los datos
procedentes de uno o varios lectores RFID se las transmita al sistema de
información. También puede ser capaz de transmitir órdenes al lector
Middleware: se tratará del software desarrollado para poder recoger, filtrar y
manejar la información procedente de los diferentes controladores.
14
Figura 2.1. Funcionamiento de un sistema RFID con etiqueta pasiva.
2.3.4. Ultra Wide Band
Se corresponde con una tecnología de comunicación inalámbrica conocida hace más
de 45 años en el mundo de la investigación y militar [25]. La principal característica de
las redes Ultra Wide Band (UWB) es que permite obtener enlaces con una gran
capacidad de transmisión, consumiendo muy poca potencia. Esto se consigue
transmitiendo señales en el dominio del tiempo de muy corta duración. El periodo de
estas señales será del orden de unos pocos nanosegundos. Esto permite tener grandes
anchos de bandas en las señales transmitidas lo que conlleva considerables beneficios
en cuanto al consumo y a la capacidad de transmisión.
Por su parte, el despegue de esta tecnología se produjo en 2002 cuando el organismo
estadounidense Federal Communications Commission (FCC) permitió el uso de la
banda ubicada entre 3.6GHz y 10.1 GHz. Este acontecimiento provocó que numerosos
centros de investigación, gobiernos, la industria de las telecomunicaciones,…
investigasen posibles aplicaciones. Entre ellas, cabe citar:
Acceso a Internet de banda ancha a muy alta velocidad.
Localización con precisión de centímetros.
Imágenes de radar de alta resolución.
Obtención de imágenes a través de paredes.
Navegación y seguimiento de objetos de forma precisa.
Finalmente, el principal inconveniente de esta tecnología es que sólo se puede utilizar
en un corto rango de espacio, cercano a los 10 metros de cobertura. Esto está
motivado por los niveles tan bajo de potencia que la FCC estableció para UWB. En
15
concreto, la máxima potencia de salida de un transmisor UWB es de 0.0001 mW/MHz
lo que supone que para un ancho de banda típico de 500 Mhz se tenga una potencia
de salida de 0.05 mW, valor que se encuentra muy por debajo de la máxima potencia
permitida, por ejemplo, en el estándar 802.11b que es 100 mW. Esto supone 2000
veces menos potencia.
2.3.5. Wi-Fi
Se trata de un estándar internacional que implementa los niveles inferiores del modelo
OSI, en concreto, el nivel físico y el de enlace, sobre un canal inalámbrico. En su
concepción se pensó para sustituir a Ethernet (estándar 802.3) en aquellas zonas o
puntos donde difícilmente podríamos llegar con un cable. De ahí que los métodos de
acceso al medio físico sean similares a los usados en Ethernet. Por otro lado, se trata
de un estándar que desde que apareciera en 1997 ha sufrido una constante evolución,
encontrando varias versiones del mismo [26]:
2.3.5.1. 802.11a
Esta versión del estándar se corresponde con la tercera generación de redes
inalámbricas debido a que apareció en el mercado después de las redes 802.11 y
802.11b. Aunque en un principio, su desarrollo se había iniciado antes que el estándar
802.11b. A pesar de ello, se retrasó debido a los requisitos tecnológicos necesarios
para poder llevarlo a cabo.
En concreto, las redes inalámbricas 802.11a se caracterizan por operar a una
frecuencia de 5 Ghz. en los EEUU, en la banda de frecuencia conocida como UNII
(Universal Networking Information Infraestructure). Sin embargo, esta forma de
comunicación inalámbrica no está autorizada para su utilización en Europa porque la
banda que usa para operar se encuentra ocupada por el estándar HyperLAN2.
Las principales características que aporta son:
Una capacidad de enlace de 54 Mbps.
Al trabajar en la banda UNII, posee mayor inmunidad frente a las interferencias
por solapamiento puesto que dicha banda contempla el uso de 4 canales para
este fin.
Uso de un rango de frecuencias relativamente libre como son los 5 Ghz.
16
2.3.5.2. 802.11b
Este estándar apareció en 1999 con la idea de permitir a los usuarios comunicarse con
sus dispositivos con redes Ethernet a través de transmisores/receptores de
radiofrecuencia. Por este motivo, la institución IEEE se vio obligada a cambiar los
mecanismos de acceso a las redes Ethernet para añadir el soporte de las nuevas capas
físicas y de enlace introducidas por 802.11b. En concreto, se optó por usar CSMA/CA
(Carrier-Sense Multiple Access with Collision Avoidance) en la capa de enlace y para la
capa física se eligieron tres técnicas:
DSSS (Direct Sequence Spread Spectrum) usando la banda de los 2,4 GHz.
FHSS (Frecuency Hopping Spread Spectrum) operando en el rango de los
2,4GHz.
Infrarrojos.
La principal ventaja de este estándar es que ha sido ampliamente usado en todo el
mundo para establecer redes inalámbricas por ser el primero que salió de forma
comercial. No obstante, presenta una serie de inconvenientes que en revisiones
posteriores se han intentado corregir. Entre estas se pueden citar:
Problemas de interferencias debido a que el rango de frecuencias en el que
opera se encuentra saturado al tratarse de una banda libre.
Capacidad de transmisión reducida, admite hasta 11 Mbps.
Requiere de modulaciones que contrarresten los efectos de multitrayectos.
Sensible a la distancia de tal forma que a una distancia a más de 75 metros, la
capacidad del enlace cae a 2 Mbps.
2.3.5.3. 802.11g
Este estándar surgió como una extensión del 802.11b con el que se pretendía mejorar
la capacidad de transmisión del enlace usando el mismo rango de frecuencias, es decir,
la banda de 2,4 Ghz. Para ello, lo que se hizo fue introducir un segundo modo de
acceso basado en OFDM usado ya en las redes 802.11a que permitió aumentar la
capacidad del enlace hasta los 54 Mbps. De esta forma, al disponer de las dos técnicas
de modulación, las usadas en 802.11b y la usada en 802.11a, este estándar podía dar
servicio a dispositivos que cumpliesen la normativa 802.11b y a la vez a los nuevos
dispositivos compatibles con el estándar 802.11g.
17
Por tanto, la principal ventaja de las redes 802.11g es el aumento considerable de la
capacidad de transmisión, hasta 54 MBPS. No obstante, al compartir la misma banda
que 802.11b presenta las mismas desventajas.
2.3.5.4. 802.11n
Se corresponde con una norma todavía en fase de propuesta, es decir, sigue siendo
evaluado por los grupos de trabajo del IEEE. En Junio de 2.009 estaba prevista su
publicación como estándar, pasando a constituir de esta forma la última revisión del
estándar 802.11. Se caracteriza principalmente por conseguir un aumento de la
capacidad de transmisión muy superior a la proporcionada por 802.11a/b/g. Se
podrían alcanzar hasta 600 Mbps. Para poderlo conseguir ha sido necesario emplear
dos conceptos claves en la definición de la capa física: el uso de sistemas MIMO
(Multiple In Multiple Out) y un ancho de banda de 40 Mhz. para los diversos canales
existentes. La unión de estas dos decisiones de diseño ha originado ese aumento de la
capacidad de transmisión.
Por su parte, durante la formulación de este estándar se ha mantenido siempre el
carácter compatible del mismo con las revisiones anteriores de 802.11 por lo que
permite el uso de modulaciones OFDM para poder usar dispositivos compatibles con
802.11a/b y las técnicas de acceso vistas en 802.11b. De esta forma, pueden usarse los
más de 250 millones de dispositivos existentes en el mercado actual de las
comunicaciones inalámbricas en este tipo de redes. Esta característica supone una
gran ventaja comercial puesto que el usar un nuevo estándar de comunicaciones
inalámbricas no supone tener que cambiar los dispositivos que el usuario pueda ya
haber adquirido.
En consecuencia, entre las principales ventajas de 802.11n podemos citar:
Mayor capacidad de transmisión, hasta 600 Mbps.
Retrocompatibilidad con los dispositivos 802.11a/b/g.
Uso de modos para ahorrar consumo y mejorar la utilización de los canales.
Aprovechamiento de los rayos multitrayectos para mejorar la capacidad de
transmisión.
En la Tabla 2.2 se puede ver una comparativa entre las diferentes versiones de la
especificación Wi-Fi.
18
802.11b 802.11g 802.11a 802.11n
Tasa máxima de
datos (Mbps) 11 54 54 300
Tasa real de datos
(Mbps) 5 20 22 146
Nº de canales
disponibles 3 3 12
3 en 2,4 GHz.
12 en 5 GHz.
Probabilidad de
interferencia Alta Alta Baja Baja
Comportamiento
en entornos
difíciles
Pobre Medio Bueno Muy bueno
Compatibilidad 802.11b 802.11b/n 802.11a 802.11a/b/g/n
Frecuencias (GHz.) 2,4 2,4 5 2,4 y 5
Seguridad WEP/WPA/WPA2 WEP/WPA/WPA2 WEP/WPA/WPA2 WEP/WPA/WPA2
Tabla 2.2. Comparativa entre las diferentes versiones de la especificación Wi-Fi.
2.3.6. WiMAX
Se trata de una estándar de comunicaciones cuyo principal objetivo consiste en dar
servicios de banda ancha de una forma inalámbrica a áreas metropolitanas, es decir,
está pensado para ser usados en redes MAN. Por este motivo, se desarrolló para cubrir
distancias de hasta 50 Kms. y permitir una capacidad de transmisión de hasta 100
Mbps. Con estas características, esta tecnología podría hacer frente a otras como DSL y
las líneas T1 tendidas en el bucle de abonado.
WiMAX se corresponde con el nombre con el que se comercializa el estándar 802.16
del IEEE [27], organismo encargado del desarrollo y mantenimiento del mismo desde
que fuese transferido por el NIST (National Institute of Standards and Technologies) en
1998 a este organismo.
La idea fundamental de WiMAX se centra en poder dar una gran variedad de servicios,
motivado por el bajo coste de los enlaces, que pueden ir desde actuar como backbone
para redes 802.11, dar servicios de conexión a dispositivos móviles sin hacer uso del
estándar 802.11, como red de respaldo de las redes cableadas,…
Entre las principales características de WiMAX, podemos mencionar:
Dos rangos de frecuencias para operar:
o 10GHz-66GHz: se corresponde con la banda asignada en la primera
versión del estándar. El principal problema de este rango es que
requiere visión directa entre las distintas estaciones para poder llevar a
19
cabo la comunicación, provocando el encarecimiento de la instalación al
tener que aumentar el número de estaciones que coloquemos.
o 2GHz-11GHz: en esta banda se establecen dos rangos, uno en los 3,5
GHz que requiere de licencia para poder transmitir y otro en los 5,8 GHz
que se halla en la banda libre y, por tanto, no necesitaríamos ningún
tipo de licencia.
Uso de selección dinámica de la frecuencia de utilización. Esta técnica permite
seleccionar la frecuencia de transmisión en base a las interferencias generadas
por otros sistemas en la banda usada y por la interferencia co-canal y ajustar la
potencia de transmisión en base a estos parámetros. De esta forma, consigue
mejorar el rendimiento de la comunicación.
Útil en redes punto-multipunto.
Asignación de una determinada calidad de servicio a cada conexión, lo que
permite poder transportar sobre la capa de enlace de WiMAX protocolos como
ATM, Ipv4 o Ipv6.
Finalmente, cabe mencionar que en 2005, el IEEE aprobó el estándar 802.16e en el que
se definen redes de banda ancha móviles usando WiMAX como capa física y de enlace.
Se prevé que mediante estas redes se pueda dar servicio a vehículos que circulen hasta
120 km/h.
2.4. Comparativa
A modo de resumen, se presenta una breve comparativa entre las diversas tecnologías
estudiadas previamente, destacando lo mejor de cada una de ellas a una nivel
tecnológico y cualitativo [28].
Bluetooth ZigBee RFID UWB 802.11b 802.11a 802.11g 802.11n WiMAX
Tasa de transferencia [Mbps]
1-3 0.25-0.02 0.2·10-3-
0.1 200 11 54 54 200 70
Alcance máximo [m]
22.86 10-100 0.1-200 9.144 60.96 45.72 60.96 45.72 50·103
Potencia [mW]
100 30 500 400 750 1500 1000 2000 20000
Ancho de banda [MHz]
1 0.6 500 22 20 20 40 5-10
Eficiencia espectral [b/Hz]
1 0.05 0.4 0.5 2.7 2.7 5 3.7
Eficiencia en potencia [mW/Mbps]
100 1000 2 68 27 19 10 2000
Precio [€]
2.20 1.47 0.25-25 5.14 3.67 8.82 6.61 14.70 40
Tabla 2.3. Resumen de la comparativa entre las diferentes tecnologías inalámbricas vistas.
20
A nivel cualitativo, cada una de las tecnologías propuestas aporta las siguientes
características:
Bluetooth
o Está orientada a aplicaciones de voz y datos.
o Opera en el espectro libre de 2,4 GHz.
o Puede operar a una distancia de entre 1 y 100 metros dependiendo de
la clase del dispositivo.
o La tasa máxima de transferencia es de 3 Mbps.
o Puede penetrar objetos sólidos.
o Es omnidireccional y no requiere de visión directa para poder trabajar.
o Permite hasta tres modos de seguridad.
ZigBee
o Posee una capacidad de hasta 250 Kbps usando las frecuencias de 2,4
GHz., 40 Kbps en 915 MHz. y 20 Kbps en 868 MHz., variando su alcance
de los 10 a los 100 metros.
o Pretende ser un estándar en comunicaciones inalámbricas para las
aplicaciones de control remoto en la industria.
o Debido a su objetivo, se explica su bajo consumo, bajo coste, fácil uso y
escasa capacidad de transmisión.
o En la actualidad, existen tres niveles de seguridad aunque en la primera
especificación liberada no se contemplaban mecanismos de seguridad.
RFID
o Existen aproximadamente 140 estándares ISO para RFID que regulan un
amplio rango de aplicaciones.
o En RFID, las etiquetas pasivas se deben poder alimentar a distancias por
el lector. Por este motivo, el receptor debe encontrarse relativamente
cerca, a pocos centímetros.
o Las etiquetas activas, por el contrario, se pueden leer a distancias de
varios metros puesto que éstas se encuentran alimentadas y no
requieren que el receptor les aporte energía para su funcionamiento.
21
o RFID puede operar a bajas frecuencias, por debajo de 100 MHz., y a
altas frecuencias, banda UHF o en la banda libre de los 2,4 GHz. Y 5,8
GHz.
UWB
o Posee un bajo ratio de consumo (1mW/Mbps) unido a una gran
capacidad de transferencia.
o Idealmente, tendrá un bajo consumo de energía, bajos precios, alta
capacidad de transferencia de datos, podrá atravesar los obstáculos y
usarán una amplia franja del espectro radioeléctrico.
o Existen dos organismos de estandarización compitiendo por regular esta
tecnología: UWB Forum, que apuestan por el uso de una interfaz radio
basada en la secuencia directa (DS-UWB), y la WiMedia Alliance, que
promueven un sistema basado en la modulación OFDM.
o Para las redes WSN, el estándar ha propuesto que se use la
recomendación IEEE 812.15.4ª basada en IR-UWB, es decir, hacer uso
de la tecnología UWB en el espectro infrarrojo. Esta técnica permite
alcanzar hasta 850 Kbps en un rango de 10 a 50 metros.
Wi-Fi
o Su coste y consumo de potencia son superiores al resto de las
tecnologías inalámbricas presentadas a excepción de WiMAX.
o Existen multitud de especificaciones que regulan los distintos aspectos
de este estándar.
o 802.11a: utiliza OFDM como modulación y opera en el rango de los 5
GHz. Posee una velocidad máxima de 54 Mbps.
o 802.11b: funciona en el rango de los 2,4 GHz., tiene una tasa máxima de
transferencia de 11 Mbps y usa DSSS. Se corresponde con la primera
versión del estándar Wi-Fi.
o 802.11g: funciona en el rango de los 2,4 GHz., tiene una tasa máxima de
transferencia de 54 Mbps y usa OFDM. Es compatible con la versión
802.11b.
o 802.11e: regula la calidad de servicio.
22
o 802.11h: se corresponde con un complemento de la norma 802.11a en
Europa y proporciona el control de potencia y la gestión del espectro.
o 802.11i: Aumenta la seguridad incluyendo el estándar de cifrado
avanzado (AES). Esta norma no es totalmente compatible con versiones
anteriores.
o 802.11k: se encuentra en desarrollo y permitirá una mayor gestión de
los recursos radios en redes 802.11x.
o 802.11n: Se espera que opere en el rango de los 5 GHz. Y ofrecerá una
velocidad máxima de datos de más de 100 Mbps. Está orientada para
aplicaciones multimedia.
o 802.11p: estándar desarrollado para el sector de la automoción. Será la
base para las comunicaciones de corto alcance en EEUU.
o 802.11r: mejora la capacidad de los usuarios para moverse entre los
puntos de acceso o estaciones base.
o 802.11s: se encuentra en desarrollo y se espera que permita la creación
de redes 802.11x con una topología en forma de malla.
WiMAX
o Se trata de una red inalámbrica de área metropolitana.
o Posee un alcance de 50 Km. con tasas de transferencias de hasta 70
Mbps.
o La primera versión del estándar, 802.16, operaba en el rango de
frecuencias que van desde los 10 GHz. Hasta los 66 GHz. Lo que
implicaba que debía existir visión directa entre el transmisor y el
receptor.
o El último estándar, 802.16a, opera entre los 2 y 11 GHz. y no necesita
línea de visión.
o Contempla el uso de receptores en vehículos móviles siempre cuando
no superen la velocidad de 100 Km/h.
o Ha sido creado para competir con la tecnología xDSL y el acceso por
módem de cable.
o
23
2.5. Elección tecnológica
El análisis realizado en las subsecciones previas de las diferentes tecnologías
inalámbricas utilizadas permite al lector hacerse una idea de la gran variedad de
elecciones que se pueden efectuar para tal objetivo. La elección de la tecnología
inalámbrica se ha efectuado en base a dos criterios:
Bajo consumo.
Capacidad de transmisión de datos.
Amplia difusión del estándar.
El primer criterio de decisión viene impuesto por las características que se le
presuponen a una red de nodos inalámbricos, puesto que el receptor que llevarán los
usuarios deberá tener una gran autonomía ya que están alimentados mediante
baterías cuya capacidad es limitada. Por este motivo, la tecnología inalámbrica
utilizada debe caracterizarse por su bajo consumo.
El segundo criterio obedece a la necesidad de transmitir datos. Se deberá buscar un
compromiso entre eficiencia energética y capacidad de transmisión, debido a que
cuanto menor sea el consumo, menor será la tasa de transferencia.
Con respecto al tercer factor, se ha impuesto como un requisito fundamental el crear
un sistema basado en un estándar ampliamente difundido ya que esto permitiría a
posteriori, el crecimiento y la expansión del sistema.
Con el fin de satisfacer dichos criterios, se ha optado por elegir como soporte de la
comunicación la especificación Bluetooth. Como se ha podido comprobar
previamente, Bluetooth es un estándar ampliamente utilizado en la industria y en el
sector multimedia. Cualquier dispositivo comercial moderno dispone de un
transceptor Bluetooth, lo que permitiría al usuario poder utilizar dicho sistema
mediante el uso de un software dedicado. Por otro lado, Bluetooth es un sistema de
transmisión de datos con una gran capacidad y con un consumo muy reducido en
comparación con tecnologías que ofrecen un rendimiento similar. Otra característica
de Bluetooth, es que se corresponde con una especificación que posee un gran apoyo
de la industria electrónica, está continuamente en desarrollo y los transceptores
poseen un precio muy asequible, aproximadamente 10€.
24
3. Capítulo 3
Bluetooth como
tecnología inalámbrica
3.1. Introducción
La tecnología inalámbrica Bluetooth [29] se ha convertido en una especificación global
como mecanismo para establecer una comunicación rápida, fiable y sin cables entre
multitud de dispositivos como pueden ser ordenadores portátiles, teléfonos móviles,
periféricos o manos libres para vehículos motorizados. El principal motivo de su rápida
extensión se debe a la facilidad para transferir datos y sincronizar dispositivos. No
obstante, en el ámbito industrial esta tecnología ha despertado un creciente interés
como consecuencia de su bajo coste y gran capacidad de transmisión, además de su
rápida implantación en la mayor parte de los dispositivos móviles y ordenadores
portátiles.
En el resto del capítulo se analizarán las principales características del estándar en su
versión 2.1, de forma que se pueda obtener una visión general del mismo y se
detallarán aquellos conceptos claves para el desarrollo de este proyecto.
3.2. Descripción general
Bluetooth surge como una especificación para Redes Inalámbricas de Área Personal
(WPAN) que posibilita la transmisión de voz y datos entre diferentes dispositivos
mediante un enlace por radiofrecuencia segura y globalmente libre (2,4 GHz). Los
principales objetivos que se pretenden conseguir con esta norma son:
Facilitar las comunicaciones entre equipos móviles y fijos.
Eliminar cables y conectores entre éstos.
Ofrecer la posibilidad de crear pequeñas redes inalámbricas y facilitar la
sincronización de datos entre nuestros equipos personales.
25
En 1994, Ericsson inició un estudio para investigar la viabilidad de una nueva interfaz
de bajo costo y consumo para la interconexión vía radio (eliminando así cables) entre
dispositivos como teléfonos móviles y otros accesorios. El estudio partía de un largo
proyecto que investigaba unos multicomunicadores conectados a una red celular,
hasta que se llegó a un enlace de radio de corto alcance, llamado MC link. Conforme
este proyecto avanzaba se fue haciendo claro que éste tipo de enlace podía ser
utilizado ampliamente en un gran número de aplicaciones, ya que tenía como principal
virtud que se basaba en un chip de radio.
De esta forma, se creó el protocolo de comunicaciones inalámbricas Bluetooth cuyas
distintas versiones son:
Bluetooth v.1.1 (IEEE Standard 802.15.1 - 2002).
Bluetooth v.1.2 (IEEE Standard 802.15.1 - 2005).
Bluetooth v.2.0 (Bluetooth 2.0 + EDR publicada por el SIG).
Bluetooth v.2.1 + EDR (Bluetooth Core Specification Version 2.1 publicada por
el SIG el 26 de Julio de 2007).
Bluetooth v.3.0 +HS (Abril de 2009).
La versión 1.2, a diferencia de la 1.1, adopta una solución inalámbrica complementaria
para permitir la coexistencia de sistemas Bluetooth y Wi-Fi en el espectro de los 2.4
GHz, sin interferencia entre ellos. Para ello, usa la técnica de saltos en frecuencias
adaptativos (AFH), que consigue una transmisión más eficiente y un cifrado más
seguro. Para mejorar las experiencias de los usuarios, esta versión ofrece una calidad
de voz con menor ruido ambiental, y permite una rápida configuración de la
comunicación con otros dispositivos Bluetooth dentro del rango del alcance.
La versión 2.0, fue creada para ser una especificación separada. Se caracteriza por
incorporar la técnica Enhanced Data Rate (EDR) que le permite mejorar las velocidades
de transmisión en hasta 3Mbps a la vez que intenta solucionar algunos errores de la
especificación 1.2.
La versión 2.1, simplifica los pasos para crear la conexión entre dispositivos, además el
consumo de potencia es 5 veces menor. No obstante, se han añadido otras mejoras
sustanciales a la especificación como la generación de informes de datos erróneos, la
respuesta extendida al proceso de descubrimiento, eventos de finalización por
extinción del temporizador en la supervisión del enlace o el modo de seguridad 4.
Finalmente, la versión 3.0 añade nuevas mejoras al estándar Bluetooth en relación a la
pila de protocolos usada. Se introducido la capa AMP, lo que ha provocado una mejora
26
de la capa HCI para interactuar con AMP de una forma más óptima así como la
seguridad. Se ha mejorado el protocolo L2CAP con la inclusión de los modos Streaming
y de retransmisión mejorada, se han solucionado problemas en el soporte del canal así
como una mejora de la máquina de estados L2CAP para los canales AMP. Como una
característica novedosa, se encuentra una capa de adaptación del protocolo 802.11.
En relación a los aspectos más tecnológicos, la tecnología inalámbrica Bluetooth utiliza
la banda de radio ISM (Industrial, Science and Medical) de 2,4 GHz. que se encuentra
disponible en todo el mundo y que no requiere de una licencia por parte de las
autoridades reguladoras de las telecomunicaciones propias de cada país. Esto permite
que los dispositivos Bluetooth puedan operar en cualquier región del globo terrestre
sin necesidad de cambiar ningún componente hardware del dispositivo.
El sistema emplea un transmisor de salto en frecuencia para contrarrestar las
interferencias y las pérdidas de intensidad de señal, y cuenta con un gran número de
portadoras disponibles para la transmisión de datos debido al uso de una modulación
espectro ensanchado por salto en frecuencia (FHSS). Para minimizar la complejidad del
transmisor, se utiliza una modulación de frecuencia binaria. La tasa de transferencia de
símbolos es de 1 MSímbolo/s, admitiendo una velocidad de hasta 1 Mbps en el modo
de transferencia básica y una velocidad de transmisión aérea total de 2 a 3 Mbps en el
modo de transferencia mejorada o EDR. Este último modo se corresponde con una
especificación incluida en la especificación 2.1 del estándar Bluetooth.
Por su parte, sobre esta interfaz radio, se definen dos tipos de enlaces: físicos y lógicos.
Los enlaces físicos se corresponde con un enlace de comunicación entre dos
dispositivos que se intercambian paquetes, sea cual sea la dirección de estos. No
obstante, la norma impide que todos los dispositivos puedan establecer enlaces con
todos, sino que sólo podrán establecer un enlace físico dentro de una misma red el
maestro y un esclavo. De forma que dos dispositivos que actúen como esclavos en una
red no podrán formar un enlace físico nunca.
Con respecto a los enlaces lógicos, estos son los que permiten soportar las aplicaciones
de voz y datos. Estos se corresponden con enlaces SCO y con enlaces ACL,
respectivamente. Los enlaces ACL, se tratan de enlaces asíncronos no orientados a
conexión, por lo que proporcionan un enlace no fiable de tal forma que los paquetes
que se envían a través de estos enlaces no se garantizan que se entreguen al otro
extremo del enlace. Por esta razón este tipo de enlaces son convenientes para
servicios basados en conmutación de paquetes. En relación a los enlaces SCO, su
principal característica es que se corresponden con enlaces síncronos orientados a
conexión, por lo que han sido diseñados para soportar voz en tiempo real y tráfico
multimedia. Por ello, son ideales para servicios que requieran un enlace fiable de
transmisión o estén basados en conmutación de circuitos. Tanto la voz como los datos
27
se transmiten en forma de paquetes y la especificación Bluetooth permite crear
enlaces ACL y SCO al mismo tiempo.
Finalmente, la pila de protocolos que usa Bluetooth se organiza en capas al igual que el
modelo OSI. En la figura 3.1 se pueden comprobar los diferentes protocolos de los que
hace uso la especificación para gestionar y controlar los diferentes enlaces y
conexiones. Cada uno de estos protocolos será revisado en secciones posteriores del
capítulo.
Figura 3.2. Pila de protocolos Bluetooth.
3.3. Arquitectura Bluetooth
La pila de protocolos Bluetooth se basa en el modelo de referencia OSI del organismo
internacional de estandarización ISO para la interconexión de sistemas abiertos. La
especificación Bluetooth utiliza una arquitectura de protocolos que permiten el
intercambio transparente de datos entre aplicaciones diseñadas de acuerdo con dicha
especificación y fomentan la interoperabilidad entre los productos de diferentes
fabricantes.
Se pueden observar dos áreas en dicha pila de protocolos, que pueden ser
implementadas en distintos sistemas o todos en un mismo sistema. Estas áreas son:
El módulo Bluetooth (periférico hardware), encargado de las tareas
relacionadas con el envío de información a través de la interfaz de
radiofrecuencia. Se encargaría de las tareas asignadas a la capa física y parte de
la capa de enlace en el modelo OSI. Esto supone la codificación de los bits, la
modulación utilizada o la potencia con la que se transmite.
28
El host Bluetooth (implementación software), relacionado con los protocolos
asociados a las capas superiores como la capa de red o de aplicación.
El nexo de unión entre estas dos zonas diferenciadas es la denominada Interfaz de
Controlador de Host o, por sus siglas en inglés, HCI. Se encarga de suministrar una
interfaz uniforme de acceso a las capacidades del controlador Bluetooth a través de un
conjunto de comandos que afectan a diferentes bloques de la arquitectura de
Bluetooth como puede ser el gestor de enlaces o la banda base.
En las siguientes subsecciones se procederá a detallar el funcionamiento básico de los
bloques que componen la especificación Bluetooth.
3.3.1. Radio
Como se ha comentado anteriormente, los dispositivos Bluetooth operan sobre la
banda ISM de 2.4 GHz. utilizando un transceptor de salto en frecuencias para combatir
las interferencias y los desvanecimientos en la señal causados por el medio físico. En
concreto, las frecuencias operativas de Bluetooth se hallan mediante la expresión:
.
Esta expresión permite hallar las frecuencias centrales de los canales Bluetooth.
Como se puede comprobar del análisis de la expresión anterior, los canales de
radiofrecuencia están espaciados 1 MHz en el espectro. Además para cumplir con las
regulaciones fuera de banda de cada país, se ha dejado una banda de guardia de 2
MHz en el límite inferior de la banda y de 3.5 MHz en el superior.
Por su parte, la especificación define dos tipos de modulaciones para transmitir datos,
dependiendo del modo de operación del dispositivo. De esta forma, si se operan en el
modo normal denominado Basic Rate y que alcanza una velocidad de transmisión
máxima de 1 Mbps, se usa una modulación FM binaria que minimiza la complejidad del
transceptor. No obstante, se define un modo opcional de transmisión que permite
alcanzar una mayor velocidad de transmisión, denominado Enhanced Data Rate, que
usa una modulación PSK y que posee dos variantes a su vez: DQPSK, que permite
alcanzar los 2 Mbps, y 8 DPSK, con la que se pueden obtener hasta 3 Mbps de tasa de
bits. La tasa de símbolos para ambas modulaciones es de 1 MSímbolo/s.
Para poder efectuar una transmisión full-duplex, se ha optado por usar un esquema de
multiplexación por división en el tiempo (TDD) en ambos modos. Este mecanismo
permite emular un canal de comunicación full dúplex a partir de un enlace de
comunicaciones half-duplex. Para ello, lo que se hace es dividir el tiempo en ranuras o
slots, asignando un cierto número de ellos al enlace de subida y otros al enlace de
29
bajada. Esto supone una gran ventaja cuando los enlaces son asimétricos ya que
permiten asignar más capacidad al canal que lo requiera.
Figura 3.3. Esquema de multiplexación por división en el tiempo de comunicaciones Bluetooth.
El otro aspecto más importante de la interfaz radio se corresponde con la potencia de
transmisión. Según la potencia máxima de salida, en la especificación Bluetooth se
distinguen tres tipos de dispositivos:
Clase
Potencia
de salida
(Pmax)
Potencia
Nominal
Potencia
de salida
(Pmin)
Control de potencia Alcance
1 100 mW
(20 dBm) N/D 1 mW (0 dBm)
Pmin< +4 dBm a Pmax
Opcional:
Pmin2 a Pmax
~100 m
2 2.5 mW
(4 dBm) 1 mW (0 dBm) 0.25 mW (-6 dBm)
Opcional:
Pmin2 a Pmax
~10 m
3 1 mW
(0 dBm) N/D N/D
Opcional:
Pmin2 a Pmax
~1 m
Tabla 3.31. Especificación de las clases de dispositivos y sus características.
La clase de dispositivo Bluetooth es un parámetro importante en una aplicación, ya
que determinará el alcance máximo del sistema.
3.3.2. Banda Base
La banda base permite el enlace físico de radiofrecuencia entre dispositivos Bluetooth
dentro de una piconet, es decir, dos o más dispositivos Bluetooth que comparten un
mismo enlace físico. Como estos terminales utilizan la expansión de espectro por
saltos de frecuencia, donde los paquetes se transmiten en franjas de tiempo
predefinidas por frecuencias conocidas, este nivel utiliza procedimientos de
averiguación y localización para sincronizar la frecuencia de saltos de transmisión y los
relojes de los diferentes dispositivos Bluetooth.
30
Además se encarga de controlar las operaciones sobre los bits y los paquetes, detectar
y corregir los errores que se produzcan en el medio, así como de la difusión automática
de mensajes a diferentes puntos de la red o del cifrado. También emite confirmaciones
y peticiones de repetición de las transmisiones recibidas. Es decir, efectúa las tareas de
la capa de enlace del modelo OSI.
3.3.2.1. Canales físicos
Corresponden con el nivel más bajo de abstracción dentro de la arquitectura
Bluetooth. Se definen cuatro tipos de canales físicos: dos estarán destinados a las
comunicaciones entre dispositivos conectados y asociados dentro de una piconet
específica; mientras que los otros dos, se destinarán al proceso de descubrimiento y al
establecimiento de una conexión. No obstante, los cuatro canales físicos mencionados
comparten características comunes como son:
Combinación de una secuencia de saltos en frecuencia pseudo-
aleatoria, lo que motiva la reducción de los efectos nocivos de las
interferencias.
Intervalos de tiempos específicos para las transmisiones.
Código de acceso.
Codificación de la cabecera de los paquetes.
Por su parte, un dispositivo Bluetooth puede usar solo uno de estos canales físicos en
un instante de tiempo dado. Sin embargo, en la norma se contempla la existencia
concurrente de múltiples operaciones, es decir, un mismo dispositivo puede
encontrarse realizando varias operaciones tales como transmitir datos y estar a la
espera de ser descubierto o de que le establezcan una conexión. Para ello se ha usado
un sistema de multiplexión por división en el tiempo entre los canales. De esta forma,
se consigue transmitir la sensación de que un mismo equipo puede encontrarse
conectado simultáneamente en varias piconets mientras está siendo descubierto o
esperando el establecimiento de una conexión nueva. En este sentido, algunos
dispositivos avanzados pueden ser capaces de conectarse simultáneamente a más de
un canal, aunque este hecho no queda recogido en la norma.
A continuación se muestran los diferentes canales físicos definidos en el estándar
Bluetooth.
Canal físico básico para piconets. En el estado “Conexión”, este canal se
corresponde con el usado por defecto. Queda definido por el maestro de la
piconet que, por definición, se trata del dispositivo que inicia una conexión
31
mediante paging. Además, el maestro será quien se encargue de controlar el
tráfico de la piconet mediante un esquema de polling. En este tipo de canales,
la secuencia de saltos en frecuencia pseudo-aleatoria hace uso de las 79
frecuencias de RF disponibles y se determinará mediante el reloj del maestro y
su dirección Bluetooth. En relación a la división en intervalos de tiempos, estos
poseen una duración de 625 microsegundos y son numerados de acuerdo a los
27 bits más significativos del reloj del maestro. El rango de numeración va
desde 0 a y es una rango periódico con periodo . Por otro lado, el
maestro siempre empezará a transmitir en un intervalo de tiempo par,
quedando a la espera de recibir datos de los esclavos en los instantes impares.
En el caso de usar paquetes cuya transmisión ocupe varias divisiones
temporales, se puede conmutar la transmisión por el proceso de recepción. De
tal forma que el maestro transmitiría en instantes impares y los esclavos en los
pares. A su vez, después de efectuar una transmisión, un paquete de respuesta
es esperado durante un tiempo tras el comienzo de la transmisión.
El parámetro N es un número entero e impar mayor que cero y su valor
depende del tipo de paquete que se haya transmitido. Por su parte, en el caso
de la recepción, el correlador de acceso buscará un código de acceso correcto
en el canal. Si no se obtiene ningún resultado positivo, entonces el receptor
esperará hasta el siguiente intervalo de recepción. En caso de producirse una
comparación satisfactoria, el receptor quedará pendiente de recibir el resto del
paquete salvo que el destinatario no sea ese dispositivo, haya un error
irrecuperable en la cabecera o este se produzca en la carga del paquete.
Figura 3.3. (a) Transmisión de paquetes multi-intervalos y (b) ciclo de transmisión y recepción de un
transceptor maestro en un modo normal de transmisión para paquetes de un solo intervalo.
Canal físico adaptado para piconets. Este tipo de canal se diferencia del
anterior en que el número de frecuencias que utiliza es inferior a los 79
definidos por la norma. No obstante, existe un mínimo que canales de RF a usar
y se corresponde con 20. Además de este hecho existen una segunda
32
diferencia, es que el mismo mecanismo de canal que hace la frecuencia esclava
es el que realiza anteriormente la transmisión maestra.
Canal físico para Page Scan. Estos canales se caracterizan por seguir un patrón
de salto más lento que los canales físicos para piconets. Este hecho se debe al
uso de una secuencia de salto más pequeña y que es determinada por la
dirección Bluetooth del que busca. En cuanto a la temporización del canal físico
para Page Scan, esta será determinada por el reloj nativo del terminal que
busca los dispositivos. Durante el procedimiento de paging, el maestro
transmitirá mensajes relacionados con el dispositivo al que se quiere conectar.
En un único intervalo de transmisión, el mensaje se transmitirá en dos
frecuencias diferentes como se muestra en la figura 3.4. Para el intervalo de
recepción, el dispositivo escuchará los mensajes de respuestas en dos
frecuencias diferentes.
Figura 3.4. Ciclo Rx/Tx de un transceptor en modo Page. En ella, se usa para las frecuencias de la
secuencia de salto correspondientes a la transmisión y , para las de recepción.
Canal físico para Inquiry Scan. Estos canales se caracterizan por seguir un
patrón de salto más lento que los canales físicos para piconets. Este hecho se
debe al uso de una secuencia de salto más pequeña y que es determinada por
la dirección Bluetooth del que busca. En cuanto a la temporización del canal
físico para Inquiry Scan, esta será determinada por el reloj nativo del terminal
que busca los dispositivos. Durante el proceso de Inquiry o de descubrimiento,
el maestro transmitirá mensajes con el código de acceso general o dedicado.
Por su parte la temporización para el descubrimiento es equivalente al
explicado para el mecanismo de paging.
33
Figura 3.5. Temporización de un paquete de respuesta al inquiry con éxito en la (a) primera mitad del
intervalo y (b) con éxito en la segunda mitad del intervalo.
3.3.2.2. Enlaces físicos
Un enlace físico representa una conexión a nivel de banda base entre dispositivos. Éste
siempre estará asociado a un solo canal físico.
Por su parte, los enlaces físicos poseen un conjunto de propiedades que son comunes
a todos los mecanismos de transporte lógicos. Estas propiedades resultan ser:
Control de potencia.
Supervisión del enlace.
Encriptación.
Cambio de la tasa de transferencia de datos dada según la calidad del canal.
Control de paquetes que ocupen varios intervalos temporales.
De las propiedades anteriores cabe destacar la supervisión del enlace debido a que es
una tarea crítica. Una conexión puede romperse por motivos tales como que uno de
los terminales haya salido fuera de cobertura, existen muchas interferencias en el
canal o se haya producido un fallo en la alimentación de algún equipo. Puesto que
alguno de estos fallos se produce sin previo aviso, es importante monitorizar el enlace
tanto del lado del maestro como del esclavo para evitar posibles colisiones cuando la
dirección del transporte lógico o de un miembro en estado park se reasigne a otro
esclavo.
Para poder detectar las pérdidas, tanto el maestro como el esclavo usarán un
temporizador de supervisión del enlace. Una vez recibido una cabecera de paquete
válida con la dirección de un esclavo en el enlace físico, el temporizador se reiniciará. Si
en algún instante durante el estado de conexión, el temporizador alcanza su valor
límite, , la conexión se considerará desconectada. Este mismo
temporizador es el usado para los transportes lógicos ACL, SCO y eSCO.
34
Finalmente, el valor del temporizador se negocia con el Gestor del enlace, eligiéndose
de tal forma que resulte mayor que los periodos asociados a los estados sniff y hold.
3.3.2.3. Transportes lógico
En este apartado se procederá a describir los mecanismos que la especificación
Bluetooth posee para ofrecer diferentes servicios que cubran las exigencias de los
usuarios. En concreto se definen cinco tipos de transportes lógicos:
Orientado a conexión síncrono (SCO, Synchronous Connection-Oriented). Se
caracteriza por ser un enlace punto a punto simétrico entre el maestro y un
esclavo específico. Este transporte lógico se basa en la reserva de intervalos de
tiempos, lo que permite emular una conexión basada en conmutación de
circuitos, ya que dicha reserva es permanente mientras el enlace exista. El
maestro puede soportar hasta tres enlaces SCO a un mismo esclavo o a varios.
Por su parte, un esclavo puede llegar a mantener hasta tres enlaces con un
mismo maestro o dos enlaces si estos proceden de maestros diferentes, lo que
implicaría que el dispositivo esclavo estaría inmerso en varias piconets.
Orientado a conexión síncrono extendido (eSCO, extended Synchronous
Connection-Oriented). Este segundo tipo de enlace síncrono se corresponde
con un transporte lógico punto a punto entre el maestro y un esclavo
específico. Sin embargo, a diferencia de SCO, el enlace puede ser simétrico o
asimétrico, lo que implicaría que el número de intervalos temporales
reservados no tiene por qué ser igual entre el maestro y el esclavo que entre el
esclavo y el maestro. Este transporte lógico se basa en la reserva de intervalos
de tiempos, al igual que SCO, lo que permite emular una conexión basada en
conmutación de circuitos. Por otro lado, eSCO soporta una ventana de
retransmisión inmediatamente después de los intervalos reservados. La unión
de estos intervalos y de la ventana de retransmisión es lo que se conoce como
ventana eSCO.
No orientado a conexión asíncrono (ACL, Asynchronous Connectionless Link).
Este tipo de transporte lógico permite suministrar un mecanismo de transporte
basado en conmutación de paquetes entre el maestro y todos los dispositivos
35
esclavos que constituyan la piconet, incluidos aquellos que ya poseen un enlace
SCO y/o eSCO activo. Para ello hace uso de los intervalos de tiempo no
reservados por los enlaces SCO y eSCO. Por su parte, entre un maestro y un
esclavo tan sólo puede existir un enlace ACL.
Difusión para esclavos activos (ASB, Active Slave Broadcast). Este transporte
lógico se usa cuando el maestro quiere comunicarse con todos los esclavos
activos. No existen asentimientos debido a que el tráfico es unidireccional
desde el maestro de la piconet a los esclavos. Sólo puede ser usado por el
tráfico de grupo L2CAP. Nunca se utilizará por los canales orientados a
conexión de L2CAP, señalización de control L2CAP o por la de LMP.
Difusión para esclavos en estado parked (PSB, Parked Slave Broadcast). Este
transporte lógico se usa cuando el maestro quiere comunicarse con los esclavos
que han sido puestos en estado parked. Este mecanismo de transporte resulta
más complejo que los anteriores por lo que se lleva a cabo en varias fases, cada
una de las cuales posee una finalidad diferente. Estas fases son:
Información de control: usada para transportar los enlaces lógicos LMP.
Información de usuario: utilizada para transportar los enlaces lógicos de L2CAP.
Fase de acceso: transporta la señalización de la banda base.
3.3.2.4. Enlaces lógicos
Los enlaces lógicos se definen como el nivel de la arquitectura más bajo usado para
ofrecer servicios de transporte de datos a los diferentes usuarios de Bluetooth. En la
especificación se definen cinco tipos de enlaces:
Control del enlace (LC, Link Control). Sirve para transportar información de
control del enlace como ARQ, control de flujo y la caracterización de la carga.
Se transporta en todos los paquetes excepto en el paquete ID que no tiene
cabecera.
Control ACL (ACL-C, ACL Control). Se utiliza para transportar la información de
control intercambiada entre el gestor de enlaces del maestro y de los esclavos.
36
Usuario asíncrono/isócrono (ACL-U, User Asynchronous/Isochronous). Se usa
para transportar los datos de usuario L2CAP asíncrono e isócrono. Estos
paquetes pueden ser transmitidos en uno o más paquetes de la banda base.
Usuario síncrono (SCO-S, User Synchronous). Se emplea para transportar de
forma transparente los datos de usuario síncronos. Sobre el viajan el transporte
lógico SCO.
Usuario extendido síncrono (eSCO-S, User Extended Synchronous). Se destina
para transportar de forma transparente los datos de usuario síncronos. Sobre el
viajan el transporte lógico eSCO.
3.4. Código de acceso
Se corresponde con el primer campo que aparece en todos los paquetes Bluetooth. La
estructura genérica de estos se representa en la figura 3.2.4, tanto para modo básico
de transferencia como para el modo EDR.
La misión del código de acceso es identificar todos los paquetes intercambiados en un
canal físico de forma que todos los paquetes que se envíen por el mismo canal físico
estén precedidos del mismo código de acceso. Además, se usa también para
sincronización y compensación del offset de la tensión continua.
Figura 3.6. (a) Estructura de un paquete genérico para el modo básico y (b) Estructura de un paquete
genérico para el modo EDR.
Figura 3.7. Formato del código de acceso.
Existen dos tipos de códigos de accesos, uno corto, que ocupa 68 bits y que está
compuesto únicamente de un preámbulo y una palabra de sincronización, y otro largo,
que añade un tercer campo denominado trailer y cuya longitud se incrementa hasta
los 72 bits.
37
Por otro lado, en la especificación se definen diversos tipos de códigos de accesos. Las
diferencias entre ellos radican en las diferentes formas en las que usan la parte más
baja de la dirección Bluetooth (representada en la norma por sus siglas en inglés: LAP,
Lower Address Part) para construir la palabra de sincronización.
Tipo de código LAP usado Longitud [bits]
CAC Maestro 72
DAC Dispositivo con el que se ha iniciado una conexión 68/72
GIAC Reservado 68/72
DIAC Dedicado 68/72
Tabla 3.4. Resumen de los tipos de códigos de acceso diferentes especificados en la norma.
En relación al preámbulo consiste en un patrón de ceros y unos de 4 símbolos usados
para facilitar la compensación en continua. La secuencia utilizada es 1010 si el bit
menos significativo de la palabra de sincronización comienza por 1 ó 0101, si empieza
por cero.
Figura 3.8. Preámbulo.
Con respecto a la palabra de sincronización, ésta está compuesta por un código de 64
bits derivado de los 24 bits que componen el LAP. La forma en la que se construye
dicha palabra garantiza una gran distancia de Hamming entre las
diferentes palabras de sincornización generadas a partir de los distintos LAPS.
Finalmente, el trailer es un apéndice a la palabra de sincronización cuando la cabecera
del paquete sigue al código de acceso. Esta suele ser la situación del código de acceso
CAC, aunque también suele darse en el DAC y el IAC cuando estos códigos se usan en
los paquetes FHS intercambiados durante una respuesta de tipo page o inquiry. Está
compuesto de un patrón de ceros y unos de cuatro símbolos. De manera que con los
tres bits más significativos de la palabra de sincronización forman un conjunto de 7 bits
de unos y ceros alternos que puede usarse para extender la compensación de DC.
Figura 3.9. (a) Trailer en CAC cuando el bit más significativo es cero y (b) trailer en CAC cuando el bit
más significativo es uno.
38
3.5. Operación del controlador de enlaces
En esta sección se procederá a describir cómo se establece una piconet y cómo los
dispositivos pueden sumarse y retirarse de dicha piconet. También se discutirá el
funcionamiento de las scatternets, o redes compuestas con miembros que pertenecen
a varias piconets a la vez.
Figura 3.10. Diagrama de estados del controlador de estados.
Para moverse de un estado o subestado a otro, se utilizan los comandos del gestor de
enlaces o señales internas del controlador, como puede ser la señal de disparo del
correlador y las señales de vencimiento de los temporizadores.
En relación al estado Standby, este se caracteriza por ser el estado por defecto en el
dispositivo. En él, el terminal puede encontrarse operando en un modo de bajo
consumo donde únicamente se encuentra el reloj en funcionamiento. Este estado
puede ser abandonado para pasar al subestado Page, Page Scan, Inquiry o Inquiry
Scan.
Con respecto al estado de conexión, se corresponde con el estado donde la conexión
entre dos dispositivos se ha establecido y el intercambio de paquetes puede comenzar.
39
En ambos dispositivos se utiliza el código de acceso del canal (CAC, impuesto por el
maestro) y el reloj nativo del maestro. A su vez, en este estado se puede usar la
secuencia de salto de canal básica o adaptada, en cuyo caso se necesitaría el mapa de
canales AFH.
El estado de conexión empieza con un paquete POLL enviado por el maestro para
verificar el cambio de la temporización de él y los saltos de canal. El esclavo puede
responder con cualquier tipo de paquete. Si no respondiera o el maestro no recibiese
respuesta por parte del esclavo, ambos dispositivos pasarían al subestado Page o Page
Scan.
Por su parte, el primer paquete transmitido en el estado de conexión contiene
información de control que permite caracterizar el enlace y dar más detalles de los
dispositivos conectados. Estos mensajes serán intercambiados entre los gestores de
enlaces de ambos dispositivos.
Para informar de la salida del estado Connection, se usan los comandos detach o reset.
En el caso de que el enlace se haya desconectado de manera normal, se usará el
comando detach. Mientras que el comando reset queda reservado para un reinicio del
controlador de enlaces. Después de que este haya sido completado, la operación que
estuviese ejecutándose se perderá.
Por otro lado, en el estado de conexión, un dispositivo no tiene por qué estar siempre
presente en el canal y puede declararse no disponible a través de los modos de
funcionamiento Sniff o Hold.
Figura 3.11. Representación detallada del estado Connection.
Por tanto, dentro del estado Connection se pueden encontrar tres modos de
funcionamiento del dispositivo diferentes, como puede observarse en la Figura 3.11.
Estos modos serán:
Modo activo. En este estado, tanto el maestro como el esclavo
participan en el canal. Hasta siete esclavos pueden encontrarse en el
modo activo en un mismo instante de tiempo. El maestro será quién
planifique los tiempos de transmisión asignados a cada uno según la
demanda de tráfico hacia y desde los distintos esclavos. Además,
soporta transmisiones regulares para almacenar los esclavos
40
sincronizados. Estos dispositivos se conocen como esclavos activos. Si
un esclavo activo no es direccionado, puede retirarse hasta la próxima
nueva transmisión del maestro. Por su parte, cuando un dispositivo está
participando en múltiples piconets, debe escuchar en el intervalo de
tiempo de transmisión del maestro al esclavo correspondiente. Se
recomienda que un dispositivo no abandone una piconet en la que está
participando más de intervalos de tiempo.
Modo Sniff. Durante este modo, el ciclo de actividad del esclavo en la
piconet puede ser reducido. Por ejemplo, se puede pensar en un esclavo
que se encuentra en modo activo sobre un enlace ACL. Él escuchará en
todos los intervalos de tiempos ACL del tráfico del maestro, a menos
que se trate de un enlace perteneciente a una scatternet o esté ausente
debido al modo Hold. Si este dispositivo se encontrase en modo Sniff,
los intervalos de tiempos que el esclavo estaría escuchando se verían
reducidos, de forma que el maestro solo transmitiría en unos intervalos
específicos. Dichos intervalos estarán separados por un tiempo .
Figura 3.12. Esquema temporal del funcionamiento del modo Sniff.
Modo Hold. Cuando un dispositivo entra en modo Hold provoca que,
temporalmente, no se puedan recibir paquetes ACL. No obstante,
cualquier paquete asociado a un enlace síncrono (SCO o eSCO) será
soportado. Esto permite al dispositivo en modo Hold, poder realizar
otras tareas como descubrir nuevos dispositivos o atender a otra
piconet. También puede ser utilizado para hacer entrar al dispositivo en
un modo de bajo consumo. Durante este modo, el esclavo almacena su
dirección de transporte lógica. Por otro lado, antes de poder entrar en
modo Hold, el maestro y el esclavo tiene que ponerse de acuerdo en la
duración del intervalo de tiempo que el esclavo permanecerá en dicho
modo. De esta forma, cuando el esclavo se pase al modo Hold, se
iniciará un temporizador con dicho valor. Cuando éste expire, el esclavo
despertará y se sincronizará a la piconet esperando nuevas
transmisiones del maestro.
41
En la Figura 3.10 se muestra el diagrama de estados del controlador de enlaces y cómo
se puede acceder a cada uno de ellos. En él se observan tres estados principales
denominados standby, connection y park. Además de estos tres estados, existen siete
subestados utilizados para el establecimiento de conexiones y para el descubrimiento
de los dispositivos Bluetooth existentes en el rango de cobertura. Estos siete
subestados se corresponden con:
Page. Se trata de un subestado utilizado por el maestro (fuente) para
activar y conectar a un esclavo (sumidero) en el subestado page scan. El
maestro intenta coincidir con la actividad de exploración del esclavo,
transmitiendo repetidamente los mensajes de paging consistentes en el
código de acceso del dispositivo esclavo en diferentes canales. Puesto
que el reloj del maestro y del esclavo no están sincronizados, el maestro
no conoce exactamente cuando el esclavo despertará ni en que salto de
frecuencia. Por tanto, el maestro transmite un tren de idénticos
mensajes de page scan en diferentes frecuencias y escucha entre los
intervalos de transmisión hasta que recibe una respuesta del esclavo.
El maestro comunica la dirección Bluetooth del esclavo al controlador. Ésta se usará
por el maestro para determinar la secuencia de saltos del subestado page. Para la fase
de la secuencia, el maestro usará una estimación del reloj del esclavo. Aunque el
maestro y el esclavo usen la misma secuencia de saltos, la fase puede ser diferente, de
forma que el esclavo y él no se sincronicen. Por este motivo, el maestro transmite
varios mensajes page durante un intervalo corto de tiempo en un conjunto de
frecuencias activas. Durante cada intervalo de transmisión, el maestro transmitirá
secuencialmente en dos frecuencias diferentes. En el siguiente intervalo de recepción,
el receptor escuchará secuencialmente en dos frecuencias diferentes.
Figura 3.13. Intercambio de mensajes durante la fase inicial de la conexión cuando un esclavo
responde un primer mensaje page.
42
Del subestado page se puede acceder desde el estado Standby o Connection.
Page Scan. Se corresponde con un estado donde un dispositivo puede
ser configurado para usar un procedimiento de exploración estándar o
entrelazado con el fin de establecer una conexión. Durante una
exploración normal, el dispositivo escucha durante una ventana de
tiempo (11,25 ms por defecto), mientras que la exploración
entrelazada se mejora con dos exploraciones, una tras otra, de
. Por este motivo, si el intervalo de exploración no es al
menos dos veces la ventana de exploración, el modo entrelazado no se
podrá usar. Durante esta ventana, el dispositivo escuchará en una única
frecuencia, mientras su correlador espera encontrar su código de acceso
de dispositivo (DAC). La ventana de exploración deberá ser lo
suficientemente larga como para que dé tiempo a completar la
exploración de 16 frecuencias. Cuando el dispositivo entra en este
estado, seleccionará la frecuencia de exploración de acuerdo a la
secuencia de saltos determinada por la dirección Bluetooth del
dispositivo. La fase de la secuencia se determinará por los bits 12, 13,
14, 15 y 16 del reloj nativo del dispositivo. Cada 1.28 segundos se
seleccionara una frecuencia diferente. Este estado puede ser accesible
desde los estados Standby y Connection.
Master Response. Se corresponde con el subestado en el que entra el
dispositivo maestro cuando recibe un mensaje de respuesta page por
parte del esclavo. Si se revisa la figura 3.13, se podrá comprobar que se
corresponde con el paso 2. En esta situación, se congelará en el maestro
el valor actual del reloj que se usa como entrada en el esquema de
selección de salto para el subestado page. Este valor, se transmitirá en
un paquete FHS con destino el terminal esclavo. En él, se halla todo la
información necesaria para construir el código de acceso al canal (CAC)
sin requerir operaciones matemáticas para derivar la dirección de
acceso del dispositivo Bluetooth maestro. El paquete FHS se transmitirá
en el comienzo del siguiente intervalo de tiempo entre el maestro y el
esclavo tras la respuesta del esclavo.
Después de que se haya enviado, se esperará durante un segundo un mensaje de
respuesta por parte del esclavo como asentimiento de la correcta recepción del
paquete FHS. Esta respuesta contendrá el DAC del dispositivo esclavo. Si no se recibe
respuesta, el maestro retransmitirá el paquete FHS con un valor actualizado del reloj y
usando aún los parámetros del esclavo cada vez hasta que se reciba un segundo
mensaje de respuesta o el temporizador asociado al tiempo de espera de una
43
respuesta cumpla. En este último caso, el maestro volverá al subestado page y enviará
un error al gestor de recursos de la banda base.
Por su parte, si la respuesta del esclavo se recibe, el maestro usará sus parámetros, es
decir, pasará a utilizar su CAC y su reloj. Finalmente, el maestro entrará en el estado de
Connection.
Slave Response. Este subestado se corresponde con el estado del
controlador de enlaces para responder un mensaje de tipo page. Como
se puede observar en la figura 3.10, después de recibir el mensaje page
en el paso 1, el esclavo transmitirá una respuesta que contiene su
código de acceso de dispositivo, es decir, deberá responder con su DAC.
Dicho mensaje de respuesta, se generará después de recibir el
mensaje page del paso 1. Acto seguido, el esclavo activará su receptor
transcurridos desde el comienzo del mensaje de respuesta, a
la espera de recibir un paquete FHS.
Figura 3.14. Temporización de los paquetes de respuestas en el subestado page.
Si un paquete FHS se recibe en este subestado dentro de los límites temporales
establecidos, el esclavo responderá con mensaje para asentir la recepción de dicho
paquete. En ese instante, el esclavo cambiará al CAC del maestro y modificará el reloj
en base al recibido en el paquete FHS. Finalmente, el esclavo entrará en el estado
Connection, usando el reloj y la dirección Bluetooth del maestro para determinar la
secuencia de salto en frecuencia y el CAC.
Por el contrario, si la configuración de la conexión falla antes de que el estado
Connection sea alcanzado, el esclavo estará escuchando en el canal siempre y cuando
no se haya recibido un paquete FHS o el temporizador asociado a la recepción de un
mensaje de respuesta venza. No obstante, cada , deberá seleccionar la
44
siguiente secuencia de salto en frecuencia con dirección maestro-esclavo. Si no se
recibe nada después de que se cumpla nuevamente dicho temporizador, el esclavo
deberá devolver al subestado page scan durante un periodo de búsqueda.
Inquiry. Este subestado se usa para descubrir a nuevos dispositivos. Es
muy similar al subestado Page. En concreto, las temporizaciones
asociadas a la transmisión y a la recepción serán las mismas. Con
respecto a las frecuencias de transmisión y de recepción, éstas seguirán
la secuencia de salto de inquiry y de inquiry response, que se
determinarán por el GIAC y el código nativo de reloj del dispositivo que
realiza el proceso de descubrimiento. Por su parte, entre cada
transmisión, se buscarán mensajes de respuestas (paquete FHS).
Cuando una respuesta se reciba, el paquete entero se procesará. Si el
bit EIR del paquete FHS se encuentra fijado a uno, quiere decir, que se
tratará de una respuesta extendida y se deberá esperar tras la
recepción de la respuesta para recibir la respuesta extendida. Todos
estos paquetes no se asentirán.
Figura 3.15. Formato del paquete FHS.
Por otro lado, de este subestado tan solo se puede salir de tres formas diferentes:
o El gestor de recursos de la bandabase genera un comando de
parada tras alcanzar un número de respuestas especificado. En
caso de no especificar dicho valor, el gestor de recursos no
podrá solicitar la salida del subestado.
o El temporizador asociado al tiempo de descubrimiento vence.
o El host que alberga al dispositivo Bluetooth decide cancelar el
descubrimiento mediante el envío de un comando.
Al subestado de inquiry se puede acceder desde los estados standby o connection. No
obstante, antes de poder acceder al inquiry desde el estado Connection, el dispositivo
debe liberar tanta capacidad del enlace como le sea posible para poder llevar a cabo la
búsqueda de nuevos terminales. Para garantizar esta premisa, en la especificación se
aconseja utiliza los modos sniff, hold o park. Sin embargo, los intervalos de tiempos
asignados a las conexiones síncronas no se verán perturbados por el proceso de
descubrimiento. De hecho, se interrumpirá para poder transmitir en los intervalos de
tiempo reservados para los enlaces SCO y eSCO, puesto que son más prioritarios que la
acción de descubrir nuevos dispositivos.
45
Inquiry Scan. En este subestado se lleva a cabo la tarea de buscar el
código de acceso IAC durante un período lo suficientemente largo como
para completar dicha búsqueda en las 16 frecuencias asignadas. Resulta
similar al subestado page scan, salvo que en vez de buscar dispositivos
por el DAC, se hace mediante el IAC. Existen dos tipos de búsquedas, la
normal y la entrelazada. En el caso de una búsqueda normal, la longitud
del período de búsqueda se denota por y las frecuencias
donde realizarla se determinan por . Para el modo entrelazado de
búsqueda, lo que se hace es mejorar el proceso de búsqueda mediante
dos exploraciones en diferentes frecuencias, una se efectúa en el salto
de frecuencia definido por el modo normal y el otro se realiza en
. Para que se pueda ejecutar de forma correcta, es
necesario que el intervalo de búsqueda sea al menos dos veces
. Además, la fase es determinada por el reloj nativo del
dispositivo que se encuentra en este subestado, cambiando cada 1.28
segundos.
Este subestado puede ser accedido desde los estados standby y connection. Al igual
que sucede en el estado inquiry, el dispositivo deberá reservar toda la capacidad
posible.
Inquiry Response. Se trata del subestado de respuesta a los mensajes de
inquiry. No puede enmarcarse dentro del subestado Slave Response,
debido a que este último se aplica sólo como respuesta a los mensajes
page. Cuando el mensaje inquiry se recibe en el subestado inquiry scan,
el receptor devolverá un paquete FHS como respuesta conteniendo la
dirección Bluetooth del dispositivo y otros parámetros. En el caso de
que el receptor estuviera esperando una respuesta extendida, se
enviaría la respuesta extendida transcurrido el tiempo necesario tras el
paquete FHS de respuesta. El mecanismo implementado en el esclavo
será el siguiente:
o En el primer mensaje inquiry recibido en el subestado inquiry
scan, el esclavo entrará en el subestado inquiry response.
o Si el esclavo está configurado para devolver un mensaje de
respuesta extendida, en el paquete FHS de respuesta, el bit EIR
se encontrará fijado a uno. Pasados , responderá con el
mensaje de respuesta extendida.
o En caso contrario, el dispositivo esclavo responderá únicamente
con el paquete FHS.
46
o En el caso de que existan muchos dispositivos Bluetooth,
correctamente configurados, en las proximidades del terminal
que está efectuando el proceso de descubrimiento, puede surgir
un problema si todos los dispositivos intentan responder a la vez
el mensaje de inquiry. Sin embargo, debido a que cada
dispositivo tiene un reloj corriendo arbitrariamente, es poco
probable que todos ellos usen la misma fase en la secuencia de
salto del proceso de descubrimiento. Para evitar colisiones
repetitivas, se ha implementado un sistema de espera aleatorio.
Si el dispositivo recibe un mensaje inquiry y responde con un
paquete FHS, generará un número aleatorio entre 0 y un número
máximo. Este último puede ser de 1023 para intervalos de
búsquedas mayores que 1.28 segundos o tan pequeño como 127
si el intervalo es inferior a 1.28 segundos.
Por su parte, tras salir de este subestado, el dispositivo podrá volver al estado de
connection o standby, aunque antes de realizar este paso se permite la transición hacia
el subestado page scan.
3.6. LMP
Cuando dos dispositivos Bluetooth son descubiertos en el rango de cobertura de
ambos y deciden establecer una conexión entre ellos, los gestores de enlaces (en
inglés, Link Manager, LM) de ambos dispositivos interactúan entre sí intercambiando
una serie de mensajes para gestionar y controlar el la comunicación entre ellos. Al
conjunto de mensajes que intercambian bajo una serie de reglas se conoce como
Protocolo de Gestión de Enlaces (en inglés, Link Manager Protocol, LMP) y se usa para
controlar y negociar todos los aspectos de las conexiones Bluetooth entre dos
dispositivos. Esto incluye la configuración y control de enlaces y transportes lógicos y el
control de los enlaces físicos. En este punto cabe destacar que todos los mensajes LMP
se aplicarán exclusivamente al enlace físico y a los enlaces y transportes lógicos
asociados a la comunicación establecida entre el dispositivo emisor y el receptor, y
viceversa.
47
Figura 3.16. Operación del protocolo de gestión de enlaces.
Algunos de los servicios soportados por LMP son:
Transmisión y recepción de datos.
Petición de nombre.
Petición de las direcciones de enlace.
Establecimiento de la conexión.
Autenticación.
Negociación del modo del enlace y establecimiento. Esta característica
puede variar en el transcurso de una conexión.
Este protocolo está constituido por un conjunto de mensajes, denominados PDU, que
serán intercambiados sobre enlaces lógicos de tipo ACL-C en los transportes lógicos
ACL. Dichos mensajes poseen una prioridad más alta que los datos de usuario, para
que un mensaje que necesite enviar el gestor de enlaces no se vea retrasado por el
tráfico de los protocolos superiores, como L2CAP.Sin embargo, sí que es posible que
las PDUs se vean retrasadas por las retransmisiones múltiples de paquetes de banda
base individuales. En cualquier caso, el gestor de enlaces filtra e interpreta estos
mensajes en el lado receptor por su entidad par y no se propaga a los niveles
superiores. Las capacidades de detección y corrección del transporte lógico ACL son,
en general, suficientes para los requisitos de LMP. Por tanto, las PDUs no contienen
48
ninguna información adicional para informar de la detección de errores más allá de las
que puedan realizarse a través de los controles realizados al contenido de los mensajes
de LMP.
Por su parte, existen 56 PDUs definidas en la especificación Bluetooth, cada una de las
cuales, se utiliza para llevar a cabo una función diferente. A cada PDU se le asigna un
código de operación de 7 ó 15 bits que permite identificar de forma unívoca los
diferentes mensajes. Los primeros 7 bits del código de operaciones y un identificador
de transacción son localizados en el primer byte de la carga. Si el campo asociado al
código de operación tiene un valor comprendido entre 124 y 127, entonces se le añade
un byte adicional en la carga para generar un código de operación de 15 bits. El resto
de parámetros que pueda contener la PDU se ubicarán en los bytes siguientes.
Figura 3.17. Estructura de las PDUs intercambiadas por los gestores de enlace.
Cada PDU puede ser de carácter obligatorio u opcional. Desde este punto de vista, el
gestor de enlaces no requiere transmitir una PDU opcional, pero deber ser capaz de
reconocer todas las PDU, obligatorias u opcionales, y, si se requiere una respuesta,
enviar una contestación válida, incluso cuando se trate de una característica que no
esté soportada. No obstante, es posible solicitar una lista de cuáles de las PDUs
opcionales están soportadas.
Finalmente, LMP opera en términos de transacciones. Una transacción hace referencia
a un conjunto de mensajes intercambiados entre dos dispositivos con una finalidad
particular. Todas las PDUs que forman parte de la misma transacción deberán tener el
mismo identificador que se almacena como parte del primer byte del código de
operaciones. Éste se encuentra en el bit menos significativo. Valdrá “0” si la PDU forma
parte de una transacción iniciada por el maestro y “1” en caso contrario, es decir, si la
transacción fue iniciada por el esclavo.
3.7. Modos de operación
Existen tres modos de operación diferentes:
49
Modo de retención (Hold mode): el transporte lógico ACL de una
conexión entre dos dispositivos Bluetooth se puede poner en modo de
retención durante un tiempo especificado. Durante este tiempo, el
maestro no puede transmitir paquetes. Normalmente, se activa este
modo cuando no hay necesidad de enviar datos durante un período
relativamente extenso. Durante dicho período, se puede apagar el
transceptor para ahorrar energía. No obstante, este modo también se
puede utilizar si el dispositivo necesita descubrir nuevos terminales o
ser descubierto por otros dispositivos. Finalmente, tanto el maestro
como el esclavo pueden solicitar entrar en modo retención.
Modo de escucha selectiva (Sniff mode): se corresponde con otro modo
de funcionamiento que permite ahorrar energía en los dispositivos
Bluetooth. Para entrar en el modo de escucha selectiva, el maestro y el
esclavo negocian un intervalo y un desplazamiento de escucha selectiva,
que especifica la temporización de las franjas de escucha selectiva.
Después de eso, las franjas de escucha selectiva continúan de forma
periódica con el intervalo especificado. Cuando el enlace se encuentra
en este modo, el maestro sólo puede iniciar una transmisión en dicha
franja. Por su parte, existen dos parámetros que controlan la actividad
de escucha en el esclavo:
o Duración de la escucha selectiva: determina durante cuántas
franjas debe escuchar el esclavo, comenzando por la de escucha
selectiva, incluso si no recibe un paquete con su propia dirección
de miembro activo.
o Fin de escucha selectiva: determina cuántas franjas adicionales
debe escuchar el esclavo si continúa recibiendo sólo paquetes
con su propia dirección de miembro activo.
Finalmente, el maestro puede forzar al esclavo a entrar en modo de escucha selectiva,
pero tanto el maestro como el esclavo pueden solicitar por propia voluntad entrar en
este modo. Al recibir la solicitud, se puede devolver la misma con los parámetros
modificados, o se puede finalizar la negociación.
Modo de aparcamiento (Park mode): si no es necesario que un esclavo
participe en el canal, pero aun así debe mantenerse sincronizado con los
saltos en frecuencias, se puede colocar al esclavo en modo de
aparcamiento. En él, el dispositivo abandona su dirección de miembro
activo. Por otro lado, cuando se coloca un esclavo en modo aparcado, se
le asigna una dirección de miembro aparcado exclusiva, que puede ser
50
utilizada por el maestro para desaparcar dicho esclavo. Incluso sin su
dirección de miembro activo, el dispositivo puede todavía sincronizarse
con el canal despertándose en respuesta a mensajes emitidos a
intervalos predeterminados. El maestro también puede cambiar los
parámetros del modo de aparcamiento, transferir información de
difusión o dejar que el esclavo aparcado solicite acceso al canal.
El maestro puede forzar la entrada en modo aparcamiento. En este procedimiento, el
maestro finaliza la transmisión del mensaje actual y luego envía la orden para pasar a
modo de aparcamiento. Cuando el esclavo la recibe, finaliza la transmisión que
estuviera realizando y responde con un mensaje aceptando la orden. No obstante, el
maestro también puede solicitar la entrada en dicho modo en vez de forzarla. Para
ello, el maestro finaliza la transmisión y envía una petición de entrada en modo
aparcado. Si el esclavo acepta la solicitud para entrar en modo aparcamiento, finaliza
la transmisión actual y luego responde con un mensaje de aceptación. Si el esclavo
rechaza dicha petición, respondería con una negación. Finalmente, el esclavo puede
solicitar ser colocado en modo aparcado. En ese caso, el esclavo finaliza la transmisión
del mensaje actual y luego envía al maestro una solicitud de entrada en modo
aparcado. Si el maestro acepta la petición de modo aparcado, finaliza la transmisión
del mensaje actual y luego envía la orden de entrada en modo aparcado. Si el maestro
rechaza dicho modo, enviaría un mensaje rechazando dicha petición.
3.8. HCI
Las siglas inglesas HCI se corresponden con Host Controller Interface y es la parte de la
especificación Bluetooth que se encarga de suministrar una interfaz de comandos al
controlador de la banda base y gestor de enlaces, y de acceder al estado del hardware
y de los registros de control. En esencia, esta interfaz da un método homogéneo de
acceso a las capacidades de la banda base de Bluetooth. Se divide en tres secciones:
HCI Firmware. Se ubica en el controlador del transceptor Bluetooth. Esta
sección implementa los comandos HCI para el hardware Bluetooth
mediante acceso a las órdenes de la banda base, comandos del gestor
de enlace y a los registros de control, de estado y de eventos.
La capa de transporte. Se corresponde con la sección del HCI encargado
de interconectar al HCI driver con el HCI firmware. Un ejemplo de la
capa de transporte podría ser el conjunto de capas que pueden existir
entre el controlador HCI en un PC (véase, por ejemplo, la pila BlueZ) y el
firmware existente en un transceptor Bluetooth. Todas esas capas
intermedias, desde el sistema operativo hasta el mecanismo de
comunicación utilizado, USB, UART o RS-232, deben suministrar la
51
capacidad de transferir datos sin un conocimiento exhaustivo de los
datos que están siendo transferidos.
HCI driver. Está localizado en el transceptor Bluetooth o puede estar
integrado en el equipo que alberga el transceptor. Esta sección hace
referencia a la entidad software. El equipo recibirá notificaciones
asíncronas de eventos HCI, los cuales se usan para notificar cuando
ocurre algún suceso susceptible de ser notificado. Cuando el host
descubre que un evento ha tenido lugar, entonces analizará el paquete
recibido para determinar el tipo de evento acaecido.
Figura 3.18. Información general de extremo a extremo de las capas de software inferiores utilizadas
en la transferencia de datos.
3.8.1. Comandos HCI
HCI otorga un método homogéneo de acceso, basado en órdenes o comandos, a las
capacidades de Bluetooth. Para poder efectuar tal tarea, estos se encuentran
ordenados en grupos según la función que realicen. Los diferentes comandos que se
pueden encontrar en la norma son:
52
Grupo Descripción Ejemplo
Eventos genéricos
Los eventos genéricos pueden ocurrir debido a
múltiples comandos o eventos que pueden suceder
en cualquier instante
Command Complete
Event
Configuración del
dispositivo
Se utilizan para ubicar al Controlador en un estado
conocido Reset Command
Control del
controlador de flujo
Se usan para controlar los flujos de datos desde el
Host al controlador
Read Buffer Size
Command
Información del
controlador
Permiten que al Host descubrir información local
sobre el dispositivo
Read Local Version
Information Command
Configuración del
controlador
Dejan configurar los parámetros globales de
configuración
Read Local Name
Command
Descubrimiento de
dispositivos
Son comandos o eventos que consienten a un
dispositivo descubrir otros dispositivos que se
encuentran en su rango de cobertura
Inquiry Command
Configuración de
conexiones Permiten a un dispositivo realizar una conexión a otro
Create Connection
Command
Información remota Acceden a la información de configuración de un
dispositivo remoto que es descubrible
Remote Name Request
Command
Conexiones
síncronas
Se usan para el establecimiento de conexiones
síncronas
Setup Synchronous
Connection Command
Estado de la
conexión
Obtienen la configuración de un enlace,
especialmente utilizados para los enlaces de bajo
consumo
Hold Mode Command
Estructura de la
Piconet Permiten descubrir y reconfigurar una piconet
Role Discovery
Command
Calidad de servicio Especifican los parámetros para fijar una determinada
calidad en el servicio
Flow Specification
Command
Enlaces físicos Configuran un enlace físico Read Link Supervision
Timeout Command
Control de flujo en el
Host
Se utilizan para controlar el flujo de datos hacia el
Host
Host Buffer Size
Command
Información del
enlace Obtienen información sobre un enlace particular
Read LMP Handle
Command
Autenticación y
encriptación
Permiten la autenticación de un dispositivo remoto y
la encriptación de un enlace
Authentication
Requested Command
Pruebas Se utilizan para poner a un dispositivo en modo de
prueba y verificar el comportamiento del mismo
Read Loopback Mode
Command
Tabla 3.3. Comandos HCI: agrupación y descripción.
3.9. L2CAP
Dentro de la especificación Bluetooth, el protocolo L2CAP (Logical Link Control
Adaptation Protocol, Protocolo de Adaptación y Control de Enlaces Lógicos) se encarga
de la multiplexación de los protocolos de niveles superiores y de las tareas de
segmentación y recomposición de paquetes. También se encarga de transportar
53
información de calidad de servicio entre un dispositivo y otro. Al igual que LMP, L2CAP
se halla en un nivel superior a la banda base y reside en el nivel de enlace de datos del
modelo de referencia OSI.
Figura 3.19. Ubicación de L2CAP dentro de la pila de protocolos de Bluetooth.
L2CAP permite que las aplicaciones y protocolos de nivel superior transmitan y reciban
paquetes de datos de una longitud máxima de 64 KB de longitud. Además, también
contempla control de flujo por canal y retransmisiones a través de los modos de
control de flujo y retransmisión, respectivamente.
Figura 3.20. Diagrama de bloques del protocolo L2CAP.
En otro orden, mientras que en la especificación de la banda base se definieron dos
tipos de enlaces (enlaces síncronos orientados a conexión, SCO, y enlaces asíncronos
no orientados a conexión, ACL), el protocolo L2CAP está definido únicamente para
enlaces de tipo ACL y no puede existir nada más que un enlace de este tipo. Esto se
54
debe a que L2CAP depende de las comprobaciones de integridad en el nivel de banda
base para proteger la información transmitida, siendo los enlaces ACL los únicos
capaces de satisfacer dichas exigencias a través de un esquema ARQN/SEQN de un bit.
Entre las características de L2CAP están la sencillez y una baja sobrecarga del enlace, lo
que le hace apropiado para su implementación en dispositivos con recursos de cálculo
y memoria limitados como teléfonos móviles, sistemas empotrados o dispositivos PDA.
Estas características le permiten alcanzar una elevada eficiencia de ancho de banda sin
consumir demasiada energía, de acuerdo con los objetivos de eficiencia energética de
la comunicación establecidos en la interfaz radio Bluetooth.
Además de su eficiencia, realiza las siguientes tareas:
Multiplexación de protocolos y/o canales. El hecho por el que la
multiplexación de los protocolos superiores y de los canales se
efectuada por L2CAP se debe a que la banda base no posee ningún tipo
de campo identificativo que permita realizar dicha tarea.
Segmentación y re ensamblado. Si L2CAP tiene el control sobre la
longitud de las tramas transmitidas, se favorece el funcionamiento de
muchas aplicaciones multiplexadas sobre L2CAP. Esto se debe a:
o La capa de segmentación dejará la separación necesaria entre las
unidades de datos de las aplicaciones para satisfacer los
requisitos de latencia.
o La gestión de la memoria y de los buffers se resulta más sencilla
cuando L2CAP controla el tamaño de los paquetes.
o La corrección de errores mediante retransmisiones se puede
efectuar de manera más eficiente.
o La cantidad de datos que se destruye cuando una PDU del
protocolo L2CAP se corrompe o se pierde puede hacerse más
pequeña que la unidad de datos de la aplicación.
o La aplicación está desacoplada de la segmentación requerida
para encapsular los paquetes de la aplicación en los de las capas
inferiores de la especificación Bluetooth.
Control de flujo por canal L2CAP. Este se implementa debido a que el
control de flujo de tipo stop-and-go que se usa en la banda base puede
no ser suficiente para la mayoría de las aplicaciones. Por este motivo,
L2CAP también provee un servicio de control de flujo para aplicaciones
55
o perfiles que puedan necesitarlo, sin necesidad que lo implemente
estos. El uso de dicho control de flujo es un aspecto opcional del
protocolo.
Control de errores y retransmisiones. Algunas aplicaciones requieren
una tasa de error residual mucho más pequeña que la suministrada por
la banda base. L2CAP incluye comprobaciones de errores adicionales y
retransmisiones de tramas L2CAP.
Fragmentación y recombinación. Las capas inferiores tiene limitada las
capacidades de transmisión por lo que podrían requerir el uso de
fragmentos de tamaños diferentes a los creados por la subcapa de
segmentación de L2CAP. Por tanto, las capas por debajo de L2CAP
pueden fragmentar y recombinar PDUs de L2CAP para crear fragmentos
que se ajusten a las capacidades de la capa. Durante una transmisión,
muchos niveles diferentes de fragmentación y recombinación pueden
ocurrir en ambos dispositivos.
Calidad de servicio. Durante el proceso de establecimiento de una
conexión L2CAP, se permite el intercambio de información atendiendo a
la calidad de servicio esperada entre los dos dispositivos Bluetooth.
Cada implementación L2CAP monitoriza los recursos usados por el
protocolo y se asegura que la calidad de servicio se satisface.
3.9.1. Modo de operación de L2CAP
L2CAP está basada en torno al concepto de canales. A cada una de las terminaciones
de un canal L2CAP se le denomina identificador de canal (Channel Identifier, CID). De
esta forma es como se conoce al nombre que representa a una terminación de un
canal lógico en un dispositivo. Su alcance es local, es decir, únicamente afecta al
dispositivo en cuestión. El conjunto de valores que puede tomar el identificador de
canal se representa en la tabla 3.4.
En relación a la asignación de CID, esta es relativa a un dispositivo en concreto y la
asignación de los mismos puede ser totalmente diferente en otro terminal, salvo que
se usen los CIDs reservados que se muestran en la tabla 3.4.
56
CID Descripción
0x0000 Identificador nulo. Se corresponde con un identificador ilegal y nuca podrá usarse como
una terminación destinataria
0x0001 Canal de señalización
0x0002 Recepción de canales no orientados a conexión
0x0003-
0x003F Reservados para funciones específicas de L2CAP
0x0040-
0xFFFF Asignados dinámicamente
Tabla3.4. Descripción de los diferentes CID que se pueden utilizar.
La figura 3.21 muestra el uso de varios identificadores CID entre entidades L2CAP
situadas al mismo nivel en dispositivos diferentes. Los canales de datos orientados a
conexión representan una comunicación entre dos dispositivos, donde un CID
identifica a cada extremo del canal. Los canales no orientados a conexión limitan el
flujo de datos a una única dirección. Estos canales se utilizan para soportar un “grupo”
de canales, donde el CID del origen representa a uno o más dispositivos remotos. En
una entidad L2CAP, es obligatorio el soporte de un canal de señalización que permita
crear y establecer canales orientados a conexión y negociar cambios en las
características de los canales orientados y no orientados a conexión. Además de todos
estos CID, se reserva uno más para todo el tráfico entrante de canales de datos no
orientados a conexión. En la figura, se utiliza un CID para representar un grupo
formado por los dispositivos 3 y 4. El tráfico que se envía desde este CID se dirige al
canal remoto reservado para el tráfico de datos no orientado a conexión.
Figura 3.21. Ejemplo del uso y significado del campo CID.
Con respecto al modo de funcionamiento de L2CAP, este protocolo puede operar de
tres formas diferentes:
Modo L2CAP básico.
57
Modo control de flujo. En este modo, en caso de pérdida no se realizan
retransmisiones, sino que se detecta las PDUs perdidas y se notifican a
las capas superiores.
Modo retransmisión. Se caracteriza por la utilización de un
temporizador que garantiza que todas las PDUs son entregadas a la
entidad L2CAP par, retransmitiendo al vencimiento del mismo aquellas
que fuesen necesarias. Se utiliza un mecanismo de tipo go-back-n,
gracias al cual se puede simplificar el protocolo y limitar los requisitos
de los buffers.
El modo L2CAP básico es el modo ejecutado por defecto, es decir, cuando el
dispositivo no ha sido configurado previamente para funcionar en alguno de los otros
dos.
3.10. Perfiles
Para que un dispositivo pueda utilizar la tecnología inalámbrica Bluetooth, debe saber
interpretar los perfiles Bluetooth, que describen las distintas aplicaciones posibles.
Estos perfiles son guías que indican los procedimientos por los que los dispositivos
equipados con tecnología Bluetooth se comunican entre sí. Existe un amplio abanico
de perfiles que detallan los diferentes tipos de uso y aplicaciones de la tecnología
inalámbrica Bluetooth. Al seguir las directrices proporcionadas en las especificaciones
Bluetooth, los desarrolladores pueden crear aplicaciones compatibles con otros
dispositivos que se ajusten a este estándar.
Cada perfil incluye, como mínimo, información sobre las siguientes cuestiones:
Dependencia de otros perfiles
Propuestas de formato de interfaz de usuario
Características concretas de la pila de protocolos Bluetooth utilizada por
el perfil. Para realizar su función, cada perfil se sirve de ciertas opciones
y parámetros en cada capa de la pila. También se puede incluir un breve
resumen de los servicios requeridos si resulta necesario.
En la tabla 3.5, se recogen todos los perfiles soportados por la especificación Bluetooth
v.2.1, así como los protocolos en los que se apoyan estos para hacer uso de las capas
inferiores de la norma.
58
Perfil Descripción
Perfil de distribución de
audio avanzado (A2DP)
El perfil A2DP describe cómo transferir sonido estéreo de alta calidad de
una fuente de sonido a un dispositivo receptor.
Protocolo de control de
audio y vídeo (AVRCP)
El perfil AVRCP proporciona una interfaz estándar para manejar
televisiones, equipos de alta fidelidad o cualquier otro equipo electrónico,
y permitir así que un único control remoto, o cualquier otro tipo de mando,
controle todo el equipo de audio y vídeo al que el usuario tiene acceso.
Perfil básico de imagen
(BIP)
El perfil BIP establece cómo puede controlarse remotamente un dispositivo
de imagen, así como la forma de enviarle órdenes de impresión y de
transferencia de imágenes a un dispositivo de almacenamiento.
Perfil básico de impresión
(BPP)
El perfil BPP permite enviar mensajes de texto, de correo electrónico,
tarjetas de visita electrónicas e imágenes, entre otras cosas, a las
impresoras disponibles dependiendo de las tareas de impresión.
Perfil de acceso RDSI
común (CIP)
El perfil CIP establece cómo se deben transferir las señales RDSI a través de
una conexión inalámbrica Bluetooth.
Perfil de telefonía
inalámbrica (CTP)
El perfil CTP describe la implementación de un teléfono inalámbrico a
través de un enlace inalámbrico Bluetooth.
Perfil de red de marcado
(DUN)
El perfil DUN proporciona un acceso telefónico estándar a Internet y a
otros servicios de marcado a través de una conexión Bluetooth.
Perfil de fax (FAX) El perfil FAX describe cómo un dispositivo terminal puede utilizar a otro
como puerta de enlace para la transmisión de faxes.
Perfil de transferencia de
archivos (FTP)
El perfil FTP establece los procedimientos de exploración de carpetas y
archivos de un servidor a través de un dispositivo cliente.
Perfil de distribución
genérica de audio y vídeo
(GAVDP)
El perfil GAVDP sienta las bases de los perfiles A2DP y VDP, pilar de los
sistemas diseñados para la transmisión de sonido e imagen mediante la
tecnología Bluetooth.
Perfil genérico de
intercambio de objetos
(GOEP)
El GOEP se utiliza para transferir objetos de un dispositivo a otro.
Perfil manos libres (HFP) El perfil HFP describe cómo un dispositivo que actúa como puerta de
enlace puede utilizarse para realizar y recibir llamadas a través de un
dispositivo manos libres.
Perfil de sustitución de
cable de copia impresa
(HCRP)
El perfil HCRP describe cómo imprimir archivos mediante un enlace
inalámbrico Bluetooth utilizando controladores en el proceso.
Perfil de auricular (HSP) El HSP describe cómo un auricular con tecnología Bluetooth se comunica
con otro dispositivo con tecnología Bluetooth.
Perfil de dispositivo de
interfaz humana (HID)
El perfil HID recoge los protocolos, procedimientos y características
empleados por las interfaces de usuario Bluetooth tales como teclados,
dispositivos punteros, consolas o aparatos de control remoto.
Perfil de
intercomunicador (ICP)
El perfil ICP establece cómo conectar dos teléfonos móviles con tecnología
Bluetooth dentro la misma red sin utilizar la red telefónica pública.
Perfil de introducción de
objetos (OPP)
Este perfil distingue entre servidor y cliente de introducción (push) de
objetos.
Perfil de redes de área
personal (PAN)
El perfil PAN describe cómo dos o más dispositivos con tecnología
Bluetooth pueden formar una red ad hoc y cómo ese mismo mecanismo
permite acceder a la red de forma remota a través de un punto de acceso.
Perfil de aplicación de El perfil SDAP detalla cómo una aplicación debe utilizar el perfil SDP para
59
descubrimiento de
servicio (SDAP)
identificar los servicios de un dispositivo remoto.
Perfil de servicio de
puerto (SPP)
El perfil SPP describe cómo configurar puertos de serie y conectar dos
dispositivos con tecnología Bluetooth.
Perfil de sincronización
(SYNC)
El perfil SYNC se utiliza junto al GOEP para sincronizar los elementos del
administrador de información personal (PIM), como agendas y datos de
contacto, entre dispositivos con tecnología Bluetooth.
Perfil de distribución de
vídeo (VDP)
Este perfil dicta los pasos que deben seguir los dispositivos Bluetooth con
tecnología Bluetooth para la transferencia de flujos de datos de vídeo.
Protocolo Descripción
Protocolo de control de
audio y vídeo (AVCTP)
El protocolo AVCTP describe los mecanismos de transferencia para
intercambiar mensajes que permitan controlar los dispositivos de audio y
vídeo.
Protocolo de distribución
de audio y vídeo (AVDTP)
El AVDTP detalla los procedimientos de negociación, establecimiento y
transmisión del flujo de audio y vídeo.
Protocolo Bluetooth de
encapsulación de red
(BNEP)
El protocolo BNEP se utiliza para transportar protocolos de red comunes,
como IPv4 o IPv6, entre los distintos medios de transmisión Bluetooth.
Protocolo de intercambio
de Objetos (OBEX)
OBEX es un protocolo de transferencia que define los objetos de datos y el
protocolo de comunicaciones que deben utilizar dos dispositivos para
intercambiar objetos.
Protocolo de control de
telefonía (TCP)
Este protocolo establece la señalización para el establecimiento de
llamadas de voz y datos en dispositivos con tecnología Bluetooth.
RFCOMM con TS 07.10 El protocolo RFCOMM emula los parámetros de un cable de serie y el
estado de un puerto RS-232 para transmitir datos en serie.
Tabla 3.5. Perfiles y protocolos soportados por la especificación 2.1 de Bluetooth.
En esta sección se procederá a desarrollar el protocolo RFCOMM exclusivamente
debido a que es el utilizado en la realización del proyecto. Por este motivo, se le
recomienda al lector si está interesado en conocer en detalle algún perfil o protocolo
diferente a éste en mayor profundidad, acuda a la referencia [29] y revise el
documento correspondiente.
3.11. RFCOMM
El protocolo RFCOMM suministra al dispositivo Bluetooth un mecanismo de emulación
de puerto serie sobre el protocolo L2CAP. Se corresponde con un protocolo de
transporte sencillo que se usa para el transporte de los datos de usuario, de las señales
de control de módem y de los comandos de configuración. Se encuentra basado en la
especificación TS07.10 de la ETSI, European Telecommunications Standards Institute,
organismo que se encarga de la normalización en la industria de las
telecomunicaciones.
60
Figura 3.22. Modelo de referencia RFCOMM.
En la figura 3.22 se puede observar los elementos en los que se apoya RFCOMM. De
todos ellos cabe destacar la entidad de emulación de puertos, ubicada por encima de
dicho protocolo y cuya misión radica en traducir la interfaz de comunicación específica
de un sistema en servicios RFCOMM. Sobre dicha capa, se apoyaría la aplicación en
cuestión, la cual estaría contemplando una interfaz de comunicaciones equivalente a
un puerto serie. El resto de elementos se corresponde con protocolos o niveles
detallados en secciones anteriores.
Para la finalidad de RFCOMM, se requiere de dos aplicaciones ejecutándose en
dispositivos diferentes que esperan que la comunicación tenga lugar a través de un
cable serie, el cual resultará emulado por este protocolo. No obstante, dichas
aplicaciones, al no ser conscientes de los procedimientos Bluetooth para establecer
cables series emulados, pueden necesitar la ayuda de una aplicación auxiliar que utilice
la especificación Bluetooth a ambos lados del enlace.
Por su parte, existen dos tipos de dispositivos básicos a los que RFCOMM debe dar
servicio:
Dispositivos que actúan como terminaciones de la comunicación, como
puede ser un ordenador o una impresora.
Dispositivos que forman parte del enlace de comunicación como resulta
ser un módem.
Aunque RFCOMM no hace distinciones entre estos dos dispositivos, el uso de uno u
otro terminal posee implicaciones en el protocolo, tales como el uso de tramas
utilizadas exclusivamente por un tipo.
61
3.11.1. Señales de control
RFCOMM emula las 9 líneas de una interfaz RS-232. Estas quedan registradas en la
siguiente tabla:
Pin Descripción
102 Señal común
103 Transmisión (TXD)
104 Recepción (RXD)
105 Petición para envío (RTS)
106 Limpiar para enviar (CTS)
107 Conjunto de datos listos (DTS)
108 Terminal de datos listo (DTR)
109 Detección de portadora de datos (CD)
125 Indicador de llamada (RI)
Tabla 3.6. Líneas RS-232 emuladas en RFCOMM.
3.11.2. Emulación Módem-Null
Como se ha comentado anteriormente, RFCOMM está basado en TS07.10. Esta norma
no distingue entre dispositivos DTE, equipo terminal de datos, y DCE, equipo de
comunicación de datos, cuando se trata de transferir los estados de los circuitos que
no son de datos. Para ello, lo que se hace es enviar las señales de control RS-232 como
una serie de señales DTE/DCE independientes.
Señales TS 07.10 Señales de control RS-232 correspondientes
RTC DSR, DTR
RTR RTS, CTS
IC RI
DV DCD
Tabla 3.7. Correspondencia de las señales de control recogidas en la norma TS07.10 y las señales de
control RS-232.
La forma en la que TS07.10 transfiere las señales de control RS-232 es creando un
enlace modem-null implícito cuando dos dispositivos del mismo tipo se conectan entre
sí. Este sistema previsto por RFCOMM deberá funcionar en la mayoría de las
situaciones posibles.
3.11.3. Puerto serie emulado
Este protocolo soporta hasta 60 conexiones simultáneas entre dos dispositivos
Bluetooth. No obstante, este número puede variar según la implementación específica
62
del fabricante. Un identificador de enlace de datos de conexión (DLCI) identifica una
conexión permanente entre un cliente y un servidor de aplicaciones. El DLCI está
representado por 6 bits, pero su rango de valores utilizables oscila entre 2 y 61. El
identificador de enlaces es único dentro de una sesión RFCOMM entre dos
dispositivos.
Para tener en cuenta el hecho de que tanto el cliente como servidor de aplicaciones
pueden residir en ambos lados de una sesión RFCOMM, con clientes en ambos lados
pudiendo realizar conexiones independientes entre sí, el espacio de valores DLCI se
divide entre los dos dispositivos que se comunican mediante el concepto de servidor
RFCOMM canales.
Si un dispositivo Bluetooth soporta múltiples puertos series emulados y se les permite
a las conexiones tener terminaciones en los diferentes dispositivos, la entidad
RFCOMM debe ser capaz de ejecutar múltiples sesiones TS07.10. Esta tarea se lleva a
cabo mediante el multiplexor de sesiones. Para ello, cada sesión es multiplexada
utilizando su propio identificador de canal, CID. La capacidad de ejecutar múltiples
sesiones es una característica opcional del protocolo RFCOMM.
63
4.
4.1. Introducción
El sistema propuesto nace como respuesta desde el mundo de las TIC (Tecnologías de
Información y las Comunicaciones) a la problemática que sufre el colectivo de
discapacitados visuales, para quienes es imposible recibir la enorme cantidad de
información visual existente en la sociedad actual, en la que se han hecho enormes
esfuerzos de integración de los diferentes colectivos de discapacitados, pero en la que
aún persiste un gran vacío. El sistema ofrece soluciones para hacer llegar información
disponible habitualmente en forma visual (nombres de calles, carteles en
establecimientos públicos y privados, tablones de anuncios, directorios, advertencias
de obras, semáforos, estado de ascensores, delimitadores como el de carril bici,
pantallas con horarios de llegadas y salidas, etc.) a personas con discapacidad visual,
evitando la discriminación que este colectivo sufre respecto a la situación descrita
anteriormente.
El sistema ofrece una solución tecnológica para conseguir que la información visual
disponible llegue de manera precisa hasta un usuario con discapacidad visual, para que
éste pueda interpretarla y usarla en su beneficio, haciéndole la vida un poco más
sencilla e independiente.
El sistema proporciona información contextual a los usuarios con discapacidad visual y
permite la exploración de un lugar desconocido o poco habitual del usuario mediante
la descripción del mismo, incrementando la independencia y autonomía de los
usuarios. El sistema le permite conocer el entorno donde se encuentra y las diferentes
rutas que puede tomar para desplazarse, mediante locuciones. Durante el recorrido el
usuario irá recibiendo información acerca de negocios, paradas de autobuses y sitios
de interés, que le permitirán ubicarse en su mapa mental [30] ajustado a la realidad y
obtener así un desplazamiento más tranquilo y seguro.
4.2. Servicios
El sistema brinda cuatro tipos de información que son: informaciones contextuales,
información de localización, información de orientación y, por último, alertas sobre
64
peligros potenciales. Como cada tipo de información o servicio está asociado a un tipo
de acción determinada, los tipos de información que brinda el sistema se llaman
servicios.
4.2.1. Servicio de información
El servicio de información es el servicio más genérico del sistema y suministra al
usuario toda información contextual que pueda necesitar a medida que va avanzando
por su recorrido. El usuario puede navegar por la información suministrada hasta
encontrar la opción que desee. Algunos ejemplos son: el nombre de una calle, la
descripción de un objeto en un museo, la identificación de un edificio, información
comercial o turística, carta de un restaurante, señales informativas, información sobre
pasos peatonales, etc.
4.2.2. Servicio de orientación
En lo que respecta a la orientación, las personas con discapacidad visual sólo necesitan
simples instrucciones textuales [31], tales como “siga recto 15 metros y luego tome el
pasillo a la derecha”. Gracias a las habilidades obtenidas de los instructores de
orientación y movilidad (O&M, Orientation and Mobility) es fácil para los
discapacitados visuales seguir curvas con sus bastones y utilizar el ruido proveniente
del tránsito para mantener una dirección constante en las aceras. Por todo ello, el
servicio de orientación brindará cortos mensajes con directivas direccionales que
permitirán a los usuarios encaminarse hacia un lugar en concreto.
Se definen tres tipos de posibles rutas por las que puede transitar un usuario y estas
son:
Rutas con caminos definidos: los caminos definidos son todos aquellos por
donde un usuario puede transitar y quedan determinados por la dirección hacia
donde van andando. Son caminos que obligan al usuario a seguir una
determinada ruta, unívoca, y sólo se necesita de la dirección de circulación para
poder orientarlo.
Rutas sin caminos definidos: Son los contrarios a los anteriores, en los que no
se puede dar indicaciones unívocas. Para solventar este tipo de incertidumbre
se recurre al uso de marcas. Una marca es una indicación del camino que ha
tomado el usuario con el fin de averiguar el camino que ha transitado para
llegar hasta un punto concreto. Para este caso en concreto las marcas serán las
direcciones Bluetooth de los balizas de localización.
Rutas mixtas: es cuando se mezclan los dos tipos de rutas mencionados
anteriormente.
65
En la Figura 4.1 se pueden ver los distintos tipos de rutas mencionadas más arriba. La
ruta C es una ruta definida y las rutas A y B son caminos sin rutas definidas. Nótese que
si un usuario llega a la baliza principal desde C, no habrá confusión alguna con respecto
a las orientaciones que ésta le pueda brindar pero si lo hace desde los caminos A o B,
la baliza principal tiene que saber por cual camino ha llegado el usuario a fin de poder
indicarle exactamente la dirección a tomar.
A B
C
Baliza principal
Baliza de localización
Figura 4.1. Ejemplos de tipos de rutas.
Al colocar dos balizas de localización, uno en la ruta A y otro en la B, ya seremos
capaces de discernir el camino tomado por el usuario y guiarlo de forma correcta a su
destino.
4.2.3. Servicio de localización
El servicio de localización se encarga de dar un aviso sonoro, puntualizando el sitio,
lugar o cosa que el usuario está buscando. Por ejemplo, si un usuario está buscando el
despacho de una persona en concreto, selecciona la opción de localización y cuando
llegue al sitio, la baliza asociada empezará a emitir un sonido (pitidos) para que el
usuario pueda localizar con exactitud el lugar que está buscando.
4.2.4. Servicio de alerta
El servicio de alerta se aplica a las situaciones en las cuales el usuario puede estar en
peligro, tales como cercanías de escaleras, zanjas, pisos mojados o armarios con alta
tensión. Cuando un usuario se acerca a un sitio con algún servicio de alerta activo, se le
comunicará del peligro y se le dará las indicaciones de cómo retirarse de forma segura
66
del lugar. Los avisos de alerta son prioritarios y en ningún caso se pueden dejar de
escuchar.
4.3. Hardware del sistema
El sistema está compuesto fundamentalmente de tres elementos electrónicos, dos
fijos que denominamos baliza principal y baliza de localización, y uno móvil que lleva el
usuario del sistema. Las características principales de cada elemento son:
Baliza Principal (BP): elemento fijo que está concebido para ofrecer la
información que el usuario pueda necesitar, a fin de satisfacer sus necesidades.
Almacena la información en modo texto y la envía al receptor cuando este lo
requiere. Tiene capacidad para procesar peticiones, almacenar información y
enviar información vía enlaces inalámbricos Bluetooth. También se puede
configurar el rango de cobertura.
Baliza de localización (BL): elemento fijo más simple que la baliza principal,
utilizado para ofrecer al usuario informaciones elementales, facilitar el servicio
de localización y ayudar al sistema a atender el servicio de orientación. Su
alcance es configurable y habitualmente inferior al de un NP.
Móvil (M): elemento móvil que tiene el usuario y que interactúa con él. Es el
lazarillo que le va indicando de todo lo pertinente a su paso. Es totalmente
configurable y está pensado para que sea amigable con el usuario, además de
discreto.
Las balizas servidores, intercambian información con los elementos móviles que se
muestren interesados en la información que estos brindan y están en su rango de
cobertura. Se colocan en los lugares donde se expone una información escrita con el
fin de suministrar la información equivalente a personas con discapacidad visual. La
posibilidad de configurar el alcance de cada baliza obedece a la necesidad de una
mejor adecuación funcional para los distintos tipos de lugares donde se podría instalar
el sistema, ya que no es lo mismo informar en el vestíbulo de una estación de trenes
que en los pasillos de un edificio.
Una característica fundamental del sistema es su capacidad para cubrir un número
muy importante de aplicaciones. Este hecho, el de ser una solución genérica, es una
de sus claves y la diferencia fundamental con otros sistemas.
4.4. Software del sistema
Desde un punto de vista software, la filosofía de funcionamiento del sistema es
análoga a la de los navegadores y servidores web. El elemento móvil es el cliente que
67
solicita páginas, de donde extrae la información, y el elemento fijo es el servidor que
satisface dichas peticiones de páginas. La baliza principal, entonces, debe estar a la
escucha de peticiones de páginas provenientes de los móviles y debe incluir toda la
lógica necesaria para recibir dichas peticiones y servirlas en un tiempo razonable, de lo
contrario el usuario podría salirse del alcance o bien la información ya podría ser
errónea.
Las balizas están concebidas para ofrecer toda la información que el usuario pudiera
necesitar, a fin de satisfacer las necesidades de los usuarios. Para ello, las balizas
principales transmiten la información almacenada en modo texto a los clientes,
mediante enlaces inalámbricos Bluetooth. Las balizas principales tienen, por lo tanto,
capacidad para procesar y almacenar información. Para almacenar eficientemente la
información, se incorporará en las balizas principales, un servidor web que permitirá al
cliente seleccionar específicamente qué información recibir, ya que ésta estará
separada en distintas páginas web según se necesite.
El software de la baliza de localización es más simple que el de los principales pero
cumple con otras funciones, tales como localizar sitios de interés y dejar un rastro en la
memoria del dispositivo móvil como se vio anteriormente.
El elemento móvil que lleva el usuario es el encargado de pedir las informaciones
concernientes a cada lugar, procesarlas y desplegarlas al usuario. El móvil recibe la
información como texto en archivos XML y para presentarla al usuario se necesita
convertirla en audio.
Para ofrecer los servicios del sistema, se instalan las balizas principales con rango de
alcance Bluetooth programado de manera que cubran el área a la que se desea dar
servicio. Estas balizas contienen la información que se ofrece al usuario que maneja el
dispositivo móvil. Las balizas están constantemente buscando a los móviles, una vez
encontrados, se inicia una negociación entre ellos para verificar si el usuario tiene
interés en una información en concreto. Si la tiene, la información se envía
automáticamente al móvil y se reproduce al usuario. Si no, se alerta al usuario que está
en la zona de cobertura del sistema y se le despliegan un menú sonoro, indicando las
opciones que tiene configurado en ese lugar.
Una vez reconocido el móvil en el sistema, se puede solicitar más información a la
baliza principal, basándose en los menús y submenús que se le ha entregado
inicialmente. También puede solicitar localización de puntos de interés en el área de
servicio del sistema o la orientación hacia un punto en concreto. En la baliza, principal
o secundario, puede estar asociado al punto de interés que desea localizar el usuario,
en este caso, se generará un aviso o mensaje sonoro que ayudará al usuario a la
localización del punto.
68
La interacción con las balizas de localización es similar a la que se experimenta con las
balizas principales, sólo que la información almacenada en éstos es mucho menor y no
se despliega un menú al usuario. Siempre se guarda el rastro por donde ha pasado el
usuario y, si se asocia con un lugar y es el sitio que el usuario efectivamente buscando
está, se activa la señal sonora que indica el lugar encontrado.
4.5. Particularidades del sistema propuesto
Un punto a discutir es qué elemento se encarga de realizar la búsqueda de
dispositivos. Parecería lógico que el dispositivo móvil vaya buscando a los servidores,
según el usuario se desplace de un sitio a otro, y el propio dispositivo le vaya
informando sobre las balizas que encuentra en su camino. Otro enfoque sería que las
balizas estén continuamente a la búsqueda de los clientes que entren a su alcance. En
lo referente al software, el hecho de buscar dispositivos supone una sobrecarga de
procesamiento, ya que se deben mantener en una lista de los elementos encontrados
que permita discriminar, de alguna manera, a los nuevos dispositivos que requieren
atención; además, supone un gasto de energía. Para permitir mayor autonomía a los
móviles, se ha decidido que la búsqueda sea realizada por las balizas, ya que estar
continuamente a la búsqueda de clientes supone el consumo de recursos, tanto de
procesamiento como de energía [32], lo que disminuye la autonomía de los mismos.
El proceso de descubrimiento en la especificación Bluetooth es fundamental en el
establecimiento de la comunicación. Este proceso se divide en tres fases [33]:
En la primera fase, el dispositivo que inicializa la comunicación (que se
denomina master en la norma) busca dispositivos a su alrededor. El master se
encuentra en el estado Inquiry durante esta fase, mientras que los dispositivos
vecinos que estén a la escucha (slaves o esclavos según la norma) se deben
encontrar en el estado Inquiry Scan.
A la fase anterior, le sigue el proceso denominado paging en el que ambos
dispositivos, master y slave, realizan un handshaking, o comunicación con
acuse de recibo, mediante el cual intercambian información fundamental para
la formación del enlace.
La última fase consiste en el establecimiento del enlace físico.
Una importante cuestión a tener en cuenta en el establecimiento de un enlace
inalámbrico de tipo Bluetooth, es que si los dispositivos conocen sobre la existencia de
otros en su rango de cobertura, esto no implica que exista ningún tipo de enlace entre
ellos. Por otro lado, el proceso de descubrimiento se encuentra totalmente
enmascarado en la comunicaciones ordinarias que se realizan hoy en día con
dispositivos de uso común, como son los teléfonos móviles y ordenadores, pero
cuando se requiere una respuesta rápida o con requerimientos de tiempo específicos,
69
es necesario tener un mayor control sobre los parámetros que intervienen en el
proceso de descubrimiento. La componente aleatoria en el proceso de descubrimiento
es elevada [34, 35], requiriendo este estudio de un análisis estadístico complejo [36].
Existen muchos estudios acerca de cómo acelerar el proceso de descubrimiento
empleando la norma Bluetooth, [37, 38, 39], y en la actualidad se está estudiando la
introducción de nuevas tecnologías, mecanismos fuera de banda, para intentar
mejorar este proceso de descubrimiento y emparejamiento. En concreto, y a partir de
la especificación Bluetooth 2.1, se incluye la tecnología NFC como forma de
intercambiar información de emparejamiento.
Ahora bien, una vez establecida una conexión Bluetooth, existen una importante
variedad de parámetros relacionados con la calidad de la transmisión, por lo que llegar
a concluir cómo es esta calidad resulta una tarea complicada, especialmente por la
cantidad de variables que intervienen, algunas muy difíciles de controlar debido a su
componente aleatorio como se puede observar en los modelos de propagación de la
señal que se suelen utilizar [40, 41]. Muchas de estas variables dependen del
dispositivo particular y de su diseño particular, lo que nos lleva por ejemplo al tipo y
comportamiento de los amplificadores internos o las antenas [41].
Otro punto importante a tener en cuenta es la coexistencia del sistema con otros
dispositivos Bluetooth que no son del sistema. Una de las razones para la utilización
del estándar Bluetooth es la gran aceptación y expansión que ha tenido en el mercado;
y prueba de ello es el creciente número de teléfonos móviles y ordenadores portátiles
que traen incorporados este estándar. Ahora bien, se debería tener en cuenta qué
pasaría en un escenario en el cual pasa un gran número de personas con sus teléfonos
móviles y ordenadores portátiles. Por ejemplo, si se instala el sistema en un
aeropuerto, es muy probable que se tengan muchos dispositivos Bluetooth encendidos
que nada tienen que ver con la plataforma. ¿Afecta esa situación al sistema?
Dada esta situación, se hace imperiosa la necesidad de un mecanismo de
discriminación de esos dispositivos y por fortuna, el estándar Bluetooth nos da la
solución. Se utiliza el código de acceso mencionado en el capítulo 3, sección 3.3.2.1 de
la siguiente manera. Cambiando convenientemente el código de acceso, al hacer la
búsqueda de dispositivos se consigue que sólo respondan los dispositivos que tengan
ese código de acceso específico, eliminando así a todos los dispositivos que no son del
sistema. En cuanto a la visibilidad de los elementos de la plataforma se pueden utilizar
dos opciones del estándar Bluetooth [29]; los estados Inquiry Scan y Page Scan. Lo que
permite optar por cuatro posibilidades, mostradas en la Tabla 4.1.
Entonces, para que las balizas del sistema no sean descubiertos y pasen desapercibidos
por otros dispositivos que no pertenezcan al sistema, se desactiva el estado Inquiry
70
Scan, dejándolo totalmente oculto para procesos de detección, y para que los
elementos puedan comunicarse, se deja activo el estado Page Scan. En los dispositivos
móviles se dejan activos ambos estados ya que los servidores son quienes están a la
búsqueda de los dispositivos móviles o clientes.
Inquiry Scan
Page Scan
Interpretación
ON ON El dispositivo local es detectable por otros dispositivos Bluetooth y acepta peticiones de conexión entrantes. Es el estado por defecto de los dispositivos
OFF ON Aunque no es detectable por otros dispositivos Bluetooth, el dispositivo acepta peticiones de conexión entrantes
ON OFF El dispositivo local es detectable por otros dispositivos Bluetooth pero no acepta las conexiones entrantes
OFF OFF El dispositivo no es detectable por otros dispositivos y no acepta conexiones entrantes, usado en dispositivos que sólo realizan conexiones salientes
Tabla 4.1. Interpretación de los estados Inquiry Scan y Page Scan.
La topología de red definida en la norma Bluetooth impone una cantidad máxima de
dispositivos que puede tener una piconet, que es hasta siete dispositivos esclavos
activos y hasta doscientos cincuenta y cinco dispositivos aparcados (modo park).
Entonces, como limitación, sólo podremos tener siete usuarios activos al mismo
tiempo en un servidor. Una manera de mejorar dicha limitación es pasar al modo
aparcado los clientes que no estén realizando pedidos de páginas, dejando lugar a
nuevos usuarios pero esto implica un grave problema: luego de unas pruebas se ha
constatado que existe la posibilidad de que el dispositivo aparcado salga del área de
influencia del dispositivo que lo aparcó, sin que éste lo haya sacado de ese modo,
entonces se encontrará “invisible” para los demás dispositivos del sistema, quedando
permanentemente incomunicado. Por esta razón se ha decidido descartar el uso del
modo park en la plataforma.
En la norma Bluetooth se define la función Hci_Inquiry para buscar dispositivos
cercanos. Este comando hará que el dispositivo entre al modo de búsqueda de
dispositivos cercanos por medio de los paquetes de encuesta anteriormente
mencionados. El primer parámetro, LAP, es el código de acceso al cual deben
responder los dispositivos. El segundo parámetro, LEN, especifica la duración total del
modo de búsqueda y cuando este tiempo expira, la búsqueda se detiene. El siguiente
parámetro es la cantidad de respuestas que pueden ser recibidas antes que se detenga
el ciclo de búsqueda. Los parámetros involucrados en el ciclo de búsqueda se resumen
en la Tabla 4.2.
71
Parámetro Valor Descripción
LAP 0x9E8B00 – 0x9E8B3F Es el LAP de donde se derivan los códigos de acceso
LEN Tiempo = LEN * 1,28 s Siendo, 1 < LEN < 30
Cantidad de tiempo del ciclo de búsqueda, este puede ser de 1,28 segundos hasta 38,40 segundos
Num_Resp 1 – 255 Número máximo de respuestas esperadas de dispositivos
Tabla 4.2. Parámetros involucrados en la búsqueda de dispositivos.
Para hacer que los elementos del sistema sólo respondan a un determinado código de
acceso, se ha modificado el LAP. Para establecer el campo LEN, que es el tiempo de
búsqueda, se han hecho numerosas pruebas a fin de determinar cuál es la
combinación, dando LEN = 3 un mejor comportamiento. Por último, el número máximo
de respuestas es un campo variable en función al sitio en concreto donde se instala el
sistema. Es las pruebas realizadas se han configurado en el valor máximo.
72
5.
5.1. Introducción
Según vimos anteriormente en la sección 4.3 el sistema cuenta con tres elementos
hardware, dos fijos y uno móvil. Toda la información visual existente deberá ser
recopilada y almacenada por las balizas del sistema y es transmitida a los elementos
móviles, que reproducen la información al discapacitado, permitiéndole el acceso a la
información. Esta información se envía de manera inalámbrica al dispositivo móvil,
mediante enlaces Bluetooth. A continuación se describen brevemente los elementos
hardware del sistema y se discuten las opciones escogidas.
5.2. Baliza principal
En esta sección se verán las necesidades del hardware de la baliza principal del
sistema, se describirán las opciones que se han valorado y se justificará la selección
final. Durante la fase de selección de la tarjeta CPU se evaluaron múltiples alternativas,
aunque algunas fueron descartándose debido a cambios en los requisitos del sistema
durante esta fase. Así, por ejemplo, se evaluaron tarjetas basadas en PC industriales
con una buena integración de periféricos, tamaño reducido y bajo coste. Finalmente,
dada la necesidad de implantar un sistema operativo, la búsqueda se centró en
tarjetas CPU comerciales tipo PC/104 que estuvieran dotadas de suficiente memoria y
velocidad de procesamiento, atendiendo las siguientes características:
Arquitectura del procesador conocida (x86 o ARM).
Velocidad del procesador.
Puerto Ethernet.
Capacidad de expansión de memoria (RAM, Flash, etc.).
Dimensiones reducidas.
Soporte de sistemas operativos conocidos.
A continuación, se listan tres de las opciones que se han estudiado.
73
5.2.1. Beagle Board
Beagle Board [42] es un proyecto que ha desarrollado una computadora en tarjeta de
bajo coste y consumo, desarrollada por un pequeño grupo de ingenieros de Texas
Instruments y Digi-Key. El corazón de la tarjeta es su procesador OMAP3530 (de
Texas), de núcleo ARM8 que admite varios sistemas operativos. Sus principales
características son:
Procesador OMAP3530 de 600MHz.
Procesador de gráficos integrado.
Memoria: RAM de 256 MB y Flash de 256 MB.
DVI-D, S-Video.
Puertos: USB, RS 232, I2C, SPI y JTAG.
Entrada/salida de audio.
Sistemas operativos: Win CE, Android, Angstrom, Ubuntu, Gentoo, Maemo y
una versión de RISC OS 5.
Consumo: hasta 2W.
Figura 5.1. Fotografía del Beagle Board.
Esta tarjeta posee muy buenas prestaciones pero toda la parte gráfica no será utilizada
en el sistema. En la figura 5.1 se muestra una fotografía de la Beagle Board.
Cabe mencionar que tiene una wiki muy completa con muchos ejemplos y datos
técnicos.
5.2.2. MOPS-PM
MOPS-PM [43] es una computadora en tarjeta, que cumple con el estándar PC/104. Se
basa en un procesador Intel y fabricado por Kontron.
74
Las principales características son:
Procesador Intel Pentium o Celeron con velocidades de hasta 1,4 GHz.
Puertos: COM, USB 2.0, LAN, LPT y VGA.
Cache L2 (512KB a 2MB).
Opción para teclado y mouse PS/2.
Consumo: 5W.
Figura 5.2. Fotografía del MOPS-PM.
En la figura 5.2 se puede observar una tarjeta MOPS-PM. Esta tarjeta tiene muy buenas
características pero no tiene soporte para audio, necesita de un complemento lo que
significa un aumento en las dimensiones del dispositivo fijo y a su vez, aumenta el
costo del mismo.
5.2.3. PM-LX y PM-GX
Las PM-LX y PM-GX [44] son computadores en tarjeta que cumplen con la norma
PC/104. Tienen procesadores AMD y son fabricadas por IEI Technology.
Figura 5.3. Fotografía del PM-LX (izquierda) y PM-G (derecha).
75
Las características principales son las siguientes:
Procesadores AMD GX466 de 333MHz o LX800 de 500MHz
Puertos: COM, USB 2.0, LAN, LPT y VGA.
Memoria RAM DDR, hasta 1 GB.
Ethernet 10/100 Mbps.
Interfaces: USB 2.0, LPT, RS-232, RS-422/RS-485 y PS/2.
Ranura para memoria Compact Flash.
VGA integrada.
Consumo entre 5,0 y 5,5 W.
5.3. Comparación entre alternativas de elementos fijos
En los casos estudiados, la arquitectura interna de los procesadores es similar a las x86
desde el punto de vista de la instalación de un sistema operativo; salvo la Beagle Board
que es de núcleo ARM.
En la tabla 5.1 se muestran los precios de las opciones barajadas.
Precio de las opciones para la baliza principal (Euros)
Beagle Board MOPS-PM PM-LX PM-GX 149 78 228 159
Tabla 5.1. Comparativa de precios entre los sistemas considerados.
Las características de todas las tarjetas son parecidas, pero finalmente se decide
emplear la tarjeta MOPS-PM de Kontron por los siguientes motivos:
Velocidad de procesamiento bastante buena y capacidad de manejar grandes
cantidades de memoria.
Incorpora un procesador Intel, el cual alcanza temperaturas considerablemente
más bajas que sus homólogas AMD.
El precio es el más bajo.
5.4. Baliza de localización
La baliza de localización se corresponde con un sistema microcontrolador de bajo
coste cuya tarea radica en realizar continuamente procesos de descubrimiento para
encontrar a los usuarios que están en su rango de cobertura.
En la Figura 5.4 se puede observar un diagrama de bloques de los distintos
componentes que forman la baliza de localización. En él se puede comprobar que se
han utilizado los componentes básicos para dotar de funcionalidad a la baliza de
localización. La inclusión del zumbador, así como del puerto de entradas y salidas
76
digitales, se ha hecho para poder dotar de una finalidad secundaria a la baliza de
localización. Un ejemplo de esta podría ser la activación del zumbador al detectar que
el usuario quiere localizar un sitio en concreto donde éste se encuentre.
Figura 5.4. Diagrama de bloques de la baliza de localización.
5.4.1. Microcontrolador ATMEGA 8
El ATMEGA8 es un microcontrolador de 8 bits de bajo consumo realizado en tecnología
CMOS y basado en la arquitectura AVR RISC. Además, al ser capaz de ejecutar
instrucciones en un solo ciclo de reloj, logra un rendimiento cercano a 1 MIPS por MHz,
lo que permite optimizar el consumo de energía frente a la velocidad de
procesamiento.
Las principales características que posee son:
Arquitectura RISC.
Memoria:
o 8 KB de memoria Flash para programa
o 512 B de EEPROM.
o 1 MB de RAM interna
Periféricos:
o 2 temporizadores/contadores de 8 bits.
o 1 temporizador/contador de 16 bits.
o Contador de tiempo real con oscilador externo.
o 3 canales PWM.
77
o 6 canales ADC de 10 bits.
o Temporizador Watchdog con oscilador separado
o Comparador analógico.
Interfaz de conexión:
o 23 puertos de entradas/salidas digitales.
o I2C.
o USART programable.
o SPI maestro/esclavo.
Características especiales:
o Power-on-Reset.
o Oscilador interno RC que puede ser calibrado.
o 5 modos de funcionamiento.
78
Figura 5.5. Diagramas de bloque del ATMEGA8.
5.4.2. Módulo Bluetooth Bluegiga WT12
El Bluegiga WT12 es un módulo Bluetooth que cumple con la versión de la
especificación 2.1. Contiene todo lo necesario para poder implementar una
comunicación Bluetooth: interfaz radio, antena y la torre de protocolos Bluetooth
completa. Su principal función será la de iniciar procesos de descubrimientos
detectando el objetivo a localizar así como a los diversas balizas de localización que
puedan existir en su rango de cobertura.
79
Las principales características del módulo son:
Rango hasta 300 metros.
Antena integrada o conector UFL.
Tasa de transmisión de hasta 3 Mbps.
Cumple RoHS.
Soporte Scatternet.
USB interface (2.0 compatible).
Soporte 802.11.
Memoria Flash 8Mb.
UART con modo bypass.
Figura 5.6. Ubicación de iWrap en la torre de protocolos Bluetooth.
Otra de las características de este módulo, es que está equipado con un firmware
propietario denominado iWrap que permite abstraer al usuario de la torre de
protocolos Bluetooth. De esta forma, a través de comandos ASCII se pueden efectuar
tareas tales como descubrir dispositivos, establecer una comunicación a nivel
RFCOMM o configurar aspectos como el código de acceso de descubrimiento o IAC.
Con esta solución, se evita el usar un microprocesador que actúe de host para correr la
pila de protocolos
Dicha pila posee compatibilidad con los siguientes perfiles Bluetooth:
80
A2DP: modo fuente y sumidero.
AVRCP.
Identificación de dispositivo.
Puerto Serie, soportando los dos tipos de dispositivos.
Manos libres.
DUN.
OPP.
FTP y PBAP.
HDP y SSP.
5.4.3. Configuración del módulo
Para poder llevar a cabo una correcta comunicación, es necesario configurar el módulo
Bluetooth correctamente. Para ello, será necesario enviarle una serie de comandos
para su correcta configuración.
El primer comando que se deberá enviar al módulo será “SET CONTROL MUX 1\n”,
éste permite utilizar un modo de funcionamiento especial del módulo WT-12A que se
caracteriza por no hacer distinción entre el modo comandos y el modo datos que
utiliza el iWRAP. La ventaja de este modo es que permite mantener dos o más
conexiones simultáneas con diferentes dispositivos de un modo sencillo. Para su
correcto funcionamiento, es necesario utilizar el siguiente formato de trama mostrado
en la Tabla 5.2.
Longitud [bits] Nombre Descripción Valor
8 SOF Comienzo de trama 0xBF
8 LINK Identificador del enlace Enlace de datos: 0x00-0x08
Enlace de control: 0xFF 6 FLAGS Banderas de la trama 0x00
10 LENGTH Tamaño del campo de datos - 0-800 DATA Datos -
8 nLINK Final de la trama {{LINK} XOR 0xFF}
Tabla 5.2. Formato de trama en el modo multiplexado.
Como se puede observar en la Tabla 5.2, todos los comandos que vayan desde el
equipo que actúe como host hacia el módulo, deberán enviarse con el formato de
trama descrito. Por su parte, la respuesta a los diferentes comandos así como los datos
recibidos desde uno o varios equipos remotos, serán enviados con el mismo formato
de trama.
81
La ventaja del modo multiplexado es que no se necesita hacer un intercambio especial
entre el modo comando y el modo datos, sino que todos los datos y comandos son
transmitidos del mismo modo. Esto permite un gran ahorro de tiempo en escenarios
multipuntos, donde, en el peor de los casos, un cambio de modo podría tardar hasta
dos segundos. También supone una gran ventaja en escenarios donde existen muchas
conexiones activas recibiendo datos simultáneamente. En estas situaciones, el cambio
de modo puede resultar en la pérdida de datos debido al coste de tiempo que supone.
Figura 5.7.Comunicación Host – iWRAP - Host.
Figura 5.8. Comunicación Host - iWRAP - Dispositivo remoto y viceversa.
El resto de comandos de inicialización deberán enviarse a la pila de protocolos iWRAP
con el formato del modo multiplexado y se corresponderán con:
"SET BT LAP 9e8b05": este comando permite modificar el valor del IAC,
estableciendo un valor reservado para así garantizar que el funcionamiento del
sistema no interfiere con el resto de dispositivos Bluetooth existentes en la
sala. Además permite establecer un nivel de seguridad mayor, debido a que al
colocar un código de descubrimiento limitado, las balizas principales y
secundarias no podrán ser descubiertos por el resto de terminales, salvo que
estos efectúen un descubrimiento con dicho valor.
"SET BT PAGEMODE 3 1000 0": mediante esta orden, se configura el módulo
Bluetooth como visible y conectable. Además, se indica que el valor del
82
temporizador asociado a un error en el establecimiento de una conexión sea de
2,56 segundos.
“SET BT POWER 3 3 3": fija el nivel de potencia en el proceso de
descubrimiento a 3 dBm, que se corresponde con el máximo posible. De esta
forma, se asegura que se puede cubrir el máximo rango de espacio, lo que
posibilitará espaciar las balizas de localización una mayor cantidad.
"SET CONTROL CONFIG 0 001F": Este comando establece el modo entrelazado
de descubrimiento y de establecimiento de conexión, permitiendo una mayor
efectividad a la hora de buscar a los usuarios.
"SET CONTROL ECHO 4": permite eliminar el “echo” generado por el software
iWRAP al enviarle un comando a través del puerto serie.
Finalmente, mencionar que la comunicación con el microcontrolador se efectuará a
través de un puerto USART, utilizando una velocidad de 115200 bps y un formato de
comunicación 8N1, es decir, 8 bits, sin paridad y un bit de parada.
5.5. Hardware del móvil
En cuanto al dispositivo móvil se ha pensado en utilizar teléfonos móviles comerciales
(Nokia, Sony-Ericsson, Motorola, etc.) ya que están ampliamente distribuidos en el
mercado. El problema encontrado es la compatibilidad del software a desarrollar, ya
que las distintas marcas poseen distintos sistemas operativos (por citar algunos:
Symbian de Nokia, Sony-Ericsson y Motorola, SX1 de Siemens, SGH-x de Samsung y, en
los móviles nuevos, Android). Además de la pluralidad de opciones, otro aspecto a
tener en cuenta es que son sistemas operativos bajo licencia.
Una alternativa encontrada fue la de utilizar un dispositivo móvil con software libre. Se
han analizado tres opciones que se muestran más abajo.
5.5.1. Openmoko
Openmoko (OM) es un proyecto de software y hardware abierto e intenta crear el
primer sistema operativo libre para teléfonos móviles, permitiendo al usuario
personalizar totalmente el terminal para satisfacer sus necesidades [45].
Tiene como características: microprocesador Samsung S3C2442B, de arquitectura
ARM920T. Este tipo de arquitecturas (ARM9x) se están implantando rápidamente en
los sistemas empotrados y móviles de comunicaciones debido a su elevada potencia de
cálculo, su bajo consumo y el bajo coste de desarrollo que presenta. Por otro lado, el
uso del mismo supone que, a la hora de compilar los códigos fuentes de los programas
a ejecutar en esta plataforma, se deba hacer uso de compiladores cruzados para poder
obtener un ejecutable válido para el procesador en cuestión. Posee además de dos
83
acelerómetros, conectividad GPRS, GSM, Bluetooth con chipset CSR BlueCore 4,
802.11g y GPS, entre otras.
Figura 5.9. Openmoko, versiones Neo 1973 y Neo FreeRunner.
El sistema operativo que gobierna Openmoko se basa en una distribución de Linux
para dispositivos móviles con un kernel 2.6.24. Tiene al menos tres distribuciones
oficiales (OM 2007.2, OM 2008 y OM 2009) y otras de la comunidad OM, que se
detallarán más adelante.
5.5.2. nanoLiab
El proyecto Liab (Linux in a box) [46] se inició en el verano de 1998 en el Instituto de
Sistemas Electromagnéticos de la Universidad Técnica de Dinamarca, DTU. El objetivo
era desarrollar una pequeña plataforma con un microprocesador para realizar tareas
de control y adquisición de datos en relación con un dispositivo de medición de
antenas. El prototipo y la primera generación del LIAB se desarrollaron en DTU. Luego
lo desarrolla una empresa privada, llamada LIAB ApS. Las partes del hardware y el
software gestor de arranque son copyright de LIAB ApS. Sin embargo, la mayoría del
software es de fuente abierta. En la Figura 5.10 se ve una fotografía de la placa.
Sus principales características son:
Procesador ATMEL AT91RM9200 de 200 MHz.
Sistema operativo: Linux (kernel 2.6.16).
Real-Time Clock.
Memoria RAM 32 MB.
Memoria ROM/FLASH 16 MB.
Puerto Ethernet 10/100 Mbit.
84
Puerto USB 2.0 host.
Entrada/salida de audio.
Figura 5.10. Fotografía del nanoLiab.
5.5.3. Limestone
Limestone [47] es una placa base que cuenta con todas las infraestructuras básicas
necesarias para construir una computadora de mano o PDA personalizada.
Figura 5.11. Fotografía de la placa del Limestone (izquierda) y placa con carcasa y pantalla (derecha).
Se listan a continuación sus principales características:
Procesador Marvell PXA320 de 806 MHz.
Memoria RAM de 128 MB y 1GB de NAND FLASH.
Sistema operativo: Windows CE 6.0.
Ranura para memorias del tipo SD (Secure Digita).
Batería de Ion de litio e indicador de estado de la batería.
Entrada/salida de audio de 16 bits.
USB host.
Pantalla táctil.
Interfaz para teclado.
Interfaz para cámara.
Puertos: 3 UARTs, SPI, I2C, GPIO.
No incluye carcasa.
85
5.6. Comparación entre alternativas de móviles
La elección del hardware del dispositivo móvil se decantó por el Openmoko debido
fundamentalmente a la gran flexibilidad que permite al ser un proyecto abierto, tanto
software como hardware. Otra cuestión favorable es que incorpora con un sistema
operativo Linux de kernel 2.6, particularidad deseada, ya que incluye las librerías de
desarrollo Bluetooth integradas y no es necesario compilarlas para utilizarlas.
En la Tabla 5.3 se muestran los precios de las distintas alternativas para el móvil.
Precio de las opciones (Euros)
Openmoko Nanoliab Limestone
237 249 218
Tabla 5.3. Precios de las opciones de móviles.
Si bien no es la alternativa más barata, la comunidad de desarrolladores está en
continuo crecimiento, se caracteriza por ser solidaria y con aportes fructíferos, lo que
permitirá la incorporación paulatina de nuevas funcionalidades y la optimización de las
existentes.
5.7. La plataforma Openmoko
Openmoko es un proyecto de código abierto cuya intención es crear un sistema
operativo libre para teléfonos móviles. Han sido varios los terminales desarrollados por
esta plataforma, entre los que se encuentra el GTA02 o el Neo Freerunner, que es el
terminal que emplearemos para este proyecto.
El sistema operativo desarrollado por Openmoko está basado en un núcleo Linux. Las
licencias con las que son lanzados los productos de esta plataforma proporcionan a los
desarrolladores y a los usuarios libertad para realizar ligeros cambios estéticos o
transformarlo radicalmente. Más allá de liberar el software, también se facilitan los
archivos CAD bajo licencia Creative Commons, por lo que también se puede decir que
se trata de un plataforma de hardware libre. Es la filosofía de software libre la que
confiere a esta plataforma un atractivo importante desde el punto de vista del
desarrollador.
El terminal con el cual se realizan las pruebas del software desarrollado es un GTA02, o
Neo Freerunner, cuyas especificaciones son las siguientes:
Procesador ARM Samsung 2442 SoC de 400 Mhz.
Kernel Linux 2.6.
Pantalla táctil de alta resolución de 2.8 pulgadas 480 x 640 píxeles.
86
128MB de memoria SDRAM para permitir la ejecución de varias aplicaciones a
la vez.
Modulo GPS interno para programas de posicionamiento y navegación.
Bluetooth para el intercambio local de datos y USB.
WiFi 802.11 b/g para rápida transferencia de datos y navegación web.
Dos acelerómetros 3D que permiten saber la orientación para por ejemplo
cambiar a modo apaisado automáticamente.
Tribanda GSM y GPRS 850/1800/1900 Mhz para Norte América y
900/1800/1900 Mhz para el resto del mundo.
En la Figura 5.12 podemos observar la arquitectura software en la que se basa la
plataforma Openmoko. Observamos que se trata de un sistema empotrado basado en
varias capas.
Figura 5.12. Framework de la plataforma Openmoko.
En un primer nivel nos encontramos con el kernel Linux 2.6.x, el cual posee los drivers
necesarios para interactuar con el hardware presente en el dispositivo móvil, así como
las librerías estándar que contienen las APIs de Unix. Entre los servicios básicos
ofrecidos por este nivel al nivel superior podemos encontrarnos con servicios que dan
soporte a la comunicación mediante Bluetooth (bluez), servicios que dan soporte a
comunicaciones GSM (gsm 0710), servicios que dan soporte a dispositivos de audio
(gstreammer alsa), entre otros.
87
En el siguiente nivel encontramos los procesos que usan los servicios ofrecidos por el
nivel inferior. Estos procesos ofrecen al nivel superior servicios como telefonía,
configuración del dispositivo, servicios de red, localización mediante GPS, control de
eventos, sincronización temporal, etc. Los servicios ofrecidos por este nivel son
accesibles desde el nivel de aplicación gracias a que el framework dispone de un
método de comunicación de procesos denominado DBUS, el cual permite que una
aplicación pueda comunicarse con un servicio que se encuentra registrado en dicho
BUS a través de una de las interfaces accesibles de las que dispone dicho servicio.
Todos los servicios disponibles para la capa de aplicación están registrados en DBUS,
por lo que si un desarrollador desea elaborar una aplicación que, por ejemplo, necesite
usar el servicio de localización GPS, lo único que tendría que hacer es comunicarse con
el servicio que da soporte GPS a través de la interfaz de la que éste dispone en DBUS.
Por último, se nos presenta la capa de aplicación. En esta capa se encuentran las
aplicaciones basadas en librerías gráficas como GTK+, Qtopia o X11.
Para más información se puede acudir a la web de la plataforma Openmoko [45].
5.8. Hardware desarrollado
El hardware de la baliza principal, como se mostró en la sección 5.2, es un PC
industrial. Éste se asentará sobre una placa base de fabricación propia a través de la
cual se le pasará la alimentación. Esta placa base, además, se encargará de convertir
los niveles de tensión DC a los niveles adecuados, contendrá la etapa de amplificación
para el altavoz, permitirá la comunicación mediante los puertos Ethernet y serie. Por
motivos de estética y seguridad se ha colocado en una caja plástica y hecho el
mecanizado correspondiente de donde saldrán los cables de alimentación y conectores
a redes externas. Incorpora diodos LED para indicar la puesta en funcionamiento del
sistema.
En la Figura 5.13 se muestra una fotografía de la baliza principal montada en la placa
base y dispuesto en una caja. La caja es de plástico ABS (Acrilonitrilo Butadieno
Estireno), muy resistente a golpes y con protección un índice de protección (IP) 65, que
la resguarda del polvo y del agua. En el lateral sobresalen el pasamuros, donde irá el
cable de alimentación y el cable de red, y los diodos LED, que indican la puesta en
marcha del sistema.
88
Figura 5.13. Fotografía de la baliza principal.
En la Figura 5.14 se puede apreciar la baliza de localización.
Figura 5.14. Fotografía de una baliza de localización.
Po último, en la Figura 5.15 se muestra el elemento móvil, basado (como se ha
comentado anteriormente) en el dispositivo móvil denominado Openmoko.
Figura 5.15. Fotografía del elemento móvil de la plataforma.
89
6.
6.1. Introducción
Una vez hecha la elección del hardware, se pasa a describir el software
correspondiente a cada elemento del sistema. Se ven en este capítulo las necesidades
den cuanto a la programación, se describen las aplicaciones desarrolladas y se da una
esbozo de la interoperabilidad entre las distintas partes del sistema. Se empieza con la
elección del sistema operativo adoptado y luego se hablará de cada una de las partes
que componen la plataforma electrónica, mostrando diagramas del funcionamiento e
indicando las funciones principales de cada una de las partes del software para una
mejor comprensión del mismo.
6.2. Sistema operativo
Un sistema operativo se puede definir como el software de gestión del sistema [48], es
decir, como un conjunto de programas destinados a realizar diversas tareas como
puede ser la administración eficaz de los recursos de un equipo. Para la elección del
mismo se tienen dos opciones principales, optar por un software privado o por una
alternativa de código libre. Se ha optado por la segunda alternativa.
El motivo de utilizar esta última es porque al tratarse de código libre, se tienen
accesibles las fuentes tanto del kernel y de una gran variedad de aplicaciones que
ayudará al desarrollo de ésta. Por otro lado, se prevé que aparezcan más aplicaciones
que serán desarrolladas por la amplia comunidad de desarrolladores, aplicaciones que
pueden incorporarse paulatinamente al sistema. Debido a su uso generalizado, los
controladores de dispositivos para todo tipo de hardware se puede encontrar en
Internet y el entorno de programación está bien documentado, tanto en los libros
como en numerosos READMEs, FAQs y HOWTOs disponibles en Internet. Otro motivo
de peso es el costo, pero al tratarse de sistemas operativos libres, podemos hablar
sistemas operativos de costo cero.
90
Optar por sistemas operativos de código libre permitirá optimizar el rendimiento del
sistema y adaptarlo a las necesidades en todo momento. En el caso de que se hubiera
adquirido un sistema operativo propietario, se estaría restringido a las libertades
otorgadas por el fabricante del mismo. Además, sería imposible personalizar el sistema
tanto como se desease ya que al tratarse de un software cerrado, el código fuente no
es accesible y, por tanto, no se puede modificar.
Dentro de los sistemas operativos de código libre, nos centraremos en los sistemas
GNU/Linux. Actualmente, Linux es un núcleo monolítico híbrido, es decir, es una
especie de gran programa que contiene todas las herramientas necesarias para
funcionar pero que admite la carga de módulos adicionales que se instalan según
necesidades concretas. Los controladores de dispositivos y las extensiones del núcleo
normalmente se ejecutan en un espacio privilegiado conocido como ring 0, con libre
acceso al hardware, aunque algunos de estos controladores pueden ser llamados
desde el espacio de usuario. A diferencia de los núcleos monolíticos tradicionales, los
controladores de dispositivos y las extensiones al sistema operativo se pueden cargar y
descargar fácilmente como módulos, mientras el sistema continúa funcionando sin
interrupciones. También, a diferencia de los núcleos monolíticos tradicionales, los
controladores pueden ser pre-volcados bajo ciertas condiciones. Esta habilidad fue
agregada para gestionar correctamente interrupciones de hardware, y para mejorar el
soporte del multiprocesamiento simétrico.
Existe un sistema de archivos que se carga durante el arranque y que posee todos los
directorios, programas, particiones, dispositivos, etc. Una de las grandes ventajas de
este tipo de sistemas es que los periféricos se manipulan exactamente igual que un
fichero, pudiendo utilizar en la inmensa mayoría de situaciones las mismas funciones
usadas para gestionar los ficheros.
Una distribución es una variante del kernel de Linux que se enfoca a satisfacer las
necesidades de un grupo específico de usuarios. En consecuencia, cada una de las
mismas podrá incluir un número diferente de aplicaciones que le otorguen un
determinado valor añadido a dicha distribución. Un ejemplo de aplicación que no tiene
que estar presente en una distribución es un instalador gráfico, el cual facilita todo el
proceso de instalación y configuración del equipo. Las herramientas que suelen
incluirse en las distribuciones de Linux proceden de diversos proyectos de código
abierto como puede ser GNU, BSD, KDE, Mozilla, entre otros.
6.3. Distribuciones Linux
A continuación se muestran las distribuciones Linux evaluadas.
91
6.3.1. Debian
Se trata de una distribución estable, madura y popular entre la comunidad GNU/Linux.
Ofrece una herramienta de gestión de paquetes denominada APT que permite la
descarga e instalación automatizada de paquetes a través de Internet en modo
consola. A su vez, posee uno de los sistemas de repositorios con mayor cantidad de
programas. No obstante, los repositorios de Debian no dan soporte a paquetes
propietarios denominados non-free, lo que provoca que determinados paquetes deban
ser instalados desde repositorios no oficiales o bien tengan que ser compilados
manualmente. Finalmente, resulta ser una distribución muy configurable y con el
desarrollo pertinente sobre la misma puede dar lugar a un sistema rápido, fiable, muy
estable y fácil de configurar. Sin embargo, resulta ser una distribución que requiere
unos conocimientos previos considerables debido a que numerosas tareas no se
encuentran automatizadas.
Los requisitos hardware de esta distribución resultan ser de los más bajos de todas las
distribuciones. Se puede ejecutar en máquinas con al menos 32 megabytes de
memoria RAM y puede ocupar un espacio mínimo de entre 20 y 48 MB dependiendo
de la arquitectura de la plataforma en la que se instala y sin usar gestor gráfico.
Realizando la instalación de un entorno de ventanas como es GNOME, ocuparía un
máximo de 200 MB. Finalmente, uno de los mayores inconvenientes que tiene esta
distribución es que el período de actualización de la distribución estable suele ser
elevado, puesto que las aplicaciones y kernels deben pasar toda una batería de
pruebas que garanticen su estabilidad y su correcto funcionamiento. No obstante, las
versiones testing de esta distribución se actualizan semanalmente y resultan casi tan
fiables como una release version.
6.3.2. Ubuntu
Ubuntu es una distribución GNU/Linux que ofrece un sistema operativo
predominantemente enfocado a ordenadores de escritorio aunque también
proporciona soporte para servidores.
Basada en Debian GNU/Linux, Ubuntu concentra su objetivo en la facilidad de uso, la
libertad de uso, los lanzamientos regulares (cada 6 meses) y la facilidad en la
instalación. Ubuntu es patrocinado por Canonical Ltd., una empresa privada fundada y
financiada por el empresario sudafricano Mark Shuttleworth.
Desde el punto de vista de los requisitos hardware, Ubuntu posee los siguientes
requerimientos:
Procesador: 300 MHz x86.
92
Memoria RAM: 64 MB.
Disco Duro: 4GB (con swap incluida).
Placa de video VGA.
Sin embargo, para que funcione de manera más rápida y estable, se recomienda que el
equipo posea las siguientes características:
Procesador: 700 MHz x86.
Memoria RAM: 384 MB.
Disco duro: 8GB.
Tarjeta de vídeo capaz de soportar resolución de 1024x768.
Tarjeta de sonido.
Conexión a internet.
6.3.3. Fedora
Fedora es una distribución de GNU/Linux para propósitos generales basada en RPM,
que se mantiene gracias a una comunidad internacional de ingenieros, diseñadores
gráficos y usuarios que informan de fallos y prueban nuevas tecnologías. Cuenta con el
respaldo y la promoción de Red Hat.
La herramienta habitual en Fedora para interactuar con los repositorios a través de
línea de comandos se denomina Yum; así mismo existe un entorno gráfico Yum
denominado Pirut (para tareas de instalación y eliminación de paquetes) y Pup (para
tareas de actualización de paquetes).
Yum posee un front-end llamado Yumex.
6.3.4. Gentoo
Gentoo Linux es una distribución GNU/Linux orientada a usuarios con cierta
experiencia en estos sistemas operativos. Fue fundada por Daniel Robbins, basada en
la inactiva distribución llamada Enoch Linux. En el año 2002, esta última pasó a
denominarse Gentoo Linux.
La piedra angular de Gentoo es Portage, un gestor de paquetes, inspirado en los ports
BSD, escrito en Python y Bash. Portage implementa algunas características avanzadas
que no están presentes en los ports BSD: la gestión de dependencias, afinamiento
preciso de los paquetes a gusto del administrador, instalaciones falsas al estilo
OpenBSD, cajas de arena durante la compilación, desinstalación segura, perfiles de
sistema, paquetes virtuales, gestión de los ficheros de configuración y múltiples
ranuras para distintas versiones de un mismo paquete.
93
Una ventaja de Gentoo es que las versiones de software se actualizan de forma
continua, a diferencia de otras distribuciones donde los paquetes pasan meses en
comprobación. Ello permite tener un sistema con las últimas versiones de todo el
software, ideal para tareas de escritorio. Por el contrario, aunque es algo poco
habitual, a veces el uso de versiones del software insuficientemente comprobadas da
como resultado bugs que pueden suponer un riesgo para servidores de producción.
Otra desventaja de este sistema es que poner en marcha un sistema completo, o
actualizar un sistema que ha estado desatendido durante un tempo, puede requerir
una considerable cantidad de tiempo (horas o incluso días si el ordenador es muy
antiguo), mientras se descargan y compilan todos los paquetes nuevos. Aun así,
Gentoo permite por regla general una actualización sin problemas, a diferencia de
otras distribuciones donde puede llegar a resultar complicado o casi imposible. Esta
actualización también es posible a partir de binarios pre-compilados, lo que requiere
menos tiempo.
6.3.5. Damn Small Linux
Damn Small Linux es una distribución Linux Live CD funcional y completa, basada en
Knoppix y pensada para funcionar en computadoras con muy pocos recursos o
antiguos, como los procesadores Intel 80486. Su tamaño reducido (50MB) consigue
mantener la esencia de Knoppix en un completo entorno de escritorio. Gracias a su
pequeño tamaño, se puede poner dentro de una Memoria USB y arrancar con la
misma en cualquier computadora.
DSL tiene incluidos scripts para la descarga e instalación del Advanced Packaging Tool
(APT) de Debian, y Synaptic, su GUI. Adicionalmente, Damn Small Linux permite la
descarga directa de programas grandes como OpenOffice.org y el GNU Compiler
Collection (GCC), de igual manera que programas más pequeños como Xmms por
medio del sistema MyDSL, que permite a los usuarios la comodidad de una descarga e
instalación de aplicaciones en un clic.
6.3.6. LFS (Linux From Scratch)
Linux From Scratch o LFS es una colección de documentos que nos indican los pasos
para compilar una distribución GNU/Linux desde cero. El proyecto se diferencia de
otras distribuciones en que no consta de paquetes y scripts pre ensamblados para una
instalación automática del sistema, sino que sus usuarios son provistos simplemente
con paquetes de código fuente y un manual de instrucciones para el armado de un
sistema GNU/Linux propio.
94
Debido al inmenso trabajo que demanda la instalación de este sistema en comparación
a otras distribuciones, los usuarios que deciden hacer uso de LFS son principalmente
aficionados que desean aprender sobre el funcionamiento interno de un sistema
GNU/Linux y ensamblar un sistema a su medida. Linux From Scratch es también
utilizado como base de varias distribuciones, usualmente alejadas de su espíritu
original de "metadistribución".
6.4. Distribución de la baliza principal
Para la elección del sistema operativo, la principal opción sería utilizar una distribución
de GNU/Linux que cumpliese una serie de características como las detalladas a
continuación:
Facilidad de instalación.
Máxima compatibilidad con diferentes periféricos
Amplio soporte por una comunidad de desarrolladores.
Gran número de aplicaciones.
Mantenimiento continúo en el tiempo y disponibilidad de actualizaciones.
Con base en estos criterios, se ha optado por la distribución Debian Etch 4.0 porque es
la que reúne todos los requisitos citados anteriormente y en base a la gran cantidad de
soporte ofrecido a esta distribución, la gran cantidad de recursos existentes en los
repositorios oficiales de la misma y la experiencia a nivel de usuario con este sistema.
Esta distribución tiene la ventaja de permitir una instalación en modo avanzado que
consiente una personalización en gran medida. Para ello, brinda la posibilidad de
instalar únicamente el sistema base sin necesidad de tener un entorno gráfico. Esto
supone tener un sistema inicial del cual partir sin necesidad de compilar los paquetes
que componen el sistema base a mano para su posterior instalación. Esto permite
reducir los costes de tiempos de puesta en marcha del sistema y el sistema sigue
manteniendo toda la capacidad de personalización que un sistema LFS.
Si comparamos con otras distribuciones, Debian se caracteriza por tener un enorme
apoyo en la comunidad de código abierto, así como un foro en castellano especializado
en resolver dudas y bugs. A su vez, el repositorio oficial de la misma consta de más de
26000 paquetes disponibles para el usuario final, por lo que tan sólo es necesario
hacer uso del comando apt-get install en consola, o bien, mediante el programa gráfico
Synaptic, para instalar cualquier aplicación.
Por otra parte, el proceso de instalación de la misma es uno de los más depurados,
fiables y fáciles de ejecutar de la inmensa cantidad de distribuciones existentes. Esto
va a provocar que la instalación del sistema operativo en el dispositivo final sea
relativamente sencilla.
95
En cuanto a su instalación en la placa PC104, es necesario indicar que ésta puede ser
llevada a cabo de dos formas:
Mediante uso de un CD-ROM externo y conectado al puerto IDE de dicha
tarjeta.
Mediante una instalación en red.
6.5. Distribución del cliente
Hay una gran cantidad de distribuciones para el dispositivo móvil, todas disponibles en
la comunidad de desarrolladores y usuarios de los dispositivos Openmoko, llamada
Openmokowiki [49] y se pueden dividir en tres tipos de distribuciones: las oficiales, las
comunitarias y las no oficiales.
OM es el nombre que se ha dado a la distribución oficial del proyecto y hasta el
momento hay tres. Estas versiones se basan en GNU/Linux y han sido adaptadas para
que las funciones del teléfono. Las distribuciones oficiales son:
OM 2007: Distribución lanzada por el proyecto Openmoko, su desarrollo
comenzó el 26 de Julio del 2007, y actualmente ya no sigue siendo desarrollada
y fue reemplazada por OM 2008.
OM 2008: Se agrega Qtopia sobre X11 para las funciones de telefonía. Usa un
administrador de ventanas llamado Illumine y soporte para GTK+. Ha logrado
encontrar y solucionar un gran número de errores de la versión anterior.
OM 2009: Actual versión de la distribución OM, la última emisión (de testing)
fue el 16 de Junio del 2009, luego ha quedado abandonada ya que los
desarrolladores se han movido a otras distribuciones, ya que las diferencias
entre las distribuciones son mínimas. Ésta se basa en el framework FOE y Parolli
como software de administración para las comunicaciones.
6.5.1. Distribuciones comunitarias
SHR (Stable Hybrid Release): Esta distribución está enfocada a crear un sistema
operativo funcional basado en el framework de la organización
Freesmartphone y las EFL (Enlightenment Foundation Libraries).
FDOM (Fat and Dirty OpenMoko): Es una distribución más amplia que la oficial
OM que pretende demostrar las excelentes capacidades del Neo FreeRunner.
6.5.2. Distribuciones no oficiales
Entre las distribuciones no oficiales podemos encontrar las siguientes:
96
Qt Extended Improved.
Debian GNU/Linux: Debian es el sistema operativo visto anteriormente y
permite al Neo FreeRunner puede utilizar los paquetes basados en la
arquitectura ARM.
Gentoo: es posible instalar Gentoo de tres maneras, compilación cruzada,
compilación en el mismo Neo o emulación de un Neo.
Android: la empresa Koolu fue la pionera en implementar este sistema
operativo en el Neo.
Hackable:1: es una distribución comunitaria destinada a dispositivos que
pueden ser estudiados (hackeables).
neovento: distribución basada en Debian GNU/Linux destinada al Neo
Freerunner y utiliza LXDE y Zhone.
OpenWrt: Distribución destinada a sistemas embebidos.
Mer: Es una distribución basada en Maemo.
La instalación por defecto es la distribución Om 2007, que es muy simple. Según una
encuesta realizada en Agosto del 2009, la distribución más utilizada dentro de la
comunidad Openmoko es la SHR (60%), seguido de una de las distribuciones Om (15%),
Debian (6%), Hackeable:1 (6%), Qt Extended Improved (5%) y por último, la
distribución Android (4%). Los restantes (4%) utilizan alguna de las otras distribuciones
disponibles.
La distribución que se utilizará es la SHR, que permite un mejor aprovechamiento del
hardware del dispositivo, ya que en ciertas distribuciones, algunos de los componentes
hardware no funcionan correctamente y esto es muy importante a la hora de evaluar
la expansión del sistema.
6.6. Aplicaciones de la baliza principal
Teniendo en mente la filosofía de funcionamiento de la plataforma electrónica, basada
en peticiones de páginas, se pasará a describir las aplicaciones de las balizas principales
del sistema. En la Figura 6.1 se pueden ver las distintas aplicaciones desarrolladas para
las balizas principales.
La aplicación principal tiene dos funciones principales, por un lado estará buscando
nuevos clientes y, por el otro, espera peticiones de páginas por parte de los clientes,
que es donde se envían las informaciones que el usuario necesita. Para satisfacer las
peticiones de páginas cuenta con la aplicación Pasarela, que está buscando
continuamente clientes y hace de interfaz con el servidor Apache. El servidor Apache
contiene todas las páginas que el usuario pueda necesitar y se encarga de almacenar
ficheros XML.
97
PASARELA
Aplicaciónprincipal
ServidorApache
FicherosXML
Figura 6.1. Elementos software de las balizas principales del sistema.
6.6.1. Aplicación principal
La aplicación principal se encarga de la configuración del dispositivo Bluetooth,
escribiendo el código de acceso limitado y seleccionando el modo de búsqueda
entrelazado. También gestiona los datos de cada uno de los clientes vinculados al
servidor y coordina los distintos procesos que corren en el servidor, para que el
funcionamiento del mismo sea totalmente autónomo. Para conseguirlo, se divide en
dos hilos de procesamiento, utilizando sentencias de la librería OpenMP. En la Figura
6.2 se muestra cómo se distribuyen los hilos dentro de la aplicación principal.
Figura 6.2. Diagrama de las funciones de la aplicación principal.
La primera sentencia de la librería OpenMP fija el número de hilos que tendrá la
aplicación, luego se establecen las secciones a las que se le asignarán los hilos. En este
caso, se ha divido en dos secciones. Primero se tiene la sección encargada de la
búsqueda de dispositivos móviles al alcance y la segunda se encarga de la gestión de la
pasarela.
Aplicación principal () { modificar_parámetros_BT (); omp_set_num_threads (2); #pragma omp parallel sections { #pragma omp section { busca_clientes (); //Hilo de búsqueda de clientes } #pragma omp section { pasarela (); //Hilo de escucha de clientes } } }
98
6.6.2. Busca_clientes
La función busca_clientes se encarga de buscar continuamente dispositivos que estén
al alcance de las balizas principales, los encuentra y los va organizando en listas de
dispositivos para su mejor manejo. La primera lista corresponde a los dispositivos
encontrados y se actualiza cada nueva tanda de búsquedas. La segunda, es la de
dispositivos inactivos, que son aquellos que no intercambian información con los
elementos fijos pero continúan dentro del rango de alcance de éstos. En cada ciclo de
búsqueda, los clientes encontrados se introducirán en la lista de encontrados. Luego se
recorre dicha lista y la compara con la de dispositivos inactivos, actualizando ambas y
liberando la de encontrados para dar lugar a un nuevo ciclo. También detecta los
dispositivos que hayan salido del rango de cobertura del elemento fijo, comparando la
lista de dispositivos inactivos con la de encontrados y actualizando dichas listas. En la
Figura 6.3 se muestra el diagrama de la función buscar_clientes.
Figura 6.3. Diagrama de las funciones que buscan clientes.
Para cada ciclo de búsqueda se establecen dos parámetros principales, uno es el
tiempo máximo del ciclo de búsqueda y, el otro, es la máxima cantidad de respuestas
esperadas. Estos parámetros se pueden configurar según el tipo de respuesta que se
espera en cada sitio, ya que no es lo mismo el vestíbulo de una estación de trenes que
un pasillo estrecho. Para el primer caso se podría pensar en tiempos más largos, ya
que la superficie a cubrir es mayor y la probabilidad de encontrar usuarios es más alta.
Se ha visto que la eficiencia en la búsqueda se ve degradada por la cantidad de
dispositivos [50] y se han hecho pruebas para determinar el tiempo óptimo de
duración del ciclo de búsqueda. Las pruebas se muestran en el Capítulo 7.
En cuanto a los tamaños, la lista de encontrados puede albergar hasta 255 dispositivos,
máximo tamaño determinado por la norma Bluetooth en un ciclo del Inquiry y la lista
buscar_clientes () { lista_encontrados = NULL; lista_encontrados = hci_inquiry (); Mientras lista_encontrados != NULL Si lista_encontrados [i] = lista_activos Si lista_encontrados [i] = lista_inactivos avisar_cobertura (); lista_inactivo = lista_encontrado [i]; Fin Si Fin Si Fin Mientras actualizar_listas ();
}
99
de inactivos no tiene cota superior pero no se esperan muchos clientes al tratarse de
pequeñas áreas de espacio.
6.6.3. Pasarela
La pasarela es la encargada de recibir todas las peticiones de páginas de los móviles y
envía las respuestas. La pasarela está a la espera de peticiones de conexión por parte
de los clientes, escuchando un socket RFCOMM de Bluetooth. Una vez establecida la
comunicación abre otro socket, esta vez uno TCP al puerto 80, donde redirige la
petición que le llega del cliente al servidor web que contiene todas la páginas que el
usuario pueda necesitar y queda a la espera de la respuesta. Cuando recibe la
respuesta del servidor web, la envía al cliente, a través del socket Bluetooth, y da por
terminada la comunicación. De ahí viene el nombre de pasarela, por ser una interfaz
que permite peticiones/respuesta entre distintos protocolos, Bluetooth y TCP en este
caso. Esta sucesión de eventos se muestra en la figura 6.4. A la izquierda se muestran
los sockets correspondientes a la aplicación del cliente, y a la derecha, los sockets de la
pasarela del elemento fijo, que actúa como servidor [51].
Figura 6.4. Sucesión de pasos para conexión entre sockets.
El primer paso es la creación de los sockets [52], tanto del lado del cliente como del
servidor (con la directiva create). En el segundo paso, para el socket cliente es bastante
fácil, basta tan solo con especificar una dirección y un puerto al cual conectarse
(comando connect), dejando al sistema operativo a cargo de los detalles a bajo nivel.
Una vez que el socket esté conectado puede ser utilizado para trasferir datos. Los
sockets del servidor requieren un poco más de trabajo, ya que se tienen que realizar
varios pasos previos antes que pueda ser utilizado. Primero se debe asociar un socket
(mediante la directiva bind) a un recurso del adaptador Bluetooth local y el número del
puerto a utilizar. Luego, se debe cambiar al socket a modo escucha (con el comando
listen), que indica al sistema operativo que acepte peticiones de conexión entrantes.
Una vez que el socket del cliente intente conectarse al del servidor y permita la
100
transferencia de datos, el servidor debe aceptar el pedido de conexión entrante (con la
directiva accept). Luego de realizar todos los pasos descritos, la pasarela debe actuar
como cliente para transferir el pedido que le ha llegado por parte del móvil al servidor
web.
Una de las principales diferencias entre un socket de servidor y un socket de cliente es
que la aplicación del servidor, al aceptar la conexión, puede vincular ese pedido de
conexión a otro socket, dejando el socket original listo para seguir escuchando
peticiones de conexión de futuros clientes.
Cuando finaliza la transferencia de datos desde la pasarela, se da por terminada la
conexión y se espera la siguiente petición. El esquema de la pasarela se muestra en la
Figura 6.5.
Figura 6.5. Funciones en la Pasarela.
La pasarela, entonces, estará siempre a la escucha de peticiones por parte de los
clientes. Una vez recibida, la transfiere al servidor web. Luego cuando recibe los datos
del servidor los envía de vuelta al cliente. La pasarela es totalmente transparente para
los datos que pasan por ella, sólo se encarga de servir las peticiones que le llegan.
6.6.4. Servidor web
El servidor web utilizado es el Apache, por ser de código abierto y altamente
configurable. Es uno de los servidores web más utilizados en la actualidad. Fue
desarrollado y está mantenido por Apache Software Foundation [53]. Como ventajas
se tiene que permite autenticación y negociación de contenido y está disponible para
muchos sistemas operativos. Se puede ver como desventaja la carencia de interfaz
gráfica donde configurar las opciones pero, a cambio, la extensa bibliografía y recursos
electrónicos disponibles, mitigan dicha carencia.
Para satisfacer los requerimientos de la plataforma se han instalado el módulo PHP,
para dar soporte a la generación de páginas web dinámicas, y el módulo SSL, que
incrementa la seguridad del sistema. En el servidor Apache están alojadas tres páginas
PHP para solucionar distintas necesidades, éstas son:
escuchar_clientes () { escuchar_peticiones (); enviar_al_servidor_web (); esperar_respuesta_apache (); enviar_respuesta_cliente (); }
101
connect.php: se utiliza cuando un cliente es encontrado por primera vez por un
servidor. Se encarga de enviar al cliente el tipo información que ese servidor
específico tiene almacenado, dejando en manos del cliente la decisión de
realizar o no peticiones.
audio.php: cuando un cliente solicita un fichero de audio, esta función es la
encargada de serializar dicho fichero y enviarlo al cliente como respuesta.
extern.php: esta función devuelve el código fuente de cualquier página visible
desde el servidor web dentro del servidor.
6.6.5. Manejo de listas
La gestión de listas de dispositivos Bluetooth se ha implementado con listas
doblemente enlazadas, usando la librería propia LList. Esta librería dispone de los
procedimientos estándar y funciones de fácil uso para el manejo de listas en C. Esta
librería se usará para la gestión de las tres colas de dispositivos que se mencionaron
anteriormente.
6.7. Aplicaciones del elemento móvil
En esta sección se mostrarán los distintos componentes del software de los elementos
móviles de la plataforma. Se muestra un diagrama en la figura 6.6. Sobre una
aplicación principal se han desarrollado una serie de aplicaciones para el uso del
dispositivo por parte del usuario. Estas aplicaciones se ejecutarán sobre la base de un
escritorio sonoro que permitirá usar el dispositivo de manera fácil e intuitiva. Podrá
asimismo cambiar de aplicación cuando el usuario lo desee y personalizar su
dispositivo, al tener disponible todas las opciones de configuración del móvil.
Aplicaciónprincipal
Mplayer Html_get
XML Parser
TTS
Figura 6.6. Elementos software de los dispositivos móviles.
102
La base de la comunicación se encuentra en la función Html-get, encargada de tramitar
las peticiones de páginas que el usuario necesite. Luego se analiza dicha respuesta y se
determina si es texto, se procesará con el analizador XML y si es audio, el fichero será
decodificado y reproducido directamente al usuario.
6.7.1. Aplicación principal
La aplicación principal es la encargada de manejar todas las demás funciones dentro
del elemento móvil. EL dispositivo móvil, al ser descubierto por una baliza, recibe un
fichero de texto donde se anuncian todas las informaciones que éste tiene
almacenadas. De ahí, el móvil finalmente decide si le interesa o no la información
adscrita a esa baliza. En caso afirmativo, solicita la información mediante la aplicación
Html_get y posteriormente se encarga de interpretarla y reproducirla al usuario. En
caso negativo, simplemente lo ignora y queda a la escucha de otro posible servidor. En
la figura 6.7 se muestran las funciones que se realizan dentro de la aplicación principal.
Figura 6.7. Funciones en la aplicación principal del cliente.
Primeramente, la aplicación principal cambia los parámetros del adaptador Bluetooth
y luego se queda permanentemente a la escucha de los servidores que están al
alcance. Cuando un cliente entra dentro del radio de alcance de un servidor, éste le
envía en un fichero XML toda la información que tiene adscrita. El cliente es el
encargado de analizar la información que le llega del servidor, decidir si le interesa
dicha información, reproducirla al usuario y hacer las peticiones pertinentes. El primer
tipo de ficheros que intercambian los elementos del sistema es el de información en
formato texto (XML) y el dispositivo móvil es el encargado de analizarlo (parser) y
Cliente () { modificar_parámetros_BT (); Hacer siempre escuchar_servidor (); recibir_datos (); Si tipo de datos es texto analizar_XML (); Fin Si Si tipo de datos es audio decodificar_audio ();
reproducir_audio ();
Fin Si
Mientras Servidor sea válido
Html_get ();
Fin Mientras
Fin Hacer
}
103
decidir si la información le es útil. Si desea pedir más informaciones, se vale de la
función Html_get y vuelve a empezar el proceso.
6.7.2. Html_get
La aplicación Html_get es la encargada de las comunicaciones entre el dispositivo
móvil y la pasarela de las balizas principales. Realiza las peticiones de páginas que el
usuario necesita y se encarga de gestionar el análisis de las respuestas.
Los parámetros de entrada pueden variar según si la baliza principal tiene o no acceso
a Internet. Los parámetros son:
Host: Es la dirección del servidor al que queremos conectarnos. Si es un
elemento fijo sin conexión a Internet recibe la dirección del localhost
(generalmente 127.0.0.1) y si el elemento fijo tiene conexión a Internet, se pasa
la dirección del servidor al que quiere conectarse.
Página: Para ambos casos se pasará la ruta al recurso que se desea, ya sea texto
o audio.
Dirección Bluetooth: Es la dirección Bluetooth del elemento fijo al que
queremos conectarnos para recibir los ficheros.
6.7.3. Escritorio Sonoro
El Escritorio Sonoro es una aplicación análoga al escritorio de un ordenador, salvo que
todas las indicaciones serán mediante señalizaciones sonoras. Estará encargado de
interactuar con el usuario, permitiéndole ejecutar todas las aplicaciones instaladas en
el móvil. También proporcionará una interfaz para configurar y personalizar el
dispositivo.
6.7.4. Analizador XML (parser)
Esta aplicación recibe los ficheros XML y los analiza para extraer información, dando a
la aplicación principal los datos que ésta necesite para determinar si ese elemento fijo
contiene información útil o no. Para analizar los ficheros XML se ha optado por utilizar
la librería Libxml [54] de GNOME, concretamente la versión Libxml2, con soporte para
XML2.0 bajo licencia del MIT, y puesta a disposición como software libre de código
abierto.
Esta librería es nativa para C, pero incluye soporte para otros lenguajes y entornos de
desarrollo. Soporta multitud de estándares, como XML, Namespaces (XML), Base
104
(XML), RFC2396, XPath, HTML4 Parser, XInclude, XPointer, y casi la totalidad de los
estándares de la W3C referentes a desarrollo web con XML.
Mediante el uso de esta librería, se analizarán los diferentes archivos XML recibidos
por el receptor a estructuras en C, para poder analizarlas y actuar en consecuencia. El
análisis consta de tres etapas, el análisis léxico, el sintáctico y el semántico.
Análisis léxico: También conocida como etapa de scanner, en la que recibe
como entrada un fichero XML y genera una serie de tokens que sirven de
entrada para la siguiente fase del análisis. Se dice que un documento está bien
formado léxicamente, si cumple la normativa de generación de documentos
XML, tales como las de abrir y cerrar etiquetas, especificación de atributos,
variables o propiedades, etc.
Análisis sintáctico: El siguiente estado es el análisis sintáctico, donde se
comprueban que los tokens generados en la fase anterior, forman una
expresión válida. Esto se realiza usando una gramática libre de contexto, que
define recursivamente componentes que pueden aparecer en una expresión y
el orden en que estos deben aparecer. Un documento está bien formado
sintácticamente si cumple la estructura de formación de documentos XML. Por
ejemplo, cada etiqueta abierta debe ser cerrada, no se deben cerrar etiquetas
no abiertas, el documento debe tener una estructura de árbol, entre otras.
Análisis semántico: En esta etapa se trabaja en las implicaciones de la expresión
ya validada y realiza las actuaciones pertinentes. Entenderá el tipo de XML
recibido (y validado léxica y sintácticamente) y el significado de cada uno de los
tokens que éste contiene, e incluirá toda la lógica necesaria para saber que
realizar con este tipo de información, ya sea reproducir una locución o pedir el
envío de otra página o recurso que se necesite.
6.7.5. Reproductor de audio
Las distintas distribuciones disponibles para los terminales de la plataforma Openmoko
suelen disponer de uno o varios reproductores de audio instalados, como mplayer,
mpd, etc. Entre los reproductores existentes para el Neo Freerunner se encuentra el
citado mplayer, el cual es empleado como sistema backend en multitud de
aplicaciones disponibles para los terminales, como por ejemplo: Pythm, Intone u
omShuffle. Estas aplicaciones no son más que frontend e interfaces gráficas que usan
mplayer como software reproductor.
El reproductor de audio seleccionado para el desarrollo del proyecto y que por tanto,
deberá ser instalado en el dispositivo móvil prototipo será mplayer. Los motivos que
nos llevan a seleccionar este reproductor y no otro son:
105
Reproduce audio en muchos formatos.
Es capaz de reproducir varios flujos de audio de forma simultánea.
Permite controlar el flujo de audio desde un programa mediante la ejecución
en modo esclavo. Este es el principal motivo por el que se ha elegido este
reproductor como sistema backend.
6.8. Comunicación con el Openmoko
Con el fin de facilitar la programación del Openmoko, haciéndola más sencilla y rápida
se comunica el dispositivo móvil con el ordenador, mediante un cliente Secure SHell
(SSH). De este modo se puede visualizar en la pantalla del ordenador, todo aquello que
se esté ejecutando en el Openmoko.
La comunicación entre el ordenador y el Openmoko se realiza mediante la interfaz
USB, entonces es necesario configurarla para establecer la comunicación entre ambos
y se siguen los siguientes pasos:
1. Configuración de la conexión USB: # sudo ifconfig usb0 192.168.0.200 netmask
255.255.255.0 (se asigna una dirección IP al puerto USB).
2. Comprobación de la misma: # ping -I usb0 192.168.0.202 (dirección por defecto
del Openmoko).
3. Establecimiento de la conexión: # ssh [email protected] y se deja en blanco
el password.
4. Para finalizar la conexión simplemente se utiliza el comando: # exit.
Una vez realizados los tres primeros pasos, tenemos establecida la comunicación con
el Openmoko y el sistema estará listo para realizar la tarea que se le encomiende.
6.9. Herramientas de compatibilidad (toolchains)
Debido a que el Openmoko se encuentra desarrollado sobre un procesador ARM, se
necesitan una serie de herramientas que permiten la compatibilidad con arquitecturas
empotradas. En la Wiki de desarrolladores mencionada en [49] se puede encontrar el
conjunto de herramientas encargadas de la traducción de una plataforma a otra, éstas
reciben el nombre de toolchains.
Para instalarlas, es necesario seguir una serie de pasos, que dependen del
microprocesador y del sistema operativo que posea el ordenador en donde se trabaja.
Para descargar del paquete para el procesador del ordenador de trabajo se ejecuta:
Para plataformas Linux de 32 bits:
106
# wget http://downloads.openmoko.org/developer/toolchains/ openmoko-i686-
20090323-armv4t-linux-gnueabi-toolchain-openmoko.tar.bz2
Para plataformas Linux de 64 bits:
# wget http://downloads.openmoko.org/developer/toolchains/ openmoko-x86_64-
arm-linux-gnueabi-toolchain.tar.bz2
Para instalarlas se debe ir a un directorio específico, mediante la sentencia:
# cd /usr/local/openmoko/
Y luego extraer los ficheros ejecutando la sentencia:
# tar-zxvf /sources/openmoko-XYZ-arm-linux-gnueabi-oolchain.tar.bz2
Luego se ejecuta una aplicación para alterar algunas variables de entorno que son
necesarias mediante la sentencia:
# ./usr/local/openmoko/arm/setup-env
Luego se añade en la ruta de este directorio para poder usar los archivos desde
cualquier otra ubicación mediante la sentencia:
# export PATH=$PATH:/usr/local/openmoko/arm/bin
Posteriormente y antes de cargar las librerías son necesarias otras variables de
entorno, para establecerlas se utiliza la sentencia:
# ./usr/local/openmoko/arm/environment-setup
Luego se actualizan las bases de datos opkg:
# opkg-target update
Y finalmente se instalan las librarías necesarias:
# opkg-target list |grep edje-dev
# opkg-target install libedje-dev
Todo este proceso puede ser largo, generalmente en torno a una hora.
6.10. Síntesis de voz humana
107
La síntesis de voz humana es la producción artificial de habla humana. Un sistema
usado con este propósito recibe el nombre de sintetizador de voz y puede llevarse a
cabo en software o en hardware. A los mecanismos de síntesis de voz se los llama a
menudo TTS (text-to-speech), en referencia a su capacidad de convertir texto en
locuciones. Un sistema TTS se compone de dos partes: un frontend y un backend. A
grandes rasgos, el frontend toma como entrada texto y produce una representación
fonética y el backend toma como entrada la representación lingüística simbólica y
produce una forma de onda sintetizada.
El frontend desempeña dos tareas principales. Primero, toma el texto y convierte las
partes problemáticas como números y abreviaturas en palabras equivalentes. Este
proceso se llama normalización de texto o preprocesado. Entonces asigna una
transcripción fonética a cada palabra, y divide y marca el texto en varias unidades
prosódicas, tales como frases y oraciones. Luego realiza la conversión de texto a
fonema, que no es más que el proceso de asignar transcripciones fonéticas a las
palabras. La combinación de transcripciones fonéticas e información prosódica
constituye la representación lingüística fonética. El backend, toma la representación
lingüística simbólica y la convierte en sonido. Este proceso es conocido comúnmente
como sintetizador.
A continuación se describen los distintos mecanismos de TTS que se han considerado y
se justifica la elección final.
6.10.1. eSpeak
eSpeak [55] es una aplicación TTS que puede ser manejada desde consola. Luego de
varias pruebas se ha notado que la voz producida no es muy realista, sonando bastante
robótica. Como ventajas se pueden citar su facilidad de uso, da gran libertad ya que
permite el control tanto de la velocidad de reproducción como del tono y la amplitud
de la voz. Cabe destacar que no da problemas con ningún tipo de texto, como números
con coma o palabras que contienen letras especiales como la ñ.
Esta opción fue descartada porque, a pesar de que es muy fácil de instalar y usar, la
aplicación ocupa mucho espacio en disco y la voz que reproduce el audio, que no se
puede variar, es artificial y poco agradable.
6.10.2. Festival
Festival [56] es un sistema desarrollado originalmente por el Centro de Investigación
de Tecnologías del Lenguaje de la Universidad de Edinburgo, la Universidad de
Carnegie Mellon y varios otros centros de enseñanza que han realizado contribuciones
108
al proyecto. Se distribuye como software libre bajo licencia del tipo MIT-X11 que
permite el uso sin restricciones. Incluye documentación completa para desarrollar
sistemas de síntesis de voz con varias APIs, siendo un entorno ideal para el desarrollo e
investigación de las técnicas de síntesis de voz.
El proyecto se ha escrito en lenguaje C++ y se ha implementado como un intérprete de
comandos el cual puede conectarse con diversos módulos y aplicaciones. Además
existen librerías para el desarrollo de aplicaciones en los lenguajes Java y C++, así como
un interfaz para el editor de textos. El proyecto festival es multilingüe. Además algunos
grupos han desarrollado herramientas que permiten utilizar otros idiomas con el
proyecto, entre ellos castellano con voz andaluza y catalán.
6.10.3. Flite
Flite [57] es un pequeño y rápido motor de síntesis de voz desarrollado en la
Universidad de Carnegie Mellon. Deriva del Festival, a quien debe el nombre, Festival
lite. Se ha diseñado para pequeñas máquinas empotradas como alternativa al Festival.
Esta opción fue descartada debido al poco desarrollo existente de voces e idiomas ya
que sólo incluye el inglés.
Finalmente, se ha escogido Festival como el mecanismo de síntesis de voz porque, a
pesar que ocupa más espacio en disco, se puede modificar e instalar sólo los paquetes
necesarios. La principal ventaja de usar Festival es su gran difusión entre la comunidad
de programadores, por lo que se han desarrollado muchos idiomas y herramientas
adicionales, como compresores y reproductores, compatibles con Festival.
Las principales características de Festival son:
Licencia tipo X11 que permite el uso sin restricciones tanto en aplicaciones
comerciales como no comerciales.
Poco tamaño en disco, aproximadamente 11MB incluyendo una voz en
español, masculina y de acento andaluz.
Cada voz adicional ocupa entre 3 y 5 MB.
Se pueden crear ejecutables que conviertan a voz automáticamente distintos
tipos de documentos (txt, html, xml entre otros), dotando de más versatilidad a
la pasarela.
6.11. Programación paralela
Al analizar las prestaciones de la plataforma electrónica, se hace imperiosa la
necesidad de recurrir a la programación paralela ya que estaremos realizando
actividades que podrían requerir su atención simultánea. Por ejemplo, puede darse la
109
situación en que un cliente esté reproduciendo un mensaje y llegue al alcance de un
servidor. Éste no escucharía al servidor y sencillamente lo ignoraría, perdiéndose así de
toda la información que le podría brindar.
Las técnicas más comunes para paralelizar códigos se muestran a continuación.
6.11.1 Técnicas multithread
Las técnicas multithread [58] permiten la ejecución de varios procesos
simultáneamente, compartiendo el procesador. A esto se conoce como
multithreading. A cada proceso se lo denomina thread (del inglés: hilo, hebra). Es
posible entonces, generar varios procesadores lógicos utilizando un único procesador
físico, de tal manera que si los recursos que necesitan los distintos threads son
diferentes, se mantienen flujos de instrucciones separados como si se contara con
varios procesadores. De paralelismo multiprocesador no se hablará en este trabajo ya
que escapa de las intenciones. El principal problema a solventar cuando se emplean
técnicas multithread es la de compartir un único recurso, por varios hilos de
programación. Para compartir un recurso se disponen de prioridades para evitar que
dos o más hilos cambien un mismo valor o lean valores falsos. Esta tecnología ha sido
implementada ya en los procesadores Xeon y Pentium 4 con el nombre de
hyperthreading. Actualmente los Core i7 de Intel poseen dos hilos de procesamiento
por cada núcleo, con lo que el sistema ve al microprocesador como uno de ocho
núcleos en vez de cuatro, que son los que físicamente tiene.
Hay dos paradigmas en programación paralela que están ampliamente extendidos, la
programación mediante paso de mensajes y la programación para memoria
compartida. El modelo de programación por paso de mensajes es uno de los
paradigmas más antiguos y utilizados en la programación de máquinas paralelas. Su
razón de ser está ligada a la creación de los primeros computadores paralelos,
ayudado por la poca necesidad de hardware que requiere para ser implementado. El
paralelismo es controlado explícitamente por el programador, lo que representa su
principal inconveniente ya que deja en manos de éste la responsabilidad de resolver
las dependencias de datos y evitar los interbloqueos y condiciones de carrera.
Antes de hablar de la programación en memoria compartida debemos aclarar algunos
conceptos como por ejemplo el de thread de ejecución. Aunque más arriba se ha
hecho una breve introducción, ahora se verá su estructura. Un thread de ejecución
puede ser definido como un flujo de instrucciones independiente que permite ser
planificado para su ejecución como tal por el sistema operativo, esto es, una secuencia
de instrucciones de un programa. Mirando desde el punto de vista de un programador,
se asocia a un proceso que se ejecuta de forma independiente de su programa
110
principal. Ampliando esta idea, si el programa principal tiene más de un proceso, todos
los procesos se podrían planificar para su ejecución simultánea e independiente por el
sistema, lo que describiría a un programa multithread.
Un proceso en UNIX consiste en un único flujo de ejecución que comienza en el
programa principal. Cada línea de código se ejecuta por turnos y exactamente una
línea a la vez. En UNIX cada proceso tiene información sobre los recursos del programa
y de su estado de ejecución, lo que implica:
Espacio de direcciones virtual (pila, datos y segmento de código).
Recursos del sistema (entorno, directorio de trabajo, descriptores de ficheros,
librerías, señales, ID de proceso, del usuario y del grupo, entre otras).
Instrucciones de programa.
Herramientas de comunicación interprocesos IPC (Inter-process
Communication) como: colas de mensaje, pipes, semáforos o memoria
compartida.
Estos recursos son privados a cada proceso ya que por ejemplo, los procesos no
pueden acceder al espacio de direcciones de otro proceso, abrir o cerrar ficheros de
otro, etc. Los procesos para poder comunicarse crean canales externos al proceso
mediante los mecanismos que el propio UNIX les proporciona para tales fines y son
programas muy tediosos ya que se implementan a muy bajo nivel y suponen una
sobrecarga considerable. En el modelo multithread un proceso puede expandir threads
de ejecución adicionales al suyo, de manera que los nuevos threads utilizan y conviven
con los recursos del proceso que los ha creado y, además, es posible que el sistema
operativo los planifique y ejecute como entidades independientes, en gran medida
porque duplican únicamente la parte de los recursos que les permite existir como
código ejecutable.
Este control de flujo independiente es posible porque cada thread mantiene:
Conjunto de registros y puntero de pila.
Pila para variables locales y direcciones de devolución del control.
Mecanismo de planificación (prioridad).
Conjuntos de señales pendientes o bloqueadas.
Datos específicos del thread (identificador de thread).
En cuanto al ciclo de ejecución, en el entorno UNIX un thread:
Existe en un proceso y utiliza los recursos del proceso.
Tiene su propio control de flujo, mientras exista su proceso padre y el sistema
operativo lo soporte.
111
Duplica sólo los recursos esenciales que necesita para poder desarrollarse de
forma independiente.
Puede compartir los recursos del proceso con otros threads que actúan de igual
forma independiente o dependientemente.
Muere si el proceso padre del recurso muere.
Es ligero porque la mayoría de la sobrecarga se ha genero con la creación de su
propio proceso.
Los threads del mismo proceso comparten:
Las instrucciones del proceso.
La mayoría de los datos.
Los descriptores de los ficheros abiertos.
Las señales y los gestores de las señales.
El directorio de trabajo actual.
ID de usuario y de grupo.
Puesto que los threads creados por el mismo proceso comparten recursos, se cumple
que:
Los cambios hechos por un thread sobre el sistema de recursos compartido
(como cerrar un fichero) pueden ser vistos por el resto de threads.
Dos punteros que tienen el mismo valor apuntan al mismo dato.
Es posible leer y escribir en la misma posición de memoria y, por tanto, se
requiere sincronización explícita por parte del programador.
Resumiendo, los threads comparten su memoria con otros threads, mientras que para
los procesos habitualmente tenemos diferentes áreas de memoria para cada uno. Otra
ventaja a la hora de utilizar threads en vez de utilizar un grupo de procesos es el
cambio de contexto entre procesos. Además, las comunicaciones entre threads son
más sencillas y rápidas de implementar que la comunicación entre procesos.
En lo que se refiere a estándares en memoria compartida y para sistemas UNIX, se ha
desarrollado el estándar IEEE POSIX 1003.1c (1995) [59], una interfaz para la
programación mediante threads utilizando lenguaje C. Las implementaciones que se
adhieren a este estándar se conocen como librerías de threads POSIX o de Pthreads.
Actualmente, la mayoría de los sistemas cuentan con librerías threads que se apoyan
en este estándar por lo que, en la práctica, se ha constituido en uno de los auténticos
estándares para la programación de máquinas de memoria compartida. El uso de
librerías de threads está ampliamente extendido entre los programadores de sistemas,
pero menos entre los programadores de aplicaciones. Se considera que el tipo de
112
primitivas que proporciona es de bajo nivel y que el esfuerzo y conocimientos
requeridos al programador son aún elevados.
Posteriormente aparece OpenMP (Open Multi Processing) [60] que constituye una
forma de programación basada en directivas con las que el usuario puede, a alto nivel,
introducir las primitivas adecuadas para la programación en memoria compartida. A
comienzos de los años 90 ya los vendedores de máquinas de memoria compartida
proporcionaban extensiones a Fortran, basadas en directivas, que eran funcionalmente
similares. El usuario añadía a su programa secuencial Fortran directivas que
especificaban qué bucles serían paralelizados. El compilador era el responsable de
paralelizar de forma automática tales bucles sobre máquinas de multiprocesamiento
simétrico (SMP). En 1997 aparecen las primeras especificaciones de OpenMP para el
lenguaje Fortran, que luego evolucionará hasta un estándar de facto en la
programación en máquinas de memoria compartida ya que aún no está registrado.
OpenMP está compuesto de tres elementos:
Directivas de compilación.
Rutinas de librería.
Variables de entorno.
En el sitio oficial se pueden encontrar los documentos y archivos de la especificación
que son libres y no requieren licencia para su uso. Proporciona un estándar para una
variedad de plataformas y arquitecturas de memoria compartida, mediante un
conjunto limitado de directivas para programar dichas máquinas por ejemplo se puede
obtener un paralelismo significativo utilizando tan sólo tres o cuatro directivas.
Luego de haber implementado funciones básicas de paralelismo, se hace notable la
diferencia de dificultad de implementación por parte de los threads del POSIX. Por el
contrario, el uso de las librarías OpenMP se hace casi de forma intuitiva y amigable.
OpenMP puede ser utilizado para cualquier paralelización, separando el código en
diferentes secciones que serán ejecutadas de forma paralela por diferentes hilos de
procesamiento. Además, esta asignación entre secciones e hilos se hace de forma
dinámica. Es decir, si un hilo finaliza su sección asignada y queda alguna sección más
por ejecutarse, éste se hará cargo de su ejecución, mejorando en gran medida el
rendimiento en comparación con el manejo de hilos de forma manual. La
implementación de aplicaciones bajo OpenMP se realiza mediante la inserción de
directivas en el código C, indicando qué partes del código se realizarán en paralelo y las
variables que podrán ser cambiadas por ese hilo (públicas) y cuáles no (privadas).
113
114
7. Capítulo 7
Pruebas y aportaciones
7.1. Introducción
En este capítulo se mostrarán las pruebas realizadas para determinar algunos
parámetros del sistema, tales como modos de detección, tiempos de descubrimiento,
etc. a fin de ajustarlos para el mejor desempeño del mismo. Luego veremos cómo se
comporta el sistema en una prueba realizada en el edificio de la Escuela de Ingenieros.
7.2. Pruebas con los dispositivos Bluetooth
A fin de determinar de forma óptima los parámetros de funcionamiento del sistema se
han hecho una serie de pruebas con los dispositivos Bluetooth para obtener
básicamente el tipo de búsqueda y el tiempo de descubrimiento del ciclo de inquiry.
7.2.1. Modos de detección de dispositivos
La norma Bluetooth estable dos tipos distintos de búsqueda de dispositivos, el modo
normal y el modo entrelazado, como se discutió en la sección 3.5. Para determinar cuál
de los dos tipos de búsqueda tiene mejor resultado, se han dispuesto en una sala
dispositivos Bluetooth y se ha lanzado el proceso de búsqueda reiteradas veces. A fin
de tener una estimación estadística confiable, las pruebas se han lanzado 15 veces.
Para ver cómo afecta el número de dispositivos al alcance, se ha hecho la prueba con 2
dispositivos y, luego se ha repetido la misma, con 15 dispositivos a fin de comparar los
resultados obtenidos. En las pruebas se ha cambiado la duración del ciclo de
búsqueda, con valores del 1 al 10. En las figuras 7.1 y 7.2 se puede observar el
porcentaje de dispositivos encontrados con el modo normal de búsqueda (línea a
trazos) y con el modo entrelazado (línea continua).
En ambos casos con el modo entrelazado se tiene una mejor respuesta que con el
modo normal, especialmente para tiempos de búsqueda cortos (menores a 5). Con el
modo entrelazado y para el caso de 2 dispositivos, con tiempo de búsqueda mayor a 2
ya tenemos respuestas del 100% de los dispositivos y en el caso de 15 dispositivos, a
partir de tiempo de búsqueda mayor a 3. Eso significa que necesitamos 3,84 segundos
115
para localizar 15 dispositivos. Con el modo normal, para encontrar todos los
dispositivos, para el caso de 2 dispositivos se necesitan 6,4 segundos y para el caso de
15 dispositivos no se asegura que sean encontrados todos los dispositivos; eso
significaría que existe la posibilidad que algún usuario pueda quedarse sin servicio.
Queda demostrado entonces, que se debe utilizar el modo entrelazado para mejorar el
proceso de búsqueda.
Figura 7.1. Prueba de descubrimiento de dispositivos Bluetooth con 2 dispositivos.
Figura 7.2. Prueba de descubrimiento de dispositivos Bluetooth con 15 dispositivos.
0%
20%
40%
60%
80%
100%
120%
1 2 3 4 5 6 7 8 9 10
Po
rce
nta
je d
e d
isp
osi
tivo
s e
nco
ntr
ado
s
Tiempo del ciclo de búsqueda [N*1,28 ]
modo normal
0%
20%
40%
60%
80%
100%
120%
1 2 3 4 5 6 7 8 9 10
Po
rce
nta
je d
e d
isp
osi
tivo
s e
nco
ntr
ado
s
Tiempo del ciclo de búsqueda [N*1,28 ]
modo normal
116
7.2.2. Tiempos de búsqueda del ciclo Inquiry
Prestando atención ahora al tiempo de búsqueda de dispositivos, length o LEN,
determinaremos el tiempo óptimo del ciclo de búsqueda. Debemos recordar que la
norma establece 48 intervalos de tiempo discretos, múltiplos de 1,28 segundos, dados
de la siguiente manera:
En la prueba se ha tomado valores del 1 al 10 como se mencionó antes, porque la
norma asegura que la probabilidad de encontrar a todos los dispositivos se da a partir
de LEN = 8 y es el tiempo estándar en los teléfonos móviles y en los ordenadores.
Ahora bien, fijándonos en la figura 7.1 que corresponde al caso de 2 dispositivos, se ve
que todos los dispositivos son encontrados con el modo de búsqueda entrelazado a
partir de LEN = 2. Si nos fijamos en la figura 7.2, el caso de 15 dispositivos, podemos
notar a partir de LEN = 3 se encuentran todos los dispositivos al alcance. Nótese que la
diferencia entre ambos es de 1,28 segundos y tomando en consideración que no se
espera un gran número de usuarios en un sitio en concreto, se podría utilizar LEN = 2
sin mayores inconvenientes.
7.3. Pruebas de funcionamiento del sistema
Se ha realizado dos pruebas en el edificio de la Escuela de Ingenieros. La primera
consiste en guiar a un usuario desde el Centro de Cómputo hasta la sala de
ordenadores, ambos ubicados en la Entreplanta 2 de la Escuela.
Figura 7.3. Mapa del recorrido desde el Centro de Cálculo hasta la Sala de Ordenadores.
117
En esta prueba se han dispuesto cinco balizas, una principal y cuatro de localización,
como se puede ver en la figura 7.3. Los resultados se muestran en la tabla 7.1.
Probabilidad de detección del móvil
LEN P(BN=5) P(BN=4) P(BN=3) 1 50 % 40% 10 % 2 90 % 10% 0 % 3 70 % 20 % 10 % 4 30 % 60 % 10 %
Tabla 7.1. Probabilidad de detección en el servicio de localización.
La tabla 7.1 muestra la probabilidad hallada que el dispositivo móvil sea detectado por
un número de balizas. Como dijimos anteriormente, el sistema cuenta con 5 balizas,
entonces se podría ver la columna con P(NB=5), como la probabilidad de llegar a
destino siendo detectado por todas las balizas. Nuevamente se corrobora que con el
campo LEN = 2, se obtiene las mejor probabilidad de éxito.
Hay que tener en cuenta que para estos casos, la detección de los dispositivos se ha
hecho en movimiento y pueden variar con respecto a los hallados anteriormente, que
eran estáticos. En ninguna de las repeticiones se ha dado el caso de que el número de
balizas que detecten al móvil, NB, sea menor a 3, por ello no se incluyen en la tabla.
La segunda prueba consiste en que el sistema lleve a un usuario desde la entrada de la
Escuela hasta el despacho del profesor Dr. Federico Barrero, en el Departamento de
Electrónica. Ahí se probarán las otras funcionalidades del sistema, como el servicio de
localización y de alerta. En este caso se han utilizado 2 balizas principales y 6 balizas de
localización.
En la figura 7.4 se ve el mapa de la planta baja de la Escuela de Ingenieros y donde se
puede ver el camino a seguir por el usuario. Cuando una persona que pase frente a la
Escuela, se le avisará al usuario que ha llegado a ese edificio y si quiere recibir alguna
información.
Entonces el usuario accede y se le informa de cómo llegar hasta la entrada de la
Escuela. Una vez allí el usuario escucha la información adscrita a esa baliza e indica su
interés por un sitio especial, que es el despacho descrito anteriormente. Ahí se le
pregunta si quiere que se localice el sitio cuando se encuentre cerca. Entonces escucha
las indicaciones hasta llegar al mismo y los pitidos de la baliza cuando llega a destino.
118
Figura 7.4. Mapa de planta baja de la Escuela de Ingenieros y ruta a seguir por el usuario.
Figura 7.5.Mapa del entreplanta 2 y ruta final del usuario.
119
7.4. Aportaciones
Gracias al trabajo efectuado se han podido hacer 4 contribuciones a IX Congreso de
Tecnologías Aplicadas a la Enseñanza de la Electrónica (TAEE) realizado en Madrid en el
mes de Abril de 2010. Las publicaciones llevan los siguientes títulos:
Plataforma para el aprendizaje de tecnologías inalámbricas y redes de sensores
basada en el sistema open hardware denominado Openmoko. GANADORA DEL
PREMIO ACCESIT EN TAEE 2010.
Desarrollo de experiencias prácticas basadas en el estándar de comunicaciones
inalámbricas Bluetooth.
Sistema de orientación basado en brújula electrónica para la realización de
prácticas.
Plataforma basada en microprocesador para el aprendizaje de tecnologías
inalámbricas RFID, NFC y Bluetooth.
Por otro lado se han presentado dos artículos en prestigiosos congresos
internacionales. El primero corresponde al congreso Wireless Applications and
Computing (WAC), desarrollado en Friburgo, Alemania, llamado “A methodology for
improving inquiry time in bluetooth devices”.
El segundo corresponde a un nuevo enfoque que se ha dado al sistema, y que resalta
su versatilidad. Se trata sobre un sistema de ayuda a víctimas de desastres
ambientales, presentado en Salónica, Grecia llamado: “A wireless in-door system for
assisting victims and rescue equipments in a disaster management” en el marco del
congreso Intelligent Networking and Collaborative Systems (INCoS).
Todas las aportaciones se adjuntan en el Apéndice 1.
120
8. Capítulo 8
Conclusiones 8.1. Introducción En este capítulo se presentan las principales conclusiones sobre el trabajo realizado y
se esbozan las líneas futuras de trabajo.
8.2. Conclusiones
En este trabajo se presenta el diseño e implementación de un sistema electrónica de
accesibilidad para discapacitados visuales, mediante la cual una persona con
discapacidad visual puede acceder a toda la información de su entorno. El sistema
desarrollado es una extensión del proyecto de investigación inicial, que ha permitido el
desarrollo de un sistema electrónico de asistencia a discapacitados visuales. En base al
hardware originalmente desarrollado para la asistencia a mujeres víctimas de violencia
de género, se ha diseñado e implementado un sistema tiflotecnológico, donde he
contribuido en gran parte del desarrollo software (en el proyecto, además de mi
trabajo, han colaborado mi tutor, como investigador responsable de la propuesta, el
Prof. Sergio L. Toral, y 3 investigadores contratados que se han encargado del
desarrollo de las plataformas hardware del sistema para la atención a los colectivos
mencionados).
El sistema tiflotecnológico, derivada del proyecto original, consta de tres elementos:
dos fijos y uno móvil. Los elementos fijos se deben colocar en los sitios donde se desea
informar a los usuarios, quienes llevan consigo el elemento móvil, que es el encargado
de reproducir los mensajes que llegan de los elementos fijos. Se han mostrado las
alternativas estudiadas al momento de escoger los elementos hardware del sistema y
las distintas opciones referentes al software, en cuya elección participé activamente
durante los primeros 4 meses de estancia en España, colaborando con los profesores
Dr. Federico Barrero y Dr. Sergio Toral (cabe destacar que durante ese periodo de
tiempo, era el único investigador contratado con cargo al proyecto). A partir de ese
momento, y durante un periodo de entre 8 y 9 meses, he contribuido al desarrollo del
software de la plataforma. Se ha mostrado el diseño e implementaciones del software
desarrollado, explicándose las pruebas de validación realizadas, en las que se ha
podido constatar el buen desempeño del protocolo Bluetooth en la aplicación. Se ha
probado, además, la interoperabilidad entre los dispositivos del sistema mediante un
121
par de ejemplos ilustrativos, en el que un usuario es conducido a través del edificio de
la Escuela de Ingenieros. El primero consiste en orientar al usuario desde el Centro de
Cálculo hasta la Sala de Ordenadores y, el segundo, desde la entrada de la Escuela
hasta el despacho de un profesor en el Departamento de Ingeniería Electrónica. En
dichos ejemplos se recorren todas las aplicaciones software desarrolladas, mostrando
así cada uno de los pasos que se recorren hasta que el usuario recibe la información
almacenada en un elemento fijo. Se ve, asimismo, la versatilidad que se esconde
detrás del sistema tiflotecnológico, ya que para brindar nuevos servicios bastará con
añadir tantas líneas de código XML como servicios se pretende ofrecer.
Por último, y fuera de la experiencia profesional lograda en la realización de este
trabajo, me gustaría resaltar lo enriquecedora que ha sido mi estancia en España, que
me ha permitido entablar contacto con otra cultura (hermana, pero diferente a la
paraguaya) y conocer el estado y metodología de trabajo de otras sociedades, lo que
ha contribuido definitivamente a mi formación como Ingeniero y como persona.
8.3. Futuros trabajos
En cuanto a nuevos dispositivos hardware que se pueden agregar al diseño propuesto
se pueden mencionar: un GPS y una brújula electrónica. El GPS brindaría, en entornos
outdoor, una forma de localización de respaldo y permitiría que las balizas estén más
espaciadas entre sí. La brújula electrónica para estimar la dirección (en grados) a la que
mira el usuario y que permitirá discernir el sentido de movimiento del mismo,
personalizando el mensaje a enviar al usuario.
En cuanto a software, se propone el desarrollo de una interfaz gráfica que sea
aprovechable tanto para personas con ceguera como para personas que tienen resto
visual, ya que por simplicidad, los ejemplos desarrollados están hechos en base a la
consola de Linux. Entonces, aparte de reproducir locuciones, se pueden pensar en
utilizar flechas que indiquen la dirección que debe tomar el usuario.
También se ha pensado en la utilización de los acelerómetros que dispones el
OpenMoko para utilizarlos como mandos del elemento móvil. Entonces si un usuario
quiere pasar a la siguiente opción del menú, bastaría con un simple movimiento de su
muñeca.
122
9. Anexo 1
Publicaciones y aportes
123
124
DESARROLLO DE EXPERIENCIAS PRÁCTICAS BASADAS EN EL
ESTÁNDAR DE COMUNICACIONES INALÁMBRICAS BLUETOOTH
E. MARSAL, D. GUTIÉRREZ, M. SOTO, J. HINOJO, F. CORTÉS, F. BARRERO, S. TORAL
Departamento de Ingeniería Electrónica. Escuela Superior de Ingenieros. Universidad de
Sevilla. España
[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected]
Resumen de la comunicación Bluetooth es un protocolo de comunicaciones inalámbrica que nos permite conectar dos o
más dispositivos a corta distancia, permitiendo la transmisión de voz y de datos mediante
enlaces de radio frecuencia en la banda ISM de 2.4 GHz. Para acercar al alumno el estándar, se
han desarrollado en el Departamento de Ingeniería Electrónica de la Universidad de Sevilla un
conjunto de prácticas para que los alumnos de la titulación de Ingeniería de Telecomunicación,
sin necesidad de un exhaustivo conocimiento teórico de la norma, puedan experimentar con
algunos de los parámetros más importantes en el establecimiento de las comunicaciones
inalámbricas Bluetooth, como son el proceso de descubrimiento de dispositivos y el rango de
alcance. El desarrollo realizado pretende, posteriormente, que los alumnos aprendan a
caracterizar los enlaces establecidos mediante análisis estadísticos, a fin de evaluar la calidad de
estos.
Se presenta una breve introducción al estándar Bluetooth y se explica el proceso de
descubrimiento de dispositivos y el diagrama de estados de la norma Bluetooth. Luego, se
muestran las aplicaciones prácticas desarrolladas, en las cuales los alumnos podrán cambiar los
parámetros de configuración del proceso de búsqueda de dispositivos, establecer conexiones
entre dispositivos, enviar y recibir ficheros. Por último, se explican los parámetros que
caracterizan los enlaces Bluetooth.
Se intenta estimular el aprendizaje basado en prácticas, necesario en aplicaciones de este
tipo, ya que se necesita mucho tiempo para desarrollarlas.
Referencias [1] Bluetooth Special Interest Group. Bluetooth Specification Version 2.1 + EDR,
http://www.bluetooth.com/ (2007).
[2] G. Záruba y I. Chlamtac. Accelerating Bluetooth Inquiry for Personal Area Networks. Global
Telecommunications Conference, 2003, vol. 2, pp.702-706, GLOBECOM '03, Diciembre 2003.
[3] B. Peterson, R. Baldwin y J. Kharoufeh. Bluetooth Inquiry Time Characterization and Selection.
Mobile Computing, IEEE transactions, vol. 5, pp. 1173-1187, 2006.
[4] G. Záruba y V. Gupta. Simplified Bluetooth Device Discovery – Analysis and Simulation. Systems
Scineces, 2004. Proceedings of 37th Annual Hawaii International Conference, pp. 9pp, 2004.
[5] S. Asthana y D. Kalofonos. The problem of Bluetooth pullution and accelerating connectivity in
Bluetooth Ad-Hoc networks. Pervasive Computing and Communications, 2005. PerCom 2005. Third
IEEE International Conference, pp. 8-12, 2005.
[6] X. Zhang y G. Riley. Evaluatioin and accelerating Bluetooth device discovery. Radio and Wireless
Symposium, pp. 467-470, 2006.
[7] F. Bektas, B. Vondra, P. Veith, L. Faltin, A. Pohl y A. Scholtz. Bluetooth communication employing
antenna diversity. Computers and Communication, 2003. Proceedings. Eighth IEEE International
Symposium on, 2003, pp.652-657, vol 1, 2003.
[8] A. Mohammed y T. Hult. Evaluation of the Bluetooth link and antennas performance for indoor
office environments by measurement trials and FEMLAB simulations. Vehicular Technology
Conference, 2005. VTC 2005-Spring. 2005 IEEE 61st, pp. 238-242, vol. 1, 2005.
[9] F. Forno, G. Malnati, G. Portelli. Desing and implementation of a Bluetooth ad hoc network for
indoor positioning. Software, IEE Proceedings, pp. 223- 228, vol. 152, 2005.
[10] BlueZ, pila de protocolos Bluetooth oficial para Linux, http://bluez.org/
125
DESARROLLO DE EXPERIENCIAS PRÁCTICAS BASADAS EN EL
ESTÁNDAR DE COMUNICACIONES INALÁMBRICAS BLUETOOTH
E. MARSAL, D. GUTIÉRREZ, M. SOTO, J. HINOJO, F. CORTÉS, F. BARRERO, S. TORAL
Departamento de Ingeniería Electrónica. Escuela Superior de Ingenieros. Universidad de
Sevilla. España
[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected]
Los sistemas de comunicación inalámbrica representan hoy en día el
ejemplo más claro de cómo influyen las nuevas tecnologías de la
información y las comunicaciones en la vida cotidiana de los seres
humanos. Bluetooth, utilizado en dispositivos tan habituales como el
teléfono móvil o la PDA, es uno de estos estándares de comunicación
inalámbrica más empleados. El uso del estándar Bluetooth se basa en
una serie de conceptos como la potencia de transmisión o los códigos
de acceso y el tiempo dedicado al proceso de descubrimiento, ocultos
generalmente al usuario del sistema. En este trabajo se presenta el
desarrollo de una serie de actividades experimentales que permiten a
los alumnos entrenarse en las características básicas del estándar
Bluetooth, accediendo y modificando sus parámetros de
configuración. Todas las experiencias prácticas, desarrolladas como
ampliación del enfoque práctico de la asignatura denominada
“Laboratorio de Instrumentación” adscrita a la titulación de
Ingeniería de telecomunicaciones en la escuela Superior de
Ingenieros de la Universidad de Sevilla, se basan en las librerías
BlueZ y en el sistema operativo Linux.
1. Introducción Bluetooth es un protocolo de comunicaciones inalámbrica que nos permite conectar dos o más
dispositivos a corta distancia, permitiendo la transmisión de voz y de datos mediante enlaces de
radio frecuencia en la banda ISM de 2.4 GHz [1]. Está adoptado como estándar (IEEE 802.15)
dentro del grupo de redes inalámbricas de área personal (WPAN). Si bien las especificaciones de la
norma Bluetooth son claras, las implementaciones en las distintas plataformas no son intuitivas y se
hace estrictamente necesario conocer al detalle la especificación, lo que requiere un gran esfuerzo
inicial por la extensión de la propia normativa (la versión 3.0 de Bluetooth se documenta en no
menos de 1700 páginas). Para acercar al alumno el estándar, y debido a la situación descrita, se han
desarrollado en el Departamento de Ingeniería Electrónica de la Universidad de Sevilla un conjunto
de prácticas para que los alumnos de la titulación de Ingeniería de Telecomunicación, sin necesidad
de un exhaustivo conocimiento teórico de la norma, puedan experimentar con algunos de los
parámetros más importantes en el establecimiento de las comunicaciones inalámbricas generadas por
Bluetooth, como son el proceso de descubrimiento de dispositivos y el rango de alcance. El
desarrollo realizado pretende, posteriormente, que los alumnos aprendan a caracterizar los enlaces
establecidos mediante un extenso análisis estadístico, a fin de aprendan a evaluar la calidad de estos.
2. El estándar Bluetooth: establecimiento y calidad del enlace inalámbrico El proceso de descubrimiento en la especificación Bluetooth es fundamental en el
establecimiento de la comunicación asociada al estándar Bluetooth. Este proceso se divide en
tres fases [2]:
En la primera fase, el dispositivo que inicializa la comunicación (que se denomina
master en la norma) busca dispositivos a su alrededor. El master se encuentra en el
126
estado Inquiry durante esta fase, mientras que los dispositivos vecinos que estén a la
escucha (slaves según la norma) se deben encontrar en el estado Inquiry Scan.
A la fase anterior, le sigue el proceso denominado paging en el que ambos
dispositivos, master y slave, realizan un handshaking, o comunicación con acuse de
recibo, mediante el cual intercambian información fundamental para la formación
del enlace.
La última fase consiste en el establecimiento del enlace físico.
Una importante cuestión a tener en cuenta en el establecimiento de un enlace inalámbrico
de tipo Bluetooth, es que si los dispositivos conocen sobre la existencia de otros en su rango de
cobertura, esto no implica que exista ningún tipo de enlace entre ellos. Por otro lado, el proceso
de descubrimiento se encuentra totalmente enmascarado en la comunicaciones ordinarias que se
realizan hoy en día con dispositivos de uso común, como son los teléfonos móviles, pero cuando
se requiere una respuesta rápida o con requerimientos de tiempo específicos, como son los
sistemas de instrumentación electrónica, es necesario tener un mayor control sobre los
parámetros que intervienen en el proceso de descubrimiento. La componente aleatoria en el
proceso de descubrimiento es elevada [2, 3], requiriendo este estudio de un análisis estadístico
complejo [3]. Existen muchos estudios acerca de cómo acelerar el proceso de descubrimiento
empleando la norma Bluetooth, [4, 5, 6], y en la actualidad se está estudiando la introducción de
nuevas tecnologías, mecanismos fuera de banda, para intentar mejorar este proceso de
descubrimiento y emparejamiento. En concreto, y a partir de la especificación Bluetooth 2.1 y
3.0, se incluye la tecnología NFC como forma de intercambiar información de emparejamiento.
Ahora bien, una vez establecida una conexión Bluetooth, existen una importante variedad
de parámetros relacionados con la calidad de la transmisión y entre sí, por lo que llegar a
concluir cómo es esta calidad resulta una tarea complicada, especialmente por la cantidad de
variables que intervienen, algunas muy difíciles de controlar debido a su componente aleatorio
como se puede observar en los modelos de propagación de la señal que se suelen utilizar [7, 8].
Muchas de estas variables dependen del dispositivo particular y de su diseño particular, lo que
nos lleva por ejemplo al tipo y comportamiento de los amplificadores internos o las antenas [9].
El acercamiento de forma práctica a las tecnologías inalámbricas de tipo Bluetooth se
plantea como objetivo docente a cumplir, dado su extenso uso a nivel de electrónica de
consumo, en una asignatura de origen práctico como es el Laboratorio de Instrumentación del 5º
de la titulación Ingeniero en Telecomunicación adscrita al Departamento de Ingeniería
Electrónica de la Universidad de Sevilla. De esta manera, se instruye experimentalmente a los
alumnos a nuevas formas de instrumentación sin cables utilizando el aire como medio de
transmisión.
127
Figura 1. Diagrama de estados en el controlador de enlaces Bluetooth.
El objetivo de estas prácticas es hacer que los alumnos se paseen por los distintos estados
del controlador de enlaces Bluetooth sin que eso suponga un excesivo gasto de tiempo y
esfuerzo. Tres son los estados principales involucrados en el establecimiento de una conexión
inalámbrica Bluetooth (Fig. 1): STANDBY (Espera), CONNECTION (Conexión) y PARK
(Aparcar). Aparecen, además, otros siete subestados denominados paginación, detección de
paginación, búsqueda, detección de búsqueda, respuesta del maestro, respuesta del esclavo y
respuesta a la búsqueda. Los subestados son estados transitorios que se usan para establecer
conexiones y permitir el descubrimiento de dispositivos. Para pasar de un estado o subestado a
otro, se usan comandos del gestor de enlaces o bien señales internas del controlador de enlaces.
Desde el punto de vista del conjunto de aplicaciones desarrollada para la configuración de
cada uno de los parámetros de los dispositivos Bluetooth, así como la gestión de las
comunicaciones entre los mismos, se ha empleado BlueZ [10], que es la implementación de la
pila de protocolos Bluetooth para sistemas operativos basados en Linux, que ofrece todo un
extenso conjunto de módulos, librerías y aplicaciones para el trabajo con esta tecnología. A
pesar de que existen otras implementaciones, como la desarrollada por el centro de
investigación de Nokia y denominada Affix, el hecho de decantarse por BlueZ es prácticamente
obligado, teniendo en cuenta que ofrece una serie de prestaciones que no ofrece ninguna de las
otras implementaciones posible, tales como:
Está definida como la implementación oficial de la denominada “Bluetooth Stack”
para sistemas UNIX.
Viene por defecto instalada y completamente integrada en la mayoría de
distribuciones Linux del mercado (lo que mejora la capacidad de interoperabilidad
del alumno con la tecnología).
Existencia de infinidad de aplicaciones y librerías.
Sin embargo, a nivel didáctico ofrece lamentablemente carencias, como es la escasa
documentación ofrecida, principal problema de muchos de los proyectos de desarrollo en
software libre y código abierto. Esto hace que su uso en los instantes iniciales sea poco
amigable, y la curva de aprendizaje necesaria para llegar a hacer un uso razonable de BlueZ sea
demasiado extensa. Para resolver este tipo de inconvenientes existe la posibilidad de la
generación de un conjunto de funciones y de APIs en los que los parámetros de configuración a
añadir se resuelven como parámetros a introducir en dichas funciones, elevando el nivel de
abstracción y permitiendo al alumno un primer acercamiento mucho más liviano y menos
costoso en tiempo hacia BlueZ.
BlueZ fue desarrollada por Qualcomm desde 2001 bajo licencia GPL, promovida por el
Bluetooth Interest Group desde 2005 y disponible de manera oficial como parte de la
implementación de los kernels de Linux a partir de la versión 2.4.6.
3. Aplicaciones desarrolladas Las aplicaciones para los alumnos se han hecho en código ANSI C, permitiéndoles
cambiar los parámetros por línea de comando e ir así variándolos, a fin de constatar como afecta
el cambio de las mismas a las pruebas siguientes. En cuanto a la aplicación a la asignatura
denominada Laboratorio de Instrumentación Electrónica, se han desarrollado una serie de
trabajos prácticos para ayudar al alumno a comprender los parámetros que entran en juego al
establecerse un enlace inalámbrico Bluetooth, así como el rango de valores posibles que pueden
tomar. Estos ensayos son:
Pruebas de búsqueda de dispositivos. El proceso de descubrimiento es asimétrico. Un
128
dispositivo Bluetooth trata de encontrar otros dispositivos cercanos enviando mensajes de
descubrimiento (inquiry requests). Los dispositivos Bluetooth que están disponibles para ser
encontrados escuchan estos mensajes y responden con su dirección Bluetooth. Este proceso de
descubrimiento utiliza un canal físico especial para los mensajes de búsqueda. En la prueba
diseñada, se busca que los alumnos interactúen con los parámetros de búsqueda de dispositivos
Bluetooth que se detallan a continuación:
Inquiry length. Valor que especifica el tiempo máximo que el dispositivo debe
esperar las respuestas de los otros dispositivos. Puede tomar valores enteros de 1 a
30, que corresponden a múltiplos de 1,28 s.
Number of responses. Máximo número de respuestas que el dispositivo espera.
Puede tomar valores de 1 a 255 dispositivos. El valor cero significa infinitas
respuestas.
LAP. Representa a la parte baja de una dirección Bluetooth. Puede tomar valores
desde 9E8B00 hasta 9E8B3F, expresado en notación hexadecimal. Si se le asigna
cero, se utiliza el código de acceso general 9E8B33.
IAC. Especifica el número de códigos de acceso de búsqueda que serán utilizados
por el dispositivo local durante la fase Inquiry scan. Puede tomar valores de 1 a 40
en notación hexadecimal.
Type. Selecciona que tipo de búsqueda realizar. Los valores pueden variar de 0 a
FF en notación hexadecimal; el valor 0 implica búsqueda estándar y el 1 hará la
búsqueda entrelazada. Los demás valores están reservados para usos futuros.
Mode. Modifica el tipo de resultado esperado en las búsquedas de dispositivos.
Puede tomar valores de 0 a FF en notación hexadecimal. El valor 0 representa la
respuesta estándar, el valor 1 añade el valor del RSSI a la respuesta y el valor 2 es
para obtener la respuesta extendida. Los valores de 3 a FF, están reservados.
Figura 2. Captura de pantalla de los resultados de la búsqueda de dispositivos con código de acceso
general.
Se ven los resultados de la búsqueda de dispositivos cercanos (Fig. 2), se ven la dirección
Bluetooth y el nombre amigable de cada dispositivo. La aplicación debe ejecutarse con los
parámetros len y max_rsp como entrada, que son el tiempo de búsqueda y la cantidad de
dispositivos que esperamos encontrar respectivamente. La búsqueda finaliza cuando se satisface
una de las dos condiciones.
129
Figura 3. Captura de pantalla de los resultados de la búsqueda de dispositivos con código de acceso
dedicado.
El cambio de los parámetros de búsqueda de dispositivos (Fig. 3), antes y después del
cambio de los valores. La aplicación desarrollada debe ejecutarse con cinco parámetros, que
son: la dirección Bluetooth del dispositivo local, el código de búsqueda, el código de acceso, el
tipo y el modo de respuesta del proceso de búsqueda.
Pruebas de calidad de enlace. Se pretende que los alumnos obtengan los parámetros que
hacen referencia a la calidad del enlace y a la potencia recibida y transmitida por los
dispositivos a fin de establecer métricas y poder comparar los estados de los enlaces. Las
variables analizadas son:
Transmit Power Level (TPL), que especifica el nivel de potencia transmitida (en dBm)
por el módulo Bluetooth. En la mayoría de los casos un emisor responderá con el nivel
de potencia configurado por defecto para iniciar o responder a las preguntas, aunque la
variable TPL puede variar durante la conexión, debido al control de potencia, mediante
comandos de regulación de potencia. En la especificación Bluetooth el control de
potencia es obligatorio en los dispositivos de clase 1 y opcional en los demás.
Received Signal Strength Indicator (RSSI). Variable que indica si el nivel de potencia
recibida está dentro, por encima o abajo del denominado Golden Receiver Power Range
(GRPR), que es considerado como el rango ideal de potencia aplicable al transmisor
para el establecimiento del enlace Bluetooth. Tal como se define en la especificación
Bluetooth, un RSSI positivo o negativo (en dB) indica que el nivel de potencia está por
encima o por debajo de la GPRP, respectivamente, mientras que cero es el valor ideal
(el nivel de potencia recibida está dentro de GRPR).
Link Quality (LQ). Evalúa la calidad del enlace que se percibe en el receptor. El índice
varía desde 0 hasta 255. A mayor valor, mejor es el estado del enlace. Para la mayoría
de los módulos de Bluetooth, que se deriva de la tasa media de error de bit (BER) visto
en el receptor, y se actualiza constantemente en forma de paquetes que se reciban. Sin
embargo, la asignación exacta de BER a LQ es específico del dispositivo. LQ se utiliza
principalmente para adaptarse a los cambios en el estado del enlace, en particular, para
apoyar al denominado CQDDR (Canal Driven Quality Data Rate).
Se muestra la aplicación desarrollada para evaluar las características del enlace (Fig. 4). A
ésta se le pasa la dirección Bluetooth del dispositivo al que estamos conectados y nos devuelve
la potencia actual del transmisor, el valor del RSSI y la calidad del enlace. Se ve como variando
la posición y velocidad de los dispositivos, las características del enlace varían.
130
Figura 4. Captura de pantalla con los resultados de los parámetros de calidad de enlace.
Pruebas de control de enlace. Se han desarrollado pruebas para analizar parámetros y
estados muy importantes de entender a la hora de desarrollar aplicaciones para comunicaciones
Bluetooth. Dentro de estos, destacar:
Park mode. Cuando un dispositivo slave no necesita participar en una piconet, pero aún
necesita estar sincronizado con el master, puede entrar en este modo, donde el slave
tiene muy poca actividad pero se despierta a intervalos regulares de tiempo para
mantenerse sincronizado con la piconet.
Role switch. Un dispositivo necesita intercambiar las funciones cuando, por ejemplo,
necesita ser master de más de una piconet.
Figura 5. Captura de pantalla de la aplicación para cambiar los parámetros de control de enlace.
Se ven las opciones de la aplicación de control de enlace (Fig. 5), que nos permite enviar
ficheros entre dispositivos Bluetooth (para realizar pruebas de control de velocidad o parámetros
que necesiten de un enlace establecido), aparcar dispositivos y, por último, cambiar el rol
master-slave de una piconet.
4. Conclusión Este trabajo presenta el desarrollo de aplicaciones que permitirán a los alumnos de
Laboratorio de Instrumentación acercarse de forma fácil y práctica a la norma Bluetooth,
saltándose los detalles de programación de una pila de protocolos específica. Esto permitirá
concentrarse en el significado y valor de una serie de parámetros referentes a la búsqueda y
detección de dispositivos Bluetooth, así como las características del enlace establecido y la
configuración topológica de una red Bluetooth. Además se intenta estimular el aprendizaje
basado en prácticas, necesario en aplicaciones de este tipo.
131
Referencias [1] Bluetooth Special Interest Group. Bluetooth Specification Version 2.1 + EDR,
http://www.bluetooth.com/ (2007).
[2] G. Záruba y I. Chlamtac. Accelerating Bluetooth Inquiry for Personal Area Networks. Global
Telecommunications Conference, 2003, vol. 2, pp.702-706, GLOBECOM '03, Diciembre 2003.
[3] B. Peterson, R. Baldwin y J. Kharoufeh. Bluetooth Inquiry Time Characterization and Selection.
Mobile Computing, IEEE transactions, vol. 5, pp. 1173-1187, 2006.
[4] G. Záruba y V. Gupta. Simplified Bluetooth Device Discovery – Analysis and Simulation. Systems
Scineces, 2004. Proceedings of 37th Annual Hawaii International Conference, pp. 9pp, 2004.
[5] S. Asthana y D. Kalofonos. The problem of Bluetooth pullution and accelerating connectivity in
Bluetooth Ad-Hoc networks. Pervasive Computing and Communications, 2005. PerCom 2005. Third
IEEE International Conference, pp. 8-12, 2005.
[6] X. Zhang y G. Riley. Evaluatioin and accelerating Bluetooth device discovery. Radio and Wireless
Symposium, pp. 467-470, 2006.
[7] F. Bektas, B. Vondra, P. Veith, L. Faltin, A. Pohl y A. Scholtz. Bluetooth communication employing
antenna diversity. Computers and Communication, 2003. Proceedings. Eighth IEEE International
Symposium on, 2003, pp.652-657, vol 1, 2003.
[8] A. Mohammed y T. Hult. Evaluation of the Bluetooth link and antennas performance for indoor office
environments by measurement trials and FEMLAB simulations. Vehicular Technology Conference,
2005. VTC 2005-Spring. 2005 IEEE 61st, pp. 238-242, vol. 1, 2005.
[9] F. Forno, G. Malnati, G. Portelli. Desing and implementation of a Bluetooth ad hoc network for
indoor positioning. Software, IEE Proceedings, pp. 223- 228, vol. 152, 2005.
[10] BlueZ, pila de protocolos Bluetooth oficial para Linux, http://bluez.org/
132
PLATAFORMA BASADA EN MICROPROCESADOR PARA EL
APRENDIZAJE DE TECNOLOGÍAS INALÁMBRICAS RFID, NFC
Y BLUETOOTH
D. GUTIÉRREZ, E. MARSAL, M. SOTO, J.M. HINOJO, F. CORTÉS, F. BARRERO, S.
TORAL
Departamento de Ingeniería Electrónica. Escuela Superior de Ingenieros. Universidad de
Sevilla. España
[email protected], [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected]
Resumen de la comunicación Las tecnologías inalámbricas han sufrido una enorme expansión en los últimos años,
integrándose en una amplia gama de dispositivos móviles, como teléfonos, PDAs y
computadoras. Dos de estas tecnologías son el estándar NFC (Near Field Communication) y la
tecnología RFID (Radio Frequency Identification). Por otro lado, Bluetooth es una
especificación que define redes inalámbricas de área personal (WPAN) de corto alcance,
trabajando en las frecuencias 2.4 GHz a 2.4835 GHz.
A lo largo de la carrera de Ingeniería de Telecomunicación, el alumno percibe a menudo
ciertas carencias a nivel práctico en su formación. Este hecho es especialmente crítico en el área
de la electrónica, y más específicamente en las tecnologías inalámbricas, donde se tienen
conocimientos teóricos pero es complicado llevarlos al campo práctico por las dificultades que
esto conlleva. Es precisamente una asignatura práctica como el Laboratorio de Instrumentación
Electrónica, perteneciente al 5º curso de la titulación de Ingeniería de Telecomunicación en la
Escuela Superior de Ingenieros de la Universidad de Sevilla, el espacio que consideramos más
adecuado para solventar, dentro de lo posible, esas carencias. El sistema de aprendizaje
desarrollado permite a los alumnos experimentar con las tres tecnologías de forma
independiente, o enlazarlas para formar un sistema pasarela entre ellos. El objetivo es que
tecnologías tan novedosas como NFC se integren en los nuevos sistemas de enseñanza
universitaria dentro del nuevo marco europeo. Para la evaluación del grado de satisfacción de
los alumnos y el nivel de conocimiento adquirido con la experiencia planteada, se ha
desarrollado un cuestionario en el cual los alumnos pueden calificar de 1 a 5 el grado de
satisfacción con cada una de las sesiones desarrolladas. Además se invita a los alumnos a que
expresen su opinión sobre la experiencia y posibles mejoras que se puedan incluir para futuros
años.
Referencias [1] Dean A.Gratton. Developing Practical Wireless Applications 216-224.
[2] ECMA_International. Near Field Communication –white paper-(2004).
[3] Bluetooth SIG, Bluetooth Baseband Specification, version 2.1+EDR, www.bluetooth.org.
[4] Bluetooth SIG, Host Controller Interface Functional Specification, version 2.1+EDR,
www.bluetooth.org.
[5] C.Y.Leong, K.C.Ong, K.K.Tan*, O.P.GAN, Near Field Communication and Bluetooth Bridge
System for Mobile Commerce. IEEE International Conference on Industrial Informatics 50-55
(2006). [6] M. Sallinen, E. Strömer, A. Ylisaukko-oja. Sensor Technologies and applications,
SENSORCOMM’08. Second International Conference586-591 (2008).
[7] G. Matas, I. Luque, M.A. Gómez-Nieto. How NFC can be used for compliance of European Higher
Education Area Guidelines in European Universities. Near Field Communication NFC’09, first
international workshop 3-8 (2009).
[8] H. Mika, H. Mikko, A. Ylisaukko-oja. Practical implementation of passive and semi-passive NFC
enabled sensor. Near Field Communication NFC’09, first international workshop 69-75 (2009).
[9] Página oficial del proyecto Bluez http://www.bluez.org/
133
[10] Página oficial del proyecto LibNFC http://www.libnfc.org/
PLATAFORMA BASADA EN MICROPROCESADOR PARA EL
APRENDIZAJE DE TECNOLOGÍAS INALÁMBRICAS RFID, NFC
Y BLUETOOTH
D. GUTIÉRREZ, E. MARSAL, M. SOTO, J.M. HINOJO, F. CORTÉS, F. BARRERO, S.
TORAL
Departamento de Ingeniería Electrónica. Escuela Superior de Ingenieros. Universidad de
Sevilla. España
[email protected], [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected]
En este trabajo se presenta el desarrollo de una plataforma, basada
en un microprocesador de bajo coste, que pretende acercar a los
alumnos al uso y desarrollo de aplicaciones basadas en las
tecnologías inalámbricas RFID y Bluetooth. Mientras que el estándar
NFC representa el ejemplo más claro del elevado crecimiento que
están experimentado recientemente los dispositivos RFID, Bluetooth
personifica el grado de desarrollo y uso que pueden alcanzar estas
tecnologías inalámbricas gracias a los dispositivos electrónicos de
uso cotidiano como son teléfonos móviles, PDAs y PCs portátiles.
Para mostrar a los alumnos el interés de ambas tecnologías, se ha
desarrollado un sistema simple para la realización de trabajos
prácticos en una asignatura denominada “Laboratorio de
Instrumentación Electrónica”, adscrita a la titulación de Ingeniería
de telecomunicaciones en la escuela Superior de Ingenieros de la
Universidad de Sevilla.
1. Introducción A lo largo de la carrera de Ingeniería de Telecomunicación, el alumno percibe a menudo
ciertas carencias a nivel práctico en su formación. Este hecho es especialmente crítico en el área
de la electrónica, y más específicamente en las tecnologías inalámbricas, donde se tienen
conocimientos teóricos pero es complicado llevarlos al campo práctico por las dificultades que
esto conlleva. Es precisamente una asignatura práctica como el Laboratorio de Instrumentación
Electrónica, perteneciente al 5º curso de la titulación de Ingeniería de Telecomunicación en la
Escuela Superior de Ingenieros de la Universidad de Sevilla, el espacio que consideramos más
adecuado para solventar, dentro de lo posible, esas carencias.
Por otro lado, las tecnologías inalámbricas han sufrido una enorme expansión en los últimos
años, integrándose en una amplia gama de dispositivos móviles, como teléfonos, PDAs y
computadoras. Dos de estas tecnologías son el estándar NFC (Near Field Communication) y la
tecnología RFID (Radio Frequency Identification) las cuales en multitud de ocasiones se
confunden. RFID es una tecnología que surge a finales de la década de los cuarenta y que se
impulsa su uso a través de sistemas de vigilancia electrónica. Los dispositivos RFID pueden
operar dentro de tres distintos rangos de frecuencias en función de la aplicación particular [1];
baja de 125 kHz a 134 kHz o de 140 kHz a 148.5 kHz, alta de 13.56 MHz y ultra alta entre 868
MHz y 928 MHz. Se definen dos elementos en las comunicaciones RFID, la etiqueta o tag y el
lector o interrogador. Por otro lado NFC es un protocolo de comunicaciones de corto alcance
que surge de combinar tecnologías de interconexión y RFID. NFC permite a dos dispositivos
electrónicos realizar una comunicación punto a punto con el simple hecho de que ambos entren
134
en contacto (en la práctica porque estén a una distancia muy corta, hasta 10 cm) utilizando la
banda alta de frecuencia de 13.56 MHz [1, 2]. Por su parte, Bluetooth es una especificación que
define redes inalámbricas de área personal (WPAN) de corto alcance, trabajando en las
frecuencias 2.4 GHz a 2.4835 GHz. La banda de frecuencias se divide, a su vez, en 79 canales,
con un ancho de banda de hasta 3 Mbits/s. Los dispositivos que cumplen el estándar Bluetooth
se conectan entre sí conformando las redes denominadas Piconets, o redes maestro-esclavo que
pueden estar formada por un único maestro, hasta 7 dispositivos activos y 255 estacionados
todos ellos como esclavos. A su vez, varias de estas redes Piconets se pueden unir formando las
denominadas redes Scatternets [3, 4].
El sistema de aprendizaje desarrollado permite a los alumnos experimentar con las tres
tecnologías de forma independiente, o enlazarlas para formar un sistema pasarela entre ellos
(fig.1). Dada la escasez de dispositivos de tipo lector NFC o RFID, se ha incorporado la
funcionalidad pasarela NFC-Bluetooth al sistema para poder realizar aplicaciones basadas en
dispositivos NFC [5, 6], empleando equipos electrónicos comerciales fáciles de localizar y
accesibles a los alumnos como son los teléfonos móviles, que en la actualidad vienen casi todos
provistos de conectividad Bluetooth.
Figura 1: Esquema de funcionamiento del sistema desarrollado.
El objetivo es que tecnologías tan novedosas como NFC se integren en los nuevos sistemas
de enseñanza universitaria dentro del nuevo marco europeo [7]. Sistemas como el que se
presenta ayudan a la integración de este tipo de tecnologías, encajando perfectamente con un
nuevo enfoque eminentemente práctico que se está implantando en la asignatura y que ofrece al
alumno la posibilidad de realizar un pequeño desarrollo basado en sistemas reales, en este caso
basado en el sistema microprocesador presentado, y que permite manejar las tecnologías
inalámbricas Bluetooth, NFC y RFID.
Descripción del sistema El sistema de aprendizaje implementado se basa en un sencillo microprocesador que se
encarga de manejar las comunicaciones RFID, NFC y Bluetooth. Aunque el sistema permite
leer y escribir tanto tags RFID como NFC, la descripción del sistema se va realizar teniendo en
135
cuenta sólo el estándar NFC, ya que el funcionamiento con RFID sería similar. La
comunicación NFC se realiza mediante un lector/escritor de etiquetas pasivas (NFC target) que
lee la información contenida en ellas. La etiqueta no necesita alimentación, y simplemente
aprovecha el campo magnético generado por el lector para alimentarse y poder transferirle los
datos. El encargado de generar el campo electromagnético se denomina Iniciador (NFC
Initatior) [2].
Por su parte, la comunicación Bluetooth se realiza mediante un dispositivo embedded
Bluetooth que permite ser controlado mediante comandos ASCII enviados por el
microprocesador. Estos comandos, parecidos a los comandos AT, permiten establecer enlaces
RFCOMM hacia cualquier otro dispositivo remoto con enlace Bluetooth, como puede ser un
ordenador personal o un teléfono móvil.
El microprocesador elegido ha sido el Atmega128. Se trata de un microprocesador de 8 bits
de núcleo AVR, que se ha programado utilizando ANSI C para desarrollar una biblioteca de
funciones de acceso y control de los dispositivos inalámbricos del sistema. Se ha escogido este
microcontrolador por tratarse de un dispositivo profusamente empleado en el ámbito industrial,
dado su bajo coste y versatilidad. El microprocesador posee sin embargo otras características
que lo hacen aconsejable en un ambiente educativo, en especial, contiene una gran cantidad de
interfaces para comunicar con otros dispositivos electrónicos como son UARTs, I2C y SPI. Para
simplificar el desarrollo del sistema, se ha utilizado el sistema de desarrollo JMS2206 que
contiene el microprocesador Atmega128 trabajando con un cristal de 4 MHz. A su vez,
incorpora la interfaz de programación JTAG, permitiendo utilizar herramientas de depuración
de código (debugger ATJTAGICE). Con este sistema, los alumnos pueden desarrollar sus
propias aplicaciones, visualizando en tiempo real la ejecución de código programado en la
memoria FLASH del microprocesador.
Entre los diferentes dispositivos de acceso a etiquetas NFC pasivas, se escogió el dispositivo
HF Multi ISO OEM de ACG, compatible con las normativas ISO14443 A/B, ISO 15693, ISO
18000-3, dispositivos RFID EPC, Mifare© y NFC. El principal motivo para esta elección es que
el lector soporta un gran número de clases de etiquetas tanto de RFID como NFC. Mediante una
interfaz serie, el lector NFC se conecta con el microprocesador Atmega. Utilizando esta misma
interfaz, el lector NFC se puede conectar a un PC para que los alumnos visualicen y ejecuten,
con la ayuda de la aplicación Hyperterminal de Windows o alguna similar, todos los comandos
integrados en las librerías desarrolladas para realizar escrituras y lecturas de las etiquetas de
forma sencilla e intuitiva, y de forma análoga a como actuaría el microprocesador en el sistema
completo.
Los dispositivos embedded Bluetooth seleccionados son indistintamente el WT-11 o WT-12.
La diferencia entre ambos es la clase de dispositivo Bluetooth, clase 1 y clase 2
respectivamente. La clase del dispositivo está estrechamente ligada con el alcance de la
comunicación Bluetooth, menos de 10 metros para dispositivos clase 2 y hasta 100 metros para
dispositivos clase 1. Ambos dispositivos son controlados mediante comandos ASCII enviados
mediante una comunicación serie establecida entre el microprocesador y el dispositivo WT. Los
comandos se almacenan en la memoria FLASH de datos del Atmega128, ofreciendo el
dispositivo WT dos modos de operación: modo comandos y modo datos. En el modo comandos,
el cual se encuentra definido por defecto, el dispositivo está a la espera de recibir comandos por
parte de microprocesador a través de la comunicación serie establecida. Con estos comandos se
pueden establecer parámetros de configuración fundamentales para el estándar Bluetooth tales
como la potencia de transmisión y el tiempo de Inquiry o búsqueda de dispositivos. En el modo
datos, la información que recibe el dispositivo a través de la interfaz serie es enviada por el
enlace RFCOMM establecido. El cambio entre ambos modos de funcionamiento se gestiona a
través del microprocesador Atmel. Al igual que con el dispositivo NFC, el dispositivo WT se
136
puede conectar a un PC mediante una comunicación serie, haciendo posible a los alumnos de
una manera sencilla y análoga a la del microprocesador, la interacción con el dispositivo WT.
Estos aspectos refuerzan la idea de que las tecnologías Bluetooth y NFC pueden funcionar de
forma independiente en la plataforma de aprendizaje.
Para mejorar la interacción del sistema de aprendizaje con los alumnos se incluyen en el
sistema varios elementos indicadores como son:
Zumbador, para generar una señal sonora en los siguientes casos, cuando el sistema está
preparado para leer un nuevo tag y cuando se abre o cierra la comunicación Bluetooth.
Con esta señal sonora el alumno puede seguir de una forma intuitiva las distintas fases
por las que pasa el sistema.
Diodos leds de indicación. En concreto, un led que se encontrará encendido mientras el
sistema se encuentre alimentado y otro que se iluminará cuando se ha leído
correctamente un tag.
A continuación se muestra una imagen del sistema pasarela implementado (fig.2).
Figura 2: Imagen del sistema desarrollado.
En la parte superior se puede observar el lector/escritor de tags. Situado a la derecha de la
placa, el dispositivo Bluetooth, en este caso WT-12 con todo el hardware de acondicionamiento
asociado al dispositivo. A la izquierda se encuentra el sistema hardware del microprocesador,
entre éste y el WT-12 se encuentra el zumbador. Por último los diodos leds se encuentran
situados en la parte superior, junto a la bornera de alimentación externa.
El sistema pasarela es un sistema abierto desde el punto de vista hardware permitiendo
integrar un gran número de sensores haciendo usos de las interfaces disponibles del
microprocesador, como se puede observar en otros diseños de sistemas pasarela [8].
Desde el punto de vista del desarrollo de aplicaciones, se han implementado varios
137
programas de ejemplo en ANSI C para la conexión con dispositivos remotos provistos de
Bluetooth. Se ha optado por desarrollar las aplicaciones empleando la librería de desarrollo de
BlueZ [9], que nos otorga una extensa API para el manejo de conexiones Bluetooth. Dado que
BlueZ está desarrollada en C bajo licencias de código abierto, es posible tener un control total
sobre la implementación realizada, lo que ofrece numerosas ventajas desde el punto de vista
educativo. Por otro lado, BlueZ es nativa para sistemas UNIX, de manera que viene integrada
por defecto en la mayoría de distribuciones Linux más conocidas, con lo que las dependencias
de paquetes y compatibilidades con las distintas arquitecturas son absolutas.
Algunos de los usos y vertientes didácticas de este tipo de aplicaciones son las siguientes:
Modo espía, o aplicaciones simples que nos permiten tener una visión en pantalla de
las tramas Bluetooth recibidas y realizar un análisis de las mismas para comprobar
cómo se realizan los procesos de búsqueda, de apertura o cierre de una conexión en
Bluetooth.
Iniciador de aplicaciones en local, actuando la conexión entrante como iniciador de
procesos corriendo en local e incluso pasándoles condiciones y/o parámetros a los
mismos. Este tipo de aplicaciones permite integrar el sistema con otras aplicaciones
realizadas en clase, o para dar una visión de cómo otras ramas del conocimiento,
por ejemplo la domótica, podrían hacer uso de estos sistemas.
Conexión con aplicaciones en remoto, como servicios web, actuando la conexión
entrante como lanzadora del proceso cliente que consume el servicio, permitiendo, a
su vez, añadirle condiciones y parámetros a éste.
Cabe destacar que este tipo de aplicaciones ofrecen una visión más software del sistema, y
ofrecen la posibilidad de analizar otras áreas temáticas como son el desarrollo de aplicaciones,
el manejo de APIs, la realización de arquitecturas productor-consumidor o cliente-servidor, el
trabajo a distintos niveles de abstracción (desde conexiones a sockets RFCOMM para el
Bluetooth hasta manejo de servicios web), la generación de aplicaciones multi-hilo y
multiproceso (llamadas al sistema, forks-joins, OpenMP, MPI, regiones críticas, semáforos,
señales, etc.), el trabajo con interfaces de entrada-salida, y prácticamente cualquier integración a
nivel de software que didácticamente creamos conveniente. Aunque toda la implementación está
desarrollada en C, todas las funcionalidades y beneficios para el alumno son perfectamente
extrapolables usando cualquier otro lenguaje de propósito general, ya que otras opciones, como
Java, incluyen sus propias APIs para trabajo con dispositivos y manejo de conexiones
Bluetooth. Por otro lado, el desarrollo de aplicaciones para dispositivos móviles es también
posible haciendo uso de la propia librería BlueZ (para dispositivos con arquitecturas y con
distribuciones Linux soportadas), de opciones en Java (para terminales con máquina virtual
instalada) o empleando .NET (para terminales con Windows Mobile o similar).
La realización de aplicaciones de escritorio para la parte relacionada con el dispositivo NFC
ofrece opciones como el uso de la API de la librería LibNFC [10].
Aplicación al Laboratorio de Instrumentación Electrónica Este sistema va a ser empleado en el Laboratorio de Instrumentación Electrónica de 5º curso
de la titulación de Ingeniero de Telecomunicación, como complemento para la formación
práctica de los alumnos. Se trata de una asignatura práctica en la que los alumnos trabajan en
grupos usando diferentes equipos de instrumentación como osciloscopios, analizadores de
espectro, multímetros, analizadores lógicos, etc. Las prácticas están estructuradas en dos grupos.
El primero, contiene prácticas guiadas, explicadas paso a paso. En estas prácticas, los alumnos
aprenden y revisan el manejo básico de los aparatos de instrumentación, usándolos para obtener
medidas en circuitos sencillos. El segundo grupo contiene prácticas donde los alumnos tienen
que usar todo el conocimiento que han aprendido durante el primer grupo de prácticas, junto con
otros conocimientos adquiridos durante la carrera, para solucionar los problemas propuestos en
138
la práctica. Dado que esta asignatura pertenece al 5º curso, los alumnos ya tienen conocimientos
de instrumentación, y aunque se supone que son capaces de manejar la mayoría de los aparatos,
es aconsejable recordarles su uso. En esta estructura se han detectado algunos problemas, entre
ellos destaca la falta de aplicación directa de los circuitos sobre los que se trabaja.
Con el uso de esta plataforma de aprendizaje se pretende motivar al alumno mediante el
empleo en aplicaciones prácticas reales de dispositivos electrónicos inalámbricos cotidianos.
Para ello, se han planificado diversas sesiones de trabajo en las que los alumnos serán
introducidos en el uso de las distintas tecnologías involucradas en el sistema desarrollado, hasta
llegar al grado de conexionarlas formando el sistema pasarela completo. A continuación se
esboza el contenido de las distintas sesiones planificadas:
Familiarización con dispositivos embedded Bluetooth, y en el manejo y envío de
comandos ASCII mediante comunicación serie desde un PC hasta los dispositivos WTs,
para su configuración y el establecimiento de las comunicaciones Bluetooth.
Manejo del lector/escritor de tags mediante un PC con comunicación serie. Estructura
de memoria de los distintos tags, login de sectores, escritura y lectura de bloques de
memoria.
Introducción a las librerías BlueZ de Linux y uso de las mismas con dispositivos
“dongles” USB.
Desarrollo del sistema pasarela NFC-Bluetooth. Programación del microprocesador
Atmega y uso de la aplicación de depuración.
Inserción de la comunicación del sistema pasarela con dispositivos móviles.
Desarrollo de un programa de aplicación en el PC o en el teléfono móvil para mostrar
los resultados del sistema de aprendizaje.
Para la evaluación del grado de satisfacción de los alumnos y el nivel de conocimiento
adquirido con la experiencia planteada, se ha desarrollado un cuestionario en el cual los
alumnos podrán calificar de 1 (poco satisfactorio) a 5 (muy satisfactorio) el grado de
satisfacción con cada una de las sesiones desarrolladas. En este cuestionario también se pide que
se evalúe al profesorado, por lo que el cuestionario es totalmente anónimo para que los alumnos
puedan expresar sin temor todos sus pensamientos. Además se invita a los alumnos a que
expresen su opinión sobre la experiencia y posibles mejoras que se puedan incluir para futuros
años.
4. Conclusión En este trabajo se presenta una plataforma para la realización de prácticas relacionadas con
la programación de sistemas empotrados, microcontroladores de bajo coste, dispositivos de
comunicación inalámbrica NFC y Bluetooth. El sistema propuesto constituye una herramienta
docente novedosa y útil en asignaturas de últimos cursos y carácter eminentemente práctico,
como es el caso del Laboratorio de Instrumentación Electrónica en el que se utilizará el sistema,
puesto que acerca aplicaciones de tipo práctico y reales al alumno. Trabajar con sistemas reales
permitirá atraer la atención de los alumnos, ayudándoles a comprender mejor la utilidad de los
conocimientos adquiridos a lo largo de la carrera. Finalmente, la amplia funcionalidad del
sistema desarrollado permitirá a los alumnos desarrollar infinidad de aplicaciones prácticas con
dispositivos móviles de uso diario.
Referencias [1] Dean A.Gratton. Developing Practical Wireless Applications 216-224.
[2] ECMA_International. Near Field Communication –white paper-(2004).
[3] Bluetooth SIG, Bluetooth Baseband Specification, version 2.1+EDR, www.bluetooth.org.
[4] Bluetooth SIG, Host Controller Interface Functional Specification, version 2.1+EDR,
www.bluetooth.org.
[5] C.Y.Leong, K.C.Ong, K.K.Tan*, O.P.GAN, Near Field Communication and Bluetooth Bridge
System for Mobile Commerce. IEEE International Conference on Industrial Informatics 50-55
139
(2006). [6] M. Sallinen, E. Strömer, A. Ylisaukko-oja. Sensor Technologies and applications,
SENSORCOMM’08. Second International Conference586-591 (2008).
[7] G. Matas, I. Luque, M.A. Gómez-Nieto. How NFC can be used for compliance of European Higher
Education Area Guidelines in European Universities. Near Field Communication NFC’09, first
international workshop 3-8 (2009).
[8] H. Mika, H. Mikko, A. Ylisaukko-oja. Practical implementation of passive and semi-passive NFC
enabled sensor. Near Field Communication NFC’09, first international workshop 69-75 (2009).
[9] Página oficial del proyecto Bluez http://www.bluez.org/
[10] Página oficial del proyecto LibNFC http://www.libnfc.org/
140
PLATAFORMA PARA EL APRENDIZAJE DE TECNOLOGÍAS
INALÁMBRICAS Y REDES DE SENSORES BASADA EN EL
SISTEMA OPEN HARDWARE DENOMINADO OPENMOKO
J.M. HINOJO, D. GUTIÉRREZ, E. MARSAL, M. SOTO, F. CORTES, F. BARRERO, S.
TORAL
Departamento de Ingeniería Electrónica. Escuela Superior de Ingenieros. Universidad de
Sevilla. España
[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected]
Resumen de la comunicación Los mecanismos de gestión y transmisión de contenidos e información están sufriendo en
la actualidad un desarrollo frenético, favorecidos por el desarrollo de la sociedad de la
información y, sobre todo, de las tecnologías electrónicas. Dentro de estos nuevos mecanismos
cabe destacar los estándares de comunicaciones inalámbricas, que permiten la interconexión de
sistemas dotados de una cierta inteligencia, como pueden ser los sistemas empotrados,
formando complejas redes sin cables. Hoy en día, estándares como Bluetooth o Zigbee se han
abierto un importante hueco a nivel industrial (recopilación de información extraída de sensores,
acción de control remota, etc.) o incluso comercial (cualquier teléfono móvil o PDA que se
precie de serlo incorpora en la actualidad la capacidad de comunicarse empleando el estándar
Bluetooth, lo que ha permitido desarrollar nuevos sistemas de información como son los
sistemas de navegación en interiores de edificios) gracias a las prestaciones que ofrecen: bajo
frente a tecnologías como Wifi y una capacidad de transmisión de datos relativamente alta.
No obstante, la formación que los alumnos de Ingeniería reciben sobre este tipo de
sistemas es fundamentalmente teórica y carece de la necesaria visión práctica por la dificultad
que supone desarrollar un sistema sencillo con el que los alumnos puedan trabajar y adquirir
destrezas profesionales en un tiempo razonable. Para intentar mejorar la visión práctica que el
alumnado adquiere sobre el manejo de sistemas de comunicación inalámbricos, en el
Departamento de Ingeniería Electrónica de la Escuela Superior de Ingenieros de Sevilla se está
llevando a cabo un importante esfuerzo en pro de la remodelación de las prácticas de las
diferentes asignaturas que tiene adscritas. Este es el caso de dos asignaturas denominadas
“Complementos de Sistemas Electrónicos Digitales” y “Laboratorio de Instrumentación
Electrónica” y, pertenecientes a 3er y 5º curso, respectivamente, de la titulación de Ingeniería de
Telecomunicación. Ambas asignaturas aúnan esfuerzos en la actualidad para desarrollar nuevas
prácticas que permitan al alumno tener una visión más clara y práctica sobre el manejo de los
sistemas electrónicos de comunicación y, en concreto, de los estándares inalámbricos. Los
estándares WiFi y Bluetooth son algunos de los sistemas de comunicación inalámbrica que
centran estos nuevos desarrollos. En este sentido, y dada las asignaturas involucradas en la
experiencia, parece adecuado el desarrollo de actividades de tipo práctico que involucren al
alumno con el manejo de los sistemas empotrados y el análisis y estudio de sistemas
microprocesadores y microcontroladores actuales, con la caracterización de enlaces
inalámbricos basados en Bluetooth. En esta dirección se encamina la propuesta docente
planteada en este artículo: el desarrollo de un sistema que permita al alumno familiarizarse de
forma práctica con el manejo de una tecnología inalámbrica tan extendida como Bluetooth,
mediante la programación de sistemas empotrados.
Referencias [1] Página oficial del proyecto Openmoko. http://wiki.openmoko.org/wiki/Main_Page
[2] Albert S. Huang, Larry Rudolph. Bluetooth essentials for programmers,. Cambridge University
Press (2007).
[3] Robert Morrow. Bluetooth operation and use, McGraw-Hill (2002).
141
[4] H. Schildt. C:Manual de referencia. McGraw-Hill (2002).
[5] Bluetooth SIG. Core Specification v2.1 + EDR. http://www.bluetooth.com
[6] Ian McLoughlin. Secure embedded systems: the threat of reverse engineering. 14th
IEEE
International Conference on Parallel and Distributed Systems. pp. 729-736. (2008).
PLATAFORMA PARA EL APRENDIZAJE DE TECNOLOGÍAS
INALÁMBRICAS Y REDES DE SENSORES BASADA EN EL
SISTEMA OPEN HARDWARE DENOMINADO OPENMOKO
J.M. HINOJO, D. GUTIÉRREZ, E. MARSAL, M. SOTO, F. CORTES, F. BARRERO, S.
TORAL
Departamento de Ingeniería Electrónica. Escuela Superior de Ingenieros. Universidad de
Sevilla. España
[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected]
La enseñanza relacionada con las tecnologías electrónicas requiere
acercar al alumno complejos sistemas, como son aquellos que se
relacionan con las comunicaciones inalámbricas. Para conseguir este
acercamiento se ha desarrollado un sistema para la realización de
prácticas basado en un dispositivo comercial “Open Hardware”
denominado Openmoko, que permite la caracterización del enlace
inalámbrico y, a su vez, potencia la creatividad del alumno en la
aplicación de estas tecnologías.. El sistema genera un enlace
inalámbrico haciendo uso de un sistema empotrado comercial, un PC
y una suite de aplicaciones con las que se pueden realizar prácticas
en asignaturas adscritas a la titulación de Ingeniería de
Telecomunicación e impartida por el Departamento de Ingeniería
Electrónica de la Escuela Superior de Ingenieros de Sevilla.
1. Introducción Los mecanismos de gestión y transmisión de contenidos e información están sufriendo en
la actualidad un desarrollo frenético, favorecidos por el desarrollo de la sociedad de la
información y, sobre todo, de las tecnologías electrónicas. Dentro de estos nuevos mecanismos
cabe destacar los estándares de comunicaciones inalámbricas, que permiten la interconexión de
sistemas dotados de una cierta inteligencia, como pueden ser los sistemas empotrados,
formando complejas redes sin cables. Hoy en día, es habitual encontrar gran cantidad de
sistemas interconectados entre sí, empleando estándares como GPS, GPRS, WiFi, Bluetooth o
Zigbee. Aunque los sistemas de comunicaciones inalámbricos por excelencia son las redes
WiFi, utilizadas profusamente en el mundo de la informática de consumo, otros estándares
como Bluetooth o Zigbee, de menor alcance y tasa de transferencia de información pero
también de mucho menor consumo, se han abierto un importante hueco a nivel industrial
(recopilación de información extraída de sensores, acción de control remota, etc.) o incluso
comercial (cualquier teléfono móvil o PDA que se precie de serlo incorpora en la actualidad la
capacidad de comunicarse empleando el estándar Bluetooth, lo que ha permitido desarrollar
nuevos sistemas de información como son los sistemas de navegación en interiores de
edificios).
No obstante, la formación que los alumnos de Ingeniería reciben sobre este tipo de
sistemas es fundamentalmente teórica y carece de la necesaria visión práctica por la dificultad
que supone desarrollar un sistema sencillo con el que los alumnos puedan trabajar y adquirir
destrezas profesionales en un tiempo razonable. Otro inconveniente asociado a este tipo de
142
sistemas es su indefinición programática, adscrita en simultáneo a áreas de conocimiento
diferentes como son la tecnología electrónica, la teoría de las señales y las comunicaciones o la
telemática. Para intentar mejorar la visión práctica que el alumnado adquiere sobre el manejo de
sistemas de comunicación inalámbricos, en el Departamento de Ingeniería Electrónica de la
Escuela Superior de Ingenieros de Sevilla se está llevando a cabo un importante esfuerzo en pro
de la remodelación de las prácticas de las diferentes asignaturas que tiene adscritas. Este es el
caso de dos asignaturas denominadas “Complementos de Sistemas Electrónicos Digitales” y
“Laboratorio de Instrumentación Electrónica” y, pertenecientes a 3er y 5º curso,
respectivamente, de la titulación de Ingeniería de Telecomunicación. Ambas asignaturas aúnan
esfuerzos en la actualidad para desarrollar nuevas prácticas que permitan al alumno tener una
visión más clara y práctica sobre el manejo de los sistemas electrónicos de comunicación y, en
concreto, de los estándares inalámbricos. Los estándares WiFi y Bluetooth son algunos de los
sistemas de comunicación inalámbrica que centran estos nuevos desarrollos. En este sentido, y
dada las asignaturas involucradas en la experiencia, parece adecuado el desarrollo de
actividades de tipo práctico que involucren al alumno con el manejo de los sistemas empotrados
y el análisis y estudio de sistemas microprocesadores y microcontroladores actuales, con la
caracterización de enlaces inalámbricos basados en Bluetooth. En esta dirección se encamina la
propuesta docente planteada en este artículo: el desarrollo de un sistema que permita al alumno
familiarizarse de forma práctica con el manejo de una tecnología inalámbrica tan extendida
como Bluetooth, mediante la programación de sistemas empotrados.
2. Descripción del sistema El sistema implementado se basa en un PC dotado de conectividad Bluetooth y
ejecutando una distribución de Linux, un dispositivo empotrado conocido como OpenMoko
(Fig. 1) y un conjunto de aplicaciones que permiten a los alumnos caracterizar, mediante la
obtención de datos experimentales, los enlaces Bluetooth. Algunas de las características más
destacables que se pueden estudiar son el establecimiento de conexiones mediante la búsqueda
de servicios por parte de la aplicación cliente, cómo afecta a la búsqueda el publicar servicios de
carácter privado o cómo se reconocen dichos servicios por dispositivos comerciales como puede
ser un teléfono móvil.
Con respecto al PC, se ha utilizado un ordenador de sobremesa de arquitectura x86,
arquitectura con la cual el alumno está familiarizado. La distribución de Linux instalada en el
equipo se corresponde con una distribución Ubuntu 9.04. La elección de esta distribución se
debe, en primer lugar, a que dispone de una extensa comunidad de soporte. De esta forma, si un
alumno se encuentra con algún problema puede recurrir a simples buscadores web, como
Google, o a foros especializados en esta distribución para resolverlo (se fomentaría así el
autoaprendizaje y la búsqueda de información por parte del alumno).En segundo lugar, a la gran
cantidad de paquetes software existentes para esta distribución, lo que permite tener actualizado
el sistema cómodamente, así como instalar librerías adicionales de una manera muy sencilla y
cómoda. Por último, la semejanza de las estructuras de ficheros a las distribuciones de tipo
Debian, lo que supone un punto de partida avanzado debido a nuestra experiencia con este tipo
de sistemas operativos.
Ubuntu se adapta, por tanto, a las exigencias que se le podrían imponer a una distribución
de Linux destinada a fines educativos. En cuanto a las herramientas de compilación para el PC,
se suministrará el compilador gcc, que cuenta además con la ventaja de que se encuentra
incorporado dentro del sistema operativo como una utilidad más. El desarrollo de aplicaciones
mediante compilación cruzada permite, además, que el alumno se familiarice con un proceso de
diseño económico, ya que la programación y compilación se realiza en una máquina diferente al
sistema empotrado, ahorrando tiempo y costes en el desarrollo.
143
Figura 1. Sistema Openmoko denominado Neo FreeRunner.
Por otro lado, el otro dispositivo que formará parte del sistema de comunicaciones
inalámbricas basado en Bluetooth será un teléfono móvil de carácter libre denominado
Openmoko, en concreto la versión Neo FreeRunner. Este terminal se corresponde con un
proyecto de hardware y software abierto destinado a usuarios avanzados para que puedan
personalizar el teléfono móvil para satisfacer sus necesidades. Se caracteriza por disponer de un
microprocesador Samsung S3C2442B, cuya principal característica es que presenta una
arquitectura ARM920T a 400 MHz. Este tipo de arquitecturas (ARM9x) se están implantando
rápidamente en los sistemas empotrados y móviles de comunicaciones debido a su elevada
potencia de cálculo, su bajo consumo y el bajo coste de desarrollo que presenta. Por su parte, el
uso de la misma supone que, a la hora de realizar los códigos fuentes de los programas a
ejecutar en esta plataforma, debamos hacer uso de la compilación cruzada para poder obtener un
ejecutable válido para el procesador en cuestión. Otras ventajas adicionales que ofrece
Openmoko son los dos acelerómetros disponibles (ubicados en diferentes posiciones para poder
realizar las correcciones pertinentes a las medidas obtenidas) o la conectividad GPRS, GSM,
Bluetooth con chipset CSR BlueCore 4, 802.11g y GPS, entre otras. Como se puede comprobar,
se corresponde con un sistema empotrado que permite su uso en una gran cantidad de
aplicaciones diferentes, permitiendo que el alumno pueda investigar y desarrollar tareas en áreas
de conocimientos que involucren las comunicaciones inalámbricas o los sistemas de
instrumentación, medida y adquisición de datos.
El sistema operativo que gobierna Openmoko es una distribución de Linux para
dispositivos móviles con un kernel 2.6.24, de forma que puede aprovecharse para que el alumno
adquiera abundantes conocimientos sobre la programación de dispositivos móviles basada en el
kernel de Linux. El motivo por el que se optó por usar un sistema operativo libre y no uno
privado, como puede ser Symbian o Windows Mobile, se debe a que es de código abierto, lo
que implica un control absoluto de las aplicaciones externas adquiridas. Además, se dispone de
una amplia libertad de uso y desarrollo de aplicaciones (Fig. 2), así como de la existencia de un
amplio soporte por parte de desarrolladores externos. Por ejemplo, existencia de una extensa
API de programación que permite simplificar tareas como la lectura de acelerómetros o leer la
señal del GPS. Por otro lado, se consigue una gran reutilización de las aplicaciones
desarrolladas. Finalmente, se estima que la creación de aplicaciones será rápida puesto que al
ejecutar Linux, el usuario del sistema únicamente debe conocer el funcionamiento del mismo
(algo muy habitual en la actualidad) para empezar a diseñar y construir una primera aplicación.
En cuanto a los dispositivos usados para establecer el sistema destinado a la realización
de las prácticas, en principio se ha implementado un enlace Bluetooth empleando dispositivos
comerciales, dongle USB con chipset CSR BlueCore 4 compatible con la versión 2.1 del
estándar Bluetooth. Esto permite realizar tareas como la modificación de la potencia de
transmisión durante el proceso de inquiry, realizar búsquedas en modo RSSI extendido o
aumentar la velocidad de transferencia. El motivo de la elección de un enlace Bluetooth para las
primeras experiencias es su profusión a nivel comercial, lo que se prevé provoque cierto interés
por parte de los alumnos. En cuanto al tipo de dongle seleccionado, se escogió uno cuyo chipset
144
fuese compatible con la versión 2.1 del estándar Bluetooth para que el alumno pudiese
experimentar con todos los comandos de la capa HCI que permiten configurar la comunicación
inalámbrica a bajo nivel.
Figura 2. Estructura software del dispositivo Neo FreeRunner.
Finalmente, para dotar de una cierta funcionalidad a esta plataforma de aprendizaje
hemos desarrollado una aplicación que sigue una arquitectura de tipo cliente-servidor. Para ello,
hacemos uso del protocolo SDP (Service Discovery Protocol) o Protocolo de Descubrimiento de
Servicios. Este protocolo permite a los programas clientes descubrir la existencia de diversos
servicios proporcionados por uno o varios servidores de aplicaciones, junto con los atributos y
propiedades de los servicios que se ofrecen. Estos atributos incluyen el tipo o clase de servicio
ofrecido y el mecanismo o la información necesaria para utilizar los mismos.
SDP se basa en una determinada comunicación entre un servidor que contiene los
servicios ofrecidos y un cliente que desea algún servicio específico. El servidor mantiene una
lista de registros de servicios, los cuales describen las características de estos. Cada registro
contiene información sobre un determinado servicio. Para recuperar la información asociada a
alguno de estos registros, el cliente debe realizar una petición SDP. Si el cliente o la aplicación
asociada con el cliente deciden utilizar un servicio, deben establecer una conexión
independiente con el servicio en cuestión. SDP proporciona un mecanismo para el
descubrimiento de servicios y sus atributos asociados, pero no proporciona ningún mecanismo
ni protocolo para utilizar dichos servicios. Es en este punto donde se establece una
comunicación RFCOMM (Fig. 3), que se corresponde con la emulación de un puerto serie para
transmitir información a través de él.
Figura 3. Enlace de comunicación establecido por RFCOMM.
Por su parte, un cliente SDP normalmente realiza una búsqueda de servicios acotada por
determinadas características. No obstante, hay momentos en los que resulta deseable descubrir
todos los servicios ofrecidos por un servidor SDP sin que pueda existir ningún conocimiento
previo sobre los registros que pueda contener. Este proceso de búsqueda de cualquier servicio
ofrecido se denomina navegación o browsing.
La tecnología inalámbrica Bluetooth hace un uso muy amplio de procesos de
145
descubrimiento que permiten a los dispositivos identificarse entre sí cuando entran dentro del
radio de acción, y establecer las conexiones apropiadas para que los dispositivos puedan
ejecutar las aplicaciones comunes y acceder a varios servicios. Por medio del descubrimiento de
servicios, las redes personales son básicamente autoconfigurables. Esto, a su vez, hace a los
dispositivos portátiles muy sencillos de utilizar. En consecuencia, las conexiones son
enteramente transparentes para el usuario y no requieren asistentes de instalación ni
configuraciones en línea.
3. Aplicación del sistema Para ayudar a los alumnos a familiarizarse con el sistema propuesto, se han desarrollado
una aplicación de tipo servidor que ofrece servicios y un programa cliente que realiza la
búsqueda de estos servicios. En el caso del servidor, el programa se encargará de atender las
peticiones del cliente suministrándole los ficheros de las páginas del menú solicitadas. También
deberá registrar un servicio SDP que permita al cliente identificar al equipo en concreto. El
cliente, por contra, deberá poder buscar un equipo a partir de un determinado servicio, así como
solicitar los ficheros asociados a las entradas de los menús visitados y procesarlos. La idea
desarrollada ha consistido en aprovechar el protocolo SDP para poder descubrir aquellos
dispositivos que pertenezcan a nuestra aplicación para posteriormente solicitarle un inicio de
conexión y poder realizar el envío de información a través del enlace establecido (Fig. 4). Por
tanto, tendríamos el programa que actúa como servidor en el PC o en una máquina remota. Éste,
al arrancar, registrará en una tabla los servicios que dicha máquina es capaz de soportar. Este
servicio deberá ser público para que el cliente, la aplicación a ejecutar en el terminal móvil,
pueda realizar una búsqueda del mismo y encontrarlo. Una vez que se haya registrado, el
servidor deberá quedar a la escucha de una petición de conexión. Por otro lado, el programa
cliente, lo primero que tendrá que realizar al arrancar es un escaneo de los dispositivos que tiene
a su alcance para que, una vez detectados todos, pueda realizar una consulta a cada uno de ellos
para determinar si el servicio que se solicita está disponible. En caso de encontrarlo, deberá
solicitar los atributos que posee dicho servicio para poder configurar la petición de conexión.
Una vez configurada, se solicitará el inicio de una comunicación mediante el establecimiento de
una conexión RFCOMM al canal donde el servidor se encuentra a la escucha. Tras la detección
del equipo remoto con el programa servidor, y el correspondiente establecimiento de conexión,
el cliente solicitará el fichero principal de configuración de los menús, que albergará la temática
de las entradas, y los procesará, identificando aquellas líneas que hagan referencia a texto plano
a mostrar en la ventana y a botones que contengan las entradas de los menús.
146
Figura 4. Estructura básica de la aplicación cliente y servidor desarrollada.
El funcionamiento de la aplicación desarrollada, fue comprobado mediante dos pruebas.
Una primera en la que se modificó el tiempo de búsqueda del servidor por parte del cliente
(buscando minimizar el tiempo que el cliente debe esperar para poder encontrar al servidor), y
una segunda en la que se declaró un servicio como privado para comprobar que verdaderamente
dicho servicio quedaba oculto al cliente. A continuación, se muestran los resultados obtenidos
(Fig. 5)(Fig. 6). Como se puede observar, esta aplicación sirve como una muestra del potencial
que este sistema de comunicaciones inalámbricas posee y la diversidad de proyectos en los que
se puede aplicar.
RFCOMM
USUARIO
OPENMOKO SERVIDOR SERVICIOS SDP
147
Figura 5. Pruebas de las aplicaciones cliente y servidor. Ejecución del servidor.
Figura 6. Pruebas de las aplicaciones cliente y servidor. Ejecución del cliente.
148
4. Aplicación académica El sistema desarrollado tendrá como finalidad su aplicación en prácticas tanto en cursos
introductorios a los sistemas microprocesadores basados en DSPs como puede ser
“Complementos de Sistemas Electrónicos Digitales” como en las asignaturas de último curso,
donde se le presuponen al alumno los conocimientos suficientes como para poder sacarle el
máximo provecho al sistema mediante la realización de trabajos prácticos. En función del nivel
del curso en el que se utilice se pueden adaptar las prácticas.
Así, por ejemplo, en las asignaturas de cursos inferiores se puede emplear el sistema para
introducir a los alumnos en el proceso de compilación cruzada, de tal forma que sean ellos los
que realicen una aplicación sencilla que haga uso del algún módulo del sistema desarrollado.
Esto les permitirá adquirir pericia con el proceso de realización de programas para
microprocesadores. Con este fin, tendrán que codificar y compilar en el PC un programa
mediante el uso del compilador cruzado y las librerías necesarias para, finalmente, descargarlo
en el sistema Openmoko donde se ejecutaría y depuraría.
Para facilitar esta labor y como parte del sistema diseñado, se desarrolló una API de libre
disposición para los alumnos, interfaz de programación que permite leer los valores de los
acelerómetros del terminal Openmoko. De esta forma, el alumno puede hacer uso de las
funciones incluidas en la API para realizar una lectura del acelerómetro y en función del valor
obtenido generar una respuesta u otra en la pantalla del dispositivo.
Por otra parte, en los últimos cursos, los alumnos poseen un mayor conocimiento de
diversas disciplinas como telemática, teoría de la señal o electrónica. Esto permitiría sacarle un
mayor provecho al sistema puesto que en este caso, pueden aplicar los conocimientos
adquiridos en estas parcelas para aplicarlos en la creación de complejas aplicaciones. Como
ejemplo de posibles proyectos que se les podría asignar a los alumnos se podría mencionar el
diseño de redes distribuidas de procesamiento basados en un sistema inalámbrico de
comunicaciones como el diseñado, aplicaciones de tipo cliente/servidor que hagan uso de
servicios web o el diseño e implementación de algoritmos de posicionamiento.
5. Conclusión Se ha desarrollado una plataforma de comunicaciones inalámbricas, basada en el estándar
Bluetooth, para motivar a los alumnos de Ingeniería mediante el uso de dispositivos electrónicos
de consumo. El sistema desarrollado es una herramienta novedosa y versátil que permite realizar
prácticas a alumnos de los primeros cursos y a aquellos que se haya cerca de finalizar sus
estudios. El hecho de hacer uso de un sistema “open hardware” como es Openmoko permite
ofrecer al alumno un sistema atractivo al alumnos, además de ofrecerle un entorno (incluido el
sistema operativo) totalmente configurable por él. La existencia de una comunidad de
desarrolladores detrás del dispositivo seleccionado permite reducir los tiempos de aprendizaje,
aumentar los conocimientos adquiridos y fomentar el autoaprendizaje y la búsqueda de
información por parte de los alumnos, cualidades que resultarán muy beneficiosas en su futura
actividad profesional.
Referencias [1] Página oficial del proyecto Openmoko. http://wiki.openmoko.org/wiki/Main_Page
[2] Albert S. Huang, Larry Rudolph. Bluetooth essentials for programmers,. Cambridge University
Press (2007).
[3] Robert Morrow. Bluetooth operation and use, McGraw-Hill (2002).
[4] H. Schildt. C:Manual de referencia. McGraw-Hill (2002).
[5] Bluetooth SIG. Core Specification v2.1 + EDR. http://www.bluetooth.com
[6] Ian McLoughlin. Secure embedded systems: the threat of reverse engineering. 14th
IEEE
International Conference on Parallel and Distributed Systems. pp. 729-736. (2008).
149
SISTEMA DE ORIENTACIÓN BASADO EN BRÚJULA
ELECTRÓNICA PARA LA REALIZACIÓN DE PRÁCTICAS
J.M. HINOJO, D. GUTIÉRREZ, E. MARSAL, M. SOTO, F. CORTÉS, F. BARRERO, S.
TORAL
Departamento de Ingeniería Electrónica. Escuela Superior de Ingenieros. Universidad de
Sevilla. España
[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected]
Resumen de la comunicación En la actualidad, los terminales móviles, tales como teléfonos móviles, PDAs o Pocket
PCs, se han convertido en dispositivos multimedia que son capaces de ofrecer una gran cantidad
de servicios y funciones muy diferentes de la principal. Este hecho se debe sobre todo al bajo
coste que supone fabricar los sensores necesarios para poder dotar a dichos dispositivos de esas
funcionalidades añadidas. La extraordinaria difusión en dispositivos comerciales de elementos
tales como acelerómetros o brújulas electrónicas motivan a los usuarios de estos, entre los que
se encuentran especialmente los alumnos de Ingeniería. Este interés hacia dispositivos
habitualmente asociados a consolas para juegos y terminales móviles de última generación,
pretende ser aprovechado para incrementar la atención y la motivación de los alumnos adscritos
a la titulación de Ingeniería de Telecomunicación de la Universidad de Sevilla. Se ha
desarrollado un sencillo sistema digital de orientación, basado en una brújula electrónica y
conectado a un microprocesador empleando un puerto I2C. El objetivo perseguido es disponer
de un dispositivo versátil que pueda ser empleado en las prácticas de la asignatura para que el
alumno adquiera conocimientos prácticos sobre el diseño de circuitos de adaptación de señales,
manejo e interpretación de instrumentación electrónica como analizadores lógicos,
programación de microprocesadores y gestión de periféricos de comunicaciones como el I2C o
el SPI, y desarrollo de aplicaciones relacionadas con la gestión del sistema de orientación como
la realización de algoritmos que permitan optimizar el proceso de orientación haciendo uso del
sensor magnético.
Referencias [1] Michael J. Caruso. Applications of Magnetic Sensors for Lof Cost Compass Systems. Honeywell,
SSEC.
[2] Dominique Paret. El Bus I2C: de la teoría a la práctica. Paraninfo (1995).
[3] Francisco Rogelio Palomo Pinto, Alfredo Pérez Vega-Leal, Eduardo Galván. Problemas resueltos
de instrumentación electrónica. Universidad de Sevilla (2006).
[4] Miguel A. Pérez García. Instrumentación electrónica. Thomson-Paraninfo (2008).
[5] Karim Yaghmour. Building Embedded Linux Systems. O´Reilly Media (2003).
[6] Gert van der Horn, Johan L. Huijsing. Integrated smart sensors: desgin and calibration. Kluwer
Academic Publishers (1998).
[7] F. Cortés, S. Gallardo, F. Barrero, S. Toral. Plataforma para el desarrollo de sensores inteligentesy
sistemas microprocesados. 7o Congreso de Tecnologías Aplicadas a la Enseñanza de la Electrónica
(TAEE2006). Madrid (2006).
[8] Hua Sun, Peike Yang. Design and Research on Errors Compensation of Digital Compass.
Proceedings of the 2009 IEEE International Conference on Mechatronics and Automation. pp. 4742-
4747.
[9] Zhi Li, Xiang Li, Youngjun Wang. A Calibration Method for Magnetic Sensors and Accelerometer
in Tilt-compensated Digital Compass. The Ninth International Conference on Electronic
Measurement and Instruments. pp. 868-871, vol. 2, (2009).
[10] Hong-Shik Kim, Jong-Suk Choi. Advanced indoor localization using ultrasonic sensor and digital
compass. International Conference on Control, Automation and Systems. pp. 223-226. (2008)
150
SISTEMA DE ORIENTACIÓN BASADO EN BRÚJULA
ELECTRÓNICA PARA LA REALIZACIÓN DE PRÁCTICAS
J. M. HINOJO, D. GUTIÉRREZ, E. MARSAL, M. SOTO, F. CORTÉS, F. BARRERO, S.
TORAL
Departamento de Ingeniería Electrónica. Escuela Superior de Ingenieros. Universidad de
Sevilla. España
[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected]
En este trabajo se presenta el desarrollo de un sistema electrónico de
orientación, basado en diferentes brújulas electrónicas comerciales,
para la enseñanza práctica en un Laboratorio de Instrumentación
Electrónica. Se han analizado diferentes tipos de brújulas
electrónicas de dos y tres ejes para determinar la precisión obtenida
con vistas a ser usadas como sistemas de orientación electrónica. El
sistema desarrollado forma parte de un plan de renovación docente
llevado a cabo en la asignatura, adscrita a la titulación de Ingeniería
de Telecomunicaciones de la Universidad de Sevilla, con vistas a
aumentar la motivación de los alumnos en clase.
1. Introducción En la actualidad, los terminales móviles, tales como teléfonos móviles, PDAs o Pocket
PCs, se han convertido en dispositivos multimedia que son capaces de ofrecer una gran cantidad
de servicios y funciones muy diferentes de la principal. Este hecho se debe sobre todo al bajo
coste que supone fabricar los sensores necesarios para poder dotar a dichos dispositivos de esas
funcionalidades añadidas. La extraordinaria difusión en dispositivos comerciales de elementos
tales como acelerómetros o brújulas electrónicas motivan a los usuarios de estos, entre los que
se encuentran especialmente los alumnos de Ingeniería. Este interés hacia dispositivos
habitualmente asociados a consolas para juegos y terminales móviles de última generación,
pretende ser aprovechado para incrementar la atención y la motivación de los alumnos adscritos
a la titulación de Ingeniería de Telecomunicación de la Universidad de Sevilla. Se ha
desarrollado un sencillo sistema digital de orientación, basado en una brújula electrónica y
conectado a un microprocesador empleando un puerto I2C. El objetivo perseguido es disponer
de un dispositivo versátil que pueda ser empleado en las prácticas de la asignatura para que el
alumno adquiera conocimientos prácticos sobre el diseño de circuitos de adaptación de señales,
manejo e interpretación de instrumentación electrónica como analizadores lógicos,
programación de microprocesadores y gestión de periféricos de comunicaciones como el I2C o
el SPI, y desarrollo de aplicaciones relacionadas con la gestión del sistema de orientación como
la realización de algoritmos que permitan optimizar el proceso de orientación haciendo uso del
sensor magnético.
2. Descripción del sistema El sistema desarrollado se corresponde con un equipo prototipo destinado a la orientación
electrónica basado en una brújula digital, que es la encargada de realizar las mediciones del
campo magnético terrestre y determinar la desviación del sistema frente al norte magnético.
151
Para desarrollarlo, se analizaron diferentes sensores que actúan como brújulas electrónicas
(Tabla 1).
Los criterios de selección del sensor empleado son la precisión del sensor, su precio, las
características eléctricas del sensor y la forma de acceder al dispositivo. Los componentes
analizados pueden ser clasificados en dos grandes grupos: brújulas electrónicas de dos ejes y de
tres ejes. La principal diferencia entre ellas es la obtención de la medida del campo magnético
terrestre en el plano XY, o en un sistema de tres coordenadas. Puesto que el objetivo es poder
realizar una orientación fiable, el hecho de obtener el vector del campo magnético terrestre en
una base tridimensional permite tener caracterizado a dicho vector completamente, por lo que el
resultado obtenido podrá ser más preciso sin encarecer sobremanera el dispositivo final.
Modelo Hitachi
HM55B HMC 6352 V2Xe HMC 5843 1490
Alimentación
[V] 2,7 – 3,3 2,7 – 5,2 3 1,8 – 3,3 5
Sensibilidad
[uT] 1 – 1.6 10 – 75 1100 - -
Consumo
activo [mA] 9 - 13 1 2 - 25
Consumo
pasivo [uA] 1 - 5 1 0,2 - -
Ejes 2 2 2 3 -
Resolución 3° 0,5 ° 0,01° 1º 45°
Precisión - 2,5 ° 2° - -
Interfaz SSI I2C SPI I2C -
Tiempo de
medida [s] 0.040 - - 0,02-2 2,5
Dimensiones
[mmxmm] 0,762 x
0,762 6,6 x 6,5 x
1x5 2,54 x 2,54 x
1,2 0,4 x 0,4 x
0,13 -
Encapsulado 6 pin DIP 24 pin LCC - 25 pin LCC -
Precio [€] 14 26 50 19 15
Tabla 1. Sensores magnéticos analizados tras el proceso de búsqueda.
Por otro lado, una vez se seleccione la brújula es necesario considerar la problemática de
su sistema de referencia al adquirir las medidas[8,9]. Este efecto puede observarse en la figura
1. Cuando la brújula digital inicia el muestreo de los valores del campo magnético, éste los
expresa con respecto a su base, determinada por la posición en la que se haya el integrado con
respecto al suelo. Por tanto, necesitamos aplicar una transformación a los valores medidos para
poder obtener las proyecciones de los mismos en una base que pueda servir de referencia para
operar de forma independiente de la orientación del dispositivo. En concreto, si tomamos el
PCB del hardware desarrollado como el plano XY del sistema de referencia de la brújula, el eje
Z será el eje perpendicular a este plano. Si a continuación, tomamos la superficie de la Tierra
(las distancias manejadas en la aplicación permiten aproximar la Tierra como una superficie
plana) como el sistema de referencia en el que operar (Fig. 1), la brújula tendrá una cierta
orientación definida unívocamente mediante dos ángulos:
Roll o ángulo formado entre el eje Y de la brújula y el eje Yh del sistema de referencia
152
ubicado en la Tierra.
Pitch, que se corresponde con el ángulo formado por el eje X del sistema de referencia de
la brújula con el eje Xh de la Tierra.
Figura 1. Disposición de los ejes de la brújula y de la Tierra.
La orientación del PCB y, por extensión, de la brújula no tiene por qué coincidir con el
sistema de referencia tomado. Por tanto, las medidas que dé el sensor deberán ser corregidas en
la medida de lo posible. Para ello, se pueden usar distintas técnicas para resolver el problema:
1. Usar un inclinómetro. Esta solución contemplaría añadir un sensor más al sistema para
conocer en todo momento la inclinación de la brújula. De esta forma, los ángulos de
roll y pitch se podrían determinar de una manera muy sencilla puesto que tan sólo
sería necesario efectuar una lectura de los valores y sustituir en las fórmulas de
corrección que se adjuntan, para obtener los valores del campo proyectados en el
sistema de referencia ubicado en la Tierra. Así, sólo restaría realizar el arcotangente
del cociente entre Yh y Xh para obtener el ángulo de desviación con respecto al norte
magnético (Ec. 1)[1].
Xh=X·cos(φ)+Y·sen(θ)sen(φ)-Z·sen(φ) (1)
Yh=Y·cos(θ)+Z·sen(θ)
θ =roll
φ=pitch
2. Usar un acelerómetro. Esta segunda solución permitiría detectar los cambios de
aceleración que sufriese el dispositivo de forma que, analizando los signos del módulo
de la aceleración, se podría sacar la posición del PCB, es decir, los ángulos de roll y
pitch. Nuevamente, deberíamos aplicar las correcciones anteriores para poder obtener
la proyección del campo magnético terrestre en un sistema de ejes estático como
resulta ser el ubicado en la superficie de la Tierra.
3. Aplicar aproximaciones y cálculos matemáticos. Esta tercera opción es especialmente
interesante si se utiliza una brújula de tres ejes, y permite, a partir de las medidas
obtenidas por el sensor, realizar transformaciones para rotar la base de la brújula al
sistema de referencia ubicado en la Tierra. Para ello, es necesario conocer los ángulos
de roll y pitch del PCB respecto de la base terrestre. No obstante, si se presupone que
el usuario dispone del PCB en posición horizontal (cosa habitual al realizar el alumno
la práctica), se puede asumir que el ángulo roll puede ser pequeño, inferior a 20º. En
este supuesto, se pueden aproximar las funciones trigonométricas por sus series de
Taylor truncadas hasta el primer orden. Por tanto, el coseno se aproximaría como la
unidad y el seno se podría aproximar por su argumento. Con dicha aproximación, se
elimina una de las incógnitas y bastaría conocer el ángulo de pitch para poder obtener
153
una medida fiable del campo magnético terrestre.
Como se puede observar, las alternativas propuestas para resolver el problema de conocer
la orientación del dispositivo se han clasificado según la facilidad de la solución. La primera
solución resulta eficaz, rápida y sencilla. Sin embargo, el introducir un sensor más implicaría
complicar el hardware excesivamente. La segunda solución, basada en acelerómetro, permite
obtener medidas del ángulo de desviación de manera precisa a base de complicar más el
software y el hardware; necesitaríamos un algoritmo para determinar el ángulo del receptor
respecto del eje X e Y según las aceleraciones registradas. Además, se debería incluir un
segundo sensor, aumentando nuevamente la complejidad del PCB. La ventaja de esta solución
frente a la primera es que aunque acelerómetro complica el software, ofrece mayor versatilidad
al sistema desarrollado, pudiéndose emplear en un mayor número de aplicaciones. Finalmente,
la tercera solución es la menos precisa de todas, puesto que se basa en aproximaciones. No
obstante, es la solución más simple de las tres, dado que sólo requeriría una brújula electrónica
de tres ejes para llevar a cabo la determinación del ángulo de desviación con respecto al norte
magnético.
Tras el análisis de la problemática asociada a la medida, se opta por emplear una brújula
de 3 ejes por lo que de las brújulas analizadas (Tabla 1), la única que se adapta es el modelo
HMC5843 del fabricante Honeywell. El resto de brújulas sólo disponen de las medidas del
campo magnético en 2 ejes, cometiendo un error de precisión elevado (alcanzando hasta 20º de
error como en el caso de la brújula HM55B). La conexión al microprocesador del sistema es
simple al tratarse de una comunicación I2C que tan sólo utiliza dos líneas: I2C_DATA e
I2C_CLOCK (Fig. 2)[2].
Figura 2. Esquema de conexionado de la brújula.
Finalmente, el último componente está constituido por un sistema empotrado gobernado
por un procesador con arquitectura ARM desarrollado por la compañía Freescale. En concreto,
el núcleo del mismo corresponde con una arquitectura ARM926J-S cuya velocidad de
funcionamiento es de 266 MHz. Por tanto, se corresponde con un dispositivo que posee un gran
potencial tanto en aplicaciones de cómputo como en aquellas situaciones donde se requiera una
gran conectividad. Se caracteriza por presentar un puerto I2C, al cual conectaremos nuestro
sistema de orientación, cuatro UART, tres puertos CSPI, dos SSI y un puerto destinado a
aplicaciones de audio. Además, presenta tres temporizadores para poder realizar mediciones de
tiempo, un módulo PWM, líneas de entrada/salida de propósito general y diversos periféricos
más (Fig. 3)[5].
Sistema maestro
Brújula Circuito de
I2C Conexió
n
154
Figura 3. Diagrama de bloques del procesador ARM utilizado.
3. Aplicación del sistema El sistema presentado anteriormente se ha desarrollado para usarse en la asignatura
denominada “Complementos de Sistemas Electrónicos Digitales”, perteneciente al 3er
curso de
la titulación de Ingeniero de Telecomunicación. La idea es emplearlo como sistema de
adquisición de datos y periférico externo a un sistema empotrado basado en una CPU con
arquitectura ARM9. El microprocesador seleccionado dispone de una distribución de Linux
completamente funcional en su interior, lo que permitirá al alumno familiarizarse con las
técnicas de programación de periféricos en sistemas empotrados a alto nivel (sobre GNU/
Linux).
El dispositivo desarrollado posee una doble finalidad. Por un lado, se pretende que el
alumno potencie sus habilidades como diseñador de circuitos electrónicos interconectando el
sistema electrónico de orientación (periférico externo)[7] al sistema empotrado mediante el bus
I2C. Para ello deberá hacer un esfuerzo por entender los manuales de instrucciones de ambos
dispositivos y profundizar en el conocimiento del bus I2C. Por otro lado, el alumno deberá
desarrollar aplicaciones sobre sistemas operativos GNU/Linux, mediante el uso de APIs.
En consecuencia, se consigue ofrecer un entorno de desarrollo similar a otros comerciales
y usados en la industria electrónica. Además de esta labor, se tendrá que enfrentar también a la
tarea de interpretar los datos obtenidos del sensor y diseñar un algoritmo que pueda ser
implementable en el sistema empotrado. El objetivo final es que, en grupos de trabajo, se
desarrolle un sistema de orientación electrónico que pueda ser usado en aplicaciones de campo.
Para ello, el estudiante desarrollará una aplicación software que: permita fijar el norte
geográfico mediante un proceso de calibración, lea y procese los valores del campo magnético
terrestre obtenidos de la brújula electrónica y genere una salida con la desviación que el
dispositivo presente con respecto al norte geográfico (Fig. 4).
155
Figura 4. Captura de la comunicación entre la brújula electrónica y el sistema empotrado.
4. Conclusión En este artículo se ha presentado una nueva implementación electrónica a emplear en las
prácticas de la asignatura denominada “Complementos de Sistemas Electrónicos Digitales”, de
3er curso de la titulación de Ingeniero de Telecomunicación de la Universidad de Sevilla. Se ha
desarrollado un sistema de orientación electrónico que conecta dos dispositivos independientes
mediante un bus I2C: una brújula electrónica y un DSP con núcleo ARM. El objetivo
perseguido es el aprendizaje de conceptos básicos de diseño digital y análisis de sistemas
electrónicos digitales, así como de desarrollo de aplicaciones software para dispositivos
empotrados. La implementación presentada constituirá una herramienta docente útil en
asignaturas de introducción a los sistemas basados en microprocesadores, donde el alumno
podrá comprobar de forma práctica y con aplicaciones conceptualmente sencillas, el interés de
este tipo de dispositivos en la tecnología electrónica actual, así como sus posibilidades. Además,
permitirá instruir al alumno en una metodología de diseño y programación cercana a la realidad,
permitiéndole poner en práctica conceptos teóricos estudiados en otras asignaturas.
Referencias [1] Michael J. Caruso. Applications of Magnetic Sensors for Lof Cost Compass Systems. Honeywell,
SSEC.
[2] Dominique Paret. El Bus I2C: de la teoría a la práctica. Paraninfo (1995).
[3] Francisco Rogelio Palomo Pinto, Alfredo Pérez Vega-Leal, Eduardo Galván. Problemas resueltos
de instrumentación electrónica. Universidad de Sevilla (2006).
[4] Miguel A. Pérez García. Instrumentación electrónica. Thomson-Paraninfo (2008).
[5] Karim Yaghmour. Building Embedded Linux Systems. O´Reilly Media (2003).
[6] Gert van der Horn, Johan L. Huijsing. Integrated smart sensors: desgin and calibration. Kluwer
Academic Publishers (1998).
[7] F. Cortés, S. Gallardo, F. Barrero, S. Toral. Plataforma para el desarrollo de sensores inteligentesy
sistemas microprocesados. 7o Congreso de Tecnologías Aplicadas a la Enseñanza de la Electrónica
(TAEE2006). Madrid (2006).
[8] Hua Sun, Peike Yang. Design and Research on Errors Compensation of Digital Compass.
Proceedings of the 2009 IEEE International Conference on Mechatronics and Automation. pp. 4742-
4747.
[9] Zhi Li, Xiang Li, Youngjun Wang. A Calibration Method for Magnetic Sensors and Accelerometer
in Tilt-compensated Digital Compass. The Ninth International Conference on Electronic
Measurement and Instruments. pp. 868-871, vol. 2, (2009).
[10] Hong-Shik Kim, Jong-Suk Choi. Advanced indoor localization using ultrasonic sensor and
digital compass. International Conference on Control, Automation and Systems. pp. 223-226. (2008)
156
10. Referencias
1. Bruce B. Blasch, William R. Wiener, Richard L. Welsh. Foundations of
orientation and mobility.
2. RNIB Digital Accessibility team.
http://www.tiresias.org/index.htm
3. Organización Mundial de la Salud, nota descriptiva N° 282, Mayo 2009.
http://www.who.int/mediacentre/factsheets/fs282/es/index.html
4. Vitek, S. - Klima, M. PERSEUS Personal Help for Blind User. International
Conference on Applied Electronics, p. 367 - 370, ISBN 978-80-7043-865-7,
Pilsen, 2010.
5. Giudice, N. A., y Legge, G. E. Blind navigation and the role of technology.
Engineering handbook of smart technology for aging, disability, and
independence, pp. 479-500, John Wiley & Sons, 2008.
6. Baudoin, G., Venard, O., Uzan, G., Rousseau, A., Benabou, Y., Paumier A.,
Cesbron, J. How can blinds get information in Public Transports using PDA? The
RAMPE Auditive Man Machine Interface, Proc. 8th European Conference for the
advancement of assistive technology in Europe, AAATE 2005, pp. 304-316, Lille,
2005.
7. Sánchez, J., y Oyarzún C. Asistencia móvil basada en audio para la movilización
por medio de microbús de personas ciegas. 2007.
8. Sánchez, J., Sáenz, M. Audio-Based Mobilization and Orientation of Users with
Visual Disabilities through Subway Networks. International Journal on Disability
and Human Development, IJDHD, pp. 235-242. 2006.
9. España Caparros, José A. El sistema braille. Organización Nacional de Ciegos.
Málaga, 2002.
157
10. Serrano Mascaraque, Esmeralda. La e-accesibilidad y la discapacidad visual en
España. Revista general de información y documentación, ISSN 1132-1873, Vol.
19, Nº 1, pp. 189-219, 2009.
11. Ed Welsh R. L. et al. Mobility Devices, in Foundations of Orientation and
Mobility, ISBN/ISSN 0891280936, pp. 357-402, AFB, EUA, 1979.
12. Kay, L. Electronic aids for blind persons: an interdisciplinary subject. Physical
Science, Measurement and Instrumentation, Management and Education. IEE
Proceedings A Science, Measurement & Technology, vol. 131, no. 7, pp. 559-
576, 1984, EUA.
13. Borenstein, J.; Ulrich, I. The GuideCane-a computerized travel aid for the active
guidance of blind pedestrians. Robotics and Automation. Proceedings IEEE
International Conference on , vol.2, no., pp.1283-1288 vol.2, 20-25, 1997.
14. Benjamin, J. M., Ali, N. A., y Schepis, A. F. A Laser Cane for the Blind.
Proceedings of the San Diego Biomedical Symposium, Vol. 12, pp. 53-57, 1973.
15. Kawai, Y., M. Kobayashi, H. Minagawa, M. Miyakawa y F. Tomita. A Support
System for Visually Impaired Persons Using Three-Dimensional Virtual Sound.
International Conference on Computers Helping People with Special Needs, 327-
334, 2000, Karslruhe, Germany.
16. Loomis, J. M., R.G. Golledge, y R.L. Klatzky. Navigation system for the blind:
Auditory display modes and guidance. Presence: Teleoperators and Virtual
Environments, pp. 193-203, 1998.
17. Strothotte, T.; Petrie,H.; Johnson, V.; y Reichert, L. MoBIC: an aid to increase
the independent mobility of blind and elderly travellers, 2nd TIDE Congress,
Paris, La Villette, 1995.
18. Makino, H.; Ishii, I.; Nakashizuka, M.; Development of navigation system for the
blind using GPS and mobile phone combination. Engineering in Medicine and
Biology Society. Bridging Disciplines for Biomedicine. Proceedings of the 18th
Annual International Conference of the IEEE , vol. 2, pp. 506-507 vol.2, 31, 1996.
19. Marsh, A.; May, M.; y Saarelainen, M.; Pharos: coupling GSM and GPS-TALK
technologies to provide orientation, navigation and location-based services for
the blind. Information Technology Applications in Biomedicine. IEEE EMBS
International Conference on Information Technology Applications in
Biomedicine, pp. 38-43, 2000.
158
20. Moller, K.; Toth, F.; Wang, L.; Moller, J.; Arras, K.O.; Bach, M.; Schumann, S.; y
Guttmann, J. Enhanced Perception for Visually Impaired People. Bioinformatics
and Biomedical Engineering ICBBE 2009. 3rd International Conference, pp.1-4,
11-13, 2009.
21. Pissaloux, E.; A characterization of vision systems for blind people mobility.
Systems, Man and Cybernetics, 2002 IEEE International Conference, vol. 4, pp.
6-4, 6-9, 2002.
22. Robert, Max. Bluetooth: A Short Tutorial. Mobile and Portable Radio Research
Group, Bradley Department of Electrical and Comuper Engineering, Virginia
Tech.
23. ZigBee Alliance, ZigBee Specification, 2008.
http://www.zigbee.org/
24. Smith, Roger. RFID: A Brief Technology Analysis. 2004.
25. Wylie-Green, M.P.; Ranta, P.A.; Salokannel, J. Multi-band OFDM UWB solution
for IEEE 802.15.3a WPANs. Nokia Research Center, Nokia Group.
http://research.nokia.com/
26. IEEE 802 LAN/MAN Committee. http://www.ieee802.org/
27. Nuaymi, Loutfi. WiMAX: technology for broadband wireless a . Wiley &
Sons, 2007.
28. Grupo de interés especial Bluetooth. Comparación entre tecnologías.
http://www.bluetooth.com/Bluetooth/Technology/Works/Compare/
29. Grupo de interés especial Bluetooth. Core Specification Versión 2.1 + EDR,
2007.http://www.bluetooth.com/Bluetooth/Technology/Building/Specifications/Default.htm
30. Sánchez, J., Maureira, E. Subway Mobility Assistance Tools for Blind Users.
Lecture Notes in Computer Science, LNCS 4397, pp. 386-404, 2007, Springer-
Verlag Berlin Heidelberg, 2007.
31. Loomis, J., Golledge, R. y Klatzky, R. GPS-Based Navigation Systems for the
Visually Impaired. Fundamentals of Wearable Computers and Augmented
Reality. Lawrence. Erlbaum Associates, 2001.
32. Cano, J. C. Cano, J.M. Calafate, C. González, E. y Manzoni, P. Evaluation of the
trade-off between power consumption and performance in Bluetooth based
systems. Sensor Technologies and Applications, SensorComm 2007, pp. 313-
318. Octubre 2007.
159
33. Thamrin, Taqwan y Sahib, Shahrin. The Inquiry and Page Procedure in Bluetooth
Connection. International Conference of Soft Computing and Pattern
Recognition, Diciembre 2009.
34. G. Záruba y I. Chlamtac. Accelerating Bluetooth Inquiry for Personal Area
Networks. Global Telecommunications Conference, 2003, vol. 2, pp.702-706,
GLOBECOM '03, Diciembre 2003.
35. B. Peterson, R. Baldwin y J. Kharoufeh. Bluetooth Inquiry Time Characterization
and Selection.Mobile Computing, IEEE transactions, vol. 5, pp. 1173-1187, 2006.
36. G. Záruba y V. Gupta. Simplified Bluetooth Device Discovery – Analysis and
Simulation. Systems Scineces, 2004. Proceedings of 37th Annual Hawaii
International Conference, pp. 9pp, 2004.
37. S. Asthana y D. Kalofonos. The problema of Bluetooth pullution and accelerating
connectivity in Bluetooth Ad-Hoc networks. Pervasive Computing and
Communications, 2005. PerCom 2005. Third IEEE International Conference, pp.
8-12, 2005.
38. X. Zhang y G. Riley. Evaluation and accelerating Bluetooth device discovery.
Radio and Wireless Symposium, 2006. IEEE pp. 467-470, 2006.
39. F. Bektas, B. Vondra, P. Veith, L. Faltin, A. Pohl y A. Scholtz. Bluetooth
communication employing antenna diversity. Computers and Communication,
2003. Proceedings. Eighth IEEE International Symposium on, 2003, pp.652-657,
vol 1, 2003.
40. A. Mohammed y T. Hult. Evaluation of the Bluetooth link and antennas
performance for indoor office environments by measurement trials and FEMLAB
simulations. Vehicular Technology Conference, 2005. VTC 2005-Spring. 2005
IEEE 61st, pp. 238-242, vol. 1, 2005.
41. F. Forno, G. Malnati, G. Portelli. Desing and implementation of a Bluetooth ad
hoc network for indoor positioning. Softwar IEE Proceedings, pp. 223- 228, vol.
152, 2005.
42. Organización BeagleBoard. Página oficial del proyecto. http://beagleboard.org/
43. Kontron Embedded Computers Ag. Página principal. http://www.kontron.com/
44. IEI Technology Corp. Página principal. http://www.ieiworld.com/
45. Openmoko Inc. página oficial. http://www.openmoko.com/
160
46. Linux in a Box Company. Página oficial. http://www.liab.dk/
47. Toradex. Página oficial. Kit Limestone PDA.
http://www.toradex.com/Es/Products/Limestone_PDA_Kit
48. Tanenbaum, Andrew S. Sistemas Operativos Modernos. Pearson Education,
2003.
49. Openmokowiki. Página principal. http://wiki.openmoko.org/wiki/Main_Page
50. S. Asthana y D. Kalofonos. The problem of Bluetooth pullution and accelerating
connectivity in Bluetooth Ad-Hoc networks. Pervasive Computing and
Communications, 2005. PerCom 2005. Third IEEE International Conference, pp.
8-12, 2005.
51. Huang, Albert y Rufolph, Larry. Bluetooth essentials for programmers.
Cambridge University Press, 2007.
52. Stevens, W. Richard. Advanced Programming in the UNIX Environment. Addison
Wesley, 2005.
53. The Apache Software Foundation. Página oficial. http://www.apache.org/
54. Consorcio World Wide Web. Página oficial Libxml2. http://xmlsoft.org/
55. SourceForge. Sintetizador de voz eSpeak. http://espeak.sourceforge.net/
56. Universidad de Edimburgo, The Centre for Speech Technology Research: The
Festival Text to Speech synthesis System.
http://www.cstr.ed.ac.uk/projects/festival/
57. Universidad Carnegie Mellon, Speech Software at CMU: Flite.
http://www.speech.cs.cmu.edu/flite/
58. Almeida, Francisco et al. Introducción a la programación paralela. Paraninfo,
2008.
59. IEEE POSIX y The Open Group. Página principal.
http://posixcertified.ieee.org/
60. OpenMP. The OpenMP API Specification for Parallel Programming.
http://openmp.org/wp/