1. Análisis de Symbian OS para desarrollar aplicaciones
distribuidas sobre terminales GPRS
Almudena Díaz, Pedro Merino, Fº Javier Rivas
Dept. de Lenguajes y Ciencias de la Computación
ETSI de Telecomunicación
Univ. de Málaga
29071 Málaga
{almudiaz,pedro}@lcc.uma.es, javier_rivas@eresmas.com
Resumen
El papel que desempeñan los teléfonos móviles en
en el ámbito de los sistemas distribuidos ha
evolucionado en los últimos años hasta llegar a
convertirse en entornos en los que se pueden
desarrollar complejas aplicaciones. Por esta razón
han surgido numerosas plataformas, tales como
Symbian, cuyo objetivo es adaptarse a las
limitaciones de los terminales móviles y proveer
al desarrollador de las herramientas necesarias
para la programación de aplicaciones en
terminales móviles. Symbian OS es un sistema
operativo especialmente diseñado para adaptarse a
los requerimientos de un teléfono móvil. En este
artículo se revisan loas aspectos que pueden tener
más impacto en las aplicaciones desarrolladas
sobre este sistema operativo en los terminales
GPRS actuales. También se lleva a cabo una
evaluación cuantitativa de las comunicaciones de
datos sobre dicha plataforma que permite extraer
conclusiones acerca de la experiencia de los
usuarios de aplicaciones en terminales móviles.
1. Introducción
Los teléfonos móviles con tecnología GPRS
(General Packet Radio Service) o UMTS
(Universal Mobile Telecommunications System)
comienzan a sustituir a los ordenadores personales
como terminales de Internet tanto en uso
profesional como de ocio. Sin embargo, al tratarse
de dispositivos con características propias como
las limitaciones de memoria, CPU o batería
resulta necesario desarrollar nuevos sistemas
operativos y entornos de desarrollo específicos
que se ajusten a las exigencias de dichos
terminales.
En este artículo se revisan nuestras
experiencias con el sistema operativo Symbian
OS, tanto desde el punto de vista del desarrollador
como de las prestaciones que ofrecen al usuario
final. En este trabajo nos centramos en los
aspectos que se han revelado críticos para mejorar
la percepción del usuario cuando emplea TCP/IP
sobre estos terminales. Muchas de las experiencias
provienen de desarrollos recientes como clientes
de correo [1] y clientes para domótica [2][3] para
terminales móviles.
Las velocidades proporcionadas por GPRS
han propiciado el desarrollo de aplicaciones que
hacen un uso intensivo de las comunicaciones.
Con la reciente puesta en marcha de UMTS las
velocidades medias alcanzadas pueden llegar
hasta los 384 kbits. Esto junto con las elevadas
prestaciones de los teléfonos de última
generación, usualmente llamados smartphones,
permite el desarrollo aplicaciones multimedia que
explotan el concepto de movilidad en su sentido
más amplio.
En este escenario han ido surgiendo una gran
variedad de sistemas operativos y plataformas
orientadas al desarrollo de aplicaciones para
dispositivos móviles: Symbian OS [12], Linux
Embedded[16], Microsoft CE[19], Blackberry
OS[20], Brew[18], J2ME[14], Mophun[17]. De
todas ellas, el sistema operativo Symbian OS
Actas de las XIII Jornadas de Concurrencia y Sistemas Distribuidos, pp.259-269
ISBN: 84-9732-432-3 © 2005 Los autores, Thomson

