pfc1175 PDF

Índice general
1. Introducción 1
1.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Introducción a las tecnologías inalámbricas . . . . . . . . . . . . . . . . 1
1.3. Aplicaciones de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Competencia de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Objetivos del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Tecnología Bluetooth 7
2.1. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Perfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1. Perfil Genérico de Acceso . . . . . . . . . . . . . . . . . . . . . 10
2.5.2. Perfil de Puerto Serie . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.3. Perfil de Descubrimiento de Servicio . . . . . . . . . . . . . . . 10
2.5.4. Perfil Genérico de Intercambio de Objetos . . . . . . . . . . . . . 11
2.5.5. Perfil de Telefonía Inalámbrica . . . . . . . . . . . . . . . . . . . 11
2.5.6. Perfil de Intercomunicador . . . . . . . . . . . . . . . . . . . . . 11
2.5.7. Perfil de Manos Libres . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.8. Perfil Dial-Up Networking . . . . . . . . . . . . . . . . . . . . . 11
2.5.9. Perfil de Fax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.10. Perfil de Acceso LAN . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.11. Perfil Object Push . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.12. Perfil de Transferencia de Archivos . . . . . . . . . . . . . . . . 12
2.5.13. Perfil de Sincronización . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Topología red Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7. Piconet y Scatternet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7.1. Piconet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7.2. Scatternet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8. Pila de protocolos de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . 15
2.8.1. Arquitectura hardware . . . . . . . . . . . . . . . . . . . . . . . 16
2.8.1.1. Capa de radio . . . . . . . . . . . . . . . . . . . . . . 17
2.8.1.2. Banda base . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.1.3. LMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
I
II ÍNDICE GENERAL
2.8.2. HCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.3. Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.3.1. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.3.2. L2CAP . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8.3.3. RFCOMM . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.4. Protocolos adaptados . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.4.1. PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.4.2. TCP/UDP/IP . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.4.3. Protocolo OBEX . . . . . . . . . . . . . . . . . . . . . 23
2.8.4.4. WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9. Pilas de protocolos para modelos de uso de Bluetooth . . . . . . . . . . . 23
2.9.1. Teléfono 3 en 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9.2. Transferencia de ficheros . . . . . . . . . . . . . . . . . . . . . . 24
2.9.3. Headset final . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.9.4. Acceso a LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.9.5. Bridge de Internet . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9.6. Sincronización continúa . . . . . . . . . . . . . . . . . . . . . . 25
2.10. Pasos para el establecimiento de la conexión . . . . . . . . . . . . . . . . 25
2.10.1. Estados de un dispositivo Bluetooth . . . . . . . . . . . . . . . . 26
2.10.2. Establecimiento de la conexión . . . . . . . . . . . . . . . . . . 26
2.10.3. Modos de Conexión . . . . . . . . . . . . . . . . . . . . . . . . 29
2.11. Productos Bluetooth disponibles en el mercado . . . . . . . . . . . . . . 29
2.11.1. PocketPCs con Bluetooth . . . . . . . . . . . . . . . . . . . . . . 30
2.11.2. Teclados y ratónes inalámbricos mediante tecnología Bluetooth . 30
2.11.3. Teléfonos móviles . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.11.4. Puntos de enlace mediante Bluetooth . . . . . . . . . . . . . . . 32
2.11.5. Tarjetas Compact Flash Bluetooth de BlueTake . . . . . . . . . . 32
2.11.6. Auriculares o headset . . . . . . . . . . . . . . . . . . . . . . . . 33
2.11.7. Reproductor headset MP3 con Bluetooth . . . . . . . . . . . . . 33
2.11.8. Kit de impresión Bluetooth de 3com . . . . . . . . . . . . . . . . 33
2.11.9. Tarjeta SD Bluetooth de Socket . . . . . . . . . . . . . . . . . . 34
2.11.10.Receptor GPS Bluetooth . . . . . . . . . . . . . . . . . . . . . . 34
2.11.11.Sistema de manos libres Bluetooth para el coche . . . . . . . . . 35
2.12. Material Utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.12.1. BlueCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.12.2. Dispositivos Bluetooth por USB de Microtune . . . . . . . . . . 37
2.12.2.1. Chip de los dispositivos . . . . . . . . . . . . . . . . . 37
2.12.2.2. MT0760 Bluetooth OneChip . . . . . . . . . . . . . . 37
2.12.3. Sony Ericsson P800 . . . . . . . . . . . . . . . . . . . . . . . . 39
3. IP sobre Bluetooth 41
3.1. IP sobre Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.1. IP sobre L2CAP . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.2. IP sobre [PPP sobre L2CAP] . . . . . . . . . . . . . . . . . . . . 41
3.1.3. IP sobre [BNEP sobre L2CAP] . . . . . . . . . . . . . . . . . . . 42
ÍNDICE GENERAL III
3.1.4. IP sobre [PPP sobre RFCOMM] . . . . . . . . . . . . . . . . . . 42

3.1.5. IP sobre ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.6. IP sobre SCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2. LAN en Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1. Perfil de acceso LAN definido en la especificación Bluetooth . . . 44
3.2.1.1. Conexión a un LAP . . . . . . . . . . . . . . . . . . . 44
3.2.1.2. Enlaces PPP . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.2. Propuesta de cómo usar IP sobre PPP . . . . . . . . . . . . . . . 47
3.2.3. Mecanismo básico de roaming por la comunicación . . . . . . . . 47
3.3. PAN en Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1. perfil PAN definido en la especificación Bluetooth . . . . . . . . 49
3.3.2. Bluetooth Network Encapsulation Protocol . . . . . . . . . . . . 50
3.3.3. Paquetes de encapsulación . . . . . . . . . . . . . . . . . . . . . 51
3.3.4. Funcionamiento de L2CAP en el entorno IP . . . . . . . . . . . . 51
3.3.5. IP sobre BNEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.5.1. BNEP en modo infraestructura . . . . . . . . . . . . . 52
3.3.5.2. BNEP en modo ad-hoc . . . . . . . . . . . . . . . . . 53
3.3.5.3. Conexión de dos PANU . . . . . . . . . . . . . . . . . 53
4. Desarrollo del proyecto 55

4.1. Bluetooth y Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1.1. Historia de Bluetooth y Linux . . . . . . . . . . . . . . . . . . . 55
4.1.2. Software Bluetooth con licencia pública (GPL) . . . . . . . . . . 56
4.1.3. OpenBT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1.4. BlueDrekar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.5. Affix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.1.6. BlueZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2. Instalación de BlueZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.1. Compilación del núcleo de Linux . . . . . . . . . . . . . . . . . 59
4.2.2. Descarga, compilación e instalación de los paquetes BlueZ . . . . 60
4.3. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.1. Autoiniciación de dispositivos . . . . . . . . . . . . . . . . . . . 61
4.3.2. Seguridad en las comunicaciones . . . . . . . . . . . . . . . . . 62
4.3.3. Inicialización de los dispositivos . . . . . . . . . . . . . . . . . . 63
4.3.4. Herramientas básicas disponibles . . . . . . . . . . . . . . . . . 64
4.3.4.1. hciconfig . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.4.2. hcitool . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.4.3. l2ping . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.4.4. hcidump . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.4.5. Conexión a nivel de banda base entre dos dispositivos
Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4. Perfil de red de área Personal (PAN PROFILE) . . . . . . . . . . . . . . 66
4.4.1. Instalación del módulo BNEP . . . . . . . . . . . . . . . . . . . 67
4.4.2. Utilización del demonio PAN . . . . . . . . . . . . . . . . . . . 68
4.4.2.1. Creación de una conexión entre dos PANUs . . . . . . 69
IV ÍNDICE GENERAL
4.4.2.2. Creación de un escenario modo ad-hoc . . . . . . . . . 69

4.4.2.3. Creación de un escenario modo infraestructura . . . . 70
4.4.2.4. Funcionalidad de búsqueda . . . . . . . . . . . . . . . 70
4.4.2.5. Configuración de las interfaces . . . . . . . . . . . . . 71
4.5. Perfil de red de área local (LAN Profile) . . . . . . . . . . . . . . . . . . 72
4.5.1. Configuración del sistema . . . . . . . . . . . . . . . . . . . . . 73
4.5.1.1. Conexión RFCOMM . . . . . . . . . . . . . . . . . . 73
4.5.2. Conexión PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5.2.1. Demonio DUN (Dial-Up Network) . . . . . . . . . . . 78
4.5.2.2. Establecimiento con dund . . . . . . . . . . . . . . . . 80
4.5.2.3. Establecimiento sin dund . . . . . . . . . . . . . . . . 80
4.6. Conexión Bluetooth del Sony Ericsson P800 . . . . . . . . . . . . . . . . 81
4.6.1. Configuración previa en el ordenador . . . . . . . . . . . . . . . 81
4.6.2. Configuración del P800 . . . . . . . . . . . . . . . . . . . . . . 82
4.6.3. Conexión RFCOMM con el P800 . . . . . . . . . . . . . . . . . 82
4.6.4. Conexión del P800 a una LAN sobre Bluetooth . . . . . . . . . . 83
5. Conclusión y líneas futuras 91
A. Contenido del CD-ROM 93

Índice de figuras
1.1. Clasificación de las tecnologías inalámbricas . . . . . . . . . . . . . . . . 2

1.2. Aplicaciones de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Perfiles de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Ejemplo de maestros y esclavos . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Ejemplo de una piconet . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Ejemplo de sacatternet . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5. Pila de protocolos Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6. Esquema del hardware de un dispositivo Bluetooth . . . . . . . . . . . . 16
2.7. División del canal físico de Bluetooth . . . . . . . . . . . . . . . . . . . 17
2.8. Canal físico de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9. Transmisión por división en el tiempo . . . . . . . . . . . . . . . . . . . 19
2.10. Tipos de enlaces físicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.11. Formato de los paquetes SCO y ACL, respectivamente . . . . . . . . . . 20
2.12. Formato de un paquete L2CAP . . . . . . . . . . . . . . . . . . . . . . . 21
2.13. Pila de protocolos para teléfono 3 en 1 . . . . . . . . . . . . . . . . . . . 23
2.14. Pila de protocolos para la transferencia de ficheros . . . . . . . . . . . . . 24
2.15. Pila de protocolos para el headset final . . . . . . . . . . . . . . . . . . . 24
2.16. Pila de protocolos para el modelo de uso de acceso a LAN . . . . . . . . 25
2.17. Pila de protocolos para hacer un bridge de Internet . . . . . . . . . . . . 25
2.18. Pila de protocolos para el modelo de sincronización continua . . . . . . . 26
2.19. Posibles cambios de estado de un dispositivo Bluetooth . . . . . . . . . . 27
2.20. Proceso de búsqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.21. Proceso de paginación . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.22. Heweltt Packard iPAQ 5450 . . . . . . . . . . . . . . . . . . . . . . . . 30
2.23. Teclados y ratóns con tecnología Bluetooth . . . . . . . . . . . . . . . . 31
2.24. Nokia 6600 y Panasonic X70 . . . . . . . . . . . . . . . . . . . . . . . . 32
2.25. Punto de enlace BlueTake . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.26. Tarjeta Compact Flash Bluetooth de BlueTake . . . . . . . . . . . . . . . 33
2.27. Headset BlueTake, Motorola y Plantronics, respectivamente . . . . . . . 33
2.28. Reproductor headset MP3 con Bluetooth . . . . . . . . . . . . . . . . . . 34
2.29. Kit de impresión Bluetooth para impresoras . . . . . . . . . . . . . . . . 34
2.30. Tarjeta SD Bluetooth de Socket . . . . . . . . . . . . . . . . . . . . . . . 35
2.31. Receptor GPS Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.32. Sistema de manos libre para el coche . . . . . . . . . . . . . . . . . . . . 36
V
VI ÍNDICE DE FIGURAS
2.33. Chip MT0760 de Microtune . . . . . . . . . . . . . . . . . . . . . . . . 38

2.34. MT0760 Bluetooth OneChip sin carcasa . . . . . . . . . . . . . . . . . . 38
2.35. Diferentes vistas del MT0760 Bluetooth OneChip . . . . . . . . . . . . . 39
2.36. Sony Ericsson P800 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1. IP sobre L2CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2. IP sobre PPP sobre L2CAP . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3. IP sobre BNEP sobre L2CAP . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4. IP sobre PPP sobre RFCOMM . . . . . . . . . . . . . . . . . . . . . . . 43
3.5. Conexión a un LAP usando el perfil LAN . . . . . . . . . . . . . . . . . 45
3.6. Formato de una trama PPP . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.7. Establecimiento de una conexión PPP . . . . . . . . . . . . . . . . . . . 47
3.8. Camino más usual para conseguir IP sobre PPP . . . . . . . . . . . . . . 47
3.9. Group ad-hoc Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.10. NAP Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.11. Pila para el protocolo BNEP . . . . . . . . . . . . . . . . . . . . . . . . 50
3.12. Paquete de encapsulación . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.13. Escenario modo infraestructura . . . . . . . . . . . . . . . . . . . . . . . 52
3.14. Escenario modo ad-hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1. Diagrama de BlueZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2. Captura con la salida de hcitool inq y hcitool scan . . . . . . . . . . . . . 66
4.3. Captura de una conexión por el lado del dispositivo maestro . . . . . . . 67
4.4. Captura de una conexión por el lado del dispositivo esclavo . . . . . . . . 68
4.5. Escenario creado entre dos PANUs . . . . . . . . . . . . . . . . . . . . . 69
4.6. Servidor en un enlace entre dos PANUs . . . . . . . . . . . . . . . . . . 70
4.7. Cliente en un enlace entre dos PANUs . . . . . . . . . . . . . . . . . . . 71
4.8. Escenario modo ad-hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.9. Captura con el GN creado en un ordenador . . . . . . . . . . . . . . . . . 72
4.10. Escenario modo infraestructura . . . . . . . . . . . . . . . . . . . . . . . 73
4.11. Captura que muestra la creación de un NAP . . . . . . . . . . . . . . . . 74
4.12. IP sobre Bluetooth de acuerdo con el perfil LAN . . . . . . . . . . . . . . 75
4.13. Enlace RFCOMM en el lado del servidor . . . . . . . . . . . . . . . . . 76
4.14. Dispositivo que solicita conexión a un servidor . . . . . . . . . . . . . . 77
4.15. Captura con dos enlaces RFCOMM de un ordenador . . . . . . . . . . . 77
4.16. Muestra de los módulos cargados en el ordenador . . . . . . . . . . . . . 78
4.17. Captura con los pasos realizados para lanzar un servidor PPP . . . . . . . 81
4.18. Establecimiento, en el lado del cliente, de una conexión PPP utilizando
dund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.19. Captura con los pasos realizados por un cliente sin utilizar dund . . . . . 83
4.20. Pasos para la configuración Bluetooth del P800 . . . . . . . . . . . . . . 84
4.21. Escenario creado por el P800 y el ordenador . . . . . . . . . . . . . . . . 84
4.22. Conexión PPP entre el P800 y el ordenador . . . . . . . . . . . . . . . . 85
4.23. Solicitud de pines entre el P800 y el ordenador . . . . . . . . . . . . . . 87
4.24. system log que muestra el enlace PPP entre el P800 y el ordenador . . . . 88
Capítulo 1
Introducción
1.1. Resumen
El mundo de las comunicaciones móviles (wireless) ha experimentado una gran evo-
lución en su desarrollo y aplicaciones. Hoy en día, es posible tener en nuestros hogares
una red inalámbrica IEEE 802.11b [IEEE, WWW], comunicar el móvil con el ordenador
mediante Bluetooth, o comunicar dos redes LAN (Local Area Network) de dos edificios.
Una red inalámbrica es aquella que utiliza ondas electromagnéticas no guiadas como
medio de transmisión de la información. Las grandes ventajas de estas redes son: movili-
dad, facilidad a la hora de la instalación y adaptación a cualquier topología. Este proyecto
trabaja con la tecnología inalámbrica Bluetooth. En la figura 1.1 se puede ver una gráfica
donde se muestra una clasificación de los distintos tipos de tecnologías inalámbricas que
existen.
Bluetooth es el nombre dado a una tecnología nueva (1998) que posibilita la cone-
xión inalámbrica de corto alcance (hasta 100 metros) de voz y datos entre computadoras
de escritorio y portátiles, agendas digitales personales (PDA, Personal Digital Assistant),
teléfonos móviles, impresoras, escaner, cámaras digitales e incluso dispositivos electró-
nicos en el hogar. La finalidad de Bluetooth es sustituir los cables que conectan aparatos
electrónicos. Este nuevo entorno de aplicación se conoce como redes PAN (Personal Area
Network). Sus características más notables son su robustez, la baja complejidad, y el bajo
precio. Bluetooth fué diseñado para funcionar en ambientes de frecuencia ruidosos por
lo que lo hacen robusto frente a interferencias. Los módulos Bluetooth funcionan en la
banda de ISM (Industrial Scientific and Medical) a 2.4GHz, y evitan la interferencia de
otras señales saltando a una frecuencia nueva después de la transmisión de un paquete.
Comparado con otros sistemas que operan en la misma banda de frecuencia, la capa de
radio Bluetooth salta más rápido y emplea paquetes más cortos.
1.2. Introducción a las tecnologías inalámbricas

El gran fenómeno de Internet se ha expandido en la actualidad a otros mercados en un
principio inimaginables como la telefonía celular. Por otra parte, la globalización de las
comunicaciones inalámbricas ha permitido el desarrollo de nuevos estándares y productos
1
2 CAPÍTULO 1. INTRODUCCIÓN
Figura 1.1: Clasificación de las tecnologías inalámbricas
que muy pronto ofrecerán cambios en todas nuestras actividades. Nuevos y emergentes
estándares inalámbricos tales como IEEE 802.11 [IEEE 802.11, WWW], IEEE 802.15
[IEEE 802.15, WWW], Bluetooth [Bluetooth, WWW], HiperLAN/2 [HiperLAN/2, WWW],
HomeRF [HomeRF, WWW] en combinación con otras tecnologías no tan nuevas como la
telefonía celular, asociado con nuevos protocolos como el WAP (Wireless Aplication Pro-
tocol), permitirán la interconexión de las redes actuales e Internet a dispositivos móviles
como teléfonos celulares, PDAs y otros dispositivos portátiles.
Estas nuevas tecnologías inalámbricas utilizan técnicas avanzadas de modulación que
permiten un nivel alto de seguridad, así como resistencia a la interferencia de dispositivos
electrónicos y a otros usuarios. La mayoría de los usuarios podrán compartir una banda
de frecuencia sin interferencias. Además, estas nuevas tecnologías utilizan bandas de fre-
cuencias sin licencia (ISM), que permiten el uso libre de la frecuencia (excepto en Francia
y Japón).
Son muchas las ventajas que ofrecen las tecnologías inalámbricas para el acceso a In-
ternet. En un principio las únicas tecnologías inalámbricas que existían eran la satelital
y la conexión a través de enlaces de microondas. Los proveedores de servicios en Inter-
net brindaban a sus usuarios el acceso a los servicios a través de medios guiados tales
como cobre, cable o fibra óptica. Es decir, el usuario no accedía inalámbricamente a la
información. Los pocos dispositivos que existían en esa época eran limitados y no eran
interoperables debido a que no existían estándares y sólo estaban disponibles por unos
pocos fabricantes. Por ello, el mercado estaba muy segmentado y los precios de los equi-
pos eran elevadísimos [Ref1, WWW], por lo que era imposible su expansión y limitaba el
desarrollo de nuevas tecnologías “sin cables”.
Hoy en día, gracias a la creación de nuevos estándares inalámbricos, se ha permitido
la fabricación de nuevos productos a un precio cada vez más accesible a los usuarios y
con más ancho de banda. A continuación, se describen otros factores que han influido en
la selección de la opción inalámbrica para el acceso a redes e Internet.
1.2. INTRODUCCIÓN A LAS TECNOLOGÍAS INALÁMBRICAS 3
Figura 1.2: Aplicaciones de Bluetooth
Se han abierto frecuencias que no necesitan permisos para transmisión en las bandas
de 2.4 a 2.4835 GHz y 5 GHz, que habían estado reservadas para equipos industria-
les, científicos y médicos.
Están cambiando los patrones de trabajo, más gente de negocios necesita acceder a
Internet desde cualquier lugar.
Es más fácil para el proveedor de servicios de telecomunicaciones e Internet brindar
a sus usuarios el acceso sin cables que con ellos.
Es más fácil la incorporación de nuevos usuarios a una redes inalámbricas.
Con los nuevos productos y tecnologías inalámbricas los usuarios podrán acceder a
las redes corporativas e Internet desde su casa, de camino al trabajo o en la carretera
sin una conexión física. Con teléfonos inteligentes será posible recibir Internet y enlazar
directamente computadoras, máquinas de fax y otros dispositivos de oficina. A su vez, las
conexiones entre las redes guiadas podrán ser inalámbricas.
Es previsible, por tanto, que en un futuro no muy lejano, la velocidad de los disposi-
tivos “sin cables” se incremente gracias a novedosas tecnologías inalámbricas y a nuevos
estándares.
Al igual que las redes tradicionales guiadas es posible clasificar las redes inalámbricas
en categorías.
WAN/MAN (Wide Area Network/Metropolitan Area Network)

LAN (Local Area Network)
PAN (Personal Area Network)
1.3. Aplicaciones de Bluetooth

El futuro de Bluetooth está cimentado en las expectativas de más de 2000 compañías
pertenecientes al Bluetooth SIG [Bluetooth SIG, WWW]. Cada desarrollador ha colabo-
rado en la visión conjunta que se tiene para la tecnología, y los casos de uso que están
planeados son diversos.
IEEE espera que Bluetooth se estándarice a la norma IEEE 802.15.2 (WPAN, Wireless-
PAN) para la coexistencia con las redes locales inalámbricas (WLAN, Wireless Local Area
Network), y que surjan versiones de alta y baja velocidad, para aplicaciones de multime-
dia y de dispositivos de baja complejidad. Al crearse estos estándares, se ampliarían aún
más las posibilidades para el uso de Bluetooth, por ejemplo, para el modelo de baja ve-
locidad y baja complejidad (IEEE 802.15 TG 4) se esperan diversas aplicaciones como
sensores, juguetes interactivos, carnes inteligentes, controles remotos o dispositivos para
la automatización del hogar.
Bluetooth SIG y sus compañías patrocinadoras han creado y desarrollado una cantidad
considerable de escenarios de prueba, algunos de los más interesantes se enumeran a
continuación:
Automatización hotelera: la cadena de hoteles Holiday Inn, Axis Communications

AB y Registry Magic han juntado sus esfuerzos para convertir el Holiday Inn de
Wall Street en el primer hotel en prestar servicios inalámbricos, [Ref2, WWW].
Acceso a Internet en aeropuertos: muchos ejecutivos que viajan regularmente se

