BENEMERITA UNIVERSIDAD AUTONOMA DE PUEBLA

FACULTAD DE CIENCIAS DE LA COMPUTACION

SIMULACIÓN DEL CONTROL DE UN ROBOT MOVIL A TRAVÉS DE

GSM

TESIS PROFESIONAL

PARA OBTENER EL TITULO DE LICENCIADO EN CIENCIAS DE LA

COMPUTACION

PRESENTA

CRISOFORO PAISANO OSORIO

ASESOR:

Dr. RODRIGO MONTÚFAR CHAVEZNAVA

COASESOR:

Dr. MIGUEL ANGEL LEÓN CHÁVEZ

1
2
 Índice
Introducción…………………………………………………………………………………3

1.-Teléfono celular…………………………………………………………………………..6
1.1.- Surgimiento del teléfono celular………………………………………………….……6
1.2.- Funcionamiento y aplicaciones de un teléfono celular………………………………...7
1.3.- Infraestructura de la red Celular………………………………………………… …..10
1.4.- Tonos telefónicos……………………………………………………………………..11

2.- Sistema global para comunicaciones móviles (GSM)………………………………….13

2.1.- Antecedentes e historia del sistema global para comunicaciones móviles……….…..13
2.2.- Arquitectura de la red GSM………………………………………………………….14

3.- Servicio de Mensajes cortos (SMS)…………………………………………………….18

3.1.- Estructura de SMS…………………………………………………………………...18
3.2.- Funcionamiento de SMS……………………………………………………………...19
3.3.- Servicio de Mensajes Multimedia (MMS)……………………………………………23

4.- Control del robot……………………………………………………………………….24

4.1.- Antecedentes del robot………………………………………………………………..24
4.2.- Características del robot ……………………………………………………………...27
4.3.- Simuladores del robot………………………………………………………………...27
4.3.1.- Simulador Saphira…………………………………………………………………..27
4.3.2.- Simulador Stage Player……………………………………………………………..28
4.3.3.- Simulador Java Mobile Robots (JMR)……………………………………………..28

5.-Simulador Java Mobile Robots (JMR)………………………………………………….30

5.1.- Características del simulador JMR…………………………………………………...30
5.2.- Funcionamiento del simulador JMR………………………………………………….30

6.- Sistema de simulación del teléfono celular……………………………………………..39

6.1.- Planteamiento del sistema SimGSM…………………………………………………39
6.2.- Proceso de Modelado del sistema SimGSM…………………………………….........42
6.2.1.- Modelo de Análisis…………………………………………………………………43
6.2.2.- Modelo de Diseño…………………………………………………………………..50
6.2.3.- Modelo de Implementación………………………………………………………...64
6.2.4.- Modelo de Pruebas y Resultados …………………………………………………..77

7.- Interfaz entre simuladores………………………………………………………………78

7.1.-SimGSM………………………………………………………………………………78
7.2.- Java Mobile Robots (JMR)…………………………………………………………...80

8.- Conclusiones y Observaciones…………………………………………………………83

Bibliografía ………………………………………………………………………………116

1
Apéndice 1: Funcionamiento del Sistema GSM y Arquitectura del Protocolo…………...84

Apéndice 2: Manual de usuario JMR (Java Mobile Robots)………………………………98

2
Introducción
El gran avance de la tecnología en el campo de la telefonía celular ha permitido realizar
distintas aplicaciones tales como la transmisión de voz, datos, audio y video con algunas
limitaciones. Con ayuda del sistema global para comunicaciones móviles, al teléfono móvil
se le han agregado cada vez más funciones tales como el servicio de mensajes cortos, entre
otros más.

Con estos servicios surge la idea de controlar un robot por medio de un teléfono celular
con tecnología GSM. Esta idea consiste en que el usuario pueda controlar el robot desde
donde se encuentre, estableciendo la comunicación a través del sistema de telefonía celular.

La solución a la idea propuesta anterior consiste en lo siguiente:

De un simulador de un controlador para un robot móvil, el cual hará las funciones de un
teléfono celular con tecnología GSM (SimGSM). Este simulador deberá interactuar con
otro sistema existente, el simulador del robot móvil (SimRobot), de modo que la
interacción entre ambos sea transparente para su uso posterior con el robot físico, un
Pioneer 2. El Pioneer2 es un robot que pertenece a la familia de robots móviles.

SimRobot recibe de SimGSM los comandos que a continuación se mencionan:

• Adelante
• Gira

Con el comando adelante se especifica la distancia que se desea mover al robot y dicha
distancia es medida en milímetros. Con respecto al comando gira se debe indicar el
número de grados que se desea que gire el robot.

SimRobot lleva a cabo dichos comandos, además puede enviar la información del estado
del robot a SimGSM.

El SimGSM consta de los siguientes módulos:

1. Teléfono celular con tecnología GSM.
2. MODEM GSM
3. Centro de servicio de mensajes cortos (SMSCYCT).

El módulo 1 asemeja a un teléfono celular, a partir del cual el usuario puede establecer
la comunicación con el robot, en este módulo se muestran los datos del SimRobot, ya sea el
estado del robot, así como el envió y recepción de mensajes para el control del robot, al
igual que el envío de tonos. Con lo anterior podemos ver que contamos con dos maneras de
realizar el control del robot: (1) estableciendo comunicación directa y empleando tonos y
(2) a través del envío de mensajes.

El simulador del robot cuenta con una cámara para obtener las imágenes del mundo en que
se encuentra. Para obtener la distancia del robot a los obstáculos se usan los sónares que

3
posee el robot, la velocidad de adquisición del sonar es de 25Hz y el rango de sensibilidad
del sónar va desde 10cm a aproximadamente 5m.

El módulo 2 simula un MODEM GSM, el cual está conectado con el simulador del robot
(SimRobot).

El módulo 3 simula el funcionamiento del centro de servicios de mensajes cortos (Short

Message Service Center, SMSC) el cual se encarga del envío de este tipo de mensajes, así
como también la central telefónica.

Los módulos se relacionan como lo muestra la figura 1.

Modulo1
Modulo2
GSM
Modulo3 MODEM
Robot

Central de Servicio de
Mensajes Cortos y Central
Telefónica (SMSCYCT)

Figura1: Esquema del sistema SimGSM.

Como se muestra en la figura 1, si el comando que se va a enviar es por tonos, entonces el

teléfono celular se conecta a la red de telefonía GSM y de ahí con el MODEM GSM el
cual se conecta a su vez con el simulador del robot. Pero si el comando es enviado como
mensaje corto entonces se establece la conexión al centro de Servicios de mensajes cortos
y después se conecta con el MODEM GSM. La forma en que son enviados los comandos
es decisión del usuario.

Algunas de las aplicaciones que se han desarrollado con este tipo de teléfonos celulares,
sólo por mencionar tenemos la siguiente:
Se trata de un notificador GSM el cual es un equipo para el envío de mensajes cortos
(mensajes de texto) a teléfonos móviles GSM.

Algunas de las aplicaciones en las que podemos usar este notificador GSM son:

Con ayuda de un termostato, la alerta del riesgo de heladas

El aviso de la abertura de puertas o ventanas ya sea en nuestra casa o
en el trabajo.

4
El resto de la tesis está constituida de la siguiente manera.

En el capítulo 1 tratamos los antecedentes del teléfono celular con tecnología GSM.
También se explica el funcionamiento de un teléfono móvil y algunas de sus aplicaciones.

En el capítulo 2 explicamos como surge la tecnología GSM, sus antecedentes y su historia,

así como también vemos sus características y el funcionamiento de dicha tecnología.

En el capítulo 3 se presenta el servicio proporcionado por la tecnología GSM que es el

servicio de mensajes cortos (SMS short message service). En este capítulo se analiza la
estructura de este servicio y su funcionamiento, así como también el servicio de mensajes
multimedia.

En el capítulo 4 tratamos aspectos relacionados con el simulador de las funciones del robot
Pioneer 2, tales como los antecedentes de un robot, así como la historia de cómo surgió, sus
características y el funcionamiento del simulador.

En el capítulo 5 se dá una breve explicación de cómo funciona el simulador JMR (Java

Mobile Robots).

En el capítulo 6 se desarrolla la ingeniería de software para el sistema.

Se explican los modelos de análisis, diseño, implementación y pruebas realizadas.

En el capitulo 7 se describe la interfaz del simulador del robot así como también la interfaz
del simulador realizado.

En el capítulo 8 se dan las conclusiones del trabajo desarrollado y sus perspectivas.

5
Capitulo 1

Teléfono Celular
1.1.- Surgimiento del Teléfono Celular

Las tecnologías inalámbricas han tenido su auge y desarrollo en estos últimos años. Una de
las que ha tenido un mayor desarrollo ha sido la telefonía celular. Uno de los aspectos más
interesantes del teléfono celular es que se trata solamente de un radio extremadamente
sofisticado [1].

A pesar de que la telefonía celular fue concebida estrictamente para la voz, la tecnología
celular de hoy es capaz de brindar otro tipo de servicios, como la transmisión de datos,
audio y vídeo con algunas limitaciones.

La telefonía celular se ha desarrollado a lo largo de diferentes generaciones:

La primera generación (1G).

La 1G de la telefonía móvil hizo su aparición en 1979 y se caracterizó por ser analógica y

estrictamente para voz.

La segunda generación (2G)

La 2G arribó hasta 1990, y a diferencia de la primera se caracterizo por ser digital.

El sistema 2G utiliza protocolos de codificación más sofisticados y se emplea en los

sistemas de telefonía celular actuales.

La tercera generación (3G)

La 3G se caracteriza por contener alta convergencia de voz y datos con acceso

inalámbrico a Internet; en otras palabras, es apta para aplicaciones multimedia y altas
transmisiones de datos.

Los protocolos empleados en los sistemas 3G soportan altas velocidades para la

transmisión de información y están enfocados para aplicaciones más allá de la voz como
audio (MP3), video en movimiento, videoconferencia y acceso rápido a Internet, sólo por
mencionar algunas [2].

6
1.2.- Funcionamiento y Aplicaciones de un Teléfono Celular

Una de las cosas más interesantes acerca de los teléfonos celulares es que en realidad son
radios, unos radios extremadamente sofisticados, pero radios al fin y al cabo [1].

Una buena forma de entender la sofisticación de un teléfono celular es compararlo con un

radio de onda corta (OC) o con radio de doble vía. Un radio OC es un aparato simple. Este
permite que dos personas se comuniquen utilizando la misma frecuencia, así que sólo una
persona puede hablar a la vez. Un teléfono celular es un dispositivo dual, esto quiere decir
que utiliza una frecuencia para hablar, y una segunda para escuchar. Una radio OC tiene 40
canales. Un teléfono celular puede utilizar 1664 canales. Estos teléfonos también operan
con "células" y pueden alternarse a medida que el teléfono se desplaza. Las células le dan a
los teléfonos un rango increíble. Un radio de doble vía puede transmitir quizás hasta dos
millas. Un radio OC, debido a que tiene un poder mucho más alto, puede transmitir hasta
cinco millas. Alguien que utiliza un teléfono celular, puede manejar a través de toda la
ciudad y mantener la conversación todo el tiempo. Las células son las que dan a los
teléfonos celulares un gran rango.

El teléfono celular estándar llamado AMPS (Advanced Mobile Phone System, o sistema de
telefonía móvil avanzada) fue aprobado y usado por primera vez en Chicago en 1983. El
estándar estableció un rango de frecuencias entre los 824 y los 894 Megahertz para
teléfonos análogos. Para enfrentar la competencia y mantener los precios bajos, este
estándar estableció el concepto de dos portadores en cada mercado, conocidos como
portadores A y B. A cada portador se le dá 832 frecuencias de voz, cada una con una
amplitud de 30 Kilohertz. Un par de frecuencias (una para enviar y otra para recibir) son
usadas para proveer un canal dual por teléfono. Las frecuencias de transmisión y recepción
de cada canal de voz están separadas por 45 Megahertz. Cada portador también tiene 21
canales de datos para usar en otras actividades [3].

Hace tiempo, antes de la aparición de los teléfonos celulares, la gente utilizaba radio
teléfonos en sus autos. En los sistemas de radio teléfono existía una antena central por
ciudad y 25 canales disponibles para esa antena. Esta antena central implicaba que su auto
tuviera un transmisor muy potente lo suficiente como para transmitir por 40 o 50 millas.
Esto también significaba que no mucha gente podía usar radio teléfonos, simplemente no
había los suficientes canales.

La gran idea del teléfono celular reside en que una ciudad puede ser dividida en pequeñas
"células" que permiten extender la frecuencia por toda una ciudad.

La comunicación móvil celular se basa en el concepto de la reutilización de la frecuencia.

Es decir, el espectro limitado asignado al servicio se reparte, por ejemplo, el canal N fijo
sin traslape, que entonces se asigna en un patrón repetido regular a una rejilla de células
hexagonales. El hexágono es sólo una idealización conveniente que se aproxima a la de un
círculo pero forma una rejilla sin espacios ni traslapes como es mostrado en la figura 1.1.
La elección de N depende de varios aspectos que incluyen el ambiente de la propagación, la
distribución del tráfico, y los costos locales. El ambiente de la propagación determina la
interferencia recibida de las células vecinas del co-canal que alternadamente determina la

7
distancia de la reutilización, es decir, la distancia permitida entre las células del co-canal
(células usando el mismo sistema de canales de frecuencia).

Figura 1.1: Esquema de las células.

La determinación del tamaño de la célula se basa generalmente en la distribución y la

demanda del tráfico local. Cuanto mayor es la concentración de la demanda del tráfico en el
área, el tamaño de la célula tiene que ser más pequeño a fin de beneficiar la frecuencia
situando a un número menor de suscriptores roaming y así de esta manera, se limita la
probabilidad de bloqueo de la llamada dentro de la célula. Por otra parte, cuanto más
pequeño es el tamaño de la célula, más equipo se necesitará en el sistema ya que cada
célula requiere del equipo necesario de transceptor y conmutador, éste es conocido como el
subsistema de estación base (BSS), a través del cual el usuario móvil accede a la red a
través de enlaces de radio. El grado en el cual el espectro de frecuencia asignado es
reutilizado sobre el área de servicio celular, determina la eficiencia del espectro en los
sistemas celulares. Esto significa cuanto más pequeño es el tamaño de célula, y cuanto más
pequeño es el número de células en la geometría de la reutilización, será más alta la eficacia
del uso del espectro. Puesto que los sistemas de modulación digital pueden funcionar con
una señal más pequeña de interferencia para la misma calidad del servicio, ésta permitirá
una distancia más pequeña de la reutilización y proporcionará así una eficacia más alta del
espectro. Ésta es una ventaja que el celular digital proporciona sobre los más viejos
sistemas celulares análogos de comunicación por radio. Cada célula es típicamente de un
tamaño de 10 millas cuadradas [35].

Debido a que los teléfonos celulares y las estaciones base utilizan transmisores de bajo
poder, las mismas frecuencias pueden ser reutilizadas en células no adyacentes.

Cada célula tiene una estación base que consta de una torre y un pequeño edificio en donde
se tiene el equipo de radio. Cada célula utiliza un séptimo de los 416 canales duales de voz.
Entonces, cada célula tiene más o menos 59 canales disponibles. En otras palabras, con una
célula pueden hablar 59 personas al mismo tiempo.

8
Los teléfonos celulares poseen transmisores de baja potencia dentro de ellos. Muchos
teléfonos celulares tienen dos intensidades de señal: 0.6 Watts y 3 Watts (en comparación,
la mayoría de los radios de banda civil transmiten a 4 Watts). La estación base también
transmite a baja potencia. Los transmisores de baja potencia tienen dos ventajas:

1. El consumo de energía del teléfono, que generalmente funciona con baterías,

es relativamente bajo. Esto significa que la baja potencia requiere de baterías
pequeñas, y ésto hace posible que existan teléfonos que caben en la mano.

2. Las transmisiones de las estaciones base y de los teléfonos no alcanzan una

distancia más allá de la célula. Es por esto que, en cada celda de la figura 2.1
se pueden utilizar las 59 frecuencias. Las mismas frecuencias pueden ser
reusadas por toda la zona.

La tecnología celular requiere de un gran número de estaciones base para ciudades de

cualquier tamaño. Una típica ciudad grande puede tener cientos de torres emisoras. Pero
debido a que hay tanta gente utilizando teléfonos celulares, los costos se mantienen bajos
para el usuario. Cada portador en cada ciudad tiene una oficina central llamada MTSO
(Mobile Telephone Switching Office). Esta oficina maneja todas las conexiones telefónicas
y las estaciones base de la región [4].

Vale mencionar que los sistemas digitales han utilizado comúnmente sectores de células
con 120 grados o antenas direccionales más pequeñas a distancias más lejanas, más baja es
la efectividad de la reutilización. Esto permite un número más pequeño de células en el
patrón de la reutilización y hace una fracción más grande del espectro total de la frecuencia
disponible dentro de cada célula.

Digamos que si tenemos un teléfono celular, lo encendemos, y alguien nos trata de llamar,
la MTSO recibe la llamada, y trata de encontrarnos. En primera instancia, la MTSO nos
tratará de encontrar activando el teléfono (utilizando uno de los canales de control, ya que
el teléfono se encuentra siempre escuchando) en cada célula de la región hasta que el
teléfono responda. Entonces la estación base y el teléfono deciden cuál de los 59 canales en
el teléfono celular usarán. Ahora estamos conectados a la estación base y podemos empezar
a hablar y escuchar.

A medida que nos movamos en la célula, la estación base notará que la fuerza de la señal
disminuye. Entre tanto, la estación base de la célula hacia la que nos estamos moviendo
(que está escuchando la señal) será capaz de notar que la señal se hace más fuerte. Las dos
estaciones base se coordinan a sí mismas a través del MTSO, y en algún punto el teléfono
obtiene una señal que le indica que cambie de frecuencia. Este cambio hace que el teléfono
mude su señal a otra célula.

En los sistemas modernos, los teléfonos esperan una señal de identificación del sistema
(IDS) del canal de control cuando se encienden. El teléfono también transmite una
propuesta de registro y la red mantiene unos datos acerca de su ubicación en una base de
datos (de esta forma es que la MTSO sabe en que célula nos encontramos si quiere timbrar

9
nuestro teléfono). A medida que nos movamos entre células, el teléfono detecta los cambios
en la señal, los registra y compara con los de la nueva célula cuando cambia de canal. Si el
teléfono no puede hallar canales para escuchar se sabe que está fuera de rango y muestra un
mensaje de "sin servicio".

La última tendencia son los teléfonos celulares digitales. Utilizan la misma tecnología
radial (en diferentes bandas de frecuencia -por ejemplo, los teléfonos PCS utilizan
frecuencias entre los 1.85 y 1.99 Gigahertz-) pero comprimen su voz en unos y ceros. Esta
compresión permite que entre 3 y 10 llamadas telefónicas ocupen el espacio de una simple
voz análoga. Estos aparatos también ofrecen otras características como correo electrónico y
agenda.

1.3.- Infraestructura de la Red Celular

El concepto de red celular es basado en la superposición de una arquitectura de red tipo

estrella sobre la infraestructura de comunicación telefónica fija existente (landline). La red
de la telefonía se utiliza para proporcionar no solamente enlaces de comunicación entre un
usuario móvil y un usuario fijo, sino también para proporcionar la conectividad entre los
usuarios móviles que vagan en células remotamente localizadas o en el dominio de las
redes móviles operadas por diversos proveedores de servicio. Las BSS’s, proporcionan la
administración de los recursos de radio, y la conmutación entre los canales de radio y las
ranuras de TDM (multiplexion por división de tiempo) en sus conexiones con el centro de
conmutación móvil (MSC). MSC enlaza grupos de BSS’s vecinos a través de punto a
punto landline o microondas E1. El MSC actúa como el centro del nervio del sistema. Este
controla el marcado y procesado de la llamada, y coordina el handover1 de la conexión
móvil a partir de una estación base a otra mientras que el móvil vaga alrededor. Cada MSC
alternadamente está conectado con la red pública local de conmutación telefónica
(PSTN/ISDN) para proporcionar la conectividad entre usuarios móviles y los usuarios de
teléfonos fijos, además de la conectividad global necesaria entre el MSC’s de la red móvil
celular. Esto es pensado para permitir a cualquier usuario móvil comunicarse con cualquier
otro usuario móvil o de telefonía fija en el mundo. Así, la conectividad global
proporcionada por la infraestructura telefónica landline existente es utilizada para enlazar a
los suscriptores de celulares móviles por todo el mundo [35].

Los enlaces directos entre ciertas MSC’s "locales" pueden también proporcionarse para
permitir la comunicación entre dos usuarios móviles, evitando a la red de la telefonía
cuando hay una circulación de tráfico considerable entre los usuarios móviles que vagan en
las áreas bajo la cobertura de estos MSC’s.

Así, la trayectoria de comunicación entre dos usuarios móviles que vagan bajo cobertura de
dos MSC' s locales puede ó no puede cambiar a través de la red pública de telefonía. Esto
depende de la conectividad proporcionada entre las dos MSC’s. El MSC puede también
conectar con las redes de datos públicas (PDN).

1
Este se da cuando una llamada en progreso puede cruzar la frontera de la celda adyacente. En este, un nuevo
canal debe ser asignado a la llamada en la nueva celda para evitar una terminación forzada de la llamada.

10
1.4.- Tonos Telefónicos

Tono dual de múltiples frecuencias (DTMF), también conocido como marcación por
tonos (Touch Tone) es utilizado para señales telefónicas en la banda de frecuencias de la
voz hacia el centro de conmutación de la llamada.

Antes del DTMF los sistemas telefónicos utilizaban una serie de clics sobre la línea
telefónica para la marcación de los números, este sistema es conocido como marcación por
pulsos. Los clics eran realmente los que empezaban ó rompían la conexión en la línea
telefónica, equivalía a mover un interruptor de luz a prendido ó apagado.

DTMF fue desarrollado en los laboratorios Bell a fin de permitir a la señal de marcado el
empleo de números de larga distancia, y la posibilidad de reestablecer enlaces inalámbricos
a través de microondas ó de satélites. Los codificadores/decodificadores fueron agregados a
las terminales que convertirían el pulso estándar en tonos de DTMF y los pondrían de
vuelta a la terminal remota. En el sitio remoto otros codificadores/decodificadores
descifrarán los tonos y los cambiarán a una serie de clics. Esto era como si se estuviera
conectado directamente a la terminal, las señales trabajarían sobre cualquier clase de
conexión. Esta idea de usar la red existente para señales así como para mensajes se conoce
como in-band signaling.

El sistema Touch Tone también introdujo una disposición de estandarización del teclado.
Después de probar no menos de 18 diversas disposiciones, se eligió uno que eventualmente
sigue siendo similar a los que hoy se usan, con un 1 en la parte superior izquierda y 0 en el
fondo.

Los ingenieros también habían previsto que los teléfonos podrían ser utilizados para tener
acceso a las computadoras, y examinaron un número de compañías para ver lo que
necesitarían para este papel. Esto condujo a la adición de las teclas (#) y el asterisco (*), así
como también un grupo de teclas para la selección del menú, A, B, C y D

Los militares de los Estados Unidos también utilizaron las letras en su sistema de teléfono
Autovon. Aquí las utilizaron antes de marcar un número en el teléfono para darle prioridad
a algunas llamadas, cortando las llamadas existentes si era necesario. La idea era permitir
que el tráfico importante llegara a su destino. Por ejemplo, presionando C, inmediatamente,
antes de marcar haría que el interruptor primero busca cualquier línea libre, y si todas las
líneas estuvieran en uso, colgaría cualquier llamada no prioritaria, y después cualquier
llamada de prioridad, esto quiere decir que primero buscaría una línea libre en tal caso de
no encontrar entonces busca una llamada que no tiene prioridad y si no encontrara alguna,
posteriormente buscara una llamada de prioridad inferior a la prioridad marcada y colgaría
dicha llamada. Si bien el sistema telefónico Autovon ya no existe, se conservan sus nombres
originales que eran (A) “Flash Override”, (B) “Flash”, (C) de inmediato, y (D) la prioridad.
Con presionar una de estas teclas se da prioridad a la llamada, eliminando las otras
conversaciones sobre la red. “Flash Override” es la prioridad más alta.

11
El teclado numérico de DTMF se presenta en una matriz 4 x 4 con cada fila que representa
una frecuencia baja, y cada columna que representa una frecuencia alta. Presionar una sola
tecla tal como '1 'enviará un tono senosoidal de dos frecuencias: 697 y 1209 hertz. Los dos
tonos son la razón de porque se llama multi-frecuencia. Estos tonos entonces son
descifrados por el centro de conmutación para determinar que tecla fue presionada.

En la tabla 1 se presenta un esquema de las bajas y altas frecuencias.

Tabla1) Frecuencias Del Teclado numérico de DTMF

1 2 3 A 697 hertz
4 5 6 B 770 hertz
7 8 9 C 852 hertz
* 0 # D 941 hertz
1209 hertz 1336 hertz 1477 hertz 1633 hertz

Las frecuencias fueron diseñadas inicialmente con un cociente de 21/19, que es levemente
menor que un tono entero, para evitar los armónicos o las frecuencias naturales que podrían
ocurrir cuando se envían los dos tonos. Las frecuencias pueden no variar más que +/- 1.5%
de su frecuencia nominal, o el centro de la conmutación no hará caso de la señal. Los tonos
de alta frecuencia pueden tener el mismo volumen o tener más ruido que los tonos de bajas
frecuencias cuando se están enviando a través de la línea. La diferencia de la intensidad
entre las frecuencias altas y bajas puede ser tan grande como 3 decibeles (dB) y se refiere
como twist [5].