2. tiene dos características que posiblemente lo harán
destacarse a medio plazo. Por una parte, su diseño
se realizó directamente para terminales móviles,
en lugar de ser una adaptación de otro sistema
existente. Por otra parte, no está ligado a un único
fabricante, sino que es fruto de un consorcio en el
que participan la mayoría de ellos.
En este artículo se lleva a cabo un análisis del
sistema operativo Symbian centrándose en el
soporte que ofrece para las comunicaciones y en
las decisiones adoptadas en su diseño para
adaptarse a las peculiaridades de los terminales
móviles. El objetivo es dar una visión de los
aspectos más relevantes que deben conocer los
desarrolladores de nuevos servicios telemáticos.
La organización del artículo es la siguiente.
En la sección 2 se describe la arquitectura del
sistema operativo. En la sección 3 se describe el
modelo de programación de objetos activos y las
particularidades de la programación sobre
Symbian. La sección 4 trata la problemática
asociada a los contextos PDP y el uso de NAT por
parte de los operadores. En la sección 5 se
discuten aspectos de rendimiento de las
comunicaciones a partir de experiencias de
proyectos concretos. Finalmente se presentan las
conclusiones.
2. Visión general de Symbian OS
El consorcio Symbian fue constituido en 1998 y
esta integrado por los principales fabricantes del
sector de la telefonía móvil Fig 1. Su objetivo de
partida fue el desarrollo de un sistema operativo
específico para teléfonos móviles con capacidad
para la comunicación de datos. Symbian OS se
asienta en la experiencia de Psion en el desarrollo
de EPOC, el primer sistema operativo
verdaderamente enfocado hacia terminales
móviles con capacidades para comunicaciones.
Symbian OS es actualmente un sistema
operativo multitarea de 32 bits basado en ROM
con una arquitectura de micro-kernel altamente
modular que ofrece numerosas APIs (Application
Programming Interfaces) para el desarrollo de
aplicaciones de comunicaciones y soporta los
principales estándares de la industria inalámbrica
WAP, XHTML, J2ME, MIDP, MMS, Bluetooth,
GPRS, CDMA, SyncML, IPv6, IPsec, etc.
Para la programación de aplicaciones se
pueden utilizar distintos lenguajes: Visual Basic,
Java, OPL y C++. Siendo este último el lenguaje
nativo de Symbian y el que proporciona acceso a
un mayor número de funcionalidades.
Existen diferentes SDKs (Software
Development Kit) para el desarrollo. El SDK
proporciona las herramientas y la documentación
necesarias para el desarrollo de aplicaciones en
Symbian y un emulador del terminal móvil para
PC. Los distintos SDKs están ligados a diferentes
plataformas. Cada una de estas plataformas
proporciona una interfaz de usuario y un conjunto
de aplicaciones del sistema para mensajería,
telefonía, multimedia, agenda y otras tareas, que
permite a los diferentes fabricantes personalizar
sus entornos de desarrollo. Estas aplicaciones
hacen uso de los motores de aplicación genéricos
proporcionados por Symbian OS. Las principales
plataformas existentes son UIQ, Nokia Serie 60 y
Nokia Communicator.
Figura 1. Fabricantes de teléfonos móviles con licencia
Symbian en 2005
2.1. Arquitectura en capas
El sistema operativo Symbian presenta una
estructura en capas (Fig 2).
La capa base constituye el núcleo de Symbian
y está formada por las librerías de usuario, el
servidor de ficheros, el microkernel, y los
controladores de dispositivos.
El microkernel separa el núcleo funcional del
sistema operativo de extensiones y partes
específicas del sistema. El tamaño del núcleo del
kernel en Symbian OS constituye
aproximadamente un 5% del tamaño total del
sistema operativo. Esta separación proporciona al
sistema una alta modularidad y mejora la
portabilidad, el refinamiento y la personalización
260 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