ven cada vez más en necesidad de tener acceso continuo a su correo electrónico y al
Web. Hasta ahora la solución adoptada por muchos suele ser una llamada telefónica
a un número de acceso de su proveedor o una complicada y costosa conexión a
través de un teléfono celular. Actualmente, compañías como American Airlines y
TWA están desarrollando el servicio de Internet Inalámbrico en sus salas de espera
de primera clase, [Ref2, WWW].
Acceso a información en trenes: BT Syncordia y Midland Mainline han comenza-

do pruebas para verificar la posibilidad de utilizar intranets basadas en Bluetooth
dentro de sus vagones, [Ref2, WWW].
Uso de dispositivos BLIP (Bluetooth Local Infotainment Point) [BLIP de Ericsson, WWW]:
Ericsson, compañía creadora de Bluetooth, ha lanzado un nuevo concepto para em-
pujar la utilización de dispositivos de esta tecnología en la calle, como manera de
fomentar su uso para fines comerciales y alimentar su desarrollo. La unidad Blip,
que contiene un pequeño sistema corriendo una versión especial de Linux que per-
mite montar aplicaciones interactivas de entretenimiento e información en estable-
cimientos comerciales y lugares públicos, [Ref2, WWW].
1.4. Competencia de Bluetooth

Las dispositivos inalámbricos que usan la banda libre ISM de 2.4 GHz están sujetos a
interferencias, tanto de dispositivos inalámbricos ajenos de otro tipo, como de generadores
1.5. OBJETIVOS DEL PROYECTO 5
de ondas en esa misma frecuencia como lo son los hornos microondas. Con estos dos en
mente, los creadores de Bluetooth escribieron el estándar de manera que fuera robusto en
situaciones de alto nivel de ruido y donde no se garantiza la claridad del canal.
Los dispositivos Bluetooth luchan constantemente (incluso, también entre sí) por el
espectro de frecuencias con los dispositivos de WLANs como IEEE 802.11 o HomeRF,
aunque estas dos tecnologías no están dirigidas a los mismos mercados. Una tecnología
que comparte algunos casos de uso con Bluetooth es IrDA (Asociación de Datos Infrarro-
jos) [IrDA, WWW], un estándar para comunicaciones vía infrarroja entre dispositivos.
Hay varias cosas que IrDA hace mejor de Bluetooth. Por ejemplo IrDA, en su versión
actual, puede sostener tasas de transferencia de 4 Mbps y 16 Mbps, mientras que Blue-
tooth debe conformarse con 1 Mbps y la promesa de 2 Mbps ó 10 Mbps una vez que
comience el desarrollo de las revisiones del estándar. Hay ciertas características de IrDA
que contrastan fuertemente con las ofrecidas por Bluetooth:
La seguridad de IrDA se basa en la direccionalidad del rayo de luz infrarrojo, mien-

tras que Bluetooth fija un sistema de seguridad en la capa física.
IrDA requiere línea de visión directa entre dispositivos, mientras que Bluetooth
permite la operación a través de objetos no metálicos.
IrDA es más popular entre los dispositivos inalámbricos actuales y es compatible

con revisiones de IrDA anteriores.
Bluetooth se adapta mejor para servicios de acceso a red y de marcación y otros

casos en que el usuario puede moverse.
Bluetooth es mejor para soluciones de difusión (broadcast) de información.
Una conclusión general, es que ambas tecnologías se complementan y tienen nichos

de aplicaciones distintos.
1.5. Objetivos del Proyecto

Este proyecto tiene como objetivos el estudio de la tecnología Bluetooth y del sopor-
te que ésta ofrece para los protocolos TCP/IP. El tema 2 explica el estándar Bluetooth,
además tiene una sección donde se habla de nuevos dispositivos Bluetooth sacados al
merdado, y estudia los modelos concretos utilizados en las pruebas del proyecto. El tema
3 trata de explicar las distintas soluciones para usar IP sobre Bluetooth con el perfil LAN
(IP sobre PPP sobre RFCOMM) y el perfil PAN (IP sobre BNEP). En el tema 4 se expli-
can las pruebas realizadas en el proyecto. Finalmente, el tema 5 ofrece las conclusiones y
líneas futuras.
Capítulo 2
Tecnología Bluetooth
2.1. Bluetooth
El origen de la palabra Bluetooth proviene de Harald Bluetooth (Harald Diente Azul),
quien fue un gran Rey Vikingo que logró unir Dinamarca y Noruega en el siglo X.
Es una tecnología reciente, de especificación abierta1 , que define una forma de co-
municación inalámbrica, la cual posibilita la transmisión de voz y datos entre diferentes
equipos mediante un enlace por radiofrecuencia de corto alcance. Los principales objeti-
vos que se pretende 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 sincroni-

zación de datos entre nuestros equipos personales.
Tecnológicamente hablando, Bluetooth funciona a través de pequeños y baratos trans-

misores/receptores de radio de corto alcance que son empotrados en los teléfonos móviles,
ordenadores y todos los posibles aparatos electrónicos que se conocen hoy, directamente
o a través de adaptadores como las PC Cards.
2.2. Antecedentes
En 1994 Ericsson [Ericsson, WWW] inició un estudio para investigar la viabilidad de
una interfaz de radio, de bajo coste y bajo consumo, para la interconexión entre teléfonos
móviles y otros accesorios con la intención de eliminar cables entre aparatos. El estudio
partía de un largo proyecto que investigaba sobre unos multicomunicadores conectados
a una red celular, hasta que se llegó a un enlace de radio de corto alcance, llamado MC
link. Conforme avanzaba este proyecto, se vió que este tipo de enlace podía ser utilizado
1
La especificación abierta hace posible que los vendedores puedan, libremente, implementar sus propios
protocolos de aplicación sobre los protocolos específicos de Bluetooth, permitiendo así el desarrollo de
nuevas aplicaciones que fomentan el desarrollo de las capacidades de la tecnología Bluetooth.
7
8 CAPÍTULO 2. TECNOLOGÍA BLUETOOTH
ampliamente en un gran número de aplicaciones, ya que su coste era relativamente bajo.
Bluetooth es una norma abierta que se encuentra en fase de revisión y mejora. La ver-
sión actual es la 1.1 [BTSIG1.1, WWW], posterior a la 1.0 y a la 1.0b[BTSIG1.0B, PDF].
Si se tiene en cuenta que esta tecnología está comenzando a dar sus primeros pasos, son
de esperar nuevas revisiones en los próximos años conforme se vayan incorporando al
mercado nuevos productos, y surjan nuevos escenarios de uso de los equipos.
2.3. SIG
A principios de 1997, y a medida que avanzaba el proyecto MC link, Ericsson fue
despertando el interés de otros fabricantes de equipos portátiles. En seguida se vió clara-
mente que para que el sistema tuviera éxito, un gran número de equipos deberían estar
equipados con esta tecnología. Esto fue lo que originó a principios de 1998, la crea-
ción del grUpo de interés especial (SIG, Special Interest Group), formado por 5 pro-
motores que fueron: Ericsson, Nokia [Nokia, WWW], Toshiba [Toshiba, WWW], IBM
[IBM, WWW] e Intel [Intel, WWW]. La especificación surgió de la colaboración de estas
empresas, a la que después se incorporaron 3COM/Palm [3COM/Palm, WWW], Compaq
[Compaq, WWW], Dell [Dell, WWW], Motorola [Motorola, WWW], Xircom [Xircom, WWW].
Actualmente, existen más de 1600 empresas que han adoptado esta tecnología para desa-
rrollarla con sus propios productos, convirtiendo a Bluetooth en una de las tecnologías de
red jamás implantadas con tanta rapidez.
El objetivo princiapal para los productos Bluetooth de primera generación fueron los
entornos de negocios que viajaban frecuentemente. Por lo que se pensó en integrar el chip
de radio Bluetooth en equipos como: ordenadores portátiles, teléfonos móviles, PDAs y
auriculares. Esto originaba una serie de cuestiones previas, que en un futuro se convirtie-
ron en propiedades de Bluetooth, tales como:
El sistema debería operar en todo el mundo.
El emisor de radio deberá consumir poca energía, ya que debía integrarse en equipos
alimentados por baterías.
La conexión debería soportar voz y datos, y adicionalmente aplicaciones multime-

dia.
Para poder operar en todo el mundo era necesaria una banda de frecuencias abierta,
es decir, sin necesidad de licencia independientemente del lugar del planeta donde nos
encontremos, para transmitir hasta una distancia de 100 metros a velocidades de transfe-
rencia del orden de los 721 Kbps. Sólo la banda ISM (médico-científica internacional) de
2,45 GHz cumple con estos requisitos, con rangos que van de los 2.400 MHz a los 2.500
MHz, y sólo con algunas restricciones en países como Francia y Japón, hasta hace poco
España también tenía restricciones.
2.4. FUTURO 9
2.4. Futuro
La tecnología Bluetooth comprende equipos hardware, software y requisitos de in-
teroperabilidad, por lo que para su desarrollo ha sido necesaria la participación de los
principales fabricantes de los sectores de las telecomunicaciones y la informática, ya men-
cionados (ver 2.3).
Bluetooth SIG creó diversos grUpos de trabajo para desarrollar la tecnología. El grUpo
de Audio/Vídeo, es presidido por Ruud van Bokhorst (Philips [Philips, WWW]) y Mar-
kus Zumkeller (Sony [Sony, WWW]). Los avances logrados en este área, en términos de
estándar de productos, se centran en: audífonos, parlantes y micrófonos de audio con gran
calidad, visualización de vídeo inalámbrico de corto alcance, calidad de voz de dictado,
cámaras de vídeo inalámbricas, funcionalidad de videoconferencia y calidad de voz de
banda ancha.[Ref4, WWW]
En el año 2002 se estima que se incorporó, la tecnología Bluetooth, a más de 100
millones de dispositivos, entre ellos teléfonos móviles, computadoras y otras clases de
equipos electrónicos.
Algunos investigadores norteamericanos predicen[Ref3, WWW] que para el 2005 se
venderán 955 millones de dispositivos equipados con tecnología Bluetooth. El estudio
de Cahner[Cahner, WWW] (Cahner’s Instat Group) hace referencia a un gran desarrollo
en la tecnología inalámbrica, a pesar de los desagradables informes que aluden a que el
desarrollo se verá afectado por la recesión económica.
2.5. Perfiles
Un perfil es un conjunto de características funcionales para cada aplicación que Blue-
tooth soporta. El concepto de perfil se utiliza para asegurar la interoperabilidad entre varias
unidades Bluetooth que cumplan los mismos perfiles. Cada dispositivo Bluetooth tiene al
menos un perfil, es decir, una aplicación para la cual se puede utilizar el dispositivo.
Cuando dos equipos quieran comunicarse entre sí, deben tener un perfil compartido. Por
ejemplo, si se quiere transferir un fichero o archivo desde un ordenador preparado para
Bluetooth a otro, ambos deben poseer o tener configurado un perfil de transferencia de
archivos, como OBEX.
La posibilidad de definir perfiles en Bluetooth marca una diferencia con otras tecno-
logías inalámbricas que solamente se centran en capas física y enlace.
En la figura 2.1 se destacan, con un asterisco (*), los perfiles a estudiar y probar en
este proyecto.
Los perfiles se clasifican dentro de modelos de uso. Dentro de cada modelo existen
uno o más perfiles que definen las diferentes capas del protocolo Bluetooth. Hay muchos
modelos de uso, y a medida que pasa el tiempo se diseñan nuevos modelos, por lo que es
muy difícil enumerarlos todos.
Cada equipo determina que perfiles ha de cumplir, por ejemplo, un auricular cumplirá
el perfil de auricular (headset) y el de acceso genérico (GAP,Generic Access Profile), pero
no el de puerto serie (SPP) o el de propiedades de marcado en red (DUN). En la figura 2.5
se puede ver la pila de protocolos de Bluetooth.
A continuación, se explican algunos de los perfiles Bluetooth más interesantes.
Figura 2.1: Perfiles de Bluetooth
2.5.1. Perfil Genérico de Acceso

Este perfil define los procedimientos generales para el descubrimiento y estableci-
miento de conexión entre dispositivos Bluetooth. El GAP maneja el descubrimiento y
establecimiento entre unidades que no están conectadas y asegura que cualquier par de
unidades Bluetooth, sin importar su fabricante o aplicación, puedan intercambiar informa-
ción a través de Bluetooth para descubrir qué tipo de aplicaciones soportan las unidades.
2.5.2. Perfil de Puerto Serie

El Perfil de Puerto Serie (SPP, Serial Port Profile) especifica los requisitos para dispo-
sitivos Bluetooth, necesarios para establecer una conexión emulada de cable serie usando
RFCOMM entre dos dispositivos similares. Este perfil solamente requiere soporte para
paquetes de un slot. Esto significa que pueden ser usadas ráfagas de datos de hasta 128
kbps. El soporte para ráfagas más altas es opcional. RFCOMM es usado para transportar
los datos de usuario, señales de control de módem y comandos de configuración. El perfil
de puerto serie es dependiente del GAP.
2.5.3. Perfil de Descubrimiento de Servicio

El Perfil de Descubrimiento de Servicio (SDP, Service Discovery Profile) concreta los
protocolos y procedimientos para una aplicación en un dispositivo Bluetooth donde se
desea descubrir y recUperar información relacionada con servicios localizados en otros
2.5. PERFILES 11
dispositivos. El SDAP es dependiente del GAP.
2.5.4. Perfil Genérico de Intercambio de Objetos

El Perfil Genérico de Intercambio de Objetos (GOEP, Generic Object Exchange Profi-
le) define protocolos y procedimientos usados por aplicaciones para ofrecer características
de intercambio de objetos. Los usos pueden ser, por ejemplo, sincronización, transferencia
de archivos o modelo Object Push. Los dispositivos más comunes que usan este mode-
lo son agendas electrónicas, PDAs, teléfonos celulares y teléfonos móviles. El GOEP es
dependiente del perfil de puerto serie.
2.5.5. Perfil de Telefonía Inalámbrica

El Perfil de Telefonía Inalámbrica (CTP, Cordless Telephony Profile) precisa cómo
un teléfono móvil puede ser usado para acceder a un servicio de telefonía de red fija a
través de una estación base. Es usado para telefonía inalámbrica de hogares u oficinas
pequeñas. El perfil incluye llamadas a través de una estación base, haciendo llamadas
de intercomunicación directa entre dos terminales y accediendo adicionalmente a redes
externas. Es usado por dispositivos que implementan el llamado “teléfono 3-en-1” (ver
2.9.1).
2.5.6. Perfil de Intercomunicador

El Perfil de Intercomunicador (Intercom Profile) define usos de teléfonos móviles, los
cuales establecen enlaces de conversación directa entre dos dispositivos. El enlace directo
es establecido usando señalización de telefonía sobre Bluetooth. Los teléfonos móviles
que usan enlaces directos funcionan como walkie-talkies.
2.5.7. Perfil de Manos Libres

El Perfil de Manos Libres especifica los requisitos, para dispositivos Bluetooth, nece-
sarios para soportar el uso de manos libres. En este caso el dispositivo puede ser usado
como unidad de audio inalámbrico de entrada/salida. El perfil soporta comunicación se-
gura y no segura.
2.5.8. Perfil Dial-Up Networking

El Perfil Dial-Up Networking (DUN, Dial-Up Networking) precisa los protocolos y
procedimientos que deben ser usados por dispositivos que implementen el uso del modelo
llamado puente Internet. Este perfil es aplicado cuando un teléfono celular o un módem
son usados como un módem inalámbrico.
2.5.9. Perfil de Fax

El Perfil de Fax (Fax Profile) define los protocolos y procedimientos que deben ser
usados por dispositivos que implementen el uso de fax. Un teléfono celular que soporte
este perfil puede ser usado como un fax inalámbrico.
2.5.10. Perfil de Acceso LAN

El Perfil de Acceso LAN (LAN Acess Profile) especifica el acceso a una red de área
local, LAN, usando el protocolo punto-a-punto (PPP, Point-to-Point) sobre RFCOMM.
PPP es usado para lograr acceder a redes soportando varios protocolos de red. El perfil
resiste acceso LAN para un dispositivo Bluetooth sencillo, acceso LAN para varios dis-
positivos Bluetooth y para conectar dos ordenadores con PPP (usando interconexión PPP
con emulación de cable serie).
2.5.11. Perfil Object Push

El Perfil Object Push (OPP, Object Push Profile) define protocolos y procedimientos
usados en el modelo Object Push. Este perfil usa el GOEP. En el modelo Object Push hay
procedimientos para introducir, sacar e intercambiar objetos con otro dispositivo Blue-
tooth.
2.5.12. Perfil de Transferencia de Archivos

El Perfil de Transferencia de Archivos (File Transfer Profile) especifica protocolos y
procedimientos usados en el modelo de transferencia de archivos. El perfil usa el GOEP.
En el modelo de transferencia de archivos hay procedimientos para explorar un grUpo de
objetos de otro dispositivo Bluetooth, transferir objetos entre dos dispositivos y manipular
objetos de otro dispositivo. Los objetos podrían ser archivos o fólderes de un grUpo de
objetos tal como un sistema de archivos.
2.5.13. Perfil de Sincronización

El Perfil de Sincronización (Synchronisation Profile) define protocolos y procedimien-
tos usados en el modelo de sincronización. éste usa GOEP. El modelo soporta intercam-
bios de información, por ejemplo para sincronizar calendarios de diferentes dispositivos.
2.6. Topología red Bluetooth

Para poder establecer una comunicación entre dos dispositivos Bluetooth, uno de ellos
debe establecer el papel de maestro y otro el rol de esclavo. El maestro es el encargado
de la sincronización de la comunicación. Todos los esclavos conectados al maestro salta-
rán a la frecuencia establecida por el maestro. El maestro se encarga de controlar cuando
2.7. PICONET Y SCATTERNET 13
Figura 2.2: Ejemplo de maestros y esclavos
un esclavo puede transmitir, reservando ranuras temporales para éste. El papel de maes-
tro es, generalmente, de aquel que comienza la comunicación, aunque este papel puede
cambiarse más tarde.
Un maestro puede establecer comunicación con hasta 7 esclavos activos. Cabe desta-
car que el papel de maestro o esclavo solamente tiene importancia a la hora de realizar el
sincronismo a bajo nivel.
2.7. Piconet y Scatternet

La topología de las redes Bluetooth puede ser punto a punto, o punto a multipunto.
Las redes con este tipo se denominan piconets. Éstas tienen la posibilidad de crecer hasta
alcanzar 7 conexiones punto a punto. Las piconets se pueden extender mediante la for-
mación de scatternets. Una scatternet es la red producida al establecer comunicación dos
dispositivos pertenecientes a dos piconets diferentes. Dentro de una piconet los diferen-
tes dispositivos pueden actuar como maestros y como esclavos, dependiendo de si están
enviando o recibiendo información. Antes de enviar o recibir información, debe haber un
paso previo a la comunicación. El dispositivo que vaya a actuar como maestro debe enviar
la información del reloj, para sincronizarse y para que los demás dispositivos interpreten
correctamente la información transmitida.
2.7.1. Piconet
Si un equipo se encuentra dentro del radio de cobertura de otro, estos pueden esta-
blecer conexión entre ellos. En principio sólo son necesarias un par de unidades con las
mismas características de hardware para establecer un enlace. Los participantes en la pi-
conet pueden intercambiar los papeles si un esclavo quisiera asumir el papel de maestro.
Sin embargo sólo puede haber un maestro en la piconet al mismo tiempo.
Cada unidad de la piconet utiliza su identidad maestra y reloj nativo para seguir en el
canal de salto. Cuando se establece la conexión, se añade un ajuste de reloj a la propia
frecuencia de reloj nativa de la unidad esclava para poder sincronizarse con el reloj nativo
del maestro.
Figura 2.3: Ejemplo de una piconet
Las unidades maestras controlan en tráfico del canal, por lo que estas tienen la capa-
cidad para reservar slots en los enlaces SCO. Para los enlaces ACL, se utiliza un esquema
de sondeo. A un esclavo sólo se le permite enviar un slot a un maestro cuando éste se ha
dirigido por su dirección MAC (medio de control de acceso) en el procedimiento de slot
maestro-esclavo.
2.7.2. Scatternet
Los equipos que comparten un mismo canal sólo pueden utilizar una parte de la capa-
cidad de éste, ya que lo tiene que compartir. Aunque los canales tienen un ancho de banda
de un 1 Mhz, cuantos más usuarios se incorporan a la piconet, disminuye la capacidad
hasta unos 10 kbit/s. Teniendo en cuenta que el ancho de banda medio disponible es de
unos 78 MHz (de 2402 MHz a 2480 MHz) en USA y Europa (excepto en Francia), éste
no puede ser utilizado eficazmente, cuando cada unidad ocUpa una parte del mismo canal
de salto de 1 MHz. Para poder solucionar este problema se adoptó una solución de la que
nace el concepto de scatternet.
Para crear una scatternet un dispositivo de una de las dos piconets tiene que pertene-
cer a dos de éstas. Para esto hay dos formas de hacerlo: ser esclavo de las dos piconets
o ser esclavo de una piconet y maestro de la otra. Las unidades que se encuentran en el
mismo radio de cobertura pueden establecer potencialmente comunicaciones entre ellas.
Sin embargo, sólo aquellas unidades que quieran intercambiar información comparten un
mismo canal creando la piconet. Este hecho permite que se creen varias piconets en áreas
de cobertura sUperpuestas. A un grUpo de piconets se le llama scatternet. El rendimiento,
en conjunto e individualmente de los usuarios de una scatternet es mayor que el que tiene
cada usuario cuando participa en un mismo canal de 1 MHz. Además, estadísticamente se
obtienen ganancias por multiplexión y rechazo de canales de salto. Debido a que indivi-
dualmente cada piconet tiene un salto de frecuencia diferente, diferentes piconets pueden
usar simultáneamente diferentes canales de salto.
2.8. PILA DE PROTOCOLOS DE BLUETOOTH 15
Figura 2.4: Ejemplo de sacatternet
2.8. Pila de protocolos de Bluetooth
Una pila de protocolos es un conjunto de capas de la pila de Bluetooth, con el fin