12
Capitulo 2

Sistema Global para Comunicaciones Móviles (GSM)

2.1.- Antecedentes e historia del sistema global para comunicaciones móviles

En el inicio de los años 80, después de que el NMT (“Nordic Mobile Telephone”), el
sistema de telefonía móvil analógico de cobertura escandinava, tuviera éxito, los sistemas
analógicos existentes, tenían limitaciones. Primera, ante la gran demanda de los servicios
móviles, la capacidad de las redes analógicas existentes no era suficiente. Segunda, las
diversas formas en las que opera este tipo de sistema no hacia posible una compatibilidad
entre los usuarios de móviles, por ejemplo: una terminal TACS (servicio de telefonía móvil
analógico puesto en funcionamiento en el Reino Unido en 1985) no podía acceder dentro de
una red NMT, y viceversa. Además, el diseño de un nuevo sistema de telefonía celular
requiere tal cantidad de investigación que ningún país europeo podía afrontarlo de forma
individual. Todas estas circunstancias apuntaron hacia el diseño de un nuevo sistema, hecho
en común entre varios países.

El principal requisito previo para un sistema de radio común es el ancho de banda de radio.
Esta condición había sido ya prevista unos pocos años antes, en 1978, cuando se decidió
reservar la banda de frecuencia de 900 ± 25 MHz para comunicaciones móviles en Europa.

Este problema fue el mayor obstáculo solucionado. Quedaba organizar el trabajo. El mundo
de la telecomunicación en Europa siempre había estado regido por la estandarización. La
CEPT ("Conférence Européene des Postes et Télécommunications") es una organización
para la estandarización presente en más de 20 países europeos. Todos estos factores
llevaron a la creación en 1982 de un nuevo cuerpo de estandarización dentro de la CEPT,
cuya tarea era especificar un único sistema de radiocomunicaciones para Europa a 900
MHz. El recién nacido "Groupe Spécial Mobile" (GSM) tuvo su primer encuentro en
Diciembre de 1982 en Estocolmo, bajo la presidencia de Thomas Haug de la administración
sueca. Treinta y una personas de once países estuvieron presentes en este primer encuentro.
En 1990, por requerimiento del Reino Unido, se añadió al grupo de estandarización la
especificación de una versión de GSM a la banda de frecuencia de 1800 ± 75 MHz. A esta
variante se le llamó DCS1800 ("Digital Cellular System 1800"). En los Estados Unidos, la
FCC (Federal Communications Comission) decidió abrir partes de las frecuencia de los
1900 Mhz para usos móviles, con la elección del sistema por parte de las operadoras. El
PCS1900 fue entonces desarrollado, una variante del GSM para aprovechar la oportunidad
recién abierta en el mercado norteamericano (en el que la mayoría de las operadoras utiliza
el CDMA). En Noviembre de 1995 el primer servicio PCS1900 fue lanzado en los Estados
Unidos Americanos [6].

Actualmente los sistemas GSM900/1800/1900 son utilizados en 135 países, con 345
millones de utilizadores diseminados por 366 redes. El reciente lanzamiento de terminales
tribanda (que operan en la frecuencia 900, 1800 y 1900 Mhz) posibilita capacidades de

13
roaming cada vez mayores, ya que los usuarios pueden utilizar las tres frecuencias
disponibles en los cinco continentes. El significado actual de las siglas GSM ha cambiado
y en la actualidad corresponden a "Global System for Mobile communications" 7 .

2.2.- Arquitectura de la red GSM

El Sistema Global para Comunicaciones Móviles (GSM) posee una serie de características
que lo diferencian dentro del universo de las comunicaciones móviles. Nacido en los años
80 fruto de una cooperación sin precedentes en Europa, el sistema comparte elementos
comunes con otras tecnologías utilizadas en la telefonía móvil, como la transmisión digital
de voz y datos y la utilización de células. A continuación se explican las características
técnicas fundamentales del sistema, así como sus capacidades.

Una red GSM está constituida por los siguientes tres elementos: la terminal, la estación-
base (BSS) y el subsistema de red o nodo. Adicionalmente existen centros de operación
establecidos por las operadoras, para vigilar el estado de la red.

La estación móvil o terminal contiene la tarjeta del Módulo de Identificación de Suscriptor

(SIM,”Subscriber Identity Module”), que es utilizada para identificar el usuario dentro de la
red. El SIM confiere movilidad personal al usuario de la tarjeta, permitiéndole acceder a los
servicios de la red independientemente del teléfono móvil que use o de su localización. El
SIM puede ser protegido contra uso indebido a través de un código llamado número de
identificación personal (PIN, “personal identity number”) que hay que marcar cada vez que
se conecta el móvil con el SIM insertado. Existe además un número que identifica cada
terminal individualmente, el International Mobile Susbcriber Identity (IMEI), pero que es
independiente del SIM.

La estación-base controla la conexión de radio entre el teléfono celular y la red y es

también conocida por célula, ya que cubre una determinada área geográfica. Un subsistema
de estación base (BSS,” base station subsystem”) está compuesta por dos elementos: la
estación transrecibidora de base (BTS,”Base Transceiver Station”) y la estación base de
control (BSC,” Base Station Controler”). Cada BSS puede tener una o más BTS. Las BTS
albergan el equipo de transmisión / recepción (los TRX o transceivers) y gestionan los
protocolos de radio con la terminal móvil. En las áreas urbanas existen más BTS que en
zonas rurales y en algunos casos en lugares con características físicas o geográficas
particulares (como por ejemplo, en túneles) son colocados retransmisores para garantizar el
servicio. Cada estación utiliza técnicas digitales para permitir que varios usuarios se liguen
a la red, así como para permitir que hagan y reciban llamadas simultáneamente. Esta
gestión se denomina de multiplexado.

El BSC administra los recursos de radio de una o más BTS. Entre sus funciones se incluyen
el “handoff” (que ocurre cuando el utilizador se mueve de una célula para otra, permitiendo
que la conexión se mantenga), el establecimiento de los canales de radio utilizados y los
cambios de frecuencias. Finalmente, establece la conexión entre el teléfono celular y la
Central Intercambiadora de Servicios Móviles (MSC, “Mobile Service Switching Center”),
el corazón del sistema GSM.

14
 TRX VLR HLR

SIM Otros
BTS MSC MSC’s

MS BSC
BTS EIR SMSC SIM
PSTN/
ISDN
Estación
Móvil
(Terminal)
Estación Base Subsistema de
Conmutación y red