3. de la plataforma. Las funciones que no se pueden
incluir en el microkernel debido a su complejidad
son separadas en servidores internos. Los
servidores internos extienden la funcionalidad del
núcleo.
El kernel se ejecuta en modo privilegiado,
posee los controladores de dispositivos,
implementa la política de planificación, gestiona
el consumo de potencia y la asignación de
memoria tanto para él como para los procesos que
se ejecutan en modo usuario. Se ejecuta
nativamente sobre núcleos ARM (menor consumo
que los procesadores x86 de Intel y mejor relación
rendimiento-precio). El kernel implementa un
marco de trabajo de paso de mensajes usado para
la comunicación cliente-servidor.
Los subsistemas más destacados, en cuanto a
la funcionalidad que ofrecen, son el de telefonía,
el de comunicaciones y el de mensajería.
El subsistema de telefonía proporciona un API
multimodo para sus clientes. Entres las redes
móviles abstraídas se encuentras GSM, GPRS,
EDGE, CDMA (IS-95) , 3GPP cdma2000 y 3GPP
W-CDMA.
El subsistema de comunicaciones proporciona
el marco de trabajo y los servicios del sistema
para las comunicaciones y el establecimiento de
conexiones de red. Este subsistema será analizado
con más detalle en el siguiente apartado.
El marco de trabajo de mensajería proporciona
soporte para los protocolos de envió y recepción
de SMS (Short Message Service), EMS
(Enhanced Message System), MMS (Multimedia
Message System), correo electrónico y fax.
Figura 2. Arquitectura en capas de Symbian
XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 261

4. 3. Desarrollo de servicios para Internet
Una de las características más representativas de
Symbian OS es que se trata de un sistema
operativo orientado al manejo de eventos en lugar
de al manejo de hebras. Aunque la programación
multihebra está soportada y es usada internamente
en el sistema operativo, para las aplicaciones se
recomienda evitar su uso debido a la sobrecarga
que introducen, ya que, en principio, en una
aplicación basada en eventos no se necesitaría
realizar ningún cambio de contexto, con lo cual la
sobrecarga, en este caso, sería menor que si se
emplearan hebras.
A continuación se analizarán algunas de los
aspectos más relevantes de Symbian, como son el
concepto de objeto activo y las técnicas de gestión
de memoria usadas.
3.1. Modelo de programación: Objetos Activos
Un objeto activo es una entidad manejadora de
eventos. Un planificador coordina los diferentes
objetos activos existentes para gestionar los
eventos procedentes del terminal y de las
aplicaciones. Cada objeto activo tiene una función
virtual llamada RunL(). Esta función es atómica y
es llamada cuando tiene lugar un evento del cual
el objeto activo es responsable. Dentro de esta
función se lleva a cabo un preprocesamiento del
evento para identificarlo y actuar en consecuencia.
Los objetos activos son planificados en
función de su prioridad al igual que las hebras. La
planificación de los objetos activos se lleva a cabo
de forma no expropiativa, es decir, la
planificación sólo se lleva a cabo cuando la
función RunL() en ejecución se ha completado, en
este momento el objeto activo con mayor
prioridad que esté esperando pasa a ejecutarse, si
no existe ningún objeto activo el sistema operativo
se mantiene a la espera de nuevos eventos.
De esta forma al no planificarse
expropiativamente no es necesaria la utilización
de semáforos, secciones críticas u otras técnicas
de sincronización, que implican una sobrecarga
significativa del sistema.
La elección de un sistema basado en eventos
también influye en el ahorro de batería ya que el
sistema sólo actúa cuando se produce un evento,
mientras tanto el sistema se mantiene a la espera
sin consumir ningún ciclo del procesador y por
tanto batería. Esta forma de operar es diferente a
la de los de los sistemas orientados al manejo de
hebras en los cuales se llevan a cabos sondeos
para detectar si en algunas de las hebras se ha
producido algún cambio, y por tanto existe
consumo de batería en periodos en los que en
teoría el sistema no debería estar operando.
3.2. Arquitectura cliente-servidor
La arquitectura cliente-servidor es otra de las
claves del diseño de Symbian OS. Las
aplicaciones de los usuarios y los procesos del
sistema son clientes que comparten los recursos de
una amplia variedad de servidores del sistema.
Prácticamente todos los servidores se ejecutan con
una prioridad alta, pero sin privilegios para
asegurar una respuesta puntual a sus clientes
mientras controlan el acceso a los recursos del
sistema.
La arquitectura cliente servidor permite
mejorar la extensibilidad (a través del uso de
plugins), la eficiencia (varios clientes pueden ser
atendidos por el mismo servidor), la seguridad
(los servidores y sus clientes se ejecutan en
procesos separados y se comunican a través de un
mecanismo de paso de mensajes proporcionado
por el kernel,) y la asincronía (los servidores son
implementados a través de objetos activos de
forma que los clientes se suspenden mientras
esperan a que sus peticiones sean atendidas en
lugar de llevar a cabo sondeos para comprobar el
estado de esta, con la consecuente reducción en el
número de ciclos de procesador necesarios para
atenderla).
3.3. Mecanismos de gestión de memoria
A la hora de programar en Symbian es necesario
tener en cuenta ciertas peculiaridades que ayudan
a evitar errores y a entender mejor su estilo de
programación.
Pila
Existen ciertas divergencias entre el espacio
de pila disponible en el emulador para PC y el
disponible en el terminal. El tamaño de la pila en
el emulador para PC no está limitado como ocurre
en el terminal ya que se usa la propia pila de
Windows. Para prevenir desbordamientos de la
262 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

