Este documento describe un sistema para controlar las desconexiones en dispositivos móviles con Windows CE mientras se visualizan páginas web. Se desarrolló un módulo llamado GDL que monitorea el estado de la conexión y determina si el dispositivo está conectado o desconectado basado en la eficiencia de las peticiones a un proxy. El sistema almacena páginas web localmente para que puedan visualizarse aún cuando el dispositivo esté desconectado. El GDL tuvo una eficiencia del 70% en las prue

1. Control de Desconexiones Visualizando Páginas Web en
Dispositivos Móviles Windows CE
Juan Carlos Olivares Rojas1
, Juan Gabriel González Serna1,2
,
Azucena Montes Rendón.1
y Víctor Jesús Sosa Sosa1
1
Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet)
Cuernavaca, Morelos, México
2
Centro de Investigación en Computación (CIC-IPN), México, D.F.
{jcolivares04c, gabriel, amr y vjsosa}@cenidet.edu.mx
RESUMEN
Este artículo muestra la forma en que se
debe de controlar las desconexiones en
dispositivos móviles con sistema operativo
Windows CE (Pocket PC, Smartphone),
mientras se está trabajando en aplicaciones
de red orientadas a conexión, como es el
caso de la visualización de páginas en la
Web.
El objetivo de este proyecto es tener “La
Web a un tap (punteo) de distancia” por parte
de los usuarios. Todo esto conlleva al control
de las desconexiones que se presentan en un
ambiente altamente móvil (redes inalámbricas
con WiFI y/o Bluetooth).
Palabras clave: Desconexión, Bluetooth,
Pocket PC, Redes Inalámbricas, Smartphone,
WiFi, Windows CE.
I INTRODUCCIÓN
El sueño de acceder a la información en
cualquier momento, en todo lugar y a través
de cualquier medio, está siendo posible
gracias a la aparición de los dispositivos
móviles; dichos dispositivos están
popularizándose debido a dos grandes
factores: la miniaturización de componentes y
el uso de redes inalámbricas.
Actualmente, los dispositivos móviles y
más específicamente los dispositivos PDAs,
han dejado de ser simples “jugetes
electrónicos” para convertirse en verdaderas
plataformas de cómputo.
La movilidad es el atractivo principal de
esta clase de dispositivos, la cual también se
convierte en su principal desventaja. Dicha
movilidad se ha logrado en gran medida con
el empleo de redes inalámbricas como WiFi y
Bluetooth. Debido a las características del
medio físico de transmisión (ondas de radio),
la transmisión en esta clase de redes
presenta consideraciones no previstas en
esquemas tradicionales de redes; dichas
consideraciones se reflejan en
desconexiones/reconexiones por parte de los
clientes.
La mayoría de los protocolos y
aplicaciones disponibles a través de una red,
necesitan de enlaces confiables y
persistentes que en una red inalámbrica no
están disponibles; tal es el caso de la Web, la
cual es orientada a conexión (recordar que
HTTP está basado en TCP y éste es un
protocolo orientado a conexión) y si no
existen las condiciones idóneas, los recursos
no pueden ser visualizados por los clientes.
II DESCONEXIONES
Por desconexión se entiende la condición
que se presenta cuando un equipo móvil es
incapaz de comunicarse con algunos o todos
los puntos de la red.
A pesar del gran auge que han tenido las
redes inalámbricas, aun siguen presentando
una gran desventaja: son menos confiables
que su contraparte cableada. De acuerdo con
[1] se estima la tasa de error de las redes
cableadas es de una magnitud de 10
-10
por
10
-4
de su contraparte inalámbrica, lo que
propicia que de cada megabit transmitido, un
kilobit será erróneo.

