Artículo

Desarrollo de una aplicación
en JavaME que permita el
intercambio de contenido
multimedia usando el
protocolo RTP sobre la red
EGPRS-GSM
Joswill Pájaro*
Dahyr Vergara**
Yezid Donoso***
Resumen
Arquitectura de red con dispositivos, clases, protocolos y servicios.
Fuente: elaboración de los autores-
El desarrollo de aplicaciones
móviles utilizando la plataforma
Java Micro Edition se ha visto
relegado a juegos y aplicaciones
de ocio. Debido al auge que ha
tenido la telefonía celular en el
mundo, a los celulares que cada
vez son más versátiles y a la convergencia lograda entre la red de
telefonía celular y la Internet, se
propone una solución que explora nuevos campos en la programación móvil e intenta lograr una
convergencia de servicios entre la
telefonía celular y redes de datos.
Esta investigación brinda nuevas
aplicaciones a tecnologías ya conocidas y presenta una aplicación
que permite intercambiar contenido multimedia (audio y video)
*
Ingeniero de Sistemas, Ingeniero de proyectos especiales del Centro de Informática, Universidad del Norte. jpajaro@uninorte.edu.co
** Ingeniero de Sistemas,. Analista de desempeño de red, Vicepresidencia de Red, Colombiamovil S.A. dahyrjose@gmail.com
*** Ph. D. en Redes Telemáticas. Profesor del Departamento de Ingeniería de Sistemas y computación, Universidad de los Andes. ydonoso@uniandes.edu.co
Fecha de recibido: 20 de agosto de 2009
Fecha de aceptado:01 de octubre de 2009
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
133
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
en tiempo real desde un celular
a un computador o a otro celular
usando Internet, el protocolo de
transporte en tiempo real y redes
de telefonía celular.
Palabras clave: Java ME,
multimedia, RTP (Real-time
Transport Protocol), EGPRS
(Enhanced General Packet Radio
Service), GSM (Global System
for Mobile Communications),
programación móvil, MMAPI
(Mobile Media API).
Abstract
The development of mobile
applications using Java Micro
Edition platform has been relegated to games and leisure applications. Since the boom shown
by the cell phone system in the
world, the versatility of mobile
phones and the convergence
between the Gobal System for
Mobile communications network
and the Internet, a new solution is
proposed, trying to explore new
fields in mobile programming
and achieving services convergence between cellular systems
and data networks, offering new
uses to known technologies. This
article introduces an application
that allows multimedia content
exchange (audio and video) in
real time from a cell phone to a
computer or to another mobile
device using Internet, the Realtime Transport Protocol and
Enhanced General Packet Radio
Services over GSM networks.
Key words: Java ME, multimedia, RTP (Real-time Transport
Protocol), EGPRS (Enhanced
General Packet Radio Service),
GSM (Global System for Mobile Communications), mobile
programming, MMAPI (Mobile
Media API).
134
1. Introducción
Actualmente se considera que
estamos en un momento histórico
caracterizado por una brillante
evolución de las telecomunicaciones, cuyas vertientes están extrapolando cada aspecto de nuestra
cotidianidad. Tal progreso está
integrado por todo un compilado
de investigaciones y producciones
científico-técnicas cuyo impacto no
se puede medir individualmente,
mas, como elementos funcionales
que forman parte de un sistema,
revolucionan la forma en la que nos
comunicamos.
Como ejemplo de esto presentamos el resultado de la integración de
varias tecnologías en una aplicación
que permite intercambiar contenido
multimedia (streaming en tiempo
real) de audio y video entre teléfonos móviles y computadoras; que
utiliza la red celular Gobal System
for Mobile Communications (GSM)
para conectar los dispositivos usando el protocolo de Internet, IP, con
direcciones públicas en la red de
redes.
En primera instancia este artículo explica brevemente las tecnologías utilizadas en el desarrollo de la
aplicación que transmite contenido
multimedia usando el protocolo
Real-time Transport Protocol (RTP)
sobre redes GSM, además ilustra
las diferentes pruebas y resultados
que nos permitieron detectar las
mejores condiciones para ejecutar
la aplicación.
2. Tecnologías empleadas para
el desarrollo de la aplicación
2.1 Java ME
Java es un lenguaje de programación orientado a objetos basado
en la sintaxis de C++, con una
implementación más sencilla y especializada; el lenguaje también es
multiplataforma, ya que las aplicaciones no dependen de la arquitec-
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
tura hardware o el sistema operativo
para funcionar, porque la Máquina
Virtual de Java (Java Virtual Machine, JVM) genera el código que se
ejecuta en cada plataforma a partir
del bytecode, binario que se obtiene
al compilar el código fuente.
Figura 2. Componentes detallados de la arquitectura de la plataforma Java ME.
Fuente: (Juntao, 2003)
Figura 1. Variación del esquema Componentes
de la arquitectura de la plataforma Java.
A continuación se definen los
componentes de la plataforma Java
ME ilustrados en la Figura 2:
2.1.1 Configuración Java ME
Fuente: (Piroumian, 2002, p. 3)
Los componentes de la arquitectura Java, visibles en la Figura
1, indican que una aplicación
desarrollada en este lenguaje depende de la máquina virtual, esta
pseudoportabilidad permitió la
definición de la plataforma Java
ME. Para encontrar un punto medio
entre portabilidad y desempeño
en implementaciones concretas y
reales, la nueva arquitectura posee
componentes denominados configuraciones, perfiles y paquetes
opcionales: las configuraciones y
los perfiles son los componentes
principales para implementar el lenguaje en los dispositivos móviles;
así mismo, los paquetes opcionales
agregan funcionalidad y definen
las características especiales de los
equipos.
Las configuraciones definen las
características mínimas que debe
tener un dispositivo o una familia
de dispositivos para brindar soporte
a la plataforma Java; entre estas
encontramos la Configuración de
Dispositivos de Conexión Limitada (Connected Limited Device
Configuration, CLDC). Esta está
diseñada para dispositivos generalmente inalámbricos conectados
intermitentemente a la red, con
pocos recursos: procesadores de
16 a 32 bits no muy rápidos y al
menos 160 KB de memoria. También soporta un subconjunto muy
limitado de librerías de Java SE y
carece de muchas de sus características. Esta configuración especifica
la implementación de Java en los
teléfonos celulares (Piroumian,
2002, p. 7).
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
135
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
2.1.2 Perfiles
Funcionalidades como interfaces de usuario y almacenamiento
se agregan con los perfiles; mientras que las existentes, como las
conexiones de red, se mejoran
(Knudsen, 2003). Al igual que las
configuraciones, los perfiles, son
orientados a la capacidad y categoría de los dispositivos. El Perfil para
Dispositivos de Información Móvil
(Mobile Information Device Profile,
MIDP) es el más importante basado
en la configuración CLDC, también,
es considerado el perfil para teléfonos celulares ya que son los dispositivos de información móvil más
comunes (Piroumian, 2002, p. 10).
Las aplicaciones diseñadas en Java
para celulares reciben el nombre de
MIDlets, debido a este perfil.
2.1.3 Paquetes Opcionales
Hasta este punto la plataforma
Java ME brinda herramientas para
desarrollar juegos, aplicaciones
que intercambian información con
el usuario, con otros dispositivos...
Los paquetes opcionales se introducen para evitar la redefinición de
configuraciones o perfiles cuando
dispositivos de una misma familia
tienen características adicionales a
los demás (Juntao, 2003).
La Interfaz de Programación
de Aplicaciones Multimedia Móviles (Mobile Media Application
Programming Interface, MMAPI)
es un paquete opcional que agrega
funcionalidad multimedia a la pla-
taforma Java ME. Incluye clases e
interfaces que proporcionan players,
controles y otros elementos para reproducir audio y video en diferentes
formatos, capturar sonido, tomar
fotografías; en fin, capacidades
multimedia. La especificación del
paquete MMAPI no es estricta en
la definición de los protocolos o
formatos soportados, esta cualidad
permite que se adapte a muchos dispositivos basados en la plataforma
Java sin importar las cualidades de
los dispositivos o la capacidad de la
red (Rantalahti, 2006).
2.2 global System for Mobile
Communications, gSM
El Sistema Global para las Comunicaciones Móviles es un estándar mundial para la comunicación
con teléfonos celulares (De Wulf,
2001, p. 15). Un sistema de comunicación celular está compuesto
por celdas, a su vez, formadas por
antenas que tienen una cobertura
específica; así cuando un usuario
se sale del área de cobertura de una
antena entra al área de otra antena.
En GSM (Figura 3), cada usuario tiene un teléfono celular o
estación móvil (MS), éste debe ser
autenticado mediante una tarjeta
SIM que identifica al usuario en la
red. La Estación Transmisora Base
(BTS, Base Transceiver Station) es
la parte de la red que se comunica
con las estaciones móviles. Las BTS
están compuestas por un conjunto
de emisores/receptores fijos; éstos
Figura 3. Variación del esquema Componentes de la red GPRS/GSM.
Fuente: (Rysavy, 2006, p.12)
136
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
intercambian información con los
teléfonos que se encuentran dentro
de la celda que controla cada BTS.
Continuo a la BTS se encuentra
el Controlador de Estación Base
(BSC, Base Station Controller)
que se comunica con una o más
BTS concentrando el tráfico de las
estaciones base; simultáneamente,
sirve de pasarela hacia el subsistema
de red. El equipo próximo al BSC
es el Centro de Conmutación Móvil
(MSC, Mobile Switching Center) es
un conmutador de red GSM. Además de conectar este sistema con
la red de telefonía pública RTCP/
RNIS, sirve de interfaz de las bases
de datos de GSM con el subsistema
de radio. Luego el HLR (Home
Locator Register) de un suscriptor
de una red celular es un banco de
datos que contiene información del
cliente.
2.3 Enhanced General Packet
Radio Service, EGPRS
El sistema GPRS agrega servicios de conmutación de paquetes a
la red GSM (Rysavy, 2006, p. 13).
Esto permite que, en el sistema
GSM el usuario pueda acceder a
redes de datos utilizando el protocolo de Internet (IP), este se activa
cuando la estación móvil solicita
acceso a la red. GPRS agrega nuevos elementos a la red GSM (Figura
3), los más importantes son el Nodo
Servidor Soporte del Servicio
GPRS (SGSN, en inglés) y el Nodo
Pasarela Soporte del Servicio GPRS
(GGSN).
A su vez, EGPRS, también
conocida como Enhanced Datarate for GSM Evolution (EDGE),
incrementa la tasa de transferencia
de GPRS hasta tres veces y duplica
la capacidad de información usando
la misma porción de espectro del
operador (Rysavy, 2006, p. 14); esto
es posible gracias a la mejora en la
interfaz de radio, mientras que los
demás elementos de la red permanecen iguales.
La diferencia en la cantidad de
información y la tasa de transferencia se logra por la implementación
de una nueva técnica de modulación, métodos de transmisión errortolerante combinados con mejoras
Tabla 1. Comparación de velocidades entre GSM, GPRS y EGPRS.
Tecnología
GSM
GPRS
EGPRS
Tasa Pico Máx.
14 kbps
160 kbps
473 kbps
Tasa
Promedio
9 kbps
40 kbps
130 kbps
Otras Características
Conmutación de circuitos
Conmutación de paquetes en GSM
Actualización software de GPRS
Fuente: Elaboración propia
Tabla 2. Comparación de datos técnicos entre GPRS y EGPRS.
Modulación
Vel. de símbolo
Vel. de modulación de bit
Vel. de datos de radio por intervalo de tiempo
Vel. de datos de usuario por int. de tiempo
Vel. de datos de usuario (8 int. de tiempo)
Vel. de datos de radio (8 int. de tiempo)
GPRS
GMSK
270 ksym/s
270 kb/s
22.8 kb/s
20 kb/s(CS4)
160 kb/s
182.4 kb/s
EDGE
8-PSK/GMSK
270 ksym/s
810 kb/s
69.2 kb/s
59.2 kb/s(MCS9)
473.6 kb/s
553.6 kb/s
Fuente: (Ericsson, 2003, p.5)
Leyenda: GMSK (modulación por desplazamiento gausiano mínimo), 8-PSK (modulación por desplazamiento de
ocho fases), MCS (esquema de codificación de modulación)
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
137
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
en los mecanismos de adaptación
del enlace y una nueva codificación
de canal que puede transmitir servicios de voz o datos conmutando
paquetes o circuitos (Ericsson,
2003, p. 5). GPRS y EGPRS poseen diferentes comportamientos y
protocolos en los nodos que componen el sistema de estación base
de GPRS. Mas, en el core de la
red, GPRS y EDGE comparten los
mismos protocolos para el manejo
de paquetes, esto indica que EDGE
es un agregado de GPRS y por tanto
no puede trabajar solo.
Aunque ambos comparten la
misma velocidad de símbolo (Tabla
2), la velocidad de modulación de
bit en EDGE es tres veces mayor,
esto indica que en el mismo periodo
EGPRS puede trasmitir tres veces
más bits que GPRS. Esta es la principal razón para la gran diferencia
en la tasa de transmisión (Ericsson,
2003, p. 5).
En GPRS se definieron cuatro
esquemas de codificación (de CS1
a CS4). Cada uno tiene diferentes
cantidades de códigos de corrección de errores que se optimizaron
para diferentes ambientes de radio.
Mientras que, en EGPRS se definieron nueve esquemas (MCS1MCS9) que realizan la misma tarea
que los esquemas de GPRS. Los
primeros cuatro (MCS1- MCS4)
usan GMSK, mientras que los cinco
siguientes (MCS5- MCS9) usan
8PSK (Ericsson, 2003, p. 6). De
acuerdo con estas especificaciones,
el desempeño de la conexión y la selección del esquema de modulación
dependen del equipo móvil que se
utilice y de la calidad del ambiente
de radio.
2.4 Real-Time Transport
Protocol, RTP
RTP utiliza el protocolo de
transporte UDP ya que es un protocolo no orientado a la conexión
que aunque no ofrece corrección de
138
errores aprovecha muy bien la velocidad de la red (Schulzrine et al.,
2003, p. 4); tampoco asegura una
recepción correcta de los paquetes
(Postel, 1980, p. 1). Por esta razón
se marca el orden de los paquetes
y el tiempo de reproducción en
la cabecera RTP, así los paquetes
que lleguen fuera de secuencia o
después del instante que se deben
ver o escuchar se descartan para no
estropear la reproducción en curso
con paquetes fuera de orden.
Figura 4. El protocolo RTP en el modelo OSI.
Fuente: Elaboración propia
El protocolo RTP trabaja en la
capa de aplicación del modelo OSI
(Figura 4) contrario a lo que su nombre puede sugerir. Fue diseñado para
la transmisión de datos con características de información en tiempo real
como videoconferencias y voz sobre
IP; brinda soporte a las características de transmisiones RT (real time)
como marcas de tiempo y secuencia
de paquetes, también brinda soporte a características de información
multimedia como tipos de contenido,
CODEC, tasa de bits, entre otras.
La cabecera de un paquete
RTP tiene el formato observado en
la Figura 5, los campos tienen el
siguiente significado:
Versión (V, longitud 2 bits):
identifica la versión de RTP (Schulzrinne et al., 2003, p.13).
Relleno (en inglés padding, P,
long. 1 bit): si el bit de relleno está
activo, el paquete contiene uno o
más bytes de relleno adicionales al
final que no hacen parte de los datos
(Schulzrinne et al., 2003, p.13).
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
Figura 5. Cabecera de un paquete RTP.
Fuente: Elaboración propia
Extensión (X, 1 bit): si está
activo, la cabecera fija debe ser extendida (Schulzrinne et al., 2003).
tenido de este paquete (Schulzrinne
et al., 2003, p.16).
Cantidad de CSRC (CC, 4 bits):
contiene el número de CSRC de la
sesión (Schulzrinne et al., 2003,
p.13).
Marca (M, 1 bit): la interpretación de la marca se define por
el perfil (Schulzrinne et al., 2003,
p.14).
Tipo de contenido de carga útil
(en inglés payload type, 7 bits): formato de la carga útil (Schulzrinne et
al., 2003, p.14).
Número de secuencia (16 bits):
el número de secuencia se incrementa uno a uno por cada paquete
RTP enviado (Schulzrinne et al.,
2003, p.14).
Marca de tiempo (en inglés
timestamp, 32 bits): guarda el instante de muestreo del primer byte
en el paquete RTP (Schulzrinne et
al., 2003, p.14).
SSRC (32 bits): identifica el origen de sincronización (Schulzrinne
et al., 2003, p.16).
Lista de CSRC (0 a 15 elementos, 32 bits cada uno): identifica las
fuentes que contribuyen en el con-
Figura 6. Cabecera de extensión de un paquete RTP.
Fuente: Elaboración propia
Adjunto a la cabecera del paquete RTP se puede agregar una de
extensión, ésta permite implementaciones individuales, para experimentar con funciones de contenidos
independientes que requieren información adicional para transmitirla
en la cabecera RTP.
3. Metodología
3.1 Desarrollo de la aplicación
dad
3.1.1 Esquema de conectivi-
Para el desarrollo de la aplicación se consideró el siguiente
esquema de conectividad.
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
139
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
Figura 7. Arquitectura de red con dispositivos, clases, protocolos y servicios.
Fuente: Elaboración propia
GPRS, los terminales móviles (A,
B y C) y el servidor (D); también
los protocolos, clases y objetos de
la aplicación que intervienen en
la comunicación. Dicho esquema,
pese a que muestra todos los elementos de la red que intervienen
en la comunicación, no muestra
toda la red GPRS y corresponde a
un caso particular donde el móvil A
ha iniciado una sala para transmitir
audio utilizando el servidor D y los
móviles B y C son receptores de
esta sala.
La aplicación consta de dos
componentes el cliente y el servidor.
Figura 8. Esquema de conectividad.
Fuente: Elaboración propia
En el esquema de la Figura 7
se observan elementos de la red
140
3.1.2 Aplicación Servidor
El servidor se desarrolló en
Java SE, requiere un computador
con una dirección IP pública en
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
Internet. Este soporta los servicios
de transmisión de audio y video, a
uno o más clientes.
Para intercambiar contenido
multimedia se crea el concepto de
salas, que consiste en un usuario
emisor que envía el flujo de datos
al grupo de usuarios receptores. La
Figura 8 ilustra el funcionamiento
del concepto de salas. Este diagrama explica las conexiones que se
establecen entre los usuarios que
transmiten multimedia y el servidor,
así como entre este último y los
clientes registrados en una sala.
Los emisores, ubicados a la
izquierda en la Figura 8, necesitan
la dirección IP del servidor para
transmitir y el puerto UDP que les
ha sido asignado al solicitar el servicio. El servidor, a su vez, necesita
la dirección IP y el puerto UDP de
cada uno de los clientes registrados
en cada sala; para así, replicar el
paquete que viene del dispositivo
emisor tantas veces como usuarios
tenga la sala. Para explicar este
caso se subraya el puerto UDP 1721
señalado en el servidor, este puerto
es local y es donde recibe el flujo;
los otros puertos son remotos, por
estos los receptores reciben el flujo
redireccionado del servidor.
3.1.3 Aplicación Cliente
El cliente está diseñado para
ejecutarse en Java ME en un teléfono celular, también puede funcionar
en un computador por medio de un
Emulador. La norma JSR-135 que
especifica la implementación de
MMAPI no define el codificadordecodificador (CODEC) utilizado al
capturar sonido, cada fabricante decide cual implementar (Rantalahti,
2006). El formato más encontrado
es modulación de código de pulso
(Pulse Code Modulation, PCM), es
un CODEC diseñado para codificar
señales digitales, dado que presenta
una gran calidad de sonido con una
baja compresión del flujo final de
datos, éste es el formato utilizado
al capturar sonido.
Como MMAPI no brinda herramientas para grabar video, este
paquete solo permite capturar fotografías en formatos JPEG o PNG,
la aplicación captura imágenes
(JPEG) secuencialmente y las envía
por la red para conseguir el efecto
del video.
Figura 9. Esquema de conexión TCP. Fuente: elaboración propia
El diagrama de conexión TCP
(Figura 9) explica la conexión
entre un cliente y el servidor para
intercambiar datos del control de
los servicios así:
– Se abre un ServerSocket (en el
Servidor D y la clase TCPServer de la Figura 7) en el puerto
9090.
– Una vez montado el servidor:
los clientes pueden conectarse a
él a través de un socket cliente
(clase TCPMobileClient) que
apunta a la dirección IP del
servidor y al puerto especificado
anteriormente.
– Al conectarse el cliente el socket es encapsulado en un hilo
(clase SubThread) para así poder dejar el puerto 9090 abierto
y atender la llegada de nuevos
clientes que soliciten acceder al
sistema. Esta clase gestiona el
control del sistema, por esto se
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
141
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
muestran los flujos de entrada
y de salida como flujos de control.
3.2 Pruebas realizadas
Los requisitos de hardware
y software encontrados durante
el desarrollo de la investigación
fundamentaron la definición de las
pruebas. Los resultados que arrojaron ayudaron a determinar las condiciones mínimas y recomendadas
para el funcionamiento aceptable o
superior de la aplicación.
3.2.1 Definición de pruebas
Las pruebas se diseñaron con
base en dos objetivos: encontrar el
dispositivo móvil que cumple con
las condiciones establecidas y lograr la mejor relación entre calidad/
bytes transmitidos.
Se examinaron celulares de
fabricantes como Ericsson (W600),
Nokia (6101 y 6620), Siemens
(C56) y Motorola (Motorazr); se
encontró que el dispositivo que
mejor se ajustaba era el Nokia
6620, que además de completar los
requerimientos mínimos alcanzaba
algunos recomendados. En este
equipo se realizó la siguiente prueba
para comprobar la disponibilidad de
la tecnología EDGE:
Velocidad de transmisión de
datos: se realizó programando una
herramienta en Java (J2ME) que enviaba paquetes de datos (con 100kb,
200kb y 400kb de tamaño) desde el
celular (en una red EGPRS/GSM)
a un computador con IP fija pública
en Internet utilizando el protocolo
TCP, alcanzamos comunicaciones
de hasta 115kbits/sec. ¡EDGE está
en casa!!! Con esta tasa de transferencia comprobamos que el móvil se
puede conectar a una red EGPRS.
Teniendo en cuenta el esfuerzo
del dispositivo al procesar cada
paquete, la velocidad de la red y
la tasa de pérdida UDP definimos
las siguientes pruebas para mejorar
142
la experiencia del usuario con la
aplicación:
3.2.1.1 Tiempo empaquetado de
audio: el tiempo de empaquetado
afecta la calidad de la reproducción
en las siguientes condiciones:
Si el paquete es muy pequeño,
aumenta la tasa de pérdida y la
cantidad de paquetes que tiene que
procesar el dispositivo móvil se
incrementa consumiendo posiblemente más recursos de los que el
celular ofrece.
Si es muy grande, el tiempo
que demora en llegar el paquete
al Servidor, cuando lo envía el celular y viceversa puede aumentar
significativamente. Así, se pierde
la sensación de una comunicación
en tiempo real porque los datos
no se envían hasta que termina la
grabación.
Esta prueba se realizó en el
móvil ejecutando el módulo cliente, el sonido capturado se codificó
aplicando el CODEC PCM con
muestras a 8KHz y 8 bits por
muestra. El tamaño de cada paquete
varía dependiendo del tiempo de
empaquetado.
3.2.1.2 Retardo entre imágenes: el tiempo transcurrido entre
imágenes afecta la calidad de la
comunicación en los siguientes
escenarios:
Si es muy corto, la cantidad de
imágenes que tiene que procesar el
dispositivo móvil, al enviar o recibir, se incrementa y consume más
recursos de los que el celular ofrece.
También se incrementa la cantidad
de bytes que deben ser transmitidos
por la red, esto ocasiona que aumente el número de paquetes perdidos o
que llegan fuera de tiempo.
Si el tiempo es muy largo, el
número de imágenes que recibe el
móvil disminuye y se perdería la
continuidad entre éstas, entorpeciendo la calidad del video.
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
Las pruebas de video se
realizaron ejecutando el módulo
cliente en el celular; capturando
imágenes de 160x120 píxeles con
24 bits por píxel, comprimidas con
el formato JPEG: se obtuvo un
tamaño aproximado de 6KB por
imagen (paquete).
4. Resultados
Para definir los requisitos
mínimos y recomendados para
instalar y ejecutar la aplicación se
comenzó con una investigación
teórica. Esta sirvió de filtro para
seleccionar los dispositivos que
ofrecieran las exigencias mínimos.
Después de desarrollar pruebas en
los dispositivos que cumplieron
éstos requisitos, se definen los
requerimientos recomendados y se
refinaron los mínimos. El resultado
de este proceso se resume en la
Tabla 3.
De la Tabla 3 sintetizamos
que para ejecutar la aplicación se
requiere que el dispositivo móvil
sea de gama alta: es necesario que
tenga algunas características mínimas como soporte Java, conexión
de datos, cámara, capturar audio y
características más exigentes como
soporte BlueTooth, transferencia de
datos mayor a 64kpbs, entre otras,
son opcionales pero mejoran la experiencia al ejecutar la aplicación.
Los resultados de la prueba de tiempo de empaquetado de audio (numeral
2.2.1.1) se plasman en la Tabla 4.
Las pruebas de video realizadas variando el tiempo entre las
imágenes arrojaron los resultados
mostrados en la Tabla 5
Finalmente se decidió
transmitir paquetes de tres segundos para el sonido y enviar
un frame (imagen) por segundo para obtener una buena relación entre calidad, consumo
en red y procesamiento en los
celulares.
Tabla 3. Requisitos mínimos y recomendados para los celulares
Requisito
Heap Memory
Soporte a Hilos
Cámara
Soporte J2ME
Pantalla a color
Procesador
Conexión de datos
Sistema GSM
Soporte EDGE
Características J2ME
Protocolos
Grabar Audio
Capturar
fotografías
Reproducción
Almacenamiento
Persistente
Bluetooth
Mínimo
Recomendado
1MB
2
Si
Si, MIDP 2.0 y MMAPI
Si, Miles de colores
16 bits
64kbps
Si
Si
Ilimitada
3 o más
Si
Si, MIDP 2.0 y MMAPI
Si, Millones de colores
32 bits
128kbps
Si
Si
Datagram, Capture, Sockets
Si
Datagram, Capture, Sockets
Si, comprimido
Si
Si, también video
Si, audio y video
Si, ambos comprimidos
Si
Si
No
Si
Fuente: Elaboración propia
Tabla 4. Resultados de experimentación con el tiempo empaquetado
Tiempo
empaquetado
(ms)
Bytes enviados
(Bytes/min)
Bytes recibidos
(Bytes/min)
3000
375168
374508
2000
385608
385608
1500
369144
348884
1000
302080
265096
750
267584
156452
500
190330
70356
400
21957
ERROR
Calidad de la reproducción
Se entiende bastante pese al retardo que hay
entre grabaciones. No se nota mucho la pérdida de
paquetes de voz. El tamaño de cada paquete oscila
entre 20500 y 22600 bytes.
Se entiende el audio pero se va nota más el espacio
entre grabaciones. El tamaño de cada paquete
oscila entre 12400 y 14600 bytes.
No es tan clara la transmisión, se nota la pérdida
de paquetes. El tamaño de cada paquete es
aproximadamente 10260 bytes.
Se torna fastidioso al no poder entender lo que
se transmite. Haciendo un cálculo generoso
diríamos que solo se escucha la mitad de lo
que se transmite. El tamaño de cada paquete es
aproximadamente 6164 bytes.
No se entiende nada, hay que hacer un esfuerzo
para tratar de descifrar lo que se transmite. El
tamaño de cada paquete es aproximadamente 4116
bytes.
No se entiende absolutamente nada con la llegada
de paquete tras paquete tan rápidamente.
A los pocos segundos de recibir ocurre un error
al no entender los paquetes que llegan (son muy
pequeños)
Fuente: elaboración propia
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009
143
Desarrollo de una aplicación en JavaME que permita el intercambio de contenido multimedia
usando el protocolo RTP sobre la red EGPRS-GSM
Joswill Pájaro • Dahyr Vergara • Yezid Donoso
Tabla 5. Resultados de experimentación de video variando el retardo entre frames
Retardo entre
frames(ms)
Bytes enviados
(Bytes/min)
Bytes recibidos
(Bytes/min)
3000
73253
69220
2000
1500
107632
136880
103401
136880
1000
177552
177552
750
500
400
224365
282712
328041
220363
282712
328041
300
371309
367240
Calidad de la reproducción
Se entienden las imágenes y llegan en intervalos de tiempo regulares, pero ese tiempo es muy largo y se
torna molesto.
Siguen siendo tiempos regulares y es un poco menos desagradable
Se obtiene una buena calidad de video
Mejora rendimiento, dado que los tiempos entre imágenes siguen siendo regulares, pero ya es bastante
agradable el flujo de la secuencia de imágenes
El tiempo entre imágenes empieza a ser irregular, lo que molesta un poco, pero aún la calidad es buena
El tiempo entre imágenes es irregular y no se muestran algunas imágenes
Se omiten muchas imágenes, lo que hace parecer que la grabación ha sido pausada cuando no es así
No se entiende nada porque llegan mas paquetes de los que puede procesar
el celular
Fuente: Elaboración propia
5. Conclusiones
En este artículo se presentó
una aplicación que permite intercambiar contenido multimedia,
esta transferencia de datos se
realizó entre dispositivos móviles (teléfonos celulares) y computadores. Para esto se utilizó la
red de telefonía celular GSM, la
tecnología EDGE y la Internet al
transmitir los datos. Al instalar
la aplicación se encontró que
los teléfonos celulares necesitan
cumplir unos requerimientos mínimos y preferiblemente alcanzar
los requerimientos recomendados. Dados los requisitos, estos
equipos se pueden considerar de
gama alta.
Se utilizaron los protocolos
UDP para el contenido multimedia y el TCP para los datos de
control. También se implementó
el protocolo RTP en JavaME para
encapsular la información de audio y video. Estos protocolos se
apoyan en el protocolo IP para el
direccionamiento, debido a esto
es posible pronosticar su funcionamiento en redes nuevas que
los soporten. Con experimentos
desarrollados en el laboratorio
se pudo ejecutar la aplicación
emulando la transferencia inalámbrica de los datos con una
red de área personal BlueTooth
144
(Personal Area Network, PAN).
Así se demostró la flexibilidad de
la aplicación con las capas bajas
de la arquitectura de la red.
En la definición del paquete
opcional Mobile Media API se
especifica que su implementación
requiere de un reproductor de sonido y de video, pero no especifica
el CODEC que debe utilizar. Para
lograr una aplicación común a la
mayoría de dispositivos se utilizó
el CODEC PCM que ofrece una
buena calidad de sonido con baja
compresión. Como el video en
MMAPI solo se puede visualizar,
mas no permite grabarlo, se suplió
esta necesidad capturando fotografías en formato JPEG y enviándolas
secuencialmente para lograr el
efecto del video.
Como trabajo futuro se propone
la implementación de CODEC que
brinden una mejor relación entre
calidad y compresión del contenido (audio o video), esto permite
optimizar el uso de la red y mejorar
la experiencia del usuario; migrar
la aplicación a otras plataformas
enfocadas a dispositivos móviles
como Symbian OS y Windows CE.
También se sugiere el desarrollo de
una aplicación en Java ME que dada
una secuencia de imágenes genere
un flujo de datos codificado con un
CODEC de video.
Bibliografía
De Wulf, Martin (2001). Un logiciel
d’illustration des protocoles GSM
et GPRS sur la voie radio. Namur,
Belgique, 93 p. Trabajo de Grado
(maître en informatique). Facultés
Universitaires Notre-Dame de la
Paix. Institut d’Informatique.
Ericsson, Edge (2003) Introduction of
high-speed data in GSM/GPRS networks. ERICSSON Ed., Suecia.
Juntao, Michael (2003). Enterprise J2ME:
Developing mobile Java applications. Prentice Hall PTR.
Knudsen, Jonathan (2003). Wireless Java
Developing with J2ME, Second Edition. Apress.
Piroumian, Vartan (2002). Wireless
J2ME™ Platform Programming.
Prentice Hall PTR. 293 p.
Postel, J (1980). User Datagram Protocol,
USC/Information Sciences Institute,
RFC 0768.
Rantalahti, Antti (2006). Documentación
de la Especificación Mobile Media
API (JSR-135). http://java.sun.com/
(4 dic. 2006).
Rysavy, Peter (2005). Data capabilities:
GPRS to HSDPA and beyond. 3G
Americas.
Schulzrinne, Henning et al. (2003). RTP:
A Transport Protocol for Real-Time
Applications, IETF/Network Working Group, RFC 3550.
El Hombre y la Máquina No. 33 • Julio-Diciembre de 2009