5. pila es recomendable localizar los descriptores en
el heap, usar únicamente objetos automáticos para
datos y cadenas de pequeño tamaño y evitar
programar recursivamente (si esto último fuera
inevitable deberían ser minimizados los tamaños
de los parámetros pasados y de las variables
automáticas usadas en la parte recursiva).
CleanUp Stack
En un sistema limitado en memoria como es
un teléfono móvil se debe prestar especial
atención a la gestión de la memoria, para este fin
Symbian implementa un mecanismo propio
denominado Cleanup Stack.
El Cleanup Stack es una pila especial que
almacena los punteros a los objetos que necesitan
ser liberados cuando ocurre una excepción. Todas
las aplicaciones tienen su propio Cleanup Stack
que es creado por defecto.
Cualquier puntero definido localmente que
apunte a un objeto localizado en el heap debe ser
añadido al Cleanup Stack si existe riesgo de que
una excepción tenga lugar y no hay ninguna otra
referencia al objeto. Si no tiene lugar ninguna
excepción los punteros deberán ser borrados de la
pila por el programador.
Los datos pertenecientes a las instancias de
una clase no pueden ser añadidos al Cleanup
Stack ya que son eliminados por el destructor de
la clase.
Construcción en dos fases
Por el mismo motivo que antes los
constructores y los destructores de los objetos no
pueden generar excepciones ya que si esto ocurre
se podrían producir fugas de memoria. Para
solucionar esto la construcción de objetos se lleva
a cabo en dos fases. En una primera fase se
procede a la inicialización del objeto y en una
segunda fase, y usando el CleanUp Stack, se lleva
a cabo la asignación de memoria, de forma que si
en esta fase se produjera alguna excepción la
memoria asignada hasta ese momento sería
correctamente liberada.
Manejo de excepciones
Symbian proporciona sus propios mecanismos
para el manejo de excepciones. El sistema de
excepciones de Symbian está adaptado a las
normas de programación usadas en Symbian
(clases C, clases T, códigos de error de 32 bits…)
con esto se evita la sobrecarga introducida por el
mecanismo de manejo de excepciones de C++
(try, catch y throw).
El manejo de excepciones empleado en
Symbian se basa fundamentalmente en la macro
TRAP y sus variantes (p.e. TRAPD permite que el
código se ejecute en un ambiente protegido (trap
harness)) y en la llamada User::Leave() la cual, en
caso de malfuncionamiento, termina la ejecución
de la función actual y devuelve el código del
error.
Procesador
Los procesadores de los dispositivos más
recientes son procesadores RISC con frecuencias
de reloj que rondan los 200MHz, frecuencia que
resulta adecuada para la mayoría de las
aplicaciones. Sin embargo el desarrollador debería
tener en mente que los procesadores no disponen
de unidad de punto flotante (UPF). Por este
motivo se recomienda evitar en la medida de lo
posible el uso de notación en punto flotante, ya
que la velocidad de ejecución de la aplicación
podría experimentar una disminución
considerable.
3.4. Subsistema de comunicaciones
El subsistema de comunicaciones de Symbian OS
proporciona los siguientes servicios:
• Gestor de base de datos que se encarga de
controlar la configuración de todo el sistema
de comunicaciones.
• Servidor de sockets y un API de cliente que
permite la implementación de distintos
protocolos de comunicación a través del
interfaz de sockets. Los protocolos pueden
ser cargados dinámicamente a través de
plugins.
• Administrador de red que proporciona el
marco de trabajo para la conexión con otros
ordenadores o redes. El administrador
proporciona los mecanismos necesarios para
que el cliente pueda monitorizar el progreso a
través de, por ejemplo, una conexión PPP.
XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 263