2. Los principales eventos que producen una
desconexión según [2] son los siguientes:
1. El nodo se ha movido
2. Se presenta un traspaso de célula
3. Se ha añadido o removido un
dispositivo adaptador de red.
4. La calidad de la señal de radio se ha
deteriorado.
5. La batería está perdiendo capacidad.
6. Se ha detectado una nueva red.
7. Se ha detectado una variación en el
ancho de banda.
Los eventos de desconexión entre otros
factores, ocasionan que las redes
inalámbricas presenten menor ancho de
banda, menor desempeño, poca confiabilidad
y mínima seguridad; en conclusión, presentan
menos garantías de calidad de servicio (QoS)
que las redes de infraestructura cableada, lo
cual es crítico en muchas aplicaciones como
por ejemplo sistemas basados en la Web o
sistemas multimedia. Actualmente se está
trabajando en la parte técnica (protocolos,
componentes electrónicos, etc.) de las redes
inalámbricas; por lo que, en entornos donde
existe poca movilidad, el uso de redes
inalámbricas es altamente confiable y está
creciendo vertiginosamente (e.g. redes
inalámbricas caseras).
El esquema tradicional de
comunicaciones distribuidas (arquitectura
cliente/servidor) así como todos los
esquemas orientados a conexión presentan
las siguientes características:
1. Requiere de una conexión
persistente.
2. Si la conexión se pierde, la
transacción también.
3. Cualquier falla de comunicación es
atribuida a la red.
4. Su esquema de interacción es
consumidor de tiempo.
Con el tiempo, se ha podido a preciar que
el modelo cliente/servidor en ambientes
móviles presenta las siguientes
características:
Los periodos de desconexión son
frecuentes.
1. Están limitados en tiempo de
conexión debido a la batería.
2. Los enlaces en ocasiones son caros
y poco confiables.
Ante estas circunstancias, se hace
necesario llevar un control y administración
de las transacciones realizadas en un
ambiente móvil. Este trabajo se enfoca en la
visualización de páginas Web, ya que se ha
comprobado que es el recurso más utilizado
en la Internet después del correo electrónico.
III ANTECEDENTES
El desarrollo de esta propuesta forma
parte de un Sistema de Gestión de
Acaparamiento en esta clase de dispositivos
móviles [3]. Él cual a su vez forma parte del
proyecto Moviware [4], cuyo objetivo principal
es brindar servicios a equipos móviles que
están propensos a frecuentes desconexiones.
En [5] se trabajó en una idea similar, con la
salvedad de que el desarrollo fue para
clientes móviles tradicionales (laptops con
interfaces de red inalámbrica); mientras que
en el presente trabajo de investigación se
está laborando sobre arquitecturas no
tradicionales como es el caso de dispositivos
móviles con sistema operativo Windows CE.
IV METODOLOGÍA DE SOLUCIÓN
Un esquema interesante para resolver el
problema de las desconexiones cuando se
accede a recursos Web, es el acaparamiento
de sitios Web. El acaparamiento se basa en
la idea de que el espectáculo debe continuar.
Si los usuarios no pueden acceder a los
datos, los datos deben seguir a los usuarios.
Esto es muy similar a la recarga de energía
en las baterías de los dispositivos móviles;
por lo que en el acaparamiento se habla de
“recarga de datos”. Así como un usuario
móvil carga su batería y se desconecta de la
red eléctrica para trabajar, así del mismo
modo un usuario acapara recursos
informáticos mientras éste se encuentre
conectado a una red inalámbrica, para
posteriormente poder visualizar sitios Web sin
necesidad de estar conectado.
El Acaparamiento de acuerdo con [6], es
el proceso de replicación y proceso en
desconexión de datos previamente
seleccionados y copiados localmente en el
cliente móvil.
En este trabajo nos enfocamos al
desarrollo de un módulo de control de
desconexiones, al que se ha denominado
GDL (Gestor de Desconexiones Locales),
dicho módulo al igual que el GAP (Gestor de
Acaparamiento para Pocket PC) está
desarrollado en .NET CompactFramework
con lenguaje C#, ya que según un estudio
realizado con anterioridad [7], es por muchas

3. razones la mejor herramienta para programar
en esta clase de dispositivos.
En la Figura 1, se muestra el proceso de
obtención de un recurso en la Web a través
del sistema que se está desarrollando.
Figura 1. Diagrama de estado del proceso de
obtención de un recurso Web
La parte principal de este esquema
consiste en los procesos de monitorear la
conexión (en el caso de que no se pueda
obtener un recurso en línea), así como
también la reconexión (en caso de que el
sistema este desconectado y se detecte que
el medio de comunicación es fiable y haya
conexión). Determinar el estado de la
conexión no es una tarea sencilla, dado que
si determinamos el estado de la conexión de
primera mano, podría llevarnos a
conclusiones equívocas; por ejemplo,
determinar que existe una desconexión
cuando el recurso no pudo obtenerse (podría
ser que el servidor Web no responda pero la
conexión es correcta) o determinar que el
dispositivo se encuentra conectado pero la
conexión es inestable y en un momento
existe conexión y en otros no. Por estos
motivos se desarrolló un mecanismo para
predecir desconexiones que a continuación
se describe.
Para el proceso de monitoreo,
simplemente verificamos que el Proxy en el
lado servidor GAT (Gestor de Acaparamiento
y Transcodificador) este funcionando
adecuadamente. Dicho intermediario se
encarga de obtener el recurso Web
acapararlo en el servidor para después
enviarlo al cliente. También realiza
transcodificación de contenidos Web en caso
de ser necesario (por transcodificación se
entiende el proceso de convertir un recurso
Web de tal forma que su contenido se adapte
a las limitantes de despliegue de cualquier
clase de dispositivos [8]). Este Proxy se
encuentra actualmente en desarrollo.
El monitoreo se aplicó a dispositivos
Pocket PC 2000, 2002 y 2003 Second Edition
(Windows Mobile); enfocándonos en esta
última plataforma, ya que nos permite instalar
una consola de línea de comandos y hacer
un seguimiento del proceso de monitoreo, tal
y como se muestra en la Figura 2.
Figura 2. Monitoreo de conexiones en
dispositivos móviles PPC 2003
El proceso de monitoreo consistió en
determinar de manera aleatoria durante tres
segundos el número de peticiones que se
podrían realizar (aproximadamente 15
peticiones, en un rango de aproximadamente
200ms por petición). Se eligió este esquema
a comparación de monitorear constantemente
el desempeño de la red, ya que de esta forma
se consumía mucho tiempo de proceso
innecesario. En la Tabla 1 se muestran los
resultados obtenidos de la prueba al GDL.
Tabla 1. Resultados obtenidos de las pruebas.
Peticiones Acertadas Fallas Eficiencia
14.98 10.87 4.2 70.54%

