Comunicacin inalmbrica

Las transmisiones de datos entre equipos electrnicos sin cables se estn aplicando cada vez ms debido a los medios tecnolgicos actuales, estos medios son los circuitos integrados los cuales permiten hacer un diseo sin tener demasiados conocimientos de RF, debido a que estos dispositivos requieren pocos componentes externos y ningn tipo de ajuste en RF. Primero se usaron mdulos de RF con componentes discretos unidireccionales y precisamente para no tener que depender del diseo de una circuitera en RF. Posteriormente con la aparicin de circuitos transmisores completamente integrados que unificaron las funciones de emisor y receptor, haciendo uso de diferentes bandas de frecuencia que se fueron estandarizando en diferentes zonas (Europa y USA), han permitido poderlos utilizar en los diferentes campos de aplicacin industrial, comercial, y mbito medico, como por ejemplo: control remoto, transmisin de datos en sensores, sistemas de adquisicin de datos, monitorizacin mdica o de la salud, etc... Las comunicaciones inalmbricas por RF se pueden dividir en las que no cumplen ningn protocolo estndar, las que cumplen un protocolo estndar y en las normativas sobre sus distintas frecuencias de trabajo, que a la vez definen velocidad de transmisin, ancho de banda y campo de aplicacin.

ZigBee IEEE 802.15.4

Iniciado por Philips, Honeywell, Invensys y seguido por Motorola (ahora Freescale), Mitsubishi y hasta 25 empresas ms, con la idea de crear un sistema estndar de comunicaciones inalmbrico y bidireccional, ideado para usarlo dentro de dispositivos de domtica, automatizacin de edificios (denominado inmtica), control industrial, perifricos de PC y sensores mdicos. Los miembros de esta alianza justifican el desarrollo de este estndar para cubrir el vaco que se produce por debajo del Bluetooth. Puede transmitir con un simple protocolo de 20kB/s hasta 250Kbps trabajando a una frecuencia de 2,4GHz con la tecnologa GSSS, bajo consumo y rangos entre 10 y 75 metros, aunque las condiciones fsicas ambientales son las que determinan las distancias de trabajo. IEEE 802.15.4 es un simple protocolo de paquetes de datos para redes inalmbricas ligeras. ZigBee, se conoce con otros nombres como "HomeRF Lite", tambin puede usar las bandas libres ISM de 2,4 GHz, 868 MHz (Europa) y 915 MHz (EEUU). Una red ZigBee puede estar formada por hasta 255 nodos, los cuales tienen dormido el transceiver ZigBee la mayor parte del tiempo, para mantener un bajo consumo.

Fundamentos del estndar IEEE 802.15.4 El IEEE 802.15.4 es un protocolo de paquete de datos simple para redes inalmbricas ligeras. Muchos de los aspectos de este diseo han sido usados durante muchos aos en redes de radio paquetes. Debido a que ZigBee se concentra en la baja transmisin de datos, se emplea CSMA (Carrier Sense Multiple Access) para evitar interferencias. CSMA indica simplemente que los dispositivos 802.15.4 escuchan antes de transmitir. Si hay una interferencia, el dispositivo espera un perodo de tiempo y vuelve a intentarlo otra vez. Hay 16 canales definidos en la banda de 2.4 GHz. Y dispone de estructuras beacon (guas) para mejorar la latencia. El estndar IEEE 802.15.4 define mltiples niveles de seguridad. El protocolo 802.15.4 est diseado para la monitorizacin y para aplicaciones de control donde la duracin de la pila es importante.

Objetivo El objetivo de esta tecnologa no es obtener velocidades muy altas, ya que solo puede alcanzar una tasa de 20 a 250Kbps en un rango de 10 a 75 metros, si no que es obtener sensores cuyos transceptores tengan un muy bajo consumo energtico. De hecho, algunos dispositivos alimentados con dos pilas AA puedan aguantar 2 aos sin el cambio de bateras. Por tanto, dichos dispositivos pasan la mayor parte del tiempo en un estado latente, es decir, durmiendo para consumir mucho menos.

Bandas de operacin ZigBee opera en las bandas libres de 2.4Ghz, 858Mhz para Europa y 915Mhz para Estados Unidos. En la siguiente figura se puede ver el espectro de ocupacin en las bandas del protocolo 802 (incluyendo ZigBee).

Figura 1. Tecnologas en 2.4GHz En la banda de 2.4Ghz usa la modulacin de espectro expandido DSSS (Direct Sequence Spread Spectrum). A una velocidad de transmisin de 250Kbps y a una potencia de 1mW cubre aproximadamente unos 13 metros de radio. En la siguiente figura se muestran las caractersticas de radio de las seales.

Figura 2. Caractersticas de radio

En la siguiente tabla se puede observar la distancia en funcin de la potencia transmitida y la velocidad de transmisin:

Tabla 1. Distancia de transmisin

En cuanto a la gestin del control de acceso al medio hace uso de CSMA/CA (Carrier Sense Multiple Acces with Collision Avoidance) y es posible usar ranuras temporales TDMA (Time Division Multiple Access) para aplicaciones debaja latencia. Nodos y topologa de red En una red ZigBee pueden haber hasta 254 nodos, no obstante, segn la agrupacin que se haga, se pueden crear hasta 255 conjuntos/clusters de nodos con lo cual se puede llegar ha tener 64770 nodos para lo que existe la posibilidad de utilizar varias topologas de red: en estrella, en malla o en grupos de rboles, como puede verse a continuacin:

Figura 3. Topologas de Red

Se permite un encaminamiento o enrutamiento de saltos mltiples, tambin conocido como multi-hop, que permite que estas redes abarquen una gran superficie.

En ZigBee hay tres tipos de dispositivos: 1. Coordinador Slo puede existir uno por red. Inicia la formacin de la red. Es el coordinador de PAN. 2. Router Se asocia con el coordinador de la red o con otro router ZigBee. Puede actuar como coordinador. Es el encargado del enrutamiento de saltos mltiples de los mensajes. 3. Dispositivo final Elemento bsico de la red. No realiza tareas de enrutamiento. Una posible configuracin de una red sera la siguiente:

Figura 4. Ejemplo de red ZigBee Otro punto importante es el soporte y la disponibilidad total de la malla, es decir, que ante cadas de nodos, la red busca caminos alternativos para el intercambio de mensajes, un ejemplo se puede ver a continuacin. Supongamos que disponemos de una red en la cual los nodos estn conectados en malla y se intercambian datos entre un interruptor y una lmpara.

Figura 5. Camino de comunicacin (interconexin) Si algunos de los nodos que contiene falla y dichos nodos formaban parte del camino que seguan los mensajes en la comunicacin, la red podra sufrir una

cada: Figura 6. Cada de dos nodos de red ZigBee permite que se puedan establecer rutas alternativas para seguir comunicando los dispositivos:

Figura 7. Creacin de un camino alternativo

Seguridad En cuanto a seguridad, ZigBee puede utilizar la encriptacin AES de 128bits, que permite la autentificacin y encriptacin en las comunicaciones. Adems, existe un elemento en la red llamado Trust Center (Centro de validacin) que proporciona un mecanismo de seguridad en el que se utilizan dos tipos de claves de seguridad, la clave de enlace y la clave de red. Capa de Aplicacin La pila de arquitectura ZigBee consta de varios componentes en capas como IEEE 802.15.4 2003 en la capa de Control de Acceso al Medio (MAC), la capa fsica (PHY) y la capa de red Zigbee (NWK). La capa de aplicacin de ZigBee se subdivide en la subcapa APS, la capa ZDO (Zigbee Device Objects) y los objetos de aplicacin definidos por cada uno de los fabricantes.

Figura 8. Pila de protocolo ZigBee Subcapa de Soporte La subcapa de soporte de aplicacin (APS) proporciona un interfaz entre la capa de red (NWK) y la capa de aplicacin (APL) a travs de un conjunto de servicios que se utilizan junto a los ZDO y otros objetos que hayan sido definidos por los fabricantes. Los servicios los ofrecen dos entidades: la entidad de datos APS (APSD) a travs del servicio de punto de acceso APSDE (APSDE-SAP) y la entidad gestora del APS (APSME-SAP) a travs de un servicio que ofrece el punto de acceso APSE-SAP. APSDE proporciona el servicio necesario para la transmisin de datos y el transporte de de datos de aplicacin entre dos o ms dispositivos en la misma red. APSME proporciona el servicio de descubrimiento y enlace de dispositivos y mantiene una base de datos de los objetos llamado APS Information Base (AIB). Capa de Red Las primitivas de confirmacin de la capa de red, suelen incluir parmetros encargados de informar acerca del estado de las solicitudes que genera la capa inmediatamente superior, la capa de aplicacin. Estos parmetros son los que aparecen en la siguiente tabla.

Tabla 2. Primitivas de Confirmacin

Descripcin General La capa de red es necesaria para ofrecer servicios a la capa inmediatemente superior, la capa de Aplicacin, que permitan realizar operaciones sobre la capa inmediatamente inferior a la misma, la sub-capa de MAC, definida en el IEEE 802.15.4-2003. Es decir, la capa de red hace de interfaz entre la capa de Aplicacin y la de MAC. Para esto, la capa de red dispone en esta interfaz de dos servicios, con los que cubre las necesidades de la capa de Aplicacin. Estos dos servicios se conocen como Servicio de Datos y Servicio de Control.

La comunicacin entre la capa de Aplicacin y la sub-capa MAC, se lleva a cabo en el SAP de la capa de Red. Utilizando las interfaces descritas anteriormente. Esto se traduce de forma que, entre la capa de Aplicacin y la de Red existen dos SAP, uno por cada servicio que la capa de Red oferta a la de Aplicacin. De la misma forma que aparecen otros dos SAP ms entre la capa de Red y la sub-capa de MAC.

Figura 9. Capa de Red Claves de Seguridad La seguridad en una red de dispositivos ZigBee se basa en claves de enlace y de red. En una comunicacin por unicast entre pares de entidades APL la seguridad se basa en claves de 128bits entre los dos dispositivos. Por otro lado, la comunicacin existente cuando es por broadcast, tambin las claves para la seguridad se establecen de 128bits entre todos los dispositivos de la red. Un dispositivo adquiere la clave de enlace mediante el transporte de clave, establecimiento de clave o dada en la preinstalacin desde el fabricante. Por otro lado, para el establecimiento de la clave de red hay dos maneras: el transporte de clave y la preinstalacin. Como se ha mostrado en apartados anteriores el establecimiento de clave se obteniendo previamente una clave de enlace basndose en una clave maestra. Esta clave maestra puede ser obtenida por el transporte de dicha clave o en fbrica. La clave de red tiene que ser usada por las capas MAC, NWK y APL de ZigBee. Las claves maestras y las de enlace solo pueden ser usadas en la subcapa APS, de hecho, las claves maestras y de enlace deben estar disponibles solo en la capa APL. Arquitectura de Seguridad Las aplicaciones ZigBee se comunican usando el estandar de wireless IEEE 802.15.4 que especifica que hay dos capas, la capa fsica (PHY) y la capa de control de acceso al medio (MAC). ZigBee construye en estas capas una capa de red (NWK) y otra de

aplicacin (APL). La capa de MAC proporciona servicios de que permiten la fiabilidad y la comunicacin directa entre dispositivos. La capa de red (NWK) proporciona enrutado y funciones de multihop que se puedan necesitar para crear cada una de las topologas que se necesiten como la de estrella, malla, rbol, etc. La capa APL incluye la subcapa de soporte de aplicacin (APS), los ZDO y las aplicaciones. El ZDO es responsable de toda la gestin de dispositivos mientras que la capa APS proporciona el servicio necesario para los ZDO y las aplicaciones ZigBee. Seguridad MAC Cuando una trama en la capa MAC tiene que ser asegurada, ZigBee tiene queusar la capa de seguridad que se indica en la especificacin 802.15.4. La capa MAC se encarga de su propio proceso de seguridad aunque sean las capas superiores las encargadas de determinar el nivel de seguridad a usar. La siguiente figura muestra un ejemplo de los campos de seguridad que tienen que ser incluidos en las tramas en las que se indica que tiene que existir seguridad a nivel de MAC.

Figura 10. Seguridad en MAC Seguridad NWK (Red) Cuando una trama en la capa de red necesita ser asegurada, ZigBee debe usar ciertos mecanismos de proteccin de los datos. Al igual que la capa MAC, el mecanismo de proteccin de trama en la capa de red NWK usa de la encriptacin Advanced Encription Standard, es decir, AES. Sin embargo son las capas superiores las que deben indicar el nivel de seguridad que se tiene que aplicar. Una responsabilidad de la capa de red (NWK) es enrutar los mensajes sobre enlace multihop. La capa de red tiene que enviar como broadcast sus peticiones de enrutado y recibir las respuestas. Se realiza de manera simultnea el enrutamiento de los mensajes de peticiones que se envan a los dispositivos cercanos y los que se reciben de ellos. Si la clave de enlace apropiada se indica, la capa de red usa esta clave de enlace para asegurar sus tramas de red. Si por el contrario no se indica, para poder asegurar los mensajes de la capa de red usa su propia clave de red para asegurar las tramas de red. Por tanto en el formato de la trama se indica de manera explcita la clave que se ha usado para protegerla.

La siguiente figura muestra los campos que se deben incluir en una trama de red.

Figura 11. Seguridad en NWK Seguridad en APL Cuando una trama en la capa APL necesita ser asegurada, la subcapa APS es la encargada de gestionar dicha seguridad. La capa APS permite que la seguridad de trama se base en las claves de enlace y de red (Link y Network Keys) como se ha visto en apartados anteriores. La siguiente figura muestra los campos para proporcionar seguridad en una trama del nivel APL.

Figura 12. Seguridad en APL

Establecimiento de Clave Los servicios de establecimiento de clave en la subcapa APS proporcionan el mecanismo por el cual un dispositivo ZigBee puede obtener una clave secreta compartida (la clave de enlace) con otro dispositivo ZigBee. En establecimiento de clave existen dos elementos: el que inicia la comunicacin y el que responde, que normalmente es el que le dar la validacin. La informacin de validacin, es decir, la clave maestra da paso a que el elemento iniciador pueda establecer una clave de enlace. En el establecimiento del protocolo de clave simtrica Symmetric-Key Key Establishment (SKKE), el dispositivo iniciador establece una clave de enlace con el receptor usando la clave maestra. Esta clave maestra, puede venir dada de fbrica o que se implemente desde el centro de validacin, que puede ser un tercer elemento o bien puede venir dada como datos introducidos por usuario.

Transporte de Clave El servicio de transporte de clave proporciona tanto la posibilidad de transportar la clave de manera segura y no segura de un dispositivo a otros. La instruccin o comando de transportar clave segura significa transportar las claves maestras, de enlace, de red desde el centro de validacin a los dispositivos.Este comando no protege con criptografa la clave que tiene que ser cargada.

WIMAX IEEE 802.16