6. • Servidor de comunicaciones serie que
proporciona la abstracción de un puerto serie
(RS232C) lo que permite a los teléfonos
Symbian actuar como un DCE y un DTE. Los
módulos de comunicación se pueden cargar
dinámicamente para comunicarse con los
controladores y las diferentes pilas de
protocolos.
Symbian proporciona una pila dual que
soporta tanto IPv4 como IPv6. La pila IP
proporciona una arquitectura basada en plugins
que permite la implementación de extensiones.
Los plugins pueden interactuar con los niveles
OSI 2, 3 y 4, y pueden ser instalados, cargados y
descargados y en tiempo de ejecución. Uno de
los plugin más destacados es el IPSec, para la
seguridad en las comunicaciones.
3.5. Contextos PDP (Packet Data Protocol)
Para el establecimiento de una comunicación de
datos a través de GPRS el usuario debe
proporcionar los datos de la sesión y enviar la
petición a la red. Para establecer una sesión con
una red de paquetes (PDN) como Internet se debe
aportar una descripción de las características del
flujo de datos que se desea establecer y la red
GSM/GPRS en función los datos recibidos
analizará la viabilidad del establecimiento de
dicho flujo de datos.
Se denomina contexto PDP a la conexión
entre el terminal de usuario y la GGSN (Gateway
GPRS Support Node) del operador. Para el
establecimiento de esta conexión es necesario el
envío de un paquete de activación del contexto
PDP en el que se incluye información acerca del
tipo de red de paquetes de datos (p. e IPv4), la
dirección de red asignada (p.e. una dirección IPv4
192.168.2.1), los requerimientos de calidad de
servicio (QoS) y el nombre del punto de acceso
(APN), a través del cual el tráfico será enrutado
hacia la red de paquetes de datos. Actualmente el
campo de la dirección IP se envía en blanco y es
el operador el encargado de asignar una dirección
IP dinámica que puede ser pública o privada,
implicando esta última opción la imposibilidad de
establecer comunicaciones directas entre
terminales.
Un terminal móvil puede tener más de un
contexto PDP activo a la vez, y tener por tanto
más de una dirección IP, lo que a todo los efectos
supone tener más de un interfaz de red. Es decir,
si un terminal móvil soporta varios contextos PDP
un navegador WAP puede usar un punto de
acceso para wap mientras un cliente de correo usa
un punto de acceso GPRS, y estar ambas
aplicaciones conectadas y transmitiendo datos.
Cuando el terminal está negociando con la red
el establecimiento de una sesión de datos se debe
especificar el nombre del punto de acceso (APN).
El punto de acceso puede identificar un servicio o
una red externa (p.e. Internet) y suele expresarse a
través de un identificador de red que no es más
que la URL usada por el SGSN (Serving GPRS
Support Node) para consultar en el DNS del
operador la GGSN que proporciona el APN
solicitado por el cliente. Este mecanismo permite
enrutar el tráfico desde y hacia la intranet del
operador.
4. Eficiencia de las comunicaciones
A la hora de evaluar las características de la
comunicación sobre Symbian, se ha aprovechado
la experiencia obtenida en la evaluación de
aplicaciones sobre otras plataformas como
Mophun [1][2][3]. Los resultados obtenidos para
dichas plataformas han ayudado a identificar
aspectos de interés y puntos fuertes de Symbian
OS.
Figura 3. Escenario de captura de tráfico
264 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