de que cada conjunto de capas forman una pila de protocolos, con la que un cliente y
un servidor con la misma pila pueden permitir que las aplicaciones funcionen unas entre
otras.Cada pila de protocolos usa un enlace de datos y una capa física común. En la figura
2.5 se puede ver la pila completa de protocolos de Bluetooth.
Los protocolos que están por debajo del interfaz controlador de computador (HCI,
Host Controller Interface),el protocolo gestor del enlace (LMP, Link Manager Protocol),
el protocolo de adaptación y control de enlace lógico (L2CAP, Logical Link Control and
Adaptation Protocol) y el protocolo de servicio de descubrimiento (SDP, Service Disco-
very Protocol) son los protocolos que necesariamente debe contener un dispositivo Blue-
tooth. Estos protocolos son el núcleo de Bluetooth.
El resto de protocolos, no pertenecientes al núcleo de Bluetooth, sólo serán necesa-
rios si lo requiere la aplicación concreta. La mayor o menor complejidad de la pila de
protocolos para una aplicación dada vendrá determinada por los requerimientos de és-
ta. A continuación se van a explicar algunas de las capas más importantes de la pila de
Bluetooth, y algunos de los protocolos adaptados.
Figura 2.5: Pila de protocolos Bluetooth
Figura 2.6: Esquema del hardware de un dispositivo Bluetooth
2.8.1. Arquitectura hardware

Las capas o protocolos inferiores (capa de radio, banda base y LMP), por debajo de
HCI, como se muestra en la figura 2.5, son implementadas por el propio hardware del
dispositivo Bluetooth. Estas capas dan una interfaz simple para crear comunicaciones de
voz y datos entre dos dispositivos.
El hardware que forma el dispositivo Bluetooth está constituido por dos partes. Un
dispositivo de radio, encargado de modular y transmitir la señal, y un controlador digital,
compuesto por una CPU, por un procesador de señales digitales (DSP, Digital Signal
Processor) llamado controlador de enlace (LC, Link Controller) y de los interfaces con el
dispositivo anfitrión.
El LC es el encargado del procesamiento de banda base y del control de los protocolos
ARQ2 y FEC3 de capa física. Además, se encarga de las funciones de transferencia (tanto
asíncrona como síncrona), codificación de audio y encriptación de datos.
2
Solicitud automática de repetición (ARQ, Automatic Repeat Request)
3
Control de errores de reenvío (FEC, Forward Correction Error)
Figura 2.7: División del canal físico de Bluetooth
El CPU del dispositivo se hace responsable de atender las instrucciones relacionadas

con Bluetooth del dispositivo anfitrión, para así simplificar su operación. Para ello, sobre
el CPU corre un software denominado Link Manager que tiene la función de comunicarse
con otros dispositivos por medio del protocolo LMP.
Algunas tareas realizadas por LC y el Link Manager son:
Envío y recepción de datos
Empaquetamiento y peticiones
Determinación de conexiones
Autenticación
Negociación y determinación de tipos de enlace (SCO o ACL)
Determinación del tipo de cuerpo de cada paquete
Ubicación del dispositivo en modo sniff o hold
2.8.1.1. Capa de radio

Es la capa más baja definida en la especificación Bluetooth. Especifica los requisitos
del aparato transceptor. Maneja y controla las señales de radiofrecuencia (RF, Radio Fre-
quency). El canal de radio de Bluetooth utiliza espectro ensanchado y salto en frecuencia
(FHSS, Frequency Hopping Spread Spectrum), por lo que puede cambiar de estado hasta
1600 veces por segundo sobre 79 frecuencias distintas separadas 1 MHz, empezando en
2.402 GHz y terminando en 2.480 GHz, como se aprecia en la figura 2.7. Para cumplir
las normas de banda en cada país, se deja una banda de guardia en los límites sUperior e
inferior de la banda.
En Francia y Japón, esta banda de frecuencia es menor y utiliza un sistema de 23 sal-
tos, debido a problemas por conflictos con las frecuencias utilizadas por el ejército en sus
transmisiones. En la figura 2.8 muestra una tabla resumen del canal físico de Bluetooth.
FHSS
Frequency Hopping Spread Spectrum funciona con la transmisión de un paquete de infor-
mación sobre un canal distinto cada vez, siguiendo un patrón de salto que conoce tanto
el emisor como el receptor. De esta forma se evitan muchas interferencias y se consigue
Figura 2.8: Canal físico de Bluetooth
robustez. Cada ranura temporal en Bluetooth dura 625 , y cada paquete puede durar
una, tres o cinco ranuras temporales, llamadas slots.
Clases de potencia
Un dispositivo Bluetooth se clasifica dentro de 3 tipos de potencia:
Clase de potencia 1: para aparatos de gran cobertura, 100 metros, con una potencia
máxima de 20 dBm.
Clase de potencia 2: para dispositivos de cobertura media, 10 metros, cuya potencia

máxima es de 4 dBm.
Clase de potencia 3: para aparatos de bajo alcance, 10cm, con potencia máxima
entorno a 0 dBm.
Modulación de frecuencia Gausiana

Bluetooth utiliza una modulación de frecuencia Gaussiana (GFSK, Gaussian Frequency
Shift Keying), en la que un “1” binario es representado por una desviación positiva de la
frecuencia y un “0” binario por una desviación negativa de la frecuencia.
2.8.1.2. Banda base

Esta capa define piconets, maneja sincronización entre dispositivos, define estados de
potencia y los tipos de enlaces.
Banda base es la capa física de Bluetooth, principalmente trata los canales y enlaces
físicos, corrección de errores, seguridad de Bluetooth y selección de salto. Esta capa, que
se encuentra encima de la capa de radio, trata los paquetes, hace la paginación y aplica un
esquema de división dÚplex en el tiempo (TDD, Time Division DUplex), para así poder,
alternativamente, ser transmisor y receptor. El maestro empieza su transmisión en los slots
pares y el esclavo en los slots impares, para así poder llevar acabo la transmisión, como
se aprecia en la figura 2.9.
La banda base controla el tipo de enlace, que puede ser síncrono o asíncrono.
Síncrono orientado a la conexión (SCO, Sinchronous Connection Oriented)

Este tipo de enlace es orientado a comunicaciones de voz. El enlace es punto a punto
entre el maestro y un esclavo de la piconet. El maestro puede tener hasta tres enlaces
full-dUplex simultáneos de voz. Los enlaces funcionan a 64 kb/s y los paquetes no
se retransmiten nunca.
Figura 2.9: Transmisión por división en el tiempo
Figura 2.10: Tipos de enlaces físicos
Asíncrono sin conexión (ACL, Asinchronous Connectionless)

Enlace para conexiones de datos. Es un único enlace entre el maestro y varios escla-
vos, por lo que es un enlace punto multipunto. El maestro puede establecer conexión
con cualquier esclavo de la piconet, aunque éste tenga un enlace SCO ya estableci-
do. Únicamente puede haber un enlace ACL y los paquetes pueden retransmitirse.
La tasa mayor de transmisión se laogra con los paquetes de tipo DH5 (ver siguiente
sección). Así se logra alcanzar una conexión punto a punto o una tasa asimétrica
máxima de 723,2 Kb/s en un sentido y 57,5 Kb/s en otro.
Tipos de paquetes
En una primera clasificación, hay tres tipos de paquetes, los que ocUpan 1, 3 ó 5 ranuras
temporales (slots). Además de las ranuras temporales, los paquetes también se diferencian
por los distintos modos de corrección de errores, que son DM (Data Medium Speed) o DH
(Data High Speed). También existen los paquetes DV (Data Voice), como combinación
de datos SCO y ACL en un mismo paquete en una ranura. Por lo que existen nueve tipos
diferentes de paquetes, tres DM, tres DH y tres DV.
En la figura 2.11 siguiente, se ve el formato de un paquete SCO y de un paquete ACL,
respectivamente, donde la única diferencia entre ellos es la carga útil o payload.
Direcciones de las unidades Bluetooth
Los dispositivos Bluetooth tienen asignadas cuatro tipos diferentes de direcciones, cada
una con una función distinta.
Figura 2.11: Formato de los paquetes SCO y ACL, respectivamente
BD_ADDR (Bluetooth Device Address) dirección única de 48 bits que cada dispo-
sitivo transceptor de Bluetooth posee.
AM_ADDR (Active Member Address) es un número de 3 bits, únicamente válido

cuando el esclavo está activo en el canal.
PM_ADDR (Parked Member Address) dirección de 8 bits para diferenciar a los

esclavos estacionados.
AR_ADDR (Access Request Address) dirección de petición de acceso usada por el

esclavo estacionado para determinar el medio slot esclavo-a-maestro en la ventana
de acceso, esto le permite mandar mensajes de petición de acceso.
Seguridad en Bluetooth
La seguridad, en el nivel de enlace, se mantiene mediante la autenticación de los usuarios
y la encriptación de la información. Para esta seguridad básica se necesita una dirección
pública que sea única para cada dispositivo (BD_ADDR), dos claves secretas (clave de
autenticación y clave de encriptación) y un generador de números aleatorios. Primero, el
dispositivo realiza la autenticación emitiendo un mensaje y el otro dispositivo tiene que
enviar una respuesta a ese mensaje basado en el propio mensaje, su BD_ADDR y una
clave de enlace compartida entre ellos. Después de la autenticación, la encriptación se usa
para comunicarse.
2.8.1.3. LMP
LPM es el protocolo que administra todos los recursos preestablecidos por la capa
banda base, realiza transición entre modos de potencia, administra los enlaces y realiza
funciones de seguridad. Principalmente, el Protocolo de administración del enlace, se
encarga de descubrir otros administradores remotos y comunicarse con ellos.
Figura 2.12: Formato de un paquete L2CAP
2.8.2. HCI
La interfaz de controlador del host, HCI, es un dispositivo hardware opcional dentro
del dispositivo Bluetooth. HCI es utilizada principalmente como interfaz entre un ordena-
dor y un dispositivo Bluetooth, ésta puede trabajar con varias capas diferentes del contro-
lador del computador: USB, RS 232 ó UART. HCI envía órdenes al controlador de banda
base y al protocolo LMP. A través de esta interfaz, las capas altas de la pila Bluetooth
pueden comunicarse con las capas bajas mediante comandos.
Principalmente, HCI realiza tres funciones, implementa las órdenes para el hardwa-
re de Bluetooth, recibe notificaciones de eventos asíncronos cuando algo ocurre, y por
último, realiza la transferencia de datos, sin “importarle” los datos que transfiere.
2.8.3. Arquitectura Software

En esta sección se pasa a explicar todas las capas de las pila Bluetooth que no perte-
necen a la parte hardware. Estas capas solamente son utilizadas por un dispositivo si las
necesita para desarrollar la aplicación para la que ha sido desarrollado.
2.8.3.1. SDP
El protocolo de descubrimiento de servicios sirve para ofrecer u obtener información
sobre otros dispositivos Bluetooth, con vistas a comunicarse con ellos y utilizar los servi-
cios que ofrecen. El protocolo SDP se utiliza siempre y su objetivo principal es descubrir
que servicios ofrecen otros aparatos Bluetooth.
2.8.3.2. L2CAP
Logical Link Control and Adaption Protocol es el primer protocolo a nivel software.
L2CAP apoya la emisión multicanal de protocolos de niveles más altos, la segmentación
de paquetes y la nueva sesión, y el transporte de la información de servicio.
L2CAP es uno de los capas necesarias para los protocolos de niveles sUperiores, ya
que ofrece servicios de datos a estos protocolos. L2CAP puede ser visto como un multi-
plexor, ya que se encarga de coger los datos de las capas sUperiores y de las aplicaciones
y enviarlas, gracias a la interfaz HCI, a las capas bajas de las pila. Esta capa, sólo puede
transmitir datos, nunca audio.
El formato de los paquetes L2CAP es el siguiente:
L2CAP tiene varias funciones, entre ellas se destacan las más importantes:
Multiplexación de protocolos de capas sUperiores: L2CAP permite, con esta fun-

ción, compartir el mismo enlace físico.
Segmentación y reensamblado: como los paquetes de datos definidos en la capa

banda base están limitados en tamaño, la función de segmentación y reensamblado
permite a las capas sUperiores transmitir paquetes mayores que los que aprueban
las capas bajas de la pila.
Gestión de QoS (calidad de servicio): el establecimiento de conexión admite el in-

tercambio de información dependiendo de la calidad del servicio, L2CAP controla
que los convenios QoS se efectúen.
Los canales lógicos que crea la capa L2CAP son identificados por un canal de identifi-
cación (CID, Channel Identifier). Las implementaciones para manejar el CID son libres y
no se puede utilizar el mismo CID como punto final local de canal L2CAP para múltiples
canales L2CAP simultáneos entre un aparato local y algún aparato remoto. Las capas que
descansan sobre L2CAP son identificadas por el protocolo multiplexor de servicio (PSM,
Protocol Service Multiplexor). Los dispositivos remotos solicitan una conexión a un PSM
particular, y L2CAP reserva un CID.
2.8.3.3. RFCOMM
El protocolo de radio frecuencia orientado a emular puertos serie COM en un PC

(RFCOMM, Radio Frecuency oriented emulation of the serial COM port on a PC) pro-
porciona la emulación de puertos sucesivos sobre el protocolo L2CAP. RFCOMM es un
protocolo de transporte que modula una comunicación a través del puerto RS-232 sobre
un canal L2CAP. Además, RFCOMM proporciona mecanismos para el control de flujo.
RFCOMM utiliza los servicios de L2CAP para establecer canales L2CAP a entidades
RFCOMM de otros dispositivos.
2.8.4. Protocolos adaptados

Ante la necesidad de utilizar otros protocolos ya existentes, como IP (Internet Proto-
col), se han adaptado éstos y es posible tener aplicaciones Bluetooth utilizando TCP/IP
(Transmision Control Protocol/Internet Protocol) o PPP (Point-to-Point).
2.8.4.1. PPP
PPP está construido para funcionar sobre RFCOMM y poder establecer conexiones
punto a punto. El trabajo de PPP es coger los paquetes IP y enviarlos o recibirlos a una
LAN. En este proyecto PPP se utiliza para asignar direcciones IP a los dispositivos Blue-
tooth con los que se han trabajado.
2.9. PILAS DE PROTOCOLOS PARA MODELOS DE USO DE BLUETOOTH 23
Figura 2.13: Pila de protocolos para teléfono 3 en 1
2.8.4.2. TCP/UDP/IP
Estos protocolos son usados para acceder a Internet y su implementación en aparatos

Bluetooth permite la comunicación con cualquier otro aparato que esté conectado a Inter-
net. Sin estos protocolos adaptados Bluetooth no sería lo que es hoy, ya que la mayoría de
los dispositivos que poseen Bluetooth los utilizan, por ejemplo, como un punto de acceso
Bluetooth que se puede usar como bridge a Internet.
2.8.4.3. Protocolo OBEX
OBEX (IrOBEX) es un protocolo de sesión creado por la Asociación de Datos Infra-

rrojos (IrDA) para intercambiar objetos con la misma base funcional que HTTP (Hiper-
Text Transfer Protocol) pero con un sistema más rápido.
2.8.4.4. WAP
El Protocolo de Aplicación Inalámbrico (WAP, Wireless Aplication Protocol), es uti-

lizado en Bluetooth para funciones de control remoto o búsqueda de datos desde un orde-
nador hacia un handset.
2.9. Pilas de protocolos para modelos de uso de Bluetooth

Cada pila de protocolos es necesaria para un determinado modelo de uso de Bluetooth.
La capa más inferior representada en los gráficos de cada pila, será L2CAP, aunque por
debajo estarán banda base, la capa de radio y LMP.
2.9.1. Teléfono 3 en 1
Un mismo teléfono puede utilizarse como fijo, si se encuentra dentro del radio de ac-
ción del punto de acceso instalado en nuestra casa, como teléfono móvil si está fuera del
radio de acción del punto de acceso, y por último, como medio de acceso a nuestros con-
tactos, teléfonos, correo electrónico, etc. En la figura 2.13 se aprecia la pila de protocolos
necesaria para este modelo de uso.
Figura 2.14: Pila de protocolos para la transferencia de ficheros
Figura 2.15: Pila de protocolos para el headset final
2.9.2. Transferencia de ficheros

El protocolo destinado o diseñado para la transferencia de ficheros es el OBEX, que
se encuentra por encima de RFCOMM. Aparte de éste, el modelo de uso, representado en
la figura 2.14, necesita del protocolo SDP para descubrir los servicios disponibles.
2.9.3. Headset final

El audio se conecta directamente con la capa banda base, sin la ayuda de L2CAP. El
headset envía órdenes o comandos AT y recibe los códigos resultantes, con lo que permite
al headset responder a llamadas entrantes y finalizarlas sin tener que manejar físicamente
el teléfono.
2.9.4. Acceso a LAN

Esta pila de protocolos utiliza el protocolo adaptado PPP. Éste se encuentra por encima
de RFCOMM que lo precisa para transferir datos útiles. Encima de PPP se encuentra IP,
necesario para acceder a una LAN, esta parte es esencial para el proyecto y será explicada
con más profundidad en el capítulo 3 (IP sobre Bluetooth).
2.10. PASOS PARA EL ESTABLECIMIENTO DE LA CONEXIÓN 25
Figura 2.16: Pila de protocolos para el modelo de uso de acceso a LAN
Figura 2.17: Pila de protocolos para hacer un bridge de Internet
2.9.5. Bridge de Internet

Este escenario necesita una pila de protocolos de dos ramas más la de SDP. En una
de las ramas se tienen órdenes AT sobre RFCOMM utilizadas para controlar el teléfono
móvil o módem. En la otra rama, el protocolo PPP sobre RFCOMM para transferir datos
útiles.
2.9.6. Sincronización continúa

Los dispositivos Bluetooth mantienen constantemente la información sincronizada,
por lo que si se modifica algo en nuestro ordenador y lo mismo estaba almacenado en
nuestra PDA, se modificará automáticamente. La pila utilizada es la representada en la
figura 2.18.
2.10. Pasos para el establecimiento de la conexión

En este apartado se explican cuales son los posibles estados de un dispositivo Blue-
tooth, y los pasos que se realizan antes de crear una conexión Bluetooth.
Figura 2.18: Pila de protocolos para el modelo de sincronización continua
2.10.1. Estados de un dispositivo Bluetooth

Conectado: el dispositivo está activo y operativo.
Standby: el aparato Bluetooth está totalmente inactivo.
Inquiry: proceso que permite a un dispositivo descubrir nuevos dispositivos.
Inquiry Scan: estado con el que un dispositivo permite que sea descubierto por otros
dispositivos que están haciendo un inquiry.
Page: este proceso le permite a un maestro establecer una conexión con un esclavo.
Page Scan: de igual forma que con el proceso inquiry, el dispositivo que desee conec-
tarse al maestro debe estar en este estado, page scan, esperando paquetes page.
2.10.2. Establecimiento de la conexión

Primero, si no se conoce nada de un aparato remoto, se realizará un proceso de bús-
queda, y a continuación el proceso de paginación.
Proceso de búsqueda: el proceso de búsqueda consigue descubrir los dispositi-

vos están en su área de cobertura y determina las direcciones y los relojes de los
aparatos. El dispositivo fuente envía los paquetes de la búsqueda y espera a recibir
respuesta de la búsqueda. En el otro lado, el destino, recibe los paquetes de búsque-
da siempre que esté en el estado de análisis de la búsqueda, y pasará al estado de
respuesta de la búsqueda y mandará los paquetes de respuesta de la búsqueda a la
fuente. Este proceso se puede ver en la figura 2.20.
Proceso de paginación: con este proceso se consigue establecer conexión con

el otro dispositivo. Únicamente se necesita la dirección del dispositivo Bluetooth
con el que se quiere crear la conexión. En el primer paso, el dispositivo fuente
pagina el aparato destino, en el otro lado, el destino recibe la paginación, entonces,
éste manda una contestación a la fuente. Después, la fuente manda un paquete FHS
(Frequency Hop Syncgronisation) al destino y éste manda una segunda contestación
2.10. PASOS PARA EL ESTABLECIMIENTO DE LA CONEXIÓN 27
Figura 2.19: Posibles cambios de estado de un dispositivo Bluetooth
a la fuente. Por último, la fuente y el destino intercambian características del canal.

El proceso de paginación puede observarse gráficamente en la figura 2.21.
De un conjunto total de 79 (23) portadoras del salto, un subconjunto de 32(16) porta-

doras activas han sido definidas. El subconjunto, que es seleccionado pseudo-aleatóriamente,
se define por una única identidad.
Acerca de la secuencia de activación de las portadoras, se establece que, cada una de
ellas visitará cada salto de portadora una sola vez, con una longitud de secuencia de 32
(16) saltos. En cada uno de los 2.048 (1.028) saltos, las unidades que se encuentran en
modo standby (en espera) mueven sus saltos de portadora siguiendo la secuencia de las
unidades activas. El reloj de la unidad activa siempre determina la secuencia de activación.
Durante la recepción de los intervalos, en los últimos 18 slots ó 11.25 ms, las unidades
escuchan una simple portadora de salto de activación y correlacionan las señales entrantes
con el código de acceso derivado de su propia identidad. Si la mayoría de los bits recibidos
coinciden con el código de acceso, la unidad se auto-activa e invoca un procedimiento de
ajuste de conexión. Sin embargo, si estas señales no coinciden, la unidad vuelve al estado
de reposo hasta el siguiente evento activo.
Para establecer la piconet, la unidad maestra debe conocer la identidad del resto de
unidades que están en modo standby en su radio de cobertura. El maestro, que inicia
la piconet, transmite el código de acceso continuamente en periodos de 10 ms, que son
Figura 2.20: Proceso de búsqueda
Figura 2.21: Proceso de paginación
recibidos por el resto de unidades que se encuentran en standby. El tren de 10 ms de

códigos de acceso de diferentes saltos de portadora, se transmite repetidamente hasta que
el receptor responde o bien se excede el tiempo de respuesta.
Cuando una unidad emisora y una receptora seleccionan la misma portadora de salto,
la receptora recibe el código de acceso y devuelve una confirmación de recibo de señal, es
entonces cuando la unidad emisora envía un paquete de datos que contiene su identidad
y frecuencia de reloj actual. Después de que el receptor acepta este paquete, ajusta su
reloj para seleccionar el canal de salto correcto determinado por el emisor. De este modo
se establece una piconet en la que la unidad emisora actúa como maestra y la receptora
como esclava. Después de haber recibido los paquetes de datos con los códigos de acceso,
la unidad maestra debe esperar un procedimiento de requisito por parte de los esclavos,
diferente al proceso de activación, para poder seleccionar una unidad específica con la que
2.11. PRODUCTOS BLUETOOTH DISPONIBLES EN EL MERCADO 29
comunicarse.
El número máximo de unidades que pueden participar activamente en una simple pi-
conet es de 8, un maestro y siete esclavos, por lo que la dirección MAC del paquete de
cabecera que se utiliza para distinguir a cada unidad dentro de la piconet, se limita a 3
bits.
2.10.3. Modos de Conexión