INTRODUCCIN WiMAX (World Interoperability for Microwave Access) es un sistema de comunicaciones digital inalmbrico, tambin conocido como IEEE 802.16, destinado a redes inalmbricas de rea metropolitana. Puede proveer accesos inalmbricos de banda ancha (BWA) por encima de 50 Km. Para estaciones fijas, y de 5 a 15 Km. para estaciones mviles. En contraste, el estndar de red inalmbrica de rea local WiFi/802.11 est limitado en muchos casos a solamente 30 a 100 metros. WiMAX soporta fcilmente tasas de datos similares a WiFi, pero la influencia de las interferencias disminuye. WiMAX opera en frecuencias tanto licenciadas como no licenciadas, proveyendo un ambiente regulado y un modelo econmico y viable para los carriers inalmbricos. Puede utilizarse para networking inalmbrico casi como el protocolo WiFi ms comn. El estndar IEEE 802.16 define las caractersticas tcnicas del protocolo de comunicaciones. Con este, es posible la ltima milla en accesos wireless en reas remotas, difciles y costosas de alcanzar con cable o fibra. Tambin podra servir como backhaul WiFi permitiendo una rpida y fcil conexin de hot spots WiFi a Internet cuando no sea conveniente acceder con cable. Eventualmente, permite conectar notebooks y PDAs directamente a las redes de rea metropolitana (MAN), que proveen un rango de cobertura inalmbrica continuo geogrficamente . Generalidades de 802.16 En Enero de 2003, el IEEE aprob el estndar 802.16a, el cual cubre bandas de frecuencias entre 2 GHz y 11 GHz. Este estndar es una extensin del estndar IEEE 802.16 para 10-66 GHz publicado en Abril de 2002. Este subrango de frecuencias en 11 GHz permite el desempeo de enlaces sin lnea de vista (NLOS), haciendo al IEEE802.16a la tecnologa apropiada para aplicaciones de ltima milla donde los obstculos como rboles y edificios estn siempre presentes y en donde las estaciones bases pueden necesitar ser montadas sin discreciones en los techos de viviendas o edificios en vez de en torres o montaas. La configuracin ms comn 802.16a consiste en una estacin base montada en un edificio o torre que comunica en configuracin puntomultipunto a abonados ubicados en oficinas u hogares. El 802.16a posee un rango de hasta 48 Km. con celdas tpicas de 6.5 a 9.5 Km. Dentro del radio de celda tpico, el desempeo sin lnea de vista y throughpout son ptimos. En adicin, el 802.16a provee una tecnologa inalmbrica ideal para conectar WLANs 802.11 y hotspots comerciales con Internet.

Con datos compartidos de hasta 75 Mbps, un sector simple de una estacin base 802.16a donde un sector es definido como un par simple de radios transmisor / receptor en la estacin base provee suficiente ancho de banda para soportar simultneamente 60 puntos de negocio con conectividad nivel T1 y cientos de hogares con conectividad nivel DSL, usando canales de 20 MHz de ancho de banda. Para soportar un modelo de negocio rentable, los operadores y proveedores de servicio necesitan sostener una mezcla de abonados de alto nivel de ingresos y un alto volumen de abonados residenciales. El 802.16 ayuda a satisfacer este requerimiento mediante el soporte de niveles de servicio diferenciados, los cuales pueden incluir servicios de nivel T1 garantizados para negocios, o servicios DSL best effort para usuarios residenciales. La especificacin 802.16 tambin incluye funciones de seguridad robustas y la Calidad de Servicio (QoS) necesaria para soportar servicios que requieren baja latencia como video y voz. El servicio de voz 802.16 puede ser el tradicional TDM o voz sobre IP (VoIP).

Figura 1: estndares 802.16 y 802.16a utilizados para accesos inalmbricos de banda ancha y 802.11 backhaul

ESTNDAR 802.16

Tabla 1: estndar IEEE 802.16

Caractersticas Bandas con y sin licencia. Ancho de banda mnimo por canal 1.75 MHz. Optimo 10 MHz. Las bandas sin licencias de 2.4 y 5 GHz deben usarse con cautela. Posibilidad de gran interferencia. Algunos pases an no han asignado las bandas para WiMAX. Duplexing: FDD es ms adecuado para trfico de empresas, TDD ms adecuado para trfico asimtrico. WMAN no es una WLAN, comparada con WLAN: multimedia QoS, ms usuarios, mayor tasa de bits y mayor alcance WMAN no es una WWAN, comparada con WWAN: altas tasas de bits, movilidad limitada, menos alcance.

Servicios y prestaciones de WiMAX

Servicios Acceso a Internet de Alta Velocidad. Voz (VoIP). Transmisin de datos (VPN IP, Lnea Dedicada).

Conectividad a Internet para redes WiFi / GSM / GPRS / UMTS.

Prestaciones: Soporta diferentes niveles de servicio para usuarios particulares y empresas. Posibilidad de aumentar el ancho de banda o las prestaciones en funcin de las necesidades de los usuarios. Precio de servicios similares a ADSL /Cable pero con prestaciones superiores: simtrica o asimtrica, mayor ancho de banda, calidades de servicios con velocidades garantizadas, control remoto para la resolucin de incidencias. Gran ancho de banda: hasta 70 Mbps por usuario y hasta 420 Mbps por estacin base. Rpido despliegue (hasta 50 Km de cobertura). Fcil instalacin (se puede ejecutar en un plazo de dos horas). La prestacin de servicios WiMAX en frecuencias de uso exclusivo permite garantizar calidades de servicio (carrier class). Alta eficiencia en el uso del espectro y estabilidad. Permite la transmisin simultnea de voz, video y datos.

Comparativo WiFi / WiMAX / 3G WiMAX puede operar en el espectro licenciado o no licenciado.

Tabla 3: Resumen de Enlaces de Radio 802.16

Tabla 4: Comparativo diferentes tecnologas wireless

Principales caractersticas de IEEE 802.16 Las principales caractersticas de IEEE 802.16 son las siguientes: Tasa de Transferencia. Escalabilidad. QoS. Seguridad.

Tasa de Transferencia Por medio de un robusto esquema de modulacin, el IEEE 802.16 entrega una alta tasa de transferencia a altos rangos con un alto nivel de eficiencia espectral que es tambin tolerante a reflexiones de seal. La modulacin dinmica adaptativa permite a la estacin base negociar la tasa de transferencia por rangos. Por ejemplo, si la estacin base no

puede establecer un link robusto a un abonado distante usando el esquema de modulacin de mayor orden, 64 QAM (Modulacin por Amplitud en Cuadratura), el orden de modulacin se reduce a 16 QAM o QPSK, la cual reduce la tasa de transferencia e incrementa el rango efectivo.

Escalabilidad Para acomodar un planeamiento de celda fcil en el espectro de ambas bandas licenciada y no licenciada-exenta en todo el mundo, el 802.16 soporta canales de ancho de banda flexibles. Por ejemplo, si un operador tiene asignado 20 MHz de espectro, este operador puede dividirlo en 2 sectores de 10 MHz cada uno, o 4 sectores de 5 MHz cada uno. Focalizando la potencia en sectores de pequeos incrementos, el operador puede incrementar el nmero de usuarios manteniendo un buen rango y tasa de transferencia. Para escalar aun ms la cobertura, el operador puede rehusar el mismo espectro en dos o ms sectores creando aislaciones propias entre las antenas de estaciones base.

Cobertura En adicin al soporte de un esquema de modulacin robusto y dinmico, el estndar IEEE 802.16 tambin soporta tecnologas que incrementan la cobertura, incluida la tecnologa de malla (mesh) y las tcnicas de antena inteligente. Mientras la tecnologa de radio mejora y los costos bajan, la habilidad de incrementar la cobertura y la tasa de transferencia usando mltiples antenas para crear diversidad en transmisin y/o recepcin aumentar sensiblemente la cobertura en escenarios extremos.

Calidad de Servicio (Qos) La capacidad de voz es extremadamente importante, especialmente en mercados internacionales no cubiertos por servicio. Por esta razn el estndar IEEE 802.16a incluye caractersticas de calidad de servicio que permiten servicios incluyendo voz y video que requieren una red de baja latencia. Las caractersticas de garanta requeridas por el controlador de acceso al medio (MAC) del IEEE 802.16, permiten al operador brindar simultneamente niveles de servicio Premium garantizados para negocios, tanto como niveles de servicio T1, y servicio de alto volumen best effort a hogares, similares a niveles de servicio de cable, todos dentro de la misma rea de servicio perteneciente a una estacin base.

Seguridad Las caractersticas de privacidad y encriptado estn incluidas dentro del estndar 802.16 para soportar transmisiones seguras y proveer autenticacin y encriptado de datos.

ARQUITECTURA IEEE 802.16 El estndar 802.16 contempla tanto el interface de aire como las funciones relacionadas con los bucles locales inalmbricos o bucles inalmbricos fijos (WLL). Por ellos se crearon tres grupos distintos de trabajo: IEEE 802.16.1, IEEE 802.16.2 y IEEE 802.1.3

IEEE 802.16.1: tiene como objetivo el interface de aire para 10-66 GHz. IEEE 802.16.2: centrado en la coexistencia de los diversos sistemas de acceso inalmbrico de banda ancha. IEEE 802.16.3: se ocupa de la interface de aire para las frecuencias de 211 GHZ que requieren licencia.