7. 4.1. Escenarios de captura de tráfico
Durante las primeras fases del desarrollo de una
aplicación las pruebas se realizan normalmente
utilizando un emulador sobre un PC. Este tipo de
herramienta resulta apropiado en primera instancia
al no requerirse de terminales reales, pero por otro
lado puede enmascarar posibles limitaciones de
las implementaciones en terminales reales. Sin
embargo, para analizar el comportamiento de una
aplicación sobre un terminal real, es necesario
utilizar una configuración como la de la Fig. 3.
Para reproducir un escenario habitual, se ha
utilizado un equipo conectado a Internet a través
de un router ADSL, la transmisión de datos con
el terminal móvil se realiza mediante una
conexión GPRS, la red GPRS empleadas es una
red en explotación. El tráfico generado por la
aplicación se ha capturado utilizando un
analizador de protocolos en la red local del equipo
servidor.
4.2. Pruebas con terminales Symbian
Para la realización de pruebas con terminales
reales se han utilizado los teléfonos Nokia 6600 y
Nokia 7610 que incorporan la versión 7.0 de
Symbian OS.
Con el objetivo de caracterizar el
comportamiento de las comunicaciones se ha
utilizado una aplicación de FTP para generar dos
tipos de tráfico diferenciados: interactivo e
intensivo.
El tráfico interactivo se caracteriza por el
envío de mensajes de tamaño reducido en ambos
sentidos. La latencia en la transmisión, y no el
throughput, es el parámetro más importante en
una comunicación de este tipo, ya que el diálogo
entre las dos partes requiere para avanzar de un
intercambio continuo en ambos sentidos. Este tipo
de comportamiento se ajusta al proporcionado por
la conexión de control FTP, ya que el protocolo se
basa en la transmisión de peticiones y respuestas
de pequeño tamaño (normalmente menor de 64
bytes). En la Fig. 4 se muestra la evolución del
tiempo de ida y vuelta (Round Trip Time) de una
conexión de control FTP.
También puede observarse cómo para
determinados grupos de paquetes el tiempo de ida
y vuelta es mayor. Esto se debe a que,
paralelamente a la conexión de control FTP,
eventualmente se establecen conexiones de datos.
La finalidad de estas conexiones de datos es la
transferencia de datos de tamaño algo mayor,
como listados de directorios. Aunque los datos
transmitidos en estas conexiones son menos de
264 bytes en las pruebas realizadas se ha
observado que el tiempo de ida y vuelta se llega a
incrementar en más 500 ms con respecto al valor
típico. Para conseguir mejorar los tiempos de
respuesta de las aplicaciones resulta necesario
reducir al mínimo posible el tamaño de los
mensajes enviados.
En la Fig.4 se puede observar que el tiempo de
ida y vuelta máximo llega a ser de 2,8 segundos.
Aprovechando que las implementaciones
probadas de TCP soportan la utilización de marcas
de tiempo se ha podido llegar a la conclusión de
que este excesivo retardo se ha originado en el
sentido del terminal móvil al servidor. La causa de
este retraso puede estar en el mecanismo de
retransmisión que incorporan los protocolos de
acceso radio para ofrecer una transmisión de datos
fiable ante eventuales pérdidas de tramas.
Por otro lado, el tráfico intensivo se
caracteriza por el envío continuo de datos en el
mismo sentido de transmisión. El tamaño de los
mensajes es mayor que en el tráfico interactivo.
Para estudiar este tipo de transmisiones se han
analizado las conexiones de datos para la descarga
de ficheros vía FTP. En las siguientes gráficas se
representa la transferencia de un fichero de 70
KBytes.
Como se aprecia en la Fig. 5, el tiempo de ida
y vuelta medio para una conexión de datos es
mayor que para la conexión de control (unos 2
segundos), pero esto no es crítico, ya que en este
caso la magnitud que determina la percepción que
el usuario tiene del rendimiento es el tiempo total
de transferencia, que está estrechamente
relacionado con el throughput.
El throughput medio observado en la Fig. 6 es
de unos 27kbps, tardándose 20,5 segundos en
transmitir los 70KBytes del fichero. Para archivos
de mayor tamaño podría resultar algo mayor, ya
que durante la transferencia llegan a alcanzarse los
32kbps.
La Fig.7 representa la evolución de los
números de secuencia enviados y confirmados. En
la aplicación utilizada los ficheros se envían en
bloques de 4096 bytes, pero estos se fragmentan
en segmentos TCP de tamaño máximo 1356 bytes.
XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 265