Un dispositivo Bluetooth en estado de conexión puede encontrarse en cualquiera de
los siguientes cuatro modos: Active, Hold, Sniff y Park.
Modo Active
En el modo activo, la unidad Bluetooth participa activamente en el canal. El maestro
planifica la transmisión basada en las demandas de tráfico hacia y desde los diferen-
tes esclavos. Además, soporta transmisiones regulares para mantener a los esclavos
sincronizados al canal. Los esclavos activos escuchan en las ranuras maestro a es-
clavo esperando paquetes. Si un esclavo activo no es direccionado, podría dormir
hasta la próxima transmisión del nuevo maestro.
Modo Hold
Los dispositivos sincronizados a una piconet pueden entrar en los modos power-
saving en los que la actividad de los dispositivos es menor. La unidad maestra puede
poner unidades esclavas en modo hold, donde únicamente está funcionando un con-
tador interno. Las unidades esclavas también pueden demandar ser puestas en modo
hold. La transferencia de datos vuelve a comenzar de forma instantánea cuando las
unidades abandonan este modo.
Modo Park
En este modo, un dispositivo se encuentra sincronizado a la piconet pero no partici-
pa en el tráfico. Los dispositivos en el estado park han abandonado sus direcciones
MAC y ocasionalmente escuchan el tráfico del maestro para volver a sincronizarse
y comprobar los mensajes broadcast. Tiene el ciclo de trabajo más corto de los tres
modos de ahorro de energía (sniff, hold y park).
Modo Sniff
Los dispositivos sincronizados a una piconet pueden entrar en los modos de ahorro
de energía en los cuales la actividad del dispositivo es menor. En el modo sniff, un
dispositivo esclavo escucha a la piconet a una tasa reducida, lo que reduce su ciclo
de trabajo. El intervalo sniff es programable y depende de la aplicación. Tiene el
mayor ciclo de vida de los tres modos de ahorro de energía.
2.11. Productos Bluetooth disponibles en el mercado

En esta sección del proyecto se describen distintos a la vez que recientes dispositivos
con la tecnología Bluetooth. Como ya se dijo (ver 1.3), son muchas las aplicaciones
Figura 2.22: Heweltt Packard iPAQ 5450
Bluetooth y todavía quedan muchas por descubrir. A continuación, se pasa a explicar los
aparatos que incorporan Bluetooth más novedosos disponibles en el mercado.
2.11.1. PocketPCs con Bluetooth

Cada día aparecen más PDA en el mercado que incluyen Bluetooth de forma inte-
grada. Entre este tipo de equipos, los PocketPC son los dispositivos Bluetooth con más
perfiles incorporados. El PocketPC del que se habla es esta sección es el reciente HP iPAQ
5450 [Hewlett Packard, WWW] (figura 2.22), que incorpora Bluetooth, dispone de conec-
tividad Wireless LAN, lo que amplia enormemente las posibilidades de estos equipos, ya
que será posible la comunicación de forma inalámbrica con otros dispositivos persona-
les mediante Bluetooth y a la vez estar conectados a una red local inalámbrica de alta
velocidad.
Este nuevo equipo HP, a diferencia de sus antecesores, los Compaq IPAQ 3870 y 3970
en el que la implementación de Bluetooth había sido muy limitada, se han introducido
mejoras en cuanto a la integración de la tecnología Bluetooth. Se han incorporado varios
perfiles, como por ejemplo el de auricular, que permite poder usar un auricular Bluetooth
en futuras aplicaciones de conexión a una red celular de telefonía móvil.[Ref5, WWW]
2.11.2. Teclados y ratónes inalámbricos mediante tecnología Blue-

tooth
Microsoft [Microsoft, WWW] propone un teclado y ratón inalámbricos mediante tec-
nología Bluetooth . El teclado incorpora las teclas multimedia típicas de control de vo-
lumen, mute, play, stop, pausa, avance y retroceso de pista, además de las teclas para
función sleep y accesos directos a Internet, correo, etc.[Ref5, WWW]
El ratón es óptico con botones personalizables y rueda scroll.
Apple [Apple, WWW] estrena su ratón y teclado inalámbrico basados en tecnología
Figura 2.23: Teclados y ratóns con tecnología Bluetooth
Bluetooth. Los nuevos productos necesitan para funcionar una computadora que tenga
sistema operativo Mac OS X v.10.2.6 como mínimo. Estos accesorios pueden ubicarse a
una distancia de hasta diez metros de la computadora y tienen encriptación segura de 128
bits, de manera que la información que se escribe en el teclado, por ejemplo, no puede
ser espiada en el camino. Una de las características más importantes es que incorporan
el software AFH (Adaptative Frequency Hopping), también desarrollado por Apple, que
elimina las interferencias entre el teclado y el ratón y cualquier otra herramienta o red ina-
lámbrica que haya en el ambiente y que pueda hacer que el desempeño de los accesorios
no sea óptimo.[Ref6, WWW]
2.11.3. Teléfonos móviles

La gran mayoría de los últimos teléfonos móviles que están saliendo al mercado incor-
poran Bluetooth. Así, se consigue que estos dispositivos móviles sean más que un simple
dispositivo para llamar, ya que con Bluetooth podrán intercambiar datos con un ordenador,
hablar con el móvil a través de un headset o conectarse a una LAN. más completos.
En primer lugar se habla del Panasonic X70[Panasonic, WWW], el cual tiene cámara
integrada CMOS 110K y pantalla principal de 132x136 píxeles a 65.000 colores, que se
caracteriza exteriormente por su diseño de carcasa partida y de doble pantalla, ya que
sobre la parte posterior de la pantalla principal, una vez cerrado el terminal se dispone de
una pequeña pantalla en blanco y negro de 96 X 28 píxeles, que proporciona una serie
de información básica acerca del estado del terminal. Otras características que posee el
Panasonic son Bluetooth e IrDa, 4MB de memoria dinámica, Java, sonidos polifónicos,
SMS / MMS / Email, entre otras.[Ref5, WWW]
Nokia aporta el nuevo 6600. Mientras se espera la llegada del primer modelo de esta
serie con conexión a redes de tercera generación, el 6650, Nokia ha lanzado un nuevo mo-
delo con prestaciones muy similares a éste, pero con conexión a las redes GSM/GPRS ac-
tuales. Se trata del modelo 6600, el cual entre otras características destacadas dispondrá de
conexión tribanda GSM/GPRS E900/1800/1900 cámara integrada con zoom, grabación de
Figura 2.24: Nokia 6600 y Panasonic X70
Figura 2.25: Punto de enlace BlueTake
audio y video, 6 MB de memoria RAM interna, además de una ranura para tarjetas de me-
moria Stick Duo (SD), Java MIPD 2.0, sincronización y conexión wireless vía Bluetooth.
Otro aspecto destacado de este nuevo móvil es su excelente pantalla TFT a color con una
resolución de 176x208 píxeles capaz de representar hasta 65,536 colores.[Ref5, WWW]
2.11.4. Puntos de enlace mediante Bluetooth

La marca BlueTake [BlueTake, WWW] tiene puntos de enlace con tecnología Blue-
tooth con la que se conseguirá conectar una red inalámbrica con otra red inalámbrica
convencional (IEEE 802.11). El punto de enlace tiene un área de cobertura de 100 me-
tros (clase 1), sensibilidad de -70 dBM. La interfaz cuenta con puertos RS232 y puertos
10/100 Base-T Ethernet.[Ref5, WWW]
2.11.5. Tarjetas Compact Flash Bluetooth de BlueTake

BlueTake ha lanzado al mercado tarjetas Compact Flash Bluetooth que disponen de
10 metros (clase 2) de área de cobertura en espacio libre de obstáculos y una sensibilidad
Figura 2.26: Tarjeta Compact Flash Bluetooth de BlueTake
Figura 2.27: Headset BlueTake, Motorola y Plantronics, respectivamente
menor a -85 dBm.[Ref5, WWW]
2.11.6. Auriculares o headset

Son muchos los auriculares disponibles que transmiten y reciben a través de Blue-
tooth, en la figura 2.27 se presentan 3 modelos de auriculares (BlueTake, Motorola o
Plantronics[Plantronic, WWW]), todos con Bluetooth y con un alcance efectivo de 10
metros (clase 2).[Ref5, WWW]
2.11.7. Reproductor headset MP3 con Bluetooth

La firma coreana Openbrain Technologies[OpenBrain, WWW] ha desarrollado un re-
productor MP3 con conexión Bluetooth que se suministra conjuntamente con otro modelo
de auricular estéreo Bluetooth. Con este equipo, además de poder escuchar música sin ne-
cesidad de tener a mano el reproductor, se podrá transferir los temas en MP3 desde y
hacia el ordenador, gracias al adaptador USB opcional y al software suministrado. Los
primeros auriculares mostrados en la figura 2.28, como los que se suministran junto con
el reproductor MP3, disponen del perfil de auricular que dejará poder usarlos también con
el teléfono móvil (siempre que el móvil disponga de Bluetooth).[Ref5, WWW]
2.11.8. Kit de impresión Bluetooth de 3com

Es una opción para aquellos que deseen dotar de conectividad Bluetooth a su com-
putador e impresora mediante los dos adaptadores suministrados con este kit, y es que
Figura 2.28: Reproductor headset MP3 con Bluetooth
Figura 2.29: Kit de impresión Bluetooth para impresoras
permitirán poder compartir estos equipos con otros dispositivos Bluetooth. Este kit no es
sólo una solución de impresión inalámbrica para el ordenador, sino que se podrá imprimir
directamente en una impresora vía Bluetooth desde otro ordenador, una PDA o incluso
un teléfono móvil. El computador también puede conectarse con otros dispositivos Blue-
tooth, aparate de la impresora, gracias al adaptador USB.[Ref5, WWW]
2.11.9. Tarjeta SD Bluetooth de Socket

La empresa Norteamericana Socket[Socket, WWW], especialista en periféricos y sis-
temas de conexión para equipos móviles ha creado la Tarjeta Bluetooth Compact Flash,
sin antena exterior, que permite poder integrarla completamente en dispositivos como
PocketPCs y Handhelds PCs (PCs de bolsillo). Sus reducidas dimensiones (24 x 40 x 2.1
mm.) y su ligerísimo peso de 10 gr, además de un consumo de corriente insignificante,
hacen que el rendimiento y características generales de nuestro equipo anfitrión no se vea
afectado.[Ref5, WWW]
2.11.10. Receptor GPS Bluetooth

Socket ha presentado un receptor portátil GPS (Global Positioning System) de 12 ca-
nales con conexión inalámbrica mediante Bluetooth. Este GPS inalámbrico dispone de un
transmisor Bluetooth de Clase 2, lo que le proporciona una distancia máxima de cone-
xión de hasta 10 metros, distancia más que suficiente para el uso personal para el que está
Figura 2.30: Tarjeta SD Bluetooth de Socket
Figura 2.31: Receptor GPS Bluetooth
orientado el equipo. Es compatible con cualquier dispositivo Bluetooth V1.1 que soporte
el perfil de puerto serie. Sus reducidas dimensiones, 50x90x16mm, y su ligero peso de
61 g, lo hacen el compañero ideal de PDAs, ordenadores portátiles e incluso teléfonos
móviles con conexión Bluetooth durante nuestros viajes. Dispone además de conexión
para antena externa en aquellos casos en que sea necesario o recomendable el uso de
ésta.[Ref5, WWW]
2.11.11. Sistema de manos libres Bluetooth para el coche
La empresa Parrot[Parrot, WWW] ha desarrollado el primer sistema de manos libres

para el coche. El Parrot CK4000 permite telefonear con el teléfono en el bolsillo. Permite
oír al interlocutor en los altavoces de la radio.
Se puede cambiar de teléfono Bluetooth sin necesitar de cambiar la instalación tele-
fónica. El CK4000 se adapta a todos los teléfonos con Bluetooth del mercado de hoy.
Al salir del coche, se conserva el teléfono móvil. De este modo, con el mismo teléfo-
no, los interlocutores pueden llamarle esté dónde esté, en el coche o en cualquier otro
lugar.[Ref7, WWW]
Figura 2.32: Sistema de manos libre para el coche
2.12. Material Utilizado

En esta sección se explica el estándar que desarrolla chips Bluetooth. Además se habla
de los dispositivos Bluetooth utilizados en el desarrollo de las pruebas del proyecto.
Todos los dispositivos utilizados incorporan un microchip Bluetooth que incorpora un
radio transmisor. Éste es implantado en los dispositivos digitales. Entonces, la tecnología
Bluetooth se encarga de realizar las conexiones de forma continua, sin utilizar ningún
cable.
2.12.1. BlueCore
BlueCore [BlueCore, WWW] es un estándar para el desarrollo de chips Bluetooth.
BlueCore realiza arquitecturas que combinan banda de base DSP (Digital Signal Pro-
cessor), radio y las funciones del microcontrolador. Además facilitando un completo soft-
ware Bluetooth se posibilita el desarrollo para lograr la interoperatividad.
Principales Caracteristicas de BlueCore:
Plataforma CMOS: Los dispostivos de BlueCore son fabricados con tecnología de
los semiconductores complementarios de óxido metálico (CMOS, Complementary
Metal Oxide Semiconductor). El bajo coste, suministro de seguridad y los beneficios
del proceso resultante de su tecnología, proporcionan el mejor soporte para ayudar
al éxito de OEMs (Fabricantes de equipos originales) en el competitivo mercado de
las aplicaciones inalámbricas.
2.12. MATERIAL UTILIZADO 37
Diseño de chip sencillo: BlueCore está desarrollando soluciones de radio CMOS

para aumentar la velocidad y simplificar el diseño del ciclo para Bluetooth. Esto ha
resultado un excepcional grado de integración, eliminando todos los componentes
adicionales antes requeridos.
Entre las nuevas técnicas innovadoras crean un nuevo diseño que permite al canal
de filtros ser implementado en CMOS y un on-chip VCO incluyendo todos los
elementos resonantes. Esto elimina todos los componentes externos SAW (tipo de
filtro), cerámicos o inductores. Todo lo que resta es añadir una antena y cristal, más
unos elementos pasivos y un par de pistas de impresión para introducir un filtro
RF. Después, se puede conectar la función Bluetooth en el sistema principal, de
la misma manera en que se añade un circuito digital. Hay incluso un regulador de
voltaje el cual facilita a BlueCore ser manejado desde USB.
Software on-chip: BlueCore incorpora software de Bluetooth en formato BlueS-

tack, lo que reduce el tiempo de desarrollo. Una nueva característica de sus servicios
es que posibilita a los usuarios la configuración del nivel de BlueStack que carga
al mismo tiempo, usando un conector de software. Esto proporciona al usuario la
opción de utilizar la configuración estándard de Bluetooth con un HCI entre los
subsistemas de radio de Bluetooth y su servidor.
2.12.2. Dispositivos Bluetooth por USB de Microtune

Para la realización del proyecto se han utilizado unos equipos Bluetooth de la empresa
Microtune [Microtune, WWW]. Microtune es una empresa representada en España por
Ibérica de Componentes, S.A. El modelo exacto de los dispositivos es el MT0760. Las
características que definen los módems son: pequeño tamaño, bajo consumo y gastos de
producto. Bluetooth establece el cumplimiento de normas, funcionalidad fácil de usar,
capacidad de configuración flexible y tiempo-a-mercado corto.
2.12.2.1. Chip de los dispositivos

Bluetooth implica movilidad, por lo que el consumo de energía se debe controlar hasta
el más mínimo detalle. Para conseguir alcanzar el objetivo de bajo consumo y bajo coste
se ideó una solución implementada en un solo chip de 9x9 milímetros integrado por tran-
sistores de tecnología CMOS, y un consumo inferior en un 97 % al de un teléfono móvil.
Para transmitir a una distancia máxima de 10 metros necesita 1 mW de potencia, mientras
que la versión de largo alcance, 100 metros, se eleva a 100 mW.
Estos dispositivos incorporan todas las funciones (RF, base banda, la memoria y el
procesador) necesarias para la solución total Bluetooth.
2.12.2.2. MT0760 Bluetooth OneChip

El dispositivo utilizado en las pruebas es el modelo MT0760 Bluetooth OneChip, se
puede ver sin carcasa en la figura 2.34. El MT0760 es un transceptor de banda de 2.4 GHz
con lógica de banda base Bluetooth integrada, incluyendo un interfaz USB 1.1, memoria
flash programable y procesador system-chip. Los puertos UART, SPI (Serial Peripheral
Figura 2.33: Chip MT0760 de Microtune
Figura 2.34: MT0760 Bluetooth OneChip sin carcasa
Interface) y PMC (PMConnex de Project Management Centre) ofrecen Bluetooth 1.1 full-
speed y capacidad de transmisión de voz.
Diseñado como un Bluetooth USB Dongle-on-Chip el MT0760 también puede ser
integrado en ordenadores portátiles, cámaras digitales, PDAs y una amplia variedad de
aplicaciones inalámbricas de voz y datos.
La memoria flash del MT0760 OneChip puede ser programada con la pila Bluetooth
1.1 a través del interfaz del controlador de host (HCI) o mediante el protocolo RFCOMM.
También están disponibles unos perfiles certificados, tales como HSP, HFP, DUNP, FTP
y OPP.
El diseño compacto del MT0760 se encuentra en un solo encapsulado para lograr una
fabricación de gran volumen y bajo coste, con los mínimos componentes externos. Esta
reducción de componentes minimiza los costes y mejora la fiabilidad del producto. Al
igual que el resto de productos OneChip, el MT0760 se presenta con una licencia software
de Microtune.
El dispositivo MT0760 integra en la fabricación el conector USB y la antena impresa.
La antena impresa del módem puede ser separada para agregar una antena dual de cable.
El MT0760 soporta los sistemas operativos Windows 98, 2000, ME y XP, posee una
velocidad de transmisión de 723kbps con certificación FCC (Federal Communications
Commision) y CE (Certificación Europea). El dispositivo MT0760 puede ser clase 1 o de
2.12. MATERIAL UTILIZADO 39
Figura 2.35: Diferentes vistas del MT0760 Bluetooth OneChip
Figura 2.36: Sony Ericsson P800
clase 2.
2.12.3. Sony Ericsson P800

Además de los dispositivos de Microtune, se utilizó el teléfono móvil Sony Ericsson
[SonyEricsson, WWW] P800 equipado con Bluetooth para realizar una evaluación de IP
sobre el estándar Bluetooth.
El Sony Ericsson P800 “es” una PDA con todas las funciones más usuales (realizar
llamadas, mensajes SMS y MMS, agenda telefónica, cámara de fotos incorporada) que
tienen casi todos los teléfonos móviles de última generación.
Capítulo 3
IP sobre Bluetooth
Bluetooth no tiene IP como protocolo nativo, por lo que debe hacerse una tarea de seg-
mentación/ensamblaje para poder transmitir los paquetes IP generados por la aplicación.
Hay varias soluciones para usar IP sobre Bluetooth, en el proyecto se trabajó con IP
sobre RFCOMM e IP sobre BNEP, o lo que es lo mismo, se trataró el perfil de acceso
LAN y el perfil de Red de área Personal (PAN). Descritos en profundidad en la seción
3.2.1 y 3.3, respectivamente.
3.1. IP sobre Bluetooth

Como se ha dicho antes, hay muchas maneras de conseguir IP sobre Bluetooth, a
continuación se explican, sin introducirse muy a fondo, algunas de las posibles soluciones
de conseguir IP sobre Bluetooth.
3.1.1. IP sobre L2CAP

Cuando se utiliza este método, se consigue una red más eficiente de Bluetooth, con
menos gastos indirectos. El método todavía no se ha especificado, y puede que nunca lo
haga. IP sobre L2CAP requiere mucho procesamiento en los puntos de acceso. La meta
es hacer los puntos de acceso como “un puente” en vez de cómo un puro router.
La topología maestro-esclavo es un problema en una red IP. La meta es eliminar la
estructura maestro-esclavo y dejar cada nodo actuar idependientemente. IP directamente
sobre L2CAP no soluciona este problema.
3.1.2. IP sobre [PPP sobre L2CAP]

En este método PPP es el encargado de transportar el tráfico IP, sin embargo, la es-
pecificación de Bluetooth es abierta y permite crear otras posibilidades como correr IP
directamente sobre L2CAP.
La posibilidad de tener PPP sobre L2CAP incluye mejoras respecto al método de IP
sobre L2CAP, ya que PPP es el encargado principal de transportar tráfico IP hacia y desde
los clientes a los puntos de acceso (Access Point).
41
42 CAPÍTULO 3. IP SOBRE BLUETOOTH
Figura 3.1: IP sobre L2CAP
Figura 3.2: IP sobre PPP sobre L2CAP
3.1.3. IP sobre [BNEP sobre L2CAP]

BNEP puede ser usado con cualquier protocolo que trabaje sobre Ethernet. Además,
una de las intenciones de BNEP es esconder los papeles de maestro y esclavo. Ésta es una
de las soluciones utilizadas en el proyecto para asignar direcciones IP a los módulos con
los que se ha trabajado. En la sección 3.3 se explica más detenidamente esta solución.
BNEP soporta IPv4, IPv6, IPX y otros protocolos para el establecimiento de una red.
Probablemente, BNEP sea la mejor solución para usar IP sobre Bluetooth. Al contrario
que con PPP, BNEP soporta broadcast y una infraestructura ad-hoc 1 .
Como aspecto negativo, BNEP tiene más overhead que las otras soluciones y requiere
un método de asignación de direcciones IP únicas.
3.1.4. IP sobre [PPP sobre RFCOMM]

IP usado sobre PPP sobre RFCOMM es la otra solución utilizada en el proyecto pa-
ra dar IP a los dispositivos Bluetooth con los que se ha trabajado. IP sobre PPP sobre
RFCOMM está explicado en la sección 3.2.1.
3.1.5. IP sobre ACL

Los enlaces ACL son punto a multipunto. Las ventajas de utilizar IP sobre ACL
son: connection-less y bajo overhead. Al igual que en los enlaces SCO, las desventajas
son más numerosas: necesidad de utilizar nuevos protocolos para controlar la negocia-
ción/fragmentación de MTU la cual crea overhead. Son necesarios cambios en la capa
1
Infraestructura ad-hoc: aquella formada únicamente por un sólo estándar, es decir, sin inclusión de otra
infraestructura como puede ser una LAN.
3.2. LAN EN BLUETOOTH 43
Figura 3.3: IP sobre BNEP sobre L2CAP
Figura 3.4: IP sobre PPP sobre RFCOMM
física.
3.1.6. IP sobre SCO

Los paquetes SCO son usados en enlaces síncronos SCO. Los enlaces SCO son uti-
lizados para tranmitir voz, por lo que resulta extraño usar estos enlaces para transmi-
tir paquetes IP. Como única ventaja sería su bajo overhead en los paquetes. No inclu-
ye CRC (Cyclic Redundancy Check), sólo aporta un único enlace punto a punto, ancho
de banda insuficiente, necesidad de utilizar nuevos protocolos para controlar la negocia-
ción/fragmentación de MTU, serían alguns de sus inconvenientes.
3.2. LAN en Bluetooth

