Página 21 - Coordinación de Servicios de Información

CÜMUNICACtOt-l BLUETOOTH PARA SEf~SORES UnUZADOS EI~ APUCACIONES DE CONTROL DE TRAFICO
paquete, se debe instruir al CM para establecer
una conexión con un dispositivo de destino.
Los intentos para establecer la conexión, por
parte del CM, pueden ser exitosos o no y, por lo
tanto, alguna contingencia debe llevarse a cabo
para reintentar la reconexión o indicar la razón del
fallo. Durante el proceso, se ti enen que determinar
las características de la conexión, es decir, el juego
de servicios múlimo y la configuración necesaria
según las especificaciones de la Tabla n. El curso
normal de "solicitudes" y "respuestas" del CM
permitirán el establecimiento de una conexión se–
gura con las características deseadas.
El proceso de conexión está constituido por va–
rios estados y la conexión pasará a uno u otro es–
tado de acuerdo a la verificación de ciertas condi–
ciones. La Fig. 13 ilustra el esquema de los estados
del proceso de conexión.
Los estados por los cuales pasa el proceso de
conexión son:
a) I/licio (starting). En este estado se inicializa
al CM. Éste no es parte de la pila del protocolo
Bluetooth. Es una librería aparte y de u so opcio–
nal. Como no es una parte esencial del sistema,
no se inicializa automáticamente (a diferencia
de la pila del protocolo que se inicializa auto–
máticamente para asegurar que corre apropia–
damente). Por lo tanto, si se quiere utilizar el
CM, es necesario inicializarlo y abrirlo envián–
dole ciertos mensajes .
b) 11Iiciar conex ión (connectillg). En el siguien–
te estado se define el rol del nodo. Es necesa–
rio enviar mensajes al CM que indiquen que el
nodo se conecta como un maestro ("master")
o como un esclavo ("slave"). El proceso puede
Inicio
(Starting)
Activo
(Active)
Begin() Iniciar conexión
(Connecting)
Búsqueda
(Inquiring)
Fig. 13. Esquema de los eslados del proceso de conexión de la
pila BlueStack.
20
permanecer en este estado mientras el rol no se
haya definido.
c) BúsqJ~eda (inqlliring). La aplicación tiene
que realizar una búsqueda de los dispositivos
en su vecindad para poder obtener información
del otro nodo. Los mensajes de búsqueda que
envía la aplicación terminan, si la búsqueda ha
sido exitosa, en la recepción de un paquete FHS'
por parte del nodo remoto con información útil
para el nodo buscador. Se permanece en este
estado hasta que se define a qué dispositivo se
hará la conexión.
d) Activo (active). En este estado se logra la
comunicación y se permanece en él mientras no
ocurra una condición donde el proceso tenga
que abandon¡rrlo (i.e . el nodo remoto ha aban–
donado la conexión, una falla momentánea de
la alimentación, etc.).
Los cambios de estado dependen de las condi–
ciones en las cuales se intenta desarrollar la co–
nexión. Por ejemplo, si la conexión se interrumpe,
pero se conoce la información del nodo remoto,
se pasa al estado "iniciar conexión" y se regresa
directamente al estado "activo"; si, por alguna
razón, se pierde la conexión y existen nuevos
dispositivos en la vecindad, se hace una nueva
búsqueda y se pasa al estado activo de nuevo.
Bajo el modelo de la Fig. 12, es la aplicación la
que tiene que generar los mensajes al CM para ter–
minar en el estado "activo" de la conexión. Desde el
punto de vista de la programación de los sistemas
embebidos, la aplicación es una "TAREA" que
genera mensajes al CM el cual, a su vez, es otra
"TAREA" que comunica estos mensajes conve–
nientemente a las capas inferiores del BlueStack.
El CM se trata como la Tarea O ("Task O") en el
entorno de la programación del sistema embebi–
do (CASlRA + BlueCore) y es un número de tarea
reservado. La aplicación también tiene un núme–
ro de tarea reservado en este entorno: es la tarea 1
· 8 Un paquete FHS ("Frequency Hop Synchronisation ") contiene
toda la información que una aplicación necesita para crear una
conexión con un nodo remoto. Por ejemplo, en este paquete se
recibe la información de fa clase de dispositivo del nodo que se ha
encontrado [15, p. 13].