8. Figura 4. Tiempo de ida y vuelta de una conexión de control Ftp
Figura 5. Evolución de la conexión de datos de una sesión Ftp
266 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

9. Puede apreciarse cómo el tamaño de la
ventana de recepción del terminal móvil tiene un
tamaño considerable, 48KBytes. Disponer de una
ventana de recepción suficientemente grande
permite obtener un buen aprovechamiento de la
conexión GPRS, al posibilitarse el envío de
múltiples mensajes simultáneamente por parte del
emisor.
4.3. Pruebas con otra plataforma
Para hacernos una idea más precisa de la bondad
de Symbian OS en lo referido a comunicaciones,
resulta adecuado realizar una comparación con
otras plataformas que permitan la ejecución de
aplicaciones. Una tendencia muy común
actualmente es la utilización de máquinas
virtuales para conseguir una mayor portabilidad,
un ejemplo de ello es Mophun. Se han realizado
pruebas similares a las anteriores utilizando los
terminales T310 y T610 de SonyEricsson.
Como resultado de las pruebas realizadas se
ha detectado que existe un problema en el interfaz
entre la pila de comunicaciones TCP/IP del
terminal y la aplicación Mophun cuando los
mensajes intercambiados no son de tamaño
reducido. El problema detectado consiste en que,
cuando una aplicación que corre sobre el terminal
móvil está recibiendo datos, la aplicación deja de
recibir datos sin motivo aparente.
Las implementaciones probadas presentan
limitaciones en el tamaño máximo de bloque
leído, que es de 255 bytes. Así, al disponer los
terminales utilizados de una ventana de recepción
de 1536 bytes (bastante más reducida que en los
terminales Symbian utilizados), la aplicación debe
realizar varias lecturas para poder leer todos los
datos disponibles. Aunque a partir de los retardos
de transmisión observados la comunicación podría
ser moderadamente más rápida, los retardos en el
interfaz con la aplicación y la reducción del
tamaño de los mensajes enviados para garantizar
la fiabilidad reduce el rendimiento
considerablemente, obteniéndose un throughput
menor de 3 kbps.
Figura 6. Throughput de una conexión de datos Ftp
XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 267