4. El módulo de desconexiones se probó 100
veces obteniéndose un promedio de 14.98
peticiones realizadas en 3 segundos (se
determinó este valor ya que si se escoge un
valor más pequeño no se puede obtener
suficiente información, y si se escoge un valor
más grande se pierde tiempo vital para la
visualización de recursos), de las cuales
10.87 fueron correctas y 4.2 incorrectas para
un 70.54% de eficiencia.
En algunos casos probar eventos de
desconexión es difícil (e.g. transpaso de
células o redes, errores de hardware,
instalación en caliente de interfaces de red,
etc.) Se simularon desconexiones al
apagar/encender el mecanismo GAT, ya que
se parte del hecho de que aunque haya
conexión y garantías de buena comunicación
si no nos podemos comunicar con nuestro
intermediario, el sistema se encuentra aislado
del mundo exterior dado que no hay salida. El
esquema de posibles desconexiones se
detalla en la Figura 3
Figura 3. Esquema de desconexiones.
En el esquema 1 la desconexión con el
GAT se da entre dos equipos móviles que
están en una red ad hoc o sin infraestructura.
En el esquema 2, la desconexión se da entre
un cliente móvil y un cliente fijo; mientras que
en el esquema 3, la desconexión se produce
entre el dispositivo y su punto de acceso o
estación base.
De las pruebas realizadas, se obtuvo que
el índice de eficiencia es de
aproximadamente 70%, además se observó
que cuando se presentaban transacciones
por debajo del 30% de efectividad, era muy
difícil completarlas; es por esto que se
escogió este índice para determinar si se
presenta una desconexión o no; es decir, se
necesitará que el sistema tenga al menos el
30% de eficiencia para determinar que se
encuentra conectado, caso contrario, estará
desconectado.
Una vez probado dicho módulo, éste se
agregó al proyecto general. Se pudo observar
que no es necesario vigilar el estado de la
conexión de manera continúa, solamente en
el caso de que se pida una petición de un
recurso Web, dado que los navegadores
realizan peticiones de manera explicita por
parte de los usuarios.
Figura 4. Eficiencia en el control de
desconexiones.
En la Figura 5, se muestra la incrustación
del módulo de desconexiones en el GAP. En
este ejemplo se presenta un error ya que no
se pudo obtener un recurso en la Web y se
determinar el estado de la conexión. Al estar
el estado de la conexión por arriba del 30% el
sistema se encuentra en modo conexión. Si
el índice hubiese sido inferior al 30% el
sistema hubiese pasado a un estado
desconectado.
En la Figura 6, se puede visualizar la
forma en que ocurre una reconexión. Estando
el sistema en modo desconexión, este no
puede realizar peticiones hacia recursos Web
pero el sistema realiza una petición única
para determinar si ya existe conexión. En
este caso, se escogió que el sistema
intentará determinar el estado de la conexión
hasta el final, dado que si se intentará realizar
una petición en modo desconexión existiría
un retardo y una gran probabilidad de que el
recurso no se pudiese obtener. Sólo se
realiza una petición de reconexión y no un
conjunto de peticiones como en el caso de
monitorear la conexión, debido
principalmente al retardo en el proceso y a
que si se detectará una conexión el sistema
es capaz de detectar una desconexión y ya
no se tendría que codificar un módulo extra.
Si el GAP se encuentra en modo conexión
se muestra el recurso de la red
(transcodificándolo si es necesario). En modo
desconexión el sistema debe mostrar el