Los estndares estn organizados en una arquitectura de tres niveles o capas: Capa fsica (nivel inferior): se especifican la banda de frecuencias, el esquema de modulacin, las tcnicas de correccin de errores, sincronizacin entre transmisor y receptor, velocidad de los datos y estructura TDM (Time Divisin Multiplexing). Para soportar las transmisiones entre abonados y la estacin base, se utiliza la tcnica TDMA-DAMA (Time Divisin Mltiple Access Demand Assignment Mltiple Access). DAMA asigna capacidad a mltiples estaciones en funcin de los cambios que se produzcan en las necesidades y en la demanda. La tcnica TDMA se encarga de dividir el tiempo de un canal en una secuencia de tramas, consistente cada una de ellas en un nmero determinado de slots, y de asignar uno o ms slots por trama para formar un canal lgico. Con TDMA DAMA, la asignacin de slots a los canales vara dinmicamente. Para las transmisiones desde una estacin base a los abonados, el estndar especifica dos modos de operacin, uno dirigido a soportar trfico continuo (modo A9, tales como audio o video, y otro para tratar trficos en rfagas (modo B), como el basado en IP. Ambos son esquemas TDM. Capa de enlace de datos: por encima del nivel fsico se encuentran las funciones asociadas con la provisin del servicio a los abonados. Esas funciones incluyen la transmisin de datos en tramas y el control de accesos al medio de cableado compartido, y se agrupan en un nivel MAC (Media Access Control). El protocolo MAC define cmo y cundo una estacin base o estacin de abonado puede iniciar la transmisin sobre el canal. Y como algunas de las capas superiores al

nivel MAC, como ATM, requieren calidad de servicio, el protocolo MAC debe ser capaz de asignar capacidad de canal de radio a fin de satisfacer las demandas del servicio. Al haber un solo transmisor en la direccin hacia el usuario(de estacin base a estacin de abonado), el protocolo MAC es relativamente simple. Sin embargo, como en el sentido usuario-red compiten mltiples estaciones de abonado por el acceso, el protocolo MAC utilizado resulta ms complejo. En ambos sentidos se utiliza una tcnica TDMA, por lo que el trfico de datos se divide en varios slots de tiempo y la secuencia de stos que se dedica a un abonado forma un canal analgico, sobre el que se transmiten las tramas MAC. IEEE 802.16.1 soporta velocidades de datos por canal desde 2 hasta 155 Mbit/s. Subcapa de convergencia: por encima del Subnivel MAC aparece una capa de convergencia que proporciona funciones especficas en funcin del servicio que se est ofreciendo. Los servicios portadores soportados por IEEE 802.16.1 incluyen multicast audio / video digital, telefona digital, ATM, acceso a Internet, lneas inalmbricas de redes telefnicas y Frame Relay.

La pila de protocolos del 802.16

Subcapa dependiente del medio fsico: QPSK, QAM-16, QAM-64 Capa de enlace de datos: consta de tres subcapas Subcapa de seguridad: maneja codificacin, decodificacin y administracin de claves. Parte comn de la Subcapa MAC: aqu se encuentran los principales protocolos, como la administracin del canal. El modelo consiste en que la estacin base controla el sistema. Puede calendarizar de manera muy eficiente los canales de flujo descendente (estacin base al suscriptor) y es muy importante en el manejo de los canales ascendentes (suscriptor a la estacin base). Esta Subcapa est

completamente orientada a la conexin, para proporcionar garantas de calidad del servicio para la comunicacin de telefona y multimedia. Subcapa de convergencia especfica del servicio: su funcin es interactuar con la capa de red.

Capa fsica: La especificacin PHY WiMAX est compuesta por 3 secciones a saber: WirelessMAN-SC PHY WirelessMAN-SCa WirelessMAN-OFDM

Cada seccin es una variante del estndar segn las tcnicas de modulacin y banda de frecuencias para las cuales se ha desarrollado el mismo.

WirelessMAN-SC PHY Esta especificacin PHY destinada para operacin en la banda de frecuencia de 10-66 GHZ, est diseada con un alto grado de flexibilidad de manera de permitir a los proveedores de servicio la habilidad de optimizar los sistemas con respecto al planeamiento celular, costo, capacidades de radio, servicios y capacidad. A efectos de permitir el uso flexible del espectro, son soportadas las configuraciones TDD y FDD. Ambos casos usan el formato de transmisin burst cuyos mecanismos de framing soportan burst adaptativos en el cual los parmetros de transmisin, incluyendo los esquemas de modulacin y codificacin, pueden ser ajustados individualmente para cada SS (estacin de abonado) en la base de trama por trama. El caso FDD soporta SS fullduplex y tambin SS half-duplex, las cuales no transmiten y reciben simultneamente. El PHY uplink est basado en una combinacin de TDMA y DAMA; en particular el canal de uplink est dividido en un nmero de time slots asignados para usuarios (registracin, contencin o trfico de usuario) controlado por el MAC en el BS y puede variar a travs del tiempo para ptimo desempeo. El canal downlink es TDM con la informacin para cada SS multiplexada en un solo arreglo de datos y recibida por todas las SS dentro de un mismo sector. Para soportar half-duplex FDD en las SS, la provisin tambin es realizada por una porcin TDMA en el downlink. El PHY downlink incluye un sublayer de convergencia de transmisin que inserta un byte de puntero en la carga para ayudar al receptor a identificar el comienzo de la MAC PDU. Los bytes de datos provenientes del sublayer de convergencia de transmisin son aleatorizados, codificados con FEC y mapeados a QPSK, 16-QAM o constelacin de seal 64-QAM (opcional).

El PHY uplink est basado en la transmisin burst TDMA. Cada burst est diseado para transportar PDUs MAC de longitud variable. El transmisor aleatoriza los datos entrantes, los codifica en FEC, y mapea los bits codificados a QPSK, 16-QAM (opcional). WirelessMAN-SCa PHY El PHY WirelessMAN-SCa est basado en una tecnologa de portadora simple y diseado para operacin NLOS en bandas de frecuencias por debajo de 11 GHz. Para bandas licenciadas los anchos de banda de canal permitidos deben ser limitados por el ancho de banda regulado dividido por cualquier potencia de dos no menor que 1.25 MHz. Los elementos dentro del PHY incluyen: Definiciones TDD y FDD, una de las cuales debe ser soportada. Uplink TDMA. Downlink TD o TDMA. Modulacin adaptativa por bloque y codificacin FEC para uplink y downlink. Estructura de framing que mejora la ecualizacin y el rendimiento de estimacin de canal a travs de NLOS y ambientes de ensanchamiento de retardos extendidos. Granularidad en unidades PS en tamao de burst. FEC concatenado usando codificacin Reed-Solomon y TCM con interleaving opcional. Opciones adicionales BTC y CTC FEC. Opcin No-FEC usando control de error ARQ. Opcin de transmisin con diversidad STC (space time coding). Modos robustos para operacin de baja CINR. Seteo de parmetros de mensajes MAC/PHY que facilitan la implementacin opcional AAS. Dentro de la discusin del WirelessMAN-Sca PHY son usados cinco trminos para la organizacin de transmisiones (payload, burst set, burst frame, MAC frame). Payload se refiere al contenido de unidades individuales de transmisin que son inters de alguna entidad en el receptor. Burst contiene datos del payload y est formado acorde a las reglas especificadas por el perfil burst asociado con el burst. La existencia del burst es bien conocida por el receptor a travs del contenido de los mapas de uplink o downlink. Para el uplink es

una unidad completa de transmisin que incluye el prembulo del encabezado, la carga codificada y la secuencia de terminacin. El burst set es una entidad de transmisin autoconcatenada consistente de un prembulo, uno o ms burst concatenados y una secuencia de terminacin. Para el uplink el burst set es sinnimo de burst. El burst frame contiene toda la informacin incluida en una transmisin simple. Consiste de uno o ms burst set. Frame MAC se refiere a los intervalos de ancho de banda fijo reservados para el intercambio de datos. Para TDD, un frame MAC consiste de un subframe para el uplink y otro para el downlink, delimitados por el TTG. Para FDD el frame MAC corresponde a la mxima longitud de subframe de downlink. Los subframes del uplink FDD operan concurrentemente con los subframe del uplink pero en canales de frecuencias separadas. Cada subframe de uplink y downlink poseen un burst frame.

Especificacin WirelessMAN-OFDM PHY Basado en modulacin OFDM y diseado para operacin NLOS en las badas por debajo de los 11 GHz. La tecnologa WiMAX soluciona o mitiga los problemas resultantes de las condiciones NLOS (sin lnea visible). La tecnologa OFDM (Orthogonal Frequency Division Multiplexing) provee de un medio eficiente para superar los desafos de la propagacin NLOS. La forma de onda WiMAX OFDM ofrece la ventaja de posibilitar la operacin con un gran retardo de dispersin caracterstico de los ambientes NLOS. Mediante la virtud de los smbolos de tiempo OFDM y el uso de los prefijos cclicos, la onda OFDM elimina los problemas de la interferencia intersmbolo (ISI) y la complejidad de la ecualizacin adaptativa. Puesto que la seal OFDM est compuesta de mltiples portadoras ortogonales, el fading selectivo es localizado en subportadoras que son relativamente fciles de ecualizar. Un ejemplo es mostrado en la figura como una comparacin entre una seal OFDM y una seal de portadora simple, con la informacin siendo enviada en paralelo por OFDM y en serie por la portadora simple.

La habilidad de superar la dispersin de retardo, los multicaminos, y la ISI en una manera eficiente, permite tener mayores tasas de transferencias. Como ejemplo, es mucho ms sencillo ecualizar las portadoras individuales de OFDM que ecualizar una seal de portadora simple ms extensa.

En la figura se muestran Seales Recibidas OFDM y Portadora Simple. El rea de puntos representa el espectro transmitido. El rea slida es la entrada del receptor. Por todas estas razones los estndares internacionales recientes como aquellos fijados por el IEEE 802.16, ETSI BRAN y ETRI, han establecido el OFDM como tecnologa de eleccin preferida.

Capa MAC Una red que utiliza un medio compartido debe proveer un mecanismo eficiente de compartir. Las topologas PMP (Punto-Multipunto) y Mesh (Malla) de las redes inalmbricas son ejemplos de medios inalmbricos compartidos. Aqu el medio es el espacio a travs del cual se propaga una onda de radio. Aunque la especificacin MAC invoca los protocolos IP, ellos son requeridos solamente como base del estndar para manejo de elementos en lugar de operacin MAC.

Topologa Punto-Multipunto El downlink desde la estacin base (BS de ahora en mas) al usuario opera en la base PMP (punto-multipunto). El link inalmbrico IEEE 802.16 opera con BS central y una antena sectorizada la cual es capaz de manejar mltiples sectores independientes simultneamente. Dentro de un canal de frecuencia dada y un sector de antena, todas las estaciones reciben la misma transmisin o parte de la misma. La BS es el nico transmisor funcionando en esta direccin, de manera que transmite sin necesidad de coordinar con otras estaciones, excepto por la duplexin por divisin de tiempo que puede dividir en perodos de transmisin de uplink y downlink. El downlink es generalmente broadcast. Las estaciones de abonado (SS de ahora en mas) comparten el uplink hacia la BS bajo demanda. Dependiendo de la clase de servicio utilizada, la SS puede mantener los derechos de transmisin o el mismo puede ser garantizado por la BS luego de recibir el pedido por parte del usuario. Dentro de cada sector, los usuarios adhieren a un protocolo de transmisin que controla la contencin entre usuarios y faculta al servicio a ser acomodado a los requerimientos de ancho de banda y retardo de cada aplicacin de usuario. Esto est implementado usando garantas de ancho de banda no solicitados, interrogacin y procedimientos de contencin. Estos procedimientos son definidos en los protocolos para posibilitar a los proveedores optimizar el desempeo del sistema usando diferentes combinaciones de tcnicas de asignacin de ancho de banda mientras se mantienen definiciones de interoperabilidad consistentes. Por ejemplo, la contencin puede ser usada para evitar la interrogacin individual de estaciones abonado que han estado inactivas por un largo perodo de tiempo. El uso de la interrogacin simplifica la operacin de acceso y garantiza que aplicaciones reciban servicio de manera determinstica, si es requerido.

En general las aplicaciones de datos son tolerantes al retardo, pero las de tiempo real como video y voz requieren servicio de manera uniforme y a veces en un esquema muy rgido. El MAC es orientado a conexin. Para el propsito de mapeo de servicios en SSs y QoS variables de asociacin, todas las comunicaciones de datos estn en el contexto de conexin. El flujo de servicio puede ser provisionado cuando una SS es instalada en el sistema. Rpidamente luego de la registracin de la SS, las conexiones son asociadas con este flujo de servicio (una conexin por flujo de servicio) para proveer una referencia contra quien requiere el ancho de banda. Adicionalmente, pueden ser establecidas conexiones nuevas cuando un servicio de cliente necesite cambios. Una conexin define el mapeo entre el proceso de convergencia que utiliza el MAC y el flujo de servicio. El flujo de servicio define los parmetros de QoS que son ntercambiados en la conexin. El concepto de flujo de servicio en una conexin es central en la operacin del protocolo MAC. El flujo de servicio provee un mecanismo para el manejo de QoS del uplink y downlink. Una SS requiere ancho de banda uplink en la conexin. El ancho de banda es garantizado por la BS a la SS como un agregado de garantas en respuesta a requerimientos de conexin de SS. Una vez establecidas las conexiones, puede ser requerido mantenimiento activo. Los requerimientos de mantenimiento varan dependiendo del tipo de servicio conectado. Por ejemplo, un servicio T1 no canalizado, virtualmente no requiere servicio de mantenimiento dado que posee ancho de banda constante por cada frame. Los servicios T1 canalizados requieren algn mantenimiento debido al requerimiento dinmico (pero relativamente de variacin lenta) de ancho de banda, acoplado con el requerimiento de ancho de banda total disponible bajo demanda. Los servicios IP pueden requerir una cantidad sustancial de mantenimiento prolongado debido a su naturaleza bursty y debido a la alta posibilidad de fragmentacin. Finalmente, las conexiones pueden ser terminadas. Esto ocurre generalmente cuando un contrato de servicio a un usuario cambia. La terminacin de la conexin es estimulada por la BS o la SS. Estas tres funciones de manejo de conexiones son soportadas a travs del uso de configuraciones estticas y adiciones dinmicas, modificaciones y borrado de conexiones.

Bluetooth IEEE 802.15.1

3.1 La tecnologa Bluetooth. Bluetooth empieza a concebirse en Ericsson Mobile Communications AB (Suecia) en 1994 como el efecto colateral de un proyecto sobre enlaces de comunicadores mltiples conectados a la red celular mediante telfonos; cuatro aos ms tarde, aparece el grupo de inters en la tecnologa Bluetooth SIG (Special Interest Group) en el que aparecan Ericsson, Toshiba, IBM e Intel como empresas promotoras de la tecnologa; ms tarde se sumaron otros promotores como 3Com, Lucent, Microsoft y Motorola generndose el consorcio Bluetooth; actualmente el Bluetooth SIG cuenta con ms de 2000 empresas. El objetivo de este grupo es, fundamentalmente promover actividades relativas a mejorar la interoperabilidad de forma que con ello se favorezca el desarrollo del mercado Para tratar el tema de la interoperabilidad, en trminos nicamente de test bed, o sea, de mtrica/evaluacin de caractersticas tcnicas, se realizan los tests de productos Bluetooth mediante unos protocolos denominados Blue Units que se basan en kits de desarrollo producidos por la firma inglesa Cadence Symbionics Group parte de la firma estadounidense Cadence Design Systems a los que se puede acceder a travs de Ericsson Microelectronics AB (Suecia), AU System y Sigma ComTec. En estos momentos, para que un producto pueda considerarse como Bluetooth tiene que cumplir una serie de protocolos y perfiles; los protocolos describen cmo se realizan las tareas bsicas como sealizacin telefnica, gestin de enlace y lo que se conoce como Service Discovery, es decir, determinacin de qu servicios estn disponibles desde o travs de otros productos Bluetooth; los perfiles describen la forma en que diferentes protocolos y procedimientos bsicos funcionan conjuntamente en diferentes productos y aplicaciones Bluetooth: los perfiles estn considerados como la primera aproximacin en trminos de conseguir la interoperabilidad. Existen grupos de trabajo dentro del SIG Bluetooth que estn redactando perfiles para impresin, interfase usuario-equipo y posicionamiento (aplicaciones GPS). Adems, como un medio para tratar de acelerar el despegue del mercado, se ha creado recientemente el Bluetooth Measurement Initiative dentro del Bluetooth SIG cuyo objetivo es desarrollar hardware y software para el testing de interoperabilidad. Desde un punto de vista de tecnologa de transmisin, Bluetooth est basado en la tecnologa clsica del escenario inalmbrico conocida como spread spectrum (espectro esparcido), en concreto en frequency hopping (salto de frecuencia): estos sistemas de frequency hopping dividen la banda de frecuencia en varios canales de salto (hopping); en el transcurso de la conexin se produce una transicin brusca (salto o hopping) de un canal a otro de forma seudo aleatoria. Desde un punto de vista de arquitectura, Bluetooth se basa en el concepto de picored, un concepto genrico en las redes de rea personal que se refiere a la capacidad de varios equipos para configurarse como una red; de una forma ms estricta, la picored se puede definir como la red de corto alcance formada por dos o ms unidades o equipos que comparten un canal, es decir, que funcionan de forma sncrona y siguiendo al misma frecuencia de hopping. La picored se diferencia de otras redes similares de su entorno mediante la secuencia de frecuencia de hopping. Las picorredes se pueden enlazar de forma ad-hoc generando lo que se conoce como red de dispersin o scatternet: estas scatternets permiten que se pueda

producir la comunicacin entre configuraciones flexibles de forma continua; estas redes pueden actuar tambin como enlace inalmbrico a redes de datos ya existentes. El chip Bluetooth est formado por un transceiver de radio-frecuencia, una unidad de control de enlace banda-base conjuntamente con el software de gestin y un subsistema de antena; a los equipos que incluyen este chip y verifican las especificaciones Bluetooth se les conoce, en la literatura internacional, como productos Bluetooth enabled.

3.2 Arquitectura WPAN Bluetooth. 3.2.1 Vista de alto nivel. El estndar IEEE 802.15.1 presenta una WPAN que utiliza tecnologa inalmbrica Bluetooth. En este trabajo el trmino Blueooth WPAN o simplemente el trmino IEEE 802.15.1 WPAN se refiere a una WPAN que utiliza tecnologa Bluetooth inalmbrica.

3.3.1 Interconexin entre sistemas abiertos (OSI). Hay dos formas de ver cualquier diseo de sistemas de comunicacin; por su arquitectura y su funcionalidad. Un acercamiento hacia la arquitectura enfatiza las divisiones lgicas de un sistema y como son compatibles. El acercamiento hacia la funcionalidad hace nfasis en los componentes actuales y sus interconexiones. A continuacin se presenta una vista de la arquitectura de una WPAN (Figura 3.1). Se enfatiza la tradicional separacin de larga escala del sistema en dos partes; physical layer (PHY) del IEEE 802.15.1 y la subcapa MAC (medium access control) del DLL (data link layer). En la siguiente figura se muestra la pila del protocolo en la sptima capa del modelo del OSI en la tecnologa inalmbrica de Bluetooth y su relacin con este estndar. Como se puede observar en la siguiente figura las subcapas LLC (logical link control) y el MAC juntas abarcan las funciones deseadas para el DLL del modelo de OSI.

3.3.2 Vistazo a la red WPAN Bluetooth. La tecnologa inalmbrica de Bluetooth utiliza un radio de corto alcance que ha sido optimizado para el ahorro de energa, operacin adecuada de la batera, tamao pequeo y para ser utilizada en aparatos personales de bajo peso. Una WPAN es capaz de soportar canales sncronos de comunicacin para telefona de voz y canales de comunicacin asncronas para comunicacin de datos. Dichas facilidades permiten que una amplia gama de aplicaciones y de aparatos trabaje en una WPAN. Por ejemplo, un telfono celular puede usar canales circuitswitched para transportar audio desde y para un receptor en el encabezado mientras se encuentra utilizando un canal packet-switched para intercambiar datos con una computadora porttil. Una WPAN opera en la banda libre de los 2.4 GHz. Se utiliza un transceptor de fast frequency-hop (1600 hops/s) para evitar la interferencia y la cada de seales. Para reducir la complejidad del transceptor se utiliza la tcnica binaria FSK (frequency shift keying) para transmitir smbolos con un rango de 1 Smbolos/s. Se utiliza un canal ranurado, cada ranura de tiempo tiene una duracin de 625 s. Una trama rpida de TDD (time division duplex) se utiliza para permitir comunicaciones full duplex en capas superiores. En el canal, la informacin se intercambia a travs de paquetes. Cada paquete se transmite en una frecuencia diferente dentro de la secuencia de espera. Un paquete normalmente cubre una sola ranura, pero se puede extender de tres a cuatro ranuras. Para trfico de datos, de manera unidireccional es posible transmitir un mximo de 723.2 kb/s entre dos dispositivos. Un canal vi direccional soporta un trfico de voz entre dos

dispositivos con una velocidad de hasta 64 kb/s. La inestabilidad para el trfico de voz se mantiene bajo al usar ranuras de tiempo pequeas en la transmisin. La figura 3.2 muestra el formato general del contenido de una ranura de tiempo, trasmitida al aire en una WPAN de Bluetooth. El paquete abarca un cdigo de acceso de tamao fijo, el cual es utilizado, entre otras cosas, para distinguir una WPAN de otra. El encabezado del paquete de tamao fijo, que se utiliza para manejar la transmisin en una WPAN; y una carga de datos de tamao variable, que transporta informacin de capas superiores. Debido al tamao tan reducido de de estos paquetes, se necesita que una capa superior ms larga sea dividida en segmentos antes de que sea transmitida al aire.

Figura 3.2 - Trama de informacin.

3.4 Topologa de conexin de las WPAN Bluetooth. 3.4.1 Picoredes WPAN Bluetooth. Una picored es una WPAN formada por dispositivos Bluetooth que sirven como maestros en la picored y uno o ms dispositivos Bluetooth que sirven de esclavos. Un canal de frequency-hopping basado en la direccin del maestro define cada picored. Todos los elementos participantes en una comunicacin dentro de una picored dada son sincronizados al canal de frequency-hopping, utilizando el reloj del aparato maestro de la picored. Los dispositivos esclavos solo se comunican con el maestro en una estructura punto a punto bajo el control del maestro. Las transmisiones del maestro deben de ser ya sea de la forma punto a punto o bien

punto a multipunto. Cada lugar determina que si algunos elementos deben ser siempre maestros o esclavos. Sin embargo, este estndar no distingue entre elementos que son permanentemente maestros o esclavos. Durante una seccin de comunicacin un elemento esclavo puede comportarse como maestro en un momento dado y viceversa. 3.4.2 Redes dispersas WPAN Bluetooth. Una red dispersa (scatternet) es una coleccin de varias picoredes en operacin que se traslapan en tiempo y en espacio. Un aparato Bluetooth puede participar en mltiples picoredes al mismo tiempo, por lo que existe la posibilidad de que la informacin fluya ms all de las fronteras de una picored. Un aparato en una scatternet puede ser esclava en varias picoredes, pero puede ser maestra en solo una de ellas. La figura 3.3 muestra las diferentes formas en que los dispositivos Bluetooth se pueden interconectar para formar varios sistemas de comunicacin.

Figura 3.3 - Varios formatos en una picored. (a) Operacin con un solo esclavo. (b) Operacin multiesclavo; (c) Operacin tipo scatternet [1].

3.5 El protocolo Bluetooth de pila. La figura 3.4 muestra la pila del protocolo Bluetooth, la cual incluye los protocolos Bluetooth especficos (por ejemplo; Link Manager Protocol, LMP; Logical Link Control and Adaptation Protocol, L2CAP) y los protocolos bluethooth no especficos (tambin conocidos como los otros). Dichos protocolos no especficos incluyen al OBEX (Object Exchange Protcol), al PPP (point to point protocol), el WAP (wireless application protocol), y algunos ms. Cuando se diseo el protocolo se hizo pensando principalmente en optimizar la reutilizacin de los protocolos existentes. Este protocolo tambin reutiliza la ayuda para adaptar las aplicaciones existentes para trabajar con la tecnologa inalmbrica de

Bluetooth y asegurar una suave operacin y interoperabilidad de dichas aplicaciones. As, muchas aplicaciones ya desarrolladas por vendedores pueden tomar inmediatamente ventaja del hardware y el software de los sistemas que cumplen con las especificaciones para Bluetooth. Las especificaciones estn disponibles pblicamente y permiten el desarrollo de un gran nmero de nuevas aplicaciones que toman todas las ventajas de las capacidades de la tecnologa inalmbrica Bluetooth.

Figura 3.4 - El protocolo Bluetooth en una pila de capas .

La capa del LLC no es parte de las especificaciones Bluetooth. La figura 3.4 se pone con el fin de ensear la posicin en la que debe estar colocada con relacin al resto de las capas del protocolo. La capa de RFCOMM es un puerto serial de emulacin que permite heredar las aplicaciones sobre los links Bluetooth. Las TCS son capas de control de telefona y capas de sealizacin para aplicaciones avanzadas de telefona. La DSP es una capa de servicio que permite, a los dispositivos Bluetooth, pedir a otros dispositivos servicios que ellos pueden proveer. 3.6 Capa Fsica (PHY). La figura 3.5 indica la relacin entre el protocolo Bluetooth de pila y la PHY. La PHY es la primera de 7 capas del modelo OSI y es responsable de la transmisin de bits entre sistemas adyacentes sobre un canal areo. La descripcin de esta capa se limita a los siguientes puntos:

 Recepcin de una trama de bits de la subcapa MAC y la transmisin de una trama de bits va ondas de radio hacia una estacin asociada. Recepcin de ondas de radio de alguna estacin asociada y la conversin te estas a una trama de bits que se transmite hacia la MAC.

Figura 3.5 - Relacin de la PHY y su interfase .

3.7 Arreglo de bandas y canales en frecuencia. Los sistemas Bluetooth operan en la banda ISM (industrial, scientific, medical) de los 2.4 GHz. En la mayora de los pases alrededor del mundo, el rango de dichas frecuencias va de los 2400 MHz a los 2483.5 MHz. Sin embargo, en algunos pases, tienen limitaciones nacionales en ese rango de frecuencias. Para cumplir con dichas limitaciones internacionales, se han diseado algoritmos especiales de frequency-hopping para dichos pases. Se debe tener en cuenta que los productos que implementan reducciones de banda no trabajaran con los productos que implementan la banda completa de frecuencias. Los productos que implementan bandas reducidas de frecuencias deben, por lo tanto, considerarse como versiones locales para un solo tipo de mercado (ver tabla 3.1).

3.8 Caractersticas del transmisor. Los requerimientos en esta clusula especifican los niveles de energa en el conector de la antena del equipo. Si el equipo no tiene un conector, se asume una antena de referencia con una ganancia de 0 dB. Debido a que es complicado obtener una medida precisa en las mediciones en medidas de radiacin, se prefiere que los sistemas con una antena integrada tengan un conector temporal de antena durante las pruebas. Los equipos se dividen en tres clases de grupos dependiendo su nivel de potencia, dichos grupos se pueden apreciar en la tabla 3.2.

Tabla 3.2 - Tipos de energa.

A Energa B Lmite

mnima de salida en el ajuste mximo de energa. mnimo sugerido de energa Pmin < -30dBm.

Se requiere de control de energa para equipos que se encuentran en la clase 1. El control de energa se utiliza para limitar la transmisin de energa sobre los 0 dBm. Los controles de energa bajo los 0 dBm son opcionales y se pueden utilizar para optimizar el consumo de energa y reducir el total de interferencia. Los niveles de energa deben formar una secuencia montona con un nivel mximo de 8 dB y un mnimo de 2 dB. Los equipos que pertenecen a la clase 1que transmiten un mximo de energa de +20 dB deben de ser capaces de mantener la energa de transmisin por debajo de los 4 dBm. Equipos con capacidades de control de energa optimizan la salida de energa en un link con comandos LMP. Esto se hace al medir el RSSI (receiver signal strength indication) y reportar si se debe incrementar o disminuir el nivel de energa.

3.8.1 Caractersticas de modulacin. La modulacin es del tipo GFSK (Gaussian frequency shift keying) con un tiempo de ancho de banda (BT) = 0.5. El ndice de modulacin debe ser de entre 0.28 y 0.35. Un 1 binario se representa con una desviacin positiva de frecuencia, y un 0 binario se representa con una desviacin negativa de frecuencia. La sincronizacin de smbolo deber mejor que 20 ppm (ver figura 3.6). Para cada canal de transmisin, la desviacin mnima de frecuencia (Fmin = la menor de Fmin+,Fmin-) que corresponde a la secuencia 1010 debe de ser menor a 80% de la desviacin de frecuencia (fd) que corresponde a la secuencia 00001111. Adicionalmente, la desviacin mnima nunca debe de ser menor a 115 kHz. La transmisin de datos tiene una tasa de 1 Msmbolos/s.

Figura 3.6 Tipo de modulacin para la transmisin de datos.

El error de cruce por cero es la diferencia de tiempo entre el periodo ideal del smbolo y el tiempo de cruce real. Este debe de ser menor a 0.125 del periodo de un smbolo. La desviacin mxima de frecuencia debe de ser entre 140 kHz y 175 kHz. 3.8.2 Tolerancia de RF. La exactitud de la frecuencia central inicial (Fc) debe ser de 75 kHz como mximo para Fc. La exactitud de la frecuencia inicial se define como la exactitud de frecuencia antes de que cualquier informacin sea transmitida. La derivacin de frecuencia central se especifica en la tabla 3.3.

aLa

mxima derivacin de rango que se permite en cualquier paquete. 3.9 Caractersticas de recepcin. Para medir el desempeo de la tasa de errores de bit, el equipo debe tener algn medio de retroalimentacin. El equipo manda la informacin decodificada de regreso. El nivel de referencia de sensibilidad debe estar referido a 70 dBm. 3.9.1 Niveles actuales de sensitividad. Los niveles actuales de sensitividad se define como los niveles de entrada para los cuales el BER (bit error rate) se consideran de un 0.1%. Los requerimientos de un receptor Bluetooth es un nivel de sensibilidad de 70 dBm o mejor. El receptor debe de tener un nivel sensibilidad de 70dBm con cualquier transmisor Bluetooth. 3.9.2 Desempeo con interferencia. El desempeo con interferencia co-canal y adyacente a 1 MHz y un 2 MHz y se mide con la seal deseada a 10 dB sobre el nivel de referencia. En todas las dems frecuencias, la seal deseada debe ser de 3 dB sobre el nivel de sensibilidad de referencia. El BER debe de ser 0.1 %. 3.10 Emisiones falsas. Las emisiones falsas para un receptor Bluetooth no deben ser mayores a lo indicado en la tabla 3.4.

La energa se debe medir en un ancho de banda de 100 kHz. 3.11 Especificaciones de banda base. La figura 3.7 indica la relacin entre la pila del protocolo Bluetooth y esta clusula. Esta clusula describe las especificaciones del control de link que transporta los protocolos y las dems rutinas de menor nivel.

Figura 3.7 Relaciones e interfaces de la BB.

3.11.1 Descripcin General. Bluetooth es un enlace de radio de corto alcance que pretende remplazar conexiones por cable(s) de dispositivos electrnicos porttiles o fijos. Sus principales caractersticas son; baja complejidad, bajo consumo de energa, bajos costos adems de ser un dispositivo robusto.

Bluetooth opera en la banda libre ISM de los 2.4 GHz. Para evitar la interferencia y la perdida de informacin se utiliza un transmisor-receptor de frequency hop (salto de frecuencia). Para minimizar la complejidad del transceptor se utiliza una modulacin binaria de FM. La tasa de transferencia es de 1 Msymbol/s. Se aplica un canal ranurado con una duracin estndar de 625 s por cada slot (ranura) de tiempo. Para emular una transmisin full duplex, se utiliza una trama de TDD (time division duplex). En el canal, la informacin se intercambia por medio de paquetes. Bluetooth puede soportar un canal de datos asncronos, hasta tres canales de voz sncronos simultneamente, o un canal capaz de manejar simultneamente datos asncronos y voz sncrona. Cada canal de voz soporta 64 kb/s de datos sncronos (voz) en cada direccin. El canal asncrono puede soportar un mximo de 723.2 kb/s asimtricos o 433.9 kb/s. El sistema Bluetooth consiste de una unidad de radio, una unidad de control de link y una unidad de soporte para el manejo de las funciones y de la terminal de servico de la interfase (ver figura 3.8). Esta clusula describe las especificaciones del controlador de enlace Bluetooth, el cual transporta los protocolos de banda base y otras rutinas de bajo nivel.

Figura 3.8 Distintos bloques funcionales para un sistema Bluetooth.

Los sistemas Bluetooth proporcionan conexin punto a punto (solo se involucran dos unidades Bluetooth), o una conexin punto a multipunto (ver figura 3.9). En una conexin punto a multipunto, el canal se comparte entre varias unidades Bluetooth. Dos o ms unidades que comparten el mismo canal forman una picored. Un solo dispositivo Bluetooth trabaja como maestro de la picores, mientras que el(los) otro(s) trabajan como esclavos. Hasta siete esclavos pueden estar activos en una picored. Adems, muchos ms esclavos pueden estar conectados al dispositivo maestro en un estado inactivo o latente. Dichos esclavos latentes no se pueden estar activos en el canal, pero se mantienen sincronizados al maestro. Tanto para los esclavos activos como para los latentes, el canal de acceso es controlado por el maestro. Mltiples picoredes con reas de cobertura traslapada forman una red dispersa o una scatternet. Cada picored puede tener solamente un maestro. Sin embargo, los esclavos pueden participar en diferentes picoredes bajo una base de time-division multiplex. Adems, un maestro en una picored puede ser esclavo en otra picored. Las picoredes no deben de estar sincronizadas en frecuencia. Cada picored tiene su propio canal de salto.

Figura 3.9 Varias formaciones de picores: (a) Operacin con un solo esclavo; (b) Operacin Multiesclavo: (c) Operacin tipo scatternet [1].

3.12 El canal fsico. 3.12.1 Definicin de canal. El canal se representa por una secuencia aleatoria de salto a travs de 79 o 23 canales de RF. La secuencia de salto es nica para cada picored y es determinada por la direccin del dispositivo Bluetooth maestro. La fase en la secuencia de salto es determinada por el reloj del maestro Bluetooth. El canal se divide en rebanadas de tiempo mientras que cada rebanada corresponde a una frecuencia RF de salto. Consecuentemente cada salto corresponde una frecuencia diferente de RF. La tasa nominal de saltos es de 1600 saltos/s. Todas las unidades Bluetooth participantes en la picored estn sincronizadas en tiempo y salto dentro del canal. 3.12.2 Ranuras de tiempo. El canal se divide en ranuras de tiempo, cada una con una duracin de 625 s. Las ranuras de tiempo se numeran acorde al reloj del dispositivo maestro de las picores. La numeracin de las ranuras va de 0 a 227-1 y es ciclo con una longitud de ciclo de 227. Una secuencia TDD se utiliza para cuando transmite el maestro y el esclavo alternadamente (ver figura 3.10). El maestro debe iniciar su transmisin solo en una ranura numerada como par, y el esclavo debe de iniciar su transmisin en una ranura numerada como impar solamente. El paquete de inicio debe de estar alineado con el inicio de la ranura. Los paquetes de informacin deben de extenderse a lo mximo cinco ranuras de tiempo.

Figura 3.10 TDD y sus tiempos.

La frecuencia RF de salto debe de mantenerse fija durante la duracin del paquete. Para un solo paquete, la frecuencia de RF de salto a utilizarse se deriva del valor actual del reloj del dispositivo Bluetooth. Para un paquete con multiranura, la frecuencia de RF de salto a utilizarse para el paquete entero se deriva del reloj del dispositivo Bluetooth en la primera ranura del paquete. La frecuencia de salto en la primera ranura despus de un paquete de multi-ranuras debe de usar la frecuencia como lo determine el valor actual del reloj Bluetooth. La figura 3.11 ilustra la definicin de salto en una sola ranura y paquetes de multi-ranuras. Si un paquete ocupa ms de una ranura de tiempo, el salto de frecuencia que se aplica debe de ser la frecuencia de salto aplicada a la ranura de tiempo en donde se inici la transmisin de dicho paquete.

Figura 3.11 Paquetes multislot .

3.13 Links fsicos. Se pueden establecer diferentes tipos de conexin entre maestro y esclavo(s). Se han definido dos tipos diferentes de link: - Link sncrono de conexin orientada (SCO). - Link asncrono de conexin menor (ACL). El link SCO es un link punto a punto entre el maestro y un esclavo en la picored. El maestro mantiene el link SCO al usar las ranuras reservadas en intervalos regulares. El link ACL es un link punto a multipunto entre el maestro y todos los esclavos que participan en la picored. En las ranuras no representadas por los links SCO, el maestro puede soportar hasta 3 links SCO al mismo tiempo hacia el mismo esclavo o hacia otros. Un esclavo puede soportar hasta 3 links SCO del mismo maestro, o dos links SCO si los links se originan de diferentes maestros. Los paquetes SCO nunca son retransmitidos. 3.14 Paquetes. 3.14.1 Formato general. El orden los bits cuando se definen paquetes y mensajes, sigue el formato Little Endian, por ejemplo, las siguientes reglas se aplican: - El bit menos significante (LSB) corresponde a b0. - El LSB es el primer bit que se transmite. - En las ilustraciones, el LSB se muestra en la parte izquierda. Los datos en el canal de la picored se transportan en paquetes. El formato general de los paquetes se ilustra en la figura 3.12. Cada paquete consta de tres partes: el cdigo de acceso, el encabezado, y los datos tiles.

Figura 3.12 Estndar para el formato del paquete.

Tanto el cdigo de acceso como el encabezado son siempre de un tamao estndar: 72 bits y 54 bits respectivamente. Los datos tiles pueden variar de cero a un mximo de 2745 bits. Se han definido diferentes tipos de paquetes. Los paquetes pueden consistir de cdigos puros de acceso, el cdigo de encabezado as como el cdigo de acceso o puede contener los tres tipos de datos. 3.14.2 Cdigo de acceso. Cada paquete inicia con un cdigo de acceso. Si lo sigue un paquete de encabezado, el cdigo de acceso tiene 72 bits de informacin, de otra forma el cdigo de acceso tiene 68 bits de informacin. Este cdigo de informacin se utiliza para la sincronizacin, niveles de offset de compensacin y como identificacin. Los cdigos de acceso identifican todos los paquetes de intercambio

en el canal de la picored: todos los paquetes que se mandan en la picored son precedidos por el mismo cdigo de acceso al canal. En el receptor de la unidad Bluetooth, un correlator de desfase compara las fases respecto al cdigo de acceso y lo fija cuando detecta que se ha excedido el nivel de referencia. El cdigo de acceso tambin se utiliza para los procedimientos de voceo. En este caso, el mismo cdigo de acceso se utiliza como mensaje de sealizacin por lo que no es necesario mandar datos de encabezado o de informacin extra. El cdigo de acceso consiste en un prembulo, en una palabra de sincronizacin, o informacin de prueba; ver figura 3.13. Tanto el cdigo de acceso como el encabezado son siempre de un tamao estndar: 72 bits y 54 bits respectivamente. Los datos tiles pueden variar de cero a un mximo de 2745 bits. Se han definido diferentes tipos de paquetes. Los paquetes pueden consistir de cdigos puros de acceso, el cdigo de encabezado as como el cdigo de acceso o puede contener los tres tipos de datos. 3.14.2 Cdigo de acceso. Cada paquete inicia con un cdigo de acceso. Si lo sigue un paquete de encabezado, el cdigo de acceso tiene 72 bits de informacin, de otra forma el cdigo de acceso tiene 68 bits de informacin. Este cdigo de informacin se utiliza para la sincronizacin, niveles de offset de compensacin y como identificacin. Los cdigos de acceso identifican todos los paquetes de intercambio en el canal de la picored: todos los paquetes que se mandan en la picored son precedidos por el mismo cdigo de acceso al canal. En el receptor de la unidad Bluetooth, un correlator de desfase compara las fases respecto al cdigo de acceso y lo fija cuando detecta que se ha excedido el nivel de referencia. El cdigo de acceso tambin se utiliza para los procedimientos de voceo. En este caso, el mismo cdigo de acceso se utiliza como mensaje de sealizacin por lo que no es necesario mandar datos de encabezado o de informacin extra. El cdigo de acceso consiste en un prembulo, en una palabra de sincronizacin, o informacin de prueba; ver figura 3.13.

Figura 3.13 Formato del cdigo de acceso.

3.14.2.1 Tipos de cdigos de acceso. Existen tres tipos de cdigos de acceso: - Cdigo de acceso a canal (CAC). - Cdigo de acceso a dispositivos (DAC). - Cdigo de acceso a informacin (IAC). Cada cdigo de acceso se utiliza respectivamente para diferentes modos de operacin en las unidades Bluetooth. El cdigo de acceso a canal identifica a la

picored. Este cdigo se incluye en todos los paquetes de intercambio del canal de la picored. El cdigo de acceso al dispositivo se utiliza en procedimientos especiales de sealizacin, por ejemplo, para el voceo y como respuesta a dicho voceo. Para el cdigo de acceso a informacin existen dos variantes. Un cdigo general de acceso a informacin (GIAC) es comn a todos los dispositivos. El GIAC puede ser utilizado para ver que otras unidades Bluetooth estn en el rango. El cdigo de acceso dedicado a informacin (DIAC) es comn a para un grupo de unidades Bluetooth dedicadas que comparten algunas caractersticas. El DIAC se puede utilizar para descubrir solo aquellas unidades dedicadas en dicho rango. El CAC consiste en un prembulo, una palabra de sincrona y su longitud total es de 72 bits. Los diferentes tipos de cdigos de acceso utilizan diferentes tipos de LAPs (lower address Parts) para construir palabras de sincrona. En la tabla 3.5 se muestra un resumen de los diferentes tipos de cdigos de acceso.

3.14.2.2 Prembulo. El prembulo es un patrn fijo cero-uno de cuatro smbolos utilizados para facilitar compensaciones de DC. La secuencia puede ser 1010 o bien 0101, dependiendo de si el LSB (el bit menos significativo), de la siguiente palabra de sincronizacin es 1 o 0. El prembulo se muestra en la figura 3.14.

Figura 3.14 - Prembulo.

3.14.2.3 Palabra de sincrona. La palabra de sincrona es un cdigo de 64 bits derivado de una direccin de 24 bits (LAP); para el CAC se utiliza el LAP del maestro; para el GIAC y el DIAC, se utilizan LAPs dedicadas; para el DAC, se utiliza la unidad LAP esclava. Una buena correlacin entre las palabras de sincrona mejora los procesos de tiempo de sincronizacin. 3.14.2.4 Trailer. El trailer es adherido a la palabra de sincrona tan pronto como el encabezado del cdigo de acceso del paquete fluye. Este es el caso tpico del CAC, pero el trailer tambin se utiliza en el DAC y el IAC cuando estos cdigos se utilizan en paquetes FHS de intercambio durante procedimientos de respuesta e investigacin. El trailer se fija en un patrn de cero-uno de cuatro smbolos. El trailer junto con los tres MSBs de la palabra de sincronizacin forman un patrn de unos y ceros, que va alternando, el cual se usa para compensar extensiones de DC. La secuencia del trailer es 1010 o bien 0101 dependiendo del MSB de la palabra de sincrona es 0 o 1, respectivamente. El proceso anterior se ilustra en la figura 3.15.

Figura 3.15 Cdigo Trailer en CAC cuando la palabra de sincrona es 0 en el MSB (a), y cuando la palabra de sincronizacin es 1 en el MSB (b) .

3.14.3 Encabezado del paquete. El encabezado contiene informacin del link de control (LC) y consiste de seis campos. - AM_ADDR: 3 bits que direccional a los miembros activos. - TYPE: 4-bits de tipo de cdigo. - FLOW: 1 bit de control de flujo. - ARQN: 1 bit indicador de acknowledge. - SEQN: 1 bit de numero de secuencia. - HEC: 8 bits de deteccin de error. El encabezado total, que incluye el HEC, consiste de 18 bits, ver figura 3.16, y es codificada a un rango de 1/3, resultando en un encabezado de 54 bits. Note que los campos de AM_ADDR y TYPE son mandados con el primer LSB.

Figura 3.16 Formato del encabezado .

3.14.3.1 AM_ADDR. El AM_ADDR representa la direccin de un miembro y se utiliza para distinguir entre miembros activos y miembros participantes en la picored. En una picored, uno o ms esclavos estn conectados a un maestro. Para identificar a un esclavo por separado, cada esclavo es asignado temporalmente a una direccin de 3 bits para ser usada cuando se active. Todos los paquetes que se intercambian entre el maestro y el esclavo transportan el AM_ADDR del esclavo. La direccin de puros ceros es reservada para la transmisin de paquetes del maestro al esclavo, con excepcin del paquete de FHS que debe de usar todos los miembros de su direccin, sin embargo no es un mensaje de transmisin. 3.14.3.2 Type. Se pueden distinguir 16 tipos diferentes de paquetes. El cdigo TYPE de 4-bits especifica que tipo de paquete se utiliza. Es importante notar que la interpretacin de los cdigos TYPE depende del link fsico asociados con el paquete. Primero, se debe de determinar hacia donde se manda el paquete, a un link SCO o a un link ACL. Despus se puede determinar que tipo de paquete SCO o ACL se ha recibido. El cdigo TYPE tambin revela cuantas ranuras ocupar el paquete. 3.14.3.3 Flow. Este bit se utiliza para el control de paquetes sobre el link ACL. Cuando el buffer de RX para el link ACL en el recipiente esta lleno, se regresa una seal de alto (FLOW=0) para parar la transmisin de datos. Note que la seal de STOP solo contiene paquetes ACL. Los paquetes que solo contienen informacin (ID, POLL, y paquetes NULL) o paquetes SCO pueden seguir recibindose. Cuando el buffer de RX esta vaco, se manda una seal GO (FLOW = 1). Cuando no se reciben paquetes, o cuando hay un error en el encabezado, se asume una seal de GO. En este caso, el esclavo puede recibir un paquete nuevo con un CRC a travs de su buffer de RX aunque no este vaco. El esclavo debe de regresar un acknowledgment negativo (NAK) en respuesta a este paquete aunque el paquete pase la revisin del CRC.

3.14.3.4 ARQN. El indicador de acknowledgment de 1-bit ARQN se utiliza para informar de una fuente que ha trasmitido exitosamente con un CRC, y puede ser un acknowledge positivo ACK o uno negativo NAK. Si la recepcin fue exitosa, se regresa un ACK (ARQN = 1), de lo contrario se regresa un NAK (ARQN = 0). Cuando no se recibe ningn mensaje de respuesta, se asume un NAK. De la misma manera un NAK es la respuesta que se tiene por defaul. El ARQN va en el encabezado del paquete de respuesta. El xito de la recepcin se checa en trminos del cdigo de chequeo de redundancia cclica. 3.14.3.5 SEQN. El bit SEQN proporciona una trama secuencial de datos para ordenar los datos del paquete. Para cada nueva transmisin de paquetes que contengan datos con CRC, el SEQN bit es invertido. Se requiere que se filtren los datos de la retrasmisin en el receptor; si una retrasmisin ocurre por una falla del ACK, el destino recibe el mismo paquete dos veces. Por comparacin del SEQN de paquetes consecutivos, se puede descartar las retrasmisiones por informacin correcta en la recepcin. 3.14.3.6 HEC. Cada encabezado tiene un HEC (header-error-check) que checa la integridad del encabezado. El HEC consiste de una palabra de 8-bits generada por el polinomio 647 (representacin octal). Antes de generar el HEC, el generador HEC se inicializa con un valor de 8-bits. Despus de la inicializacin, un HEC es calculado para los 10 bits de encabezado. Antes de revisar el HEC, el receptor debe de inicializar el circuito de revisin con el UAP apropiado de 8-bits. Si el HEC no concuerda, el paquete entero es desechado. 3.14.4 Tipos de paquetes. Los paquetes usados en las picores estn relacionados con los links fsicos en los que se utilizan. En el estndar IEEE 802.15.1 se han definido dos links fsicos: el link SCO y el ACL. Para cada uno de estos links, se definen 12 tipos de paquetes diferentes. Cuatro paquetes de control son comunes a todos los tipos de links: su cdigo TYPE es nico e independiente de cada tipo de link. Para indicar los diferentes tipos de paquetes en un link, se utiliza el cdigo TYPE de 4-bits. El paquete se ha dividido en cuatro segmentos. El primer segmento est reservado para los cuatro paquetes de control comunes a todos los tipos de links fsicos; los cuatro tipos de paquetes. El segundo segmento est reservado para los paquetes que solo ocupan una sola ranura; se han definido seis de estos tipos. El tercer segmento se reserva para paquetes que ocupan tres ranuras, se han definido dos tipos de estos paquetes. El cuarto segmento est reservado para paquetes que ocupan cinco ranuras de tiempo y de estos se han identificado dos tipos de paquetes. La ocupacin de segmentemos se refleja en la segmentacin y se

puede derivar directamente del tipo de cdigo. La tabla 3.6 resume los paquetes definidos por la SCO y los diferentes tipos de link ACL.

Tabla 3.6 Paquetes definidos por el SCO y links para el ACL .

3.15 Correccin de errores. Hay tres tipos de correccin de error definidos para Bluetooth. - FEC a una tasa de 1/3. - FEC a una tasa de 2/3. - Esquema ARQ para datos. El propsito del esquema FEC en los datos de carga til es reducir el nmero de retransmisiones. Sin embargo, en un ambiente ms o menos libre de errores, los FEC proporcionan demasiada informacin que reduce la velocidad del procesamiento. Los encabezados de los paquetes siempre se protegen por un FEC a un rango de 1/3; este contiene informacin importante de link y debe ser capaz de manejar ms errores de bit.

3.16 Canales Lgicos. En el sistema Bluetooth, se han definido cinco canales lgicos: - Canal de control LC. - Canal de control LM. - Canal de usuario UA. - Canal de usuario UI. - Canal de usuario US. Los canales de control LC y LM son usados en a nivel de link de control y de manejo respectivamente. Los canales de usuario UA, UI, y US, son usados para transportar datos asncronos, iscronos e informacin sincronizada respectivamente. El canal LC se lleva en el encabezado del paquete; los dems canales van en el paquete de la carga de datos. El LM, UA, y el canal UI se indican en el campo de L_CH del encabezado de los datos del usuario. El canal US va sobre el link SCO solamente. Los canales UA y el UI van normalmente sobre el link ACL; sin embargo, tambin pueden ir sobre los datos en el paquete DV del link SCO. El canal LM puede ir sobre el link ACL o sobre el SCO. 3.16.1 Canal LC (link de control). El canal LS se encuentra dentro del encabezado del paquete. Este canal lleva informacin del link de control de bajo nivel como ARQ, control de flujo, y caracterizacin de la carga til de datos. El canal LC va en cada paquete a excepcin del paquete ID que no tiene encabezado de paquete. 3.16.2 Canal LM (link de manejo). El canal de control LM transporta informacin de control que se intercambia entre el link de administracin del maestro y los esclavos. , el canal LM utiliza paquetes protegido DM. El canal LM se indica por el cdigo L_CH en el encabezado de la informacin del usuario. Para indicar continuidad los paquetes utilizan el cdigo 01 L_CH. Si no hay fragmentacin, todos los paquetes utilizan el cdigo de inicio 10. El canal de datos iscronos trabaja midiendo el tiempo de los paquetes de inicio. Al nivel de banda base, el uso del cdigo L_CH es el mismo que el canal UA. 3.16.3 Canal US (datos sncronos de usuario). El canal US lleva datos transparentes sncronos del usuario. Este canal va sobre el link SCO. 3.16.4 Localizacin del canal. El canal LC se localiza en el encabezado del paquete. Los dems paquetes se localizan en la carga til de informacin del usuario. Los canales US solo pueden estar dentro de los paquetes SCO. Los dems paquetes estn localizados en los paquetes ACL o en tambin en el paquete SCO DV. Los canales LM, UA, y UI, pueden interrumpir el canal US si contiene informacin de mayor prioridad.

3.17 Datos de blanqueo (whitening). Antes de la transmisin, el encabezado y la carga son mezclados con datos whitening, logrando datos con muchos parmetros de redundancia y reduciendo los paquetes con de DC. 3.18 Rutina de TX. La rutina de TX va separada de cada link ACL y de cada link SCO. La figura 3.17 muestra los buffers ACL y SCO de la forma en que se utilizan en la rutina de TX. En esta figura, solo se muestran un buffer de TX ACL y un solo buffer de TX SCO. En el dispositivo maestro, hay un buffer de TX ACL separado del esclavo. Adems debe de haber uno o ms buffers de TX SCO por cada esclavo SCO (diferentes links SCO pueden ya sea reutilizar el mismo buffer de TX SCO, o cada uno tener su propio buffer de TX SCO). Cada buffer de TX consiste de dos registros FIFO: un registro al que puede leer y tener acceso por el controlador Bluetooth para poder componer los paquetes, y otro registro que puede ser ledo por el link Bluetooth de manejo para leer informacin nueva. La posicin de los interruptores S1 y S2 determinan que registro es el actual y cual es el prximo. Los interruptores son controlados por el controlador de link Bluetooth. Los interruptores en la entrada y a la salida de los registros FIFO nunca pueden ser conectados al mismo registro simultneamente.

Figura 3.17 Diagrama funcional del buffer de TX .

3.18.2 Rutina de RX. La rutina de RX va separa del link ACL y el link SCO. Sin embargo, en contraste con el buffer ACL maestro de TX, un solo buffer de RX es compartido entre todos

los esclavos. Para el buffer SCO, depende en como los diferentes links SCO son distinguidos cuando se requieren extra buffers SCO o no. La figura 3.18 muestra los buffers ACL y SCO de la forma en que se utilizan en la rutina de RX. El buffer ACL de RX consiste de dos registros FIFO: un registro que puede ser ledo por el link Bluetooth de control con la carga til del ltimo paquete RX, y otro registro al que puede tener acceso el link Bluetooth de control para leer la carga anterior de datos tiles. El buffer SCO de RX tambin consiste de dos registros FIFO: un registro que se llena con informacin de voz nueva y recin llegada, y otro registro que puede ser ledo por la unidad procesadora de voz.

Figura 3.18 Diagrama funcional del buffer de RX .

Dado que el indicador TYPE en el encabezado del paquete recibido indica si la informacin son datos y/o voz, el de-composer de paquetes puede dirigir automticamente el flujo de informacin hacia buffer apropiados. El interruptor S1 cambia cada vez que el link de manejo ha ledo el registro anterior. Si la siguiente carga de informacin llega antes de que el registro de RX este vaco, una seal de STOP se debe de incluir en el prximo encabezado paquete que es regresado. El indicador de STOP se quita tan pronto como el registro de RX esta vaco. 3.18.3 Control de flujo. Dado que el buffer de RX ACL puede estar lleno mientras una nueva carga llega, se requiere un control de flujo. Como fue mencionado anteriormente, el campo de FLOW correspondiente al encabezado puede utilizar comandos STOP o GO para detener o reanudar el flujo de los datos transmitidos. 3.18.4 Proceso de trama de bits (Bitstream).

Antes de que la informacin se mande sobre la interfase area, se realizan algunas manipulaciones de bit en el transmisor para incrementar confiabilidad y seguridad. Al encabezado del paquete se le agrega un HEC, los bits del encabezado son mezclados con una palabra de whitening, y se le aplica cdigos FEC. En el receptor, ser realaza el proceso contrario. La figura 3.19 muestra el proceso que se lleva a cabo en el transmisor y el receptor.

Figura 3.19 Proceso de TX y RX de los bits de encabezado.

Para la carga til de informacin, se realiza un proceso similar. Dependiendo del tipo de paquete, es el proceso que lleva la informacin. La figura 3.20 muestra el proceso que tiene la informacin del usuario. Adems del proceso al que es sometido la carga que contiene informacin del encabezado, la carga til de informacin puede ser sometida a un proceso de encriptacin. Solo el proceso de whitening es obligatorio para cada carga de informacin del usuario; los dems procesos son opcionales y dependen del tipo de paquete. La figura 3.20, ilustra los procesos opcionales con lneas punteadas.

Figura 3.20 Proceso de TX y RX de los bits de la carga de informacin.

3.19 Canal de control. A continuacin se describe como se establece el canal de una picored y como se pueden agregar y salir unidades a la picored.

3.19.1 Definicin maestro-esclavo. El canal en la picored se caracteriza enteramente por el maestro de la picored. La direccin del dispositivo Bluetooth (BD_ADDR) determina la secuencia de salto FH y el cdigo de acceso al canal; el reloj del sistema del dispositivo maestro determina la fase en la secuencia de salto y determina los tiempos. Adems el maestro, controla el trfico en el canal. Por definicin, el maestro es representado por la unidad Bluetooth que inicia la conexin (a una o ms unidades esclavas). Note que los nombres maestro y esclavo solo son referidas as en el protocolo del canal: las unidades por si mismas son idnticas; por lo que, cualquier unidad puede volverse maestra o esclava de la picored. Una vez que la picored se ha establecido, los roles de maestro-esclavo se pueden intercambiar. 3.19.2 Reloj Bluetooth. Cada unidad Bluetooth tiene un sistema interno de reloj que determina el tiempo y la secuencia de salto del transmisor-receptor. El reloj del dispositivo Bluetooth se deriva de un reloj que corre libre que nunca se ajusta y que nunca se apaga. Para sincronizarse con otras unidades, solo se utilizan offsets que al ser agregados al reloj nativo proporcionen relojes temporales Bluetooth que son mutuamente sincronizados. Se debe tener en cuenta que los relojes Bluetooth no tienen relacin con la hora y el da; por lo que pueden ser inicializados en cualquier valor. El reloj Bluetooth proporciona los latidos del corazn del transmisor-receptor Bluetooth. Su resolucin es de al menos la mitad de la longitud de la ranura del TX o RX, o de 312.5 s. El reloj tiene un ciclo de alrededor de un da. Si el reloj se implementa con un contador, se requiere de uno de 28-bit. El tiempo y la frecuencia de salto en el canal de una picored se determina por el reloj del dispositivo Bluetooth maestro. Cuando se establece la picored, el reloj maestro se comunica a los esclavos. Cada esclavo agrega un offset a su propio reloj para sincronizarse con el reloj maestro. Dado que los relojes corren libremente, los offsets deben de ser actualizados regularmente. El reloj determina periodos crticos y sujeta los eventos en el receptor Bluetooth. Existen cuatro periodos importantes en el sistema Bluetooth: 312.5 s, 625 s, 1.25 ms, y 1.28 s; estos periodos corresponden a los tiempos de bits CLK0, CLK1, CLK12, respectivamente (ver figura 3.21).

Figura 3.21 Reloj Bluetooth .

En los diferentes modos y estados de una unidad Bluetooth, su reloj puede tener diferentes apariencias: CLKN , el reloj nativo. CLKE, reloj estimado. CLK, reloj maestro. CLKN es el reloj nativo que corre libremente y es la referencia de las otras formas en las que aparece el reloj. CLKE y CLK se derivan del CLKN de referencia al agregarse un offset. CLKE se aproxima al reloj del recipiente. CLK es el reloj del dispositivo maestro de la picored. Se utiliza para todas las actividades de sincronizacin. Todos los dispositivos Bluetooth utilizan el CLK para sincronizar sus transmisiones y recepciones. El CLK se deriva del reloj nativo CLKN al agregarle un offset (ver figura 3.22). El offset es cero para el dispositivo maestro dado que CLK es idntico a su reloj nativo. Cada esclavo agrega un offset apropiado a su CLKN. As el CLK de los esclavos corresponde al CLKN del maestro.

Figura 3.22. Derivacin de un CLK maestro (a) y en esclavo (b) .

3.19.3 Estados observados. La figura 3.23 ilustra los diferentes estados utilizados en el control de link Bluetooth. Existen dos estados principales: STANDBY y CONNECTION; adems, existen siete suvestados, page, page scan, inquiry, inquiry scan, master response, slave response, y inquiry response. Las sub-estados son estados intermedios que se utilizan para agregar esclavos a la picored. Para moverse de un estado a otro, se utilizan ya sea comandos del link administrador Bluetooth, o seales internas en el link de control.

Figura 3.23 Diagrama de estados Bluetooth .

3.19.4 Estado de Standby. El estado de standby es el estado que tienen por default las unidades Bluetooth. En dicho estado, la unidad Bluetooth esta en un estado de bajo consumo de energa. Solo su propio reloj se encuentra corriendo hasta que ocurra una seal de cambio. El controlador puede dejar el estado de STANDBY para buscar seales de voceo, o para vocear el mismo. Cuando responde a un mensaje de voceo, la unidad no regresa al estado de STANDBY sino entra al estado de CONNECTION como esclavo. Cuando transmite exitosamente un voceo, la unidad entrar al estado de CONNECTION como unidad maestra. 3.19.5 Redes dispersas. Es posible que mltiples redes cubran la misma rea. Dado que cada picored tiene diferente maestro, las picoredes brincan independientemente, cada una con su propia secuencia de salto de canal y de fase de la forma en que cada maestro lo determine. Adems, los paquetes trasportados en cada canal son precedidos por diferentes cdigos de acceso a canal determinados por la direccin del dispositivo maestro. En la forma en que ms picoredes se agregan, la probabilidad de colisiones se incrementa; por lo que se produce una degradacin gradual del

desempeo de estos sistemas. Si muchas picoredes cubren una misma rea, una unidad puede participar en dos o ms picoredes al aplicar la tcnica de multiplexado. Para participar en el canal apropiado, debe de usar la direccin del maestro asociado a dicha red y dar un offset adecuado al reloj para obtener la fase correspondiente. Una unidad Bluetooth puede actuar como esclavo en varias picoredes, pero solo como maestro en una picored: dado que dos picoredes con el mismo maestro son sincronizadas por el mismo elemento utilizan la misma secuencia de salto, son una misma picored. Un grupo de picoredes en las que las conexiones estn dadas entre diferentes picoredes reciben el nombre de redes dispersas (scatternet). Un maestro o un esclavo puede volverse un esclavo en otra picored al ser voceado por el maestro de la otra picored. Como la unidad de voceo siempre inicia fuera del dispositivo maestro, se requiere un rol de intercambio maestro-esclavo si se desea que algn dispositivo maestro acte como esclavo. El multiplexado en el tiempo debe de usarse para conmutar entre picoredes. En caso de usar solamente links ACL, una unidad puede solicitar entrar a una picored en modo hold o park durante un tiempo en el que debe de unirse a otra picored al solo hacer un cambio de parmetros. Dado que los relojes de dos dispositivos maestros no estn sincronizados, un esclavo que participa en dos picoredes tiene que tener dos offsets agregados a su propio reloj. Como los dos relojes maestros corren independientes, es necesario actualizar los offsets para que la unidad esclava se mantenga sincronizada con los dos maestros. 3.20 Intercambio Maestro-Esclavo. Hay varias situaciones en las que se desea un cambio maestro-esclavo (MS). Primero, un cambio MS es necesario cuando alguna unidad vocea al maestro de una picored existente y quiere unirse a dicha picored, dado que por definicin, la unidad voceadora (o paging unit) inicialmente es maestra de la picores pequea que solo comprende al pager (maestro) y al paged (esclavo). Segundo, cuando un esclavo en una picored existente quiere iniciar una nueva picored en la que esta sea el dispositivo maestro y la picored maestra en la que se encuentra como esclava. El caso tardo implica un rol doble del maestro original de la picored; este se vuelve esclavo en la nueva picored mientras se sigue manteniendo como dispositivo maestro en la picored original. Tercero, un ejemplo mucho mas complicado es cuando un esclavo quiere tomar completamente una picored existente. Por ejemplo, el cambio tambin implica la transferencia de otros esclavos de la picored existente a la nueva picored. 3.20.1 Manejo de energa. 3.20.1.1 Manejo de paquetes. Para minimizar el consumo de energa, el la informacin en los paquetes se minimiza tanto en la TX y en la RX. Esto significa que si solo se necesita intercambiar informacin del link de control, se utilizarn paquetes NULL. No se realiza ningn tipo de intercambio de informacin si no existe un link de control o si

existe un comando NAK (los comandos NAK implican que no hay respuesta). Si se necesita mandar datos, la longitud de la carga se adapta para solo mandar los datos de bytes que son validos. En el lado del receptor, el procesamiento de los paquetes se lleva acabo en diferentes etapas. Si se encuentra un cdigo de acceso no valido en la ventana de bsqueda, el transmisorreceptor regresa al estado latente o dormido. Si se encuentra un cdigo de acceso, la unidad receptora se despierta y comienza a procesar el encabezado. Si existe una falla en el HEC, l anidad regresara al modo latente despus de haber procesado el encabezado. Un encabezado indica si sigue informacin til y cuantas ranuras de tiempo tiene. 3.20.1.2 Ocupacin de la ranura. Como se indico anteriormente, el tipo de paquete indica cuantas ranuras ocupa un paquete. Un esclavo al que no se haga referencia en el primer slot puede ir al estado latente durante el resto de los slots que ocupe el paquete. Esto lo puede leer del cdigo TYPE. 3.20.1.3 Supervisin de link. Una conexin puede fallar por varias razones, por ejemplo, cuando un dispositivo se mueve fuera del rango o cuando hay condiciones de falla de energa. Dado que lo anterior puede pasar sin previo aviso, es importante monitorear el link tanto el maestro como en el esclavo para evitar posibles colisiones cuando el AM_ADDR es reasignado a otro esclavo. Para ser capaces de supervisar perdidas de link, tanto el maestro como el esclavo utilizan supervisores de link por contadores de tiempo. Sobre la recepcin de un paquete que pasa el chequeo HEC y tiene el AM_ADDR correcto, el contador es iniciado. Si en cualquier momento en el estado de conexin se alcanza los niveles de supervisin llamados supervisionTO, la conexin se reinicia. El mismo valor se utiliza para las conexiones SCO y ACL. El periodo supervisin, supervisionTO, se determina en los niveles de LM. Este valor es seleccionado de tal manera que el tiempo de supervisin sea ms lago que el periodo de conexin. Los links de supervisin de un esclavo esttico se realizan al mover y sujetar el estado esttico a dicho elemento esclavo. 3.21 Seleccin de salto. En total se definen diez tipos diferentes de secuencias de salto: cinco para los sistemas 79-hop y cinco para los sistemas 23-hop, estas secuencias son como sigue: Una secuencia de salto con 32 frecuencias nicas distribuidas equitativamente sobre 79 MHz, con un periodo de 32. Una secuencia de respuesta que cubre 32 frecuencias nicas que se encuentran a una correspondencia de uno a uno a la secuencia de salto. El maestro y el esclavo utilizan diferentes reglas para obtener la misma secuencia.

 Una secuencia para buscar informacin con 32 frecuencias nicas para despertar unidades dormidas distribuidas equitativamente sobre los 79 MHz, con un periodo de 32. Una secuencia de respuesta a la seal de bsqueda que cubre 32 frecuencias nicas de respuesta que se encuentran en correspondencia uno a uno a la secuencia de salto. Un canal de secuencia de saltos que tiene un periodo muy largo, que no muestra parmetros repetitivos sobre un intervalo de tiempo pequeo, pero que distribuye las frecuencias de salto de manera equitativa sobre 79 MHz. Para la secuencia de salto, es importante que podamos cambiar fcilmente la fase hacia delante o hacia atrs, por lo que necesitamos un mapeo 1-1 de un contador hacia las frecuencias de salto. Para cada caso, es necesario una secuencia de salto del maestro hacia el esclavo y del esclavo hacia el maestro. 3.21.1 Esquema general de seleccin. El esquema de seleccin consiste de dos partes: Seleccin de una secuencia. Localizar dicha secuencia en las frecuencias de salto. El diagrama general en bloque de la seleccin de salto se muestra en la figura 3.24. La localizacin de la entrada hacia un salto particular de frecuencia se realiza en la caja de seleccin. Bsicamente, la entrada es el reloj nativo y la direccin actual. En estado de CONNECTION, el reloj nativo (CLKN) es modificado por un offset para igualar al reloj maestro (CLK). Solo el MSBs 27 del reloj se utiliza. En los subastados de pgina y de investigacin, todos los 28 bits del reloj se utilizan. Sin embargo, en el subastado de pgina el reloj nativo se modificara para que el maestro estime a la unidad esclava. La direccin de entrada consiste de 28 bits, por ejemplo, la totalidad del LAP y los cuatro LSBs de una UAP. En el estado CONNECTION, se utiliza la direccin del maestro. Cuando esta en el subastado inquiry, correspondiente al GIAC se utiliza el UAP/LAP. La salida constituye una secuencia seudo aleatoria, ya sea cubriendo 79 saltos o 23, dependiendo en del estado en el que se encuentre.

Figura 3.24 Diagrama general de bloque de una seleccin de salto.

Para el sistema de salto 79, el esquema de seleccin selecciona un segmento de 32 saltos en frecuencia ocupando 64 MHz haciendo tres saltos una vez en un orden aleatorio. Despus un segmento diferente de 32 saltos se escoge. En caso de una pagina, se busca una, o un sub-estado de pagina. En un estado de conexin la salida constituye una secuencia seudo aleatoria que se desliza sobre 79 o 23 saltos, dependiendo del sistema seleccionado de salto. Para sistemas 23hop, el tamao del segmento es de 16. Dicho principio es representado en la figura 3.25.

Figura 3.25 Diagrama general en bloque de un esquema de seleccin de salto.

3.22 Audio Bluetooth. Sobre la interfase area Bluetooth, se utiliza un formato PCM de 64 kb/s, o un CVSD (Continuous Variable Slope Delta Modulation) tambin de 64 kb/s. Posteriormente se aplica un formato de modulacin delta de compresin silbica. El cdigo de voz en la interfase de lnea debe tener una calidad igual o mejor que la calidad que proporciona el cdigo PCM a 64 k/b/s. La tabla 3.7 resume los esquemas de voz que soporta la interfase area. El cdigo apropiado de voz se selecciona despus de se realizan las negociaciones entre los links de manejo.

Tabla 3.7- Esquema del cdigo de voz soportados por la interfase area .

3.22.1 Cdigo PCM de registro. Dado que los canales de voz en la interfase area soportan tramas de 64 kb/s, se puede utilizar un cdigo de registro PCM para transmisin de trfico. Se puede aplicar una compresin tipo A-law o -law. En el caso en que la interfase del usuario utilice una compresin tipo A-law y el usuario una -law y viceversa, se utiliza una conversin Alaw a -law. Los mtodos de compresin utilizan las recomendaciones G.711 de la ITUT. 3.22.2 Cdigo CVSD. Un formato ms robusto sobre la interfase de voz es la modulacin delta. Este esquema de modulacin sigue la forma de la onda conforme la seal aumenta o disminuye su valor. La entrada al codificador CVSD es de 64 kmuestras/s de cdigo PCM linear. En las figuras 3.26, 3.27, 3.28 se muestran los diagramas de bloques del codificador CVSD y del decodificador CVSD.

Figura 3.26 - Diagrama a bloques de un codificador CVSD comparacin silbica .

Figura 3.27 - Diagrama a bloques para un decodificador con compresor silbico .

Figura 3.28 - Procedimiento de acumulacin .

En donde b(k ) representa el codificador CVSD, el acumulador por y (k), y la duracin del pulso por (k). Adems, h representa el factor de acumulacin de
atenuacin, b representa el factor de atenuacin del pulso de entrada y representa el parmetro de comparacin silbica.

3.22.3 Calidad de audio para CVSD.

Para tener una calidad de audio apropiada es necesario que las 64 kmuestras/s de cdigo PCM de la seal de entrada tengan una densidad espectral despreciable alrededor de los 4 kHz. Un punto de referencia para las seales de entrada se debe de codificar en el transmisor y mandarse a un decodificador de referencia. La densidad de energa espectral en la banda de los 4 - 32 kHz de la seal decodificada de salida, debe de estar por debajo del rango mximo unos 20 dB en el rango que va de 0 a 4 kHz.

3.23 Protocolo para el administrador de enlace (Link Manager).

Figura 3.29 Relacin de la interfase para el LM .

La figura 3.29 muestra la relacin entre la pila del protocolo Bluetooth con esta clusula. Esta clusula describe el protocolo de manejo de link o Link Manager (LMP) el cual se utiliza para controlar el link. Las seales son interpretadas y

filtradas por el Link Manager en el receptor y no son propagadas hacia capas superiores. 3.23.1 General. Los mensajes del LMP se utilizan para saber el estado del link, por seguridad y para el control del mismo. Dichos mensajes son transmitidos en la informacin del usuario en vez de ser transmitidos por el L2CAP (Logical Link Control and Adaptation
Protocol) y son distinguidos por un valor reservado en el campo de L_CH del encabezado de los datos del usuario. Los mensajes son filtrados e interpretados por el LM en el receptor y no se mandan a capas superiores como se ilustra en la figura 3.30.

Figura 3.30 Lugar del LM en la escena global.

Los mensajes del Link Manager tienen ms prioridad que los datos del usuario. Esto significa que si el Link Manager necesita mandar mensajes, no deben ser retrasados el trfico del L2CAP, aunque puede ser retrasado por algunas retransmisiones de paquetes de informacin individual de la banda base.

3.23.2 Formato del LMP. LM PDUs siempre se manda en paquetes de un solo spot, y el encabezado de la informacin de la informacin tiene que ser de 1 byte. Los dos bits menos significativos en el encabezado de la informacin determinan el canal lgico. Para el LM PDUs esos bits se determinan de la forma en que se especifica en la tabla 3.8:

El bit FLOW en el encabezado de la carga siempre es uno y es ignorado en el receptor. Cada PDU (protocol data unit) tiene asignado un cdigo de 7 bits. El ID de transaccin es posicionada en el LSB. El opcode y el bit de ID de transaccin se localizan en el primer byte del cuerpo de la informacin. (ver figura 3.31).

Figura 3.31 Cuerpo de la carga con se manda un LM PDUs.

3.23.3 Establecimiento de conexin. Despus del procedimiento de paging (voceo), el dispositivo maestro debe de seguir al esclavo con un intervalo mximo de seguimiento. Los procedimientos determinados en el LMP para solicitar compensaciones de reloj, versiones del LMP, caractersticas y servicios soportadas y solicitud de nombres. Cuando el dispositivo de voceo desea crear una conexin que envuelve capas alrededor del LM, este manda LMP_host_connection_req. Cuando la contra parte recibe este mensaje, el host es informado sobre la prxima conexin. El dispositivo remoto puede aceptar o rechazar la solicitud de conexin al mandar el LMP_accepted o el LMP_no_accepted. Alternativamente, si el esclavo necesita un cambio maestro-esclavo, este manda el LMP_slot_pffset y el LMP_switch_req despus de que halla recibido el LMP_host_connextion_req. Cuando el cambio maestro-esclavo se ha realizado exitosamente, el antiguo esclavo responder con un mensaje de LMP_accepted o con un LMP_not_accepted. La figura 3.32 resume las transacciones del LMP para el establecimiento de una conexin siguiendo el procedimiento de voceo de banda base.

Figura 3.32 Establecimiento de conexin .

3.23.4 Manejo de errores. Si el Link Manager recibe un PDU con un cdigo desconocido, este responde con el LMP_not_accepted con el mensaje de cdigo desconocido LMP PDU. Si el Link Manager recibe un PDU con parmetros invlidos, este responde con el LMP_not_accepted, con el mensaje de cdigo con parmetros LMP no vlidos. Mensajes LMP errneos pueden ser causados por errores en el canal o debido a errores sistemticos en la parte de transmisin. Para detectar el ltimo caso, el LM debe de monitorear el nmero de mensajes errneos y desconectar si este excede el umbral, el cual depende de la implementacin. 3.24 Control del enlace lgico y el protocolo de adaptacin. La figura 3.33 indica la relacin entre las capas del protocolo Bluetooth con esta clusula. Esta clusula describe el control del enlace lgico y el protocolo de adaptacin (L2CAP). Este protocolo soporta protocolos de ms niveles de multiplexado, segmentacin de paquetes, y reensamble. Este describe el protocolo para definir el estado de los dispositivos, formato de los paquetes y composicin de los mismos.

Figura 3.33 L2CAP relaciones e interfaces .

Esta seccin define el control del enlace lgico y protocolo de adaptacin, referido como L2CAP. L2CAP se encuentra sobre el protocolo de banda base y reside en la capa de enlace de datos como se muestra en la figura 3.34. L2CAP proporciona conexin orientada y servicios de desconexin de datos de servicios de capas superiores. L2CAP permite transmitir y recibir a las capas superiores y aplicaciones. Los paquetes de datos del L2CAP tienen una longitud de 64 kbytes.

Figura 3.34 L2CAP en la capa de protocolos .

3.24.1 Operacin general. El L2CAP se basa en el concepto de canales. Cada uno de los puntos finales de los canales del L2CAP se define como el identificador de canales. 3.24.2 identificador de canales. Los identificadores de canales (CIDs) son nombres locales que representan canales lgicos de tipo end-point en el dispositivo. Identificadores del 0x0001 al 0x003F son reservados para funciones especficas del L2CAP. El identificador nulo (0x000) esta definido como un identificador ilegal y nunca se debe de usar como un destino final. Las implementaciones son libres de manejar el resto de los CIDs en la manera que mejor trabaje en una implementacin en particular, con la condicin de que el mismos CID no se reutilice como canal local L2CAP de punto final para mltiples y simultneos canales L2CAP entre un dispositivo local y alguno remoto. La tabla 3.9 resume las definiciones y la participacin del nombre del espacio CID.

La asignacin de CID es relativa a un dispositivo en particular. Un dispositivo puede asignar CIDs independientemente de otros dispositivos (a menos que este necesite utilizar cualquiera de los reservados CIDs mostrados en la tabla 3.9). As, aun si el mismo valor CID ha sido asignado a un canal remoto por medio de varios dispositivos remotos conectados al un solo dispositivo local, el dispositivo local puede seguir asociado nicamente con cada CID remoto en un dispositivo diferente. 3.24.3 Operacin entre dispositivos. La figura 3.35 ilustra el uso de CIDs en una comunicacin entre entidades correspondientes a un L2CAP en dispositivos separados. Los datos de conexin

orientada de canales de datos representan una conexin entre dos dispositivos, en donde un CID identifica cada punto final de un canal. Los canales sin conexin, restringen el flujo de datos a una sola direccin. Dichos canales se utilizan para soportar un grupo de canales en donde un CID en la fuente representa uno o ms dispositivos remotos. Tambin hay un nmero de CIDs reservados para propsitos especiales. El canal de sealizacin es un ejemplo de canal reservado. Este canal se utiliza para crear y estabilizar conexiones orientadas en canales de datos y a negociar canales. Es esencial el soporte de un canal de sealizacin con una entidad L2CAP. Tambin se reserva un CID para todas las conexiones de entrada para datos de trfico. En el siguiente ejemplo, un CID es utilizado para representar un grupo que consiste del dispositivo #3 y #4. El trfico se manda del canal ID y es directo al canal remoto reservado para conexiones de trfico de datos.

Figura 3.35 Canales entre dispositivos .

3.24.3.1 Operacin entre capas. Las implementaciones de L2CAP deben de seguir la arquitectura general descrita en la figura 3.36. Las implementaciones L2CAP deben de transferir datos entre capas superiores del protocolo y capas inferiores. Cada implementacin debe tambin de soportar un nmero de comandos de sealizacin. Las implementaciones L2CAP deben de estar preparadas para aceptar ciertos tipos de eventos de capas inferiores y generar eventos en capas superiores. La forma en que estos eventos pasan entre las capas es un proceso que depende de la implementacin.

Figura 3.36 Arquitectura L2CAP.

3.24.3.2 Segmentacin y reensamble. Las operaciones de SAR se utilizan para mejorar la eficiencia al permitir un mximo de transferencias de unidades (MUT), ms largas que los paquetes de banda base. Esto reduce los encabezados al separar la red y transportar paquetes utilizados por capas superiores del protocolo sobre algunos paquetes de banda base. Todos los paquetes de L2CAP deben de segmentarse sobre la banda base de paquetes. El protocolo no realiza ninguna segmentacin ni procesos de reensamble pero el formato de los paquetes permite la adaptacin a frames ms pequeos. Una implementacin L2CAP expone un MTU de salida y segmenta capas superiores de paquetes en pedazos que pueden pasar por el Link Manager va el HCI. En el lado del receptor, una implementacin L2CAP recibe pedazos del HCI y reensambla aquellos pedazos dentro de paquetes L2CAP utilizado informacin proveniente del HCI y forma encabezados de paquetes (ver figura 3.37).

Figura 3.37 Variables L2CAP SAR .

La segmentacin y el reensamble es implementado utilizando encabezados muy pequeos en paquetes de banda base. Los dos bits de L_CH definidos en el primer byte de banda base de informacin payload (tambin llamado el encabezado de frame) se utilizan para sealar el inicio y continuacin de paquetes L2CAP. L_CH debe de ser 10 (por definicin del estndar) para la primera segmentacin en un paquete L2CAP y 01 para un segmento de continuacin. En la figura 3.38 se muestra el uso del SAR.

3.24.3.3 Procedimientos de segmentacin. La unidad mxima de transmisin (MUT) para el L2CAP se exportar usando una implementacin especfica para el servicio de la interfase. Es responsabilidad de la capa superior limitar el tamao de los paquetes enviados a la capa L2CAP debajo del lmite del MTU. Una implementacin L2CAP segmentar el paquete dentro de las unidades de datos del protocolo (PDUs) para mandarlas a las capas inferiores. Si el L2CAP corre directamente sobre la banda base del protocolo, una implementacin debe de segmentar el paquete dentro de la banda base de paquetes para ser transmitidos al aire. Si L2CAP corre bajo la interfase del controlador (que es lo ms comn), una implementacin debe de mandar dedazos de informacin de un mismo tamao hacia el controlador del host en donde estos se convertirn en paquetes de banda base. Todos los segmentos del L2CAP asociados con un paquete L2CAP debe de ser pasados a travs de la banda base antes de cualquier otro paquete L2CAP destinado a la misma unidad se mande. 3.24.3.4 Procedimientos de reensamble. El protocolo de banda base entrega paquetes ACL en secuencia y protege la integridad de los datos utilizando un CRC de 16 bits. La banda base tambin soporta conexiones confiables al utilizar mecanismos ARQ (automatic repeat request). Cuando el controlador de banda base recibe paquetes ACL, este puede sealar a la capa L2CAP la llegada de cada paquete de banda base, o bien acumular un nmero de paquetes antes de que el buffer del receptor se llene.

Las implementaciones L2CAP deben de usar el total de la longitud del campo del encabezado de los paquetes L2CAP, sino los paquetes L2CAP que no concuerden con la longitud del campo sern descartados. La figura 3.39 ilustra el uso de las operaciones de segmentacin y reensamble para transmitir un PDU a una capa superior.

Figura 3.39 Dispositivos de segmentacin y reensamble en una unidad con un HCI.

El L2CAP tiene una base para sus paquetes de informacin que fluye sobre un modelo de comunicacin basado en canales. Un canal representa un flujo de datos entre entidades L2CAP en dispositivos remotos. Los canales deben de tener conexiones orientadas o ser desconectadas. As el L2CAP es uno de dos protocolos de enlace de diferentes niveles que funcionan sobre la banda base. L2CAP es responsable de los protocolos de multiplexado de nivel superior, abstraccin de MTU, manejo de grupo, y de transmitir la calidad de servicios de informacin hacia el enlace de nivel. El protocolo puede soportar el multiplexado al definir canales. Cada canal est limitado a un protocolo en un modo de muchos a uno. Se puede limitar mltiples canales al mismo protocolo, pero un canal no se puede limitar a mltiples protocolos. Cada paquete L2CAP recibido en un canal se manda directamente hacia un nivel superior apropiado del protocolo.

El grupo de administracin proporciona la abstraccin de un grupo de unidades permitiendo un mapeo ms eficiente entre grupos y miembros de una picored con dispositivos Bluetooth. L2CAP converge informacin del QoS entre canales y proporciona algn control de admisin para prevenir que otros canales adicionales violen los niveles de Qos existentes. 3.25 Interfase de control. La figura 3.40 indica la relacin del protocolo Bluetooth con esta clusula. Esta clusula describe las especificaciones para la funcionalidad de la interfase de control para el IEEE Std 802.15.1. Esta se basa en la seccin de HCI de las especificaciones Bluetooth. El trmino interfase de Control se eligi para hacer claro el origen del material.

Figura 3.40 Relacin de la interfase de control .

3.25.1 Introduccin IEEE. El HCI (host controller interface) proporciona un comando de interfaz hacia el controlador de banda base y al link manager, y acceso al estatus del hardware y al control del registro. Esta interfaz proporciona un mtodo uniforme de acceso a la banda base Bluetooth. La seccin de HCI tiene dos funciones en la especificacin Bluetooth. 1. Define las bases para una interfaz fsica con un modulo externo Bluetooth.

2. Define las funciones necesarias de control para todas las implementaciones Bluetooth. El Host recibe notificaciones asncronas de eventos HCI independientemente de la capa de transporte de control que se utilice. Los eventos HCI se utilizan para notificar al Host cuando algo ocurre. Cuando el Host descubre que ha ocurrido algn evento, ste analizar el paquete de evento o accin recibido para determinar que evento ocurri. 3.25.2 Los commandos HCI (Host Cotroller interface). El HCI proporciona un mtodo uniforme de comandos para el acceso a las capacidades del hardware Bluetooth. Los comandos de enlace del HCI proporcionan un servidor con la habilidad de controlar las conexiones de las capas de enlace hacia otros dispositivos Bluetooth. Dichos comandos tpicamente envuelven al LM para el intercambio de comandos LMP con dispositivos Bluetooth remotos. Los comandos HCI polica son utilizados para modificar el comportamiento del LM local o remoto. Dichos comandos proporcionan al servidor, mtodos para influenciar la manera en que el LM maneja la picored. El controlador del servidor y de banda base, los comandos de informacin y de estado proporcionan al servidor acceso a varios registros del controlador del servidor. Los comandos HCI tardan diversos tiempos para que se transmitan completamente. Por lo tanto, el resultado de los comandos se reportarn de regreso con el servidor en la forma de un evento. Por ejemplo, para la mayora de los comandos el controlador del servidor generar los cdigos que indiquen que un comando ha sido completado correctamente. Este evento contiene los parmetros de regreso para que un comando HCI sea completado. Para habilitar a los servidores la capacidad de detectar errores en la capa de transporte HCI, es necesario que halla un tiempo fuera o muerto entre la transmisin del los comandos del servidor y la recepcin del controlador del servidor. Dado que el tiempo mximo que puede estar fuera la transmisin, esta est fuertemente ligada a la capa de transporte del HCI utilizada y por lo tanto es recomendable usar un valor predeterminado de 1s. La cantidad de tiempo tambin es dependiente del nmero de comandos que no han sido procesados. 3.25.2.1 Intercambio de informacin especfica de HCI. La capa del controlador de trasporte del servidor proporciona un intercambio transparente de informacin especfica del HCI. Estos mecanismos de transporte permiten al servidor mandar comandos HCI, datos ACL y datos SCO al controlador del servidor. Dichos mecanismos de transporte tambin le permiten al servidor recibir eventos HCI, datos ACL y datos SCO del controlador del servidor. 3.26 Punto de acceso a interfaces de servicios. La figura 3.41 indica la relacin del protocolo de pila Bluetooth con esta clusula. Esta clusula describe, las funciones, caractersticas, servicios e interfaces SAP

entre el MAC y las subcapas LLC dentro de la capa de enlace de datos del ISO/IEC 8802 protocolo LAN (IEEE. 802.2). La subcapa LLC constituye la subcapa ms alta en la capa en la capa del enlace de datos (ver figura 3.42) y es comn a varios medios mtodos de acceso que son definidos y soportados por las actividades del ISO/IEC 8802.

Figura 3.41 Relacin entre el Punto de Acceso a Servicios .

A continuacin se describirn los siguientes conceptos, tiles en esta clusula: a) Capa de enlace de datos (Data link layer): Es la capa conceptual de control o de procesado lgico existente en la estructura jerrquica de una estacin que es responsable de mantener el control del enlace de datos. La capa de las funciones de enlace de datos proporciona una interfaz entre la estacin lgica de capas superiores y en enlace a datos. Dichas funciones incluyen un campo de interpretacin entre la direccin y el control, el canal de acceso y los comandos, envos e interpretacin. b) Subcapa LLC: Se define como la parte de la estacin de datos que soporta el control de enlaces lgicos de uno o ms enlaces lgicos. El LLC genera comandos PDUs para transmitirlos e interpreta los comandos PDUs recibidos. Algunas de las responsabilidades asignadas a un LLC son las siguientes: 1. Inicializacin del intercambio de seales de control. 2. Organizacin del flujo de datos. 3. Interpretacin de comandos PDUs recientes y generacin de respuestas apropiadas a dichos comandos PDUs. 4. Tomar acciones respecto al control de errores y recuperacin de funciones en la subcapa LLC. c) Subcapa MAC: La parte de una estacin de datos en la que residen las funciones MAC que se encuentran debajo de la subcapa LLC. Los procedimientos