10. Figura 7. Evolución de la conexión de datos de una sesión FTP
Cuando la ventana de recepción se llena, tras
varias lecturas consecutivas se llega a un estado
en el que no se informa a la aplicación de que
quedan datos disponibles. Sin embargo,
analizando el tráfico generado, se observa que en
la ventana de recepción todavía hay datos que no
han sido entregados a la aplicación. Para evitar
esto los bloques de datos intercambiados a nivel
de aplicación deben ser de tamaño reducido.
Una importante deficiencia encontrada reside
en que la interacción con la aplicación introduce
mucho retardo en las comunicaciones, una
confirmación a nivel de aplicación acarrea un
retardo unos 600ms mayor que el asociado a las
confirmaciones propias de TCP.
Esto contrasta claramente con los resultados
obtenidos para Symbian donde no da tiempo a que
se envíen mensajes únicamente de confirmación
TCP cuando se responde a nivel de aplicación.
Resulta aparente que el interfaz entre la capa de
comunicaciones y la aplicación es mucho más
fluido en Symbian.
5. Conclusiones
Debido a la especial problemática de las
plataformas móviles, resulta necesario llevar a
cabo un análisis de las comunicaciones a distintos
niveles para detectar posibles cuellos de botella y
causas de error para las aplicaciones. A la vista de
las pruebas realizadas, se ha puesto de manifiesto
que en entornos de ejecución de tipo máquina
virtual es necesario tener en cuenta posibles
deficiencias y pérdidas de rendimiento en el
acceso a las funciones propias de los terminales.
Symbian es un sistema operativo que ha
demostrado ser altamente eficiente, permitiendo el
desarrollo de aplicaciones en el lenguaje nativo
del terminal, por lo que desde el punto de vista del
rendimiento resulta ser una buena base para el
desarrollo de aplicaciones de comunicación.
Aunque desde el punto de vista del
desarrollador Symbian presenta carencias en la
documentación de las APIS (escasez de ejemplos,
funciones no documentadas, funciones que si
268 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

11. están documentadas pero no están
implementadas…) como en las herramientas de
depuración, tanto para el terminal como para el
emulador.
Por otra parte, los retardos observados en las
conexiones GPRS sobre Symbian pueden ser
excesivos para aplicaciones sujetas a requisitos
estrictos de tiempo real (como aplicaciones de voz
sobre IP), sobre todo si el tráfico generado es
fuertemente bidireccional (full-duplex). Sin
embargo, ya que el throughput obtenido es
bastante alto, se abre la posibilidad para el
desarrollo de aplicaciones con requisitos más
relajados como el streaming (que admite latencias
mayores pero con jitter acotado) o el Push To Talk
(punto a multipunto).
Uno de los puntos hacia los que se enfocarán
futuros trabajos es al análisis de las prestaciones
obtenidas para aplicaciones sobre terminales
UMTS Symbian, donde es posible especificar
distintos grados de calidad de servicio para
ajustarse a necesidades específicas.
Referencias
[1] Almudena Díaz PFC “Cliente de Correo para
teléfonos móviles” ETSIT Universidad de
Málaga. 2004
[2] F. Javier Rivas PFC “Plataforma móvil para
acceso a servicios domóticos” ETSIT
Universidad de Málaga. 2004
[3] Juan C. Cuevas, Pedro Merino, F. Javier
Rivas, Pedro J. Reche “Migrando una
aplicación domótica a entornos móviles” XIV
Jornadas Telecom I+D 2004
[4] Leigh Edwars, Richard Barker, and the Staff
of EMCC of Software Ltd. “Developing
Series 60 Applications. A Guide for Symbian
OS C++ Developers” Addison Wesley, 2004
[5] Richard Harrison “Symbian OS C++ for
Mobile Phones” Ed. John Wiley and Sons,
LTD.2003
[6] Digia Inc “Programming for the Series 60
Platform and Symbian OS” Ed. John Wiley
and Sons, LTD. 2002
[7] Kevin Dixon ”Symbian OS Version 7.0s.
Functional description” Revision 2.1, Junio
2003, Symbian Ltd.
[8] RFC 3235 “Network Address Translator
(NAT)-Friendly Design Guidelines” 2002
[9] ] RFC 3314 “Recommendations for IPv6 in
Third Generation Partnership Project (3GPP)
Standars” 2002
[10] The 3G Partnership Project:
http://www.3gpp.org
[11] Symbian OS - the mobile operating system:
www.symbian.com
[12] Forum Nokia - Developer Resources
www.forum.nokia.com
[13] NewLC, the Symbian OS C++ developer
portal: www.newlc.com
[14] Sun Developer Network Site:
http://developers.sun.com/techtopics/mobility/
[15] Embedded Linux Consortium:
http://www.embedded-linux.org
[16] Mophun web site: http://www.mophun.com
[17] Qualcomm brew home:
http://brew.qualcomm.com/brew/es/
[18] Microsoft Windows Embedded Developer
Center:
http://msdn.microsoft.com/embedded/default.
aspx
[19] Blackberry Developer Home:
http://www.blackberry.com/developers/index.
shtml
XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 269