Las redes locales inalámbricas de hoy pueden proveer acceso a Internet, por ejemplo a
estudiantes de alrededor de un campus universitario utilizando una computadora portátil
provista con una tarjeta con acceso inalámbrico. En este sentido el IEEE ha desarrollado
varios estándares en lo que a LAN se refiere.
La especificación IEEE 802.11x define redes locales inalámbricas que emplean ondas
de radio en la banda de 2.4 GHz y 5 GHz conocido como ISM. Las velocidades típicas de
esta tecnología son 11 Mbps en la especificación IEEE 802.11b y la especificación IEEE
802.11a en la banda de 5 GHz que alcanza velocidades de hasta 54 Mbps.
Además, existe la especificación HiperLAN2 del ETSIT (Escuela Técnica SUperior
de Ingeniería de Telecomunicación) que opera en la banda de 5 GHz y que permite la

transferencia de datos de hasta 54 Mbps.
3.2.1. Perfil de acceso LAN definido en la especificación Bluetooth

El perfil de acceso LAN define como los dispositivos Bluetooth pueden acceder a los
servicios de una LAN utilizando PPP. Este perfil también dice como los mismos mecanis-
mos PPP son usados para formar una red consistente de, al menos, dos dispositivos Blue-
tooth. Básicamente, este perfil define el acceso a una LAN usando PPP sobre RFCOMM,
para ello habrá que asignar direcciones IP a los dispositivos Bluetooth que quieran acceder
a la LAN.
El perfil de acceso a LAN define como PPP es soportado en las siguientes situaciones:
Un único terminal de datos puede usar un LAP (LAN Access Point) para una cone-
xión inalámbrica a una LAN, y una vez conectado, operar como si éste estuviera
conectado a la LAN vía DUN (Dial Up Network). El terminal de datos puede en-
tonces acceder a todos los servicios suministrados por la LAN.
Al igual que un único terminal de datos puede conectarse a una LAN a través de un
LAP, un conjunto de terminales de datos pueden conectarse a una LAN de la mis-
ma forma que lo hacía un único terminal. Además, los terminales de datos podrán
comunicarse unos con los otros a través del LAP.
Dos dispositivos Bluetooth pueden comunicarse entre si gracias a una conexión PC-
to-PC, de forma similar a una conexión directa utilizando un cable para establecer
una conexión serie. En este escenario, uno de los dispositivos asumirá el rol de LAP
y el otro dispositivo el papel de DT (Data Terminal).
El perfil de acceso LAN simplemente declara como la capa IP de lo alto de la pila

Bluetooth podría ser usada para proporcionar un enlace TCP/IP entre un par de ordenado-
res o para construir una red formada por un grUpo de computadores locales y el punto de
acceso de la LAN.
El LAP es un dispositivo Bluetooth que proporciona acceso a la LAN. El LAP sumi-
nistra servicios de un servidor PPP. La conexión PPP es llevada sobre RFCOMM, éste es
el encargado de transportar los paquetes PPP. En la figura 3.5 se ve a un LAP actuando
como intermediario entre un dispositivo Bluetooth y un servidor residente en una LAN.
3.2.1.1. Conexión a un LAP

Los pasos para conectarse al punto de acceso de una LAN (LAP) son los siguientes:
1. El terminal de datos que quiere encontrar un punto de acceso a una LAN realiza
inquiries para encontrar los LAP.
2. El DT tiene que elegir de entre una lista de LAP encontrados.

Figura 3.5: Conexión a un LAP usando el perfil LAN
3. Cuando el terminal elige un LAP, pasa al proceso de pagin, formándose sólo el

enlace si el DT hace un cambio de maestro a esclavo permitiendo al LAP ser el
maestro.
4. Una vez que el enlace está establecido, una conexión L2CAP es creada y el terminal
de datos guarda los servicios existentes con una utilidad llamada LAN_Access_Using
_PPP. Ésta proporciona los parámetros necesarios para conectarse al LAN Access
Point. El trabajo de intercambio de estos parámetros es responsabilidad del proto-
colo de control del enlace (LCP,Link Control Protocol). Las conexiones RFCOMM
y PPP son establecidas a través del enlace L2CAP.
5. Luego, el terminal de datos debe negociar una dirección IP con el LAP usando una
de las partes fundamentales de PPP, el protocolo de control de IP (IPCP, IP Control
Protocol).
6. Una vez obtenida la dirección IP, el terminal de datos puede acceder a la LAN. Todo
el tráfico PPP es modificado en un enlace de encriptación, pero la autenticación en
el nivel es opcional.
3.2.1.2. Enlaces PPP
PPP, aparte de ser el protocolo encargado de coger los paquetes IP desde/hacia al

capa PPP y situarlos/cogerlos de la LAN, también es usado para llevar los paquetes IP a
través de la capa de emulación de puerto serie RFCOMM de Bluetooth. PPP encapsula la
información a transmitir en paquetes RFCOMM.
En la figura 3.6 se muestra el formato de una trama PPP.
Para establecer un enlace PPP, anteriormente se ha establecido una conexión RF-
COMM. Luego, cada lado envía paquetes LCP para probar el enlace y la configuración
de diferentes parámetros de la capa de enlace de datos.
Figura 3.6: Formato de una trama PPP
Protocolo LCP
Antes de establecer un enlace PPP entra en juego el protocolo LCP, su trabajo etsá forma-
do por cuatro fases:
1. Intercambio de paquetes LCP del tipo Configure-request. Una vez aceptada la con-
figuración entre los dos extremos con paquetes del tipo Configure-Ack el enlace está
en “OPEN”.
2. En el segundo paso, se determina si este enlace tiene la calidad suficiente para arran-
car los protocolos de red.
3. Arrancan los protocolos de control de red (NCP,Network Control Protocol).
4. Se establecen, los protocolos de control de red, y LCP se encarga del mantenimiento

del enlace mediante transmisión de paquetes echo-request y echo-reply.
El perfil de acceso LAN es construido sobre el perfil de puerto serie (SPP). Para des-
cubrir los LAPs que se encuentran en el rango de cobertura de los terminales de datos
debe usarse el procedimiento General Inquiry del perfil GAP.
Después de una satisfactoria configuración por parte de LCP, se pasa al último paso,
el cual consiste en asignar direcciones IP a los dispositivos de la nueva conexión PPP, este
trabajo es para el protocolo IPCP (IP Control Protocol). Cuando se hayan establecido las
direcciones IP, los paquetes pueden ser enviados a través del enlace PPP.
En la imagen 3.7 se puede ver gráficamente el establecimiento de una conexión PPP.
Protocolo IPCP
Es el protocolo de control de IP. Éste empieza a operar después de que se hayan estable-
cido las conexiones PPP usando LCP y opcionalmente el usuario haya sido autenticado.
El terminal de datos requiere una dirección IP para operar en una LAN. Las imple-
mentaciones PPP permiten tres opciones:
IPCP es usado para especificar una pre-configurada dirección IP.
IPCP es usado para pedir una apropiada configuración IP desde un servidor PPP.
Las opciones de IPCP son usadas para pedir una configuración IP especificada. Esta
opción es muy usual si se quieren usar móviles IP.
Con esto último, se quiere decir que no se necesita algún tipo especial de servidor
DHCP. La conexión PPP tomará con cuidado la dirección IP asignada.
Figura 3.7: Establecimiento de una conexión PPP
Figura 3.8: Camino más usual para conseguir IP sobre PPP
3.2.2. Propuesta de cómo usar IP sobre PPP

Lo más natural para tener IP sobre PPP es la propuesta de la figura 3.8, donde el punto
de acceso incluye un servidor PPP y los paquetes IP los transporta sobre Ethernet.
Esta solución conlleva varios problemas. Primero, se necesitaría tener un servidor PPP
funcionando en cada Access Point. Además, hay problemas con el control de los nombres
y las claves. Algunos de estos problemas pueden ser resueltos usando túneles, de hecho,
es una técnica parecida a la que utiliza el protocolo de encapsulación BNEP. Hoy no se ve
esta solución, ya que la mayoría de los puntos de acceso que existen están basados en IP
sobre PPP y no en la solución de hacer túneles.
3.2.3. Mecanismo básico de roaming por la comunicación

Roaming es el proceso de moverse de una celda a otra sin perder la conexión. Cuando
un dispositivo Bluetooth es conectado a un punto de acceso y se mueve fuera del radio de

cobertura, al pasar un tiempo, la pila de Bluetooth declara el enlace terminado y cierra la
conexión LMP. Poco después, el dispositivo Bluetooth realiza un inquiry, si no encuentra
ningún punto de acceso el nodo continúa realizando inquiries, hasta que se cumpla un
timeout y se cierre la capa más alta, PPP.
Si el dispositivo Bluetooth encuentra un puntod de acceso, éste se conecta al dispo-
sitivo y pregunta por su registro de servicio (SDP). Si el Service Name de este punto de
acceso es el mismo que el que tenía el anterior, se conectará a él sin más. Pero, si el Servi-
ce Name es distinto, el dispositivo debe realizar nuevamente todo el proceso de conexión
para intentar conectarse a este nuevo punto de acceso.
Una vez conectados (Access Point y el dispositivo Bluetooth) el punto de acceso se
registrará y abrirá una conexión L2CAP con el dispositivo Bluetooth. Será necesario esta-
blecer una nueva conexión PPP y redireccionar el tráfico IP de esta nueva instancia PPP.
Moverse por una red Bluetooth, como cualquier otro tipo de red maestro/esclavo es
realizado por un único dispositivo actuando como maestro. Esta es la razón del porqué el
punto de acceso de una red debe ser siempre el maestro. El maestro mantiene una tabla
de direcciones IP para asociar cada dirección de la capa física con cada dispositivo con
capacidad IP. Esta asociación puede ser a una dirección IP, a una dirección lógica de la
capa de enlace o a una dirección física de la capa de enlace. Una implementación debe
usar una dirección de capa de enlace lógica tal como la identificación de conexión (CID)
proporcionada por L2CAP.
Para una asignación dinámica de dirección IP se tiene:
Dirección CID Dirección Bluetooth
Para una asignación permanente de una dirección IP, la dirección IP solo identificará
a un dispositivo:
Dirección IP CID
3.3. PAN en Bluetooth

En esta sección, se analiza el perfil PAN y cómo usar el protocolo de encapsulación
de redes Bluetooth (BNEP, Bluetooth Network Encapsulate Protocol) para proporcionar
capacidades de red a los dispositivos.
Las redes del tipo PAN están pensadas para cubrir distancias cortas y cerradas. Algu-
nas de las tecnologías que trabajan con este tipo de redes son Bluetooth, IEEE 802.15 y
HomeRF, todas ellas trabajan en la banda de frecuencias ISM de 2.4 GHz.
El Estándar IEEE 802.15 se enfoca básicamente en el desarrollo de estándares para
redes tipo PAN o redes inalámbricas de corta distancia. Al igual que Bluetooth el 802.15
permite que dispositivos inalámbricos portátiles como pórtatiles, PDAs o teléfonos mó-
viles puedan comunicarse e interoperar unos con los otros. Debido a que Bluetooth no
puede coexistir con una red inalámbrica IEEE 802.11x, de alguna manera la IEEE defi-
nió este estándar para permitir la interoperabilidad de las redes inalámbricas LAN con las
redes tipo PAN.
3.3. PAN EN BLUETOOTH 49
Figura 3.9: Group ad-hoc Network
Figura 3.10: NAP Bridge
HomeRF también es una especificación que permite la interconexión de dispositivos

inalámbricos en un área pequeña.
3.3.1. perfil PAN definido en la especificación Bluetooth

El perfil PAN usa el protocolo BNEP (Bluetooth Network Encapsulatión Protocol)
para emular redes Ethernet y para establecer varios tipos de configuración de redes.
Las especificaciones del perfil PAN enumeran tres modos en los cuales un dispositivo
Bluetooth puede funcionar:
1. Usuario PAN (PANU, PAN User): es el dispositivo Bluetooth que usa los servidores
NAP o GN. El PANU asume el rol de cliente de un NAP o de un GN.
2. Group ad-hoc Network(GN): es una colección de hosts móviles que crean una red
wireless ad-hoc sin el uso de una infraestructura o hardware de red. Una red per-
sonal ad-hoc es una simple piconet de Bluetooth, con conexiones entre dos o más
dispositivos Bluetooth.
3. Punto de acceso a una red (NAP, Network Access Point): es un dispositivo que tiene
uno o más dispositivos en un radio Bluetooth y actúa como proxy, router o bridge
entre la infraestructura de red existente (normalmente LAN) y clientes de una red
Bluetooth (PANUs en este caso).
Figura 3.11: Pila para el protocolo BNEP
Los distintos escenarios que se pueden crear definen tres posibles roles para un dispo-
sitivo:
Un dispositivo Bluetooth comunicándose con un NAP.
Un dispositivo Bluetooth comunicándose con otro dispositivo Bluetooth.
Un dispositivo Bluetooth comunicándose con un NAP y a la vez con otro dispositivo

Bluetooth.
3.3.2. Bluetooth Network Encapsulation Protocol

El protocolo de encapsulación de redes Bluetooth (BNEP) encapsula paquetes de
varios protocolos de red, los cuales son transportados directamente sobre el protocolo
L2CAP. BNEP es usado para trasportar paquetes de control y datos sobre Bluetooth y
proporcionar accesos a redes Bluetooth a los dispositivos. Además, BNEP facilita capaci-
dades parecidas a las que proporciona Ethernet. Como se ve en la figura 3.11, por encima
del protocolo BNEP está la capa IP y encima la capa de transporte TCP/UDP.
Con BNEP no son todo ventajas, a continuación se nombran algunas de las desventa-
jas de este protocolo:
Agrega una capa de encapsulación adicional entre la capa de encapsulación y la

encapsulación proporcionada por IP, tal que hay tres capas de encapsulación para la
solución de IP sobre Bluetooth: L2CAP, BNEP y IP.
Figura 3.12: Paquete de encapsulación
BNEP/L2CAP no se optimiza para la transmisión de IP.
Las cabeceras BNEP son borradas y reemplazadas según el tipo de enlace (USB,
I2C (Interfaz IC), bus CAN).
BNEP especifica una mínima unidad máxima de transmisión (MTU) para L2CAP
de 1691 bytes.
3.3.3. Paquetes de encapsulación

BNEP puede transportar paquetes Ethernet quedando encapsulados de la forma que
se ve en la figura 3.12. El protocolo BNEP borra y reemplaza la cabecera Ethernet con
la cabecera BNEP. Finalmente, la carga (payload) de Ethernet y la cabecera BNEP son
encapsuladas por L2CAP y enviadas a través de la conexión Bluetooth.
BNEP es usado para transportar sobre Bluetooth paquetes de datos y paquetes de con-
trol, de esta manera ofrece a los dispositivos capacidades de red similares a las ofrecidas
por Ethernet.
3.3.4. Funcionamiento de L2CAP en el entorno IP

Antes de empezar a explicar el funcionamiento de IP sobre BNEP, se deberá entender
el tratamiento de L2CAP en el entorno IP. L2CAP es un protocolo de encapsulación de
Bluetooth. L2CAP proporciona un campo para la identificación del canal (CID, Channel
Identifier), para la encapsulación dinámica de otros protocolos después del procedimiento
de descubrimiento llevado acabo por el servicio de descubrimiento de protocolo (SDP).
Usamos el campo CID para la encapsulación de IP:
Tamaño (16 bits) CID (16 bits) Payload (Carga)
La unidad máxima de transmisión (MTU,Maximum Transmition Unit) para un pa-

quete L2CAP es de 65535 bytes. En una red Bluetooth todos los paquetes L2CAP son
entregados en orden. Por lo tanto, la cabecera IP no necesita ser retransmitida para cada
fragmento IP que se envía sobre L2CAP. únicamente, el primer fragmento IP debe ser una
cabecera IP. El envió de un paquete IP por L2CAP debe fijar el Logical Channel Code
(L_CH Code) en la cabecera del protocolo administrador del enlace (LMP) a 0x01 para
indicar la continuación del último fragmento IP de un paquete IP más grande que el ta-
maño MTU de L2CAP de 65535 (cabecera IP + payload). No es necesario fijar el L_CH
Figura 3.13: Escenario modo infraestructura
Code a 0x01 para indicar el comienzo del siguiente paquete IP, ya que para conocer el
final de un paquete IP en el nivel L2CAP se puede deducir del tamaño del campo de la
cabecera IP.
3.3.5. IP sobre BNEP

BNEP encapsula paquetes IP de la red en la que trabaja. Con BNEP todos los dispo-
sitivos Bluetooth deberían comportarse como iguales con las redes externas.
En este apartado se estudiara IP sobre BNEP en tres escenarios:
Modo infraestructura[ 3.3.5.1]

Modo ad-hoc[ 3.3.5.2]
PANU-PANU[ 3.3.5.3]
3.3.5.1. BNEP en modo infraestructura

Un punto de acceso a una red (NAP, Network Access Point) corresponde a una unidad
que contiene uno o más dispositivos Bluetooth y actúa como puente, proxy o enrutador,
entre una red Bluetooth y otro tipo de tecnología de red (Ethernet, GSM, ISDN, Home
PNA, Cable Módem y Celular). La figura 3.13 ilustra la arquitectura para dos puntos de
acceso de red.
En un escenario tipo infraestructura, el usuario de la PAN (PANU) se conecta a un
NAP proporcionándole servicios de red al dispositivo Bluetooth conectado. El punto de
acceso de la red borrara las cabeceras BNEP y establece las cabeceras correctas.
Para la fase 1 del perfil PAN, el dispositivo que soporta el servicio NAP (para la figura
3.13 el móvil) debe cumplir con las características de un puente Ethernet para soportar
los servicios de red. El dispositivo NAP distribuye los paquetes Ethernet entre los dis-
positivos Bluetooth conectados o usuarios PAN. Los NAP pueden requerir características
adicionales en los casos en que el puente sea hacia otro tipo de redes, por ejemplo GPRS.
La figura 3.10 muestra la interacción de las capas de protocolo del modelo Bluetooth para
el rol NAP.
Figura 3.14: Escenario modo ad-hoc
En todos los escenarios los dispositivos deben estar en el radio de cobertura del NAP,
el cual tendrá tráfico entre el usuario de la PAN y el respectivo servidor de red. El NAP y
el PANU deben mantener abierta la conexión L2CAP.
3.3.5.2. BNEP en modo ad-hoc

La versión 1.0 del Perfil PAN especifica el escenario para una red personal ad-hoc
la cual está formada por una única piconet con conexiones entre dos o más dispositivos
Bluetooth. Un maestro y un máximo de siete esclavos conforman la red. El límite de siete
esclavos se debe al esquema activo de direccionamiento de Bluetooth. La figura 3.14 es
un escenario de una red ad-hoc.
Una red ad-hoc se crea para que un conjunto de dispositivos conforme una red tem-
poral e intercambien información. El dispositivo con el rol de maestro es el GN (Group
Ad-hoc Network) y es quien soporta el servicio GN. La figura 3.9 ilustra a nivel de las
capas de protocolo un enlace entre un GN y un PANU.
3.3.5.3. Conexión de dos PANU

Este escenario crea una conexión punto a punto entre dos usuarios de PAN (PANUs),
permitiéndose una comunicación directa entre ellos. El PANU es el dispositivo Bluetooth
que usa los servicios NAP o GN, pero en este ejemplo de conexión no existe ningún GN
ni ningún NAP, ya que el escenario está creado únicamente por dos PANU.
Capítulo 4
Desarrollo del proyecto
Este capitulo corresponde a la parte de desarrollo del proyecto, donde se explican, de

forma detallada, todas las pruebas realizadas. Lo primero que se realizó fue la elección y
todo lo relacionado con la correcta instalación de una pila Bluetooth para Linux. Después
de esto, se explica la forma de configurar los dispositivos Bluetooth que se conectan por
USB a los ordenadores. El siguiente paso fue la configuración de los ordenadores para
la asignación de direcciones IP a los dispositivos, esta parte está explicada por los dos
métodos utilizados (IP sobre BNEP y IP sobre PPP sobre RFCOMM). Una vez llegado a
este punto se realizaron pruebas con los dispositivos para comprobar la correcta conexión
de estos. Por último, se explican todos los pasos necesarios para dar una dirección IP a un
SonyEricsson P800 conectado por Bluetooth a un dispositivo de un ordenador.
4.1. Bluetooth y Linux

Dependiendo del sistema operativo a utilizar (Windows, Linux, Unix,...) existen varias
pilas Bluetooth. Ya que no se disponen de ordenadores Mac y que con el sistema operativo
Windows no hay posibilidad de realizar los objetivos del proyecto se determinó utilizar
Linux para la realización de las pruebas.
4.1.1. Historia de Bluetooth y Linux

Febrero. 1998 Formación del Bluetooth SIG
20-05-1998 Nacimiento de Bluetooth para Linux
Abril 1999 Nacimiento de OpenBT
26-06-1999 Especificación Bluetooth 1.0a
01-12-1999 Especificación Bluetooth 1.0b
25-07-2000 Nacimiento de BlueDrekar
01-12-2000 Especification Bluetooth 1.1
55
56 CAPÍTULO 4. DESARROLLO DEL PROYECTO
03-05-2001 Nacimiento de BlueZ
03-07-2001 BlueZ 1.0 se incorpora a Linux 2.4.6
23-11-2001 Nacimiento de Affix
13-06-2003 Bluetooth está totalmente integrado dentro de Linux 2.4.21
25-08-2003 Linux 2.4.22 con soporte para el perfil ISDN sobre Bluetooth
Noviembre 2003 Linux 2.4.23 con la pila para Bluetooth lista
Diciembre 2003 Incorporación estable de los aparatos inalámbricos de la raíz de

Bluetooth para el kernel 2.6.0
Kernels oficiales publicados
Linux 2.4.18: Este viejo núcleo contenía los drivers para USB y UART.
Linux 2.4.19: Sistema actualizado con un plus de los drivers de las tarjetas Nokia.
Linux 2.4.20: Soporta BNEP y añade los drivers para Anycom y tarjetas 3Com.
Linux 2.4.21: Soporta RFCOMM y se le añaden los drivers para BCSP.
Linux 2.4.22: Soporta CMTP e incluye los drivers para BlueFRITZ!.
4.1.2. Software Bluetooth con licencia pública (GPL)