del MAC incluyen fragmentacin y unin de las unidades de datos, realizar revisiones de error. d) Subcapa de especificaciones de servicios del LLC hacia la subcapa MAC: las especificaciones de servicio hacia la subcapa MAC proporcionan una descripcin de los servicios que requiere la subcapa LLC de la subcapa MAC. Estos servicios estn definidos para ser independientes a la metodologa del acceso a medios y de la naturaleza del medio en si. Todas las especificaciones antedichas estn dadas en su forma primitiva que representan en una forma abstracta el intercambio lgico de informacin y el control entre la subcapa LLC y la funcin identificada (la subcapa MAC). e) Tipo de operacin: Se define como un tipo de operacin de control de enlace de datos (DLC). La operacin de control tipo 1 proporciona una forma de desconexin a travs de un enlace de datos con un protocolo simple. Este tipo de operacin resulta til cuando las capas superiores proporcionan algn tipo de secuencia o esencia de recuperacin para que dichas capas no necesiten replegarse en la capa de enlace de datos. Adems este tipo de operacin puede ser til en aplicaciones en donde no sea necesario garantizar la entrega de cada unidad de datos de la capa de enlace de datos. f) Clases de operacin: Es alguna clase de operacin del LLC. La clase I de LLCs soporta nicamente operaciones de tipo 1. Los servicios de la clase 1 deben de ser aplicables de forma individual, grupal, global y para aplicaciones que no requieran procedimientos de control de procedimientos. 3.26.1 Subcapa LLC de especificaciones de servicios.