! " # # $ %! "
& & % & %
'( ' ) ( ( % '
& & % & % $
*+ * + # # + %, +%

( ( %
% ( %
& ( & % ) #( ( %
& %
-+ - + # # + %, %-
. # .# % .# % #
/ / % ) %") %$ ' %# /0 %
& ( ) & # ( ( % & 1 (

Figura 2.1. Arquitectura de la red GSM

El MSC, como ya fue referido, es el centro de la red, a través del cual se realiza la conexión
entre una llamada realizada desde un teléfono celular hacía las otras redes fijas como las
Redes Telefónicas Analógicas Pública (PSTN, “Public Switched Telephone Network”), las
redes Digitales de Servicios Integrados (ISDN, “Integrated Services Digital Network”) o las
redes móviles. El nodo en el que se encuentra, posee además una serie de equipos
destinados a controlar varias funciones, como el cobro del servicio, la seguridad y el envío
de mensajes SMS.

El Registro de Localización de Llamada (HLR, “Home Location Register”) contiene toda la

información administrativa sobre el cliente del servicio y la localización actual de la
terminal. Es a través del HLR que la red verifica si un teléfono celular que se intenta ligar

15
posee un contrato de servicio válido. Si la respuesta es afirmativa el MSC envía un mensaje
de vuelta a la terminal informándole que está autorizado a utilizar la red. El nombre de la
operadora aparece entonces en pantalla, informando que puede efectuar y recibir llamadas.
Cuando el MSC recibe una llamada destinada a un móvil, él va al HLR para verificar la
localización. Paralelamente, la terminal de vez en cuando envía un mensaje para la red,
para informarla del sitio donde se encuentra (este proceso es denominado poleo).

El Registro de Localización del Visitante (VLR, “Visitor Location Register”) es utilizado

para controlar el tipo de conexiones que una terminal puede hacer. Por ejemplo, si un
usuario posee restricciones en las llamadas internacionales, el VLR impide que estas sean
hechas, bloqueándolas y enviando un mensaje de vuelta al teléfono celular informando al
usuario.

El Registro de Identificación del Equipo (EIR, “Equipment Identity Register”) y la Central

de Autenticación (AC, “Authentication Center”) son utilizados para garantizar la seguridad
del sistema. El EIR posee una lista de IMEI de terminales que han sido declaradas como
robadas o que no son compatibles con la red GSM. Si el teléfono celular está en esa lista
negra, el EIR no permite que se conecte a la red. Dentro del AC hay una copia del código
de seguridad del SIM. Cuando ocurre la autorización, el AC genera un número aleatorio
que es enviado al teléfono celular. Los dos aparatos, de seguida, utilizan ese número, junto
al código del SIM y un algoritmo de encriptación denominado A3, para crear otro número
que es enviado de nuevo para el AC. Si el número enviado por la terminal es igual al
calculado por el AC, el usuario es autorizado a usar la red.

La central de mensajes cortos SMSC (Short Message System Center) es responsable de

generar los mensajes cortos de texto. Otros equipos utilizados en redes GSM pueden
adjuntar el recaudo de llamadas, la conexión a Internet, la caja de mensajes de voz, etc.

La explicación sobre las bases de datos definidas por GSM así como también la estructura
del canal de Radio, la arquitectura del protocolo se da en el apéndice 1.

Características de GSM

El sistema GSM posee una serie de funcionalidades, que pueden ser implementadas por los
operadores en sus redes. Entre estas características se incluyen:

-La posibilidad de usar la terminal y la tarjeta SIM en redes GSM de otros países
(roaming).
-El servicio de mensajes cortos (SMS) a través del que pueden ser enviadas y recibidos
mensajes con hasta 126 caracteres.
-El reenvío de llamadas a otro número.
-La transmisión y recepción de datos y fax con velocidades de hasta 9.6 Kbps.
-La difusión celular – mensajes con hasta 93 caracteres que pueden ser enviados a todos los
teléfonos celulares en un área geográfica. Los mensajes son recibidos cuando la terminal no
está siendo utilizada y pueden ser recibidos cada dos minutos.

16
-CLIP (Calling Line Identification Presentation) – permite ver en pantalla el número que
nos está llamando. Por oposición, el CLIR (Calling Line Identification Restriction) impide
que el número llamante sea visto por alguien (anónimo) gracias al CLIP.
-La posibilidad de visualización de crédito / costos.
-La notificación de llamadas en espera, cuando estamos hablando por teléfono.
-La posibilidad de colocar una llamada en espera, mientras se contesta otra.
-Las llamadas son encriptadas, lo que impide que sean escuchadas por otros.
-La posibilidad de impedir la recepción / transmisión de ciertas llamadas.
-Las llamadas de emergencia
-La posibilidad de varios usuarios hablar entre sí al mismo tiempo – servicio de conferencia
[8].

17
Capitulo 3

Servicios de Mensajes Cortos (SMS)

El papel de las compañías operadoras de telefonía celular ha sido muy importante en esta
expansión de las comunicaciones, y han tratado y tratan de amortizar sus inversiones
mediante la oferta de diferentes servicios que inciten al usuario a hacer uso de estas
comunicaciones.

3.1.- Estructura de SMS

Uno de los servicios ofertados por estas operadoras en los teléfonos celulares de tecnología
GSM es el envío y recepción de mensajes cortos, los conocidos SMS.

En el estándar GSM hay especificados dos tipos diferentes de SMS:

• SMS “Point to Point” (SMS/PP).

• SMS “Cell Broadcast” (SMS/CB).

El primer tipo permite enviar un mensaje de texto de un teléfono GSM a otro, mientras
SMS/CB permite enviar uno o más mensajes contemporáneamente (broadcast) a todos los
teléfonos que estén dentro de una determinada zona de cobertura de una o más emisores de
señal de radio. El CB puede contener un máximo de 93 caracteres, pero es posible enlazar
hasta 15 mensajes para formar un macro-mensaje. A cada mensaje CB se le asigna una
categoría que permite clasificar el tipo de información que contiene y el idioma empleado,
de modo tal que permita a los teléfonos celulares visualizar selectivamente o de descartar
los mensajes CB.

El SMS se denomina protocolo sin conexión, de hecho, cuando se transmite no se produce

ninguna conexión entre el terminal que envía y el que recibe, como sucede, por ejemplo, en
el caso de las llamadas de voz, datos o fax.

El envío de un SMS/PP desde un teléfono GSM a otro tiene que ser considerado como la
concatenación de dos operaciones diferentes: la transmisión del mensaje desde el teléfono
celular a una entidad especial de la red, llamada SMSC (Short Message Service Center), y
luego desde el SMSC hasta el teléfono celular receptor. La primera operación se denomina
SMS-MO (SMS Mobile Originated), mientras que la segunda se conoce como SMS-MT
(SMS Mobile terminated):

• SMS-MT permite recibir al usuario mensajes de texto con hasta 160 caracteres en
la pantalla del propio teléfono celular GSM
• SMS-MO permite al abonado enviar mensajes de texto con hasta 160 caracteres a
otra terminal GSM, a un fax o a una dirección de correo electrónico en Internet
[9].

18
Los mensajes SMS son herederos directos de los mensajes de los equipos localizadores de
personas, los llamados “buscas”, pero extendiendo su funcionalidad para permitir que desde
cualquier dispositivo GSM se pueda realizar un envío a otro equipo sin mediar
comunicación vocal con un teleoperador.

El éxito de este servicio, el SMS, parece provenir de la sencillez y facilidad de manejo, por
un lado, y de que “hay alguien al otro lado” con quien realizar el acto de la comunicación.
Estos dos factores han provocado dicho éxito, aún teniendo en contra el precio del servicio
en algunos casos y las limitadas características de esta comunicación.

3.2.- Funcionamiento de SMS

Las posibilidades de comunicación mediante “mensajes cortos GSM” (SMS) son muchas y
muy variadas, pero siempre limitadas por las características de estos mensajes, 160
caracteres, muy baja velocidad (en comparación con las líneas telefónicas convencionales),
duración limitada (24 ó 48 horas normalmente, sino se entregan antes son cancelados), no
es un servicio garantizado (el mensaje suele llegar pero no hay garantía de ello, ni que
lleguen en el orden en que se han enviado) y posibilidad de comunicación sólo entre
teléfonos celulares GSM entre los que haya “visibilidad” (que los operadores de los dos
teléfonos, emisor y receptor, tengan convenio de intercambio de mensajes).

Existen muchas especificaciones de formato de mensaje para los servicios prestados a

través de SMS que les dotan de gran potencia y complejidad. Pero es en el uso básico con
un sistema de enlace sencillo donde se están obteniendo los mejores resultados, tanto de
cantidad de mensajes enviados como de servicios que se están utilizando.

En todo caso, estas posibilidades resultan suficientes aprovechadas de forma adecuada, y

una de esas formas es tener uno de los lados de la comunicación gobernado por un servicio
automático que se encargue de responder a las peticiones recibidas desde múltiples
teléfonos celulares. La automatización de la recepción de los mensajes SMS, su procesado
y posterior respuesta es lo que conforma la funcionalidad de una pasarela SMS, ver Fig.
3.1.

19
 Figura 3.1: Esquema general de una pasarela SMS

El acceso a la red GSM se puede obtener de diferentes formas. El método más sencillo es
utilizando directamente una terminal GSM conectada a la computadora que actúa de
pasarela. En realidad este terminal puede ser un teléfono GSM normal con su kit de
conexión a PC (cable y software) o un MODEM GSM (igual que los módems
convencionales de red telefónica básica –RTB- pero su medio de transmisión es la red
GSM, no el par de hilos telefónicos).

La comunicación entre el ordenador y la terminal se suele realizar por un puerto de

comunicaciones serie. Casi todos los teléfonos celulares actuales incluyen un MODEM
GSM en su interior, de manera que la forma de comunicar ordenador y teléfono/MODEM
GSM es la misma que con un MODEM de RTB convencional, es decir, comandos AT. Si
el teléfono celular no incluye un MODEM GSM en su interior, es necesario comunicar con
el teléfono celular utilizando las especificaciones del protocolo que el fabricante haya
utilizado (normalmente se trata de protocolos propietarios, aunque cada vez menos). En
GNU/Linux podemos utilizar el proyecto que trata de implementar el paquete de software
Nokia Data Suite para la comunicación con estos teléfonos que implementan un protocolo
propietario de Nokia.

El otro método más habitual para acceder a la red GSM es contactar directamente con un
centro servidor de mensajes (SMSC) del operador de telefonía. Los SMSC de cada
fabricante incorporan también protocolos propietarios, por lo que es necesario realizar en
cada caso un dialogo diferente con cada tipo de SMSC, además de que el medio de
conexión también puede variar de unos a otros (IP, Frame Relay, X.25, RDSI, etc.).

Una vez comprendido el funcionamiento básico de una pasarela de mensajería SMS, nos
centraremos en la unión de las redes GSM, en un lado de la pasarela, e IP, en el otro, dada
su gran extensión y su uso común en todos los tipos de sistemas informáticos [10].

20
Aplicaciones de una pasarela de mensajería SMS

Los posibles usos que se pueden dar a una pasarela SMS entre las redes GSM e IP son
extensas.

Tenemos la siguiente lista como ejemplo de actividades que se realizan en la actualidad con
este tipo de pasarelas de mensajería:

• Correo electrónico. La pasarela convierte un mensaje de correo en SMS y un

mensaje SMS en mensaje de correo, con las consiguientes
generaciones/eliminaciones de cabeceras de mensaje.
• Distribución de mensajes SMS. Al igual que funcionan las listas de correo
electrónico, en las que un mensaje es reenviado a lo suscriptores de la lista, en la
lista de distribución de mensajes SMS la pasarela permite el mantenimiento
(alta/baja/consulta) de suscriptores y envía al resto de suscriptores de la lista los
mensajes que no son comandos de actuación sobre la propia pasarela.
• Recepción de alarmas de los sistemas de monitorización de servicios. Aplicaciones
como “mon”, “heartbeat”, agentes “snmp”, etc. Generan avisos cuando se alcanzan
ciertos eventos. Estos avisos pueden ser encaminados mediante mensaje SMS
dependiendo de su importancia, para que ciertas personas sean avisadas
inmediatamente.
• Transporte de contenidos Web. El SMS es utilizado como paquete de transporte
para hacer llegar desde el teléfono celular al servidor la petición de una página Web
y desde el servidor al teléfono Celular el contenido de dicha página una vez
“filtrada” para eliminar imágenes, tags html, cabeceras de página, etc.
• Concursos de preguntas y respuestas. Ante una solicitud desde el teléfono celular
para comenzar el concurso, la pasarela envía mensajes con preguntas, recibe
respuestas y mantiene un contador de resultados para cada participante, de manera
que se pueden generar clasificaciones.
• Sistemas de seguimiento de flotas de vehículos. Un teléfono celular unido a un
módulo GPS permite enviar información acerca de la posición exacta del portador
del teléfono, de manera que para flotas de vehículos se reciben sus notificaciones de
posición en la pasarela y ésta actualiza una base de datos consultable por otras
aplicaciones que pueden mostrar la situación de cada elemento de la flota.
• Notificación de estado de dispositivos aislados. Dispositivos de control de
temperatura y presencia, etc. Que se encuentren aislados y sin comunicación con
una red mediante enlace físico pueden hacer uso de los mensajes SMS para recibir
ordenes y para notificar de su estado (queda poca bebida, la temperatura ha
superado los 45 grados, etc.). Normalmente esta comunicación se realiza sin
intervención manual, por lo que realmente se conectan equipos automáticos en
ambos lados. Además, de inmediato, a cada persona le surgen nuevas aplicaciones,
orientadas a su área de conocimiento:
• Consulta de bases de datos.
• Mantenimiento de sistemas. Consultas de estado de servicios, reinicio de los
mismos, reinicio de equipos.
• Notificación de informaciones académicas. Notas, convocatorias de examen, etc.

21
 • Banca GSM. Servicios financieros y alarmas para el seguimiento de operaciones de
valores.
• Cualquier otro tipo de alarmas debido a caídas de tensión, detección de intrusos en
“firewalls”, etc.
• Domótica. Control y consulta de dispositivos a distancia.
• Avisos de intervención para equipos médicos, mantenimiento, rescate, etc.

Dadas las características de la red GSM que permiten la movilidad a los terminales
(teléfonos) en su zona de cobertura, su pueden imaginar aplicaciones que aprovechen la
posibilidad de localización de un teléfono, en base a la estación base de la red que en ese
momento tiene conexión con él. Sin embargo, esta información no es directamente
accesible desde el exterior de la red del operador de telefonía, por lo que, salvo aplicaciones
fuertemente integradas con la red del operador, no es posible su utilización.

Podríamos imaginar una aplicación que permitiera emitir mensajes SMS a teléfonos
celulares entre las dos y las tres de la tarde en la zona de cobertura de una estación base
situada junto a un restaurante que contratara los servicios de publicidad que un operador
pudiera ofrecer, para que todos los que por allí cerca pasaran supieran donde está dicho
restaurante. Al margen de la aplicación, podrían surgir problemas con la utilización de la
posición de las terminales para operaciones no solicitadas por el propietario de la terminal,
ya que al fin y al cabo, la situación de cada terminal es información privada del propietario.

De cualquier manera, la pasarela de mensajería sólo trata de servir de intermediario y

facilitar la labor de desarrollo de las extensiones móviles para una aplicación dada.

La pasarela de mensajería SMS/IP trata de ser como un servidor Web, realiza sus tareas de
cambio de formato y ajuste del mensaje, pero precisa de contenidos que realmente le den
una utilidad, aunque en este caso los contenidos son pequeñas o grandes aplicaciones que
permiten interactuar al usuario móvil con otro programa.

También tiene un comportamiento similar al de un Agente de Transferencia de Mensajes de

correo (MTA) ya que, de alguna forma, ésa también es su tarea: el encolado, conmutado y
entrega de mensajes.

Para finalizar con las utilidades de las pasarelas de mensajería SMS/IP, podemos añadir que
no hay un estándar para que las aplicaciones se comuniquen con las pasarelas, en general,
sino que cada una define su propia interfaz, que es diferente en todos los casos. En este
aspecto queda mucho camino por recorrer para, quizás, definir un “wrapper”, una interfaz
intermedia, normalizada, que permita la utilización de diferentes pasarelas SMS sin
necesidad de realizar cambios en la aplicación2

22
3.3.- Servicio de Mensajes Multimedia (MMS)

La Mensajería Multimedia (MMS) es un servicio de mensajes para el entorno móvil

normalizado por el foro WAP2 “Wireless Application Protocol” y por el Proyecto de
colaboración en Tercera Generación (3GPP). Al igual que el tradicional servicio de
mensajes cortos (SMS), la mensajería multimedia permite el envío automático e inmediato
de mensajes personales. No obstante, a diferencia del SMS, MMS permite a los usuarios de
teléfonos celulares mejorar sus mensajes incorporando sonido, imágenes y otros
contenidos, transformando su mensaje en un mensaje visual y de audio personalizado.

MMS resulta muy similar al servicio de mensajes cortos (SMS) y, al igual que éste,
requiere su propia interfaz. Técnicamente no utiliza WAP, ya que se trata de una aplicación
de mensajería y no de navegación.

Pero la tecnología MMS ofrece algo más que la simple ampliación del contenido de los
mensajes. Con MMS, no sólo es posible enviar mensajes multimedia de un teléfono a otro,
sino también de un teléfono a correo electrónico y viceversa. Esta función aumenta de
forma espectacular las posibilidades de la comunicación móvil, tanto para uso privado
como profesional [11].

Los principales fabricantes apuestan a que MMS evolucionará rápidamente para convertirse
en un auténtico servicio de alto consumo, tanto para el uso personal como profesional.

Es previsible que los usuarios se adapten fácilmente a MMS, ya que este sistema se puede
reconocer como una forma avanzada de SMS. De este modo, MMS se convierte en un
sólido eslabón para el paso de comunicaciones de 2G a 3G

Compatibilidad

La norma MMS incluye JPEG, GIF, texto, voz AMR y otros formatos como tipos de
soportes admitidos, mientras que los formatos no admitidos se administran de forma
controlada. Al igual que SMS, MMS constituye una norma industrial abierta y los mensajes
MMS se pueden enviar utilizando las redes y protocolos existentes. MMS también es
independiente del portador, lo que significa que no se limita exclusivamente a redes GSM o
WCDMA3.

2
Una especificación segura que permite a los usuarios accesar información de manera instantánea a través
de dispositivos portátiles sin cable como teléfonos celulares o radios de dos vías
3
WCDMA. Wide Band Code Division Multiple Acces, Acceso múltiple por división de código del ancho de
banda

23
Capitulo 4

Control del Robot

4.1.- Antecedentes del Robot

La palabra robot se empleó por primera vez en 1920 en una obra de teatro llamada
“R.U.R.” o “Los Robots Universales de Rossum” escrita por el dramaturgo checo aren
Capek. La trama era sencilla: el hombre fabrica un robot, luego el robot mata al hombre.
Muchas películas han seguido mostrando a los robots como máquinas dañinas y
amenazadoras [12].

Ahora veamos lo que es un robot. Los expertos en Robótica afirmarían que es complicado
dar una definición. Por lo cual existen varias definiciones de las cuales se presentan
algunas:
1. Ingenio mecánico controlado electrónicamente, capaz de moverse y ejecutar
de forma automática acciones diversas, siguiendo un programa establecido.
2. Máquina que en apariencia o comportamiento imita a las personas o a sus
acciones como, por ejemplo, en el movimiento de sus extremidades.
3. Un robot es una máquina que hace algo automáticamente en respuesta a su
entorno.
4. Un robot es un puñado de motores controlados por un programa de
computadora.
5. Un robot es una computadora con músculos.

La introducción de los microprocesadores desde los años 70 ha hecho posible que la

tecnología de los robots haya sufrido grandes avances, las modernas computadoras han
ofrecido un “cerebro” a los músculos de los robots mecánicos. Ha sido esta fusión de
electrónica y mecánica la que ha hecho posible al robot moderno. El término mecatrónica
se usa para describir la fusión de la electrónica y la mecánica.

El año 1980 fue llamado “primer año de la era robótica” porque la producción de robots
industriales aumentó ese año un 80 % respecto del año anterior.

Con respecto a la historia de cómo surgen los robots tenemos las siguientes generaciones:

Primera y Segunda Generación

En estas generaciones los cambios en robótica suceden tan rápido que ya se ha pasado de
unos robots relativamente primitivos a principios de los años 70, a una segunda generación.
La primera generación de robots era reprogramable, de tipo brazo, dispositivos
manipuladores que sólo podían memorizar movimientos repetitivos, asistidos por sensores
internos que les ayudan a realizar sus movimientos con precisión. La segunda generación
de robots entra en escena a finales de los años 70, tienen sensores externos (tacto y visión
por lo general) que dan al robot información (realimentación) del mundo exterior. Estos

24
robots pueden hacer elecciones limitadas o tomar decisiones y reaccionar ante el entorno de
trabajo, se les conoce como robots adaptativos.

Tercera Generación

La tercera generación acaba de surgir, está surgiendo en estos años, emplean la inteligencia
artificial (IA) y hacen uso de las computadoras más avanzadas de las que se puede disponer
en la actualidad. Estás computadoras no sólo trabajan con números, sino que también
trabajan con los propios programas, hacen razonamientos lógicos y aprenden. La IA
permite a las computadoras resolver problemas inteligentemente e interpretar información
compleja procedente de sensores avanzados.

Tendencias futuras

Durante años los robots han sido considerados útiles sólo si se empleaban como
manipuladores industriales. Recientemente han irrumpido varios roles nuevos para los
robots. A diferencia de los tradicionales robots fijos de manipulación y fabricación, estos
nuevos robots móviles pueden realizar tareas en un gran número de entornos distintos. A
estos robots no industriales se les conoce como robots de servicios.

Los robots de servicios proporcionan muchas funciones de utilidad, se emplean para el

ocio, la educación, fines de bienestar personal y social. Por ejemplo, hay prototipos que
recorren los pasillos de los hospitales y cárceles para servir alimentos, otros navegan en
oficinas para repartir el correo a los empleados. Los robots de servicios son idealmente
adecuados al trabajo en áreas demasiado peligrosas para la vida humana y a explorar
lugares anteriormente prohibidos a los seres humanos. Han probado ser valiosos en
situaciones de alto riesgo como en la desactivación de bombas y en entornos contaminados
radioactiva y químicamente.

Este crecimiento revolucionario en el empleo de robots como dispositivos prácticos es un

indicador de que los robots desempeñarán un importante papel en el futuro. Los robots del
futuro podrán relevar al hombre en múltiples tipos de trabajo físico. Joseph Engelberg,
padre de la robótica industrial, está investigando en una especie de robot mayordomo o
sirviente doméstico. Se piensa que los robots están en ese momento crítico antes de la
explosión del mercado, como lo estuvieron las PC’s en 1975. El campo de la robótica se
desbordará cuando los robots sean de dominio público, esta revolución exigirá que la gente
de la era de la información no sea “analfabeta robótica”.

Existen diferentes tipos de robots entre los cuales tenemos los siguientes:

Androides

Una visión ampliamente compartida es que todos los robots son “androides”. Los
androides son artilugios que se parecen y actúan como seres humanos. Los robots de hoy en
día vienen en todas las formas y tamaños, pero a excepción de los robots que aparecen en
las ferias y espectáculos, no se parecen a las personas y por tanto no son androides.

25
Actualmente, los androides reales sólo existen en la imaginación y en las películas de
ficción.

Móviles

Los robots móviles están provistos de patas, ruedas u orugas que los capacitan para
desplazarse de acuerdo su programación. Elaboran la información que reciben a través de
sus propios sistemas de sensores y se emplean en determinado tipo de instalaciones
industriales, sobre todo para el transporte de mercancías en cadenas de producción y
almacenes. También se utilizan robots de este tipo para la investigación en lugares de difícil
acceso o muy distantes, como es el caso de la exploración espacial y las investigaciones o
rescates submarinos.

Médicos

Los robots médicos son, fundamentalmente, prótesis para disminuidos físicos que se
adaptan al cuerpo y están dotados de potentes sistemas de mando. Con ellos se logra igualar
con precisión los movimientos y funciones de los órganos o extremidades que suplen.

Industriales

Los robots industriales son artilugios mecánicos y electrónicos destinados a realizar de

forma automática determinados procesos de fabricación o manipulación.
También reciben el nombre de robots algunos electrodomésticos capaces de realizar varias
operaciones distintas de forma simultánea o consecutiva, sin necesidad de intervención
humana, como los también llamados «procesadores», que trocean los alimentos y los
someten a las oportunas operaciones de cocción hasta elaborar un plato completo a partir de
la simple introducción de los productos básicos.
Los robots industriales, en la actualidad, son con mucho los más frecuentemente
encontrados. Japón y Estados Unidos lideran la fabricación y consumo de robots
industriales siendo Japón el número uno. Es curioso ver cómo estos dos países han definido
al robot industrial:

La Asociación Japonesa de Robótica Industrial (JIRA) dice: Los robots son “dispositivos
capaces de moverse de modo flexible análogo al que poseen los organismos vivos, con o
sin funciones intelectuales, permitiendo operaciones en respuesta a las órdenes humanas”.
El Instituto de Robótica de América (RIA) define: Un robot industrial es “un manipulador
multifuncional y reprogramable diseñado para desplazar materiales, componentes,
herramientas o dispositivos especializados por medio de movimientos programados
variables con el fin de realizar tareas diversas”.

Teleoperadores

Hay muchos “parientes de los robots” que no encajan exactamente en la definición precisa.
Un ejemplo son los teleoperadores. Dependiendo de cómo se defina un robot, los
teleoperadores pueden o no clasificarse como robots. Los teleoperadores se controlan
remotamente por un operador humano. Cuando pueden ser considerados robots se les llama

26
“telerobots”. Cualquiera que sea su clase, los teleoperadores son generalmente muy
sofisticados y extremadamente útiles en entornos peligrosos tales como residuos químicos y
desactivación de bombas [13].

4.2 Características del Robot

El simulador del robot utilizado en este proyecto cuenta con las siguientes características:
• 16 sensores
• Cámara
• Entrada serial
El robot simulado es el Pioneer 2D [14].

4.3.-Simuladores del robot

Como el sistema de simulación de GSM va interactuar con el simulador del robot, en este
capítulo se da una breve explicación de las principales características de algunos de los
simuladores disponibles y que se analizaron para poder seleccionar el simulador de robot a
utilizar, entre ellos tenemos algunos que a continuación mencionamos.

4.3.1.- Simulador SAPHIRA

Saphira [36] es una arquitectura para control de robots móviles. Originalmente ésta fue
desarrollada para la investigación del robot Flakey en SRI internacional y después estuvo
en uso por diez años. Fue desarrollada dentro de una arquitectura que soportaba una gran
variedad de investigación y programación de aplicaciones para robots móviles. Saphira y
Flakey aparecieron en 1994.

El sistema Saphira está dividido en dos partes. Las rutinas de bajo nivel han sido
reorganizadas y reimplementadas como un sistema de software separado, Aria. Es
diseñado y mantenido por Activmedia Robotics. Este es un sistema de nivel de producción
para el control del robot, basado sobre un extenso conjunto de clases de C ++. La estructura
de clases Aria hace fácil expandir y desarrollar nuevos programas: añadir nuevos sensores
al sistema.

El sistema Saphira/Aria puede ser pensado como dos arquitecturas, una construida sobre la
otra. La arquitectura del sistema implementada enteramente en Aria es un conjunto
integrado de rutinas para comunicación y control con el robot desde el servidor en una
computadora. La arquitectura del sistema es diseñada para ser fácil la definición de
aplicaciones del robot para la conexión con programas de tipo cliente. Debido a esto, la
arquitectura del sistema es una arquitectura abierta a los usuarios que desean escribir su
propio sistema de control del robot pero no quieren preocuparse acerca de las
complejidades del control de hardware y la comunicación puede ser una ventaja de las
propiedades micro-tarea y reflexión de estado de la arquitectura del sistema.

27
Las rutinas del sistema de arriba es una arquitectura del control de robot, que es un diseño
para controlar robots móviles que solventan algunos de los problemas envueltos en la
navegación.

4.3.2 Simulador Stage Player

Player [37] fue originalmente desarrollado por Brian Gerkey y Kasper Stoy, la interfaz del
simulador Stage fue originalmente escrita por Richard T. Vaughan y Andrew Howard, el
desarrollo de Player es administrado por Brian Gerkey, Andrew Howard, y Richard
T.Vaughan.
Player es primeramente desarrollado en los laboratorios “Research Robotics” de la
universidad de “Southem in California”.
Player es software libre, es un servidor multi-hilo de dispositivos del robot, éste da un
simple y completo control sobre los sensores físicos y acciones sobre el robot móvil.
Cuando Player está ejecutándose sobre el robot, el programa de control cliente se conecta a
Player por medio de un socket de TCP, la comunicación se realizará enviando y recibiendo
algunos de los comandos de un pequeño conjunto de mensajes simples.
Player está diseñado para ser un lenguaje y una plataforma independiente. El programa
cliente puede ejecutarse sobre cualquier máquina que tenga conectividad de red para el
robot, y el programa cliente puede ser escrito en cualquier lenguaje que pueda abrir y
controlar un socket TCP. Las características del cliente están actualmente disponibles en C,
C++, TCL, LISP, Java, y Pitón.

Player está también diseñado para soportar virtualmente cualquier número de clientes

4.3.3 Simulador Java Mobile Robots (JMR)

Con respecto al simulador JMR [38] es de una arquitectura tipo cliente servidor la cual
puede soportar varios robots, esto quiere decir que puede simular que está controlando
varios robots, estos robots los identifica con un nombre, también puede cargar procesos
sobre algún robot que se elija, puede conectarse con el simulador Saphira para poder tener
comunicación con un robot real.

En el cliente se manejan los dispositivos tales como sonares, cámaras de los robots que se
tengan añadidos, así como también puede regular la velocidad y ver la distancia del robot
con respecto a los obstáculos, otro aspecto más es que podemos ver el estado del robot ya
sea que esté parado, avanzando, que haya chocado con algún obstáculo, etc.

También le podemos enviar la distancia que queremos que avance, al igual que los grados
que queremos que gire.

En el servidor se reciben los comandos que le envía el cliente y los simula, en éste también
se pueden cargar mundos que es por donde va a ir navegando el robot, así como también las
imágenes que capta la cámara del robot, las cuales son enviadas al cliente y mostradas.

En el servidor también se puede seleccionar que robot queremos ver.

28
Esta es una breve explicación del funcionamiento del simulador JMR, un análisis más a
fondo se hace en el capítulo 5.

29
Capitulo 5

Simulador Java Mobile Robots (JMR)

JMR (Java Mobile Robots) [38] es un entorno Java para simulación de robots, que permite
estudiar el comportamiento de uno o varios robots sobre un mundo o entorno definido.

5.1.- Características del simulador JMR

El sistema dispone de una aplicación cliente, sobre la que se cargan los robots que se
desean probar, y de una aplicación servidor que se encarga de llevar un control de los
robots conectados, actualizar su situación en el mundo que se haya especificado, y
proporcionar al cliente los datos que se soliciten.
Se persigue con este entorno dos objetivos fundamentales: Uno es definir una interfaz de
comunicación de Java con la librería Saphira de control de robots. De este modo, se podrá
conectar el sistema al simulador de robots de Saphira (Pioneer), y también a los robots
reales que se gestionen con dicha librería. Conviene resaltar aquí la modificabilidad y
modularidad que permite Java, y que haría posible la adaptación del programa a otras
librerías de control de robots.
El otro objetivo que se persigue es proporcionar un sistema propio de simulación,
fácilmente portable, que permita sencillas modificaciones o actualizaciones del mismo. La
estructura de Java permite definir un esqueleto básico sobre el que ir modificando o
ampliando características de forma sencilla, añadiendo nuevas clases que extiendan o
sobrescriban a las anteriores. De esta forma, además de la comunicación con Saphira, se
dispone de un sistema auto-integrado, que permite la prueba de robots y procesos sobre el
mismo sin necesidad de ningún programa adicional, mediante un simulador 3D propio.
Por todo lo anterior, se ha desarrollado un programa cliente-servidor que permite la gestión
de robots, así como algunas librerías auxiliares, algunas de las cuales son utilizadas por
dichos programas, y otras facilitan la elaboración de procesos en los robots por parte del
usuario.
La arquitectura de este simulador es de cliente-servidor la cual se explica enseguida.

5.2.- Funcionamiento del simulador JMR

Debido a la arquitectura de este simulador, como se ha mencionado, cuenta con un cliente y

un servidor, su funcionamiento a grandes rasgos se explica a continuación.

Aplicación cliente

El paquete jmr.client contiene la aplicación cliente del sistema. En la parte cliente se tiene
un programa para gestionar los distintos robots que queremos conectar. El programa está
preparado para soportar varios robots simultáneamente (aunque si se está comunicando con
Saphira, sólo se permitirá uno, por las limitaciones de Saphira), y se conseguiría con ello el
mismo efecto que lanzando varias aplicaciones cliente, una por cada robot.
El cliente dispone de controles para elegir a qué servidor conectarse (actualmente, al
simulador Java, al simulador Saphira, o a un robot real a través de Saphira por un puerto

30
serie dado), indicando la dirección donde se encuentra el servidor. Esto permite comunicar
mediante RMI (Remote Method Invocation, Invocación de Método Remoto) con un
servidor situado en una máquina remota, conociendo su dirección IP y el puerto por el que
comunicarse, y también comunicar, si se permite, con un servidor en la máquina local, sin
necesidad de indicar dirección IP ni puerto.
Además, se permite añadir y quitar robots del cliente, y llevar un control de los datos de
cada robot (lecturas de sónares, estado actual, dispositivos, etc.).

El servidor.
En la parte del servidor, se distingue entre los servidores que se tienen:

El simulador 3D JAVA

El simulador 3D Java está contenido en el paquete jmr.simulator, y cuenta con un programa

que permite monitorizar la situación del mundo que se haya elegido, mediante distintas
cámaras que permiten tener una visión global del mundo o particular de cada uno de los
robots que haya en él en cada momento.
Además, cuenta con métodos para obtener los datos de cada robot en cada instante:
detección de colisiones con obstáculos mediante cálculo de intersecciones, toma de lecturas
de los sónares, captura de imágenes mediante un dispositivo de tipo cámara, y toma de
otros datos de interés, como pueden ser estimaciones de posición mediante otro tipo de
dispositivos, filtrado o procesado de imágenes, etc.

El servidor SAPHIRA

Dentro del servidor Saphira, contenido en el paquete jmr.saphira, se engloban tanto la

conexión con el simulador Pioneer como la conexión con un robot real a través de un
puerto serie utilizando Saphira. Este tipo de servidor no dispone de ninguna aplicación
visual de monitorización, sino simplemente de un programa que se deja ejecutando y
permite la comunicación con Saphira.

Para la comunicación con Saphira, se emplea JNI (Java Native Interface), una utilidad de
Java que permite incorporar al código Java fragmentos de código escritos en otros
lenguajes de programación, como C. Así, se definen en una librería un conjunto de
funciones escritas en C que interactuarán con Saphira, y desde Java se define el puente para
poder llamar a las funciones de dicha librería.

Se ha minimizado en la medida de lo posible la parte de tratamiento del robot que hace

Saphira, dejando únicamente el reflector de estado, del que tomar los datos del robot, y
utilizando algunas funciones para tomar datos y establecer velocidades. Lo que se pretende
es dejar que se gestionen todas las estructuras desde Java, y utilizar la API de Saphira para
obtener los datos y enviar los comandos básicos de movimiento (velocidad lineal y
rotacional) al robot.
Las nuevas versiones de Saphira son versiones de pago, aunque se ha desarrollado una
librería, llamada ARIA, que es de libre distribución, y permite comunicar con los robots.

31
El programa de configuración.

El paquete jmr.conf contiene una pequeña aplicación que permite definir opciones de
configuración de distintos módulos de JMR: parámetros de configuración del simulador
3D, del cliente, etc. Debemos ejecutar esta aplicación si queremos modificar estos
parámetros antes de ejecutar JMR.

Control del robot.

Para el control del robot, se tiene definido el paquete jmr.robots, con distintas clases que
permitirán almacenar datos y llevar un control del comportamiento (influencia de los
procesos en el estado final del robot, procesamiento de imágenes, gestión de dispositivos,
etc.) del robot.

El robot.

El objeto robot propiamente dicho viene dado por una interfaz que define una serie de
métodos que debe implementar todo robot, como son el envío de comandos de velocidad,
envío de otros comandos algo más complejos como avanzar una distancia o girar un
determinado ángulo, toma de datos como el estado, los parámetros, las lecturas de los
sonares, etc. También se tienen definidas rutinas estándar para establecer la conexión entre
cliente y servidor.
Partiendo de esta estructura básica, cada simulador (Java y Saphira) la adaptará a sus
propias necesidades, definiendo el código de cada uno de los métodos propuestos en la
estructura. Para el caso de Saphira, se definen unas llamadas en código nativo C para poder
interactuar con Saphira, y como se ha comentado anteriormente, JNI (Java Native Interface)
es la herramienta Java que se ha utilizado para comunicar el código Java con las llamadas a
las funciones C.

Datos del robot.

Se tienen los datos del robot repartidos en tres elementos: estado del robot, parámetros del
robot y sónares del robot, si bien estos dos últimos están muy relacionados.

Para gestionar el estado del robot se tiene definida una clase que almacena información
como la posición y orientación del robot, velocidad lineal y rotacional, estado de la batería,
y alguna otra información relevante. Esta información se caracteriza por variar con el
tiempo, y presumiblemente podrá ser distinta cada vez que se tomen datos del robot.
Por parámetros del robot entendemos datos estáticos que definen las dimensiones, datos
internos de trabajo, rangos, etc., del robot, es decir, sus características. Aquí encontramos
datos como los factores de conversión que emplea para las unidades de velocidad, lectura
de sonares, etc., el rango de velocidades (lineales y rotacionales) entre los que puede
moverse, el número de sonares, la disposición de los mismos, etc.

Finalmente, se define otra clase para guardar las lecturas de sonares que vaya tomando el
robot. Para cada lectura, se tomará información detallada sobre la distancia tomada,
coordenadas de la lectura, un contador que servirá para distinguir lecturas ya leídas de las

32
no leídas, etc. Este dato está muy relacionado con los parámetros del robot porque se
encuadra dentro de dicha estructura de datos: junto al número de sonares y la disposición de
los mismos, se almacenan las lecturas de cada uno (aunque sí sean datos dinámicos).

Control sobre los procesos en el robot.

Para poder gestionar la influencia de los procesos que se estén ejecutando en el robot, se
tiene definido un manejador que se encarga de agrupar los distintos procesos que hay en
ejecución sobre un robot, evaluar las prioridades y otros factores a considerar y generar una
respuesta que determinará el nuevo estado en que se encuentre el robot (en realidad,
determinará qué velocidad lineal y rotacional asignar al robot en función de los resultados
ponderados de los procesos).

En cuanto a los procesos, se distinguen dos tipos principales de procesos: actividades y

conductas. Las primeras fundamentalmente producen comandos directos sobre el robot (se
le envían comandos directos de movimiento), aunque también se pueden emplear para
combinar procesos, y otras tareas. Las conductas definen sobre unas variables locales qué
velocidades se quieren asignar al robot, y luego es el manejador quien se encarga de
ponderar los resultados de todas las conductas y producir una respuesta global y única. Se
podrán definir conductas y actividades de muy diversos tipos, empleando lógica difusa,
razonamiento probabilístico, etc.

Se permite que un proceso pueda llamar a otros procesos, y así poder definir procesos más
elaborados mediante módulos simples, como por ejemplo, dirigirse hacia un punto evitando
obstáculos, que podría estar compuesta por la conducta “dirigirse a un punto” y la conducta
“evitar obstáculos”.

También se deja la posibilidad de que el usuario implemente su propio manejador de robot,

que defina su propia política de control de procesos y de generación de comandos globales
para el robot en función de los mismos, sin más que extender de la clase manejador
genérica.

Visión

Se tiene un módulo dedicado a tratar el problema del procesado de imágenes en el robot. Se

definen en él estructuras de datos que permitan al servidor enviar al cliente información
sobre la imagen que está viendo en cada momento el robot, y se han definido las estructuras
de determinados métodos que se emplearán para procesar y obtener imágenes.

Además, se ha definido un puente que comunica las imágenes que puedan captarse y
procesarse con la herramienta JavaVis desarrollada en el Departamento de Ciencia de la
Computación e Inteligencia Artificial de la Universidad de Alicante, de modo que se
pueden emplear los diversos filtros y funciones que se han desarrollado para dicha librería,
y aplicarlos para procesar imágenes en el servidor y enviarlas al cliente.

33
Dispositivos.

Puede ser útil (e incluso necesario) tener la posibilidad de definir dispositivos sobre el
robot, elementos que actúen en el servidor, procesando determinados datos, y
proporcionando mecanismos para que el cliente pueda adquirir dichos datos procesados. Un
ejemplo puede ser la cámara que pueda tener el robot. Conviene disponer de un mecanismo
que permita definir la cámara, y poder visualizar así en el cliente las imágenes que capture
el robot.
Pero no sólo se trata de dispositivos físicos, como puedan ser una cámara, una pinza, o
cualquier otro elemento, sino también dispositivos lógicos, como fragmentos de código que
preprocesen información en el servidor para ponerla a disposición del cliente cuando lo
requiera. Por ejemplo, aplicar un algoritmo para determinar en qué posición puede estar el
robot, o un procesado de imágenes que también permita especular sobre dicha posición
mediante razonamiento probabilístico.

Librerías auxiliares.

Se han implementado una serie de librerías que, bien serán utilizadas por las aplicaciones
para algunas tareas auxiliares, bien permitirán al usuario definir procesos y programas Java
de forma sencilla. A continuación se comentan brevemente.

Librería para desarrollo de entornos gráficos: robotGUI

La librería jmr.robotGUI se ha desarrollado para facilitar la elaboración de aplicaciones

visuales como el propio cliente. Dispone de una serie de controles específicos que puedan
resultar interesantes para el control de robots (formados a base de controles Java Swing
agrupados), tales como paneles de imágenes, listas de parámetros, etc.
Se ha empleado esta misma librería para construir la propia aplicación cliente, de forma que
también puede servir de ejemplo de uso para construir otras aplicaciones similares.

Librería geométrica: javaGL

La librería jmr.javaGL contiene una serie de elementos geométricos que facilitan el

tratamiento de objetos del mundo en que se mueve el robot, así como del propio robot.
Dispone de objetos tales como líneas, segmentos, círculos, puntos, posiciones, que
permiten definir, entre otras cosas, los límites de los muros del mundo, las dimensiones del
robot, la posición del mismo, etc.
Se emplea sobre todo en la parte del simulador Java para obtener aproximaciones 2D del
mundo 3D que se tiene representado, mantener listas de segmentos para obtener
intersecciones (y ver con ellas si el robot ha colisionado, o determinar las lecturas de los
sonares, etc), definir posiciones, y otras funcionalidades.

Librería de lógica difusa: fuzzy

La librería jmr.fuzzy contiene un conjunto de clases que permiten emplear lógica difusa en
el comportamiento del robot, así como en otras tareas que se quieran realizar. Dispone de
elementos para poder definir variables difusas, conjuntos difusos, elaborar reglas difusas

34
que obtengan una serie de consecuentes a partir de unas entradas determinadas para sus
antecedentes, etc.
Internamente, se ha empleado la librería fuzzyJ del NRC (National Research Council of
Canada), que incorpora una serie de clases que contienen parte del código que se busca
tener. Se ha adaptado todo de forma que dispone de una librería propia, que se vale de
algunas funciones y clases de fuzzyJ para determinadas tareas, permitiendo así poder
prescindir de dicha librería en caso de considerarlo oportuno, y de ampliar los contenidos
de la misma con nuevas funcionalidades, sin la merma que supondría actuar sobre dicha
librería directamente.
Con esta librería se pueden definir conductas difusas, basadas en reglas de cuyo
cumplimiento dependerá el establecimiento de determinados parámetros como son, sobre
todo, la velocidad lineal y rotacional del robot.

Librería probabilística: prob

La librería jmr.prob se ha definido para mantener, además de una librería para control
mediante lógica difusa, una librería que permite el control mediante razonamiento
probabilístico. Además, proporciona ayuda a la hora de realizar determinadas tareas, como
generación de datos aleatorios siguiendo una determinada distribución de probabilidades,
etc.
Así, se han definido una serie de distribuciones de probabilidad conocidas y frecuentemente
empleadas, como son la distribución normal, la distribución de Poisson, y otras. También se
ha dado pie a que el usuario pueda definir sus propias distribuciones de probabilidad, tanto
discretas como continuas, dejando simplemente el esqueleto que debe cumplir toda
distribución.
Además, se tiene implementada una versión genérica del algoritmo CONDENSATION
(CONditional DENSity propagATION), un algoritmo que permite realizar estimaciones
sobre diversas características (posición del robot, reconocimiento de imágenes, etc),
mediante la disposición de un conjunto de muestras en el espacio objeto de estudio, y la
evaluación de la probabilidad de cada muestra. Con este algoritmo genérico, se podrán
especificar variantes concretas que actúen sobre un tema específico, como por ejemplo
localizar un robot en un pasillo, evaluar la posición del robot en función de la imagen que
capta, etc.

Librería de cargadores de ficheros: loaders

La librería jmr.loaders es una librería auxiliar empleada para procesar los distintos tipos de
ficheros externos que se utilizan: ficheros de parámetros de robots, de descripciones de
mundos, de configuración, etc, y almacenar la información de los mismos en las estructuras
de datos pertinentes.
Los ficheros de parámetros son los mismos que los que emplea Saphira, añadiendo algunas
palabras clave más como comentarios de Saphira, de modo que en el simulador incorporan
más datos sobre los parámetros, y en Saphira son ignoradas, pero el fichero puede leerse.
Podremos así, por ejemplo, en los mundos del simulador 3D, añadir luces, texturas, etc.

35
Directorios del usuario.

Fuera del núcleo de JMR, se tienen otros directorios o paquetes para que el usuario añada
funcionalidades:
• El paquete “process”, para añadir procesos que queramos cargar en robots
• El paquete “devices”, para añadir dispositivos que queramos cargar en robots
• El paquete “vision”, para añadir procesadores de imágenes para las imágenes que
capturen las cámaras de los robots.

Estructura general de JMR.

El directorio principal de JMR tiene la siguiente estructura:

• Colgando directamente de dicho directorio se encuentran los ficheros de
configuración, DLLs y ficheros de copyright y README sobre la aplicación.
• Todo el código fuente del núcleo de JMR se encuentra en el directorio /src/, en la
carpeta del paquete principal /jmr/, a partir del cual se tienen los distintos
subpaquetes:
o Aplicación cliente: jmr.client
o Simulador 3D: jmr.simulator
o Servidor Saphira: jmr.saphira
o Aplicación de configuración: jmr.conf
o Librería de programación de robots: jmr.robots
o Librerías auxiliares: jmr.robotGUI, jmr.javaGL, jmr.fuzzy, jmr.prob,
jmr.loaders.

• Además, se tienen algunas clases externas y paquetes que puede modificar el

usuario, en los directorios:
o process: para definir procesos que queramos ejecutar sobre los robots
o devices: para definir dispositivos que queramos cargar sobre los robots
o vision: para definir clases que permitan manipular imágenes tomadas de las
cámaras de los robots.
• En el directorio /params/ van los ficheros de parámetros de robots que se quieran
utilizar.
• En el directorio /World/ van los distintos mundos que queramos cargar.
• El directorio /conf/ contiene algunos ficheros de texto con configuración sobre el
programa.
• El directorio /lib/ contiene los ficheros JAR que utiliza JMR como librerías externas
• El directorio /images/ contiene algunas imágenes empleadas por las aplicaciones.
• El directorio /apps/ es un directorio auxiliar para programas de prueba del usuario.
• El directorio /clases/ contiene los ficheros compilados de todos los archivos fuentes
de JMR (subdivididos en paquetes).

36
Funcionamiento general.

Para la comunicación de ambas aplicaciones (cliente y servidor), se ha empleado la

tecnología RMI (Remote Method Invocation), una tecnología Java que permite ejecutar
remotamente comandos de otra máquina, y permitir así la comunicación en sistemas
distribuidos.
Por una parte, se tiene al servidor que se ha elegido (Java o Saphira), ejecutándose en una
máquina. Dicho servidor está escuchando por un puerto determinado, a la espera de
solicitudes de conexión de distintos clientes.
Por otra parte, se tiene cada uno de los clientes que se quieren lanzar, que pueden estar en la
misma máquina que el servidor o en máquinas distintas. En el cliente, se indica la dirección
en la que se encuentra el servidor, y los robots que se generen se conectarán con dicha
dirección. Podríamos también tener distintos robots conectados a distintos servidores,
dentro de un mismo cliente.
Se establece así una conexión por cada robot que se añada en la aplicación cliente, que será
gestionada de forma independiente. Una vez establecida la conexión, el cliente podrá
solicitar datos del robot al servidor ejecutando comandos remotos en el mismo (toma de
lecturas de sónares, toma del estado actual, establecimiento de la velocidad del robot, etc).
Además, se permite la conexión con un servidor local, sin necesidad de utilizar una
dirección IP y puerto, en el caso de que ambos se ejecuten en la misma máquina y no
queramos emplear RMI.
Ahora veamos la interfaz del simulador JMR. Iniciaremos con la aplicación cliente, ver fig.
5.1

Zona de parámetros
de conexión

Zona de control de
lista de robots

Zona de datos
del robot

Zona de
elementos
añadidos al
robot

Figura 5.1: interfaz de la aplicación cliente

37
La interfaz de la aplicación cliente es la mostrada en la figura 5.1 la cual contiene lo
siguiente:

• Zona de parámetros de conexión

• Zona de control de la lista de robots
• Zona de datos del robot
• Zona de elementos añadidos al robot

La aplicación cliente interactúa con el simulador 3D de java el cual es el encargado de

simular el robot y el mundo por donde navega el robot. El cual es el mostrado en la figura
5.2.

Figura 5.2 Cámara de robot y de usuario

Para una descripción más a detalle de cada uno de los elementos que componen a cada zona
y sobre la cámara del robot puede consultar el apéndice 1 manual de usuario de JMR [38].

38
Capitulo 6

Sistema de Simulación del Control de un robot móvil a través de GSM

(SimGSM)
Una parte importante en el desarrollo de sistemas es llevar acabo una serie de pasos para
poder comprender lo que el usuario quiere que realice el sistema, así como también para
que el programador pueda diseñar e implementar el sistema y para que cualquier
programador pueda entender su organización.

Otro aspecto importante es que el sistema tenga una buena organización para poder evitar
errores que puedan conllevar al mal funcionamiento del sistema o a la insatisfacción del
usuario.

Para llevar acabo la realización de este sistema hicimos uso del lenguaje unificado de
modelado (UML) [15] el cual prescribe un conjunto de notaciones y diagramas para
modelar sistemas orientados a objetos y describe la semántica esencial de lo que estos
diagramas y símbolos significan. UML se puede usar para modelar distintos tipos de
sistemas de software, sistemas de hardware y organización del mundo real.

6.1.-Planteamiento del sistema SimGSM.

SimGSM consiste en simular un teléfono celular, una central telefónica y de servicio de

mensajes cortos, un MODEM GSM y la comunicación entre ellos, cabe mencionar que el
sistema simula sólo la comunicación en una célula, ésto implica que sólo hay una central de
servicio de mensajes cortos y que el MODEM GSM, y el celular (SimCelular) están dentro
de ésta.

El funcionamiento del SimGSM es como se muestra en la figura 6.1.

GSM
MODEM
Robot

Central de Servicio de
Mensajes Cortos y Central
Telefónica (SMSCYCT)
Figura 6.1: Esquema general del sistema SimGSM.

La comunicación es de dos maneras por tonos o por mensajes cortos (SMS). Con respecto a
la comunicación por tonos ésta se hace de la siguiente manera:

39
Desde el simulador del teléfono celular se marca un número telefónico el cual es enviado a
la central telefónica para que ésta establezca o rechace la comunicación con el MODEM
GSM. Establecida la comunicación con el MODEM GSM del robot, se empieza a
introducir el comando, el comando es enviado al MODEM es decir el MODEM reconoce el
tono generado de la tecla oprimida, una vez completado el comando, el verificador de
comandos (VeriComando) toma el comando y verifica si el comando es válido. El
verificador de comandos envía al simulador del robot (SimRobot) los comandos que sean
validos.

Ya que la comunicación es por tonos entonces VeriComando se comunica con el MODEM

GSM para que el MODEM envíe los siguientes mensajes:

1. Conexión aceptada.
2. Conexión rechazada.
3. Comando ejecutado con éxito.
4. Robot colisionó.
5. Robot atascado.
6. Robot moviéndose.

Las cadenas de caracteres establecidas para la definición de los comandos son las
siguientes:
1. ** indica que es el inicio o fin del comando.
2. #**cm. indica que el robot debe avanzar los centímetros indicados.
3. #*#grad indica que el robot debe girar los grados indicados.

Por ejemplo si queremos que el robot se mueva 20cm. La cadena del comando sería de la
siguiente manera: inicio – avanza20cm - fin
** #**20 **

De modo similar si queremos que el robot gire 90º tendríamos:

Inicio – gira90º - fin
** #*#90 **

Así serian los comandos que se emplearían para la comunicación.

Con respecto a la comunicación por mensajes cortos se tiene lo siguiente:

Desde el simulador del teléfono celular se debe acceder al menú o la tecla que nos sirva
para poder escribir un mensaje corto, que para este caso es un comando, así como también
introducir el número a quien se le va a enviar dicho mensaje y pulsar enviar. Este mensaje
se envía al centro de servicio de mensajes cortos y posteriormente éste lo envía al MODEM
GSM, el mensaje que se reciba se pasa al verificador de comandos. En caso de no ser un
comando válido el verificador de comandos debe construir un mensaje corto y enviarlo al
MODEM GSM para que posteriormente el MODEM GSM envíe el mensaje a la central de
servicio de mensajes cortos y posteriormente a SimCelular notificando que el comando es
inválido.

40
En el caso de la comunicación por mensajes cortos la forma del comando a enviar será
igual a la estructura de un mensaje corto.

Cuando el comando enviado se ha verificado y es válido entonces se pasa al robot para la

ejecución de dicho comando. El primer paso que se hace es verificar el estado del robot. El
cual tiene los siguientes estados:
Collision: El robot ha colisionado.
Moving: El robot se mueve.
Stopped: El robot esta encendido, con los motores encendidos, pero detenido
sin moverse.
No motors: El robot esta conectado, pero con los motores apagados.
Disconnected: El robot esta desconectado del servidor.

En los estados de “No motors”, “Disconnected” no se puede ejecutar el comando y se

informa del error, en el caso de que el estado del robot sea “Collision” solo se puede
ejecutar comandos de girar pero no de mover y cuando el estado del robot sea “Stopped” se
puede ejecutar cualquier comando.

Al ejecutar el comando el simulador del robot señala la ubicación del robot en el mundo
como lo muestra la figura 6.2

Figura 6.2: Ubicación del robot en el mundo

El robot cuenta con una cámara para ir captando imágenes del mundo por donde esta
caminando la cual es presentada en la figura 6.3. Cabe mencionar que la imagen de la
cámara del robot es enviada a la aplicación cliente.

41
 Figura 6.3: Cámara del robot

El simulador 3D nos permite ver las dos cámaras, es decir, la cámara del robot y la cámara
de usuario las cuales son presentadas en la figura 6.4

Figura 6.4: Cámara de robot y usuario

6.2.- Proceso de Modelado del sistema SimGSM.

A continuación veamos el proceso de modelado del sistema SimGSM el cual tiene las
siguientes fases:

• Análisis
• Diseño
• Implementación
• Pruebas

La fase de Análisis comprende los siguientes diagramas de UML

• Diagrama de Casos de uso
• Diagrama de clases

Para la fase de Diseño se tienen los siguientes diagramas de UML

• Diagrama de clases (a detalle).
• Diagrama de secuencia.
• Diagrama de interacción.

42
 • Diagrama de estado.
• Diagrama de actividades

Para la Implementación se dispone del siguiente diagrama de UML

• Diagrama de componentes.

Y por último tenemos las Pruebas, para ello utilizaremos el método de caja negra.

6.2.1.- Modelo de Análisis.

Con lo expuesto en el apartado del planteamiento del sistema SimGSM se identificaron dos
casos en la que podemos establecer comunicación con el robot, los cuales son:
• Tonos
• Mensajes cortos (SMS).

Para el diagrama de casos de uso tenemos los siguientes actores:

• SimCelular.
• SimRobot.
Y los siguientes escenarios para el caso de comunicación por tonos:
• Marcar.
• Enviar tonos de comando.
• Colgar.

Con los elementos citados anteriormente se elaboró el diagrama de casos de uso el cual es
mostrado en la figura 6.2.1 la cual muestra el modelado para SimGSM cuando se ejecuta
la comunicación por tonos.

Marcar
SimRobot

Enviar
comando
SimCelular

Colgar

Figura 6.2.1: Diagrama de casos de uso para el sistema SimGSM (Tonos).

Los escenarios del diagrama de la figura 6.2.1 son descritos a continuación.

Marcar.
1. SimCelular requiere comunicarse con el robot.

43
 2. SimCelular espera a que introduzcan un número (de 10 dígitos). Los diez
dígitos corresponden al número telefónico sin el 044
3. Establecer la comunicación con el MODEM GSM del robot.

Enviar Comando.
Como la comunicación es por tonos entonces el comando es enviado carácter por carácter
al MODEM GSM del robot, es decir, se genera un tono de la tecla oprimida el cual es el
que recibe el MODEM GSM y el proceso es como sigue:
1. Introducción y envío de caracteres del comando (tonos).
2. El MODEM GSM recibe los caracteres del comando (tonos).
3. SimRobot solicita la información del comando al MODEM, hasta que se
complete el comando.
4. SimRobot verifica el comando y si es válido lo ejecuta.
5. SimRobot envía la información sobre el comando y el estado del robot.

Colgar.
El usuario presiona la tecla colgar.
Rompe la conexión.

Para el diagrama de casos de uso en el caso de comunicación por tonos tenemos los
siguientes escenarios.
• Introducir mensaje corto.
• Enviar.

Ahora veamos el diagrama de casos de uso para el caso de mensajes cortos este diagrama es
mostrado en la figura 6.2.2.

SimRobot
Introducir mensaje
corto

SimCelular
Enviar

Figura 6.2.2: Diagrama de casos de uso para el sistema SimGSM (Mensajes Cortos).

Los casos de uso de la figura 6.2.2 son descritos enseguida.

Introducir mensaje corto.
1. SimCelular requiere comunicarse con el robot.
2. Introducir el comando y el número de destino.

44
Enviar.
1. Pulsar enviar.
2. El mensaje se envía a la central de mensajes cortos para posteriormente ser enviada
al número destino, que para este caso es el número del MODEM GSM del robot.
3. SimRobot obtiene del MODEM el comando enviado.
4. SimRobot envía al MODEM GSM la información del comando y el estado del
robot en forma de mensaje corto para que el MODEM pueda enviarlo.
5. El mensaje llega a la central de servicio de mensajes cortos y éste lo envía a
SimCelular.

Una vez realizados los diagramas de casos de uso abordaremos los diagramas de clases
teniendo en cuenta los requisitos mencionados en el diagrama de casos de uso.

En primer lugar tenemos el diagrama de clases para el caso de comunicación por tonos.
Las clases que se identificaron fueron las siguientes:

• El simulador del celular (SimCelular).

• El simulador del MODEM GSM (SimModemGSM).
• Control por celular (ControlCelular).
• El simulador de la central de servicios de mensajes cortos y central
telefónica (SimSMSCyCT).

La clase SimCelular es la que se encarga de simular alguna de las funciones del celular
entre las cuales tenemos las siguientes:
• Marcar
• Generar tonos
• Colgar
• Envío de mensajes cortos
• Recibir mensajes cortos

Para lo cual se apoya de una clase llamada “recibir información” que es la encargada de
recibir la información que sea enviada al simulador del celular.

La clase SimMODEMGSM se encarga de simular la función de recibir comandos ya sea

en forma de mensaje corto o de tonos así como también el envío de información del robot
hacia el simulador del celular.

La clase control por celular (ControlCelular) es la encargada de recibir los comandos

enviados para posteriormente verificarlos y su posible ejecución.

La clase SimSMSCYCT se encarga de simular a una central telefónica y a una de servicio

de mensajes cortos. Que para el caso de comunicación por tonos se utiliza la central
telefónica y para el de mensajes cortos la central de servicio de mensajes cortos, la cual
tiene una subclase llamada “escuchar” la cual es encargada de la recepción de la
información que llegue a ésta. El diagrama de la figura 6.2.3 muestra las clases
identificadas.

45
 SimCelular SimSMSCyCT SimModemGSM

Numero: String Numori: String Numero de

Mensaje: String Numdestino: String procedencia: String
NumeroSMSC: Información: String Modo: char
String Numinter: String

-Marcar -Conexión -Conexión robot.

-Introducir comando -Romper conexión -Enviar comando al
-Recib información -Envrob. robot.
-colgar -Envcel -Env resp comand.
-Introducir mensaje -Enviar Mensaje -Liberar conexión
corto Corto. -Recibir mensaje

ControlCelular

Estarob: string
Comando: string

-Verificar
-Ejecutar
-Enviar información

Figura 6.2.3: Clases del sistema SimGSM comunicación por tonos.

La figura 6.2.4 muestra las subclases de SimCelular y SimSMSCyCT respectivamente.

Recibir información Escuchar

Numori: String Numori: String

Numdestino: String Numdestino: String
Informacion: String Información: String
Numinter: String Numinter: String

-Recib información () -Escuchar ()

-Separar -Separar ()
información

Figura 6.2.4: Subclases de SimCelular y SimSMSCyCT.

46
La clase SimCelular tiene los siguientes atributos:

Número: este atributo guarda el número marcado por el usuario.

Mensaje: es la información a transmitir.
NúmeroSMSC: es el número que tiene la central.

Métodos de la clase SimCelular

Marcar: Este método se encarga de ir obteniendo el número que esta

introduciendo el usuario así como también el de solicitar la conexión con la
central telefónica.
Introducir comando: una vez establecida la conexión con la central
telefónica y el MODEM del robot, este método es el encargado de
identificar el carácter introducido y enviarlo al MODEM GSM.
Colgar: encargado de finalizar la conexión.
Recib información: es el encargado de recibir la información que llegue a
SimCelular la cual puede ser información acerca de l robot, información
sobre la conexión y mensajes cortos.
Introducir mensaje corto: es el método que permite al usuario introducir el
mensaje y es el encargado de comunicarse con el SMSC para el envío de
dicho mensaje.

Ahora veamos los atributos y métodos de la subclase de SimCelular (recibir información).

Los atributos son los siguientes:

Numori: Es el número de origen.

Numdestino: Es el número destino
Información: Es la información recibida
Numinter: Es el número intermedio por donde paso o pasara la
información.

Los métodos son los siguientes:

Recib información: es el encargado de recibir la información que llegue al

simulador del celular.
Separarinformacion(String): es el encargado de separar la información para
posteriormente mostrarla

A continuación tenemos la clase SimSMSCyCT la cual tiene los siguientes atributos:

Numori: Es el número de origen.
Numdestino: Es el número destino
Información: Es la información recibida
Numinter: Es el número intermedio por donde pasó o pasará la
información.

Métodos de la clase SimSMSCyCT:

47
 Conexión: es el encargado de establecer la conexión con el simulador
del MODEM GSM.
Romper conexión: se encarga de terminar la conexión.
Envrob: Envía la información del Smscyct al MODEM del robot.
Envcel: Envía la información del Smscyct al simulador del celular.
Enviar mensaje corto: Es el que envía el mensaje al destino
especificado.

Enseguida se explican los atributos y métodos de la subclase de SimSMSCyCT:

Numori: Es el número de origen.

Numdestino: Es el número destino
Información: Es la información recibida
Numinter: Es el número intermedio por donde pasó o pasará la
información.

Los métodos son los siguientes

Escuchar: es el encargado de recibirlas solicitudes.

Separar: es el encargado de separar la información

Posteriormente tenemos la clase SimModemGSM:

Los atributos son los siguientes:

Numori: Es el número de origen.

Numdestino: Es el número destino.
Información: Es la información recibida.
Numinter: Es el número intermedio por donde pasó o pasará la
información.

Los métodos son los siguientes:

Conexión robot: Es el encargado de establecer la conexión con el

robot.
Enviar comando al robot: es el encargado de enviar el comando al
robot
Env resp comand: Este envía la información relacionada con el
comando y el robot.
Liberar conexión: Es el encargado de liberar la conexión.
Recibir mensaje: Es el encargado de recibir los mensajes cortos

Los atributos de la clase ControlCelular son los siguientes:

Comando: es el comando enviado.
Esta rob: es el estado del robot antes de ejecutar el comando

48
Los métodos de Control Celular

Verificar: Es el encargado de verificar que el comando enviado es

correcto
Ejecutar: Es el que permite mandar al robot el comando a ejecutar
Enviar información: envía la información sobre el comando y el
estado del robot.

49
6.2.2.- Modelo de Diseño.

Ahora veamos las relaciones entre clases, las cuales se muestran en la figura 6.2.5.

SimCelular SimSMSCyCT SimModemGSM

Numero: String Numero de Numero de

Mensaje: String procedencia: String procedencia: String
NumeroSMSC: Modo: char
String

-Marcar -Conexión -Conexión robot.

-Introducir comando -Romper conexión -Enviar comando al
-Recib información -Envrob. robot.
-Colgar -Envcel -Env resp comand.
-introducir -Enviar mensaje -Liberar conexión
mensaje corto corto -Recibir mensaje

ControlCelular

Estarob: string
Comando: string
SimRobot

-Verificar
-Ejecutar
-Enviar información

Figura 6.2.5 Relaciones entre clases

Las relaciones mostradas en la figura 6.2.5 se explican a continuación

La clase SimCelular se comunica con la clase SimSMSCyCT para que ésta pueda establecer
la comunicación con el MODEM del robot (SimModemGSM) el cual se comunica con el
control del robot a través del celular (ControlCelular) la cual es al encargada de verificar el
comando así como también el de su ejecución y posteriormente la clase ControlCelular se
comunica con el paquete SimRobot para la ejecución del comando y para obtener
información del robot. La relación de las dos clases es la misma para los dos casos tonos y
mensajes cortos.

El paquete SimRobot mostrado en la figura 6.2.5 es el que nos proporciona la simulación

del robot.

50
A continuación tenemos el diagrama de composición que es presentado en la figura 6.2.6:

SimCelular SimSMSCyCT

Numero: String Numero de

Mensaje: String procedencia: String
NumeroSMSC: String

-Introducir mensaje corto -Enviar Mensaje

-Marcar Corto.
-Introducir comando -Conexión
-Recib información -Romper conexión
-Colgar -Envrob.
-Envcel

1 1

1 1
Recibir información Escuchar

Numori: String Numori: String

Numdestino: String Numdestino: String
Informacion: String Información: String
Numinter: String Numinter: String

-Recib información () Recib informacion ()

-Separar -Separar ()
información

Figura 6.2.6: Diagrama de Composición y de cardinalidad.

La figura 6.2.6 muestra el diagrama de composición y cardinalidad de las clases SimCelular

y SimSMSCyCT. En la cual la clase SimCelular se compone de la subclase Recibir
información la cual es el componente que le ayuda a recibir la información que llega a
SimCelular y la clase SimSMSCyCT se compone de la subclase escuchar la cual es la que la
ayuda a atender las solicitudes. La cual tiene una cardinalidad de uno a uno.

51
 SimRobot

1 1

1 1
SimModemGSM ControlCelular

Numero de Estarob: string

procedencia: String Comando: string
Modo: char

-Recibir mensaje -Verificar

-Env inf del robot -Ejecutar
-Conexión robot. -Enviar información
-Enviar comando al
robot.
-Liberar conexión

6.2.7: Diagrama de composición y cardinalidad del paquete robot

El diagrama de la figura 6.2.7 presenta el diagrama de composición y de cardinalidad del

paquete robot el cual tiene como componentes la clase SimModemGSM que es el
simulador del MODEM GSM y la clase ControlCelular y la cardinalidad es de uno a uno.

Para lograr el comportamiento del sistema SimGSM veamos la secuencia cronológica

entre los objetos para ello nos ayudaremos del diagrama de secuencia. Ahora utilizando la
información del diagrama de casos de usos haremos el diagrama de secuencia.

Para el caso de la comunicación por tonos el Diagrama de Secuencia es mostrado en las

figuras 6.2.8, 6.2.9 ,6.2.10.

52
 Celular: Smscyct: MODEM: Robot:
SimCelular SimSMSCyCT SimModemGSM SimRobot

Marcar
Conexión ()
Recib información ()
Conexión robot ()

Recib información ()
Recib información ()

Figura 6.2.8: Diagrama de Secuencia para el caso de uso marcar del caso comunicación por
tonos.

En la figura 6.2.8 se muestra el proceso de marcar para establecer la conexión, el cual se

explica a continuación: El usuario invoca primero el método “Marcar” del objeto Celular,
este método permite el ingreso de una serie de dígitos, posteriormente el objeto Celular
invoca el método “Conexión” del objeto Smscyct, el cual verifica el número marcado y si el
número introducido es del MODEM del robot, entonces genera una respuesta de “éxito” o
de “fracaso” e invoca al método “Recib información” del objeto Celular. Si la respuesta es
“éxito” entonces se intenta establecer la conexión con el MODEM del robot y éste envía
una respuesta de éxito o fracaso de la conexión al objeto Smscyct el cual invoca el método
recib información del objeto Celular. Si la respuesta es de éxito entonces queda establecida
la conexión con el MODEM GSM del robot.

Celular: Smscyct: MODEM: Robot:

SimCelular SimSMSCyCT SimModemGSM SimRobot
Introducir
comando
Envrob ()
Enviar comando al robot ()
Recibir comando ()

Env inf del robot ()

Envcel ()
Recib información ()

Figura 6.2.9: Diagrama de secuencia para el caso de uso introducir comando del caso
comunicación por tonos.

La figura 6.2.9 muestra el proceso de introducir comando el cual es el siguiente: El usuario

introduce el comando en el objeto Celular y después el objeto Celular invoca el método
“Enrov” del objeto Smscyct para el envío del mensaje. El objeto Smscyct invoca el método
“Enviar comando al robot” del objeto MODEM y enseguida el objeto MODEM invoca el

53
método “Recibir comando” del objeto Robot. Hasta este punto el comando ha llegado al
robot. Aquí es donde se utiliza el componente ControlCelular del paquete robot. En el cual
se analiza la validez del comando, si el comando es válido entonces chequea/verifica el
estado del robot y si el estado del robot es distinto a “colisión” entonces se podrá ejecutar
cualquiera de los dos comandos ‘girar’ o ‘mover’, pero si el estado es colisión entonces
solo se puede ejecutar el comando ‘girar’. Ya ejecutado el comando se informa al usuario
sobre el resultado de la operación, es decir, sobre la validez del comando o el estado del
robot.

Para enviar la información del robot, el objeto Robot invoca el método “Env inf del robot”
del objeto MODEM y a su vez éste invoca el método “Envcel” del objeto Smscyct para
enviar el mensaje. El objeto Smscyct invoca el método “Recib información” del objeto
Celular para recibir le información del robot.

Celular: Smsyct: MODEM: Robot:

SimCelular SimSMSCyCT SimModemGSM SimRobot
Robot:
Colgar
Romper conexión ()
Liberar conexión ()

Recib información ()
Recib información () Éxito o fracaso
Éxito o fracaso

Figura 6.2.10: Diagrama de secuencia para el caso de uso colgar del caso comunicación por
tonos.

La figura 6.2.10 muestra el proceso de colgar en el cual el usuario invoca el método

“Colgar” del objeto Celular para terminar la comunicación y el objeto Smscyct invoca el
método “liberar conexión” del objeto MODEM para liberar dicha conexión, el objeto
MODEM invoca el método “Recib información” para enviar un mensaje de dicha
operación así como también el objeto Smscyct invoca el método “Recib información” del
objeto celular para recibir la respuesta de la operación.

Ahora presentaremos el Diagrama de Secuencia para el caso de la comunicación por

mensajes cortos el cual corresponde a la figura 6.2.11.

54
 Celular: SimCelular Smscyct: SimSMSCyCT MODEM: SimModemGSM Robot: SimRobot

Enviar Mensaje Corto ()

1
Recibir mensaje ()
Recibir comando ()

Env inf del robot ()

Enviar Mensaje Corto ()

Recib informacion ()

1 Introducir mensaje corto

Figura 6.2.11: Diagrama de Secuencia para el caso de envió de comandos por mensaje
corto.

En la figura 6.2.11 el usuario invoca el método “introducir mensaje corto” del objeto
Celular, enseguida el objeto Celular invoca el método “Enviar mensaje corto” del objeto
Smscyct y consecutivamente el objeto Smscyct invoca el método “Recibir mensaje” del
objeto MODEM. En seguida el objeto MODEM invoca el método “Recibir comando” del
objeto robot, el objeto robot invoca el método “Env inf de robot” del objeto MODEM,
posteriormente el objeto MODEM invoca el método “Enviar Mensaje Corto” del objeto
Smscyct y éste invoca el método “Recibir mensaje corto” del objeto Celular.

Para poder modelar las interacciones entre objetos en el sistema construiremos el diagrama
de colaboración.

El diagrama de colaboración para el caso de comunicación por tonos se presenta en la

figura 6.2.12.

4: enviar comando al MODEM

Smscyct: SMSCyCT MODEM: SimModemGSM

7: enviar información al SMSCyCT 6: Env resp comand

8: recibir información
2: Establecer conexión 5: recibir comando
3: enviar comando al SMSCyCT Robot: SimRobot
1: Marcar
Celular: SimCelular

Figura 6.2.12: Diagrama de colaboración para la comunicación por tonos.

55
En el diagrama de la figura 6.2.12 el objeto Celular es el encargado de establecer la
conexión con el MODEM del robot, posteriormente podemos enviar el comando. Cabe
señalar que el comando se va enviando elemento a elemento, es decir, si queremos enviar el
comando **#**1000** primero se envía el * y así sucesivamente hasta terminar de enviar
el comando, el método “Recibir comando” es el encargado de recibir los elementos
enviados del comando, el método “Env resp comand” se encarga de enviar la información
sobre el robot al celular, el método “recibir información” recibe la información enviada por
el MODEM

A continuación la figura 6.2.13 representa el diagrama de colaboración para la

comunicación por mensajes cortos.

Smscyct: SimSMSCyCT
7: Recibir Robot: SimRobot
mensaje 6: enviar
mensaje
2: enviar mensaje corto 5: Env inf
del robot
1: Marcar
3: Recibir mensaje
Celular: SimCelular
4: recibir
comando

MODEM: SimModemGSM

Figura 6.2.13: Diagrama de Colaboración para la comunicación por mensajes

cortos.

En la figura 6.2.13 el proceso de envío de comandos por mensaje corto es el siguiente:

Se introduce primero el comando y posteriormente se invoca el método “enviar mensaje

corto” el cual requiere del número a quién se le va enviar el comando, este mensaje es
enviado al SMSCyCT el cual verifica el número así como también si puede enviar el
comando al destino indicado que, para este caso, debe de ser el número del MODEM. Si el
número introducido es el del MODEM, entonces lo envía al MODEM, una vez que éste lo
recibe lo pasa al robot, el cual lleva a cabo el proceso de verificar el comando y de si puede
ejecutarlo. Una vez hecho dicho proceso envía la información al MODEM para que éste la
envíe en forma de mensaje corto al SMSCyCT y posteriormente éste la envíe al celular.

Ahora continuaremos con los diagramas de estado para los objetos:

• Celular
• Smscyct
• MODEM
• Robot

56
El diagrama de estados para el objeto Celular es mostrado en la figura 6.2.14

Recib informacion
Conexión
Marcar Colgar
Celular Celular

Introducir
comando
Sin conexión

Figura 6.2.14: Diagrama de estados para el objeto Celular.

La figura 6.2.14 muestra los estados del objeto Celular el cual comienza cuando se invoca
el método marcar del objeto celular, posteriormente pasa a esperar respuesta sobre si se
estableció la conexión. Si la conexión quedó establecida entonces se procede a la
introducción y el envío de comandos o a colgar.

Romper conexión

Conexión
Smscyct
Envrob

Smscyct
Envcel

Figura 6.2.15: Diagrama de estados para el objeto Smscyct.

La figura 6.2.15 muestra los estados del objeto Smscyct el cual está en espera de una
conexión. El ser invocado dicho método identifica hacia donde va ir la información
recibida. Cuando la información va a ir del celular al robot se invoca el método Envrob y
cuando la información va ir del robot al celular se invoca el método Envcel.

57
 Liberar
conexión

Enviar
Conexión comando
robot al robot
MODEM MODEM

Env inf robot

Figura 6.2.16 Diagrama de estados para el objeto MODEM

La figura 6.2.16 muestra el diagrama de estados para el objeto MODEM el cual está
conectado con el robot. Cuando se invoca el método conexión robot el MODEM está en
espera de una instrucción. Para identificar cual método invocar éstos pueden ser el de
liberar conexión o el enviar comando al robot o enviar información.
El método enviar información es cuando se envía la información del robot hacia el celular.

add
Recibir comando

Robot Robot
Verificar estado
Robot
del robot
Robot Ejecutar

Figura 6.2.17: Diagrama de estados para el objeto robot.

En la figura 6.2.17 se presenta el diagrama de estados para el simulador del robot.

Inicialmente espera a que se agregue un robot. El simulador del robot espera recibir un
comando, al recibir el comando este verifica el estado del robot y posteriormente lo ejecuta
si fuera el caso. La ejecución depende del estado del robot. El diagrama de estados del
robot es mostrado en la figura 6.2.18.

Comando (girar, avanzar) Resultado del movimiento

add
STOPPED MOVING COLLISION

Resultado del movimiento Comando (girar)

Figura 6.2.18: Diagrama de estados del robot

58
La figura 6.2.18 muestra los estados del robot. El simulador del robot soporta a varios
robots pero para nuestro caso solo se utiliza un robot. Entonces lo primero que tenemos que
hacer es agregarlo, una vez agregado el robot su estado inicial es de “STOPPED” enseguida
espera por un comando el cual puede ser de avanzar o girar. A la hora del inicio de la
ejecución del comando el estado del robot cambia a “MOVING”, el estado resultante de la
ejecución del comando puede ser de “COLLISION”, este estado quiere decir que el robot a
chocado con algún obstáculo; ó de “STOPPED”, esto quiere decir que el robot esta listo
para ejecutar otro comando. Cuando el estado es de “COLLISION” el robot solo puede
ejecutar comandos de girar.

Introducir Establecer Enviar

mensaje conexión mensaje Colgar
corto
Celular Celular Celular

Celular Colgar
Recibir mensaje corto

Figura 6.2.19 Diagrama de estados para el objeto Celular (Mensajes Cortos).

La figura 6.2.19 muestra el diagrama de estados para el objeto celular para el caso de
mensajes cortos. Cuando se invoca el método introducir comando el objeto puede estar
esperando por recibir algún mensaje sobre la información del comando enviado o puede
enviar otro mensaje corto.

Enviar
mensaje Cerrar programa
corto
Smscyct

Enviar mensaje corto

Figura 6.2.20: Diagrama de estados para el objeto Smscyct (Mensajes Cortos).

En la figura 6.2.20 se muestra el diagrama de estados para el objeto Smscyct el cual al

enviar el mensaje corto pasa nuevamente a esperar para poder enviar otro mensaje y así
sucesivamente. Solo cerrando el programa se llega al estado final.

59
 Recibir
mensaje
Colgar
MODEM

Env inf de robot Colgar

MODEM

Figura 6.2.21: Diagrama de estados para el objeto MODEM (Mensajes cortos).

Lo mostrado en la figura 6.2.21 es el diagrama de estados para el objeto MODEM en el

caso de mensajes cortos el cual se describe a continuación.
Se comienza cuando se invocan cualquiera de los siguientes métodos: el método recibir
mensaje o el método Env inf de robot. El método recibir mensaje es invocado cuando llega
el mensaje corto al MODEM y el método Env inf robot es cuando se requiere enviar al
celular la información sobre el estado del robot, y volver a esperar una invocación de
alguno de éstos métodos.

Recibir
comando Veri comando

Robot Robot
Verificar estado
Robot
del robot
Robot Ejecutar

Figura 6.2.22: diagrama de estados para el objeto Robot (Mensajes Cortos).

La figura 6.2.22 muestra el diagrama de estados para el objeto robot. Cuando el método
recibir comando es invocado el objeto robot recibe el comando para su posterior
verificación y ejecución de dicho comando. El estado del robot es mostrado en la figura
6.2.19.

Diagrama de actividades:

A continuación se muestra el diagrama de actividades

60
 SimCelular SimModemGSM
SimSMSCyCT

Marcar

Conexión ()

Recib informacion Conexión robot ()

Recib informacion

Recib informacion

Figura 6.2.23 Diagrama de actividades para el caso de uso marcar

SimCelular SimModemGSM
SimSMSCyCT

Introducir comando

Envrob ()

Enviar comando al robot ()

Recibir
comando
Envcel

Env inf del robot

Recib informacion

Figura 6.2.24: Diagrama de actividades para el caso de uso introducir comando

61
 SimCelular SimSMSCyCT SimModemGSM

Colgar

Romper conexión ()

Liberar conexión
()

Recib informacion

Recib informacion

Figura 6.2.25: Diagrama de actividades para el caso de uso colgar.

SimCelular SimModemGSM
SimSMSCyCT

Introducir Mensaje
Corto ()

Enviar mensaje ()

Recibir mensaje ()

Recibir
comando ()
Enviar mensaje ()

Env inf del robot ()

Recib información ()

Figura 6.2.26: Diagrama de actividades para el caso de uso enviar mensaje corto

62
La figura 6.2.23 muestra el diagrama de actividades para el caso de uso marcar el cual
comienza con la invocación del método marcar, posteriormente se pasa a establecer la
conexión con el robot y el envío de la respuesta de la conexión de la central y a
continuación la respuesta de la conexión con el MODEM

La figura 6.2.24 presenta el diagrama de actividades para el caso de uso introducir comando
el cual se introduce el comando y se envía a la central. Posteriormente este lo envía al
MODEM del robot, y éste lo envía al robot y finalmente se envía la información del estado
del robot o del comando.

La figura 6.2.25 nos muestra el diagrama de actividades para el caso de uso colgar. El
usuario invoca el método colgar, el cual pasa esta solicitud a la central para que
posteriormente ésta termine la conexión con el MODEM el cual envía la respuesta de la
operación a la central y ésta la pasa al celular

En la figura 6.2.26 aparece el diagrama de actividades para el caso de uso envío de

mensajes cortos el cual comienza con la introducción del mensaje el cual es enviado a la
SMSC para su posterior envío al MODEM y éste lo envíe al robot, una vez verificado el
comando y posiblemente ejecutado se envía la información del robot y del comando en
caso de no ser un comando valido.

63
6.2.3.- Modelo de Implementación.

En la implementación ponemos en práctica el diseño, así como también la elección de la

interfaz del sistema. El sistema se ejecuta en una sola computadora en la cual se ejecutan
las clases ya implementadas del diseño.
Para la implementación se utilizó el diagrama de componentes el cual es mostrado en la
figura 6.2.27.

SimGSM
Simrobot

SimCelular SimSMSCyCT SimMODEMGSM

Numero: String Numero de Numero de

Mensaje: String procedencia: String procedencia: String
NumeroSMSC: Modo: char
String

-Introducir mensaje -Enviar Mensaje -Recibir mensaje

corto Corto. -Recibir información
-Recibir mensaje -Conexión -Conexión robot.
corto -Romper conexión -Enviar comando al
-Marcar -Envrob. robot.
-Introducir comando -Envcel -Enviar información.
-Resp conexión -Liberar conexión
-Recib información
-colgar

Figura 6.2.27: Diagrama de componentes.

El componente mostrado en la figura 6.2.27 es el sistema SimGSM. A continuación

veamos más a detalle dichos componente.

El componente SimGSM se integra de lo siguiente:

• Clase SimCelular.
• Clase SimSMSCyCT.
• Clase SimModemGSM.
• Paquete Simrobot

64
La clase SimCelular es la encargada de simular algunas de las funciones del teléfono
celular.

El paquete SimRobot consta de lo siguiente:

• Simulación del robot.
• Clase SimModemGSM.
• Clase ControlCelular.

El paquete Simrobot es el simulador JMR (Java Mobile Robot) el cual sólo tenía la función
de simular el robot y para lo cual se le agregó la clase SimModemGSM y la clase
ControlCelular, para simular que el robot está conectado a un MODEM GSM.

El paquete de simulación del robot es el encargado de recibir los comandos que el

verificador de comando identifique como válidos.

La clase modemGSM es la encargada de simular al MODEM GSM del robot la cual se

encarga de la comunicación entre el robot y la central telefónica o la central de servicios de
mensajes cortos.

La Clase ControlCelular es la encargada de verificar el comando así como también de

informar sobre la validez o invalidez del comando, y verificar el estado del robot y de
comunicarse con el simulador para la ejecución del comando.

El software usado fue el simulador del robot JMR 2.0 (JAVA Mobile Robots) [36].

El software utilizado para la implementación del simulador fue JAVA 1.4.1, la plataforma
en la que se ejecuta este simulador es en el sistema operativo “Windows XP Professional” y
se ejecuta en una computadora con procesador Pentium III a 500Mhz y memoria de
256MB.

A continuación veamos el funcionamiento del sistema.

El sistema de simulación del control de un robot móvil a través de GSM (SimGSM) consta
de tres módulos los cuales son las siguientes:
• SimCelular.
• Smscyct.
• Paquete de simulación del robot.

El paquete de simulación del robot consta de lo siguiente:

• Simulador del robot JMR
• MODEM GSM
• Control celular

La interfaz de SimCelular es la mostrada en la figura 6.2.28

65
Comenzaremos con la parte de SimCelular para lo cual nos apoyaremos del siguiente
ejemplo.
El usuario desea controlar el robot para lo cual deberá seguir lo siguientes pasos:
• Marcar el número del MODEM.
• Enviar comando.
• Colgar.

Al poner en ejecución el modulo SimCelular tenemos lo siguiente:

La interfaz de SimCelular la cual es mostrada en la figura 6.2.28
Ejecución de recib información que es el encargado de recibir toda la
información que llegue al simulador del celular.

Figura 6.2.28 interfaz de SimCelular.

Nota: El número del celular es el 2220000002, el de la central telefónica y la central de

servicio de mensajes cortos es el 2220000000, y el número del MODEM del robot es el
2220000001.

Cuando el usuario ha introducido el número deberá pulsar marcar, al pulsar marcar se

procede a formar la siguiente estructura para la solicitud de conexión:

Numero origen $ Numero destino $ Mensaje $ Numero CT

Que para el caso del ejemplo propuesto es el siguiente:

66
 2220000002 $ 2220000001 $ Conexión $ 2220000000

La cual contiene el número del celular, el número de destino que es el del MODEM, la
solicitud de conexión y el número de la central telefónica.

La estructura es enviada a la central telefónica, al recibir la central telefónica la solicitud de

conexión ésta toma la información la cual tiene la estructura mencionada anteriormente e
invoca un método para separarla y la cual queda de la siguiente manera:

Número origen = 2220000002

Número destino = 2220000001
Mensaje = conexión.
Número de central = 2220000000.

Enseguida compara el número de destino con el número del MODEM, si es igual entonces
establece la conexión con el MODEM y envía una respuesta de éxito, de no ser así envía
una respuesta de fracaso al celular.

Posteriormente la respuesta que envía la central telefónica al celular sobre si la conexión

fue aceptada o rechazada (éxito o fracaso) tiene la siguiente estructura:

2220000000 $ 2220000002 $ Éxito $ 2220000000

La cual se pasa al método para separar la información, el cual nos da el siguiente resultado.

Número origen = 2220000000

Número destino = 2220000002
Mensaje = éxito
Número de central = 222000000.

Una vez establecido la conexión, el usuario empieza a introducir el comando el cual se va

introduciendo carácter a carácter. La figura 6.2.29 muestra que la conexión fue aceptada.

Por ejemplo veamos el comando

**#**1000**

Al enviar el primer carácter, éste se hace conforme a la estructura descrita anteriormente

que para el ejemplo es la siguiente:

2220000002 $ 2220000001 $ * $ 2220000000

Esta información es enviada a la central la cual la recibe la separa y la encamina hacia el

MODEM.

67
 Conexión aceptada

Figura 6.2.29: Conexión aceptada con el robot.

Al llegar el comando al MODEM éste lo pasa al robot. Como al simulador del MODEM
llega la información éste la separa y envía el mensaje al robot y se invoca el método para
verificar si el comando es válido. Cabe mencionar que el paso de información es por medio
de comandos AT.

Como el comando está llegando al robot carácter a carácter entonces se va verificando

carácter a carácter hasta que se complete el comando, la figura 6.2.30 muestra la recepción
del comando.

Si el comando es válido entonces verifica el estado del robot, si el estado del robot es el de
colisión entonces identifica de que comando se trata, si es de avanzar o girar, si es de
avanzar entonces el comando no se ejecuta pero si es de girar lo ejecuta. Si el estado es de

68
movimiento espera a que termine de moverse y posteriormente ejecuta el comando
verificando de nueva cuenta el estado del robot y si el estado es de parado entonces ejecuta
el comando enviado, la ejecución del comando se presenta en al figura 6.2.31.

**#**1000

Figura 6.2.30: Recepción de comandos por medio de comunicación por tonos.

La ejecución del comando es mostrada en la figura 6.2.31 la cual muestra la lectura de los
sónares, el estado del robot, así como también los números telefónicos involucrados en la
comunicación, el comando de mover y el comando enviado por el usuario. En la figura
6.2.32 se muestran la cámara de usuario y la cámara del robot, la cámara de usuario es
como si fuera una cámara colocada en la parte de arriba para observar el mundo donde el
robot va interactuar y la cámara del robot es la que tiene colocada el robot.

69
 Mover
**#**1000**

Figura 6.2.31: Ejecución del comando enviado.

Figura 6.2.32: Cámara del robot y cámara de usuario.

70
Posteriormente envía la información sobre el comando en caso de ser inválido, en caso
contrario envía la información sobre el estado del robot de la siguiente manera:

2220000001 $ 2220000002 $ Información $ 2220000000

La cual en información va el estado del robot o la palabra de invalido en caso de que el

comando lo fuera. Esta información es pasada al MODEM para que la envíe a la central y
posteriormente al celular.

Por otra parte el celular está esperando la respuesta de la validez o invalidez del comando o
la información sobre el estado del robot. Una vez recibida la respuesta se procede a enviar
otro comando o a colgar.

Para colgar se envía la información de la siguiente manera:

2220000002 $ 2220000001 $ Salir $ 2220000000

La cual es enviada a la central telefónica para liberar la conexión

A continuación veamos el envío de comandos por medio de mensajes cortos

El usuario envía un comando por medio de mensaje corto.

El usuario introduce primero el comando como lo muestra la figura 6.2.33 y debe pulsar el
botón de SMS, posteriormente se debe introducir el número a quien se le va a enviar el
mensaje como lo muestra la figura 6.2.34 y pulsar el botón enviar.

**#**1000**

Figura 6.2.33: Envío de comando por medio de mensajes cortos.

71
 Figura 6.2.34: Introducir número.

Al pulsar el botón de enviar se forma la siguiente estructura para ser enviada a la central de
servicio de mensajes cortos

2220000002 $ 2220000000 $ **#**1000** $ 2220000001

Primero tenemos el número que corresponde al número del celular, enseguida tenemos el
número corresponde a la central de servicio de mensajes cortos, posteriormente el comando
y finalmente el número del destinatario.

Al llegar esta información al central se invoca al método que separa la estructura en lo

siguiente:

Número origen = 2220000002

Número destino = 2220000000
Mensaje = **#**1000**
Número de destinatario = 2220000001

72
En este caso el número de destino es el de la central porque es donde se envía el mensaje, el
número de destinatario es el número del MODEM. La figura 6.2.35 muestra la central
telefónica para este caso.

Figura 6.2.35: Mensaje corto en la central telefónica

Posteriormente se invoca el método que envía el mensaje al número indicado. El MODEM

del robot recibe la información e invoca al método para separar la información y pasar el
mensaje al robot.

El robot recibe el mensaje (comando) e invoca el método para verificar el comando como el
comando es válido para este caso entonces chequea el estado del robot para verificar si lo
puede ejecutar, esto quiere decir que para poder ejecutar un comando de mover sólo se
puede ejecutar si el robot no está en estado de colisión y un comando de girar se puede
ejecutar sin importar el estado en el que se encuentre.

73
6.2.4.- Modelo de Pruebas y Resultados.
Prueba 1

El objetivo de esta prueba es de determinar la respuesta del simulador cuando el número

marcado es distinto al del MODEM

Supongamos que el número marcado es el siguiente 2220000004.

El número es enviado a la central telefónica y cuando llega a la central (Smscyct), ésta
verifica si el número es valido y si puede establecer la comunicación con dicho número.
Para el caso citado anteriormente no se podrá establecer la comunicación ya que este
número no es conocido por la central telefónica.
La figura 6.2.36 muestra el número marcado en el celular.

La figura 6.2.37 muestra el número de quien marco, el número de destino, el mensaje que
dice que el número es desconocido y que fue una solicitud de conexión.

Figura 6.2.36: Número marcado

74
 Figura 6.2.37: Central telefónica

Prueba 2.

El usuario envía un mensaje pero el número de destino no es conocido por la central de

servicios de mensajes cortos

Primero introduciremos el comando y luego el número y posteriormente será enviado a la

central de servicios de mensajes cortos de la siguiente manera:

2220000002$2220000000$**#**1000**$2220000001

La cual separa la información y hace las comparaciones de los números para reencaminar el
mensaje pero como no lo conoce manda el siguiente mensaje al celular:

“El número esta fuera de alcance”

El cual es presentado en la figura 6.2.38.

75
Figura 6.2.38: el número esta fuera de alcance

76
Prueba 3
Cuando el comando enviado es incorrecto.
El comando es introducido y enviado a la central y posteriormente la central lo envía al
robot el cual lo verifica y envía el mensaje de comando incorrecto.

Figura: 6.2.39: El comando es incorrecto

La figura 6.2.39 presenta el caso cuando el comando es incorrecto. Esto es para cuando la
información es enviada por medio de mensajes cortos y para la comunicación por tonos es
similar.

77
Capitulo 7

Interfaz entre simuladores.

En este capitulo describiremos la interfaz de los simuladores SimGSM y JMR. Para un
buen funcionamiento del sistema se debe ejecutar lo siguiente:
• El simulador del celular.
• El simulador de la central de servicios de mensajes cortos y la central telefónica.
• El simulador del Robot JMR.

7.1. SimGSM.

El simulador de GSM consta de lo siguiente:

1. Un simulador de un teléfono celular: con el cual se emula el marcado de
un número para el establecimiento de una llamada por tonos al igual que
el envío de mensajes cortos.
2. Un simulador del centro de servicios de mensajes cortos y la central
telefónica (SMSCyCT).

Se le asignó un número telefónico a la central de servicios de mensajes el cual es el

2220000000 e igualmente al simulador del teléfono celular el cual es 2220000002, el
número asignado al MODEM es el 2220000001.

La interfaz del simulador del teléfono celular se presenta en la figura 7.1

Figura 7.1: Interfaz del componente SimCelular.

78
Esta interfaz tiene las teclas de marcar y colgar además de la tecla de envío de mensajes
cortos y las teclas que comúnmente tiene un teléfono celular.
Para el marcado de un número sólo debemos dar clic en la tecla del número que se desee y
una vez terminado la introducción del número procedemos a pulsar la tecla marcar.

Por otro lado tenemos el simulador de la central de mensajes cortos y la central telefónica la
cual tiene una interfaz como la mostrada en la figura 7.2.

Figura 7.2: Interfaz del componente SMSCyCT.

En la figura 7.2 de la interfaz del componente SMSCyCT se muestra los números de los
teléfonos entrante, intermedio, saliente y el mensaje en caso que se trate del envío de un
mensaje corto.

A la hora de pulsar marcar en el simulador del celular, éste se conecta con la central
telefónica para verificar el número y posteriormente establecer la llamada. En este caso,
como la central telefónica sólo puede establecer la llamada con el MODEM del robot sólo
acepta el numero 2220000001. Si se marcara cualquier otro número entonces se escuchará
un tono de ocupado y no se podrá establecer la comunicación. Esto es para la comunicación
por tonos. Para la comunicación por mensajes cortos la central de mensajes cortos sólo
conoce también el número 2220000001 que corresponde al MODEM del robot. En caso
que se introduzca otro número de destino, la central telefónica respondería con un mensaje
de que el número no existe.

Una vez verificado que el número es correcto se establece la comunicación con el MODEM
del robot por medio de tonos y podemos empezar a introducir los caracteres del comando.

79
7.2. Java Mobile Robots (JMR).

La interfaz del simulador JMR es la mostrada en la figura 7.3:

Figura 7.3: Interfaz del cliente del simulador JMR

La figura 7.3 muestra la interfaz del cliente del simulador JMR en la cual podemos añadir
más robots así como también quitarlos.
Para añadir un robot solo se pulsa en el botón “add” y se nos presenta un cuadro de diálogo
como el mostrado en la figura 7.4

Figura 7.4: Cuadro de diálogo.

80
En el cuadro de diálogo mostrado debemos introducir el nombre del robot que deseamos y
pulsar aceptar. A continuación se presentará una ventana para elegir el mundo sobre el cual
el robot se desenvolverá. La ventana es como la mostrada en la figura 7.5. Posteriormente
se carga el mundo elegido en el simulador 3D de java, el cual es mostrado en la figura 8.6.

Figura 7.5: Abrir mundo.

La figura 7.5 muestra el cuadro de dialogo abrir y los mundos con los que se cuentan.

Figura 7.6: Simulador 3D de java

81
En la figura 7.6 se muestra el simulador 3D de java el cual es el espacio donde el robot se
desenvuelve.
En la figura 7.3 de la interfaz se muestran 5 cuadros de texto en los cuales se despliega la
información que pasa el MODEM al simulador del robot, estos son:

• No. de origen
• No. destino
• Comando
• Número
• VeriComando

No. de origen: Este es el número del celular que esta enviando el comando.
No. destino: Este es el número del MODEM.
Comando: Es el comando enviado para la ejecución.
Número: Es el número intermedio por el cual paso el comando.
VeriComando: Es el que verifica si el comando es válido y ahí se muestra el resultado.

82
8. Conclusiones y observaciones.
Esta tesis ha presentado el modelado, usando UML, del sistema simulador del control de un
robot móvil a través de GSM. El modelado incluye: el modelo de análisis, el modelo de
diseño, modelo de implementación y modelo de pruebas.

Cada modelo esta formado por diferentes diagramas UML. En el modelo de análisis se
tienen los diagramas de casos de uso y diagrama de clases, para el diseño tenemos los
diagramas de clase, secuencia, interacción, estado y actividades, y para la implementación
se tiene el diagrama de componentes. La implementación se desarrolló usando los paquetes
JMR, Java Media Framework, y el lenguaje de programación java. El sistema es una
arquitectura cliente servidor.

Al simulador JMR que es el encargado de simular el robot, se le agrego la parte del

simulador del MODEM GSM ya que no contaba con esta función. El paquete Java Media
Framework se utilizó para generar los tonos del simulador del celular.

El desempeño del simulador del celular, el simulador de la central telefónica y servicios de

mensajes cortos y el simulador del MODEM GSM, bajo operaciones normales es bueno,
es decir, en las operaciones de comunicación por medio de mensajes cortos y tonos, debe
estar ejecutándose los simuladores citados anteriormente de lo contrario fracasara la
comunicación. Con la implementación del simulador se logro el objetivo propuesto en esta
tesis.

Al sistema de simulación del control de un robot móvil a través de GSM se podría hacer un
modelado más a detalle y también mejorar la organización del sistema para así poder
contemplar más aspectos que pudieran con llevar a un mejor funcionamiento del mismo, así
como también el de la transferencia de imágenes que capta la cámara del robot al celular.
Además se puede hacer más eficiente la comunicación por tonos si en lugar de transmitir
caracter a caracter se transmite en una trama GSM, como se realiza en la comunicación por
mensajes cortos.

A futuro la simulación del control de un robot móvil podría ser implementada de manera
real, es decir, que desde un teléfono celular con tecnología GSM se pueda controlar a un
robot, y poder recibir en el celular las imágenes que capta la cámara del robot.

83
Apéndice 1 Funcionamiento del Sistema GSM y Arquitectura del
Protocolo
Redes de bases de datos y estandarización

GSM define un número de bases de datos de la red que son utilizadas en la ejecución de las
funciones del administrador de la movilidad y control de llamadas en una red móvil
terrestre pública (PLMN). Estos elementos incluyen los registros de la localización que
consisten del registro de localización de llamada (HLR), el registro de la localización del
visitante (VLR), el registro de identificación del equipo (EIR), y la central de
autentificación (AC). El HLR mantiene y actualiza la localización del suscriptor móvil y/o
su información de perfil de servicio. El VLR mantiene la misma información localmente,
donde el suscriptor está vagando. El VLR es definido como una función independiente,
pero es visto generalmente por los vendedores como parte del MSC. Estos registros son
llamados puntos de control de servicio (SCP) en la terminología usada en una red
inteligente (IN). El EIR es utilizado para enumerar las identidades del equipo de los
suscriptores, que se utilizan para la identificación del equipo desautorizado del suscriptor, y
por lo tanto la negación del servicio por la red. La AC proporciona las claves y algoritmos
para mantener la seguridad de las identidades del suscriptor, y para la encriptación de la
información pasada sobre el interfaz del aire. El MSC se equipa de un módulo de punto de
conmutación del servicio (SSP) el cual es utilizado para consultar las bases de datos tales
como un registro de la localización para identificar donde encontrar a un suscriptor móvil y
cuál es su perfil de servicio, para el encaminamiento, y procesamiento de las llamadas al
suscriptor.

Las especificaciones de GSM han definido funciones lógicamente separadas e interfaces

estándares para cada una de las bases de datos para permitir que cada función sea
implementada en una componente de la red separada físicamente.

Las interfaces se especifican vía la parte de aplicación del móvil (MAP) que utiliza la
parte de aplicación de la capacidad de la transacción (TCAP) de (SS7). Estos son todos los
elementos de una IN. GSM se considera una aplicación de IN y proporciona esta
consideración de implementación de GSM como experiencia en establecimiento de una red
inteligente.

Plan de numeración

La enumeración consiste en por lo menos un número de ISDN internacional asignado ya

sea al suscriptor móvil, si el teléfono celular funciona por tarjeta, o a la estación móvil, o
diferente. La estación móvil ISDN (MSIS-DN) se conforma con la recomendación del
CCITT E.164, y debe cumplir, en cada país, con el plan de enumeración del ISDN de ese
país. El número de MSISDN consiste básicamente de un código de país (CC), un “código
de destinación nacional (NDC), que especifica un PLMN dentro de ese país, y un número
de suscriptor (SN).

84
El número de MSISDN es utilizado para marcar por un suscriptor que llama del
PSTN/ISDN, y utilizado para encaminar la llamada a la entrada MSC de la red GSM. El
GSM MSC entonces utiliza el MSISDN para interrogar al HLR apropiado para requerir la
información para el encaminamiento y ampliar la llamada al MSC del teléfono celular que
visita.

La información de reencaminamiento es especificada por el número de roaming de la

estación móvil (MSRN) que se obtiene del HLR y se utiliza para dar progreso a la llamada
al teléfono celular llamado. El MSRN es un número temporal, asignado por el VLR
(asociado al MSC que visita el teléfono celular) y enviado al HLR del teléfono celular
referido a la actualización en la localización del teléfono celular o sobre una llamada por
base. El MSRN tiene la misma estructura de los números de MSISDN en el área de la
localización del visitante donde ésta es asignada

Direccionamiento y encaminamiento de la llamada

El número de MSISDN se utiliza para el encaminamiento de llamadas dentro de las redes

PSTN/ISDN. Los párrafos siguientes proporcionan una discusión sumaria de los panoramas
posibles implicados en el encaminamiento de la llamada.

Llamadas nacionales desde la red fija

Un intercambio local o de tránsito, al recibir una llamada destinada para un móvil, reconoce
el NDC, y encamina la llamada a una entrada MSC. La entrada MSC realiza la pregunta de
HLR para el MSRN, que entonces utiliza para reencaminar la llamada.

Llamadas internacionales desde la red fija

Cuando un intercambio local o de tránsito recibe una llamada internacional y reconoce el

prefijo internacional, encamina la llamada al ISC más cercano. El ISC reconoce que el
NDC indica una PLMN. Si éste puede apoyar la pregunta de HLR (es decir, si éste tiene
conectividad de señales (TCAP) al HLR) ésta pregunta al HLR y recibe el número de
roaming del suscriptor llamado y encamina la llamada al MSC que visita. Sino, encamina la
llamada al ISC de la PLMN del lugar del suscriptor llamado.

Llamadas nacionales desde dentro de una PLMN

Cuando un intercambio local (MSC) recibe una llamada destinada para un teléfono celular,
éste pregunta al HLR del teléfono celular por el número roaming del teléfono celular. En
el recibo del MSRN, encamina la llamada al MSC del teléfono celular llamado.

Direccionamiento de otros componentes de una PLMN

Otros componentes de una PLMN, los cuales pueden ser direccionados para el
encaminamiento de varios mensajes de señales, son los MSC’s, y los registros de
localización. Si estos elementos se direccionan dentro del mismo PLMN, los códigos de
punto (CP) SS7 pueden ser utilizados. Si no, para el encaminamiento del interPLMN, los

85
títulos globales (GT) derivados, por ejemplo, del código del país móvil (MCC) y de los
códigos de destinación nacionales (NDC) se utilizan.

Estructura del canal de radio en GSM

En GSM, los canales de radio se basan en una estructura de TDMA que es implementada
en las subbandas de múltiple frecuencia (TDMA/FDMA). Cada estación base se equipa
de cierto número de estos canales de frecuencia /tiempo preasignados.

La CEPT ha hecho disponible dos bandas de frecuencia para ser utilizados por el sistema
GSM. Estas son: 890-915MHz para transmitir del teléfono celular a la estación base y 935-
960MHz para transmitir de la estación base al teléfono celular. Estas bandas son divididas
en 124 pares de portadores espaciados por 200KHz, comenzando con el par 890.2MHz.
Cada sitio de la célula tiene una asignación de cierto número de portadores, extendiéndose
de solamente de uno a generalmente no más de 15 canales. La célula alcanza en tamaño de
uno a varios kilómetros.

El espectro asignado de 200KHz por canal es dividido en segmentos de tiempo usando

una asignación fija, siendo el esquema del acceso múltiple de división de tiempo (TDMA).
El eje del tiempo se divide en ocho ranuras con longitud de 0.577ms. Las ranuras se
numeran de la 0 a la 7 y forman un marco con longitud de 4.615ms. La repetición de una
ranura de tiempo en particular en cada marco constituye un canal físico.

El esquema de TDMA utiliza un bit total de índice alrededor de 270kb/s (con un cambio
mínimo gaussiano afinando la modulación, GMSK) y requiere adaptar técnicas sofisticadas
de receptor para hacer frente a los problemas de la transmisión causados por la desaparición
multidireccional.

El factor de TDMA de 8 conjuntamente con un espaciamiento de portador de 200KHz

correspondería al sistema análogo anterior usando solo un canal por portadora con un
espaciamiento de portador de 25KHz.

El sistema digital GSM permitió la operación en portadores de más baja interferencia de

radio (C/I) usando las ganancias por la compresión digital de voz junto con la codificación
del canal (corrección de error de gran alcance). El cociente reducido de C/I alternadamente
permitió el uso de distancias más cortas para la reutilización del canal para lograr una
eficiencia del espectro competitivo a la lograda por los sistemas analógicos.

La estructura TDMA es aplicada en ambas direcciones de la estación base al móvil y del

teléfono celular a la estación base. La numeración, no obstante, es escalonada por tres
ranuras de tiempo, para evitar que la estación móvil transmita y reciba al mismo tiempo.
Estas ranuras de tiempo son utilizan para llevar al usuario señales o información de control
en ráfagas. Las ráfagas son ligeramente más cortas que las ranuras, son de 546ms, se tienen
en cuenta los errores de alineación y sincronización de ráfagas, y el retraso en la dispersión
sobre la trayectoria de propagación.

86
El GSM define una variedad de tráfico y los canales de señales/control con diversos índices
de bit. Estos canales son asignados a canales lógicos derivados de la estructuración de las
ocho ranuras básicas de marcos TDMA. Para este propósito, se han definido dos estructuras
de multiframe: una que consiste en 26 marcos de tiempo (dando por resultado un intervalo
de repetición de 120ms), y uno que abarca 51 marcos de tiempo (o 236ms). El multiframe
26 se utiliza para definir los canales del tráfico (TCH), y sus canales asociados lentos y
rápidos de control (SACCH y FACCH) que llevan la información de control del enlace
entre el teléfono celular y las estaciones base.

Los TCH se han definido para proporcionar seis diversas formas de servicios, es decir,
canales de datos o conversación de máxima velocidad (fullrate) soportando velocidades
efectivas de bits de 13kb/s (para conversación), 2.4, 4.8, y 9.6kb/s y canales de velocidad
media con velocidad efectiva de bits de 6.5kb/s (para conversación) y 2.4kb/s, y 4.8kb/s
para datos (nota que la velocidad total de bit sobre estos canales es más alta debido a la
codificación requerida del canal, 22.8kb/s máxima velocidad para conversación) la máxima
velocidad de los TCH’s se implementa en 24 marcos del multiframe, con cada TCH
ocupando una ranura de tiempo de cada marco. El SACCH es implementado en el marco 12
(numerado a partir de la 0), proporcionando ocho canales SACCH, uno dedicado a cada
uno de los ocho canales de TCH. El marco 25 en el multiframe es actualmente ocioso y
reservado para implementar los ocho SACCH adicionales requeridos cuando los canales de
conversación de media velocidad se convierten en una realidad.

El FACCH es obtenido a petición por robo del TCH, y utilizado por cualquier terminal para
señalar las características y la transferencia de la trayectoria física, u otros propósitos tales
como conexión “handover” de control de mensajes. El robo de una ranura de TCH para
señales FACCH se indica a través de una bandera dentro de la ranura de TCH.

El marco 51 del multiframe tiene una estructura más compleja y referiremos al lector a la
recomendación 05.0 del G/M para las posiciones específicas de varios canales lógicos en el
multiframe. La estructura del marco 51, sin embargo, se utiliza para derivar los canales de
señales siguientes y de control.

SDCCH – el canal de control dedicado es único y se utiliza para la transferencia del control
de la llamada que señala a y desde el teléfono celular durante el establecimiento de la
llamada. Como los TCH’s, el SDCCH tiene su propio SACCH y se libera una vez que la
llamada es establecida.

BCCH – el canal del control de la difusión se utiliza del BSS al teléfono celular para emitir
información del sistema tal como los parámetros de sincronización, servicios disponibles y
el ID de célula. Este canal está continuamente activo, con ráfagas ficticias sustituidas
cuando no hay información que transmitir porque la fuerza de las señales es supervisada
por los teléfonos celulares para la determinación de desocupado.

SCH – el canal de la sincronización lleva la información del BSS para la sincronización del
marco.

87
FCCH – el canal del control de la frecuencia lleva la información del BSS para la
sincronización del portador.

CCCH – los canales comunes de control se utilizan para transferir señales de información
entre todos los teléfonos celulares y el BSS en funciones de creación de la llamada y
paginación de la llamada callpaging.

Hay tres canales comunes de control:

• PCH: el canal de paginación para llamar (paginar) a un teléfono celular del sistema
• RACH: el canal de acceso aleatorio usado por los teléfonos celulares que intentan
tener acceso al sistema. Los usuarios móviles utilizan el esquema ranurado de Aloha
sobre este canal para solicitar un DCCH del sistema en la iniciación de la llamada.

• AGCH: el canal de la concesión de acceso usado por el sistema para asignar

recursos a un móvil tal como un canal de DCCH.

Observe que los AGCH y los PCH nunca son utilizados por un teléfono celular al mismo
tiempo, y por lo tanto son implementados sobre el mismo canal lógico. Todos los canales
de señales de control, excepto el SDCCH, son implementados en la ranura de tiempo 0 en
diversos marcos de TDMA de los 51 multiframes usando una frecuencia portadora dedicada
RF asignada en una por célula base. La estructura del multiframe para el SDCCH y su canal
asociado lento asociado del control (SACC) se pone en ejecución en uno de los canales
físicos (las ranuras de TDM y los portadores del RF) seleccionados por el operador de
sistema.

Administración de la movilidad

Conexiones “handoffs”.
Estas conexiones pueden ser hechas entre los canales en la misma célula, entre los canales
en diversas células bajo misma cobertura de BSS, o entre las células bajo cobertura de
diversos BSS’s, e incluso entre diversos MSC’s. En GSM, el BSS puede autónomamente
manejar las conexiones handoffs en la misma célula, o entre las células bajo su propia
cobertura. Esto se llama conexiones handoffs internas. El MSC está implicado en el manejo
de las conexiones handoffs que necesitan ocurrir entre las células bajo cobertura de dos
diversos BSS’s. Estas son llamadas conexiones handoffs externas.

Cuando el BSS indica que un handover externo se requiere, la decisión de cuando y si un

handover externo debe ocurrir entonces es tomado por el MSC. El MSC utiliza la
información de la medida de calidad de la señal divulgada por las estaciones móviles
(MS’s) que son preprocesados en el BSS para la determinación del handover externo.

El MSC original que maneja una llamada mantendrá siempre el control de la llamada en un
handover externo a un MSC diferente e incluso a un MSC subsecuente. Cuando el BSS
realiza una conexión handoff interna, ésta informa al MSC la terminación del proceso. La
necesidad de una conexión handoff se puede indicar por el usuario móvil, a través de
mensajes en el FACH, o por el BSS ya que éste mantiene el rastreo de la calidad de las

88
señales recibidas. El BSS supervisa la calidad de la señal de radio recibida y también
transmite tales resultados al MSC quien mantiene una vista más global sobre los canales de
radio que pertenecen a su BSS’s. El MSC también puede iniciar la necesidad de una
conexión handoff por razones de tráfico en una tentativa de balancear la carga fuera del
tráfico en la red.

Manejo de información de localización

La información de la localización es mantenida y utilizada por la red para localizar al

usuario para los propósitos del encaminamiento de la llamada. La red registra la
localización del usuario en un registro llamado el HLR del usuario, que se asocia a un MSC
situado en el PLMN, al cual suscriben al usuario. Cada BSS guarda la difusión, sobre una
base periódica, de las identidades de la célula en “los canales del control de la difusión” de
las células bajo su cobertura. Los móviles dentro de cada célula mantienen controlada tal
información. Como se detectan cambios en la localización (de la última información
registrada por ellos), cada uno de ellos reporta la nueva localización al BSS que encamina
esto al VLR del MSC con el cual está conectado. El VLR, alternadamente, envía la
información de la localización al HLR del usuario, donde también se registra. Mientras
tanto, el HLR ordena al viejo VLR suprimir la vieja localización de visita del teléfono
celular de su base de datos, y también envía una copia del perfil del servicio del usuario al
VLR nuevo. La actualización de la localización es realizada por la subcapa del protocolo
de la administración de la movilidad (MM).

Ruteando y señalizando llamadas

Una llamada puede ser iniciada por un usuario móvil a otro móvil o un usuario fijo, o al
revés, por un usuario fijo a un móvil. Para encaminar una llamada a un usuario móvil, sin
embargo, la señal de red necesita primero localizar el móvil. Ilustraremos esto para el caso
cuando una llamada es iniciada por un usuario fijo, y después comentaremos respecto al
panorama en el cual la llamada es iniciada por un móvil a otro móvil. Cuando la llamada es
iniciada por un móvil a un usuario fijo, el procedimiento es un poco directo.

En el caso de una llamada iniciada por un usuario fijo, el PSTN puede utilizar el número
ISDN de la estación móvil, MSISDN, para encaminar la llamada a la entrada más cercana
MSC dentro de PLMN del móvil. El GMSC alternadamente utiliza el MSISDN para
interrogar al HLR del móvil para la información de encaminamiento requerida para ampliar
la llamada al visitante MSC del móvil en ese entonces. Este visitante MSC (o más
específicamente, el VLR dentro del MSC local) es identificado en el HLR del móvil por el
MSRN que especifica el MSC visitante

El MSRN es un número temporal asignado por el VLR y enviado al HLR en la

actualización de la localización, o la iniciación de la llamada. El MSRN debe tener la
misma estructura que el número MSISDN al del área donde el VLR es asignado. El VLR
entonces inicia el procedimiento de paginación y las páginas MSC son enviadas a la
estación móvil con una paginación broadcast a todas las BSS’s del área de localización, así
también el área exacta de la estación base del móvil podría no ser conocida.

89
Después de respuesta de paginación, la actual BSS está situada. Se establecen las
conexiones RR y MM, al igual que la autentificación del usuario (para acceder a la red),
además del cifrado.

El VLR entonces envía los parámetros requeridos para establecer la llamada al MSC, y
puede también asignar al teléfono celular un TMSI nuevo para la llamada. El MSC envía un
mensaje de establecimiento a la estación móvil. La estación móvil, al recibir el mensaje de
establecimiento, realiza una comprobación de compatibilidad y retorna un mensaje de
llamada confirmada a la red, que puede incluir la capacidad de portador de la estación
móvil.

El BSS puede en este punto asignar un canal del tráfico, TCH, a la llamada, o puede asignar
éste en una plataforma posterior, siendo los últimos al recibir el “mensaje conectar” de la
estación móvil. Si la alerta de usuario es llevada fuera del MS, un mensaje de alerta se
envía al suscriptor que llama. Cuando, el suscriptor contesta a la llamada, el MS envía un
mensaje de conectar, que en el lado de la red inicia la terminación de la asignación del
canal de tráfico y el intercambio a través de la conexión. El mensaje de conectar progresa al
suscriptor de la llamada. La red también envía un reconocimiento al MS, de entrada en el
estado activo.

Arquitectura de las capas del protocolo

La arquitectura del protocolo del GSM usada para el intercambio de señales de mensajes
concierne a la movilidad, los recursos de radio, y las funciones de administración de la
conexión. Las capas del protocolo consisten en la capa física, la capa de transmisión de
datos, y la capa 3. No se deben confundir las funciones de la capa 3 definidas por GSM
con las funciones de la capa 3 del modelo OSI.
Los protocolos de la capa 3 del GSM se utilizan para la comunicación de recursos de red, la
movilidad, el formato del código y los mensajes relativos a llamadas de administración
entre las varias entidades de la red implicadas. Puesto que en el modelo OSI algunas de
estas funciones son proporcionadas realmente por las capas más altas, el término “capa de
mensaje” podría ser más apropiado para referirse a la capa 3 en GSM. La capa de mensaje
(capa 3) del protocolo se compone de tres subcapas llamadas administración de recursos
(RR) implementada sobre el enlace entre el MS y el BSS, el administrador de la movilidad
(MM), y las subcapas de administración de la conexión (CM) que proporcionan la
comunicación entre el MS y el MSC.

La capa 3 también pone en práctica la parte del transporte del mensaje (MTP), nivel 3, y la
parte de control de la señal de conexión del CCITT SS7 sobre el enlace entre el BSS y el
MSC (la interfaz de A) para proporcionar el transporte y las funciones de direccionamiento
para señales de mensajes que pertenecen a las varias llamadas encaminadas a través del
MSC.
Para discutir la funcionalidad proporcionada por la capa 3 en la pila del protocolo GSM, se
debe prestar particular atención en no confundir los detalles de la funcionalidad de esta
capa con la que es proporcionada comúnmente por la capa 3 del modelo de referencia OSI.

90
En GSM, las subcapas CM y MM, por ejemplo, proporcionan realmente algunas de las
funcionalidades que son realizadas por las capas de transporte, de sesión, y presentación de
OSI ver Fig. 2.2.

Radio interface A-interface

BSS
MS MSC

CM CM
BSSAP
MM RR MM
Message SCCP
Layer Message
(Layer 3) RR LAPDm BSSAP Layer
MTP SCCP (Layer 3)
LAPDm TDMA/FDMA
Layer2 MTP
Layer2
TDMA/FDMA
Layer1 Layer1

Figura: 2.2 Arquitectura del protocolo GSM

Capa Física

La capa física en el enlace de radio fue discutido en la sección sobre la estructura del canal
de radio. Los canales del tráfico en la telefonía fija se forman de ranuras de TDM puestas
sobre enlaces de 2.048Mb/s (troncos E1). Los canales de señales se multiplexan de modo
lógico en un agregado de las ranuras de TDM.

La capa de enlace en el interfaz del aire

La capa de transmisión de datos sobre el enlace de radio (que conecta al MS con el BSS) se
basa en un protocolo parecido a LAPD (Link Access Protocol D channel) como el
protocolo, etiquetado como LAPDm, que se ha modificado para la operación dentro de la
limitación fijada por la trayectoria de radio. En particular, LAPDm no utiliza banderas (y
por lo tanto ningún bit de relleno) para la delimitación del marco. En cambio, la
delimitación del marco en LAPDm es hecha por la capa física que define los límites del
marco de transmisión. LAPDm utiliza un campo “Indicador de la longitud” para distinguir
el campo que lleva información de los bits usados para llenar el marco de transmisión.
LAPDm utiliza un campo de dirección para llevar el identificador del punto de acceso del
servicio, (SAPI), (3 bits en este caso) que LAPD también utiliza para identificar al usuario
del servicio proporcionado por el protocolo. Al usar marcos de comando/control, el SAPI
identifica el usuario para quien un marco de comando es dirigido, y el usuario que transmite
un marco de respuesta. Los 2 bits del discriminador del protocolo de enlace (LPD) son
utilizados para especificar una recomendación particular del uso de LAPDm, el C/R es un

91
solo bit que especifica si es un marco de comando o de respuesta según lo utilizado en
LAPD, y una dirección ampliada (EA) de 1-bit se utiliza para extender el campo de
dirección a más de un octeto (el bit EA en el último octeto de la dirección se debe fijar a 1,
si no a 0). El bit 8 es reservado para futuros usos.
LAPDm utiliza un campo de control como se utiliza en LAPD para llevar una serie de
números, y para especificar el tipo de marco. LAPDm utiliza tres tipos de marcos usados
para las funciones de supervisión, la transmisión innumerable de la información y las
funciones de control (modo sin reconocimiento), y la transmisión de información numerada
(modo multiframe reconocido) según lo utilizado en LAPD. LAPDm no utiliza bit
verificador de redundancia cíclica para la detección de error. Los mecanismos de
corrección y detección de error son, en cambio, proporcionados por una combinación del
bloque y de la codificación circunvolucional usados (en conjunción con el bit de
interpolación) en la capa física.

Capa de enlace en la interfaz A

En el enlace terrestre conectando el BSS al MSC (la interfaz A), el nivel 2 de MTP del
protocolo SS7 se utiliza para proporcionar las funciones de la capa 2 de OSI del transporte
confiable para señales de mensajes, tales como recuperación de errores de la transmisión a
través de la detección de error y de la retransmisión.

Protocolos y funciones de la capa de mensaje

Subcapa de administración de recursos de radio (RR)

La subcapa de administración (RR) termina en el BSS y desempeña las funciones de

establecimiento de las conexiones físicas sobre el radio con el fin de transmitir la señal de
información relacionada con la llamada tal como el establecimiento de señales y canales
de tráfico entre un usuario móvil específico y el BSS. Las funciones de administración del
RR se ponen en práctica básicamente en el BSS.

Subcapa de administración de movilidad (MM)

La subcapa MM se termina en el MSC y los mensajes relacionados al MS son

retransmitidos de modo transparente en el BSS usando el proceso de DTAP. La subcapa
MM proporciona las funciones que se pueden clasificar en tres tipos de procedimientos.
Éstos son llamados procedimientos específicos MM, los procedimientos comunes de MM,
y los procedimientos MM relacionados a la conexión.

Procedimientos relacionados a la conexión MM

Estos son los procedimientos usados para establecer, mantener y liberar una conexión MM
entre el MS y la red (MSC) sobre la cual una entidad de la subcapa de la administración de
la conexión (CM) puede intercambiar la información con este par. Más de una conexión
MM puede ser activada al mismo tiempo para servir entidades múltiples CM. Cada entidad
CM dentro del MS tendrá su propia conexión MM, y cada conexión es identificada por el
discriminador del protocolo, y un identificador de la transacción dentro de las señales de

92
mensajes intercambiados. El identificador de transacción es de clase análoga a la referencia
de la llamada usada por ISDN para identificar señales de mensajes de diferentes llamadas
sobre el canal D. Así las llamadas en paralelo que pueden ser soportadas por el mismo MS
son entonces identificadas por un valor diverso para el parámetro del identificador de la
transacción. El establecimiento de una conexión MM requiere que no estén activos
procedimientos específicos MM.

Las conexiones MM proporcionan servicios a las diversas entidades de la subcapa superior

de la administración de la conexión (CM) que consisten en el control de la llamada (CC),
los servicios de mensaje cortos (SMS), y los servicios suplementarios de llamada-
independiente (SS). Una conexión MM es iniciada por un mensaje de la petición del
servicio de CM que identifique la entidad de petición de CM y el tipo de servicio requerido
de la conexión de MM. Los servicios proporcionados por las conexiones MM incluyen
cosas tales como cifrado (para privacidad de la información del usuario), y autentificación
(acceso del usuario a la red y a los servicios solicitados) que sería proporcionada realmente
por las capas de presentación, y las aplicaciones de la estructura de OSI. Cada uno de estos
servicios implicaría el intercambio de múltiples mensajes entre el MS y la red antes de que
se establezca la conexión MM requerida y la entidad de petición dentro de la subcapa del
CM se notifica.

Procedimientos específicos de la administración de la movilidad

Los procedimientos específicos de MM no instalan una conexión MM. Sólo pueden ser
iniciados cuando otros procedimientos específicos MM no están funcionando, y no esté
establecida la conexión MM. Estos procedimientos consisten en la actualización de la
localización y los procedimientos de la fijación de IMSI.

Actualización de la localización

La actualización de la localización es el procedimiento para mantener la red informada de

donde el móvil está vagando. La actualización de la localización es iniciada siempre por la
estación móvil ya sea que detecte que está en una nueva área de localización, supervisando
periódicamente la información de la localización emitida por la red en el canal de la
difusión, y comparándola con la información almacenada previamente en su memoria, o
recibiendo una indicación de la red que éste no es conocido en el VLR sobre el intento de
establecer una conexión MM. Siempre que la red actualiza la localización del móvil, le
envía una “identificación de suscriptor móvil temporal actualizada” (TMSI), en el modo
cifrado, que se almacena en el MS y se utiliza para la identificación móvil subsiguiente en
la paginación y operaciones de iniciación de llamada. El propósito de usar el TMSI en
comparación con IMSI del usuario es mantener la identidad del suscriptor confidencial en
el enlace de radio. El TMSI no tiene estructura específica del GSM, y tiene significado
solamente dentro del área de la localización asignada. El TMSI tiene que ser combinado
con el identificador del área de localización (LAI) para proporcionar una identificación
inequívoca fuera del área donde se asigna.

93
Fijar IMSI

El procedimiento de fijación de IMSI es el complemento del procedimiento IMSI de

desconexión (soltar IMSI), una función de los procedimientos comunes de MM. Ambos
procedimientos son las opciones de la red cuya necesidad del uso se indica a través de una
bandera en la difusión de la información del sistema en el canal BCCH. Los procedimientos
de IMSI desconexión/conexión marcan el MS como desconectado/conectado en el VLR (y
opcionalmente en el HLR) sobre energía baja o alta o modulo de información de suscriptor
(SIM) quitado o insertado (los IMSI de desconexión deshabilitan la función de
actualización de la localización para prevenir el sobrecargo de señales innecesarias en la
red). Cualquier llamada entrante, en ese caso, se rechaza o se remite como puede ser
especificado por el usuario. El IMSI se utiliza para indicar el IMSI como activo en la red.
Se invoca este procedimiento si un IMSI se activa en una MS (energía alta, o inserción de
SIM) en el área de la cobertura de la red, o un MS activado entra en el área de la cobertura
de la red exterior. El procedimiento de la fijación de IMSI entonces se realiza solamente si
el área de la localización almacenada es en ese entonces igual que la que está siendo
difundida en el canal BCCH de la porción de la célula. De otro modo, un procedimiento
de actualización de la localización normal se invoca sin tener en cuenta si la red soporta
procedimientos de IMSI de conexión/desconexión.

Procedimientos comunes MM

Los procedimientos comunes MM pueden ser iniciados en cualquier momento mientras que
un canal de radio dedicado existe entre la red y el MS. No establecen una conexión MM,
pero pueden ser iniciados durante un procedimiento específico MM, o mientras una
conexión MM tiene lugar. Los procedimientos comunes MM consisten en IMSI de
desconexión, reasignación de TMSI, y autentificación/identificación.

Separar IMSI (IMSI “detach”)

El procedimiento IMSI de desconexión es invocado por la estación móvil para indicar el

estado inactivo a la red. No se devuelve ninguna respuesta o reconocimiento al MS por la
red al fijar la bandera activa para el IMSI.
El procedimiento IMSI de desconexión no es iniciado si al mismo tiempo un procedimiento
especifico MM está activo. En este caso, el procedimiento IMSI de desconexión se retrasa,
si es posible hasta que el procedimiento especifico MM termine de lo contrario la solicitud
IMSI de desconexión es omitida.
Si al mismo tiempo de una solicitud de desconexión, una conexión de radio está en
existencia entre el MS y la red, la subcapa MM liberará cualquier conexión en curso MM
antes de que se envíe el mensaje de indicación MM de desconexión.

Reasignación TMSI

El propósito de la reasignación de TMSI es proporcionar confidencialidad de la identidad.

Es decir, para proteger al usuario contra ser identificado y ser situado por un intruso. Este
procedimiento se debe realizar por lo menos en cada cambio del área de cobertura del
MSC. La reasignación en cualquier otro caso se deja al operador de red. Si el TMSI

94
proporcionado por una estación móvil es desconocido en la red, por ejemplo, en el caso de
una falla de la base de datos, el MS tiene que proporcionar su IMSI a petición de la red.
En este caso el procedimiento de identificación tiene que ser realizado antes de que el
procedimiento de TMSI pueda ser iniciado.

Autentificación

El propósito del procedimiento de autentificación es dejar la red verificar la identidad

proporcionada por el usuario cuando la solicite, y proporcionar una nueva clave cifrada a la
estación móvil. Los casos cuando los procedimientos de autentificación deben ser utilizados
se definen en la recomendación 02.09 de GSM. El procedimiento de autentificación es
iniciado y controlado siempre por la red.

Identificación

Este procedimiento es utilizado por la red para solicitar a una estación móvil proporcionar
los parámetros de identificación específicos a la red, tal como los identificadores móviles
internacionales del suscriptor o del equipo del usuario (IMSI o IMEI). La estación móvil
debe estar lista para responder a un mensaje de solicitud de identidad en cualquier
momento mientras que la conexión RR existe entre el teléfono celular y la red.

Subcapa de la administración de la conexión (CM)

La subcapa CM termina en el MSC y contiene las entidades que consisten en el CC

incluyendo servicios suplementarios relativos a llamadas, SMS, y la ayuda de servicios
suplementarios independientes de la llamada (SS). Una vez que se haya establecido una
conexión MM, el CM puede utilizarla para la transmisión informativa.
La entidad CC utiliza el protocolo CCITT Q.931, con modificaciones de menor
importancia, para la comunicación de los mensajes relacionados con el control de la
llamada entre el MS y el MSC.

El SMS es un servicio definido por GSM que proporciona comunicación rápida del modo
de paquete (“sin conexión”) de mensajes hasta 140 bytes entre el MS y un tercer
participante que es el centro de servicio. Estos mensajes se pueden enviar o recibir por la
estación móvil mientras que una llamada de voz ó datos está en el estado activo o inactivo.
Es aceptable, sin embargo, si se aborta el servicio mientras que una llamada está en un
estado transitorio tal como desocupado u ocupado-a-ocioso. El centro de servicio es
responsable de la colección, del almacenaje, y de la entrega de mensajes cortos, y está fuera
del alcance de GSM.

Parte de la aplicación BSS (BSSAP)

El BSS, además de proporcionar la conmutación de canal y las funciones aéreas, realiza la

administración de los recursos de radio, y las funciones que trabajan entre los protocolos de
transmisión de datos usados en la radio y el lado BSS-MSC para transportar señales
relacionadas con los mensajes. Estas funciones son proporcionadas por el proceso de

95
administración de aplicación de la BSS (BSSMAP), y el proceso de Aplicación de
Transferencia Directa (DTAP).

El BSSMAP se utiliza para poner todos los procedimientos en ejecución entre el MSC y el
BSS que requieran la interpretación y el procesamiento de la información relacionada para
distinguir llamadas, y la administración de los recursos. Básicamente, el BSSMAP es el
proceso dentro del BSS que controla los recursos de radio en respuesta a instrucciones del
MSC (en ese sentido, el BSSMAP representa la subcapa RR para el MSC). Por ejemplo,
el BSSMAP se utiliza en la asignación y la conmutación de los canales de radio en el
establecimiento de la llamada y los procesos de desocupado.

Los procesos DTAP se utilizan para la transferencia transparente de las señales de

mensajes de MM/CM entre el MS y el MSC. Es decir, la función de DTAP es proporcionar
la función que trabaja con el nivel del transporte del protocolo para transferir señales de
mensajes desde y al MS para y desde el MSC sin ningún análisis del contenido del mensaje.

Protocolos de transporte de señales

Los protocolos CCITT SS7 MTP y SCCP se utilizan para poner en práctica la transmisión
de datos y las funciones de transporte de la capa 3 para llevar el control de la llamada y la
administración de la movilidad de señales de mensajes sobre el enlace BSS-MSC. La señal
de información de las subcapas MM y CM de la estación móvil se encaminan sobre los
canales de señales (tales como el DCCH, el SACCH, el FACCH) al BSS de donde
transparentemente se retransmiten a través del proceso DTAP a un SCCP, del tipo CCITT
SS7 canal lógico, asignado para esa llamada, sobre el enlace BSS-MSC para la transmisión
a la par de la entidad CC en el MSC para el procesamiento. De manera semejante, cualquier
información de señal de llamada iniciada por el MSC en la conexión de SCCP se
retransmite con el proceso de DTAP en el BSS al canal de señal asignado, usando el
protocolo de transmisión de datos LAPDm, para la entrega a la estación móvil.

El trabajo entre el protocolo de la capa 2 sobre el lado del radio y el SS7 en el enlace BSS-
MSC es proporcionado por una unidad de distribución de datos dentro del campo de
información del SCCP. Estos parámetros se conocen como la discriminación, y los
parámetros del identificador de la conexión de transmisión de datos (DLCI). El parámetro
de la discriminación (dedicado actualmente un octeto) utiliza un solo bit para direccionar
un mensaje ya sea al proceso DTAP o al proceso BSSMAP. El parámetro de DLCI (un
octeto de tamaño) se compone de dos subparámetros que identifiquen el tipo de canal de
radio (tal como el DCCH, el SACCH, el FACCH), y el valor de la “interfaz del punto de
acceso de servicio” (SAPI) (en el protocolo LAPDm) usado para el mensaje en el enlace de
radio. El SCCP proporciona información para el multiplexado lógico de señales de diversas
llamadas sobre el mismo canal físico en el enlace de BSS-MSC. Por cada llamada
soportada por un BSS, una conexión lógica de SCCP se establece en el enlace de BSS-
MSC. Cualquier información perteneciente a una llamada específica fluye a través de esta
conexión asociada de SCCP y es así cómo el intercambio de señales de información
perteneciente a diversas llamadas son identificadas en el BSS o el MSC.

96
El modo de servicio sin conexión del SCCP también se apoya para la transferencia de
mensajes relacionados OA&M así como los mensajes de BSSMAP que no pertenecen a
ninguna llamada específica (nota: los mensajes de BSSMAP que pertenecen a llamadas
específicas, tales como mensajes hand-off, se transmiten usando la conexión de SCCP
establecida para la llamada). La función de encaminamiento de SCCP utiliza el número del
subsistema (SSN) en el octeto de la información de servicio (SIO) dentro del mensaje del
nivel 3 de MTP para distinguir mensajes diseccionados a la función de OA&M de los
diseccionados ya sea al DTAP o a la parte de aplicación BSSMAP.

El alto nivel de capacidad de traducción de dirección del SCCP, conocida como traducción
del título global, se puede entonces utilizar para proporcionar capacidades de dirección
adicional tales como uso de la enumeración E.164 para direccionar diversas entidades de
OA&M. La característica de la traducción del título global del SCCP también proporciona
el MSC la capacidad para direccionar señales de mensajes a MSC’s remotos que puedan ser
localizados en un diverso PLMN. El íntertrabajo de funciones entre el CM, MM y las
entidades de BSSMAP y las entidades correspondientes del SS7 (es decir, el ISDN-UP),
MAP, SCCP, y la parte de aplicación de las capacidades de las transacciones (TCAP) son
proporcionadas por el MSC.

Paginación

Los mensajes de paginación para los móviles se envían vía el BSSMAP al BSS como
mensaje sin conexión a través del SCCP/MTP. El mensaje de paginación puede incluir el
IMSI del móvil a fin de permitir la derivación del número de la población de la paginación.
Un solo mensaje de paginación transmitido al BSS puede contener una lista de las células
en las cuales la página debe ser difundida. Cuanto más grande es el área de paginación
definida, más baja es la frecuencia de las actualizaciones de la localización y por lo tanto el
tráfico asociado es elevado en la red.

Por otra parte, las áreas grandes de paginación resultan al incrementar el uso de la potencia
de transmisión, además de los recursos de radio (canales). Por lo tanto, el tamaño óptimo
para el área de paginación (área de localización) es determinado por un equilibrio
apropiado entre los costos de paginación y los costos de actualización de la localización.

Los mensajes de paginación recibidos del MSC se almacenan en el BS, y los mensajes
correspondientes de paginación se transmiten sobre el interfaz de radio en el tiempo
apropiado. Cada mensaje de paginación se relaciona con solamente una estación móvil y el
BSS tiene que empaquetar el mensaje pertinente de paginación. Una vez que un mensaje de
paginación es emitido sobre el canal o canales de radio, si un mensaje de respuesta se
recibe del móvil, la conexión de señal relevante se establece hacia el MSC y el mensaje de
respuesta de la página se pasa al MSC [35].

97
Apéndice 2 Manual de usuario JMR (Java Mobile Robots).
APLICACIÓN CLIENTE

Veremos ahora cómo utilizar la aplicación cliente. Haremos un recorrido por los
componentes que contiene.

PANTALLA PRINCIPAL

El programa cliente tiene una apariencia como la siguiente:

Donde podemos distinguir 4 grandes apartados:

ZONA DE PARÁMETROS DE CONEXIÓN

La zona superior (Connection) tiene una barra con las opciones de conexión:
• Dirección del servidor al que conectar (Server Address)
• Puerto por el que conectar (Server Port)
• Tipo de servidor al que conectar (Server Type), a elegir de la lista:
Simulador 3D de JMR
Simulador Pioneer de Saphira
Robot real a través de puerto serie 1 (COM1)
Robot real a través de puerto serie 2 (COM2).

98
ZONA DE CONTROL DE LA LISTA DE ROBOTS
La segunda zona (Robot List) contiene un panel para controlar los robots activos en cada
momento. Se tendrá una lista con los robots que hay en el cliente en cada momento, y
botones para añadir o quitar robots de la lista. También se tiene un apartado para elegir el
fichero de parámetros que queremos asignar al robot que vayamos a añadir (por defecto se
asignan los parámetros del fichero pion1m.p).

ZONA DE DATOS DEL ROBOT

Bajos las dos zonas anteriores se tiene la zona de datos del robot (Robot Data). En esta zona
podremos ver:
• Los parámetros del robot (Parameters): datos estáticos que informan sobre los
factores de conversión internos del robot, tamaño, número de sónares, etc.
• Los sonares del robot (Sonars): aquí se informa sobre las lecturas que tiene cada
sonar del robot, y se muestra gráficamente el entorno del robot, las lecturas que
marca y las velocidades lineal y rotacional que tiene en cada momento.
• El estado del robot (State), donde vemos datos dinámicos acerca del robot: posición
actual, velocidades actuales (lineal y rotacional), estado de la batería, etc.

ZONA DE ELEMENTOS AÑADIDOS AL ROBOT

En la zona inferior (Robot Add-ons) se tiene información sobre elementos que no forman
parte inicialmente del robot, y que se tienen como añadidos. Esta zona se subdivide a la vez
en dos:
• Los procesos que tenga añadidos el robot (Processes), que a su vez pueden ser:
o Comandos simples: en el cuadro desplegable de esta zona se tiene una serie de
comandos simples que podemos enviar al robot:
Establecer la velocidad lineal (en mm/s)
Establecer la velocidad rotacional (en grados/s)
Indicar al robot que avance una determinada distancia (en mm)
Indicar al robot que gire un ángulo relativo (en grados)
Indicar al robot que gire un ángulo absoluto (en grados)
Sólo hay que escribir en el cuadro de texto el parámetro que necesita
el comando seleccionado (la velocidad, la distancia o el ángulo,
según el comando), y pulsar el botón de enviar (Send).
o Procesos complejos: mediante el botón de añadir procesos (Add Process) podremos
cargar procesos complejos en el robot. Luego, con el botón de ver procesos (View
Processes) podremos ver en todo momento qué procesos tiene cargados el robot.
• Los dispositivos que tenga el robot (Devices). En la parte izquierda de este subpanel se
tiene una lista con los dispositivos añadidos al robot que puedan visualizarse, y a la derecha
se tiene otro subpanel donde en cada momento se verá el dispositivo que se tenga
seleccionado de la lista de la izquierda.

ESPECIFICACIÓN DE LAS OPCIONES DE CONEXIÓN

Para especificar las distintas opciones de la conexión con el servidor, se tiene el panel de
arriba de la aplicación cliente (Connection), donde:

99
 • Server Address: será la dirección IP donde se encuentra la máquina servidor a
la que conectar.
• Server Port: indica el puerto por el que conectar.
• Server Type: indica el tipo de servidor al que nos queremos conectar. Podrá
ser uno de entre:
o Java simulator: el simulador 3D de JMR
o Saphira Pioneer: conexión al simulador Pioneer de Saphira,
utilizando el servidor de JMR para Saphira.
o Saphira COM1: conexión a un robot real a través del puerto
serie 1, utilizando el servidor de JMR para Saphira.
o Saphira com2: conexión a un robot real a través del puerto
serie 2, utilizando el servidor de JMR para Saphira.

Tras especificar estos parámetros, cada vez que se añada un nuevo robot, lo hará
conectándose con las opciones indicadas en estos controles.

CONEXION LOCAL

Si no indicamos dirección IP o puerto, la conexión no se hará a una máquina remota (o al

localhost) mediante RMI, sino que se creará una conexión directa y local con el servidor
seleccionado. Esta opción, nueva en JMR 2, permite conectar de forma más rápida, y sin
necesidad de utilizar RMI, con servidores que se encuentren en la misma máquina donde
ejecutemos el cliente.

Si elegimos la conexión local, al añadir un robot se creará el servidor correspondiente de

forma automática (si no lo hemos creado ya antes al añadir un robot previamente), y se
establecerá la comunicación con el mismo.

CONECTAR / DESCONECTAR ROBOTS

Para añadir o quitar robots de la escena, se tiene el segundo panel (Robots List), donde:
• La lista Robots contiene los robots que hay conectados en este momento. En los
distintos cuadros de control del robot (parámetros del robot, estado del robot,
lecturas de sónares, etc.) aparecerán los datos relativos al robot actualmente
seleccionado de la lista.
• El botón de añadir robot (Add) sirve para añadir un nuevo robot. Al pulsarlo,
aparecerá un cuadro de diálogo para que indiquemos el nombre del robot:

Si el nombre que se introduzca ya lo tiene otro robot, se auto numerará con el

primer número libre. Por ejemplo, si al robot lo llamamos “Robot” y ya existe un
robot con el nombre “Robot”, irá asignando nombres “Robot 1”, “Robot 2” ... y así
sucesivamente hasta encontrar alguno libre.

100
 Al conectar el robot, aparecerán sus datos en los distintos cuadros de controles que
hay: parámetros, estado, lecturas de sónares etc.
• El botón de quitar (Remove) elimina al robot actualmente seleccionado,
desconectándolo del servidor.
• El cuadro para el fichero de parámetros (Params File) indica el nombre del fichero
de parámetros que queremos que tenga el robot que vamos a añadir. Podremos
escribirlo directamente en el cuadro de texto, o pulsar el botón con puntos para
buscarlo por el disco. Si vamos a conectar con Saphira, debemos asegurarnos de que
el fichero de parámetros esté también en el directorio params de Saphira, para que
pueda ser cargado.

CONTROL DE LOS DATOS DEL ROBOT

En la zona de datos del robot (Robot Data) existen una serie de controles para visualizar y
llevar un control de los datos del robot actualmente seleccionado en la lista de robots.

PARÁMETROS DEL ROBOT

Podremos ver los parámetros que definen al robot con el cuadro de parámetros
(Parameters). En este cuadro se definen:
• Angle Conversion Factor es el factor de conversión de unidades de ángulos, interno
del robot.
• Linear Velocity Conversion Factor es el factor de conversión de unidades de
velocidad lineal, interno del robot.
• Rotational Velocity Conversion Factor es el factor de conversión de unidades de
velocidad rotacional, interno del robot.
• Distance Conversion Factor es el factor de conversión de unidades de distancias,
interno del robot.
• Range Conversion Factor es el factor de conversión de unidades de rangos (lecturas
de sónares), interno del robot.
• Holonomic indica si el robot es holonómico (puede girar sobre sí mismo) o no.
• Robot Radius es el radio del robot en mm.
• Robot Diagonal es la diagonal del robot, en mm.
• Robot Width es la anchura del robot, en mm.
• Robot Length es la longitud del robot, en mm.
• Robot Height es la altura del robot, en mm.
• Maximal Linear Velocity es la máxima velocidad lineal que puede alcanzar, en
• mm/s.
• Maximal Rotational Velocity es la máxima velocidad rotacional que puede alcanzar,
en grados/s.
• Maximal Linear Acceleration es la máxima aceleración lineal que puede adquirir, en
mm/s².
• Class indica la clase de robots a la que pertenece.
• Subclass indica la subclase dentro de la clase de robots.

101
 • Name es el nombre del robot (distinto del que se asigna en la conexión, es un
parámetro interno de especificación del robot).
• Number Of Sonars es el número de sónares que tiene.
• Front Buffer indica el número de lecturas que se acumulan en los sónares frontales.
• Side Buffer indica el número de lecturas que se acumulan en los sónares laterales.

Estos son parámetros estáticos, que definen algunas características del robot.

LECTURAS DE LOS SÓNARES

Para llevar un control de las lecturas que toma el robot, se tienen los paneles centrales
(Sonars), donde se muestran los valores numéricos de dichas lecturas (en mm) y una
representación gráfica de las mismas, junto con las velocidades actuales del robot. Se marca
la velocidad lineal con una línea vertical, y la rotacional con una horizontal, y las lecturas
de sónares en azul.

ESTADO DEL ROBOT

Podremos ver el estado del robot con el cuadro State, donde:

• Linear Velocity es la velocidad lineal que lleva el robot actualmente, en mm / s.
Positiva si va hacia delante, negativa si va hacia atrás.
• Rotational Velocity es la velocidad de giro (rotacional) que lleva en grados / s.
Positiva si es giro a la izquierda, negativa si es a la derecha.
• X es la coordenada X del robot, relativa a su posición inicial sobre el mundo, en
mm.
• Y es la coordenada Y del robot, relativa a su posición inicial sobre el mundo, en
mm.
• Th es la orientación del robot en grados.
• State es el estado en que se encuentra el robot, que podrá ser uno de los siguientes:
o DISCONNECTED: el robot está desconectado del servidor.
o NO MOTORS: el robot está conectado, pero con los motores apagados.
o STOPPED: el robot está conectado, con los motores encendidos, pero
detenido, sin moverse.
o MOVING: el robot se mueve
o COLLISION: el robot ha colisionado.
• Battery es el estado en que se encuentra la batería (voltaje)
Conviene resaltar que la posición X e Y sólo se ve modificada mediante los
movimientos propios del robot. Es decir, si el usuario cambia manualmente la posición
del robot, las coordenadas X e Y no se verán modificadas con la nueva posición.
Representan movimientos automáticos del robot.

CONTROL DE LOS ELEMENTOS AÑADIDOS AL ROBOT

En la zona de elementos añadidos (Robot Add-ons) existen controles para gestionar los
procesos (Processes) que tiene cada robot, y los dispositivos (Devices).

102
PROCESOS DEL ROBOT

Al hablar de procesos en el robot, distinguimos entre comandos simples y procesos

complejos.

ENVIO DE COMANDOS SIMPLES

Para enviar comandos simples al robot, se tiene el cuadro desplegable en Processes, donde
podremos elegir los distintos comandos simples que podemos enviar:

• Linear Velocity: velocidad lineal de movimiento. Necesita un parámetro, que es la

velocidad, en mm/s.
• Rotational Velocity: velocidad de giro. Necesita un parámetro, que es la velocidad,
en grados/s.
• Move: indica que el robot avance una determinada distancia. Necesita un parámetro,
que es la distancia a avanzar, en mm.
• Turn to: indica que el robot rote hasta un determinado ángulo absoluto. Necesita un
parámetro, que es el ángulo en grados.
• Turn: indica que el robot rote un determinado ángulo relativo. Necesita un
parámetro, que es el ángulo en grados.

El cuadro de texto bajo el desplegable se emplea para pasar los parámetros que necesite
cada comando simple, y luego pulsando el botón de enviar (Send) se enviará el comando
seleccionado, con el parámetro introducido.

CARGA DE PROCESOS COMPLEJOS

Para cargar procesos en el robot se tiene el botón de cargar proceso (Add Process). Al
pulsarlo, aparecerá un cuadro de diálogo para que elijamos el proceso a cargar (un fichero
.class ya compilado con el proceso a cargar).

Al elegirlo, se mostrará un cuadro de diálogo para especificar los parámetros del proceso:

103
Al lado de cada parámetro se indica su tipo. Al final hay tres parámetros que tendrá todo
proceso:
• Timeout: tiempo (en ms) que damos al proceso para que termine. Si se indica un
valor negativo, no habrá límite de tiempo.
• Suspend: indica si el proceso se carga con un estado suspendido inicialmente, o se
ejecuta nada más cargarse.
• Process name: nombre que queremos darle al proceso (si queremos darle algún
nombre distinto al de la clase).
Tras introducir los parámetros, el proceso se añadirá al robot.

VER LOS PROCESOS DEL ROBOT

Con el botón de ver procesos (View Processes) se mostrará un panel con los procesos que
hay ejecutando actualmente sobre el robot seleccionado:

104
En el panel se muestran todos los procesos que hay actualmente cargados en el robot.
Al lado de cada proceso hay un desplegable con los distintos estados en que puede estar el
proceso. Podremos cambiar el estado de los procesos que así lo permitan eligiendo el
estado correspondiente del desplegable. Podremos elegir entre:
• LOADER: el proceso se ha cargado en el robot.
• STOPPED: el proceso ha finalizado anormalmente.
• RUNNING: el proceso está en ejecución.
• SUSPENDED: el proceso ha sido suspendido mientras se ejecutaba.
• DONE: el proceso ha finalizado satisfactoriamente.
• QUIT: no es un estado del proceso. Se empleará cuando el usuario quiera quitar el
proceso del robot.
Además, al lado de este cuadro se muestran dos líneas, de mayor o menor longitud,
indicando la influencia de cada proceso en el movimiento lineal y en el giro. Líneas cortas
indican poca influencia (cercana a 0) y líneas largas mucha influencia (cercana a 1).

DISPOSITIVOS DEL ROBOT

Los dispositivos que tenga añadidos el robot y que tengan un visor asociado, podrán
controlarse mediante el panel Devices. En la parte izquierda se tiene una lista con los
dispositivos disponibles, inicialmente puestos a OFF (es decir, ninguno se ve).
Pulsando sobre cualquiera de ellos, su marca se pone en ON, y en la parte derecha se ve el
estado del dispositivo. Volviendo a pulsar sobre él, vuelve a ponerse en OFF y deja de
verse. Al pinchar a ON un dispositivo, el resto pasa a OFF (es decir, sólo podremos ver un
dispositivo simultáneamente).

105
ACTUALIZACIÓN DE DATOS

Los datos que se muestran en la zona de Robot Data y Robot Add-ons para el robot que
tengamos actualmente seleccionado en la lista de Robot List se van actualizando
automáticamente cada cierto tiempo. En la aplicación de configuración tenemos opciones
para poder establecer la frecuencia con la que actualizar estos datos (en ms):

• Frecuencia para actualizar los paneles de Robot Data.

• Frecuencia para actualizar los dispositivos de Devices.
• Frecuencia para actualizar los procesos cuando hemos pulsado View Processes.

Deberemos ejecutar la aplicación de configuración antes de lanzar el cliente, y modificar

estas frecuencias según nuestras necesidades.

CONFIGURACIÓN

Existen una serie de parámetros configurables, que podemos establecer desde la

herramienta de configuración de JMR. Deberemos cargar la aplicación de configuración y
seleccionar la pestaña Client Application. Al elegirla, se muestra un cuadro como el
siguiente:

donde:

• Data update freq. (ms) es el período de tiempo (en ms) entre dos actualizaciones
consecutivas de los paneles de datos del robot actualmente seleccionado.

• Device update freq. (ms) es el período de tiempo (en ms) entre dos actualizaciones
consecutivas de los dispositivos del robot actualmente seleccionado.

• Process update freq. (ms) es el período de tiempo (en ms) entre dos actualizaciones
consecutivas de los procesos del robot actualmente seleccionado.

106
Valores pequeños de estas frecuencias proporcionarán actualizaciones constantes, aunque
pueden ralentizar el funcionamiento de JMR.

107
SIMULADOR 3D
Veremos ahora cómo utilizar el simulador 3D Java. Haremos un recorrido por los
componentes que contiene, y veremos cómo utilizar cada uno de ellos. Asumimos que ya se
sabe ejecutar la aplicación, pero en cualquier caso, para ver cómo se ejecuta, consultar los
apartados previos.

PANTALLA PRINCIPAL

Tras ejecutar el programa simulador, aparecerá una ventana como la siguiente:

donde podemos distinguir:

• Un canvas (área en negro) donde se podrá ver el mundo y los robots que se tengan
cargados.
• Una zona de menús, con los siguientes menús:
o File: con las opciones para carga de datos y salir del programa:
Load parameters: cargará los parámetros de robots
Load world: carga un mundo por donde mover a los robots.
Exit: cierra el servidor
o Cameras: habilita las distintas cámaras que se tengan definidas:
User: cámara de vista global del mundo.
Robot: las distintas cámaras de cada uno de los robots que haya
conectados.
World: las distintas cámaras que se definan en el mundo.
Show secondary viewer: abre / cierra otro visor además del que se tiene,
donde se tendrá la cámara de usuario.
o Vision: para realizar distintas tareas de visión.
Load processor for: indica el procesador que se cargará sobre el robot que
se seleccione.
About: muestra el logo e información sobre el programa.

108
CARGAR DATOS

CARGAR PARÁMETROS

Para cargar parámetros de un robot, elegimos la opción Load parameters del menú
File. Aparecerá un cuadro de diálogo para elegir el fichero de parámetros que se quiere
cargar, y una vez elegido, se establecerá dicho fichero de parámetros. De este modo,
cuando se conecte algún robot sin especificar qué fichero de parámetros quiere, se le
asignará el que se haya establecido con esta opción.

CARGAR MUNDOS

Para cargar el mundo donde se moverán los robots, elegimos la opción Load World del
menú File. Con esto se abrirá un cuadro de diálogo para que elijamos el mundo a cargar.
Una vez elegido, se visualizará en el canvas del servidor. Por ejemplo, el mundo simple.wld
del directorio world se ve así:

Sobre este mundo se definen una serie de cámaras, que se explican en el apartado de
cámaras. Una de las cámaras, la de usuario, permitirá movernos por el mundo y ver
distintos puntos de vista, como se verá a en el apartado de cámaras.

CÁMARAS

DEFINICIÓN DE CÁMARAS
El sistema tiene una cámara predefinida, que es la cámara de usuario, que se puede
manipular para colocarla en distintos puntos de vista del mundo. Además, tiene las cámaras
propias de cada robot (los “ojos” del robot).

Para definir una cámara adicional (que se englobarían dentro del grupo World en el menú
Camera), se deben definir en el fichero de configuración del mundo (ficheros

109
wld), con la sintaxis:

;camera <nombre> <X> <Y> <Z> <rotX> <rotY> <rotZ>

donde:

• nombre es el nombre que le damos a la cámara

• X es la coordenada X donde colocamos la cámara
• Y es la coordenada Y donde colocamos la cámara
• Z es la coordenada Z donde colocamos la cámara
• rotX es la rotación con respecto al eje X que le damos a la cámara
• rotY es la rotación con respecto al eje Y que le damos a la cámara
• rotZ es la rotación con respecto al eje Z que le damos a la cámara

Para más información sobre la configuración de mundos, consultar la documentación del

paquete loaders.

ESTABLECIMIENTO DE LA CÁMARA ACTUAL

Para determinar qué cámara utilizar en cada momento, se tiene el menú Cameras, donde
podremos elegir entre:

• User: cámara de vista global del mundo.

• Robot: las distintas cámaras de cada uno de los robots que haya conectados.
• World: las distintas cámaras que se definan en el mundo.

Podemos añadir un segundo visor en el simulador habilitando la opción Show

secondary viewer del menú Cameras. Con esto, aparecerá una zona a la derecha donde se
tendrá la cámara de usuario. Así, podremos tener por un lado una cámara cualquiera (lo que
ve un robot, otra vista del mundo), y por otro lado la cámara de usuario para llevar un
control global.

MOVIMIENTOS

Podemos mover la cámara de usuario y colocarla en distintas posiciones del mundo, así
como mover a los robots y dejarlos en la posición y orientación que queramos.

MOVIMIENTO DE LA CÁMARA DE USUARIO

Podremos mover esta cámara con las flechas y las teclas Control y Alt, de la siguiente
forma:

• Para mover el mundo sobre el plano de proyección, a izquierda, derecha, arriba y

abajo, usaremos las flechas sin más.

110
 • Para movernos hacia adelante o hacia atrás, usaremos las flechas de arriba y abajo,
con la tecla Control pulsada.
• Para rotar el mundo en un sentido u otro, sobre el plano de proyección, usaremos las
teclas izquierda y derecha con la tecla Control pulsada.
• Para rotar y mirar hacia arriba abajo, izquierda o derecha de donde estamos,
usaremos la flecha correspondiente, con la tecla Alt pulsada.

MOVIMIENTO DE ROBOTS

Podemos mover y rotar los robots que estén en cada momento sobre el mundo, bien con la
cámara de usuario o con cualquier otra cámara, mediante el ratón:
• Para mover un robot (cambiar su posición (X, Y)), se pulsa el botón derecho del
ratón sobre él y luego se arrastra por el mundo. El robot se moverá también cuando
arrastremos el botón derecho, y luego sólo hay que soltar el botón cuando el robot
esté colocado donde queríamos. El robot se moverá con respecto al sistema de
coordenadas original (si se rota el mundo, el robot seguirá moviéndose según el
sistema original).
• Para rotar un robot, se pulsa el botón izquierdo sobre él, y se arrastra
horizontalmente hacia un lado u otro, dependiendo del giro que queramos dar al
robot.

VISOR SECUNDARIO

La opción Show secondary viewer del menú Cameras permite ampliar el simulador para
mostrar una nueva cámara, que es la de usuario.

De esta forma, en la parte izquierda se tendrá la misma cámara que se tenía seleccionada, y
en la derecha la cámara de usuario, que permitirá una visión más global.

111
VISIÓN

Podemos procesar las imágenes que capturan los distintos robots cargando un procesador
de imágenes en éstos. Para ello, la opción Load processor for del menú
Vision permite elegir el robot sobre el que cargar el procesador. Dicho procesador debe ser
una clase que implemente jmr.robots.vision.ImageProcessor, y defina el método para
procesar las imágenes.

Al elegir el robot, aparecerá un cuadro de diálogo para elegir el fichero .class que contiene
el procesador que queremos cargar. Mostrará todas las clases contenidas en el directorio
${jmr.home}/vision, por lo que deberemos crear nuestro procesadores de imagen en este
directorio.

Una vez elegido, el procesador se dedicará a procesar las imágenes que capture la cámara
del robot, y guardar junto a ellas el resultado de procesar la imagen, para enviarlo a los
clientes que lo soliciten.

Desde el cliente, podremos ver la imagen procesada activando el flag de Image

Result en el panel del dispositivo tipo cámara en el cliente.

CONFIGURACIÓN
Existen una serie de parámetros configurables, que podemos establecer desde la
herramienta de configuración de JMR. Deberemos cargar la aplicación de configuración y
seleccionar la pestaña 3D simulator. Al elegirla, se muestra un cuadro como el siguiente:

112
donde:

• Threshold for the sonar incidente angle (Angulo umbral del sónar) es el ángulo
mínimo en radianes que debe haber entre la dirección del sónar y una superficie
para que la lectura producida por la superficie sea detectada por el sónar (si es
menor, hay muy poco ángulo, y la señal rebota y se pierde):
• Variance for sonar reading error (Error en las lecturas del sónar) es el error que se
comete en las lecturas de los sónares (la varianza). Esto se aplica para dar más
realismo a los datos tomados por el robot, variando la lectura tomada con una
normal de media 0 y varianza la especificada.
• Error in position estimation (Error en el avance a distancia) es el error que se
comete cuando el robot avanza una determinada distancia (la varianza). Al igual que
en el caso anterior, sirve para dar más realismo a las acciones del robot, variando la
distancia con una normal de media 0 y varianza la especificada.
• Error in orientation estimation (Error en el cambio de orientación) es el error que se
comete cuando el robot cambia de orientación (gira). Al igual que en el caso
anterior, sirve para dar más realismo a las acciones del robot, variando la
orientación con una normal de media 0 y varianza la especificada.
• Variance for velocity errors (Error en la velocidad trasnacional) es el error que se
comete al determinar la velocidad lineal del robot. Al igual que en el caso anterior,
sirve para dar más realismo a las acciones del robot, variando la velocidad con una
normal de media 0 y varianza la especificada.

113
 • Variance for rotation errors (Error en la velocidad rotacional) es el error que se
comete al determinar la velocidad rotacional del robot. Al igual que en el caso
anterior, sirve para dar más realismo a las acciones del robot, variando la velocidad
con una normal de media 0 y varianza la especificada.
• Installed devices configuration file indica la localización del fichero de definición
de los dispositivos que estamos utilizando en el Simulador 3D.
• IP address es la dirección IP a la que se enlazará el servidor
• Port es el puerto donde el servidor permanecerá a la escucha de peticiones de
conexión mediante RMI.

El fichero de configuración del simulador se encuentra en el fichero de configuración de

JMR en ${jmr.home}/conf/jmr.conf. De ahí se leerán y ahí se escribirán los valores de los
parámetros de la configuración. Los parámetros de configuración del
Simulador 3D tienen todos el prefijo sim.*.

SERVIDOR SAPHIRA
Veremos ahora cómo utilizar el servidor Saphira. Asumimos que ya se sabe ejecutar la
aplicación, pero en cualquier caso, para ver cómo se ejecuta, consultar los apartados
previos.

FUNCIONAMIENTO

Una vez ejecutado, el programa no tiene ninguna parte visual ni más opciones para el
usuario. Simplemente basta con tener preparado el simulador Pioneer o el robot real al que
se quiere conectar, y realizar la conexión desde alguna aplicación cliente.

Así pues, no se podrán realizar tareas como definir cámaras en el mundo (puesto que sólo
se cuenta con la cámara del único robot que podemos conectar). Sí se podrá procesar la
imagen que captura la cámara del robot, añadiendo un procesador. No se tiene el menú para
hacerlo, como en el caso del simulador 3D, pero también se pueden añadir procesadores
desde el código de los procesos, tomando el dispositivo de tipo cámara y añadiendo el
procesador.

CONFIGURACIÓN

Existen una serie de parámetros configurables, que podemos establecer desde la

herramienta de configuración de JMR. Deberemos cargar la aplicación de configuración y
seleccionar la pestaña Saphira server. Al elegirla, se muestra un cuadro como el siguiente:

114
donde:

• IP address es la dirección IP de la máquina desde la que se lanzará el servidor.

• Port es el puerto por que el que se quedará escuchando el servidor.
• Params directory es el directorio donde se encuentran los ficheros de parámetros
• Default params file es el fichero de parámetros que se establecerá por defecto en
caso de que no se especifique ninguno
• Default devices file es el fichero por defecto donde se guardarán los dispositivos
que tendrán los robots que se conecten a un servidor Saphira.

115
 Bibliografía.

[1] http://www.Yucatan.com.mx/especiales/celular/historia.asp

[2] http://www.Yucatán.com.mx/especiales/celular/3g.asp

[3] http://www.geocities.com/Sunsetstrip/Amphitheatre/3064/Celular.html.

[4] http://www.Yucatan.com.mx/especiales/celular/comofunciona.asp

[5] http://www.wikipedia.org/wiki/DTMF

[6] http://www.telefonos-moviles.com/articles/item.asp?ID=25

[7] http://www.todomovil.net/gsm/historia.asp

[8] http://www.telefonos-moviles.com/articles/item.asp?ID=30

[9] http://es.gsmbox.com/GSM/SMS/info-descrizione.

[10] http://congreso.hispalinux.es/congreso2001/actividades/ponencias/seco/
html/introduccion.html.

[11] http://www.nokia.es/telefonos/tecnologias/mms_faq.jsp

[12] http://webs.sinectis.com.ar/mcagliani/hrobot.htm.

[13] http://usuarios.bitmailer.com/aperobot/robothistoriatecno.htm

[14] http://activrobots.com

[15] http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-
html/c12.html

[16] http://hypertextbook.com/physics/waves/beats/index.shtml.

[17] http://users.telenet.be/educypedia/electronics/telephone.htm

[18] http://www.rvg.dccia.ua.es/jmr/index.html

[19] http://www.dage.net/dtmf_tut.html.

[20] http://usuarios.bitmailer.com/aperobot/robots.htm

116
[21] http://es.gsmbox.com/wap/come.gsmbox

[22] http://www.3gamericas.org/Spanish/Technology_Center/GSM_sp.cfm

[23] http://www.3gamericas.org/Spanish/Technology_Center/gsmfacts_sp.cfm.

[24] http://www.3gamericas.org/spanish/technology_center/qa/gsmqa_sp.cfm

[25] http://www.todomovil.net/gsm/historia.asp

[26] http://www.hackhispano.com/oldhh/paginas/gsm/gsm_02.htm

[27] http://www.hackhispano.com/oldhh/paginas/gsm.htm.

[28] http://www.progres-spain.com/espanyol/avisadorgsm.html.

[29] http://www.cept.org

[30] http://www.metc.pku.edu.cn/melab/publications/mepaper04.pdf

[31] http://www.cat.csiro.au/cmst/automation

[32] http://ccc.inaoep.mx/~rodrigo/robotica/Robotica.htm

[33] http://www.todomovil.net/gsm/art1.asp

[34] http://www.melodiasmoviles.com/documentacion/intro-gsm.php

117
[35] Overview of the GSM System and protocol Architecture
Moe Rahnema
IEEE Communication Magazine
April 1993.
[36] Saphira Software Manual
Saphira Versión 8.0a
Saphira/Aria integration
Kart G. Konolige.
SRI International, Menlo Park, California.

[37] Player
Version 1.3.1 User Manual
Brian P. Gerkey Richard T. Vaughan Andrew Howard
December 4, 2002

[38] Java Mobile Robots (JMR).

Manual del Programador versión 2.0
Domingo Gallardo López
Ignacio Iborra Baeza
Miguel Ángel Lozano Ortega.
Departamento de Ciencia de la Computación e Inteligencia Artificial
Universidad de Alicante Febrero 2003.
[39] Java 1.2 al descubierto
Jaime Jaworsky
Prentice Hall

[40] El lenguaje de programación java

Fco. Javier Ceballos
Ra_Ma

[41] Java en pocas palabras

David Flanagan
Mc Graw Hill

[42] Manual Avanzado Java 2

Felipe Lima DIAN
Edición 2000
Editorial Anaya Multimedia

[43] Introducción a Java Presentación de Java y Hot Java

Prentice Hall
Jhon December

[44] Manual de Java

Patrick Naughton
Osborne Mc Graw Hill.

118
[45] TELEASISNET: Sistema de tele-asistencia basado en un robot asistencial
R.Barea, L. M. Bergasa, E. López, M. Escudero, J. A. Hernández e
Y. Willemaers.
CD del SAAEI-EPF`04, Toulouse, 15-17 Sep. 2004.

[46] SISTEMA DE TRANSMISION-RECEPCION DESDE UN ROBOT

AUTONOMO E INTELIGENTE HACIA ACCIONAMIENTOS A
TRAVÉS DE LA RED ELECTRICA
Ignacio Bravo, Fernando Méndez, Esteban Basagoitia, Luis Miguel Bergasa
CD del SAAEI-EPF`04 Toulouse, 15-17 Sep. 2004.

[47] Control y Monitorización de Vivienda Inteligente Mediante SMS

J. A. Vera, M. Jiménez, y J. Roca
CD del SAAEI 2003, 11 y 12 de Sep 2003

[48] A. Ribeiro; R. Gz-Bueno; M. C. García-Alegre; D. Guinea

“Environment and Industrial Data Management System of a Net of Sensor
Nodes in Industrial Sites”
Proc. Geospatial World 2003, New Orleans (USA), 19-21 May 2003

[49] M. C. García-Alegre (;) R. González-Bueno (;) A. Ribeiro (;) D. Guinea

“Sistema de información, vigilancia y Control Atmosférico de un polígono
Industrial”
6º Congreso Nacional de Medio Ambiente, CDROM. Madrid Noviembre
2002.

119