En esta sección se tratan las principales características de los tipos de productos
de libre distribución con licencia GPL desarrollados para Linux y disponibles en Inter-
net. Los principales son: OpenBT [OpenBT, WWW], BlueDrekar [BlueDrekar], Bluez
[BlueZ, WWW] y Affix [Axis, WWW].
4.1.3. OpenBT
Axis Communications Inc. [Axis, WWW] desarrolló, en primera instancia, un driver
Bluetooth para Linux llamado OpenBT, el cual puede ser usado tanto en ambientes eLinux
(Linux empotrado) como en Linux tradicional. Éste fue el primer stack de protocolos
disponible, siendo ahora un proyecto de código fuente abierto, desarrollado en un kernel
de Linux 2.0.33, de tal manera que no debe presentar problemas de funcionamiento en
versiones posteriores del kernel. Implementa el perfil de LAN mediante enlaces PPP sobre
RFCOMM y además una forma simple del perfil de descubrimiento de servicios (SDPP).
El código fuente en sus versiones para ordenadores y eLinux, se encuentra disponible
en el portal de Internet de Sourceforge [Sourceforge, WWW].
4.1. BLUETOOTH Y LINUX 57
4.1.4. BlueDrekar
El driver Bluetooth de IBM, disponible bajo licencia GPL, implementa la capa de
transporte UART de la interfaz controladora del host (HCI). Este código sirve de referen-
cia para escribir drivers para otras capas de transporte HCI, como USB. El BlueDrekar es
una implementación de referencia de las capas altas del protocolo Bluetooth, disponible
bajo licencia Alpha Works [Alpha Works, WWW].
Según el fabricante, este código ha sido desarrollado y probado en ordenadores con
procesadores de arquitectura i486 ó sUperior, usando un kernel de Linux 2.2.12-20 (Red
Hat 6.1), 2.2.14-5.0 (Red Hat 6.2), 2.2.16-22 (Red Hat 7).
4.1.5. Affix
Esta pila de protocolos para Linux fue desarrollada por el centro de investigación de
Nokia en Helsinki, Finlandia. El software Bluetooth de Affix trabaja sobre plataformas
Intel, ARM (iPaq, ARM9 y otras) y PowerPC (iMac). Las últimas versiones del software
están disponibles en el sitio Web de Affix.
4.1.6. BlueZ
BlueZ fue desarrollada por Qualcomm [Qualcomm, WWW] y actualmente está dis-
ponible para uso público bajo licencia GPL. BlueZ es de código abierto y puede descar-
garse de su sitio Web http://bluez.sourceforge.net. BlueZ es más manejable a la hora de
desarrollar aplicaciones en ella, simplemente, con un dispositivo Bluetooth y un núcleo
configurado adecuadamente, se puede trabajar con cualquier rama o protocolo de Blue-
tooth.
BlueZ ofrece las siguientes funcionalidades:
Arquitectura flexible, eficiente y modular.
Soporte para múltiples dispositivos Bluetooth.
Proceso multi-tarea de datos.
Abstracción del hardware.
Interfaz de sockets estándar para todas las capas.
Soporte de seguridad a nivel PSM.
Multiplataforma: x86 (simple y multiprocesador), SUN SPARC, ARM, PowerPC,

Motorolla, DragonBall.
Funcionamiento en todas las distribuciones Linux: Debian, RedHat, SuSe, etc.
Gran cantidad de dispositivos soportados (PCMCIA, UART, USB).
Soporte L2CAP, SDP, RFCOMM y SCO.

Figura 4.1: Diagrama de BlueZ
Disponibilidad de un emulador Bluetooth (VHCI) y dispositivos de configuración y

prueba.
Soporte para los siguientes perfiles de uso: GAP, DUN, LAN, SPP, PAN, Head-set,
OBEX (FTP), OBEX (OPP).
Listas de correos participativas (lists.sourceforge.net), con desarrolladores en todo

el mundo contribuyendo al soporte y programación con BlueZ.
Existe el inconveniente de que hay que tener un nivel medio del mundo Linux para
poder entender y trabajar con Bluetooth. El segundo problema es la constante evolución
de BlueZ, ya que puede obligar a estar actualizando los paquetes de Bluetooth si se quiere
tener siempre la configuración al día.
En la figura 4.1 se muestra un diagrama de BlueZ.
4.2. Instalación de BlueZ

Antes de nada, hay que decir que para realizar todas las pruebas del proyecto se ha
utilizado la distribución Debian 3.0 de Linux. Por tanto, la ubicación de algún fichero
quizás no corresponda con la indicada si se utiliza otra distribución de Linux que no sea
Debian.
4.2. INSTALACIÓN DE BLUEZ 59
4.2.1. Compilación del núcleo de Linux