En general, los servicios de una capa (o subcapa) son las capacidades que esta ofrece a un usuario en la siguiente capa superior (o subcapa). Para lograr este servicio, una capa (o subcapa) basa sus funciones en los servicios que sta requiere de la capa (o subcapa) inferior inmediata (ver figura 3.43).

Figura 3.43. Primicias de servicio.

Los servicios se especifican cuando se describe la informacin que fluye entre el usuario N y la capa N (o subcapa). Dicho flujo de informacin se modela con eventos discretos e instantneos que llevan a cabo un servicio. Cada evento consiste en hacer pasar un servicio primario de una capa (o subcapa) a otra por una capa N (o subcapa) de acceso a servicios asociado a un usuario N. Los servicios se especifican al describir los servicios primarios y parmetros que caracterizan cada servicio. Un servicio puede tener uno o ms servicios primarios que constituyen la activacin que es relacionada a un servicio. Cada servicio primario puede tener ninguno o ms parmetros de transporte de informacin requerida para proporcionar un servicio. Los comandos se clasifican en cuatro tipos generales: a) Solicitud: La solicitud primaria o primitiva se pasa del usuario N hacia la capa N (o subcapa) para solicitar que se inicie un servicio. b) Indicacin: El indicador primitivo se pasa de la capa N (o subcapa) al usuario N para que inicie un evento interno en la capa N (o subcapa) el cual es importante para el usuario N. Dicho evento est relacionado lgicamente a una solicitud de servicio remoto o debe ser causado por un elemento interno de la capa N (o subcapa. c) Respuesta: La respuesta primario o primitiva es transmitida del usuario N a la capa (o subcapa) N para completar un procedimiento previamente iniciado por in indicador primitivo. d) Confirmacin: La confirmacin primitiva es transmitida de la capa N (o subcapa, segn sea el caso) hacia el usuario N para transportar los resultados del servicio(s) previamente solicitado(s). 3.26.2 Interfaces Bluetooth. La figura 3.44 ilustra los eventos y acciones realizadas por una implantacin de la capa L2CAP. El cliente y el SAPs del servidor simplemente representan el inicio de la solicitud y la aceptacin de la misma, respectivamente. Un cliente al nivel de aplicacin puede ya sea iniciar o aceptar solicitudes. La convencin de nombres es como sigue. La interfaz entre dos capas (interfaz vertical) utiliza el prefijo la capa inferior que ofrece el servicio hacia la capa superior. La interfaz entre dos entidades de la misma capa (interfaz horizontal) utiliza el prefijo del protocolo (agregando una P a la capa de identificacin). Los eventos que provienen del entorno se denominan solicitudes (Req), y sus correspondientes respuestas son llamadas confirmaciones (Cfm). Los eventos que vienen por debajo son llamados indicaciones (ind), y sus respuestas correspondientes son llamadas respuestas (Rsp). Respuestas que requieran procesamiento futuro son llamadas pendientes (Pnd). La notacin de las confirmaciones y de las respuestas toman contestaciones positivas. Contestaciones negativas se denotan con un sufijo Neg.

Figura 3.44 Acciones y eventos L2CAP.

Mientras que por cada accin de solicitud hay una correspondiente confirmacin (para el caso de aceptar la solicitud o una respuesta de negacin para el caso de peticiones rechazadas), las indicaciones no siempre tienen respuesta. Esto sucede especialmente si las indicaciones son simplemente informacin sobre eventos locales. 3.26.3 Relacin entre entidades con protocolo Bluetooth con construcciones IEEE 802. La figura 3.45 muestra el mapa del concepto del protocolo IEEE 802 hacia componentes Bluetooth descritos en este documento. Como se puede apreciar la PHY esta compuesta por la parte de RF y de la banda base. El MAC contiene al L2CAP y al resto la banda base. Las funciones de manejo de la PHY, como la sincronizacin y generacin de varias secuencias de frecuencia, estn incorporadas a la banda base.

Figura 3.45 - Mapa del concepto del protocolo IEEE 802 hacia componentes Bluetooth.

Referencias:

http://catarina.udlap.mx/u_dl_a/tales/documentos/lem/archundia_p_fm/capitulo3.pd f