5. recurso si este se encuentra en la caché local
del dispositivo móvil; en caso contrario,
muestra un mensaje de error, tal y como se
ve en la Figura 7. Nótese que el acceso a los
recursos en la caché local es transparente al
navegador, por lo que el navegador no se da
cuenta si el recurso está en la red o en el
dispositivo (no se emplea el protocolo file://).
Figura 5. Monitoreo de una desconexión en el
GAP.
Figura 6. Ejemplo de Reconexión en el GAP
Figura 7. Visualización de recursos en modo
desconexión.
El GDL también se probó en otros
dispositivos como el emulador de Windows
CE .NET (4.2) y en un Smartphone con
Windows Mobile 2003. En éste último el
programa se ejecuta al igual que en la
mayoría de las PPCs pero no se visualizan
resultados dado que no se cuenta con un
shell de líneas de comando (en la versión
2003 de PPCs y superior se puede instalar
una consola de línea de comandos). La
ejecución del programa en el teléfono celular
con Windows Mobile 2003 se muestra en la
Figura 8.
Figura 8. Ejecución del monitor de
desconexiones en un Smartphone 2003.

6. V CONCLUSIONES
En la actualidad es cada vez menos
común que se presenten eventos de
desconexión en redes inalámbricas, pero
debido a la naturaleza del medio físico de
transmisión, dichos eventos siempre se
presentarán y será necesario tomar está y
otras consideraciones cuando se realicen
aplicaciones en dispositivos móviles.
Las desconexiones son una norma en
ambientes móviles y lejos de enfocarse en
tratar de eliminarlas completamente se debe
hacer frente a los eventos de desconexión.
Tal es el caso de este trabajo, en donde se
implementó un módulo gestor de
desconexiones locales en esta clase de
desconexiones, obteniendo una métrica del
30% de efectividad para determinar si un
cliente móvil se encuentra desconectado o no.
VI AGRADECIMIENTOS
Al CoSNET por el apoyo económico
brindado conn la beca número 102004189PJ
para estudios de maestría.
VII REFERENCIAS
[1] Roldán Martínez, David, “Comunicaciones
inalámbricas. Un enfoque aplicado”, Editorial
Alfaomega, México, 2005, ISBN 970-15-1078-
X, pp. 363.
[2] Alarcón Gálvez, Fernando, “Mecanismo para
Gestión de Conexión en Sistemas
Cliente/Servidor Móviles”, tesis de maestría,
cenidet, agosto de 2002.
[3] Olivares Rojas, Juan Carlos, “Gestor de
Acaparamiento de Sitios Web Transcodificados
para Plataforma Pocket PC”, tesis de maestría
en desarrollo, cenidet, enero de 2005.
[4] González Serna Juan Gabriel. “Plataforma
middleware reflexiva para aplicaciones de
cómputo móvil en Internet (Movirware)”, Centro
Nacional de Investigación y Desarrollo
Tecnológico (cenidet), de septiembre de 2001
a agosto de 2003, financiamiento COSNET:
570.01-P.
[5] Verduzco Reyes Gustavo, “Gestor de
Acaparamiento de Patrones de Sitios Web en
Clientes Móviles”, tesis de maestría, cenidet,
agosto de 2003.
[6] Valenzuela Molina David R., “Mecanismo para
Predicción de Acaparamiento de Datos en
Sistemas Cliente/Servidor Móviles”, tesis de
maestría, cenidet, agosto de 2002.
[7] González Serna Gabriel, Montes Rendón
Azucena, Olivares Rojas Juan Carlos.
“Comparativa y evaluación de las herramientas
de programación para desarrollar aplicaciones
en plataforma Pocket PC”. 6to. Congreso
Internacional de las Ciencias Computacionales.
Colima, Colima, México, septiembre de 2005.
[8] Uriarte Cabada Claudia Selene.
“Transformador de Contenidos Web para
Asistentes Personales Digitales”, tesis de
maestría, cenidet, julio de 2004.
CURRICULUM VITAE
Juan Carlos Olivares Rojas es
Ingeniero en Sistemas
Computacionales por el
Instituto Tecnológico de
Morelia. Actualmente realiza
postgrado de Maestría en
Ciencias en Ciencias de la
Computación en la
especialidad de Sistemas Distribuidos en el Centro
Nacional de Investigación y Desarrollo
Tecnológico (CENIDET). También es
vicepresidente de la rama estudiantil del
CENIDET-IEEE. Sus áreas de interés son el
cómputo móvil, redes de telecomunicaciones y
base de datos.
Es Candidato a Doctor en
Ciencias de la Computación
por el CIC del IPN. Sus áreas
de interés son: Redes
inalámbricas (802.11x y
Bluetooth), Minería de uso de
la Web y Sistemas
Distribuidos.
Azucena Montes Rendón
estudió Doctorado en
Matemáticas en la Université
de Paris-Sorbonne en Francia,
en 2002. Sus áreas de interés
son: Tratamiento informático
del lenguaje natural, Web
semántica e inteligencia
artificial.
Víctor Jesús Sosa Sosa es
Doctor en Ciencias de la
Computación por la
Universidad Politécnica de
Cataluña. Sus áreas de interés
son: Sistemas distribuidos,
Programación en el Web,
Bases de datos y Sistemas
operativos.