El conjunto de paquetes de BlueZ está evolucionando constantemente y para poder
utilizarlo no valdrá cualquier núcleo instalado en los ordenadores. En el proyecto se ha
trabajado con el kernel 2.4.23, aunque antes también se utilizó sin problemas el núcleo
2.4.18. BlueZ es soportado desde núcleos 2.4.4 y sUperiores, incluyendo BlueZ a partir
del 2.4.18. Para saber que versión se tiene en el ordenadore basta con ejecutar uname -r
para saberlo. Ahora, todas las nuevas versiones de Linux tienen incorporado BlueZ.
A continuación se indican los pasos necesarios para instalar el núcleo utilizado en las
pruebas del proyecto. En primer lugar, se debe descargar, recomendablemente de la página
oficial de Linux (http://www.kernel.org), el paquete comprimido del núcleo a instalar en
los ordenadores.
El siguiente paso es descomprimir el paquete descargado en el directorio /usr/src, para
ello se debe ser root. Se descomprime de la siguiente forma:
tar xvfj linux-2.4.18.tar.gz
Para seleccionar las opciones que se desee que tenga el nuevo núcleo, hay que ejecutar
uno de los tres posibles menús:
make config
make menuconfig
make xconfig
Nota: Hay que estar en entorno gráfico para la opción xconfig.

Para la realización del proyecto tiene que estar habilitado el USB, para poder conectar
los módems Bluetooth a través de dicha interfaz. Además, se necesitan tener activadas,
para poder usar el protocolo PPP en Linux, las opciones siguientes:
Networt device sUpport ->

(*) Networt device sUpport
...
() PPP (Point-to-Point protocol) sUpport
...
() PPP sUpport for async serial ports
() PPP sUpport for sync tty ports
Dependiendo de las preferencias de cada uno, se deben compilar las opciones anterio-
res como módulos (poniendo “M”) o como parte del núcleo (“*”).
En [Ref8, WWW] se proporciona un enlace donde se ubica un howto que muestra una
pequeña descripción de cada una de las opciones del núcleo 2.4.22, aunque se podría decir
que son generales para los núcleos 2.4.X.
Una vez seleccionadas todas las opciones necesarias para la ejecución de las pruebas,
se pasa a la compilación del nuevo núcleo y su puesta en marcha. Se puede acceder al enla-
ce anterior, donde, además de explicar las opciones del núcleo, habla de como recompilar
un núcleo nuevo.
4.2.2. Descarga, compilación e instalación de los paquetes BlueZ

Para poder utilizar BlueZ hay que descargar las fuentes, éstas pueden ser bajadas de
(http://bluez.sourceforge.net). BlueZ se divide en tres partes principales y fundamentales,
con ellas se podrá trabajar y desarrollar aplicaciones. Se muestran los nombres de las
últimas versiones disponibles a fecha de la realización de este proyecto:
bluez-libs-2.4.tar.gz
bluez-sdp-1.2.tar.gz
bluez-utils-2.3.tar.gz
Bluez-libs tiene las bibliotecas para desarrollar aplicaciones para BlueZ. Bluez-utils
almacena las utilidades básicas y auxiliares, como los comandos hciconfig y hcitool, entre
otros que se nombrarán más en adelante.
Una vez descargados los paquetes lo siguiente fue descomprimirlos de la siguiente
forma y sin alterar el orden:
tar zxvf bluez-libs-2.4.tar.gz

tar zxvf bluez-sdp-1.2.tar.gz
tar zxvf bluez-utils-2.3.tar.gz
Las fuentes deben instalarse en el mismo orden que se han descomprimido. Para ins-
talar los paquetes habrá que ejecutar las siguientes órdenes, también en el orden indicado,
en el directorio creado al descomprimir los paquetes (recomendable usar el directorio
/usr/src para descomprimir los paquetes):
./configure
make
make install
Si se dispone de un núcleo inferior al 2.4.18 se necesitará inicialmente instalar el

paquete BlueZ-Kernel, el cual contiene las fuentes de BlueZ. La forma de instalar el pa-
quete será la misma que para instalar los paquetes anteriores. Cuando se intente ejecutar
\.configure se puede encontrar un error si en /usr/src no se encuentra un directorio o
enlace, con el nombre linux, con las fuentes del núcleo.
Una vez llegado a este punto, lo siguiente a realizar es añadir los alias 1 necesarios a
nuestro fichero de configuración /etc/modules.conf para que BlueZ funcione correctamen-
te. A continuación las líneas necesarias a incluir:
alias net-pf-31 bluez

alias bt-proto-0 l2cap
alias bt-proto-2 sco
alias tty-ldisc-15 hci_uart
1
Los alias sirven para no tenter que recordad nombres de sintaxis difícil como, por ejemplo, net-pf-31
y en remplazao usar bluez. Además estos alias son necesarios para poder cargar los módulos. Al ejecutar
Update-modules se actualiza el fichero /etc/modules.conf, por lo que hay que ejecutar ese comando cada
vez que se introduzca un nuevo alias en el fichero.
4.3. CONFIGURACIÓN 61
También es posible desarrollar aplicaciones sin tener un hardware Bluetooth. Sim-

plemente hay que tener el módulo hci_vhci cargado, para ello se tendrá que añadir la
siguiente línea en el fichero de los alias:
alias char-major-10-250 hci_vhci
El siguiente paso es cargar los módulos para poder utilizarlos. Estos pueden cargarse
automáticamente o manualmente. Para cargar módulos manualmente es con el comando
modprobe y el nombre del módulo a cargar. Y para cargar los módulos automáticamente
hay que incluir el nombre de cada módulo en el fichero /etc/modules:
bluez
l2cap
sco
hci_uart
hci_vhci
4.3. Configuración
La sección anterior 4.2 es la explicación de la instalación de BlueZ en los ordenadores,
en esta sección se explica de que ficheros se disponen para que al activar los dispositivos
Bluetooth se inicialicen con la configuración descrita en dichos ficheros. En esta sección
también se inidica como se inicia un dispositivo Bluetooth conectado a la interfaz USB
del ordenador.
4.3.1. Autoiniciación de dispositivos

Existe el demonio hcid que se encarga de gestionar dispositivos Bluetooth establecien-
do los sus parámetros iniciales al activarlos en un ordenador. Estos parámetros se estable-
cen en el fichero /etc/bluetooth/hcid.conf. En este fichero se pueden configurar muchas
de las opciones de los dispositivos, tales como: autenticación, solicitud de un pin para
establecer conexiones seguras o el rol de maestro o esclavo. A continuación, se mues-
tra el fichero hcid.conf explicando cada una de las opciones y dejando seleccionadas las
utilizadas en la realización de las pruebas.
# Fichero de configuraci\’on del demonio HCI.
#
# $Id: hcid.conf,v 1.3 2003/07/18 18:12:46 maxk Exp $
#
# Opciones HCId
options {
# Inicialización automática de los nuevos dispositivos
autoinit yes;
# Modo de seguridad del Manager para el dispositivo

# none - Deshabilitado security manager
# auto - Uso local del PIN para crear conexiones
# user - Preguntar siempre al usuario un PIN
#
security auto;
# Modo de apareamiento con otro dispositivo Bluetooth

# none - Apareamiento deshabilitado

# multi - Permitir apareamiento con pares de dispositivos
# once - Apareamiento una vez y denegar intentos sucesivos
pairing multi;
# Ubicación del programa que solicita y comprueba el pin
pin_helper /bin/bluepin;
}
# Configuración de los dispositivos HCI

device {
# Nombre del o de los dispositivo/s local/es
# %d - id del dispositivo
# %h - Nombre del host
name "BlueZ (%d)";
# Clase del o de los dispositivo/s local/es
class 0x100;
# Tipo de paquete por defecto

#pkt_type DH1,DM1,HV1;
# Si no se especifica tipo de paquete se toma DM1 por defecto.
# Para habilitar o deshabilitar Inquiry y Page scan
iscan enable;
pscan enable;
# Modo del enlace por defecto

# none - Política sin especificar
# accept - Siempre acepta conexiones entrantes
# master - Empieza siendo maestro las conexiones y deniega
# el cambio de rol
#
lm accept;
# Política de enlace por defecto

# none - política no especificada
# rswitch - permite cambio de role
# hold - permite modo hold
# sniff - permite modo sniff
# park - permite modo park
#
lp rxwitch;
# Autenticacion y Encriptación
#auth enable;
#encrypt enable;
}
4.3.2. Seguridad en las comunicaciones

Existe el fichero /etc/bluetooth/pin en el que se puede definir una contraseña de paso
para establecer una conexión segura con los dispositivos Bluetooth deseados. En el fichero
/etc/bluetooth/hcid.conf se puede configurar la petición o no de esta clave de paso o tener
una predefinido.
En el punto 4.6 de este proyecto se explicará el establecimiento de una conexión
Bluetooth con un Sony Ericsson P800, en la cual hay que introducir una contraseña para
crear dicha conexión.
4.3.3. Inicialización de los dispositivos

En el proyecto se configuraron conexiones entre dispositivos Bluetooth conectados al
puerto USB. Para que estos dispositvivos fuesen detectados por el ordenador, en primer
lugar, tiene que estar instalado el USB en el sistema, para ello se habilitó el soporte del
USB en la reconfiguración del núcleo. El siguiente paso fue cargar el módulo que se
encarga de HCI a través de USB. Si se quiere que éste se cargue automáticamente habrá
que incluir la siguiente línea al fichero /etc/modules:
hci_usb
Para cargar el módulo manualmente bastará con ejecutar:

modprobe hci_usb
Una vez que está todo correctamente instalado y configurado, los dispositivos se ini-
cializan cuando se conectan al USB. También se puede iniciar un dispositivo manualmente
con ejecutar:
hciconfig hciX Up
Nota: Donde ’X’ es el número identificativo del dispositivo a utilizar. Si, por ejemplo,
se tuviesen dos módems conectados en un mismo ordenador, uno sería el hci0 y otro el
hci1.
El parámetro Up es necesario siempre que el dispositivo no haya sido inicializado, es
decir, cuando al ejecutar hciconfig se muestre lo que se ve a continuación 2 :
hci0: Type USB
BD Address:00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
Una vez configurado correctamente todo lo relacionado con la inicialización del/os

dispositivo/s, al ejecutar hciconfig -a se debe mostrar por pantalla algo parecido a lo si-
guiente:
hci0: Type: USB
BD Address: 00:30:C2:28:09:2D ACL MTU: 128:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:63 acl:0 sco:0 events:7 errors:0
TX bytes:27 acl:0 sco:0 commands:7 errors:0
Features: 0xff 0xff 0x05 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE, ACCEPT
Name:’Anycom USB’
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Ver: 1.1 (0x1) HCI Rev: 0x72 LMP Ver: 1.1 (0x1) LMP Subver: 0x72
Manufacturer: Cambridge Silicon Radio (10)
2
Se recomienda que antes de trabajar con el dispositivo Bluetooth se ejecute hciconfig para ver si está
inicializado.
4.3.4. Herramientas básicas disponibles

Hay varios comandos o herramientas disponibles para trabajar con BlueZ, además,
debido a su constante evolución nacen nuevas y expiran otras viejas. A continuación se
nombran únicamente aquellas que se utilizaron. En las herramientas a utilizar es obliga-
tiorio rellenar todo lo que valla entre ’<>’ y optativo lo que vaya entre corchetes ’[ ]’.
4.3.4.1. hciconfig
Con esta herramienta se pude adaptar algunos de los parámetros de la configuración
de los dispositivos Bluetooth conectados. hciconfig permite establecer las configuraciones
apropiadas para cada aplicación.
hciconfig es una herramienta que puede varíar (sus opciones) dependiendo de la ver-
sión, debido al constante desarrollo de BlueZ. Por ello es recomendable ejecutar hciconfig
-h y notar las opciones disponibles, a continuación se muestra la ejecución de este coman-
do.
Uso:
hciconfig
hciconfig [-a] hciX [comandos]
-a Amplia la información mostrada del dispositivo
Comandos:
Up Abre e inicializa un dispositivo HCI
down Cierra un dispositivo HCI
reset Resetea un dispositivo HCI
rstat Reinicializa los contadores estadísticos
auth Habilita autenticación
noauth Deshabilita autenticacióon
encrypt Habilita encriptación
noencrypt Deshabilita encriptación
piscan Modo page scan e inquiry scan
noscan Deshabilita scan
iscan Habilita inquiry scan
pscan Habilita page scan
ptype [type] Comprueba/establece el tipo de paquetes por defecto
lm [mode] Comprueba/establece el modo link por defecto
lp [policy] Comprueba/establece la política de enlace
name [name] Comprueba/establece el nombre local
class [class] Comprueba/establece la clase del dispositivo
voice [voice] Comprueba/establece los parámetros de voz
inqparms [win:int] Comprueba/establece el tamaño de la ventana e intervalo de los inquiry scan
pageparms [win:int] Comprueba/establece el tamaño de la ventana e intervalo de los page scan
pageto [to] Comprueba/establece el timeout de los page
aclmtu <mtu:pkt>Establece el ACL MTU y número de paquetes
scomtu <mtu:pkt>Establece el SCO MTU y número de paquetes
features Muestra las características del dispositivo
version Muestra información de la versión
revision Muestra información de la revisión
4.3.4.2. hcitool
Es otra de las herramientas principales del paquete BlueZ. Ofrece servicios básicos
como, por ejemplo, realizar un inquiry, una conexión base banda, obtener información
sobre un dispositivo remoto entre otras funciones. En las siguientes líneas se muestra la
ayuda referente a este comando:
Uso:
hcitool [opciones] <comandos> [par\’ametros_de_los_comandos]
Opciones:
--help Muestra ayuda
-i dev Dispositivo HCI
Comandos:
dev Muestra los dispositivos locales
inq Inquiry a dispositivos remotos
scan Scan a dispositivos remotos
name Obtiene el nombre de un dispositivo remoto
info Obtiene información de un dispositivo remoto
cmd Someter comando HCI arbitrarios
con Mostrar conexiones activas
cc Crear conexión con dispositivo remoto
dc Desconectar de un dispositivo remoto
sr Cambiar el rol master/slave
cpt Cambiar el tipo de paquete en la conexión
rssi Muestra conexión RSSI
lq Muestra calidad del enlace
lst Muestra tiempo límite de la sUpervisión de un enlace
Para más información en el uso de un comando en especial:

hcitool <comando> --help
4.3.4.3. l2ping
Permite comprobar si un enlace está establecido, de modo análogo al comando están-
dar ping, el cual también puede utilizarse para comprobar una conexión Bluetooth siempre
que los dispositivos tengan direcciones IP asignadas. Esto será posible si se utiliza PPP
sobre RFCOMM o BNEP.
l2ping [-S dir orixe] [-s tamaño] [-c cantidades] [-f] <bd_addr destino>
4.3.4.4. hcidump
Esta utilidad permite observar los mensajes de bajo nivel intercambiados en un enlace
Bluetooth. hcidump visualiza en pantalla todos los paquetes recibidos y enviados por un
dispositivo específico. En especial, es útil cuando se quiere analizar el funcionamiento de
un dispositivo o depurar a bajo nivel posibles problemas de protocolos de comunicación.
A continuación, se acompaña la ayuda disponible de esta herramienta.
Uso:
hcidump [Opciones] [filtro]
Opciones:
-i, --device=hci_dev Dispositivo HCI
-p, --psm=psm Por defecto PSM
-s, --snap-len=len Snap len (en bytes)
-r, --read-dump=file Leer dump de un fichero
-w, --save-dump=file Salvar dump en un fichero
-a, --ascii Datos dump en ascii
-x, --hex Datos dump en hexadecimal
-R, --raw Modo raw
-t, --ts Muestra las marcas de tiempo
-?, --help Muestra esta lista de ayuda
--usage Muestra un mensaje corto del uso
Figura 4.2: Captura con la salida de hcitool inq y hcitool scan
4.3.4.5. Conexión a nivel de banda base entre dos dispositivos Bluetooth

Previamente a crear la conexión Bluetooth, se necesita la dirección BD_ADDR (di-
rección BD_ADDR de un dispositivo, ver 2.8.1.2) del dispositivo con el que se quiere
establecer conexión. Tanto con ejecutar hcitool scan como con hcitool inq se puede con-
seguir esta dirección. Las siguiente captura (figura 4.2) muestra las dos formas posibles
de conseguir la dirección BD_ADDR de los dispositivos Bluetooth remotos detectados
dentro del radio de cobertura del dispositivo que realiza la búsqueda.
Posteriormente, se realiza la prueba de conexión a nivel de banda base, para la cual
también se utliliza la herramienta hcitool con la opción cc más la dirección del dispositivo
remoto al que se quiere conectar:
hcitool cc <addr_otro_dispositivo>
En la figura 4.3 se ve, en el lado del maestro, un ejemplo de una captura de una cone-
xión, a nivel de banda base, por parte del dispositivo que realiza la petición de conexión,
y en la figura 4.4 se muestra la salida del comando hcitool con en el lado del esclavo.
4.4. Perfil de red de área Personal (PAN PROFILE)

El perfil PAN (Personal Area Networking Profile) describe como usar el protocolo
BNEP para brindar capacidades de red a los dispositivos Bluetooth. El perfil PAN presenta
los siguientes requerimientos funcionales:
Define una red IP ad-hoc, dinámica y personal.
Debe ser independiente del sistema operativo, lenguaje y dispositivo.
Da soporte para los protocolos de red más comunes como IPv4 e IPv6.
Da soporte para puntos de acceso en donde la red puede ser una LAN corporativa,
GSM u otro tipo de red de datos.
Debe acomodarse a los recursos reducidos disponibles en los dispositivos pequeños

respecto a memoria, capacidad de procesamiento y uso de interfaces.
4.4. PERFIL DE RED DE ÁREA PERSONAL (PAN PROFILE) 67
Figura 4.3: Captura de una conexión por el lado del dispositivo maestro
4.4.1. Instalación del módulo BNEP

Para disponer del protocolo BNEP debe instalarse el paquete Bluez-PAN, para ello
hay que seguir los siguientes pasos:
1. Descargar de la página oficial de BlueZ, http://bluez.sourceforge.net, la última ver-
sión del paquete BlueZ-pan, en la realización del proyecto era bluez-pan-1.1rc2.tar.gz.
2. Situarse en el directorio /usr/src.
3. Descomprimir el paquete descargado con:
tar zxvf bluez-pan-1.1rc2.tar.gz
4. Acceder al directorio creado e instalar el paquete en la computadora:

cd bluez-pan-1.1rc2
./configure
make
make install
Finalmente, una vez realizados los pasos anteriores hay que añadir la siguiente línea
al fichero /etc/modules.conf para que todo funcione correctamente:
alias bt-proto-4 bnep
Y para que el módulo BNEP se cargue automáticamente hay que incluir en/etc/modules
la palabra bnep. Para probar el protocolo BNEP sin reiniciar el ordenador, hay que cargar
manualmente el módulo:
modprobe bnep
Una vez que todo se ha realizado correctamente, antes de utilizar BNEP hay que estar
seguro que el demonio HCI (hcid) está corriendo y el dispositivo activado.
Figura 4.4: Captura de una conexión por el lado del dispositivo esclavo
4.4.2. Utilización del demonio PAN

Para poder realizar las pruebas con BNEP existe el demonio PAN (pand), para el cual
se muestra la ayuda facilitada por Linux.
Demonio PAN versi\’on 1.1pre4
Uso:
pand <opciones>
Opciones:
--show --list -l Muestra las conexiones PAN activas
--listen -s Modo escucha para conexiones PAN
--connect -c <bdaddr> Crea conexión PAN
--search -Q[duration] Busca y conecta
--kill -k <bdaddr> Mata conexión PAN
--killall -K Mata todas las conexiones PAN
--role -r <role> Rol para el dispositivo PAN local
--service -d <role> Rol para el dispositivo PAN remoto
--device -i <name> Nombre de la interfaz de red
--source -S <bdaddr> Dirección fuente
--nosdp -D Deshabilita SDP
--encrypt -E Habilita encriptación
--master -M Asume papel de maestro de la piconet
--nodetach -n No comportarse como un demonio
--persist -p[interval] Modo persistente
--cache -C[valid] Dirección caché
Para crear una conexión PAN hay que iniciar primero el demonio pand en un orde-
nador, éste adoptará el papel de maestro y servidor. Para iniciar el servidor PAN en el
ordenador hay que ejecutar lo siguiente:
pand --listen --role <PANU|GN|NAP>
Hay que elegir el rol del servidor (PANU, GN o NAP), dependiendo del tipo de cone-
xión que se quiera establecer, ver punto 3.3.5. Si se elige GN o NAP, el dispositivo será
reconocido como maestro. Siempre se puede elegir entre maestro o esclavo en el fichero
/etc/hcid.conf con la siguiente línea:
Figura 4.5: Escenario creado entre dos PANUs
lm accept, master
Además, se puede pasar un nodo a master de la siguiente manera:

pand --master
Una vez comprendio hasta esta parte, se está capacitado para establecer una conexión
con un dispositivo, ya sea entre PANUs, entre un PANU y un GN o entre un PANU y un
NAP. Para ello lo único que se necesitará es la dirección BD_ADDR del dispositivo con el
que se quiere establecer la conexión. En los siguientes apartados [ 4.4.2.1][ 4.4.2.2][ 4.4.2.3]
se pasa a crear los distintos tipos de conexiones PAN para los distintos escenarios.
4.4.2.1. Creación de una conexión entre dos PANUs

En un ordenador se ejecuta:
pand --listen --role PANU
y en el otro ordenador:
pand --connect <bd_addr_PANU_remoto> --role PANU
Las figuras 4.6 y 4.7 muestran las capturas de un servidor y un cliente, respectivamen-
te, en un enlace entre dos PANUs. Para ver los enlaces PAN que hay creados o activos
basta con ejecutar pand –show. Cuando se establece un enlace PAN entre dos dispositivos
Bluetooth, se crea la interfaz bnep0 en cada ordenador que componen la conexión. Para
ver la nueva interfaz creada habrá que activarla (ver 4.4.2.5).
4.4.2.2. Creación de un escenario modo ad-hoc

En la figura 4.8 se aprecia el tipo de conexión que se establece en un escenario en
modo ad-hoc.
Se necesita en primer lugar iniciar un GN, para ello:
pand --listen --role GN
Y luego, dependiendo del número de dispositivos que se le quieren conectar (hasta un

límite de 7), se crea la conexión de cada PANU al GN de la forma siguiente:
pand --connect <addr_GN>
En el ejemplo de este tipo de conexión, realizado en el laboratorio, se ve en la figura

4.9 con el GN, notar que en ésta captura se aprecia la conexión de dos PANU al GN. La
captura del PANU conectado al GN no se muestra ya que es exactamente la misma que
la captura mostrada en la figura 4.7. Como se ha indicado, en esta prueba realizada, se
conectan dos PANUs al GN, por ello, en el servidor o GN, cuando se ejecuta pand –show
se ven dos interfaces BNEP bnep0 y bnep1 creadas.
Figura 4.6: Servidor en un enlace entre dos PANUs
4.4.2.3. Creación de un escenario modo infraestructura

En la figura 4.10 muestra este tipo de escenario a crear.
Para crear una escena modo infraestructura inicialmente se tuvo que crear el punto
de acceso a la red (NAP), encargado de conectarse a una infraestructura LAN. La orden
necesaria para crear un NAP es:
pand --listen --role NAP
Después, dependiendo del número de dispositivos que se quieren conectar, se crea la

conexión de un PANU al NAP con la ejecución de la orden siguiente:
pand --connect <addr_GN>
La figura 4.11 recoge una captura con los pasos necesarios para crear un NAP. Nue-
vamente, no se muestra ninguna captura de la conexión del PANU, ya que sería idéntica a
la figura 4.7.
4.4.2.4. Funcionalidad de búsqueda

Existe el parámetro –search con el que se pueden buscar conexiones PAN cercanas, la
estructura de la orden es:
pand --role PANU --search [duraci\’on]
Éste realiza un inquiry a los dispositivos PAN encontrados. Una vez realizado intenta
conectarse a cualquier dispositivo Bluetooth descubierto, la búsqueda se realizará durante
el número de unidades (1 unidad = 1.28 segundos) de tiempo especificado en la opción
duración.
Figura 4.7: Cliente en un enlace entre dos PANUs
Figura 4.8: Escenario modo ad-hoc
4.4.2.5. Configuración de las interfaces

Durante el establecimiento de la conexión, una interfaz virtual de red bnep0 es creadoa
en ambos nodos. Esta interfaz puede ser configurada usando la herramienta ifconfig. A
continuación se muestra un ejemplo de como se puede configurar la interfaz virtual bnepX
La ’X’ especifica el número de la interfaz deseada a configurar., en un lado de la conexión,
más la dirección que se le desea asignar al dispositivo:
ifconfig bnep0 10.0.0.110
Esta configuración de la interfaz tiene que realizarse en todos los dispositivos que
fonmen parte de la conexión, asignando a cada una la dirección deseada. En las capturas
anteriores que mostraban las conexiones de los distintos escenarios PAN se puede apreciar
el procedimiento seguido para configurar los interfaces de los dispositivos Bluetooth.
Figura 4.9: Captura con el GN creado en un ordenador
No es necesario configurar las interfaces BENP manualmente. Hay un mecanismo

que se encarga de asignar las direcciones IP (direcciones estáticas o DHCP). Para esto, es
necesario editar un fichero llamado ifcfg-bnepX3 en /etc/sysconfig/network-script/.
Para direcciones estáticas, por ejemplo, ifcfg-bnep0 podría tener la siguiente forma:
DEVIVE=bnep0
BOOTPROTO=static
IPADDR=10.0.0.110
NETMASK=255.0.0.0
ONBOOT=no
Para DHCP el resultado sería el siguiente:

DEVIVE=bnep0
BOOTPROTO=DHCP
ONBOOT=no
Para obtener la ubicación de este directorio y ayuda en general, dependiendo del tipo
de distribución Linux que se esté usando, siempre se podrá conseguir un pequeño howto
ejecutando la siguiente órden:
man ifUp
4.5. Perfil de red de área local (LAN Profile)

Gracias al perfil de acceso LAN un dispositivo Bluetooth puede acceder a los servi-
cios de una LAN utilizando PPP sobre RFCOMM. De esta forma se pueden comunicar
dispositivos Bluetooth gracias al protocolo IP.
Para tener acceso a la LAN, se necesita tener un punto de acceso a la LAN (LAP), el
cual proporciona el acceso. El LAP es quien suministra servicios de un servidor PPP.
3
La ’X’ depender’a de la interfaz BENP creada
4.5. PERFIL DE RED DE ÁREA LOCAL (LAN PROFILE) 73
Figura 4.10: Escenario modo infraestructura
El perfil de acceso LAN expone como la capa IP de la pila Bluetooth debe usarse
para suministrar un enlace TCP/IP entre dos ordenadores o para ofrecer una red entre un
conjunto de computadores locales.
4.5.1. Configuración del sistema

Para poder utilizar el perfil LAN sobre Bluetooth se debe establecer un “camino”,
mostrado en la figura 4.12, y para ello hay que configurar todos los protocolos involucra-
dos en él.
Como ya se dijo 3.1.4, la conexión PPP es llevada sobre RFCOMM y éste es el encar-
gado de transportar los paquetes PPP. Por lo que primero se necesita un enlace RFCOMM
entre los dos dispositivos antes de establecer la conexión PPP.
4.5.1.1. Conexión RFCOMM

Para crear un enlace RFCOMM tiene que estar instalado el módulo RFCOMM (rf-
comm.o). Una vez instalados correctamente todos los paquetes indicados en la instalación
de BlueZ, lo único que falta es:
1. Incluir la siguiente línea para el alias al fichero /etc/modules.conf:
alias bt-proto-3 rfcomm
2. Cargar el módulo, ya sea automáticamente, incluyendo rfcomm en /etc/modules, o

manualmente ejecutando:
modprobe rfcomm
Figura 4.11: Captura que muestra la creación de un NAP
Antes de empezar a utilizar la herramienta rfcomm hay que crear los dispositivos rf-
commX4 en /dev, ya que sin ellos no se podrían crear conexiones RFCOMM ni por lo tanto
conexiones PPP. Para crear los /dev/rfcommX hay que situarse en /usr/src/bluez-kernel-2.3
y ejecutar ./create_dev. Si este fichero no existiese, por diferentes motivos (como no ne-
cesitar el paquete BlueZ-kernel), se pueden hacer dos cosas para crear los /dev/rfcommX:
Descargar el fichero ./create_dev de aquí[Ref9, WWW]. Guardar el fichero des-

cargado como create_dev y cambiar los permisos (chmod +x create_dev) antes de
ejecutarlo.
La segunda forma es escribir en la consola la siguiente línea:

mknod /dev/rfcommX c 216 $X
Hay que variar ’X’ de acuerdo al dispositivo que se quiera crear, por ejemplo:
mknod /dev/rfcomm0 c 216 $0
mknod /dev/rfcomm3 c 216 $3
Una vez llegado a este punto, solamente falta probar su correcto funcionamiento. Para
crear un enlace RFCOMM entre dos dispositivos Bluetooth hay que hacer uso de la he-
rramienta rfcomm, a continuación se muestra unas líneas que informan de como utilizar
esta herramienta:
4
La ’X’ es un valor que puede estar entre 0 y 255, incluidos los márgenes. Cada vez que aparezca
rfcommX en el proyecto la ’X’ será sustituida por un valor del intervalo mencionado, ya que si se deja sin
valor o éste está fuera del rango se produciá un error.
Figura 4.12: IP sobre Bluetooth de acuerdo con el perfil LAN
Uso:
rfcomm [opciones] <comandos> <dev>
Opciones:
-i [hciX|bdaddr] Dispositivo HCI local o Dirección BD
-h, --help Muestra la ayuda
-a Muestra todos los dispositivos (por defecto)
Comandos:
bind <dev> <bdaddr> [canal] Bind a dispositivo
release <dev> Elimina dispositivo
show <dev> Muestra dispositivo
connect <dev> <bdaddr> [canal] Conecta al dispositivo
listen <dev> [canal] Se pone a la espera (listen)
Para crear una conexión RFCOMM entre dos dispositivos basta con dejar en un lado
un dispositivo esperando o escuchando (listen) y conectarse a este dispositivo desde otro
punto con sólo conocer la dirección BD_ADDR des dispositivo remoto que está escu-
chando. Los comandos necesarios son:
Dispositivo 1:
rfcomm listen /dev/rfcommX
Nota: /dev/rfcommX es el dispositivo (<dev>). La ’X’ es el identificativo del canal, se

puede utilizar desde el 0 hasta el 255.
Dispositivo 2:
rfcomm connect /dev/rfcommX <bdaddr_disp1>
Figura 4.13: Enlace RFCOMM en el lado del servidor
En las figuras 4.13 (servidor) y 4.14 (cliente) siguientes se muestran las capturas de
un enlace RFCOMM:
Si se desea tener más de dos dispositivo enlazados, basta con ejecutar los comandos
utilizados por el dispositivo 1 y 2, variando /dev/rfcommX con uno que no sea el mismo
utilizado por el dispositivo conectado, sólo si se va a conectar otro módulo Bluetooth en
la misma computadora. Si por el contrario, se va a conectar un dispositivo desde otro
ordenador daría igual el valor de la ’X’ siempre que esté dentro del rango [0-255]. La
figura 4.15 enseña, con la simple ejecución de rfcomm, las conexiones RFCOMM que
tiene un ordenador con dos dispositivo conectados a él.
Existe el fichero /etc/bluetooth/rfcomm.conf en el que se pueden configurar conexiones
RFCOMM automáticamente al iniciarse una sesión en un ordenador. La estructura de este
fichero es la siguiente:
# Fichero de configuración RFCOMM.
#
# $Id: rfcomm.conf,v 1.1 2002/10/07 05:58:18 maxk Exp $
#
# ejemplo:
#
#rfcommX {
# # Dirección Bluetooth del sispostivo
# device 00:06:A2:02:58:AF;
# # Canal RFCOMM para la conexión
# channel 1;
# # Descripción de la conexión
# comment " Bluetooth dispositivo en PC-09";
#}
La ’X’ indica con el dispositivo (dev virtual) que se desea crear el enlace. Se puede
configurar más de una conexión RFCOMM en éste fichero, simplemente basta con relle-
nar, siempre en el fichero /etc/bluetooth/rfcomm.conf, esta plantilla y cambiar la dirección
Figura 4.14: Dispositivo que solicita conexión a un servidor
Figura 4.15: Captura con dos enlaces RFCOMM de un ordenador
BD_ADDR, el canal y el identificador del enlace (la ’X’). Ejemplo de posible fichero
rfcomm.conf utilizado:
rfcomm0 {
device 00:06:A2:02:58:AF;
channel 1;
comment " Bluetooth dispositivo 1 en PC-09";
}
rfcomm1 {
device 00:06:A2:02:8C:BD;
channel 2;
comment " Bluetooth dispositivo 2 en PC-09";
}
4.5.2. Conexión PPP

Una vez que se sabe como establecer conexiones RFCOMM, ya se puede configurar
una conexión PPP siempre sobre RFCOMM.
En primer lugar hay que estar seguro de que los módulos necesarios para poder traba-
jar con PPP (/itshape ppp_async y ppp_generic) están cargados. En la realización de las
Figura 4.16: Muestra de los módulos cargados en el ordenador
pruebas para el proyecto, los módulos ppp_async y ppp_generic fueron compilados como
módulos, por lo que antes de poder crear una conexión PPP se tienen que cargar estos
módulos. La figura 4.16 recoge una captura con los módulos cargados en los ordenadores
utilizados para las pruebas del proyecto.
Para crear una conexión con el protocolo BNEP se tiene el demonio PAN (pand) y
para establecer una conexión con el protocolo PPP se dispone del demonio DUN (dund).
Antes de explicar como se utilizó dund para crear conexiones PPP hay que explicar el
demonio PPP que es utilizado pordund. pppd es el demonio PPP y su ejecución significa el
lanzamiento de este demonio. La estructura y algunas opciones del demonio pppd pueden
verse aquí abajo:
Uso:
pppd [ options ]
Options:
<device> Comunicación sobre el dispositivo de nombre
<speed> Pone la velocidad (baudios) que se especifique
<loc>:<rem> Especifica dirección IP local y remota. Se puede omitir una de las dos.
asyncmap <n> Pone el async map a hexadecimal <n>
auth Requiere autenticación
connect <p> Invoca el comando <p>
crtscts Uso de control de flujo hardware RTS/CTS
defaultroute Añade ruta por defecto a la interfaz
file <f> Coge las opciones del fichero <f>
modem Uso del control de líneas módem
mru <n> Pone el valor MRU a <n> para negociación
Para ver una mayor explicación sobre cada opción y la totalidad de las opciones posi-
bles para PPP ejecute man pppd.
4.5.2.1. Demonio DUN (Dial-Up Network)

El demonio DUN (dund) facilita el establecimiento de la conexión PPP entre dos
dispositivos Bluetooth. A continuación se muestra la ayuda para el demonio DUN.
Demonio LAP (LAN Access over PPP) version 1.1

Uso:
dund <opciones> [opciones pppd]
Opciones:
--show --list -l Muestra conexiones DUN activas
--listen -s Estado de escucha para conexiones DUN
--connect -c <bdaddr> Crea conexión DUN
--search -Q[duraci\’on] Busca y se conecta
--kill -k <bdaddr> Mata conexión DUN
--killall -K Mata todas las conexiones DUN
--channel -C <canal> Canal RFCOMM
--source -S <bdaddr> Dirección fuente
--nosdp -D Deshabilita SDP
--nodetach -n No comportarse como un demonio
--persist -p[interval] Modo persistente
--pppd -d <pppd> Colocación del demonio PPP (pppd)
--msdun -X[timeo] Habilita el soporte de Microsoft dialUp networking
--cache -C[valid] Habilita la caché de direcciones
Para crear el enlace PPP con dund lo único que hay que realizar es lanzar un demonio
DUN en un lado de la conexión (servidor) y posteriormente conectar los clientes al servi-
dor. Esta forma es más sencilla que estableciendo primero un enlace RFCOMM y luego
lanzar manualmente el demonio pppd. El demonio DUN realiza automáticamente el enla-
ce RFCOMM y el lanzamiento del demonio pppd. Antes de lanzar las órdenes necesarias
para establecer la conexión, falta editar varios ficheros. Por lo tanto, el siguiente paso ha-
cia la comunicación PPP es editar el fichero /etc/ppp/options. En él deben aparecer las
opciones adecuadas al tipo de conexión PPP que se necesiten. El demonio DUN inicial-
mente lee las opciones de /etc/ppp/options, y después las del fichero /etc/ppp/peers/dun,
por lo que en el fichero options puede contener las opciones generales de PPP y el fichero
dun las utilizadas por dund.
A continuación se muestran y se explican las opciones elegidas e incluidas en el fiche-
ro /etc/ppp/options utilizado en las pruebas en uno de los ordenadores:
noauth --> No usar autenticación.
debug --> pppd guarda los contenidos de todos los paquetes de control
enviados o recibidos.
crtscts --> Usar control de flujo hardware.
lock --> Espedifica que pppd debería utilizar el bloqueo modo UUUP
del dispositivo serie para asegurarse un acceso exclusivo
al dispositivo.
local --> No usar las líneas de control del módem.
proxyarp --> Añade una entrada a la tabla del protocolo de resolución de

direcciones (ARP) de este sistema con la dirección IP de la
dirección Ethernet de su sistema.
passive --> pppd espera de forma pasiva un paquete LCP.
silent --> pppd no transmitirá paquetes LCP para iniciar una conexión
hasta que un paquete LCP válido sea recibido de la pareja.
10.0.0.110:10.0.0.109 --> dirección IP local:dirección IP remota.
El demonio DUN dispone de la posibilidad de leer el fichero de configuración que se le

especifique para el enlace PPP, lo único que hay que hacer es incluir call <fichero>cuando
se lance dund.
Para crear la conexión PPP es necesario tener un servidor escuchando. Para lanzar el
servidor hay que ejecutar lo siguiente:
dund --listen --channel X
Nota: La ’X’ es para seleccionar el canal. Si no se pone nada, por defecto toma el ca-
nal 1. El canal no es necesario especificarlo, ya que dund elige uno por defecto si no se le
especifica ninguno. Para las conexiones creadas entre los módem Bluetooth no importa el
canal seleccionado (para realizar la conexión entre el dispoistivo Bluetooth de un ordena-
dor y un teléfono móvil, dependiendo del tipo de esta conexión si es necesario seleccionar
el canal apropiado para dicha conexión).
Para comprobar que el demonio DUN está corriendo y ver los procesos que se ejecutan
y sus posibles fallos se disponen de varios ficheros, como por ejemplo /var/log/messages
y /var/log/system.
Después de arrancar el servidor se pasa a crear el enlace PPP. Para establecer la co-
nexión con el servidor se puede realizar de dos formas. La primera es “manualmente”
creando un enlace RFCOMM y posteriormente lanzando el demonio PPP. La segunda
manera de establecer el enlace PPP es lanzando otro demonio DUN para que se conecte
al servidor.
4.5.2.2. Establecimiento con dund

El mejor sistema para crear la conexión PPP es utilizando el demonio DUN. Éste crea
el enlace RFCOMM y posteriormente lanza el demonio pppd para realizar la conexión
PPP con el dispositivo remoto. Para crear la conexión con el servidor, el cual debe estar
esperando o escuchando, hay que lanzar dund en el cliente de la siguiente forma:
dund --connect <bd_addr_servidor>
La figura 4.17 muestra los pasos para lanzar el servidor PPP. Y en la figura 4.18 recoge
una captura de cómo se estableció, por parte del cliente, el enlace PPP sobre Bluetooth
entre los dos dispositivos con la “única” ayuda de la herramienta dund.
4.5.2.3. Establecimiento sin dund

Para establecer conexión con el servidor, en primer lugar hay que asegurarse que,
en el servidor, está corriendo el demonio DUN y esperando a que algún cliente quiera
conectarse a él, indicado en el apartado anterior (ver 4.5.2.2). Posteriormente se crea el
enlace RFCOMM, para ello hay dos formas:
1a Crea conexión RFCOMM con el dispositivo remoto, éste tiene que estar esperando
esta conexión (rfcomm listen /dev/rfcommX)
rfcomm connect /dev/rfcommX <bd_addr_server>
2a Más fácil que la primera, es crear un enlace con el dispositivo remoto, éste no tiene
que estar esperando este enlace:
4.6. CONEXIÓN BLUETOOTH DEL SONY ERICSSON P800 81
Figura 4.17: Captura con los pasos realizados para lanzar un servidor PPP
rfcomm bind /dev/rfcommX <bd_addr_server>
Una vez creado el enlace RFCOMM entre los dos dispositivos solamente falta lanzar
el demonio PPP, para ello:
pppd /dev/rfcommX
La siguiente captura, figura 4.19, se ve un ejemplo, en el lado del cliente, de la creación

de un enlace PPP sobre Bluetooth. El servidor es lanzado con el demonio DUN, de igual
forma que en el apartado anterior (ver 4.5.2.2), la figura 4.17 recoge una captura con el
lanzamiento de un servidor PPP con dund.
4.6. Conexión Bluetooth del Sony Ericsson P800

En esta última sección referente a la parte práctica del proyecto, corresponde con las
pruebas realizadas con un Sony Ericsson P800. Este dispositivo móvil dispone de cone-
xión Bluetooth, con ésta se conectó el P800 a uno de los dispositivos Bluetooth conectado
al ordenador por el USB.
4.6.1. Configuración previa en el ordenador

Para usar el software BlueZ con el P800 se necesitan tener los siguientes módulos
cargados:
blueZ
l2cap
sco
rfcomm
hci_usb
sdpd
hcid
ppp_async
Figura 4.18: Establecimiento, en el lado del cliente, de una conexión PPP utilizando dund
El último módulo, ppp_async, únicamente es necesario para las conexiones PPP. No

se necesita ningún paquete adicional de BlueZ, ya que fueron instalados todos los paque-
tes necesarios (BlueZ-libs, BlueZ-sdp, BlueZ-utils, BlueZ-pan) en la realización de las
pruebas de las conexiones PPP.
Antes de crear cualquier tipo de conexión con el P800, el móvil solicitaá una contrase-
ña o PIN. Este PIN puede establecese el que se desee editando el fichero /etc/bluetooth/pin.
4.6.2. Configuración del P800

Además de la configuración de los ordenadores, para crear una conexión entre el te-
léfono móvillos y el ordenador, hay que configurar el P800. Para activar Bluetooth en
el dispositivo móvil, hay que acceder a Conexiones en el Panel de control del menú
principal. Se selecciona Bluetooth y se configura el nombre deseado del P800 en la co-
nexión. También hay que poner Descubrible en el Modo de funcionamiento y Recibir
siempre en Recibiendo elementos.
4.6.3. Conexión RFCOMM con el P800

Para crear un enlace RFCOMM con el dispositivo móvil se seguirán los siguientes
pasos:
Se tendrá el dispositivo Bluetooth del ordenador correctamente funcionando en el
ordenador.
Conseguir la dirección BD_ADDR del P800 con hcitool scan.
Crear enlace RFCOMM de la siguiente forma:
rfcomm connect /dev/rfcommX <bd_addr_P800>
Figura 4.19: Captura con los pasos realizados por un cliente sin utilizar dund
4.6.4. Conexión del P800 a una LAN sobre Bluetooth

Para conectar el P800 a una red de área local se hará uso del protocolo mRouter.
mRouter está basado esencialmente en PPP. La LAN debe consistir de sólo el P800 y un
único computador, aunque este computador puede ser el punto de acceso a la LAN y el
P800 acceder a ella desde éste.
Para usar el P800 en una LAN, el móvil debe soportar el protocolo PPP. Cuando se
cree un canal PPP existirá un túnel entre el P800 y el ordenador, con una IP en cada
extremo del túnel.
Por ningún motivo en especial la conexion que se pretende crear entre el P800 y el
ordenador tendrá la estructura que se ve en la figura 4.21.
Hay varias complicaciones con el uso de PPP para conseguir el acceso a la LAN para
el P800. El P800 no acepta peticiones entrantes para iniciar una sesión PPP, ya que el
móvil esperará iniciar sesión el mismo, por lo que hay que lanzar un servidor (dund) en el
ordenador y dejarlo escuchando para que el P800 se conecte a él.
A continuación se numeran los pasos realizados para conseguir la conexión Bluetooth
del P800 al ordenador. Para entender mejor estos pasos se recomienda ver la figura 4.22
Figura 4.20: Pasos para la configuración Bluetooth del P800
Figura 4.21: Escenario creado por el P800 y el ordenador
con una captura que muestra los pasos que se realizaron para conseguir conectar el P800
al móvil.
1. Antes de que el P800 intente conectarse hace una petición SDP para encontrar el
número del canal del perfil SP (Serial Port) en el computador. Este canal solamente
será encontrado si ha sido añadio al ordenador con anterioridad usando el demonio
SDP. Para añadir este canal antes hay que saber cual es, para ello hay que ejecutar
sdptool browse <BD_ADDR_P800>, con la siguiente salida en nuestro caso:
Browsing 00:0A:D9:5D:67:B6 ...

Service Name: Voice gateway
Service Description: Voice gateway
Service Provider: Sony Ericsson
Service RecHandle: 0x10000
Service Class ID List:
"Headset Audio Gateway" (0x1112)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
Figura 4.22: Conexión PPP entre el P800 y el ordenador
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Headset" (0x1108)
Version: 0x0100
Service Name: Bluetooth Serial Port

Service Description: Bluetooth Serial Port
Service Provider: Symbian Ltd.
"Serial Port" (0x1101)
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Service Name: Dial-Up Networking

Service Description: Dial-Up Networking
Service Provider: Sony Ericsson
"DialUp Networking" (0x1103)
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 4
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
"DialUp Networking" (0x1103)
Version: 0x0100
Service Name: OBEX Object Push

"OBEX Object Push" (0x1105)
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 2
"OBEX" (0x0008)
"OBEX Object Push" (0x1105)
Version: 0x0100
Esto ha permitido saber que el canal que se debe utilizar es el 3. Así que el siguiente
paso consiste en añadir este canal al ordenador con la siguiente órden:
sdptool add --channel=3 SP
Esto dice al servidor SDP en el ordenador que el servicio de puerto serie está en el
canal 3 de RFCOMM.
2. El siguiente paso es dejar al ordenador escuchando, es decir, crear un servidor que

esté a la espera de que el P800 se conecte a él. Este servidor debe estar escuchando
en el canal 3 de RFCOMM. Para ello:
dund --listen --channel 3
Por defecto, dund crea el enlace RFCOMM utilizando el dispositivo /dev/rfcomm0,

si éste estubiese ocUpado crearía el /dev/rfcomm1 y así sucesivamente. Después,
el demonio dund lanza el demonio pppd con las opciones existentes en el fichero
options ubicado en /etc/ppp. El fichero options utilizado para la realización de la
prueba fue el siguiente:
debug
noauth
crtscts
lock
local
passive
silent
ms-dns 192.168.6.10
192.168.6.101:192.168.6.102
Todas estas opciones fueron explicadas en la sección 4.5.2.1 a exceptión de ms-

dns. El ms-dns especifica el servidor DNS que el P800 usará. Este parámetro es
requerido por PPP y sin éste el P800 no permitirá el establecimiento del enlace PPP.
3. Para probocar que el P800 inicie la conexión hay que ejecutar:
echo > /dev/rfcommX

Figura 4.23: Solicitud de pines entre el P800 y el ordenador
Antes de ejecutar esto hay que crear el enlace RFCOMM con el P800 utilizando el
dispisitivo /dev/rfcommX, para ello:
rfcomm bind /dev/rfcommX <BD_ADDR_P800> <channel_SP>
La ’X’ que define el dispositivo RFCOMM de /dev utilizado, debe ser la misma del
enlace RFCOMM con el P800 que cuando se proboca la conexión con echo.
Comentar que antes de crear la conexión el móvil P800 solicita un pin 5 , configurado
en la sección 4.6.1, después de introducir este pin, el ordenador solicita el mismo
pin. Y por último, el P800 informa de una solicitud de conexión que se debe aceptar.
La figura 4.23 expone unas capturas con las solicitudes del P800 y del ordenador.
Para todas las tareas, excepto la de transmisión, es necesario configurara primero
una relación permanente y de confianza entre el P800 y el otro dispositivo. Este
proceso se denomina emparejamiento (enlace). El P800 recuerda los dispositivos
emparejados, incluso después de apagarlo, por lo que no tiene que repetir el pro-
ceso en cada conexión con dichos dispositivos. El motivo del emparejamiento es
simplificar las conexiones futuras y convertirlas en seguras, sólo los dispositivos
emparejados se pueden conectar al P800.
5
Para todas las tareas, excepto la de transmisión, es necesario configurara primero una relación perma-
nente y de confianza entre el P800 y el otro dispositivo. Este proceso se denomina emparejamiento (enlace).
El P800 recuerda los dispositivos emparejados, incluso después de apagarlo, por lo que no tiene que repe-
tir el proceso en cada conexión con dichos dispositivos. El motivo del emparejamiento es simplificar las
conexiones futuras y convertirlas en seguras, sólo los dispositivos emparejados se pueden conectar al P800.
Figura 4.24: system log que muestra el enlace PPP entre el P800 y el ordenador
Si todo funciona correctamente se debería ver algo como la captura de la figura 4.24
que muestra el system log. No se porqué, pero la primera vez que se intente conectar el
P800 al ordenador hay que realizar dos veces echo >/dev/rfcommX.
Una vez que la sesión PPP está creada, inmediatamente el P800 intenta encontrar la
IP de la pasarela (router). Esta operación debe ser exitosa o el P800 cortará la conexión.
El P800 intenta encontrar la pasarela buscando un DNS para el host wsockhost.mrouter
en el servidor DNS que se le especifica en la conexión PPP (opción ms-dns del fichero
options). Debe ser capaz de resolver nombres en el dominio mrouter, por lo que hay que
editar un DNS en /etc/bind con el nombre mrouter. A continuación se muestran las líneas
del fichero mroute creado para poder conectar nuestro P800 al ordenador del laboratorio.
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA mrouter. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS mrouter.
@ IN A 127.0.0.1
wsockhost.mrouter. IN A 192.168.6.10
Hay sólo una entrada en el fichero mroute y apunta a la dirección IP 192.168.6.10, que
corresponde con la dirección del router que da acceso a la LAN para el P800. El router
debe necesariamente dirigir paquetes IP, pero la dirección IP debe ser real.
Capítulo 5
Conclusión y líneas futuras
Las conclusiones básicas deben establecerse en base a los objetivos propuestos en la

sección 1.5 y a la realización de estos.
En este proyecto se estudió la versión 1.1 de la especificación Bluetooth, así como la
pila de protocolos BlueZ de Linux. Los conceptos de Bluetooth adquiridos fueron esen-
ciales para comprender y desarrollar este proyecto.
El objetivo principal propuesto fue la evaluación del soporte de redes IP sobre Blue-
tooth. Para ello se probaron dos métodos distintos para asignar IP a los equipos Bluetooth
de los que se disponían. No ha habido ningún problema con los métodos propuestos (IP
sobre BNEP y IP sobre PPP sobre RFCOMM), como se muestra en las pruebas realizadas
en la parte práctica del proyecto.
Desafortunadamente, no se han podido realizar las pruebas de medicición de la SNR
de las conexiones, debido a los mediocres dispositivos Bluetooth de Microtune de los que
se dispusieron en las pruebas. Estos, al operar con cantidades "grandes"de bits echaban
atrás la conexión al transmitir a gran velociad quedando los dongles bloqueados. No hu-
biese sido posible afirmar este mal funcionamiento de los dispositivos sin ayuda de las
lista de correo de BlueZ[Sourceforge, WWW] .
El último objetivo conseguido en el proyecto fue la conexión del Sony Ericsson P800
a una LAN sobre Bluetooth.
Lineas futuras
El presente proyecto deja puertas abiertas a futuras investigaciones, debido a la conti-
nua y rápida evolución que experimentan todos los tipos de redes inalámbricas. Algunas
posibles investigaciones son:
Prueba con otros modelos.
Estudios de métodos dinámicos de asignación de IP en entorno Bluetooth.
Estudios sobre el desempeño de Bluetooth con aplicaciones IP comerciales.
Pruebas de medición de SNR.
En cuanto a los productos que existen en el mercado, la oferta se amplía a un gran

ritmo, por lo que habrá que ir visitando las páginas de Internet de los distintos fabrican-
91
92 CAPÍTULO 5. CONCLUSIÓN Y LÍNEAS FUTURAS
tes, para conocer las últimas novedades que vayan saliendo al mercado en lo referente a
dispositivos Bluetooth.
Las posibilidades que ofrece Bluetooth permiten el desarrollo de nuevos productos
y nuevas aplicaciones que pueden sUponer una mejora en la calidad de vida de muchas
personas, sin necesidad de hacer grandes inversiones de dinero. Por ejemplo, la empresa
Danesa BlueTags [BlueTags, WWW] ha instalado y puesto en marcha con éxito su siste-
ma de seguimiento en el zoológico de la localidad de Aalborg que permitirá a los padres
y monitores que acompañen a los niños durante la visita localizarlos dentro del recinto en
todo momento si estos se extravían o se alejan de su alcance. El sistema está basado entre
otros elementos, en un software de control, unos puntos de acceso Bluetooth repartidos
por todo el recinto, y en unos localizadores que se entregarán al niño a la entrada, en los
que quedará grabada la información básica de contacto con los padres o tutores. éstos reci-
birán inmediatamente un código de acceso al sistema de localización mediante un mensaje
SMS. En caso de que sea necesario, mediante el código recibido será posible responder a
este mensaje y enviar una orden de localización al sistema, el cual nos responderá en unos
instantes informando de la situación del niño dentro del área de contol.
Apéndice A
Contenido del CD-ROM
Esta memoria está acompañada de un CD-ROM donde se incluye documentación del

proyecto y los paquetes necesarios para probar BlueZ en Linux(ver 4.2).
Este CD-ROM tiene las siguientes partes:
PDF con este Proyecto Final de Carrera y PPT con la presentación del PFC.
Documentación: Specification of the Bluetooth System - Volume 2 - Core, Specifica-

tion of the Bluetooth System - Volume 3 - Profiles, especificaciones de BNEP y PDF
con el perfil PAN.
Software: Esta parte incluye todas las versiones de los paquetes disponibles de
BlueZ, descargados de http://bluez.sourceforge.net a fecha de entrega del proyecto.
Además, incluye los parches de BlueZ para los diferentes kernels y los paquetes
.dev para Debian, si se dispone de esta versión de Linux y se prefiere instalar BlueZ
de esta forma.
93
94 APÉNDICE A. CONTENIDO DEL CD-ROM
Bibliografía
[Bluetooth SIG, WWW] Bluetooth Special Interest Group http://www.bluetooth.com.
[IEEE 802.11, WWW] http://www.grouper.ieee/groups/802/11.
[IEEE 802.15, WWW] http://www.grouper.ieee/groups/802/15.
[Bluetooth, WWW] Página oficial de Bluetooth http://www.bluetooth.com.
[HiperLAN/2, WWW] Página oficila del estándar HiperLAN/2

http://www.hiperlan2.com.
[HomeRF, WWW] Página oficial del estándar HomeRF http://www.homerf.org.
[Ref1, WWW] Referencia a página Web El siglo de Torreon

http://elsiglodetorreon.com.mx/informatica/nlD/56025/m/12/y/2003.
[Ericsson, WWW] Página ofical de la empresa Ericsson http://www.ericsson.com.
[BTSIG1.1, WWW] PDF con el estándar 1.1 de Bluetooth, incluido en el CD.

http://www.bluetooth.com/pdf/bluetooth_11_profile_book.pdf.
[BTSIG1.0B, PDF] Especificaciones del sistema Bluetooth-Volumen 2 Estándar 1.0b de

Bluetooth incluido en el CD.
[Ref2, WWW] Página Web de la Universidad de Cauca

http://atenea.unicauca.edu.co/ dabravo/bluetooth/aplicaciones.htm.
[BLIP de Ericsson, WWW] Página oficial de Ericsson sobre sus dispositivos BLIP
http://www.ericsson.com/blip/main.asp.
[IrDA, WWW] Asociación de datos ifrarrojos http://www.irda.org.
[Nokia, WWW] Página oficial de la compañía Nokia http://www.nokia.com.
[Toshiba, WWW] Página oficial de la compañía Toshiba http://www.toshiba.com.
[IBM, WWW] Página oficial de la empresa IBM http://www.ibm.com.
[Intel, WWW] Página Web de Intel http://www.intel.com.
[3COM/Palm, WWW] Página Web oficial de 3COM/Palm http://www.palm.com.
95
96 BIBLIOGRAFÍA
[Compaq, WWW] Página oficial de Compaq http://www.compaq.com.

[Dell, WWW] Ubicación Web de la empresa Dell http://www.dell.com.
[Motorola, WWW] Página oficial de la compañía Motorola http://www.motorola.com.
[Xircom, WWW] Ubicación Web de Xircom http://www.xircom.com.
[IEEE, WWW] Instituto de ingeniería eléctrica y electrónica http://www.ieee.org.
[Philips, WWW] Ubicación Web de Philips http://www.philips.com.

[Sony, WWW] Página Web oficial de Sony http://www.sony.com.
[Ref3, WWW] Prensa de la página Web Philips

http://www.philips.cl/prensa/2002/enero/inalambrica.htm.
[Ref4, WWW] Artículos sobre UMTS/3G, GPRS y tecnologías inalámbricas
¯
http://www.umtsforum.net/mostrar_articulos.asp?u_adtiondisplay&u_log ¯
34.
[Cahner, WWW] Cahner’s Instat Group http://www.instat.com.

[Hewlett Packard, WWW] Página ofical de Hewlett Packard http://www.hp.com.
[Ref5, WWW] Página Web de ZonaBluetooth, información de productos Bluetooth

http://www.zonabluetooth.com.
[Microsoft, WWW] Ubicación Web de la compañía Microsoft
http://www.microsoft.com.
[Apple, WWW] Página Web oficial de Apple http://www.apple.com.

[Ref6, WWW] Página Web http://www.yosoytucuman.com.ar/.
[Panasonic, WWW] Panasonic Mobile http://www.panasonicmobile.com.
[BlueTake, WWW] Página ofcial de la empresa BlueTake http://www.bluetake.com.
[Plantronic, WWW] Ubicación Web de la compañía Plantronics

http://www.plantronics.com.
[OpenBrain, WWW] Ubicación Web de la firma coreana Openbrain Technologies

http://www.openbrain.co.kr.
[Socket, WWW] Página Web de la empresa norteamericana Socket
http://www.socketcom.com.
[Parrot, WWW] Ubicación Web de la empresa Parrot http://www.parrot.fr.

[Ref7, WWW] Referencia Web http://www.drive.com/(qmpyhe45tnsrydatdys25fy)/default.aspx?lan=es.
[BlueCore, WWW] Sitio Web oficial de la tecnología BlueCore

http://www.domotica.net/bluecore.htm.
BIBLIOGRAFÍA 97
[Microtune, WWW] Empresa representada en España por Ibérica de Componentes, S.A.

http://www.microtune.com.
[SonyEricsson, WWW] Página ofical de la compañía de teléfonos móviles Sony Ericsson

http://www.sonyericsson.com.
[OpenBT, WWW] Driver Bluetooth desarrollado por Axis Communications Inc.

http://sourceforge.net/projects/openbt.
[BlueDrekar] Ubicaciín Web de BlueDrekar diseñado por IBM

http://affix.sourceforge.net.
[BlueZ, WWW] Página oficial de software BlueZ http://www.bluez.org.
[Axis, WWW] Ubicación Web oficial de Axis Communications Inc.

http://www.axis.com.
[Sourceforge, WWW] Página Web ofical de SourceForge http://sourceforge.net.
[Alpha Works, WWW] Ubicación Web de Alpha Works http://alphaworks.ibm.com.
[Qualcomm, WWW] Página Web oficial del desarrollador de BlueZ, Qualcomm

http://www.qualcomm.com.
[Ref8, WWW] Página Web relacionada con la distribución Debian

http://www.debianitas.net/docbook/nucleo-2.4.22-iso-ver-1.0/nucleo-2.4.22-iso-ver-
1.0.html.
[Ref9, WWW] Ubicación Web para descargar el fichero create_dev

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/bluez/kernel/create_dev?rev=1.2
[BlueTags, WWW] Página Web oficial de la empresa Danesa BlueTags

http://www.bluetags.com.

pfc1175 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

pfc1175 PDF

Cargado por

Copyright:

Formatos disponibles

Índice general

3.1.4. IP sobre [PPP sobre RFCOMM] . . . . . . . . . . . . . . . . . . 42

4. Desarrollo del proyecto 55

4.4.2.2. Creación de un escenario modo ad-hoc . . . . . . . . . 69

5. Conclusión y líneas futuras 91

A. Contenido del CD-ROM 93

1.1. Clasificación de las tecnologías inalámbricas . . . . . . . . . . . . . . . . 2

2.1. Perfiles de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.33. Chip MT0760 de Microtune . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1. IP sobre L2CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1. Diagrama de BlueZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

1.2. Introducción a las tecnologías inalámbricas

Figura 1.1: Clasificación de las tecnologías inalámbricas

Figura 1.2: Aplicaciones de Bluetooth

WAN/MAN (Wide Area Network/Metropolitan Area Network)

1.3. Aplicaciones de Bluetooth

Automatización hotelera: la cadena de hoteles Holiday Inn, Axis Communications

Acceso a Internet en aeropuertos: muchos ejecutivos que viajan regularmente se

Acceso a información en trenes: BT Syncordia y Midland Mainline han comenza-

1.4. Competencia de Bluetooth

La seguridad de IrDA se basa en la direccionalidad del rayo de luz infrarrojo, mien-

IrDA es más popular entre los dispositivos inalámbricos actuales y es compatible

Bluetooth se adapta mejor para servicios de acceso a red y de marcación y otros

Bluetooth es mejor para soluciones de difusión (broadcast) de información.

Una conclusión general, es que ambas tecnologías se complementan y tienen nichos

1.5. Objetivos del Proyecto

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 sincroni-

Tecnológicamente hablando, Bluetooth funciona a través de pequeños y baratos trans-

ampliamente en un gran número de aplicaciones, ya que su coste era relativamente bajo.

El sistema debería operar en todo el mundo.

La conexión debería soportar voz y datos, y adicionalmente aplicaciones multime-

Figura 2.1: Perfiles de Bluetooth

2.5.1. Perfil Genérico de Acceso

2.5.2. Perfil de Puerto Serie

2.5.3. Perfil de Descubrimiento de Servicio

dispositivos. El SDAP es dependiente del GAP.

2.5.4. Perfil Genérico de Intercambio de Objetos

2.5.5. Perfil de Telefonía Inalámbrica

2.5.6. Perfil de Intercomunicador

2.5.7. Perfil de Manos Libres

2.5.8. Perfil Dial-Up Networking

2.5.9. Perfil de Fax

2.5.10. Perfil de Acceso LAN

2.5.11. Perfil Object Push

2.5.12. Perfil de Transferencia de Archivos

2.5.13. Perfil de Sincronización

2.6. Topología red Bluetooth

Figura 2.2: Ejemplo de maestros y esclavos

2.7. Piconet y Scatternet

Figura 2.3: Ejemplo de una piconet

Figura 2.4: Ejemplo de sacatternet

2.8. Pila de protocolos de Bluetooth

Una pila de protocolos es un conjunto de capas de la pila de Bluetooth, con el fin

Figura 2.5: Pila de protocolos Bluetooth

Figura 2.6: Esquema del hardware de un dispositivo Bluetooth

2.8.1. Arquitectura hardware

Figura 2.7: División del canal físico de Bluetooth

El CPU del dispositivo se hace responsable de atender las instrucciones relacionadas

Envío y recepción de datos

Negociación y determinación de tipos de enlace (SCO o ACL)

Determinación del tipo de cuerpo de cada paquete