movicuo comuniciones mÓviles de Última...
TRANSCRIPT
MMOOVVIICCUUOO:: CCOOMMUUNNIICCIIOONNEESS MMÓÓVVIILLEESS DDEE ÚÚLLTTIIMMAA GGEENNEERRAACCIIÓÓNN
PPAARRAA LLAA UUBBIICCUUIIDDAADD
Proyectando Javier D. Carmona Murillo
Director del proyecto José Luis González Sánchez
UNIVERSIDAD DE EXTREMADURA ESCUELA POLITÉCNICA
DEPARTAMENTO DE INFORMÁTICA PROYECTO FIN DE CARRERA INGENIERÍA INFORMÁTICA
Julio de 2.005
Movicuo
2
Proyecto Fin de Carrera. Ingeniería Informática
3
Derechos de Autor © 2005 Javier D. Carmona Murillo.
Se otorga permiso para copiar, distribuir y/o modificar este
documento bajo los términos de la Licencia de Documentación Libre
GNU, Versión 1.1 o cualquier otra versión posterior publicada por la
Free Software Foundation; sin Secciones Invariantes y con el Texto
de Portada “MOVICUO: Comunicaciones móviles de última
generación para la ubicuidad”.
Una copia de la licencia es incluida en la sección titulada “Licencia
de Documentación Libre GNU”
Movicuo
4
Proyecto Fin de Carrera. Ingeniería Informática
5
ÍNDICE SIMPLIFICADO: 1. Presentación del proyecto .................................................................................... 13
1.1. Introducción.................................................................................................... 13 1.2. Objetivos del proyecto.................................................................................... 14 1.3. Metodología utilizada..................................................................................... 15 1.4. Relación Movicuo - AGILA........................................................................... 16
2. Software Libre ...................................................................................................... 19
2.1. Introducción.................................................................................................... 19 2.2. Software Libre Vs Open Source..................................................................... 21 2.3. Otros métodos de distribución de software .................................................... 23 2.4. Licencias......................................................................................................... 24 2.5. ¿Por qué utilizar Software Libre?................................................................... 25 2.6. Cómo afectan las patentes del software al software libre............................... 26 2.7. El caso de GNU/LinEx................................................................................... 29
3. Situación tecnológica actual................................................................................. 33
3.1. Evolución histórica ......................................................................................... 33 3.2. GSM ............................................................................................................... 36 3.3. GPRS .............................................................................................................. 58 3.4. UMTS ........................................................................................................... 111
4. GRPS en un sistema Linux ................................................................................ 125
4.1. Introducción.................................................................................................. 125 4.2. Componentes de un “sistema” móvil ........................................................... 128 4.3. Acceso a capas inferiores. Comandos AT. ................................................... 130 4.4. Conexión a la red.......................................................................................... 132 4.5. GPRS sobre GNU/LinEx.............................................................................. 138 4.6. Protocolo Punto a Punto (PPP)..................................................................... 158
5. Propuesta de solución de conexión GPRS sobre LinEx. GNOME-GPRS...... 189
5.1. Especificación............................................................................................... 189 5.2. Estudio de viabilidad .................................................................................... 192 5.3. Manual del programador .............................................................................. 206 5.4. Guía de instalación y puesta en marcha........................................................ 234 5.5. Manual del usuario ....................................................................................... 237 5.6. Estudio práctico. Resultados ........................................................................ 277 5.7. Web del proyecto.......................................................................................... 297
6. Conclusiones........................................................................................................ 299
Movicuo
6
7. Líneas de investigación futuras ......................................................................... 301 8. Bibliografía.......................................................................................................... 303
8.1. Libros............................................................................................................ 303 8.2. Artículos ....................................................................................................... 303 8.3. Estándares..................................................................................................... 305 8.4. Rerefencias en Internet ................................................................................. 306
9. Anexo ................................................................................................................... 309
9.1. Licencia GNU............................................................................................... 309 9.2. Licencia de documentación libre GNU ........................................................ 315
Proyecto Fin de Carrera. Ingeniería Informática
7
ÍNDICE COMPLETO: 1. Presentación del proyecto .................................................................................... 13
1.1. Introducción.................................................................................................... 13 1.2. Objetivos del proyecto.................................................................................... 14 1.3. Metodología utilizada..................................................................................... 15 1.4. Relación Movicuo - AGILA........................................................................... 16
2. Software Libre ...................................................................................................... 19
2.1. Introducción.................................................................................................... 19 2.2. Software Libre Vs Open Source..................................................................... 21 2.3. Otros métodos de distribución de software .................................................... 23 2.4. Licencias......................................................................................................... 24 2.5. ¿Por qué utilizar Software Libre?................................................................... 25 2.6. Cómo afectan las patentes del software al software libre............................... 26 2.7. El caso de GNU/LinEx................................................................................... 29
3. Situación tecnológica actual................................................................................. 33
3.1. Evolución histórica ......................................................................................... 33 3.2. GSM ............................................................................................................... 36
3.2.1. Introducción............................................................................................ 36 3.2.2. Arquitectura de GSM ............................................................................. 37
3.2.2.1. MS (Mobile Station)....................................................................... 37 3.2.2.2. BSS (Base Station Subsystem) ....................................................... 38
3.2.2.2.1. BTS (Base Transceiver Station) .................................................. 38 3.2.2.2.2. BSC (Base Station Controller) .................................................... 39 3.2.2.2.3. TRAU (Transcoding and Rate Adaption Unit) ........................... 39
3.2.2.3. NSS (Network Switching Subsystem)............................................ 39 3.2.2.3.1. MSC (Mobile Switching Centre)................................................. 40 3.2.2.3.2. HLR (Home Location Register) y VLR (Visitor Location Register) 40 3.2.2.3.3. AuC (Authentication Centre) ...................................................... 40
3.2.3. Métodos de acceso: SDMA, FDMA y TDMA....................................... 40
Movicuo
8
3.2.3.1. SDMA............................................................................................. 40 3.2.3.2. FDMA............................................................................................. 41 3.2.3.3. TDMA ............................................................................................ 42
3.2.4. Secuencia de la transmisión.................................................................... 43 3.2.5. El problema del retardo en la transmisión sobre sistemas TDMA: Timing Advance ..................................................................................................... 44 3.2.5.1. Control del Timing Advance en el acceso a la red.................................. 44 3.2.5.2. Control del Timing Advance durante la conexión .................................. 45 3.2.6. Gestión de la Movilidad ......................................................................... 46 3.2.7. Interfaz aéreo GSM ................................................................................ 49 3.2.8. Conexión inicial...................................................................................... 53 3.2.9. Llamadas................................................................................................. 56 3.2.10. Protocolo de GSM .................................................................................. 56
3.3. GPRS .............................................................................................................. 58
3.3.1. Introducción............................................................................................ 58 3.3.2. Problemas de la conmutación de paquetes en comunicaciones móviles.61
3.3.2.1. Multitud de accesos de poca duración............................................ 61 3.3.2.1.1. Acceso mediante Aloha ranurado................................................ 62 3.3.2.1.2. Consecuencias de Aloha ranurado en GPRS............................... 63 3.3.2.1.3. Ocupación inmediata y liberación de recursos ............................ 64
3.3.3. Arquitectura GPRS................................................................................. 64 3.3.3.1. GGSN (Gateway GPRS Support Node) ......................................... 66 3.3.3.2. SGSN (Serving GPRS Support Node) ........................................... 66 3.3.3.3. CG (Charging Gateway)................................................................. 66 3.3.3.4. LIG (Lawful Interception Gateway)............................................... 66 3.3.3.5. DNS ................................................................................................ 67
3.3.4. Interfaces de red GPRS........................................................................... 67 3.3.5. Interfaz aéreo de GPRS .......................................................................... 69 3.3.6. Esquemas de codificación ...................................................................... 71 3.3.7. Tipos de terminales................................................................................. 72 3.3.8. Protocolos GPRS .................................................................................... 74
3.3.8.1. Canales físicos y lógicos ................................................................ 76 3.3.8.1.1. BCCH (Broadcast and Control Channel) .................................... 77 3.3.8.1.2. CCCH (Common Control Channel) ............................................ 77 3.3.8.1.3. PCCCH (Packet Common Control Channel) .............................. 77
3.3.8.2. SNDCP ........................................................................................... 78 3.3.8.3. LLC................................................................................................. 82
3.3.8.3.1. Modo sin asentimiento ................................................................ 83 3.3.8.3.2. Modo con asentimiento ............................................................... 83 3.3.8.3.3. Formato de la trama LLC ............................................................ 84
3.3.8.4. RLC/MAC ...................................................................................... 85 3.3.8.4.1. Flujo de bloques temporal (TBF) ................................................ 85 3.3.8.4.2. Formato de la trama RLC/MAC.................................................. 86
3.3.8.5. Protocolo de radio GPRS................................................................ 88 3.3.8.6. Nivel 1 ............................................................................................ 89 3.3.8.7. Protocolo del interfaz Gb................................................................ 89
3.3.8.7.1. Nivel 1 bis.................................................................................... 89 3.3.8.7.2. Frame Relay................................................................................. 89
Proyecto Fin de Carrera. Ingeniería Informática
9
3.3.8.7.3. BSSGP......................................................................................... 90 3.3.8.8. GTP................................................................................................. 92
3.3.9. Gestión de la conexión ........................................................................... 94 3.3.9.1. Gestión de la movilidad.................................................................. 95
3.3.9.1.1. Attach........................................................................................... 97 3.3.9.2. Gestión de la sesión ........................................................................ 99
3.3.10. QoS sobre una red GPRS ..................................................................... 105 3.3.11. Ventajas de GPRS ................................................................................ 110 3.3.12. Desventajas de GPRS ........................................................................... 111
3.4. UMTS ........................................................................................................... 111
3.4.1. Introducción.......................................................................................... 111 3.4.2. Arquitectura UMTS.............................................................................. 113
3.4.2.1. Release99...................................................................................... 113 3.4.2.1.1. UE (User Equipment) ................................................................... 114 3.4.2.1.2. RAN (Radio Access Network) ..................................................... 115
3.4.2.1.2.1. WBTS (WCDMA Base Station)............................................. 115 3.4.2.1.2.2. RNC (Radio Network Controller) .......................................... 115
3.4.2.1.3. 3GMSC (3G Mobile Switching Centre)....................................... 116 3.4.2.2. Evoluciones posteriores................................................................ 116
3.4.3. Métodos de acceso. FDD y TDD ......................................................... 117 3.4.4. QoS en UMTS ...................................................................................... 119 3.4.5. Canales en UMTS................................................................................. 121 3.4.6. Protocolo del interfaz aéreo.................................................................. 122 3.4.7. Control de potencia............................................................................... 123
4. GRPS en un sistema Linux ................................................................................ 125
4.1. Introducción.................................................................................................. 125 4.2. Componentes de un “sistema” móvil ........................................................... 128 4.3. Acceso a capas inferiores. Comandos AT. ................................................... 130 4.4. Conexión a la red.......................................................................................... 132 4.5. GPRS sobre GNU/LinEx.............................................................................. 138
4.5.1. Módulos del sistema operativo - Nivel Físico...................................... 139 4.5.1.1. Módulo CDC-ACM...................................................................... 141
4.5.2. Interacción con el teléfono. Comandos AT. ......................................... 142 4.5.3. Activar conexión PPP........................................................................... 144
4.6. Protocolo Punto a Punto (PPP)..................................................................... 158
4.6.1. Introducción.......................................................................................... 158 4.6.2. Arquitectura .......................................................................................... 159 4.6.3. Componentes y funcionamiento general .............................................. 160 4.6.4. LCP (PPP Link Control Protocol) ........................................................ 165
4.6.4.1. Configuración del enlace LCP...................................................... 168
Movicuo
10
4.6.4.2. Mantenimiento del enlace LCP .................................................... 170 4.6.5. Procolo de control de red PPP (IPCP) .................................................. 171
4.6.5.1. Funcionamiento de NCP............................................................... 171 4.6.5.2. IPCP (Internet Protocol Control Protocol) ................................... 172
4.6.6. Protocolo de autenticación de PPP (PAP) ............................................ 174 4.6.7. Formatos de las tramas PPP.................................................................. 175
4.6.7.1. Formato general de las tramas PPP .............................................. 176 4.6.7.1.1. Rangos y valores del campo protocolo...................................... 178
4.6.7.2. Formato de las tramas de control PPP y formato de las opciones.179 4.6.7.2.1. Mensajes de control PPP y valores del campo Código ............. 180 4.6.7.2.2. Formato de Opciones de los mensajes de control...................... 181
4.6.7.3. Formato de las tramas LCP .......................................................... 183 4.6.7.4. Formato de la trama PAP ............................................................. 186
5. Propuesta de solución de conexión GPRS sobre LinEx. GNOME-GPRS...... 189
5.1. Especificación............................................................................................... 189 5.2. Estudio de viabilidad .................................................................................... 192
5.2.1. Análisis de costes. ................................................................................ 194 5.2.1.1. Plan de desarrollo. Etapas del proyecto........................................ 195 5.2.1.2. Datos globales .............................................................................. 202
5.2.1.2.1. Costes y duración estimados ..................................................... 202 5.2.1.2.2. Costes y duración reales ............................................................ 204
5.3. Manual del programador .............................................................................. 206
5.3.1. Introducción.......................................................................................... 206 5.3.2. Desarrollo de aplicaciones GNOME .................................................... 207 5.3.3. Cómo programar conexiones GPRS en Linux ..................................... 208 5.3.4. Especificaciones lógicas del sistema .................................................... 209 5.3.5. Estructuras de datos .............................................................................. 210 5.3.6. Módulos ................................................................................................ 214
5.3.6.1. Main.............................................................................................. 216 5.3.6.2. Ppal ............................................................................................... 218 5.3.6.3. Conectado ..................................................................................... 221 5.3.6.4. Configuración ............................................................................... 223 5.3.6.5. Detalles ......................................................................................... 224 5.3.6.6. Deteccion_salidas ......................................................................... 226 5.3.6.7. Eggtrayicon................................................................................... 227 5.3.6.8. Ficheros ........................................................................................ 227 5.3.6.9. Notificación .................................................................................. 231 5.3.6.10. PPP_salidas................................................................................... 233
5.4. Guía de instalación y puesta en marcha........................................................ 234
5.4.1. Posibles problemas durante la instalación............................................ 236 5.5. Manual del usuario ....................................................................................... 237
5.5.1. Introducción.......................................................................................... 237
Proyecto Fin de Carrera. Ingeniería Informática
11
5.5.2. Entorno de trabajo ................................................................................ 237 5.5.3. Ejecución del programa por primera vez.............................................. 237 5.5.4. Ventana principal.................................................................................. 238
5.5.4.1. Botón “Salir” ................................................................................ 239 5.5.4.2. Botón “Ayuda” ............................................................................. 239 5.5.4.3. Botón “Configuración”................................................................. 244 5.5.4.4. Botón “Conectar” ......................................................................... 268 5.5.4.5. Botón “Analizar gráficas” ............................................................ 275
5.6. Estudio práctico. Resultados ........................................................................ 277
5.6.1. Caso 1. Tráfico constante sin QoS ....................................................... 277 5.6.2. Caso 2. Tráfico constante con QoS ...................................................... 281 5.6.3. Caso 3. Tráfico a ráfagas sin QoS ........................................................ 284 5.6.4. Caso 4. Tráfico a ráfagas con QoS ....................................................... 286 5.6.5. Caso 5. Estudio de los retardos en conexiones GPRS.......................... 289
5.7. Web del proyecto.......................................................................................... 297
6. Conclusiones........................................................................................................ 299 7. Líneas de investigación futuras ......................................................................... 301 8. Bibliografía.......................................................................................................... 303
8.1. Libros............................................................................................................ 303 8.2. Artículos ....................................................................................................... 303 8.3. Estándares..................................................................................................... 305 8.4. Rerefencias en Internet ................................................................................. 306
9. Anexo ................................................................................................................... 309
9.1. Licencia GNU............................................................................................... 309 9.2. Licencia de documentación libre GNU ........................................................ 315
Movicuo
12
Proyecto Fin de Carrera. Ingeniería Informática
13
1. Presentación del proyecto
1.1. Introducción
Según el Diccionario de la Real Academia Española, Movible significa: “Que por sí
puede moverse, o es capaz de recibir movimiento por ajeno impulso”, mientras que por
Ubicuo, se entiende: “Que está presente a un mismo tiempo en todas partes”. Con estas
dos definiciones, queda clara la motivación del Proyecto Movicuo, combinar
movimiento con ubicuidad, permitir el movimiento y estar presente en todas partes a
través de la red Internet, utilizando para ello las tecnologías móviles de última
generación y los sistemas Linux.
Más de mil millones de personas en el mundo (uno de cada seis habitantes), utilizan
teléfonos móviles GSM, en concreto, algo más de 1.375.200.000 clientes. Esta cifra se
ha alcanzado cuando la tecnología apareció hace apenas 13 años.
Más de 200 países han adoptado GSM, que ha pasado a ser la tecnología de referencia
global para la telefonía móvil, al ser la elección del 80% de los nuevos clientes,
haciendo que la cantidad de teléfonos móviles superen a las líneas telefónicas fijas en
todo el mundo.
Clientes por tecnología
GSMCDMATDMAUMTSOtras
Figura 1.1 – Número de clientes de las principales tecnologías móviles
Fuente: Informa Telecoms & Media. Marzo 2005
Movicuo
14
A pesar de estas cifras, ya han aparecido varias tecnologías que ofrecen otro tipo de
servicios que GSM no permite por sus características de diseño. Evoluciones como
GPRS, que permiten el acceso a redes de datos, en lugar de las tradicionales redes de
voz, han supuesto que el acceso a redes como Internet tenga otra lanzadera con millones
de usuarios potenciales, que cada vez demandan tecnologías que ofrezcan más
movilidad.
Esta característica, la movilidad, es una de las más demandadas en el siglo XXI. El
acceso a servicios de Internet como el correo electrónico o la banca electrónica, puede
hacerse desde cualquier sitio y en cualquier momento a través de estas tecnologías sin
más que disponer de un teléfono móvil con servicio GPRS.
El mundo del software libre no puede mantenerse al margen de estas iniciativas, y debe
sumarse a la evolución permitiendo que los usuarios de Linux, tengan la posibilidad de
acceder a estas tecnologías.
Considerando esta situación de evolución en la que nos encontramos, Movicuo pretende
ser una base en la que apoyarse para el desarrollo de sistemas de comunicaciones
móviles de última generación, ya que en este proyecto se detallan todos los aspectos
tecnológicos principales de las tecnologías GSM, GPRS y UMTS, además de aportar
una solución libre para la implantación de GPRS en un sistema como GNU/LinEx.
1.2. Objetivos del proyecto
El rápido crecimiento de Internet ha provocado la aparición de numerosas tecnologías y
protocolos de comunicaciones capaces de ofrecer múltiples servicios a los usuarios de
las redes actuales. Uno de los objetivos más importantes de este proyecto es el de usar
LinEx como plataforma donde desarrollar, implantar y explotar las tecnologías de
comunicaciones móviles más recientes y emergentes como GPRS (y en un futuro
UMTS). GNU/LinEx, debe estar dotado de todas las posibilidades actuales de
comunicación para que el acceso a Internet desde el sistema no se convierta en una
barrera de entrada para que sus potenciales usuarios desistan de usarlo en favor de otros
Proyecto Fin de Carrera. Ingeniería Informática
15
sistemas propietarios que pueden invertir grandes cantidades de dinero en seguir de
cerca la evolución tecnológica. Se pretende alcanzar también el objetivo de soportar
sobre el sistema, las comunicaciones inalámbricas mediante la unión del ordenador
portátil con el teléfono móvil, equipado con GPRS en estos momentos, y con UMTS en
el futuro.
Las tecnologías inalámbricas ofrecen importantes ventajas frente a las que requieren de
los necesarios cableados. Si a las tecnologías de comunicaciones que no requieren hilos
les unimos las ventajas de usar terminales multimedia, poco pesados y ergonómicos,
como ciertos ordenadores personales, y algunos terminales telefónicos, tendremos el
medio de acceso ideal a la sociedad de la información. En este proyecto se propone
principalmente el estudio e implantación de tecnologías de comunicaciones
inalámbricas de 2G 1/2, como GPRS (General Packet Radio Service), que servirá de
base para una futura implantación de UMTS (Universal Mobile Telecommunications
System). Para su desarrollo, se aplican técnicas propias del software libre para analizar
protocolos y proponer novedades y mejoras a la vez que nuevas aplicaciones con
calidad de servicio de estas modernas técnicas de comunicación.
1.3. Metodología utilizada
La metodología utilizada para el desarrollo de este Proyecto Fin de Carrera ha seguido
los pasos propios del desarrollo de proyectos informáticos:
Estudio y definición del problema: En esta fase se ha realizó un estudio de la tecnología
actual para comprobar la situación en la que nos encontrábamos. Se encontraron algunas
carencias de la tecnología relacionadas con el software libre, en concreto con el sistema
GNU/LinEx.
Estudio de viabilidad: Con las carencias encontradas en el punto anterior, se realizó un
estudio para analizar si existe una solución que sea factible desde varios puntos de vista
(técnico, económico y operacional).
Movicuo
16
Análisis: Una vez conocida la viabilidad del proyecto, se ha realizado un estudio con
más detalle, del funcionamiento de la tecnología, en concreto, los protocolos y
mecanismos utilizados en GNU/LinEx.
Diseño de la solución: Tras el análisis, y conocido el problema en detalle, se ha
especificado cómo debería ser la solución. Esto será un paso importante para que el
desarrollo sea más rápido y eficiente.
Desarrollo: Teniendo la solución diseñada, ahora queda desarrollarla de forma que
responda a las especificaciones creadas.
Documentación: Una parte muy importante para el conocimiento del proyecto y su
posible uso futuro es la documentación. Las posibles mejoras de Movicuo, tendrán
éxito, en la medida de que la documentación sea clara y descriptiva. El proyecto debe
quedar totalmente documentado.
1.4. Relación Movicuo - AGILA
Es necesario indicar, que este Proyecto Final de Carrera queda encuadrado dentro del
marco del proyecto AGILA (http://patanegra.unex.es/agila), otro proyecto de mayor
envergadura, en el que el autor colabora como investigador de apoyo. AGILA surge del
“II Plan regional de investigación, desarrollo tecnológico e innovación de
Extremadura”, patrocinado por la Conserjería de Educación, Ciencia y Tecnología de la
Junta de Extremadura.
Los objetivos de este proyecto, por tanto, son parte de los objetivos del proyecto
AGILA. Entre ellos está la implantación de GPRS sobre el sistema GNU/LinEx.
La herramienta software que acompaña al trabajo de investigación, ha sido desarrollada
con la intención y el convencimiento de que pueda convertirse en parte del sistema
GNU/LinEx, ya que actualmente carece de la posibilidad de permitir el acceso a Internet
Proyecto Fin de Carrera. Ingeniería Informática
17
a través de un teléfono móvil utilizando una tecnología de última generación como es
GPRS.
Desde esta situación, la herramienta podría ser adoptada por otros muchos sistemas que
tengan las mismas características que LinEx, colocándose como la aplicación de
referencia para entornos GNOME.
En todo caso, la aplicación desarrollada permite el acceso a Internet en un ordenador en
el que conectemos un teléfono móvil con soporte GPRS. Esto resulta muy útil para
aquellas ocasiones en las que sea necesario consultar una página web, ver el correo
electrónico, etc.…, en definitiva, cualquier operación que requiera una conexión a
Internet, y no se disponga mas que de un teléfono móvil y un ordenador sin ninguna otra
conexión.
Movicuo
18
Proyecto Fin de Carrera. Ingeniería Informática
19
2. Software Libre
Este proyecto está directamente relacionado con el software libre. En este apartado, se
presentan sus aspectos generales. Se hace especial hincapié en GNU/LinEx y el
software libre en Extremadura.
2.1. Introducción
La idea generalizada que existe en gran parte de la sociedad desde hace más de 30 años,
es que los vendedores de un programa software imponen las condiciones bajo las que
puede utilizarse, limitando las posibilidades de uso de un producto por el cual ya has
pagado y que es de tu propiedad.
Esta idea, como ya he dicho, generalizada, tiene la alternativa del software libre, que
concede las libertades que el software propietario tradicional niega.
Sobre el año 1984, Richard Stallman comenzó a trabajar en un nuevo proyecto al que
llamó GNU. Su idea era construir un sistema de software, de propósito general,
totalmente libre.
Una de las principales preocupaciones de Stallman era que los usuarios del software
pudieran tener más libertades de las que imponía su época. Así, nació la licencia GPL,
que utilizan un mecanismo que Richard Stallman llamó copyleft.
Stallman también fundó la Free Software Foundation (FSF) con el fin de conseguir
fondos para el desarrollo y la protección del software libre y estableció fundamentos
éticos del software libre, con documentos como: The GNU Manifesto y Why Software
Should Not Have Owners.
En estos documentos, software libre hace referencia a libertad. En concreto, Richard
Stallman se refiere a cuatro libertades:
Movicuo
20
1. Libertad para ejecutar el programa en cualquier sitio, con cualquier propósito y
para siempre.
2. Libertad para estudiarlo y adaptarlo a nuestras necesidades. Esto exige el acceso
al código fuente.
3. Libertad de redistribución, de modo que se nos permita colaborar con vecinos y
amigos.
4. Libertad para mejorar el programa y publicar las mejoras. También exige el
código fuente.
Estas libertades se garantizan con la licencia GPL, que también impone algunas
restricciones como dar crédito a los autores originales si redistribuimos el software o
incluso obligar a que los programas ajenos mejorados también sean libres, promoviendo
así, la creación de más software libre
A principios de los años 90, el proyecto GNU estaba cerca de ser un sistema completo
similar a UNIX, pero faltaba algo muy importante, el núcleo (kernel).
Por la misma época, la comunidad BSD estaba en camino hacia un kernel libre, que
apareció a principios de 1992 cuando Bill Jolitz distribuye 386BSD, un sistema que
funcionaba sobre la arquitectura i386 y que más adelante dio lugar a los proyectos
NetBSD, FreeBSD y OpenBSD.
En julio de 1991, Linus Torvalds pone un mensaje en Internet donde habla de su
proyecto de hacer un sistema libre similar a Minix. En septiembre libera la primera
versión (0.0.1), y pocas semanas después aparecen nuevas versiones. En marzo de 1994
aparece la versión 1.0. En todo ese tiempo, muchos desarrolladores se vuelcan sobre
este sistema, integrando a su alrededor multitud de programas libres. A diferencia de la
familia BSD, Linux (kernel) y gran parte de los componentes que se integran a su
alrededor se distribuyen con la licencia GPL.
Proyecto Fin de Carrera. Ingeniería Informática
21
Desde entonces, el desarrollo del software libre y de GNU/Linux ha ido creciendo,
llegando a ser, a principio de la década del 2000, un serio competidor al software
propietario en varios campos de la informática.
Ya en el nuevo milenio, la aparición de GNOME 2.x, KDE 3.x y OpenOffice, acercan
GNU/Linux a los usuarios domésticos y a muchas empresas. Estos sistemas ya son más
fáciles de instalar y la complejidad para mantenerlos y actualizarlos es comparable a la
de otros sistemas propietarios.
Hoy, las principales empresas de la industria del software tienen una estrategia con
respecto al software libre. La mayoría de las grandes multinacionales (IBM, HP, SUN,
Apple, Oracle), incorporan el software libre en mayor o menor medida. De las grandes
empresas, tan sólo Microsoft se ha posicionado totalmente en contra al software libre, y
en particular al software distribuido bajo licencia GPL.
2.2. Software Libre Vs Open Source
Las dos corrientes ideológicas más importantes entre aquellas que distribuyen el código
fuente son: Software Libre y Open Source. La primera trabaja hacia el objetivo de hacer
todo el software libre de restricciones, cree en las mejoras técnicas y trabaja a favor de
la comunidad. La segunda, Código Abierto, trabaja para conseguir la mayoría de los
mismos objetivos, pero basa sus argumentos en los méritos económicos y técnicos de
hacer el código fuente disponible libremente, en lugar de los principios morales y éticos
que se manejan en la metodología de Software Libre.
El movimiento del Software Libre está encabezado por la Free Software Foundation que
organiza la recaudación de fondos para el proyecto GNU. El software libre es más que
una ideología. En esencia, el software libre es un esfuerzo por garantizar ciertos
derechos para usuarios y diseñadores. Estas libertades incluyen la libertad para ejecutar
el programa por cualquier razón, la libertad para estudiar y modificar el código fuente,
la libertad para redistribuir la fuente, y la libertad para compartir cualquier
modificación. Para garantizar estas libertades, se creó la GNU General Public License
Movicuo
22
(GPL). La licencia GPL, obliga a cualquiera que distribuya un programa compilado
autorizado bajo la GPL a proporcionar el código fuente, y ser libre de hacer las
modificaciones al programa con tal de que esas modificaciones estén disponibles en el
código fuente. Esto garantiza que una vez el programa "se abre a la comunidad, no
puede cerrarse" excepto por el consentimiento de cada autor de cada pedazo de código
(incluso las modificaciones) dentro de él. La mayoría de los programas de Linux son
distribuidos bajo la GPL.
Es importante señalar que GPL no dice nada sobre el precio. Algo que mucha gente
confunde, es que el software libre no tiene por qué ser software gratis. Esta duda surge
por el significado del término “free”, que puede traducirse tanto por libre como por
gratis. La "parte libre" está en que el usuario o cliente posee el código fuente, no en el
precio que paga por el software. (Sin embargo, una vez que alguien lo ha vendido, o
incluso lo ha dado, un programa compilado distribuido bajo GPL éstas obligan a que se
proporcione su código fuente también).
Al frente del joven movimiento del Open Source, se encuentra la OSI (Open Source
Initiative) cuyo propósito es buscar apoyo para la distribución de software de código
abierto. Es decir, software que tiene el código fuente disponible así como el programa
listo para ejecutarse. No ofrecen una licencia específica, pero en cambio apoyan varios
tipos de licencia de fuente abierta disponibles. La idea detrás de la OSI es tener más
compañías usando código abierto permitiéndoles escribir sus propias licencias
certificadas por la Open Source Initiative. Muchas compañías quieren liberar el código
fuente, pero no quiere usar la GPL. Debido a que ellos no pueden cambiar la GPL
radicalmente, ellos ofrecen la oportunidad de proporcionar sus propias licencias
certificadas por esta organización.
Aunque la Free Software Foundation y la Open Source Initiative trabajan para ayudar al
usuario, en general, no son la misma cosa. La Free Software Foundation usa una
licencia específica y proporciona el software bajo esa licencia. La Open Source
Initiative busca un soporte para todas las licencias de código abierto, incluyendo la
licencia de la Free Software Foundation. La forma en que cada uno defiende hacer el
código fuente disponible divide a los dos movimientos, pero el hecho de que dos grupos
Proyecto Fin de Carrera. Ingeniería Informática
23
ideológicamente diversos estén trabajando hacia la misma meta, da credibilidad a los
esfuerzos de cada uno.
Independientemente de la corriente que provenga el Software ("Open-Source" o
"GNU"), ambos ofrecen productos libres y de calidad a los usuarios finales.
2.3. Otros métodos de distribución de software
FREEWARE: Programas gratuitos. Normalmente se ceden en binario y con derechos de
redistribución. Sin embargo, a veces sólo se pueden obtener de un sitio oficial,
normalmente para promocionar otros programas o servicios, como es el caso de los kits
de Java gratuitos que proporciona Sun Microsystems.
SHAREWARE: No es siquiera software gratis, sino un método de distribución, ya que
los programas, generalmente sin fuentes, se pueden copiar libremente, pero no usar
continuadamente sin pagarlos. La exigencia de pago puede estar incentivada por
funcionalidad limitada o mensajes en el programa. Además, las estipulaciones legales
de la licencia podrían utilizarse en contra del infractor.
CHARITYWARE, CAREWARE: Generalmente shareware, pero cuyo pago se exige para
una organización caritativa patrocinada. En muchos casos, el pago no se exige, pero se
solicita una contribución voluntaria. Algún software libre, como vim solicita
contribuciones voluntarias de este tipo.
DOMINIO PÚBLICO: El autor renuncia absolutamente a todos sus derechos, a favor
del común, lo cual tiene que estar declarado explícitamente en el programa, ya que si no
se dice nada, el programa es propietario y no se puede hacer nada con él. En este caso, y
si además se proporcionan los códigos fuentes, el programa es libre.
COPYLEFT: Un caso particular de software libre cuya licencia obligada a que las
modificaciones que se distribuyan sean también libres.
Movicuo
24
PROPIETARIO, CERRADO, NO LIBRE: Términos usados para denominar al software
que no es libre ni de fuente abierta.
2.4. Licencias
Lo que diferencia al software libre del resto del software es la licencia, un contrato entre
el autor (o propietario de los derechos) y los usuarios, que estipula lo que éstos pueden
hacer con su obra.
La legislación sobre derechos de autor, plasmadas en las leyes sobre propiedad
intelectual, asegura que por defecto, no se puede hacer prácticamente nada si su autor no
lo permite explícitamente. Las licencias de software libre dan ciertos permisos
explícitos.
Las condiciones (o restricciones) que imponen las licencias sólo pueden ser precisadas
por los propios autores, que según la normativa de propiedad intelectual son los
propietarios de la obra. La licencia no supone transferencia de propiedad, sino
solamente derecho de uso y, en algunos casos, de distribución.
A grandes rasgos, podemos distinguir dos tipos de licencias:
a) Licencias “minimalistas”, que no obligan a casi nada para poder redistribuir el
programa o trabajos derivados de él. La licencia más conocida de este tipo es la
licencia BSD. Estas licencias son tan permisivas que suele ser posible, por
ejemplo, que trabajos derivados del programa libre puedan redistribuirse bajo
licencias propietarias. Ejemplos de este tipo son las licencias usadas para los
sistemas BSD (Net BSD, OpenBSD, FreeBSD) y para el servidor web Apache.
b) Licencias “protectoras de la libertad”, que obligan a que las redistribuciones se
hagan bajo términos similares a la primera distribución. Este tipo de licencias
está diseñado de forma que los usuarios que reciben el programa después de una
serie de redistribuciones sigan disfrutando de las mismas restricciones que
Proyecto Fin de Carrera. Ingeniería Informática
25
garantizan que el programa nunca pueda redistribuirse como software
propietario. La licencia más conocida y habitual de este tipo es la GNU GPL,
que se usa por ejemplo para el kernel de Linux, la mayor parte de los programas
del proyecto GNU y la mayor parte de los sistemas KDE y GNOME.
2.5. ¿Por qué utilizar Software Libre?
El software libre trae consigo numerosas ventajas y pocas desventajas. De ella, la que
más fundamento tiene es la económica, ya que parece que no es posible obtener mucho
dinero de la distribución y ésta la puede y suele hacer alguien distinto al autor. Para
solventar este problema, deben utilizarse modelos de negocio diferentes a los
tradicionales.
Otras desventajas como la falta de soporte o la calidad escasa, están relacionadas con la
financiación, pero además, incluso sin financiación, el soporte a través de foros de
usuarios y desarrolladores especializados es realmente bueno, siendo normalmente los
propios autores del software los que colaboran en estos foros. La calidad del software
libre no es un problema, ya que tanto la colaboración como la competencia son dos
mecanismos muy relacionados con el software libre y que permiten que la calidad del
desarrollo sea alta.
Además, el software libre aporta beneficios a todas las partes implicadas de una u otra
forma en el desarrollo.
a) Para el usuario final, encontrar competencia en un mercado con tendencia al
monopolio, es una opción realmente interesante, en la que además, se le permite
modificar el software para adaptarlo a su uso particular.
b) Para la administración pública, ya que las características especiales deben
hacerla independiente y neutral de las empresas, dando a los usuarios servicios
accesibles, algo que el software libre ofrece.
c) Para el desarrollador, que debe adaptarse a estas nuevas situaciones, ya que
tendrá acceso a tecnología que de otra forma no podría utilizar. El uso del
Movicuo
26
trabajo de otros desarrolladores, le permitirá acceder a distintas evoluciones del
software, propiciado por la competencia.
2.6. Cómo afectan las patentes del software al software libre
Una patente da monopolio temporal sobre una tecnología, y se promueven normalmente
como mecanismos para mejorar el desarrollo tecnológico en un área dada, y para ayudar
a los innovadores a que consigan suficiente capital para convertir sus ideas en
productos. En el caso específico del software la legislación sobre derechos de autor y la
propia dinámica de la industria del software han sido suficientes para conseguir una
historia notable de rápida innovación tecnológica y buena consecución de fondos.
La industria del software es realmente dinámica. La barrera de entrada es muy baja en
campos que están tecnológicamente avanzados, y es posible convertir ideas en
productos con relativamente pocos recursos comparando con otras industrias.
Una barrera de entrada tan baja asegura que haya una fuerte competencia entre los
innovadores. Ésa es la principal razón por la cual la velocidad de desarrollo en la
industria del software es tan alta. Por otro lado, la legislación de derechos de autor
asegura que los desarrollos que hace un autor, no pueden ser usados directamente por su
competencia.
El retraso con el que otras empresas pueden desarrollar sus propios productos es
suficiente para asegurar la financiación al primer desarrollador, si es capaz de entregar
un producto razonable. La introducción de patentes de software incrementaría la
cantidad de recursos que necesita el desarrollador para poder hacer nuevos productos.
Necesitaría nuevos fondos para hacer estudios de patentes sobre su software, para pagar
licencias en caso de que su software sea alcanzado por una o más patentes (incluso si no
están relacionadas con las mejoras que introduce el producto) y para hacer provisiones
Proyecto Fin de Carrera. Ingeniería Informática
27
frente a los posibles litigios con dueños de patentes (incluso si la infracción de esas
patentes no está clara).
Además, las patentes presentan una clara ventaja a las grandes empresas que tengan
suficientes recursos, ya que comprando patentes, podrían alcanzar una situación de
monopolio, y parar completamente la innovación negándose a negociar licencias de sus
patentes. Por supuesto, eso reforzaría sus productos como únicas opciones.
Por estas y otras razones, el impacto de las patentes de software sobre el desarrollo de
software y sobre la mejora de las tecnologías del software es claramente negativo.
El impacto de las patentes sobre el software libre es, por su propia naturaleza, realmente
negativo, e incluso peor que en el caso de otros tipos de software (como el software
propietario). Hay tres características del software libre que explican este efecto negativo
específico:
• Disponibilidad del código fuente. El código fuente siempre está disponible para
su estudio y escrutinio en el caso del software libre. Eso significa que todas las
tecnologías de software que se usan están completamente expuestas a un análisis
de patentes. Si una empresa tiene que considerar la posibilidad de luchar en un
juicio por infracción de patente, la exposición del código fuente no es la mejor
estrategia posible. Las empresas querrán dificultar lo máximo posible las
querellas por infracción de patente. Eso les forzaría a no publicar el código
fuente de sus aplicaciones (ya sean tanto aplicaciones producidas como usadas
por esas empresas).
• Imposibilidad de negociar licencias. El software libre puede copiarse y
redistribuirse sin restricciones. Puede ser modificado e incorporado en otros
productos libres. Por lo tanto, no hay ningún punto único de distribución como
ocurre en el caso del software propietario. Eso hace que sea realmente difícil
encontrar un esquema para negociar licencias para el uso de patentes en
programas libres y es muy poco probable que se concedan licencias de muchas
patentes para su uso en programas libres.
Movicuo
28
• Impacto en pequeños desarrolladores. El software libre se desarrolla en muchos
casos por empresas muy pequeñas y desarrolladores individuales. El trabajo de
examinar todo el código producido y todas las contribuciones recibidas
buscando posibles usos de tecnologías patentadas está completamente fuera de
las posibilidades de esos desarrolladores. Por lo tanto, si hay que realizar
estudios de infracción de patentes antes de distribuir software (debido al riesgo
de ser acusado de infracción de patente) muchos de estos desarrolladores no
podrán producir productos con software libre. Incluso si no usan ninguna
tecnología patentada.
Por lo tanto, la promoción del software libre es absolutamente incompatible con la
introducción de las patentes de software.
En resumen, las patentes de software, como cualquier tipo de patente, tienen efectos
negativos para la sociedad en su conjunto. En otras industrias pueden producir
suficientes beneficios que los contrapesen, pero éste no es el caso de las patentes de
software. No mejoran la velocidad de desarrollo de software y pueden dañar a los
pequeños (pero muy productivos) innovadores. En el caso del software libre el impacto
de las patentes de software es especialmente dañino.
La situación actual de las patentes de software en la Unión Europea es, que a principios
de Marzo de 2005, los ministros de Industria y Energía de los Veinticinco países de la
Unión Europea, ratificaron sin debate (España era el único país que votó en contra) el
acuerdo político alcanzado en mayo de 2004 sobre la directiva sobre la patentabilidad
de invenciones implementadas en ordenadores, que está defendida por grandes
empresas como Nokia o Microsoft. En la actualidad, la directiva sobre las patentes
Hace unos días (21 Junio 2005), la comisión de Asuntos Jurídicos del Parlamento
Europeo, ha respaldado dicha directiva, que aún debe ser ratificada en la Eurocámara en
julio.
Proyecto Fin de Carrera. Ingeniería Informática
29
2.7. El caso de GNU/LinEx
A finales de los años 90, la Junta de Extremadura comienza a desarrollar una política de
implantación del conocimiento e innovación tecnológica para llegar a una igualdad y
libertad por parte de todos los ciudadanos de la comunidad. Esto se debía
principalmente al proceso que se estaba siguiendo en Europa de liberalización del
mercado de las telecomunicaciones. En esta situación, Extremadura pasaba a
encontrarse en una situación de riesgo, al resultar muy poco rentable llevar
infraestructuras a las localidades pequeñas en las que habita la mayoría de la población
extremeña. Para ello, en 1998, desde la Junta de Extremadura se lanzó un reto de
incorporar a Extremadura a la Sociedad de la Información, con el compromiso de no
dejar fuera a nadie. De esta forma comenzó un proyecto que tenía dos bases
fundamentales:
• Conectividad total para todos los municipios de la región
• Alfabetización tecnológica para todos los ciudadanos
Este proyecto pretendía ser un impulso para la formación y la creación de negocios en el
ámbito de las tecnologías de la información en Extremadura.
Las distintas actuaciones que se debían realizar, para llevar a cabo con éxito el proyecto,
suponían un coste imposible de afrontar por la administración extremeña. Bajo estas
condiciones, prácticamente la única solución viable desde el punto de vista económico,
era la de utilizar software libre. Así, a principios de 2002, la Junta de Extremadura dio a
conocer públicamente el proyecto LinEx. La idea es promover la creación de una
distribución basada en GNU/Linux con el objetivo de utilizarla en los miles de
ordenadores que se iban a instalar en los centros educativos públicos de toda la región.
Por tanto GNU/LinEx desde su comienzo tenía fijados sus objetivos:
Movicuo
30
• Objetivo Educativo para contribuir al desarrollo de la Red Tecnológica
Educativa, proporcionando un ordenador por cada dos alumnos en las aulas de
centros educativos.
• Objetivo Social y Económico para la difusión de los programas libres en
Extremadura, a través del Plan de Alfabetización Tecnológica, las Pymes y la
propia Administración.
La utilización del Software Libre evita las barreras económicas, como era el caso de las
licencias. Algunas empresas extremeñas de nuevas tecnologías ya están obteniendo
beneficios con el desarrollo de tecnología mediante este método.
El uso de este sistema por la Administración Pública de Extremadura supone un ahorro
bastante considerable, ya que según las estimaciones de la Consejería de Educación,
Ciencia y Tecnología de la Junta de Extremadura, un ahorro de 48.000 euros supondría
el coste de las licencias de uso de los diferentes programas de software propietario que
se instalarían en 22 ordenadores.
El por qué usar este modelo es debido a los objetivos propios del Software Libre. El
objetivo social de este tipo de software es evitar que los ciudadanos se vean obligados a
adquirir licencias de uso de determinados productos a la hora de emplear los medios
electrónicos para comunicarse con las administraciones públicas y que puedan hacerlo
mediante aplicaciones estándares y gratuitas. También se busca que las
administraciones públicas, no dependan de la evolución que establezca el mercado, sino
de una evolución tecnológica que asegure la calidad de los productos y reduzca las
inversiones improductivas, condicionadas por intereses comerciales.
El modelo de software libre, en el que se basa GNU/LinEx, se sustenta en la necesidad
de defender una serie de libertades en el ámbito de la tecnología digital: libertad para
usar los programas informáticos, sin restricción alguna; libertad de acceder al código
fuente de los programas, pudiendo adaptarlos según necesidades, libertad para distribuir
copias de programas; libertad para mejorar el programa y difundir esas mejoras en
Proyecto Fin de Carrera. Ingeniería Informática
31
beneficio del interés general; y libertad de inspección del código fuente para garantizar
la transparencia de los procesos.
LinEx es una distribución basada en tecnología GNU/Linux a partir del desarrollo de
Debian y GNOME. Sus utilidades son muy amplias, propias del software libre, que
permiten un aprovechamiento máximo de la tecnología para los usuarios finales. En el
proyecto Movicuo, se ha desarrollado una herramienta que puede ser incorporada a
GNU/LinEx, para permitir a los usuarios conexiones a Internet a través de sus teléfonos
móviles.
En estos dos años de vida, el proyecto GNU/LinEx ha recibido premios por haber sido
un proyecto innovador, como es el Premio de la Comisión Europea, que supone el
impulso definitivo al proyecto de acceso a la Sociedad de la Información para
Extremadura.
A pesar de los muchos reconocimientos que ha tenido este proyecto, existen en la
actualidad varios aspectos que deben ser resueltos. La Junta de Extremadura se lanzó a
comprar equipos informáticos para conseguir el ratio de dos alumnos por ordenador en
cada aula de los centros educativos extremeños, sin tener una base sólida que permitiese
al profesorado utilizar GNU/LinEx como punto de partida pedagógica para sus clases.
Esto provocó que en muchos centros de la región, los ordenadores estuvieran
almacenados sin ser utilizados, o incluso que permanecieran apagados dentro de las
propias aulas.
Antes de que muchos profesores tuviesen la formación adecuada y de que se hubiesen
desarrollado aplicaciones sobre LinEx que permitiera su uso en las distintas asignaturas
impartidas, los equipos ya estaban en los colegios, sin que nadie los utilizara. En el
campo de la informática, los productos se devalúan mucho en muy poco tiempo, por lo
que todos estos problemas han supuesto una pérdida importante de dinero.
La Administración extremeña está solventado estos errores, para empezar a cumplir los
objetivos propuestos por el proyecto GNU/LinEx.
Movicuo
32
A partir de la decisión de la Junta de Extremadura, el debate del uso de software libre
por parte de las administraciones públicas se ha avivado, y ya en España hay muchas
administraciones que han decidido seguir los pasos de Extremadura.
Actualmente, LinEx está en su versión 2004 (liberada en Agosto de 2004), y se espera
que LinEx 2005 se presente en la “II Conferencia Internacional de Software Libre -
Encuentro Internacional sobre Conocimiento Libre”, que se celebrará en Mérida en
Octubre de 2005.
Proyecto Fin de Carrera. Ingeniería Informática
33
3. Situación tecnológica actual
3.1. Evolución histórica
Las comunicaciones mediante dispositivos electrónicos han evolucionado de una forma
considerable en los últimos años. Aunque las redes comerciales de telefonía móvil
aparecieron a principio de los años 40, se consideran a las redes analógicas de finales de
los 70 en Estados Unidos y en Europa a principio de los 80, como la primera generación
(1G) de redes sin cables.
Desde estos terminales analógicos hasta las propuestas para tercera y cuarta generación
de telefonía móvil, que ya están siendo utilizados ha habido muchos cambios en las
necesidades y requerimientos, las nuevas tecnologías ya no se enfocan tanto a la
comunicación entre personas, el enfoque cada día está más dedicado a la comunicación
entre objetos electrónicos, y a comunicaciones de datos. Los nuevos servicios requieren
una conexión mucho más rápida en lo que a datos se refiere, por eso se implementaron
protocolos como GPRS, que se puede implementar en sistemas de 2G y 2.5G.
La telefonía móvil comenzó con los sistemas analógicos, el más importante de estos
sistemas fue Advanced Mobile Phone Service (AMPS). Este sistema se conoce como de
1G. Aparece en 1983, utilizaba modulación FM.
Después del sistema AMPS, apareció el sistema IS 41 o TDMA. Este sistema divide el
canal en ranuras de tiempo, cada ranura equivale a un móvil transmitiendo información
por lo que cada canal es compartido por tres usuarios. La modulación para este sistema
es mucho más compleja que para AMPS, aquí se utilizaba π/4 DQPSK.
Otro sistema que tuvo gran éxito fue el sistema IS 95, que en lugar de utilizar TDMA
utiliza CDMA o acceso múltiple por división de código. Este sistema consiste en
asignar códigos de pseudos ruido en la transmisión. En el receptor, el dispositivo que
Movicuo
34
cuente con el código, recibe la información; para el resto de los usuarios, la información
aparece simplemente como ruido.
A principios de la década de 1980, los sistemas analógicos tuvieron un período de
rápido crecimiento en Europa. Algunos países se dedicaron a desarrollar su propio
sistema, incompatible con los de los demás.
A finales de los 80, las comunicaciones digitales comenzaron a desplazar a las
analógicas, debido a que los sistemas móviles no pueden soportar una gran capacidad de
tráfico ya que el espectro es limitado; por esta razón se tuvo en los sistemas móviles una
salida al problema de tráfico denso como el que se presenta en zonas urbanas.
Esto supuso que CEPT (Confederación de Correos y Telégrafos Europeos) formara un
grupo, llamado Groupe Speciale Mobile para estudiar y desarrollar un sistema
telefónico móvil terrestre, y público para toda Europa. En 1989 fue transferida la
responsabilidad de GSM al Instituto Europeo de Normas y Telecomunicación (ETSI) y
en 1990 se publicó la fase I de las especificaciones GSM. Este sistema tuvo la ventaja
de haberse diseñado desde cero, sin importar si era compatible con los sistemas
existentes.
GSM fue el estandarte de la segunda generación, pero pronto comenzarían a aparecer
nuevas tecnologías como GPRS (General Packet Radio Service), que puede ser
considerado de 2.5G. Este sistema utiliza TDMA y se incluyó la conmutación de
paquetes, lo que proporcionaba tasas de transmisión de datos mayores. GPRS es muy
importante porque es el sistema de conmutación de datos de mayor aceptación a nivel
mundial. En un principio fue desarrollado para Europa, pero fue adoptado por muchos
más países.
El estándar de 3G propuesto por el ETSI (European Telecommunications Standards
Institute) es UMTS (Universal Mobile Telecommunications System). UMTS es un
estándar ratificado por el ITU-T (Internacional Telecommunications Union –
Telecommunication Standardization Sector) bajo el amparo de IMT2000 (Internacional
Mobile Telephony). Este es el estándar dominante, con el estadounidense CDMA2000
Proyecto Fin de Carrera. Ingeniería Informática
35
que va ganando terreno, especialmente con los operadores que desarrollaron
CDMAONE, que es su predecesor.
UMTS es especificado como una migración de GSM de 2G a UMTS, a través de GPRS
y EDGE como se muestra en la figura 3.1.
Figura 3.1 – Evolución de GSM a UMTS
Los sistemas de tercera generación, se consideran como los sistemas que obtendrán el
mayor número de usuarios en la primera década de este siglo. Las estimaciones indican
que para el 2010 habrá al menos 600 millones de abonados. Lo más importante y por lo
que se estima este éxito es por los servicios que se podrán ofrecer.
Figura 3.2 – Posibilidades de evolución de 2G a 3G
Movicuo
36
Para el caso de 4G, los servicios se mantienen e incrementan levemente, pero la
velocidad de transmisión será mucho mayor, el punto más importante es que las
diferentes arquitecturas de los diferentes sistemas se encontrarán completamente
interconectadas, y el usuario podrá disponer de todos los servicios que ofrecen.
3.2. GSM
3.2.1. Introducción
El desarrollo de GSM comenzó con un grupo formado por la CEPT (European
Conference of Postal and Telecommunications Administrations), para investigar el
desarrollo de un estándar de comunicaciones móviles para ser usado en Europa.
Este grupo era conocido como el “Groupe Special Mobile”, o GSM, es de ahí de donde
vienen las siglas de este estándar, ahora más conocido como Global System for Mobile
Communications.
El deseo de un sistema unificado en Europa había sido una constante desde que muchos
de los países que lo componen habían desarrollado diferentes tecnologías que eran
incompatibles entre sí.
Paralelamente, en Estados Unidos, las tecnologías móviles estaban avanzadas también,
pero al ser un solo país, las necesidades de roaming no eran tan importantes como en
Europa.
GSM fue adoptado como un estándar europeo por el ETSI, para operar en tres regiones
de frecuencias principales:
• 900 MHz
• 1800 MHz
Proyecto Fin de Carrera. Ingeniería Informática
37
• 1900 MHz
GSM es con mucha diferencia el sistema más importante de la segunda generación, y ha
sido adoptado no solo en Europa, sino en las regiones Asiáticas del Pacífico y más
recientemente en América. Algunos de los operadores de redes móviles más importantes
de Estados Unidos están introduciendo GSM como una migración a UMTS o
simplemente para que la oferta de sus servicios sean mayores. Otros sistemas utilizados
son IS-136 (basada en TDMA), IS-95 o cdmaOne (basado en CDMA) y PDC.
Actualmente, GSM abarca sobre el 80 % del mercado global de los sistemas móviles.
Aunque las redes evolucionan a 3G, GSM no debería ser desplazada, ya que es una
parte de las redes GPRS y UMTS.
3.2.2. Arquitectura de GSM
La estructura de una red GSM es la que se muestra en la figura 3.3:
Figura 3.3 – Arquitectura de la red GSM
Cada uno de los componentes de esta figura se explican en los siguientes apartados.
3.2.2.1. MS (Mobile Station)
Está compuesto por el dispositivo móvil y una pequeña tarjeta llamada Subscriber
Identify Module (SIM). Esta tarjeta ofrece movilidad, ya que el usuario puede extraer la
Movicuo
38
tarjeta de un terminal y colocarlo en otro sin informar al operador de red. Esto contrasta
con la mayoría de sistemas de 2G, los cuales requieren un registro con el operador ante
esta situación.
La tarjeta SIM contiene un identificador único llamado IMSI (Internacional Mobile
Subscriber Identify), utilizado como una clave secreta para autenticación y otros
mecanismos de seguridad.
El terminal móvil es también identificado de forma única por el IMEI (Internacional
Mobile Equipment Identity), que es un número de 15 dígitos.
3.2.2.2. BSS (Base Station Subsystem)
El BSS consiste fundamentalmente en un conjunto de BTS (Base Transceiver Station)
que permiten la conexión inalámbrica del móvil a la red, a través del interfaz Um o
Interfaz aéreo. Los otros elementos que componen el BSS son: el BSC (Base Station
Controller) que controla los BTSs y el TRAU (Transcoding and Rate Adaption Unit).
3.2.2.2.1. BTS (Base Transceiver Station)
Aquí se encuentran los transceptores de radio (TRXs) que definen una célula y
mantienen el enlace de radio con el dispositivo móvil. Cada TRX puede mantener hasta
ocho usuarios simultáneamente. Si más de ocho usuarios requieren recursos de los
TRXs, recibirán un tono de ocupado o un mensaje de ocupado aparecerá en su
dispositivo. Es posible incrementar el número de usuarios conectados simultáneamente
a una célula incrementando el número de TRXs (aumentando el número de frecuencias
utilizadas). Cuando el dispositivo móvil se mueve y cambia de una célula a otra de
cobertura, el BTS debe cambiar. El primer TRX en una célula puede mantener hasta
siete usuarios, ya que un canal está reservado para broadcasting, y es conocido como
BCCH (Broadcast and Control Channel). Además, el BTS asume la mayoría de las
funciones de nivel 1 en la comunicación entre la red y el MS.
Proyecto Fin de Carrera. Ingeniería Informática
39
3.2.2.2.2. BSC (Base Station Controller)
Todos los BTS de un BS están conectados al BSC a través de un interfaz llamado Abis.
Gestiona los recursos de radio de uno o mas BTSs. Mantiene el canal de radio y
establece la frecuencia cuando un usuario pasa de una célula a otra de cobertura.
3.2.2.2.3. TRAU (Transcoding and Rate Adaption Unit)
El rol principal de los sistemas de segunda generación es transferir llamadas, por lo que
los sistemas se han diseñado para tráfico de voz. La voz humana es convertida a código
binario en un proceso relativamente complejo. GSM es un sistema algo antiguo, por lo
que el método original de codificación utilizado (LPC-RPE) no es tan eficiente como
alguno de los desarrollados para otros sistemas. Hay mucho desarrollo en el
procesamiento de señales digitales, que ha permitido que voz de alta calidad sea
transmitida de forma óptima. Aunque TRAU ha formado parte de BSS, normalmente
reside cerca del MSC, ya que esto hace que los costes se reduzcan. Los datos de voz son
transmitidos en un canal de 16kbps desde el dispositivo móvil hasta el TRAU mediante
BTS y BSC. El TRAU convierte esos datos a 64 kbps para transmitir sobre otras redes
como por ejemplo RDSI. Ver figura 3.4.
Figura 3.4 – Velocidad entre los elementos de la red GSM
3.2.2.3. NSS (Network Switching Subsystem)
Comprende el núcleo de red de circuitos conmutados. Está formado por los elementos
que se describen en los siguientes apartados.
Movicuo
40
3.2.2.3.1. MSC (Mobile Switching Centre)
Es uno de los elementos principales del NSS, que actúa como un nodo normal que
conmuta y gestiona los paquetes, con la funcionalidad añadida de pertenecer a una red
móvil. Básicamente puede considerarse que se encarga de las tareas de conmutación.
3.2.2.3.2. HLR (Home Location Register) y VLR (Visitor Location Register)
Mantienen la localización de los terminales mediante bases de datos en las que se
encuentra la “situación” de cada cliente. Cuando un MS se mueve a una nueva
ubicación, el VLR almacena la nueva posición e informa al HLR.
3.2.2.3.3. AuC (Authentication Centre)
Se suele integrar en el HLR y se encarga de las funciones de autenticación de las MS, ya
que es una base de datos que contiene una copia de la clave secreta de las tarjetas SIM
de cada usuario
3.2.3. Métodos de acceso: SDMA, FDMA y TDMA
GSM, como red de comunicaciones móviles de segunda generación, utiliza los tres tipos
clásicos de acceso múltiple: SDMA (Space Division Multiple Access), FDMA
(Frequency Division Multiple Access) y TDMA (Time Division Multiple Access).
Estos tres métodos serán utilizados en paralelo y de forma simultánea.
3.2.3.1. SDMA
La base de esta tecnología es que toda una zona geográfica no estará dedicada a una
única estación emisora. La potencia de emisión de las estaciones emisoras estará
Proyecto Fin de Carrera. Ingeniería Informática
41
limitado, ya que una frecuencia dada deberá ser usada de nuevo en otra zona cercana.
SDMA proporciona la estructura de una red inalámbrica, y esto traerá ventajas y
desventajas. Las ventajas fundamentales son la alta reusabilidad de frecuencias, y las
bajas potencias de transmisión necesitadas por los móviles.
Como desventajas, podemos decir que SDMA proporciona una estructura compleja, en
la que será relativamente complicado el control de algunos aspectos como el roaming o
el handover.
La figura 3.5 muestra la estructura de una red basada en SDMA
Figura 3.5 – Estructura de una red SDMA
3.2.3.2. FDMA
Al igual que SDMA, FDMA es una técnica de acceso múltiple en la que ahora, cada
banda de frecuencia es dividida en canales individuales. En el caso de GSM, hay que
considerar que serán necesarios dos canales de frecuencia en una conexión
Movicuo
42
bidireccional: uno para la transmisión al móvil y otro para el sentido contrario desde el
móvil hasta la estación base.
En GSM, un canal de frecuencia necesita 2x200 kHz. Más adelante en este capítulo se
explicarán las frecuencias utilizadas por GSM y cómo son repartidas.
3.2.3.3. TDMA
Para FDMA, el rango de frecuencias disponibles está dividido en canales de frecuencias
individuales. Cuando hay una conexión activa, un cliente recibe un canal de frecuencia
exclusivo para su uso mientras dure la llamada y nadie más podrá hacer uso de esta zona
del espectro.
Con TDMA, esta situación se mejora. Cada canal de frecuencia es también dividido y
cada cliente tendrá derechos de acceso a un canal durante una conexión por un corto,
pero repetido, espacio de tiempo. En un sistema TDMA, estos intervalos de tiempo que
se repiten periódicamente son llamados time-slots. Para dar la impresión de una
conexión ininterrumpida, debe ser enviada una cantidad de información determinada
por cada time-slot.
En GSM, cada canal de frecuencia es dividido en ocho time slots. Cada uno tiene una
longitud de 576’9 µs o 156’25 bits y se repite cada 4’615 ms. Según esta definición,
hasta ocho usuarios podrán utilizar un canal de frecuencia de forma simultánea e
independiente unos de otros.
Proyecto Fin de Carrera. Ingeniería Informática
43
Figura 3.6 – División en el tiempo (TDMA) y en la frecuencia (FDMA)
3.2.4. Secuencia de la transmisión
En GSM, la estación base siempre transmite tres time slots antes que el dispositivo
móvil. En otras palabras, la transmisión de un time slot de bajada (downlink), siempre
ocurrirá tres time slots antes que la transmisión del mismo time slot en el sentido de
subida (uplink).
Un dispositivo, sincronizado con una estación base que recibe información en un time
slot X, tendrá por tanto que esperar otros 3 time slots (3 x 156’25 bits = 468’75 bits),
antes de enviar sus datos.
Según esto, si se permiten transmisiones y recepciones simultaneas en el dispositivo
móvil, hay sólo varias combinaciones de slots de subida/bajada disponibles que pueden
permitir esta situación. Es imposible proporcionar a un único usuario más de cuatro
time slots para la bajada o para la subida.
Movicuo
44
3.2.5. El problema del retardo en la transmisión sobre sistemas TDMA: Timing Advance
En todos los sistemas TDMA, la transmisión de datos en ambas direcciones
necesariamente debe hacerse en forma de impulsos. En GSM, esos impulsos son
llamados ráfagas o bursts. Uno de los principales problemas de los sistemas TDMA, es
el retardo que aparece al transmitir una ráfaga. Si la transmisión es de bajada (de la
estación base a la estación móvil), no hay problemas ya que todos los dispositivos
móviles pueden recibir su señal (su ráfaga) independientemente de otras estaciones
móviles. En el otro sentido (uplink), existe la posibilidad de colisiones con las ráfagas
enviadas por otros móviles. Esto se produce porque se desconoce el retardo, o mejor
dicho, se desconoce la distancia entre el móvil y la estación base. Como los terminales
móviles pueden moverse libremente dentro de la red, ese retardo varia durante la
conexión.
De esta forma, los dispositivos móviles activos deben constantemente ajustar el
comienzo de su transmisión para que sus datos entren dentro de la ventana de recepción
de la estación base.
Este problema no existirá al comienzo de una conexión, sino durante ella. Si no se
resolviera este problema, los terminales no tendrían la posibilidad de cambiar de
posición durante una llamada. En GSM, el control de este retardo se denomina control
del avance del tiempo o Timing Advance Control.
3.2.5.1. Control del Timing Advance en el acceso a la red
El control del Timing Advance resulta particularmente difícil cuando se produce el
acceso a la red. En esta situación, el dispositivo móvil puede estar a cualquier distancia
Proyecto Fin de Carrera. Ingeniería Informática
45
de la estación base (dentro de su zona de cobertura). Esa distancia es desconocida, por
tanto:
• ¿Cómo informa el dispositivo a la estación base de su intención de acceso a la
red?
• ¿Qué ocurre con las colisiones que se puedan producir entre las señales de
distintos dispositivos móviles, debido al desconocimiento de su retardo?
En GSM, para el acceso a la red, la estación base utiliza una ráfaga de acceso especial.
Esta ráfaga es mucho más corta que las normales, de forma que por muy lejos que el
dispositivo esté de la estación base, siempre entrará en su ventana de recepción. El
dispositivo móvil siempre supone que el timing advance (la distancia) será cero cuando
se transmite una ráfaga de acceso. La longitud de la ráfaga de acceso y el ancho de la
ventana de recepción en el BTS son sumados para dar el radio máximo de cobertura de
una estación base (35 Km.). De acuerdo con el tiempo de llegada de la ráfaga de acceso
a la ventana de recepción correspondiente, la estación base estima la distancia al móvil
y le devuelve este valor durante la asignación del canal. El terminal entonces regula su
timing advance y puede entonces utilizar ráfagas normales. Por ejemplo, si el
dispositivo móvil recibe un valor de timing advance de 26, ya no transmite 486’75 bits
en la ráfaga, sino 486’75 – 26 = 460’75 bits. Así, existirá la correspondencia adecuada
entre el timing advance y el retardo entre la recepción y la transmisión en la parte del
dispositivo móvil.
Las colisiones son resueltas con la técnica de aloha ranurado, que es utilizado por todos
los estándares de comunicaciones móviles, entre ellos GSM. Esta técnica se describe
con más detalle en el apartado que trata GPRS.
3.2.5.2. Control del Timing Advance durante la conexión
Durante una conexión, la estación base recibe una ráfaga del móvil cada 4’615 ms. Con
la ayuda del campo TSC (Training Sequence Code) que aparece en una en ráfaga
Movicuo
46
normal, el BTS es capaz de medir el timing advance, según el cambio de los bits en este
campo.
Figura 3.7 – Campo TSC de la ráfaga
3.2.6. Gestión de la Movilidad GSM
Para hacer y recibir llamadas, la posición del dispositivo debe ser conocida por la red.
Sería muy ineficiente que un usuario tuviera que ser buscado por toda la red, además de
que sería prácticamente imposible soportar roaming.
Cada célula dispone de un canal de broadcast, que es utilizado por los dispositivos para
operaciones de localización. Nos referimos a localización, no como la posición exacta
del dispositivo, sino más bien a la célula en la que se encuentra.
El principal beneficio de la telefonía móvil frente a la fija es la libertad de movimientos
que permite al usuario. Esto hace que la red sea mucho más difícil de diseñar y
gestionar.
Cuando un usuario se mueve de una posición a otra, la intensidad de la señal que recibe
de la estación base a la que está conectado variará, de la misma forma que lo hará la
señal que la estación base reciba del dispositivo. Tanto la red como el dispositivo tienen
que controlar constantemente la intensidad de la señal, siendo el dispositivo el que
indique a la red la información medida. Además, el dispositivo, tendrá que observar la
intensidad de la señal que reciba de las células vecinas. Cuando la intensidad de la señal
recibida de una estación sea demasiado débil, se producirá un handover a una estación
de otra célula. La red deberá garantizar, en la medida de lo posible, que durante el
cambio de célula la llamada no se rompa, y dicho cambio se produzca de una forma
suave y transparente para el usuario.
Proyecto Fin de Carrera. Ingeniería Informática
47
En la figura 3.8 puede comprobarse que información se almacena en la red cuando un
dispositivo se encuentra en alguno de los dos posibles modos de operación: parado y
dedicado. El HLR, que está en la propia red, conoce que VLR tiene información con
respecto a un cliente en particular. Ésta, depende del estado en el que se encuentre el
dispositivo ya que en el estado parado, tan sólo es conocido el LA (Location Area) en el
que se encuentra, mientras que en modo dedicado, también se conoce la célula en la que
se localiza.
Figura 3.8 – Datos conocidos por la red según el estado
Diremos que un dispositivo está en estado parado cuando se ha registrado a la red
(normalmente al encenderse), pero no está realizando ninguna llamada. Cuando el
teléfono se encuentra en este estado, enviará información de forma periódica a la red
indicando que está activo. Cuando el usuario quiera realizar una llamada, el dispositivo
actualizará su posición en la red, y pasará al estado dedicado.
En el estado parado, la situación del dispositivo es conocida, pero de forma menos
concreta que en el modo dedicado, esto significa que sabremos en que grupo de células
se encuentra, pero no en cual de ellas. Durante este estado, el dispositivo “controla”
varias células, que serán conocidas como LA (Location Area), y envía la actualización
de su posición a la red cuando se produzcan alguna de las siguientes situaciones:
• El dispositivo traspasa la frontera entre dos LAs.
Movicuo
48
• Al transcurrir un determinado periodo de tiempo en el que el dispositivo ha
permanecido inactivo. Este tiempo es configurable por la red. Si tras ese tiempo
la red no recibe los datos de un dispositivo, supone que ha abandonado su zona
de cobertura y sus datos se borran de la red.
La mayoría de las redes GSM son diseñadas e implementadas de forma jerárquica,
siguiendo una estructura similar a la mostrada en la figura 3.9.
Figura 3.9 – Estructura jerárquica de una red GSM
Proyecto Fin de Carrera. Ingeniería Informática
49
El cambio de una célula a otra es más sencillo si los BTS son controlados por el mismo
BSC. El cambio de BSC es más complejo y necesitará más intercambio de información,
pero será menos frecuente.
LA (Location Area), es un grupo de células vecinas controladas por un MSC. Un MSC
puede controlar varias LAs.
3.2.7. Interfaz aéreo GSM
Existe un espectro limitado de frecuencias que están disponibles para GSM. El espectro
electromagnético disponible ha sido partido en distintas bandas por organizaciones
reguladoras internacionales.
Sin embargo, en algunas naciones, se realizaron regulaciones del espectro antes que la
estandarización internacional, provocando que las bandas espectrales utilizadas no sean
exactamente las mismas en todo el mundo.
Afortunadamente, en las bandas de frecuencia de 900 MHz y 1800 MHz, hubo un
acuerdo internacional, y aunque GSM originalmente fue diseñada para trabajar en la
banda de 900 MHz, es utilizada en 1800 MHz, 1900 MHz y algunas otras (como 450
MHz).
El rango de los 900 MHz está compuesto por dos bandas de 25 MHz, entre 890-915
MHz y 935-960 MHz. La banda más baja es utilizada por las transmisiones de los
dispositivos móviles (uplink), y la banda mas alta es usada para las transmisiones de la
estación base (downlink).
Figura 3.10 – Frecuencias de uso en GSM
Movicuo
50
La estación base de GSM, por lo tanto, comienza a transmitir en el 890+45 MHz. Los
dispositivos transmiten en la frecuencia menor ya que una propiedad física de las ondas
electromagnéticas dice que la atenuación será menor a frecuencias mas bajas.
La estación base puede emitir en frecuencias más altas dadas sus características, ya que
no tiene tantas limitaciones como los dispositivos móviles, en aspectos como por
ejemplo la batería.
GSM, por tanto, trabaja en combinación de varias tecnologías de acceso como SDMA
(Space Division Multiple Access), FDMA (Frequency Division Multiple Access) y
TDMA (Time Division Multiple Access). También utiliza Aloha ranurado, de forma
similar a cómo se hace en Ethernet. Este mecanismo es necesario ya que existe la
posibilidad de que dos móviles necesiten recursos al mismo tiempo. El dispositivo
utiliza este método, compitiendo con el resto, para conseguir un canal, que es necesario
para una llamada. De la misma forma que en Ethernet, existe la posibilidad de que
ocurran colisiones, por lo que se implementan mecanismos que tengan en cuenta esta
posibilidad.
La multiplexación en frecuencia (FDM) da a cada canal GSM 200 kHz de ancho de
banda y por lo tanto hay 25MHz/200kHz=125 canales disponibles en cada dirección.
Uno de esos canales no es usado para transmisión de datos, sino como una banda de
guarda, dejando 124 canales para la comunicación. La unión de un par de canales GSM,
uno de subida y su correspondiente de bajada, son controlados por un transceptor
(TRX).
La multiplexación en el tiempo (TDM) divide cada una de esos canales de frecuencia en
ocho time-slots, cada uno de los cuales puede ser asignado a un usuario o ser utilizado
para control.
El primer TRX de cada célula tendrá reservado el slot 0 para operaciones de broadcast y
control, por lo tanto podrá dar servicio como máximo a siete usuarios.
Un ejemplo de su uso puede observarse en las figura 3.11.
Proyecto Fin de Carrera. Ingeniería Informática
51
Figura 3.11 – Time-slots de la trama TDM
En la figura anterior, se puede ver como la transmisión por la estación base está
retardada en tres slots, por lo que los TRXs no tendrán que escuchar mientras
transmiten. Si el dispositivo transmite en el slot 1, también recibirá datos por en el slot
1.
La red selecciona la banda (si existe más de una opción, por ejemplo, 900MHz o
1800MHz), la frecuencia, y el time-slot que se usarán. Esta selección será transparente
al usuario, de hecho, la frecuencia y el time-slot, podrán cambiar durante la llamada, y
el usuario probablemente no se de cuenta, o escuche una pequeña interferencia.
En el roaming, la capacidad de cambiar de frecuencias a un cliente será necesaria, ya
que cuando cambie de una célula a otra vecina, no usará la misma frecuencia.
La estructura de la trama de ocho time-slots explicada anteriormente, son en realidad
parte de una multitrama mucho más larga. Hay dos tipos de multitrama: El tráfico
multitrama y el control multitrama. El primero de ellos consiste en 26 grupos de tramas
TDM, mientras que el segundo está compuesto de 51 grupos.
Canal de tráfico multitrama
La figura 3.10 muestra una multitrama GSM. Aunque esté formado por 26 tramas, sólo
24 de ellas se usarán para tráfico, ya que habrá dos de control. Los slots 12 y 25 estarán
dedicados para los canales SACCH y FACCH.
Movicuo
52
Figura 3.10 – Multi-Trama GSM
Cada uno de los ocho time slots de la trama TDM está formado por 148 bits, que en
total dura 547µs. La estructura de una de estas ráfagas de datos GSM se puede ver en la
figura 3.11.
Figura 3.12 – Ráfaga de datos GSM (Trama)
Cada time slot y la banda de guarda ocupan 156,25 bits y llevan 577 µs. La banda de
guarda es un como intervalo de tiempo (30 µs aproximadamente), en los que se podrían
mandar 8.25 bits.
En cada time-slot de 148 bits hay 3 bits al comienzo y otros 3 al final que son siempre
cero y sirven para delimitar el inicio y el final de la trama. F1 indica si los datos son de
control o del usuario. Si fuera necesario realizar un handover, la trama llevaría datos de
control. El campo etiquetado como Sincronización es el campo TSC, utilizado para
sincronizar al transmisor y al receptor, de forma que se controlen las posibles
distorsiones de la señal.
Así, los canales tanto de tráfico como de control que se pueden tener son:
Proyecto Fin de Carrera. Ingeniería Informática
53
• Canales de tráfico (TCH)
o TCH/F (Full rate): 13 Kb/s para voz y 9.6, 4.8, 2.4 para datos.
o TCH/H (Half rate): 6.5 Kb/s para voz y 4.8, 2.4 para datos.
• Canales de control (CCH)
o Common Control Channels (CCCH)
Paging Channel (PCH): Usado por la red para paginación de la
MS al finalizar la llamada.
Access Grant Channel (AGCH): Usado por la red para indicar
asignación del enlace de radio.
Random Access Channel (RACH): Acceso inicial a la red.
o Dedicated Control Channels (DCCH)
Standalone Dedicated Control Channel (SDCCH): Usado para
señalización y mensajes cortos SMS.
Slow Associated Control Channel (SACCH): Señalización no
crítica en el tiempo.
Fast Associated Control Channel (FACCH): Señalización crítica
en el tiempo.
Cell Broadcast Channel (CBCH): Mensajes SMS de broadcast.
Solo downlink.
o Canales de Broadcast (BCH)
Frecuency Correction Channel (FCCH) y Synchronization
Channel (SCH): Sirven para sincronizar la MS con la BSS.
Broadcast Control Channel (BCCH): Tiene varias funciones,
entre las más importantes están, dar información de acceso para
la celda actual, dar información de las celdas vecinas y permitir el
procedimiento de registro de la MS.
3.2.8. Conexión inicial
Cuando un terminal móvil se enciende, intentará registrarse en la red. La red a la que
esté suscrito el cliente estará almacenada en la SIM, y será la primera en comprobarse.
Movicuo
54
Si esta red está disponible, el móvil realizará una petición de conexión. En el caso
contrario, el dispositivo intentará unirse a la última red a la que se conectó antes de ser
apagado. Esta información también está almacenada en la SIM.
Si ninguna de las redes anteriores están disponibles, el móvil comenzará a buscar en
todas las frecuencias, intentando encontrar una red apropiada.
Durante este proceso de búsqueda, se estará escuchando por si se encuentra una señal
BCCH. Esta señal incluye el FCCH y el SCH. El FCCH simplemente emite una onda
senoidal para permitir la sincronización entre el dispositivo y la estación base. SCH
contiene el identificador de la estación.
El BCCH también da información de la red al dispositivo móvil, como su situación, el
LA en el que se encuentra y la identificación del operador de la red.
El dispositivo intentará unirse a esta red mediante el envío de una petición en el canal
RACH, en el que la estación base está continuamente escuchando para atender las
peticiones de acceso de los móviles. Este es un canal compartido, por lo que podrán
producirse interferencias entre las peticiones de varios dispositivos, provocando que se
descarten dichas peticiones. Después de un tiempo aleatorio se volverá a enviar la
petición.
El acceso inicial a la red se realiza de la siguiente forma:
Cuando la red tiene que buscar a un terminal debido a una llamada, el dispositivo estará
continuamente escuchando del canal de búsqueda o paginación (PCH) tanto para
peticiones como para respuestas de un canal dedicado en el RACH. Una vez que la
petición es recibida por la red, se envía la respuesta en el canal AGCH, la cual indicará
un canal de control dedicado en el que el dispositivo debería utilizar para continuar con
la negociación con la red. Así, se utilizará el canal de control SDCCH, que tiene un bit
rate mucho menor que un canal de tráfico dedicado y por lo tanto es más eficiente para
los envíos de control que necesitan transmitir poca información. El dispositivo puede
ahora continuar con la petición de attach. Toda esta secuencia de intercambio de
mensajes, se observa en la figura 3.13.
Proyecto Fin de Carrera. Ingeniería Informática
55
Figura 3.13 – Acceso inicial por una llamada entrante al móvil
El móvil envía su IMSI al MSC donde será procesado. El MSC conectará con el
HLR/AuC de la red del cliente para autenticar la tarjeta SIM, obteniendo como
respuesta tres valores: un número aleatorio (RAND), una clave (Kc) y un resultado
(SRES). El número aleatorio se envía a la SIM del móvil, el cual utiliza su sistema de
autenticación para producir un resultado (SRES’). Este resultado se envía de vuelta al
MSC, que lo compara con el valor SRES que obtuvo del AuC. Si los resultados son
iguales, la tarjeta SIM es autenticada. La clave es utilizada para encriptar los datos entre
la estación móvil y el BTS.
Una vez que la SIM ha sido autenticada, el MSC pide el IMEI al móvil. Una vez
recibido, se comprueba contra el EIR. Si tanto el IMSI como el IMEI son correctos, el
MSC solicita información del cliente al HLR. El MSC registra el móvil en el VLR, que
será quien vaya informando al HLR de la posición del dispositivo. El MSC también
provee al móvil con un identificador temporal (TMSI) que es utilizado en cualquier
operación realizada posteriormente. El uso del TMSI en lugar del IMSI aporta mayor
seguridad ya que este último no será enviado tantas veces por la el interfaz aéreo.
Movicuo
56
El TMSI está formado por menos dígitos (4 bytes) que el IMSI, lo que incrementa la
eficiencia. El proceso inicial de señalización se completa con este paso.
3.2.9. Llamadas
• Llamadas entrantes: Una llamada entrante se le pasa al Gateway MSC, que se
encarga de averiguar el HLR a partir de un número MSISDN (compuesto por en
número de teléfono + IMSI) y se le solicita información sobre el camino hacia la
MSC/VLR donde estaba el móvil la última vez.
El MSC/VLR busca al móvil a través del canal de paginación, y si este está en la
zona de cobertura, responde al mensaje de paginación y solicita un canal radio.
Por paginación entendemos el proceso de hacer un broadcast de un mensaje que
avisa a un determinado móvil a realizar cierta acción.
La MSC/VLR autentica al móvil y configura el cifrado.
El camino ya se encuentra establecido, y la señal de alarma se activa en el móvil.
• Llamadas salientes: Una llamada saliente comienza por el marcado por parte del
usuario. La MS solicita en ese momento un canal de radio y la MSC/VLR local
autentica a la MS y establece el cifrado del canal de radio.
La llamada se encamina según el número llamado y el MSC/VLR actualiza los
registros de uso y tarificación.
3.2.10. Protocolo de GSM
GSM ha sido diseñado con interfaces abiertos, y con un diagrama simple de protocolos
sobre estos interfaces.
Proyecto Fin de Carrera. Ingeniería Informática
57
Figura 3.14 – Protocolos GSM
Como se observa en la figura 3.14, el interfaz físico (en este caso el aire) consiste en los
time-slots y en las bandas de frecuencia explicadas anteriormente que son denotadas
como TDMA/FDMA. Sobre ellos, aparece la capa de enlace, que es el protocolo de
acceso punto a punto LAPD.
Los mensajes LAPD comienzan y terminan con una bandera de sincronización de 8 bits.
El campo de dirección incluye 3 bits para el SAPI (Service Access Point Identifier).
SAPI 0 es utilizada para llamadas de control, gestión de la movilidad y señalización de
los recursos de radio. SAPI 3 es utilizada para SMSs. Todos los otros valores están
reservados para uso futuro. Esta capa de enlace también permite asignar tres niveles de
prioridad a los mensajes que son transferidos mediante SAPI0. Esta prioridad es
generalmente dada por los mensajes RR (Radio Resource management) sobre MM y
CM
Movicuo
58
La capa RR es utilizada para establecer, mantener y cerrar conexiones RR, que permiten
un diálogo punto a punto entre el móvil y la red. Esta conexión es utilizada para datos y
señalizaciones.
La capa MM soporta la movilidad de los dispositivos móviles. Esto incluye informar a
la red de su localización y proveer identificación del usuario. También proporciona
servicios de gestión de la conexión a la capa CM.
La capa CM es dividida en diferentes entidades. Estas incluyen control de llamadas
(CC), soporte para servicios de mensajes cortos (SMS), soporte para servicios
suplementarios (SS) y soporte para servicio de localización (LCS).
Por último, SSCP (Signaling Connection Control Part) proporciona servicios orientados
a conexión y no orientados a conexión, y puede verse como TCP para el protocolo de
Internet. BSSAP (Base Station System Application Part), por su parte, está dividido en
dos subcapas: DTAP (Direct Transfer Application Part) utilizada para transferir los
mensajes entre el MSC y el dispositivo móvil. La otra subcapa de BSSAP es BSSMAP
(BSS Management Application Part), cuyos mensajes son trasferidos entre el BSC y el
MSC para soportar procedimientos como gestión de los recursos, control del handover y
la búsqueda (paginación) del dispositivo móvil.
3.3. GPRS
3.3.1. Introducción
El rápido crecimiento en servicios de voz ha conducido a la alta aceptación por parte del
usuario de la tecnología GSM, vista en el apartado anterior. Sin embargo, ahora el los
clientes demandan servicios que ya no son de voz. La infraestructura existente de GSM
no satisface estas necesidades debido a que GSM funciona mediante conmutación de
circuitos.
Proyecto Fin de Carrera. Ingeniería Informática
59
GPRS es un servicio de datos que permite el envío y recepción de tráfico de paquetes
(normalmente paquetes IPv4 o IPv6) a través de una red móvil. El protocolo punto a
punto (PPP) permite el cambio de protocolos de forma transparente como pueden ser
Appletalk e IPX. Está diseñado para complementar tráfico mediante conmutación de
circuitos y el servicio de mensajes cortos (SMS), además de otros nuevos servicios.
En muchos casos GPRS se ve como un paso en la evolución hacia 3G, considerándolo
como una tecnología de 2.5G. Siempre se le ha conocido como always connected, ya
que tras la conexión inicial, las siguientes que se producen son casi instantáneas y con
un retardo mínimo. Esto contrasta con la forma tradicional de llamada en GSM o de las
líneas de telefonía fija, donde cada vez que una conexión se produce, el retardo es
bastante mayor.
Las especificaciones de GPRS fueron dadas, originalmente, por la organización ETSI (a
partir de 1994), pero finalmente, en el verano de 2000, su estandarización correspondió
al 3GPP (Third Generation Partnership Project)
GPRS trabaja aportando los servicios de una red de conmutación de paquetes sobre la
red existente de GSM. Esto permite al usuario continuar utilizando la red GSM para la
voz pero si se necesita una transferencia de datos, se puede realizar vía GPRS. De esta
manera infraestructura existente se puede reutilizar.
El tráfico de voz seguirá el camino utilizado en GSM, es decir, pasará del BSS a la red
de circuitos conmutados de GSM. El tráfico GPRS será redireccionado, normalmente
dentro del BSC, a una nueva unidad llamada Packet Control Unit (PCU) y pasará por la
red de conmutación de paquetes de GPRS.
Movicuo
60
Figura 3.15 – Estructura de la red
GPRS introduce un núcleo de red basado en la conmutación de paquetes, pero utiliza
gran parte de la funcionalidad de GSM, como el HLR (Home Location Register), EIR
(Equipment Identity Register y el AuC (Authentication Centre). También aporta nuevas
características, como la capacidad para transportar diferente tipo de tráfico de forma
más eficiente para los recursos de la red, y permite introducir una amplia gama de
servicios.
Generalmente, la funcionalidad de las capas más altas no necesita ser cambiada y puede
ser reutilizada.
La red estará diseñada para soportar diferentes clases de calidad de servicio (QoS), que
son implementadas gradualmente a medida que van apareciendo cada una de las
versiones (releases) del estándar.
Una red GPRS puede ser utilizada tanto para GSM como para UMTS, sin embargo,
algunas redes no soportan ambos interfaces (GSM Gb y UMTS Iu) inicialmente, siendo
necesario un cambio en el hardware para la migración a UMTS.
Para GPRS/GSM, el interfaz de radio (el aire) es utilizado de una forma flexible,
teniendo de uno a ocho canales multiplexados en el tiempo (TDM) para tráfico GPRS.
Proyecto Fin de Carrera. Ingeniería Informática
61
Los usuarios activos comparten los slots de tiempo y son colocados de forma
independiente en el uplink o en el downlink, de forma que los recursos son compartidos
entre las conversaciones y los datos.
Enhanced GPRS (EGPRS) es una mejora al sistema, que permite un ratio de
transmisión mayor, debido al uso de diferentes técnicas de modulación y codificación.
El concepto de handover sobre GPRS no es tan crítico como en GSM, ya que el tráfico
no es en tiempo real, y puede ser almacenado temporalmente, hasta que el cambio de
célula se produzca de forma correcta. En este proceso, ahora el MS se involucra más ya
que puede iniciar el cambio de célula, aunque será responsabilidad del SGSN (Serving
GPRS Support Node) el permitir que esto ocurra.
Los métodos de seguridad son similares a los de GSM. El nodo SGSN tendrá la
responsabilidad de la autenticación del cliente y de la encriptación/desencriptación de
los datos.
Un dispositivo móvil con una tarjeta SIM estándar puede conectar a una red GPRS y
usar sus servicios si el operador de red tiene diseñadas e implementadas estas
características.
3.3.2. Problemas de la conmutación de paquetes en comunicaciones móviles.
3.3.2.1. Multitud de accesos de poca duración
La conmutación de paquete se distingue de la conmutación de circuitos en que los
recursos son ocupados cuando se necesitan. Esto también supone que los recursos serán
liberados tan pronto como no sean necesitados. Derivadas de estas situaciones, aparecen
las siguientes cuestiones:
Movicuo
62
• ¿Puede un usuario recibir recursos en la subida o bajada de datos por la
inactividad de otro y sin retardo?
• ¿Pueden existir colisiones de diferentes dispositivos móviles que realizan una
petición de asignación de recursos?
En los siguientes puntos se resuelven estas preguntas.
3.3.2.1.1. Acceso mediante Aloha ranurado
En 1969, un grupo de investigación de la universidad de Hawai instaló una red
inalámbrica para conectar Honolulu con varias islas. El sistema tenía una extensión
aproximada de 322 Km. A esta red se le dio el nombre de Aloha.
La forma de acceder al medio por esta red, dio nombre al método ALOHA, que tiene un
funcionamiento muy simple. Cuando un emisor quiere transmitir una trama,
simplemente la emite, sin preocuparse en ningún momento de si el canal está libre. Una
vez ha terminado se pone a la escucha esperando recibir confirmación de que la
información ha sido recibida correctamente por el destinatario. Si la confirmación no
llega en un tiempo razonable, el emisor supone que ha ocurrido una colisión, en cuyo
caso espera un tiempo aleatorio y reenvía la trama.
La eficiencia de este método es muy baja ya que se basa en el caos. Cuando el grado de
ocupación del canal crece, los envíos de las estaciones empiezan a colisionar unos con
otros hasta el punto de que la red puede llegar a colapsarse, es decir, saturarse sin enviar
información útil. Una colisión se produce tanto si dos emisores coinciden totalmente en
el tiempo como si solo coinciden en un bit, lo cual provoca colisiones “encadenadas” en
las que cada estación se solapa sólo brevemente con la siguiente.
En 1972 se propuso una mejora al protocolo ALOHA que consistía en establecer de
antemano unos intervalos de tiempo de duración constante para la emisión de las
tramas. De alguna manera, las estaciones estarían sincronizadas y todas sabrían cuando
empieza cada intervalo. Esto reduce la probabilidad de colisiones, ya que al menos
limita su efecto a un intervalo (no se pueden encadenar colisiones). A esta versión
Proyecto Fin de Carrera. Ingeniería Informática
63
mejorada de ALOHA se la denomina ALOHA ranurado, porque utiliza tiempo ranurado
o a intervalos. Por contraposición, al ALOHA original con tiempo aleatorio se le suele
llamar ALOHA puro.
Abramson realizó algunas estimaciones de la eficiencia de un sistema Aloha.
Suponiendo que las estaciones de la red transmiten de acuerdo con una distribución de
Poisson dedujo que el rendimiento máximo de un ALOHA puro es del 18,4%, y que
esta eficiencia se consigue con un nivel de utilización del canal del 50%.
Para un ALOHA ranurado Abramson dedujo que la eficiencia máxima es justamente el
doble, del 36,8 % y se consigue con un nivel de utilización del 100%.
Los protocolos ALOHA (y en particular ALOHA ranurado) se utilizan hoy en día en
situaciones donde no es posible o práctico detectar las colisiones, por ejemplo, además
del canal de acceso aleatorio de las redes GSM (o GPRS), otras redes de satélite o, sobre
todo, Ethernet, utilizan esta tecnología como forma de acceso al medio.
3.3.2.1.2. Consecuencias de Aloha ranurado en GPRS
El método Aloha descrito en el apartado anterior es utilizado por la mayoría de sistemas
de comunicaciones móviles como método de acceso. Como se ha explicado, permite
una eficiencia máxima del 36% en el canal de subida, lo que es importante para GSM e
incluso más para GPRS.
Hay que tener en cuenta, en todo caso, que la limitación de eficiencia para GSM y
GPRS es válida para el canal RACH, en el que el móvil envía su ráfaga de acceso a la
estación base para conseguir la correspondiente asignación de recursos.
Para los sistemas de circuitos conmutados como GSM, esta limitación no es un
problema principal. Todos los recursos son asignados para un largo periodo de tiempo
(normalmente varios minutos).
Movicuo
64
Sin embargo, para GPRS, en la que la ocupación se produce en fracciones de segundo,
es posible que haya que enviar una nueva ráfaga de acceso para cada una de esas
ocupaciones. La carga del canal RACH sube muy rápidamente y se llega al 36% con
relativa facilidad. La probabilidad de colisiones, y por tanto de retardo en el acceso se
incrementa de la misma forma. Este problema puede resolverse únicamente,
incrementando el número de RACHs. Por esto, se define para GPRS un canal PRACH
(Packet Random Access Channel), que puede ser configurado en cada célula
dependiendo de la carga.
3.3.2.1.3. Ocupación inmediata y liberación de recursos
Ya se indicó anteriormente que el dispositivo móvil y la red deben ser capaces de
solicitar y asignar recursos de forma inmediata. De otra forma, las aplicaciones que son
sensibles a los retardos pueden tener problemas en el acceso.
Esta necesidad se aplica de la misma forma a la liberación de recursos, ya que si no, el
siguiente usuario no sería capaz de adquirir el acceso suficientemente rápido.
Por tanto, las redes de conmutación de paquetes deben tener cuidado con algunos
mecanismos complejos para la autenticación de un cliente o para la activación de la
conexión. Los mecanismos de encriptación o se eliminan, o bien no se ejecutan en cada
nueva ocupación de los recursos.
3.3.3. Arquitectura GPRS
La siguiente imagen 3.16 se muestra la arquitectura general de una red GPRS y su
relación con otras redes IP como Internet:
Proyecto Fin de Carrera. Ingeniería Informática
65
Figura 3.16 – Arquitectura de la red GPRS
Como se puede ver, la red hace uso de la infraestructura de GSM. El HLR, AuC y EIR
necesitarán pequeñas modificaciones para soportar GPRS, y normalmente ese cambio
consistirá en una actualización de software. En la estructura de red de la figura se
observa como dentro del backbone GPRS se utiliza un switch Ethernet para conectar sus
componentes.
El estándar GPRS no especifica la tecnología a utilizar en el Nivel 2 para interconectar
el backbone IP, por lo que la mayoría de las redes actuales utilizan Ethernet para
implementar este backbone local, ya que es una tecnología suficientemente probada y
de un coste muy eficiente. El fallo del switch Ethernet provocaría el fallo de toda la red,
por lo que es normal encontrar en este punto redundancia en los enlaces para
proporcionar fiabilidad.
Los componentes de una red GPRS que son nuevos con respecto a la red GSM se
describen en los apartados siguientes.
Movicuo
66
3.3.3.1. GGSN (Gateway GPRS Support Node)
El GGSN proporciona la pasarela para las redes externas, gestionando la seguridad y las
funciones de contabilidad, así como la asignación dinámica de direcciones IP. Desde el
punto de vista de las redes externas IP, el GGSN es un servidor que posee las
direcciones IP de todos los abonados a los que presta servicio la red GPRS. Los nodos
estarán interconectados por una red troncal IP.
3.3.3.2. SGSN (Serving GPRS Support Node)
El SGSN ofrece encaminamiento de paquetes, incluyendo gestión de la movilidad,
autenticación y cifrado entre todos los abonados GPRS que se encuentren en el área de
servicio SGSN. Cualquier SGSN de la red puede prestar servicio a un abonado GPRS,
dependiendo de donde éste se halle. El tráfico se dirige desde el SGSN al Controlador
de la Estación Base (BSC) y al terminal móvil mediante la Estación Transceptora Base
(BTS).
3.3.3.3. CG (Charging Gateway)
En las especificaciones no se indica que se requiera, pero generalmente se implementa.
Aporta un enlace lógico al sistema de facturación del operador y reduce el número de
enlaces físicos y conexiones necesarias, ya que de otra forma, sería necesaria una
conexión separada a cada uno de los GSNs.
3.3.3.4. LIG (Lawful Interception Gateway)
Es un requisito en muchos países, para poder monitorizar el tráfico. Este es el objetivo
del LIG. Cuando el tráfico de un usuario pasa por el backbone GPRS, es posible
capturarlo y almacenarlo. Para realizar esta interceptación de los datos del usuario,
normalmente será necesaria una orden judicial.
Proyecto Fin de Carrera. Ingeniería Informática
67
3.3.3.5. DNS
En la mayoría de los casos, cuando un abonado necesite realizar una conexión vía
GPRS a una red externa, será necesario seleccionar el nombre del punto de acceso
(APN) de una lista en el dispositivo móvil. Se requiere un Domain Name System (DNS)
de modo que el SGSN pueda hacer una consulta para convertir el APN a la dirección IP
del GGSN correcto.
3.3.4. Interfaces de red GPRS
GPRS introduce nuevas definiciones de interfaces. Estos son estándares abiertos
descritos por 3GPP. Permiten que redes de distintas compañías sean construidas sin
apenas modificaciones. Como GPRS utiliza gran parte de la red GSM, es necesario que
existan interfaces entre los componentes de ambas tecnologías.
Figura 3.17 – Interfaces entre los elementos de GSM y GPRS
Los distintos interfaces que puede haber en una red GPRS se muestran en la figura 3.17
y son:
Movicuo
68
• Ga: Es utilizado para transferir registros de carga, más conocidos como CDR
(Call Detail Records) desde el SGSN y el GGSN a un CG.
• Gb: Este interfaz se encuentra entre el SGSN y el BSS. Su función es la de
transportar tanto tráfico de datos como de control. Está basado normalmente en
Frame Relay.
• Gc: Este interfaz aparece entre el GGSN y el HLR, y proporciona al GGSN el
acceso a la información del cliente. El protocolo utilizado es MAP y el interfaz
se usa únicamente para control. Este es un interfaz opcional.
• Gd: Este interfaz conecta el SGSN a una pasarela de SMS, lo que permite que
SGSN soporte el servicio de mensajes SMS.
• Gf: El interfaz Gf conecta el SGSN al EIR y permite que el SGSN compruebe el
estado de un dispositivo móvil concreto.
• Gi: Este es un punto de referencia más que un interfaz entre el GGSN y otra red
externa. Actualmente GPRS soporta IPv4, IPv6 y PPP, y Gi tiene que ser capaz
de entender estos protocolos para un acceso concreto. Por ejemplo, el punto de
acceso puede pedir transportar paquetes IPv4. Las capas inferiores de la red no
son especificadas, por lo que puede ser Ethernet, ATM, MPLS, Frame Relay o
cualquier otro protocolo de transporte.
• Gn: Este interfaz se encuentra entre los GSNs. Consiste de una pila de
protocolos que incluyen IP y GTP (GPRS Tunnelling Protocol). GTP también es
utilizado entre dos SGSN, y entre un SGSN y un GGSN de otro operador.
• Gp: Tiene una funcionalidad similar a la del interfaz Gn, y también se basa en el
protocolo GTP. Es necesario cuando el SGSN y el GGSN están en redes de
distintos operadores. Aporta funciones de seguridad y enrutado al interfaz Gn.
• Gr: Está entre el SGSN y el HLR, proporcionando al SGSN el acceso a la
información del cliente. El SGSN y el HLR pueden estar en distintas redes si el
usuario está usando el servicio de roaming. El protocolo utilizado es MAP y el
interfaz se utiliza para mensajes de control.
• Gs: Este es otro interfaz opcional. Es utilizado para control entre el SGSN y el
VLR, que es normalmente situado con el MSC y un SGSN. Utiliza el protocolo
BSSAP+ (BSS Application Part Plus), un subconjunto del protocolo BSSAP
para permitir el control entre el SGSN y el MSC/VLR.
Proyecto Fin de Carrera. Ingeniería Informática
69
Además de los interfaces descritos, hay otros dos relevantes que van a través del aire,
tanto para GPRS como para UMTS, y son los siguientes:
• Um: Este es interfaz aéreo de GSM modificado entre el dispositivo móvil y la
red fija que proporciona el servicio GPRS.
• Uu: Este es el interfaz aéreo de UMTS entre el terminal móvil la red fija que
proporciona el servicio GPRS.
3.3.5. Interfaz aéreo de GPRS
Cuando un operador ofrece GPRS, éste tendrá que convivir con GSM, por lo que el
ancho de banda que se tiene debe ser compartido entre los servicios de una y otra
tecnología. El tráfico GSM y GPRS pueden compartir la misma trama TDM, aunque no
pueden compartir la misma ráfaga (time-slot). GPRS utiliza la misma técnica de
modulación que GSM, Gaussian Minimum Shift Keying (GMSK). Al igual que en
GSM, hay 114 bits disponibles en una ráfaga para los datos del usuario. Sin embargo, la
estructura de multitrama GSM, que consiste en 26 canales de tráfico (TCH) o 51 de
control, ha sido reemplazada por un formato de 52 tramas. La figura 3.18 muestra
gráficamente esta nueva estructura.
Figura 3.18 – Formato de las 52 tramas
La nueva multitrama consiste en 12 bloques de 4 tramas consecutivas, además de dos
tramas I (idle) y otras dos T que son usadas para el canal de control del timing advance
Movicuo
70
del paquete (PTCCH). El tiempo dedicado a las tramas I y al PTCCH pueden ser usados
por el dispositivo móvil para medidas de la señal.
En GSM, un time-slot es dedicado a un solo usuario al mismo tiempo, sin embargo, el
sistema utilizado en GPRS es diferente ya que cada bloque de 114x4=456 bits puede ser
usado por distintos usuarios, que en principio, compartirán los recursos de un mismo
time-slot. Estos bloques son un tipo de TDM dentro de su propia trama TDM. A un
dispositivo se le asigna este bloque cuando tenga la necesidad de transmitir datos.
Al compartir los recursos del interfaz aéreo entre GSM y GPRS, GPRS utiliza el ancho
de banda sobrante de GSM. A menos que un time-slot esté reservado exclusivamente
para GPRS, GSM tendrá prioridad para asignar los recursos. Sin embargo, para GPRS,
los restantes time-slots serán vistos como recursos disponibles que los usuarios de datos
podrán compartir.
Desde el punto de vista del operador de red, esto le permitirá introducir nuevos servicios
que, en principio, utilizarán espacio que de otra forma no sería utilizado. Dedicar time-
slots específicamente a GPRS, incrementaría la posibilidad de bloquear llamadas de los
usuarios GSM. Conforme los servicios que no sean de voz vayan aumentando, los
operadores tendrán que volver a evaluar esta situación y puede que tengan que cambiar
la asignación de recursos.
Figura 3.19 – Tramas TDM en GPRS
Proyecto Fin de Carrera. Ingeniería Informática
71
Por ejemplo, en la figura 3.19, se muestra una trama TDM estándar, con el time slot 0
dedicado al canal de broadcast o a otros canales de control. Los otros siete time slots
están disponibles para los usuarios GSM y GPRS. Supongamos que hay cinco usuarios
GSM y dos GPRS que completan la trama TDM. Si otro usuario de GSM deseara hacer
una llamada, los dos usuarios de GPRS pasarían a ocupar un único time-slot. Si ahora
tres de los usuarios de GSM finalizan su llamada, las dos conexiones de GPRS podrían
utilizar esos slots libres incrementando así su velocidad.
3.3.6. Esquemas de codificación
Al contrario que la voz, los datos son muy intolerantes a los errores, lo que supone un
problema ya que el interfaz aéreo introduce un número significante de errores. Para
proteger a los datos, es necesario transmitir algún código que permita comprobar y en
algún caso corregir los errores. Para GPRS se han especificado cuatro nuevos esquemas
de codificación (CS-1, CS-2, CS-3 y CS-4).
Esquema de
codificación
Bit rate
(kbps)
Bit rate - datos de
usuario (kbps)
CS-1 9’05 8
CS-2 13’4 12
CS-3 15’6 14’4
CS-4 21’4 20
En la tabla anterior se muestra cada uno de los cuatro esquemas con dos valores
asociados a cada uno de ellos, el primero es el bit rate, que incluye las cabeceras
RLC/MAC, mientras que el segundo valor es la velocidad para los datos de usuario.
CS-1 da la velocidad más baja, pero la protección más alta tanto de protección como de
corrección de los errores. CS-4 por el contrario da la velocidad más alta a costa de una
menor protección de los datos y no corrige errores.
Movicuo
72
Durante una llamada, la red puede cambiar dinámicamente la codificación utilizada
dependiendo de las propiedades de la conexión, como número de errores,
retransmisiones, etc.…, y será transparente para el usuario.
3.3.7. Tipos de terminales
Los dispositivos móviles GPRS pueden ser clasificados en las tres siguientes categorías:
• Tipo A: Permite el uso simultáneo de GSM y GPRS. En esta clase GSM tendrá 1
time-slot y GPRS tendrá 1 ó más. Por ejemplo, esto podría permitir a un cliente
estar hablando por el teléfono mientras descarga un e-mail.
• Tipo B: Puede estar conectado a GSM y GPRS, pero uno de los dos está en
suspenso mientras el otro está activo. Habrá degradación del servicio para
GPRS. Por ejemplo, un cliente que esté descargando datos puede ser notificado
de una llamada entrante y podría decidir si aceptarla o no, lo que pondría la
transferencia de datos en espera.
• Tipo C: No se permitirá un uso simultaneo de ambas tecnologías, por lo que
habrá que decidir si activar GSM o GPRS.
Actualmente, y dada la complejidad de implementación, para sistemas de segunda
generación, tan solo están disponibles los tipos B y C, y parece que esto no cambiará en
un futuro próximo.
Las clases de los dispositivos definen la velocidad máxima a la que puede enviar o
recibir datos un terminal GPRS.
Clase Bajada Subida Num. Máx de Slots
1 1 1 2
2 2 1 3
3 2 2 3
4 3 1 4
5 2 2 4
Proyecto Fin de Carrera. Ingeniería Informática
73
6 3 2 4
7 3 3 5
8 4 1 5
9 3 2 5
10 4 2 5
11 4 3 5
12 4 4 5
13 3 3 Sin límite
14 4 4 Sin límite
15 5 5 Sin límite
16 6 6 Sin límite
17 7 7 Sin límite
18 8 8 Sin límite
19 6 2 Sin límite
20 6 3 Sin límite
21 6 4 Sin límite
22 6 4 Sin límite
23 6 6 Sin límite
24 8 2 Sin límite
25 8 3 Sin límite
26 8 4 Sin límite
27 8 4 Sin límite
28 8 6 Sin límite
29 8 8 Sin límite
Como se ve en la tabla, hay 29 clases de dispositivos GPRS, cada uno de ellos, tendrá
una combinación de time-slots que podrá utilizar. Así, un dispositivo tendrá un límite en
los slots que puede utilizar tanto en el envío como en la recepción de datos. También
existe un límite al máximo de slots utilizados. Por ejemplo, un dispositivo de clase 6
permite el uso de tres time slots en la bajada y dos en la subida. Además, como máximo,
permitirá el uso de cuatro time slots, por lo que un usuario que tenga asignado tres slots
para la bajada, tan sólo podrá utilizar uno para la subida.
Movicuo
74
3.3.8. Protocolos GPRS
Al igual que otros muchos protocolos de comunicaciones, GPRS está basado en una pila
de niveles que proporcionan las funciones necesarias para la comunicación con otras
capas a través de primitivas.
En GPRS se distinguen dos tipos de protocolos, llamados plano de control (puede
también encontrarse en la bibliografía como plano de señalización) y plano de usuario
(también se le conoce como plano de transmisión).
El protocolo del plano de control es utilizado dentro de una red GSM entre el BSS y el
SGSN. Existe una pequeña diferencia entre este protocolo y el de plano de usuario, ya
que este último tiene una capa adicional sobre el nivel LLC (Logical Link Control) entre
el MS y el SGSN. Esta capa es SNDCP (SubNetwork Dependent Convergence
Protocol). Las figuras 3.20 y 3.21 muestran los protocolos de plano de control y de
plano de usuario.
Plano de control
Figura 3.20 – Plano de control GSM/GPRS
Proyecto Fin de Carrera. Ingeniería Informática
75
Plano de usuario
Figura 3.21 – Plano de usuario GSM/GPRS
Tanto el plano de control como el de usuario, utilizan GTP (GPRS Tunneling protocol)
entre el SGSN y el GGSN, con la diferencia de que el primer plano usa GTP-C,
mientras que el segundo utiliza GTP-U.
A continuación aparece la figura 3.22, en la que se muestran 1500 bytes de carga útil, y
como al pasar por la pila de protocolos se le va añadiendo otra información. Los datos
serán enviados finalmente en los 456 bits disponibles dentro de un bloque a través del
interfaz aéreo.
Movicuo
76
Figura 3.22 – Fragmentación de los paquetes para la transmisión
Cada bloque está formado por cuatro tramas TDMA, cada una de las cuales tiene 114
bits para información. Los bits utilizados para la transferencia de los datos de los
usuarios y para la detección y corrección de errores, depende del esquema de
codificación utilizado.
3.3.8.1. Canales físicos y lógicos
La información de la capacidad de la red para llegar a un acuerdo con los clientes GPRS
es emitida en el canal de broadcast GSM (BCCH). GPRS aporta varios canales de
control al interfaz aéreo, alguno de ellos, son obligatorios, y otros opcionales. Cuando
se introduce un nuevo canal, la forma de nombrarlo es poner una P delante del nombre
del antiguo canal (si existía). Por ejemplo, el canal BCCH ahora es PBCCH.
Cada uno de estos canales es transferido a través de un canal PDCH. Este se equipara a
un canal físico que se toma del total de recursos GSM y GPRS.
Proyecto Fin de Carrera. Ingeniería Informática
77
3.3.8.1.1. BCCH (Broadcast and Control Channel)
El canal de broadcast y control transmite información general desde la estación base a
todos los dispositivos móviles de la célula. Una parte de esa información indica si
GPRS está soportado o no en esa célula concreta. Si GPRS está soportado y el canal
PBCCH está configurado, la posición de este canal está indicada también en el BCCH.
El PBCCH es entonces utilizado para transmitir información a los dispositivos en las
operaciones de transmisión. Si GPRS está soportado pero el canal PBCCH no existe, la
información será transmitida en el BCCH.
3.3.8.1.2. CCCH (Common Control Channel)
Este es un canal GSM, pero puede ser utilizado en GSM si PCCCH no existe. El CCCH
está formado por los siguientes canales:
• Canal de paginación (PCH): Un canal de bajada utilizado para buscar (paginar) a
los dispositivos.
• Canal de acceso aleatorio (RACH): Canal de subida utilizado para solicitar un
canal SDCCH.
• Canal de acceso concedido (AGCH): Canal de bajada utilizado para situar el
SDCCH solicitado. También puede albergar a un canal de tráfico (TCH)
directamente.
• Canal de notificación (NCH): Este canal se utiliza para realizar determinados
avisos a los móviles.
3.3.8.1.3. PCCCH (Packet Common Control Channel)
Este es un canal opcional que es transportado en un canal PDCH. Si este no aparece,
entonces la información necesaria para el funcionamiento de la conmutación de
paquetes es transmitida en el CCCH. PCCH puede ser implementado si la demanda de
transferencia de los paquetes de datos lo requiere o si hay suficiente capacidad de sobra
Movicuo
78
dentro de la red ya que incrementa la QoS para el acceso de los paquetes. Está formado
por:
• Canal de paginación de paquetes (PPCH): Canal de bajada utilizado para buscar
a los dispositivos antes de la transferencia de paquetes. Esta búsqueda puede ser
utilizada tanto por la conmutación de paquetes como la de circuitos.
• Canal de acceso aleatorio de paquetes (PRACH): Canal de subida utilizado para
solicitar uno o más canales de tráfico (PDTCH).
• Canal de acceso concedido de paquetes (PAGCH): Canal de bajada utilizado
para asignar el canal solicitado PDTCH.
• Canal de notificación de paquetes (PNCH): Canal de bajada utilizado para
realizar avisos concretos.
El tráfico actual GPRS es enviado sobre el canal de tráfico de datos (PDTCH). Este
equivale al recurso disponible que ha sido ofrecido para la transferencia. Puede ser un
único time slot, parte de un time slot o varios time slots hasta un máximo de ocho, todos
ellos deben estar en una sola frecuencia.
El canal de control PACCH está dedicado a un dispositivo particular. Es necesario tanto
en la subida como en la bajada. La información en este canal puede ser: información de
los recursos asignados, información de control de potencia o asentimientos.
3.3.8.2. SNDCP
SNDCP (SubNetwork Dependent Convergence Protocol) es un protocolo utilizado sólo
en el plano de usuario, para indicar un contexto PDP concreto. Un cliente puede tener
varios contextos PDP abiertos y cada uno de ellos esta asociado a esta capa a través de
un identificador NSAPI (network services access point identifier). Las funciones
principales del nivel SNDCP son:
• Proporcionar la multiplexación de PDPs.
Proyecto Fin de Carrera. Ingeniería Informática
79
• Compresión de los datos de usuario (incluyendo la compresión de la cabecera
IP)
• Segmentación de los paquetes de datos que serán pasados a la capa LLC.
LLC establece el tamaño máximo de la unidad de datos de protocolo (PDU) que puede
transportar en un único segmento. Si el paquete de nivel 3 (normalmente IP), llamado
N-PDU, no cabe en este tamaño, entonces será necesario que SNDCP rompa ese
paquete en segmentos más pequeños (SN-PDU) que puedan ser transportados en una
trama LLC y que luego el receptor reensamblará, obteniendo de nuevo la N-PDU.
La capa SNDCP también puede comprimir la cabecera IP según indican los estándares:
• RFC 1144: Es usado para comprimir cabeceras de la trama TCP/IP. Se basa en
el hecho de que muchos parámetros de la cabecera TCP/IP son redundantes una
vez que se ha establecido una conexión virtual TCP entre el dispositivo móvil y
la aplicación. El uso de esta compresión supone que los 40 bytes de la cabecera
TCP/IP puedan reducirse a tan sólo 2 o 3 bytes.
• V.42bis: El estándar de la ITU-T V.42bis, puede ser utilizado en GPRS. Las
cadenas de cualquier longitud pueden ser comprimidas con la ayuda de este
estándar. Se utilizan los árboles de decisión que son construidos a partir de unos
códigos que deben ser conocidos por el compresor y por el descompresor.
Aunque la compresión de los datos reduce el número de los datos transmitidos, su uso
tiene un efecto negativo al incrementar la potencia de procesamiento del MS y el SGSN.
Hay dos formatos de tramas distintos para SNDCP, uno para el modo de transferencia
con asentimiento y otro para el modo de transferencia sin asentimiento. Ambos
formatos se muestran en la figura 3.23:
Movicuo
80
Figura 3.23 – Formato de la trama SNDCP
Cuando se utiliza el modo con asentimiento, SNDCP almacenará los paquetes N-PDU y
los mantiene hasta que los segmentos producidos por dicho N-PDU son asentidos por la
entidad receptora. En el modo sin asentimiento, los paquetes son descartados tan pronto
como los paquetes N-PDU han sido enviados a la capa LLC para su transmisión.
SNDCP pedirá a la capa LLC que envíe los datos con asentimiento utilizando el
formato de trama con asentimiento, y será responsabilidad de LLC asegurar que los
datos lleguen en el orden correcto. Durante esta petición, SNDCP puede hacer la
petición de la QoS, como la clase de precedencia, el throughput de pico y la clase de
retardo en el SGSN así como indicar el throughput de pico del dispositivo móvil. Se
puede establecer también la prioridad que la capa RLC/MAC del dispositivo móvil
utilizará para la transferencia.
Cuando se realice la transferencia utilizando el modo sin asentimiento, los parámetros
de la calidad de servicio tanto en el SGSN como en el dispositivo móvil, incluirán una
clasificación de fiabilidad que indica si la capa LLC debería utilizar el modo protegido o
el modo desprotegido y si la capa RLC/MAC debe utilizar el modo con asentimiento o
sin asentimiento.
La capa LLC puede detectar errores en las tramas y dependiendo de si se está utilizando
el modo protegido o no, se entregará o se descartará la trama errónea.
Los campos de las tramas SNDCP tienen el siguiente significado:
• X (bit de reserva): Se pone a 0 por la entidad emisora y es ignorada por el
receptor.
Proyecto Fin de Carrera. Ingeniería Informática
81
• F (indicador del primer segmento): Este bit tiene el valor 1 si es el primer
segmento formado de una N-PDU. Indica que los campos DCOMP, PCOMP y
Num. N-PDU están incluidos en el paquete. También indica que hay mas
segmentos que le siguen, pero esos segmentos tendrán el valor 0 ya que no son
el primero. Si el campo es 0 también indica que DCOMP, PCOMP y Num. N-
PDU no aparecen.
• T (tipo de SN-PDU): Un 0 indica que es una trama SN-DATA (con asignación)
mientras que un 1 indica que es una trama SN-UNITDATA (sin asignación).
• M: Como una N-PDU puede haber sido dividido en varios SN-PDU, el ultimo
de éstos tiene que indicar que el N-PDU puede ser reensamblado. Un 0 indica
que es el último de la N-PDU, mientras que un 1 indica que no lo es.
• NSAPI: Indica con que contexto PDP está asociado el SN-PDU, ya que varios
contextos PDP pueden compartir el mismo enlace lógico. Los valores pueden
ser:
o 0: Es un mecanismo de escape para futuras extensiones
o 1: Información Point-to-multipoint multicast
o 2-4: Reservados para uso futuro
o 5-15: Valores de NSAPI asignados dinámicamente, que permiten un
máximo de 11 contextos.
• DCOMP (Data compression coding): Este campo aparece tan solo en el primer
segmento, y sus valores son:
o 0: No hay compresión
o 1-14: Este identificador ha sido negociado dinámicamente
o 15: Reservado para extensiones futuras
• PCOMP (Protocol control information compression coding): Este campo
aparece en el primer segmento. Puede tener los siguientes valores:
o 0: No hay compresión
o 1-14: Este identificador ha sido negociado dinámicamente
o 15: Reservado para extensiones futuras
• Num Segmento: Solo es necesario en el modo sin asentimiento, ya que LLC
asegura la entrega ordenada en el modo ACK.
• Num N-PDU – modo ack: Tendrá un valor entre 0 y 255 que indica el número
de la N-PDU.
Movicuo
82
• Num N-PDU – modo no ack: Tendrá un valor entre 0 y 255 que indica el
número de la N-PDU.
3.3.8.3. LLC
LLC (Logical Link Protocol) proporciona un enlace fiable entre el dispositivo móvil y
el nodo SGSN tanto para control como para datos. Acepta campos de información
variable desde 140 bytes hasta un máximo de 1520 bytes de payload y puede transferir
mensajes de control y de datos que pueden estar o no encriptados. Al igual que SNDCP
soporta los modos con acuse de recibo y sin acuse de recibo, además tiene la capacidad
de reordenar tramas que lleguen fuera de orden (cuando se retransmitan tramas que
tuvieran errores). Está diseñado para ser independiente de las capas inferiores, para
permitir distintas opciones.
En el plano de control, LLC transporta mensajes GMM (GPRS Mobility Management),
como la autenticación o el attach, así como información de la sesión (activación del
contexto PDP), además de transportar mensajes SMS a las capas superiores.
En el plano de usuario, las tramas LLC transportan los paquetes SNDCP que contendrán
los datos de usuario (paquetes IP).
Una conexión LLC es identificada por un identificador DLCI (DataLink Connection
Identifier), que estará formado por el identificador del punto de acceso al servicio
(SAPI) y el identificador temporal del enlace lógico (TLLI) del dispositivo móvil.
El SAPI va dentro de la cabecera de la trama LLC y define el SAP del dispositivo móvil
y el SGSN al que está asociado. Sin embargo, el TLLI es utilizado como identificador
único del dispositivo móvil (ya que por razones de seguridad el IMSI no será
transmitido), pero no aparece en la cabecera LLC.
Proyecto Fin de Carrera. Ingeniería Informática
83
Figura 3.24 – Formato de la trama LLC
La capa inferior BSSGP (entre el BSC y el SGSN) y la capa RLC/MAC (entre el móvil
y el BSC), se envían, en distintos momentos, la información TLLI que identifica al
dispositivo móvil de forma única.
3.3.8.3.1. Modo sin asentimiento
En este modo, una entidad puede iniciar transmisiones sin tener establecido una
conexión lógica. LLC no garantiza la entrega ordenada de las tramas y no tendrá ningún
procedimiento de recuperación de errores. Sin embargo, LLC puede detectar errores en
las tramas recibidas, y dependiendo del modo de protección que se esté utilizando para
la transmisión, entregará o descartará las tramas con errores. En el modo protegido, hay
una comprobación CRC de la cabecera y del campo de información. En el modo no
protegido, el CRC comprueba la cabecera y tan sólo los primeros 4 bytes del campo de
información, que corresponde a la máxima longitud de la cabecera PDU de un segmento
SNDCP. Tampoco hay un control de flujo con este tipo de transmisión desprotegida.
3.3.8.3.2. Modo con asentimiento
En este caso, cada entidad emisora es responsable del flujo de datos y de la recuperación
de errores. Para permitir esto, el enlace tiene primero que establecerse, y las tramas
Movicuo
84
serán asentidas en este nivel LLC. Este modo proporciona un servicio fiable de entrega
ordenada.
3.3.8.3.3. Formato de la trama LLC
Ahora se describen los campos de la trama LLC mostrada anteriormente.
• PD (Protocol Discriminator): Este bit se pone a 0 para indicar que es una trama
LLC. Si se pone a 1, la trama será tratada como inválida.
• C/R(Command/Response): Indica si es un comando o una respuesta al comando.
• SAPI: La dirección del servicio de la capa superior, al que esta trama tiene que
ser enviado.
• Campo de control: Hay cuatro tipos.
o Trama de supervisión (S): Estas tramas son utilizadas para realiza las
funciones propias de LLC. Pueden asentir tramas I utilizando el número
de secuencia de la trama recibida y N(R). El bit de petición de
asentimiento (A) es puesto a 1 por el emisor si se quiere un asentimiento,
y se pode a 0 en caso contrario. La trama S es enviada aunque no haya
información a transferir.
o Trama de información confirmada (I): Hay un número de secuencia para
las tramas enviadas, N(S), y para las recibidas, N(R). Cada trama I
también contiene una trama S y algunas veces se le denomina trama I+S.
o Trama de información no confirmada (UI): Se utiliza para enviar
información a las capas superiores que no necesitan confirmación. Una
trama podría perderse sin que las capas superiores se enterasen. La
información puede ir o no encriptada, según indique el campo E. El bit
PM indica que se utiliza el modo protegido y si el CRC controla la
cabecera y el payload o tan sólo la cabecera. Si se pone a 1 este campo,
significa que el payload también está protegido.
o Trama no numerada (U): Proporciona funcionalidad adicional a LLC. No
contiene ningún número de secuencia. El bit P/F (poll/final) será P si es
una trama de comando y será F si es una trama de respuesta. El bit P se
Proyecto Fin de Carrera. Ingeniería Informática
85
pone a 1 para pedir una trama de respuesta del receptor. El bit F se pone
a 1 para indicar que es una respuesta a un comando poll.
3.3.8.4. RLC/MAC
RLC/MAC (Radio Link Control/Media Access Control) tiene como función principal
segmentar paquetes LLC para transferirlos sobre el enlace de radio desde el dispositivo
móvil hasta el BSC, donde estos paquetes serán reensamblados y retransmitidos por el
BSSGP al SGSN. Esto ocurrirá en el uplink, mientras que en el downlink el mecanismo
será similar, donde el BSC recibirá los paquetes LLC de BSSGP y los segmentará en
bloques RLC/MAC para transferirlos al dispositivo móvil. Los bloques que mandará
esta capa podrán ser, al igual que anteriormente, de dos modos, con acuse de recibo o
sin acuse de recibo.
La unidad de control de los paquetes (PCU), que normalmente está situado dentro del
BSC es el responsable de las tareas de la capa RLC/MAC, como la segmentación y el
reensamblado de las tramas LLC.
Este nivel también podrá utilizar el modo con asentimiento o el modo sin asentimiento.
3.3.8.4.1. Flujo de bloques temporal (TBF)
El mecanismo de flujo de los bloques es una conexión física unidireccional para
soportar la transferencia de tramas LLC. Permite que varios dispositivos móviles
compartan un time slot o que se ocupen varios time slots en las dos direcciones. Los
canales de subida y bajada son asignados de forma independiente, permitiendo así la
transferencia asimétrica, lo que es mejor para el tráfico de datos, donde en general, hay
mayor volumen de tráfico en la bajada. A cada dispositivo móvil se le asigna uno o
varios bloques de radio a la vez, y puede haber incluso varios móviles compartiendo el
mismo canal de 9’05 Kbps. Esto puede dar una velocidad muy baja, pero siempre será
suficiente para mantener una conexión TCP/IP fuera del timeout. Al dispositivo se le
asigna el canal, el time slot y el bloque de radio en el que puede transmitir. Hay tres
Movicuo
86
técnicas para realizar esta asignación: la dinámica, la dinámica extendida y la fija. Tanto
la dinámica como la fija, son obligatorias en las redes GPRS, mientras que la dinámica
extendida es opcional.
3.3.8.4.2. Formato de la trama RLC/MAC
Distinguimos entre las tramas de control y las tramas de datos. La trama de datos y sus
campos aparecen en la figura 3.25.
Figura 3.25 – Bloque de datos RLC/MAC
• Tipo de payload: Campo de dos bits que indican si es un bloque de datos (00) o
de control (01). Un valor de 10 en el downlink indica un bloque de control con la
cabecera opcional. El resto de valores están reservados.
• RRBP (Relative reserved block period): Estos dos bits indican un bloque
reservado que el dispositivo móvil puede utilizar para un paquete de
asentimiento de control, o un bloque PACCH
• S/P (Supplementary/polling): Un 0 en este campo indica que el campo RRBP no
es válido, mientras que un 1 indica que sí lo es.
• USF (Uplink Status Flag): Este campo de 3 bits es enviado en todos los bloques
de bajada RLC para indicar la propiedad del siguiente bloque de radio de subida
en el mismo time slot.
• PR (Power Reduction): Campo de 2 bits que indica la reducción del nivel de
potencia del bloque RLC actual, comparado con la potencia del BCCH. Un valor
Proyecto Fin de Carrera. Ingeniería Informática
87
de 0 indica 0-2 dB, un 1 indica 4-6 dB y un 2 indica 8-10 dB menos que el
BCCH. El valor 3 no se utiliza.
• TFI (Temporary flor identity): Es un campo de 5 bits que identifica el TBF al
que pertenece el bloque.
• FBI (Final block indicador): Un bit que indica el último bloque de datos RLC.
Un 0 significa que hay mas bloques, mientras que un 1 significa que este es el
último bloque en este TBF.
• BSN (Block sequence number): Campo de 7 bits que lleva el número de
secuencia del bloque RLC (módulo 128) dentro del TBF.
• E (Extensión): Bit que indica la presencia del byte opcional en la cabecera del
bloque de datos. Un 0 indica que le sigue el byte de extensión.
• LI (Indicador de Longitud): 6 bits que se usan para delimitar las PDUs LLC
dentro de un único bloque de datos RLC.
• M (More): Único bit que, junto con el bit e y el LI, es utilizado para delimitar las
PDUs LLC dentro de un TBF. Identifica si otra PDU LLC sigue a la actual
dentro del mismo bloque de datos RLC.
• CV (Countdown Value): Campo de 4 bits enviado por el dispositivo móvil para
permitir a la red calcular el número de bloques RLC que quedan en el flujo
actual de subida.
• SI (Stall indicator): Bit que indica si la ventana de emisión RLC del dispositivo
móvil puede avanzar o no. Un 0 indica que la ventana no está parada.
• PI (PFI indicator): Bit que indica la presencia del campo opcional PFI. Un 0
significa que no el campo no aparece.
• TI (TLLI indicator): Este campo indica si el campo TLLI aparece o no. Un 0
significa que el TLLI no aparece.
• TLLI (Temporary logical link identifier): Campo de 32 bits opcional.
• PFI (Packet flor identifier): Este campo de 7 bits es asignado por el SGSN y
utilizado por un flujo y un valor de QoS determinado.
• Datos RLC: Aquí aparece el PDU LLC o parte de ellos si ha sido segmentado.
La cantidad de datos transferidos depende de si hay alguna cabecera opcional
RLC y del esquema de codificación utilizado.
Movicuo
88
La trama de control y los campos que se introducen y no aparecen en la trama de datos
son:
Figura 3.26 – Bloque de control RLC/MAC
• RBSN (Reduced block sequence number): Utilizado para indicar el número de
secuencia del bloque de control de bajada RLC.
• RTI (Radio transaction identifier): Campo de 5 bits utilizado para agrupar los
bloques de control de bajada que componen un único mensaje.
• FS (Final segment): Este campo es utilizado en bloques de control de bajada
para indicar el último segmento de un mensaje de control. Un valor de 0 indica
que este no es el último segmento.
• AC (Address control): Único bit que indica la presencia del byte opcional
PR/TFI/D en el bloque de control de bajada. Un 0 significa que este byte no
aparece.
• D (Direction): Bit que dirá si el TBF identificado en el campo TFI del bloque de
control de bajada es de bajada (1) o de subida (0).
• R (Retry): Único bit que dirá si el dispositivo móvil ha enviado el mensaje
channel packet request más de una vez. Un 0 dice que ha sido enviado una vez y
un 1 que ha sido enviado más veces.
3.3.8.5. Protocolo de radio GPRS
Ya se ha indicado anteriormente que el interfaz aéreo es muy poco fiable, y que por
tanto, es necesario añadir bits extra de comprobación y corrección de errores. Estos bits
extra más los datos de usuario deben entrar en el tamaño de transferencia que es de 456
bits. Según se utilice un esquema de codificación u otro, los datos de usuario irán desde
Proyecto Fin de Carrera. Ingeniería Informática
89
181 bits en el caso de CS-1 hasta 428 en el caso de CS-4, aunque la fiabilidad que
proporciona CS-1 es mucho mayor que el resto de esquemas.
3.3.8.6. Nivel 1
El nivel 1 se divide en dos sub-capas distintas, la capa física de radio-frecuencia (RF) y
la capa de enlace física. La capa RF realiza la modulación de los datos que recibe de la
capa de enlace física, y en el receptor demodula la señal. El enlace físico proporciona el
entramado, la codificación de los datos y la detección y corrección de los errores del
medio de transmisión.
3.3.8.7. Protocolo del interfaz Gb
El interfaz “Gb” conecta el BSS con el SGSN y se utiliza para datos y para control. Está
diseñada para permitir la multiplexación de muchos usuarios sobre los mismos recursos
físicos. Estos recursos son asignados a un usuario cuando se envían o reciben datos, en
contraste con lo que ocurría con el interfaz “A” utilizado en las conexiones de circuitos
conmutados, donde un usuario tiene recursos dedicados mientras que dura una llamada,
independientemente de que haya actividad o no.
3.3.8.7.1. Nivel 1 bis
Hay varias configuraciones posibles en el nivel físico, por lo que la conexión se negocia
entre los operadores y las empresas de dispositivos móviles. Las especificaciones
permiten conexiones punto a punto entre el SGSN y el BSS, y frame relay de
intermediaria.
3.3.8.7.2. Frame Relay
El nivel de red según se indica en el estándar GSM08.16, se basa en Frame Relay. Se
establecen circuitos virtuales entre el BSS y el SGSN y las transmisiones de varios
Movicuo
90
usuarios pueden multiplexarse sobre esos circuitos virtuales. En muchos casos, se
espera que haya un enlace directo entre el BSS y el SGSN, sin embargo, frame relay
permitirá una red que haga de intermediaria entre el SGSN y el BSS.
Las conexiones frame relay permitirán distintos tamaños de trama con un máximo de
1600 bytes. La cabecera de frame relay tiene una longitud de 2 bytes. Varios circuitos
virtuales permanentes (PVC) se utilizan entre el SGSN y varios BSS para transportar los
paquetes de datos BSSGP.
3.3.8.7.3. BSSGP
El protocolo BSSGP (Base Station System GPRS Protocol) se sitúa sobre la red frame
relay (normalmente) y es utilizada para transportar tanto mensajes de control como
datos del usuario sobre el interfaz Gb. La función principal de esta capa es proporcionar
la QoS requerida por el usuario. En el uplink, el BSC tomará tramas RLC/MAC del
dispositivo móvil y reensamblará un paquete LLC, que será enviado dentro de un
paquete BSSGP al SGSN. En el downlink, el BSC irá cogiendo las tramas LLC de un
paquete BSSGP, y los segmentará en tantas tramas RLC/MAC como sea necesario para
enviarlo al dispositivo móvil. Para completar esta tarea, el BSC utiliza el TLLI que es
proporcionado por el SGSN y se transporta dentro de la cabecera del paquete BSSGP.
Cada asociación RLC/MAC – BSSGP está enlazada por el TLLI. Además del TLLI, el
SGSN proporciona más información al protocolo BSSGP. Esa información es:
• El número simultáneo de time slots que el dispositivo móvil es capaz de
mantener.
• El perfil de la QoS que define entre otros parámetros, el throughput de pico, la
clase de precedencia y el modo de transferencia que tiene que utilizarse al
transmitir la trama LLC entre el BSC y el dispositivo móvil.
El formato de las tramas BSSGP aparece en la figura 3.27. Los campos que aparecen en
la figura se explican a continuación.
Proyecto Fin de Carrera. Ingeniería Informática
91
Figura 3.27 – Formato de las tramas BSSGP
• Tipo de PDU: Indica el tipo de la PDU y el formato de la trama que le sigue.
• Perfil de QoS: Define el bit rate de pico, si la SDU es de control o de datos, el
tipo de la trama LLC, la clase de precedencia y el modo de transmisión a
utilizar.
• Capacidad de acceso del MS: Define la capacidad de radio del dispositivo móvil.
Este campo es opcional y solo aparece si el SGSN quiere comprobar este
aspecto.
• Tiempo de vida de la PDU: Periodo de tiempo en el que la PDU será válida
dentro del BSS. Este periodo se establece en las capas superiores en el SGSN.
• Identificador de la célula: Este campo es necesario para los servicios de
localización. La PDU de subida incluye el identificador de la célula en la que el
LLC fue recibido.
• LSA (Localizad Service Area): Este es un campo opcional e identifica a un
grupo de células a las que aplicar unas condiciones de acceso concretas.
BSSGP no proporciona corrección de errores al contrario que RLC/MAC, y si se
necesita una retransmisión, esta se realiza entre el móvil y el SGSN a nivel LLC. Esto
es porque, como frame relay, supone que el enlace es fiable.
Movicuo
92
3.3.8.8. GTP
GTP (GPRS Tunneling Protocol) es un protocolo que actúa en el interfaz Gn entre los
elementos SGSN y GGSN.
Figura 3.28 – Interfaz entre el SGSN y el GGSN
En el modelo de capas que aparece en la figura 3.28, el nivel inferior hace referencia al
nivel físico y la capa que está por encima al nivel de enlace. El estándar no define cuales
tienen que ser estas dos capas, así que, según el caso, podremos encontrarnos Ethernet
100baseTX, ATM, Frame Relay, u otro mecanismo de transporte.
El caso normal será que el SGSN y el GGSN estén en el mismo edificio, o incluso en la
misma habitación, por lo tanto, Ethernet será la tecnología más utilizada, dada su alta
velocidad y su sencilla administración. En otros casos en los que el GGSN esté más
alejado del SGSN, la tecnología que se utilice será ATM o incluso MPLS.
Sobre las dos capas inferiores, estarán el nivel de red IP y el nivel de transporte UDP. El
uso de UDP está justificado ya que al ser un protocolo no orientado a la conexión, en el
que no se producirán asentimientos, la velocidad que se alcance será mayor, mientras
que la fiabilidad no será un problema ya que el núcleo de la red GPRS está
sobredimensionado para que no se produzcan situaciones que afecten al rendimiento de
la propia red.
El protocolo GTP está formado por dos sub-protocolos: GTP-C y GTP-U.
Proyecto Fin de Carrera. Ingeniería Informática
93
GTP-C transporta datos de control para la creación, modificación y borrado de los
túneles GTP, mientras que GTP-U transporta los datos del usuario e información de
control. La cabecera para ambos sub-protocolos es de longitud variable, siendo la
mínima 8 bytes.
Figura 3.29 – Cabecera GTP
Los tres bits E, S y PN indican si aparecen o no los campos adicionales en la cabecera.
El campo Versión, como su nombre indica, dice la versión de la cabecera. La versión
actual es la 1 (Release 99), pero hay una versión anterior 0 (Release 97).
PT (Protocol Type) es un bit que indica si el protocolo que se está utilizando es el
estándar GTP o GTP’. El protocolo GTP’ se utiliza en el interfaz Ga para aspectos de
facturación.
E (Extensión) es un bit usado para indicar si aparece o no una extensión de la cabecera.
El bit de secuencia S indica si hay un campo de número de secuencia GTP.
El bit PN (número N-PDU) se utiliza para indicar si hay un número N-PDU.
Movicuo
94
El campo Tipo del Mensaje indica que tipo de mensaje se está transportando en el
paquete (echo request, node alive request, create PDP context request, delete PDP
context request, …)
El campo de longitud indica la extensión del payload en bytes
Finalmente, TEID, identifica sin ambigüedades, los extremos del túnel.
3.3.9. Gestión de la conexión
La conexión inicial para GPRS es similar a la de GSM. La principal diferencia entre las
dos es que para registrarse en la red GPRS, el móvil tendrá que llegar a un acuerdo con
el SGSN en lugar de hacerlo con el MSC. Un dispositivo que puede conectar tanto a la
red GSM como a la red GPRS, normalmente realizará una conexión a la red GSM a
través del MSC, seguido de una conexión a la red GPRS a través del SGSN. Esto hace
que el dispositivo sea autenticado dos veces y que las respuestas al HLR también se
hagan por duplicado. Por lo tanto, por el interfaz aéreo se duplicarán las peticiones de
conexión, lo que puede suponer un problema si consideremos que es un recurso escaso
que normalmente será el principal cuello de botella. El estándar GPRS permite un
interfaz opcional entre el MSC y el SGSN, que llamaremos Gs. Si una red permite esta
posibilidad, entonces sólo será necesaria una única petición de acceso. Con esta opción,
el dispositivo móvil se registra contra el SGSN, que autentica la SIM y comprueba el
estado del dispositivo móvil. El HLR es actualizado con los datos del SGSN que está
sirviendo al móvil para las conexiones GPRS. Utilizando el interfaz Gs, el SGSN puede
actualizar el MSC/VLR con la situación del terminal e indicar que la autenticación se ha
completado. El VLR puede actualizar el HLR que está sirviendo al dispositivo para las
llamadas GSM. Este método reduce la cantidad de señalización que se envía a través del
interfaz aéreo. Un móvil sabe que una célula tiene el servicio GPRS y que puede
contactar con el SGSN en lugar de con el MSC ya que lo indica el canal de broadcast de
la célula (PBCCH).
Proyecto Fin de Carrera. Ingeniería Informática
95
3.3.9.1. Gestión de la movilidad GPRS
En los sistemas de segunda generación, la gestión de la movilidad ha sido realizada por
el núcleo de red. La situación del dispositivo móvil es conocida dentro del MSC/VLR
para los que están conectados por conmutación de circuitos, y en el SGSN para los que
están conectados por conmutación de paquetes. Para la red de conmutación de paquetes,
GPRS introduce una nueva entidad de localización, conocida como RA (Routing Area).
Cualquier actualización desde el dispositivo móvil del LA (circuitos conmutados) o RA
(conmutación de paquetes), pasa desde el BSS al núcleo de red, para ser almacenado en
el dispositivo correcto (MSC o SGSN). De esta forma, la paginación (o búsqueda) para
un dispositivo móvil se logra, en primer lugar, encontrando el MSC/VLR o SGSN
correcto, según corresponda. Éstos conocerán la situación de un dispositivo móvil en
una célula concreta o en un número de células (LA o RA) dependiendo del estado en el
que se encuentra el dispositivo. Esto puede ocasionar gran cantidad de tráfico de
señalización.
Figura 3.30 – Distintas localizaciones de la red GPRS
Un RA es un subconjunto de un LA y es definido dentro del SGSN y no del MSC. Un
RA puede tener el mismo tamaño que un LA pero no puede ser mayor.
Movicuo
96
Hay tres estados básicos en los que puede encontrarse un dispositivo GPRS: parado, en
espera y preparado.
Figura 3.31 – Estados en la gestión de la movilidad
ESTADO PARADO
En este estado, el dispositivo no está conectado a la red y por lo tanto, la red mantiene
información de localización inválida para él. El desconocimiento de la situación del
móvil hace que no pueda ser encontrado para la paginación (o búsqueda). El dispositivo
debe realizar un attach para ser registrado dentro de la red. Esto haría que el dispositivo
Proyecto Fin de Carrera. Ingeniería Informática
97
pasara del estado parado al estado preparado. Normalmente este paso se realiza
automáticamente al encender el móvil.
ESTADO PREPARADO
En este estado, la situación del dispositivo es conocida con exactitud. Cada vez que el
dispositivo cambie de célula, actualiza la red con su nueva situación. Si hay un contexto
PDP adecuado, se podrá transferir información a través de la red GPRS. El móvil
permanecerá en este estado mientras que haya transferencia de paquetes. Si no hay
transmisión durante un periodo de tiempo determinado, se pasa al estado en espera. Este
tiempo es establecido por el operador, aunque las especificaciones dan un valor por
defecto de 44 segundos. Cuando el dispositivo se enciende, pasará del estado parado al
estado preparado. Si no se activa un contexto PDP dentro del tiempo permitido, se pasa
al estado en espera. También será posible pasar del estado en espera al estado parado
cuando otro temporizador expire. Este tiempo es establecido también por el operador,
pero de nuevo las especificaciones indican un valor por defecto de 54 minutos.
ESTADO EN ESPERA
En este estado, el gestor de movilidad de la red almacena la situación del dispositivo.
Esta situación es conocida al nivel RA, que normalmente incluye varias células. Tan
sólo con actualizar la red cuando cambia de una RA (Routing Area) a otra, en lugar de
hacerlo al cambiar de célula, el dispositivo envía menos mensajes de señalización,
consiguiendo así un ahorro en la batería.
En este estado, el móvil puede activar o desactivar el contexto PDP. El contexto PDP
será necesario para enviar datos por la red GPRS, sin embargo, la transmisión y
recepción no son posibles hasta que el dispositivo cambie al estado preparado, que
ocurrirá automáticamente cuando se active el contexto PDP.
3.3.9.1.1. Attach
Los pasos a seguir en el proceso de attach a la red GPRS son los que aparecen en la
figura 3.32 y se explican a continuación:
Movicuo
98
1. El dispositivo móvil inicial el proceso con el envío del mensaje AttachRequest al
HLR. Este mensaje incluye, el P-TMSI (o el IMSI si no tiene un P-TMSI
válido), el RAI, el tipo de attach y la clase del dispositivo según sus
posibilidades multislot. RAI (Routing Area Identifier) es un identificador que
viene definido por la siguiente fórmula:
RAI = Código del país + Código de la red + Código del área de localización +
Código del área de enrutamiento.
El tipo de attach indica si es un attach sencillo GPRS o si lo es combinado
(GPRS/IMSI)
2. Las funciones de seguridad pueden ser ejecutadas como se indica para GSM. El
SGSN utilizará el IMSI para preguntar al HLR, obteniendo una tripleta que
estará formada por la clave de cifrado (Kc), un número aleatorio (RAND) y una
respuesta firmada (SRES). RAND se envía al móvil que responderá con un
SRES’. El SGSN compara el SRES que tiene el AuC con el del dispositivo, y si
coinciden, el IMSI será autenticado.
3. El SGSN envía un mensaje update location al HLR, que incluye el identificador
del SGSN y el IMSI del móvil.
4. El HLR envía update subscriber data de vuelta al SGSN en el que aparecen los
datos de suscripción asociados con esa IMSI.
5. El SGSN valida el la presencia del dispositivo en el RA y acepta el mensaje
update subscriber data.
6. El HLR acepta el update location enviado anteriormente por el SGSN.
7. Si el tipo de attach indica combined GPRS IMSI attach, entonces el VLR se
actualiza por el interfaz Gs.
8. El VLR envía un update location al HLR en el que incluye el identificador VLR
y el IMSI del dispositivo móvil.
9. El HLR enviará un mensaje update subscriber data de vuelta al VLR en el que
aparece los datos de suscripción asociados con el IMSI
10. El VLR acepta el mensaje update subscriber data
11. El HLR acepta el mensaje update location enviado por el VLR en el paso
anterior.
12. El VLR responderá al SGSN con el mensaje location update accept que incluye
la identificación VLR y el TMSI del móvil.
Proyecto Fin de Carrera. Ingeniería Informática
99
13. El SGSN devuelve un attach accept al móvil que contiene el P-TMSI y el TMSI
14. El dispositivo asiente la recepción de este mensaje.
Figura 3.32 – Proceso de Attach
3.3.9.2. Gestión de la sesión
Una vez que el dispositivo móvil se ha registrado en la red, no puede comenzar la
transferencia de paquetes hasta que no se establezca una sesión, o un contexto PDP.
Movicuo
100
Como ya se dijo anteriormente, el dispositivo tiene que estar en el estado preparado para
activar un contexto PDP, el cual, una vez activado, permanecerá así incluso si el
dispositivo pasa a estar en estado de espera. Esto permitirá que el abonado mantenga la
misma dirección IP incluso si no genera o recibe tráfico durante un tiempo.
El citado proceso de activación del contexto PDP hace que el móvil obtenga una
dirección IP, que puede ser ofrecida tanto por la red del operador móvil como por una
red externa.
Al realizar una petición de conexión, dicha petición se pasa al SGSN, quien tiene que
encontrar el GGSN adecuado que enrute los datos a la red externa correspondiente. Hay
que tener en cuenta que puede haber varios GGSN conectados a la red externa para
repartir la carga y para dar fiabilidad. Para encontrar el GGSN, el SGSN utilizará un
DNS propio del operador de red, el cual le dará la dirección IP del GGSN donde se sitúa
la conexión correspondiente, a esto también se le llama punto de acceso. Un GGSN
puede tener varios puntos de acceso (conexiones con diferentes redes externas). Una vez
obtenida la dirección IP, el SGSN puede contactar con el GGSN y preguntar por el
contexto PDP concedido para ese usuario.
El contexto PDP asegura que se establece un túnel GPRS entre el SGSN y el GGSN
para el uso exclusivo de ese usuario.
Una vez que se ha activado un contexto PDP, el usuario puede utilizar los servicios
proporcionados por un punto de acceso en particular.
En el caso de Movicuo, tendremos una aplicación software (GNOME-GPRS) que
conectará a un punto de acceso que nos da servicio para el acceso a Internet. Cuando
solicitemos una página web, por ejemplo http://patanegra.unex.es/agila, ocurrirá lo
siguiente:
El servidor web (patanegra.unex.es), responde con la página web y la dirección IP
destino, que para el servidor web es el dispositivo que hizo la petición inicial. Esta
dirección IP será enrutada por Internet hasta el GGSN, que necesita enviarla al SGSN
Proyecto Fin de Carrera. Ingeniería Informática
101
correspondiente para que la entregue finalmente al dispositivo móvil. Esto lo realiza
remitiendo la dirección IP por todos los identificadores de túnel que tiene, entonces
habrá una concordancia con alguno de ellos. El identificador del túnel consta del IMSI
del móvil que es único.
El túnel GPRS ahora envía el paquete IP al SGSN, y cuando llegue será borrado del
túnel GPRS. El SGSN tendrá que resolver la dirección IP con la dirección P-TMSI del
dispositivo móvil. La conexión única que existe entre el SGSN y el terminal es el TLLI
(Temporary Logical Link Identifier), compuesto por el P-TMSI del móvil. El TLLI
identifica de forma única el dispositivo dentro de un RA, y es enviado en todas las
transferencias de paquetes. El SGSN tiene una base de datos de correspondencias P-
TMSI a IMSI que identificará al móvil al que entregar la respuesta.
Figura 3.33 – Transporte de paquetes IP a través de la red GPRS
En la figura 3.33 puede verse todo el recorrido del paquete hasta llegar al móvil. Puede
verse que la cabecera GTP (que contiene el IMSI) es enrutada al SGSN correcto a través
de los protocolos de niveles inferiores. Una vez que el paquete alcanza el SGSN dicha
cabecera GTP es descartada y se añade una cabecera TLL. Es posible que entre el
SGSN y el dispositivo móvil, los paquetes IP puedan ser segmentados en otros más
pequeños y transportados en tramas LLC separadas. El protocolo SNDCP es el que se
encarga de esta segmentación y del reensamblado.
El paquete IP es transportado a la estación móvil utilizando varios paquetes de nivel
LLC. Entre el SGSN y el BSC, LLC puede ser transportado sobre una red frame relay.
En el BSC, los paquetes LLC son extraídos de los paquetes frame relay y son
Movicuo
102
transportados al BTS correspondiente, normalmente sobre slots TDM. El BSC segmenta
las tramas LLC en otras tramas RLC/MAC de menor tamaño. Estas serán transportadas
a través del BTS al dispositivo móvil, donde son reagrupadas para reconstruir la trama
LLC original. Cuando el BTS ha recibido las tramas RLC/MAC, las transmite por el
interfaz aéreo al móvil. Cuando los paquetes LLC llegan a éste, el paquete IP es
reensamblado y procesado por la aplicación.
Ahora vamos a explicar como es el procedimiento de activación de un contexto PDP
por iniciativa del dispositivo móvil:
1. El terminal envía la petición PDP que contiene el NSAPI, el tipo de PDP, la
dirección PDP, el APN, la petición de QoS y otras opciones de configuración
PDP. El NSAPI identifica el punto de acceso al servicio en el móvil, que es
atendido por el contexto PDP específico. El tipo de PDP indica si es una
conexión IP o PPP, y la dirección PDP representa la dirección actual. En el caso
de estar utilizando IP, la dirección PDP será la dirección IP del dispositivo. Si
éste no tiene una dirección estática, este campo será 0.0.0.0, y el GGSN será
quien asigne la dirección IP. El APN es el punto de acceso exterior del operador,
y es un campo de texto. Cada contexto PDP puede tener distintos requerimientos
de calidad de servicio.
2. Una vez que el SGSN ha recibido la solicitud, se realizan las funciones de
seguridad para autenticar al cliente y al dispositivo. El SGSN validará la petición
del cliente contra la información del HLR.
3. El SGSN genera el identificador TEID que está formado por el IMSI y el NSAPI
o un enlace a el, y comprueba si se tienen los recursos disponibles para permitir
la QoS solicitada. El SGSN localiza un GGSN que tenga acceso al access point
y envía el mensaje create PDP context request. Este mensaje está formado del
TEID, MSISDN, modo de selección, tipo de PDP, dirección PDP, APN, QoS
negociada, información de la tarifa y otras opciones de configuración PDP. A
través del HLR se comprueban las características de la tarifa, para establecer la
facturación del cliente en esta conexión. El GGSN creará una nueva entrada en
su tabla de contextos PDP y genera un identificador de tarifa. El GGSN puede
limitar la QoS para esta conexión si no tiene disponible los recursos suficientes.
Proyecto Fin de Carrera. Ingeniería Informática
103
4. El GGSN devuelve un create PDP context response al SGSN en el que irán el
identificador de la tarifa y las modificaciones correspondientes a la QoS.
5. Se ejecuta el proceso de flujo de paquetes BSS para asegurar que los requisitos
de a QoS son conocidos. Todo el flujo de paquetes relacionado con un único
dispositivo móvil, son almacenados en un contexto BSS concreto. Como un
mismo terminal puede tener varios contextos PDP activos, los contextos
individuales son identificados por un flujo de paquetes único asignado por el
SGSN. Hay tres flujos predefinidos: SMS, señalización y best effort. En estos
casos, no es necesario hacer la negociación del contexto de flujo BSS. Tanto los
flujos best effort como el SMS, pueden ser asignados a un contexto PDP y los
paquetes serán transportado en el BSS con la QoS del flujo predefinido. Para
asegurar que se garantiza la QoS, el SGSN divide el retardo de la transferencia
entre el BSS y el núcleo de la red, ya que puede estimar el retardo en el núcleo
de la red hasta el GGSN. El SGSN puede, por tanto, convertir el tamaño máximo
de la SDU, el ratio de error SDU, el ratio de errores residuales, el bit rate
máximo y el bit rate garantizado en el retardo correspondiente para esa
transferencia. El SGSN introduce el NSAPI y la dirección SGSN en su contexto
PDP y elije, en función de la QoS negociada, la prioridad de radio y el
identificador del flujo.
6. Finalmente, se envía el mensaje activate PDP context accept al dispositivo
móvil desde el SGSN, indicando que la petición ha sido aceptada.
El diagrama de activación explicado sigue la estructura que aparece en la figura 3.34
Movicuo
104
Figura 3.34 – Diagrama de activación PDP
También es posible que la petición de activación del contexto PDP le llegue al móvil
desde la red. En este caso, el GGSN conoce la dirección IP del dispositivo, algo que es
muy infrecuente y en el ámbito de Movicuo, y concretamente de GNOME-GPRS, esta
situación no se dará nunca.
La desactivación del contexto PDP también sigue unos pasos que se explican a
continuación:
1. El móvil envía un mensaje deactivate PDP context request al SGSN.
2. El SGSN puede solicitar que se ejecuten funciones de seguridad.
3. El SGSN envía el mensaje delete PDP context request al GGSN indicando el
TEID. El GGSN elimina el contexto definitivamente, dejando la dirección IP
libre para que sea asignada a otro cliente.
4. El GGSN responde con el mensaje delete PDP context response indicando el
TEID que ha sido liberado.
5. El SGSN podrá entonces enviar una respuesta al dispositivo indicando que la
desactivación se ha completado.
Proyecto Fin de Carrera. Ingeniería Informática
105
Figura 3.35 – Diagrama de desactivación PDP
3.3.10. QoS sobre una red GPRS
Para garantizar la QoS puede parecer necesario que existan asentimientos entre SGSN y
GGSN, siendo necesario el uso de TCP en lugar de UDP. Sin embargo esto puede
producir un efecto contrario en la red, bajando el tiempo de respuesta si todos los
paquetes son comprobados en el enlace punto a punto y luego chequeándolos de nuevo
en el enlace extremo a extremo.
Dejar la comprobación de errores a éstas estaciones (extremos), significa que los
paquetes pueden viajar a través de Internet a la otra punta del mundo antes de que los
errores sean encontrados. Cualquier petición de retransmisión disminuirá la
transferencia de datos y no será útil para muchas aplicaciones en tiempo real.
Esta será la forma de funcionamiento normal en la red GPRS, el uso de UDP, ya que la
red se diseña para ser robusta y sobredimensionada. En muchas ocasiones, el equipo
estará situado en el mismo área, incluso en la misma habitación. Construyendo una
infraestructura robusta, se espera que la red sea suficientemente fiable.
Movicuo
106
Cada flujo de datos tiene una QoS asociada, que define los siguientes parámetros:
• Precedencia (o Prioridad)
• Retardo
• Fiabilidad
• Throughput máximo
• Throughput medio
La QoS solicitada durante la activación puede ser modificada por varias situaciones
dentro de la red de acuerdo con los recursos disponibles. La capa RLC/MAC ofrece
cuatro niveles de prioridad para señalizar los mensajes. El dispositivo móvil puede
indicar uno de estos niveles y si la petición de acceso es o para los datos o la
señalización. Esta información es utilizada por el BSS para determinar la prioridad de la
información. El nivel de prioridad para los datos es determinado por el SGSN.
La clase de la precedencia da la prioridad a la señalización y los flujos de datos. Bajo
condiciones de funcionamiento normales la red intentará ofrecer los requisitos pedidos,
sin embargo, bajo situaciones anormales, como la congestión, puede ser necesario
desechar los paquetes.
Los parámetros siguientes pueden ser negociados como parte de la QoS ofrecida:
• Prioridad (o clases de precedencia): Este parámetro es utilizado para dar mayor
flexibilidad a la red. Los paquetes pueden ser marcados con una clase de
precedencia, para indicar si necesitan ser enviados con una prioridad mayor o si
podrían ser descartados cuando fuera necesario (por ejemplo, en situaciones de
congestión). Hay tres posibles valores de la prioridad, alta, normal y baja.
Los paquetes de una red GPRS son almacenados por un pequeño periodo de
tiempo en cada nodo (SGSN, GGSN, …), los cuales tomarán decisiones
continuamente, basándose en la prioridad, de si el paquete será enviado hacia
delante, si será almacenado hasta que los recursos estén disponibles o si será
descartado.
Proyecto Fin de Carrera. Ingeniería Informática
107
• Retardo (Delay): En una red siempre habrá retardo al transportar datos, y como
los paquetes de una misma aplicación pueden ser encaminados por diferentes
caminos, el retardo no será constante, por lo que aparece el concepto de jitter o
variabilidad del retardo.
GPRS permite elegir una de las cuatro clases de retardo que están
implementadas. Los valores especificados son el retardo y el tiempo medio
cuando el 95% de los datos es probable que lleguen. Por lo tanto, el 5% de los
datos no son explícitamente detallados.
Las especificaciones de GPRS se basan en dos tamaños de paquete, 128 y 1024
octetos. El retardo es medido sólo dentro de la red GPRS, ya que no se puede
predecir el retardo en algunas redes externas, como Internet.
Las tres primeras clases de retardo ofrecen garantías de retardo, sin embargo, la
clase 4 no especifica ningún valor, tan sólo ofrece transmisión best effort, y por
lo tanto, depende de la carga de la red.
Valores máximos del retardo
Tamaño SDU: 128 bytes Tamaño SDU: 1024 bytes
Clase de retardo
Retardo medio en
la transferencia
(segundos)
Retardo del
95% (seg.)
Retardo medio en la
transferencia
(segundos)
Retardo del
95% (seg.)
Clase 1 < 0’5 < 1’5 < 2 < 7
Clase 2 < 5 < 25 < 15 < 75
Clase 3 < 50 < 250 < 75 < 375 Clase 4 (best effort) No especificado
• Fiabilidad (Reliability): Este parámetro se define en términos de ratios de error.
Posibles problemas relacionados con este parámetro son los siguientes:
Movicuo
108
o La posibilidad de que una SDU se pierda, por ejemplo, que sea
descartada debido a un error de transmisión.
o La posibilidad de que una SDU sea entregada más de una vez, es decir,
que esté duplicada
o La posibilidad que un conjunto de SDU lleguen en orden erróneo.
o La posibilidad de que un usuario reciba una SDU corrupta sin que el
error sea detectado.
GPRS ofrece soluciones para las distintas necesidades de los clientes,
introduciendo tres clases de fiabilidad, que surgen de las combinaciones de
probabilidades de error basadas en los cuatro puntos comentados anteriormente.
Clase de
fiabilidad
Probabilidad
de pérdida de
la SDU
Probabilidad
de SDU
duplicada
Probabilidad
de SDU fuera
de secuencia
Probabilidad
de SDU
errónea
Características de
las aplicaciones
Clase 1 10-9 10-9 10-9 10-9 Sensible a errores, sin
capacidad de corrección
de errores, y tolerancia a
errores limitada Clase 2 10-4 10-5 10-5 10-6 Sensible a errores,
capacidad de corrección
de errores limitada, y
buena tolerancia a errores
Clase 3 10-2 10-5 10-5 10-2 No sensible a errores, sin
capacidad de corrección
de errores buena y
tolerante a errores
• Throughput: Este parámetro se refiere al ancho de banda, y está dividido en dos,
throughput máximo y medio.
Con respecto al throughput máximo, no se proporciona garantía de que se
alcance ese valor, ya que dependerá tanto de los recursos disponibles de la red y
de la capacidad del dispositivo móvil.
Clase Throughput de
Proyecto Fin de Carrera. Ingeniería Informática
109
pico (kbps)
1 8
2 16
3 32
4 64
5 128
6 256
7 512
8 1024
9 2048
El throughput medio define las siguientes clases (al igual que pasaba con el
retardo, la clase best effort no ofrece datos, ya que serán función de la carga de
la red):
Clase Throughput
medio (bps)
1 Best effort
2 0’22
3 0’44
4 1’11
5 2’2
6 4’4
7 11’1
8 22
9 44
10 111
11 220
12 440
13 1110
14 2200
15 4400
Movicuo
110
16 11100
17 22000
18 44000
19 111000
3.3.11. Ventajas de GPRS
• La máxima velocidad teórica es de 171.2kbps, ésta velocidad se puede alcanzar
utilizando las 8 ranuras de tiempo simultáneamente. Esto es aproximadamente
tres veces más rápido que la transmisión de datos que se utiliza usando la Red
Telefónica de circuitos conmutados, y es 10 veces más rápido que los servicios
de conmutación de circuitos utilizada anteriormente por GSM.
• La conmutación de paquetes significa que los recursos de radio de GPRS son
utilizados únicamente cuando usuarios están enviado o recibiendo datos. Esto en
lugar de dedicarle un canal a un usuario de datos por un determinado período de
tiempo, los usuarios pueden compartirse este canal cuando necesiten enviar o
recibir información. Este uso eficiente de los recursos significa que muchos
usuarios de GPRS pueden potencialmente compartir el mismo ancho de banda y
pueden ser servidos por una sola célula. El número de usuarios que soporta el
sistema depende de la aplicación que se esté utilizando y de la cantidad de datos
que estén siendo transferidos. Gracias a la eficiencia espectral de GPRS, existe
una menor necesidad de aumentar la capacidad del sistema que solo se utilizaría
en horas pico. GPRS le da la libertad al operador de maximizar el uso de sus
recursos en una forma dinámica y flexible. GPRS debe mejorar su capacidad en
horas pico ya que simultáneamente distribuye los recursos de radio, migra datos
que iban por conmutación de circuitos a GPRS, al igual que con los SMS que
migra parte del tráfico a GPRS, por medio de la interconexión de GPRS/SMS
que está especificada en el estándar.
Proyecto Fin de Carrera. Ingeniería Informática
111
3.3.12. Desventajas de GPRS
• Capacidad limitada de la célula para todos los usuarios:
GPRS sí tiene un impacto en la capacidad actual de la célula. Existen recursos
de radio limitados que tienen que utilizarse para diferentes aplicaciones. Las
llamadas de voz y las de GPRS utilizan los mismos recursos de radio. El impacto
depende del número de ranuras de tiempo que se le reservan a GPRS. Aunque
también se tiene considerar que en horas de mucho tráfico GPRS ayuda a
distribuir mejor.
• Velocidad mucho mas baja en realidad:
Alcanzar la máxima velocidad de transmisión de GPRS implicaría que un solo
usuario utilizará las 8 ranuras de tiempo disponible, y sin protección contra
errores. Claramente, un operador de red no destinaría toda su capacidad a un
solo usuario, por lo que la velocidad de GPRS es mucho mas baja. En el
apartado “5.3 Estudio práctico. Resultados” de este proyecto, se analiza la
velocidad real en las conexiones GPRS.
3.4. UMTS
3.4.1. Introducción
Hasta el año 1998 no había existido la idea de desarrollar un estándar común para 3G,
ya que, en general, las investigaciones y mejoras estaban centradas en 2G, sin
integración entre estas tecnologías.
En diciembre de 1998 se establece el 3GPP (3G Partnership Project) como organización
para coordinar la producción de estándares conjuntos entre diferentes foros de
estandarización como eran ETSI, ARIB, CWTS, ….
Movicuo
112
Inicialmente la organización 3GPP se creó para generar especificaciones técnicas para
un estándar común para redes de tercera generación, extendiendo el núcleo de red de las
redes GSM.
Actualmente, también se encarga de la estandarización de mejoras a tecnologías de
GSM, como GPRS.
UMTS ha ido evolucionando desde que apareció, de forma que esa evolución se ha
reflejado en las diferentes releases del estándar, que son:
• UMTS R99
• UMTS R4
• UMTS R5
• UMTS R6
Desde la primera release del estándar (Release99) UMTS hace uso del protocolo IP
para trasportar datos dentro del núcleo de red. En esa primera especificación, IP es
utilizado para encaminar tráfico GPRS entre el UE (User Equipment) y redes externas
como Internet y a lo largo del núcleo de red UMTS utilizando GTP (GPRS Tunnelling
Protocol).
Esto ha evolucionado en la Release4 y la Release5, hasta hacer que IP se utilice para la
totalidad del trasporte (tanto tráfico como control) a través de UTRAN (UMTS
Terrestrial Radio Access Network). El uso de IP proporciona algunos beneficios, ya que
es un protocolo suficientemente maduro y testeado. El uso de IP como mecanismo de
transporte, hace que muchas aplicaciones y servicios puedan ser portadas a UMTS.
Además, IP tiene la capacidad de transportar tanto voz como datos de forma eficiente.
Para facilitar un cambio a IPv6 de forma suave, las especificaciones de UMTS indican
que tanto IPv4 como IPv6 deben ser soportados dentro de cada elemento de la red.
El primer desarrollo de UMTS es la release99.
Proyecto Fin de Carrera. Ingeniería Informática
113
En esta red, el cambio más importante, es el acceso por radio a la red (Radio Access
Network) con la introducción de las tecnologías WCDMA (Wideband Code Division
Multiple Access) para el interfaz aéreo, y ATM como transporte. Estos cambios han
sido introducidos principalmente para soportar el transporte de voz, video y servicios de
datos en la misma red. El núcleo de red apenas cambia, ya que tan solo se realizan
pequeñas actualizaciones de software.
En los siguientes apartados veremos como ha ido evolucionando el protocolo UMTS
según las distintas versiones del estándar.
3.4.2. Arquitectura UMTS
Para hablar de la arquitectura UMTS es necesario indicar cual es la versión del estándar
que se ha tomado como referencia, ya que en cada release, esta arquitectura ha ido
introduciendo o eliminando algún elemento o alguna funcionalidad. Iremos
comprobando esta evolución, a la vez que se irá viendo como el protocolo IP ha ido
introduciéndose en esta tecnología.
3.4.2.1. Release99
IP es utilizado en GPRS/UMTS de dos formas. En primer lugar, es usado como un
mecanismo de transporte por el usuario para llevar sus datos desde el UE hasta el host
de Internet o cualquier otra red. En segundo lugar, es usado entre los dispositivos de la
red para soportar GTP.
En el R99 de UMTS, el rol de IP es limitado a la conmutación de paquetes. La
arquitectura de la red es la mostrada en la figura 3.36
Movicuo
114
Figura 3.36 – Arquitectura de la red UMTS R99
El transporte en UTRAN está basado en ATM y utiliza el nivel ATM Adaption Layer 2
(AAL2) para el tráfico en el plano de usuario, y AAL5 para la señalización. Dentro del
núcleo de circuitos conmutados, la red está basada en un núcleo GSM.
El protocolo IP es utilizado como transporte en el dominio de conmutación de circuitos
entre el SGSN y el GGSN.
En la R99 el tráfico del plano de usuario entre el núcleo de red de circuitos y UTRAN es
ATM en los niveles 1 y 2. En las versiones posteriores, esto no será así, ya que la red irá
evolucionando para convertirse en una arquitectura IP, independiente de los niveles 1 y
2.
Los elementos que componen la red son:
3.4.2.1.1. UE (User Equipment)
El equipamiento del usuario es el terminal que comunica a dicho usuario con una
estación base en el momento que quiera y en el lugar donde exista cobertura. Algunas
de las propuestas para no perder la inversión de la infraestructura de GSM, es crear
Proyecto Fin de Carrera. Ingeniería Informática
115
equipos con sistemas duales, es decir, que puedan acceder a ambas redes (GSM/GPRS y
UMTS), mientras que consolida el cambio a 3G.
3.4.2.1.2. RAN (Radio Access Network)
Es el nombre del acceso de radio diseñado para el sistema UMTS. Tiene dos interfaces
que lo conectan con la red central y con el equipo de usuario. La interfaz Iu y la interfaz
Uu (utiliza WCDMA) respectivamente. En ocasiones se le denomina UTRAN. Esta red
consiste de varios elementos, entre los que se encuentran los RNC (Radio Network
Controller) y los Nodos B (WBTS en la figura). Las interfaces internas de RAN
incluyen la interfaz Iub la cual se encuentra entre el Nodo B y el RNC, y la interfaz Iur
que conecta a los RNC entre sí.
3.4.2.1.2.1. WBTS (WCDMA Base Station)
Las especificaciones de 3GPP llaman a este elemento Nodo B, sin embargo es más
común verlo como WBTS, BTS o simplemente BS. Un Nodo B es una entidad de red
que da servicio a una o más células, sin embargo las especificaciones hablan de una sola
célula por Nodo B.
En el nodo B se encuentra la capa física de la interfaz aérea, es por eso que además de
las funciones que debe ejecutar por su naturaleza, debe realizar las funciones propias de
la capa 1.
3.4.2.1.2.2. RNC (Radio Network Controller)
El RNC es el corazón del acceso a la red. Todas las decisiones del funcionamiento de la
red se realizan aquí, y tiene un conmutador de paquetes de alta velocidad para soportar
un alto throughput. Un RNC es el encargado de controlar todos los Nodos B conectados
a él. También es posible que interconecte con otros RNCs, por lo que debe tener esta
característica. La mayoría de decisiones están basadas en software, por lo que será
necesaria una capacidad de proceso alta.
Movicuo
116
3.4.2.1.3. 3GMSC (3G Mobile Switching Centre)
Es la pieza central de una red basada en la conmutación de circuitos. Para UMTS R99,
los cambios en el núcleo de la red son mínimos, la mayoría se basan en actualizaciones
de software. La función de 3GMSC es la misma que en GSM, sin embargo, 2GMSC es
un dispositivo de banda estrecha.
3.4.2.2. Evoluciones posteriores
El siguiente paso, tras R99, es la release 4. Su arquitectura es la siguiente:
Figura 3.37 – Arquitectura de la red UMTS Release 4
Aquí, el núcleo GSM es reemplazado por una red IP, basada en la tecnología de voz
sobre IP (VoIP).
El MSC evoluciona en dos componentes separados: MGW (Media GateWay) y un
servidor MSC (MSS). Un MSS puede mantener múltiples MGWs, haciendo la red más
escalable.
Proyecto Fin de Carrera. Ingeniería Informática
117
En la release 5, la idea de que toda la red sea IP, pasando el tráfico por un único BTS,
dio como resultado la siguiente arquitectura:
Figura 3.38 – Arquitectura de la red UMTS Release 5
Otra diferencia con las versiones anteriores es que HLR, VLR y EIR son generalizados
en un HSS (HLR Subsystem).
La parte de red tradicional de circuitos conmutados es eliminada, dejando toda la red
operando con IP, generalizado para el transporte de muchos tipos de servicio. Los de
tiempo real son soportados mediante la inclusión de un nuevo dominio de red, el IMS
(IP Multimedia Subsystem).
En la actualidad 3GPP está trabajando en la release 6, que aún no se ha “cerrado” por
completo. Esta revisión cubre los aspectos que no se tratan en las anteriores. UMTS
release 6 es también conocida como 4G.
3.4.3. Métodos de acceso. FDD y TDD
Como cualquier sistema CDMA, UMTS necesita una banda de frecuencia en la que
operar. El parámetro que define el sistema es el chip rate, donde un chip es el ancho de
un símbolo del código CDMA. UMTS utiliza un ratio de 3’84 Mchips/s, lo que hace
Movicuo
118
que la anchura de la portadora sea 5Mhz. Al ser mayor que la anchura necesaria para
CDMAone (1’25 Mhz), el interfaz aéreo de UMTS es denominado CDMA de banda
ancha.
En la actualidad UMTS utiliza dos tecnologías de radio, FDD y TDD. FDD (Frequency
Division Duplex), como se hacía en GSM, separa tráfico en uplink y downlink,
colocándolos en distintos canales de frecuencia. Un operador, por lo tanto, tendrá
asignadas un par de frecuencias.
TDD (Time Division Duplex) requiere tan sólo canal de frecuencia, de forma que el
tráfico de subida y de bajada se separa enviándolos en tiempos diferentes.
La figura 3.39 muestra el uso que se hace del espectro. Los valores que se usen para
FDD son, 1920-1980Mhz para subida y 2110-2170Mhz para bajada. El mínimo
espectro que necesita un operador son dos canales de 5 Mhz, uno de subida y otro de
bajada, con una separación de 190 Mhz (2110-2170). Para proporcionar buena cobertura
y servicios, es recomendable que el operador tenga tres canales.
Figura 3.39 – Frecuencias UMTS
Según este espectro, habrá disponibles tan solo 12 parejas de canales, lo que ha hecho
que en algunos países ya se haya completado. La forma de solucionar este problema por
parte de las autoridades reguladoras, sobre todo en algunos países europeos, ha sido
subastando las licencias de uso del espectro, por lo que el precio se ha disparado y ha
supuesto un costo muy grande para las operadoras.
El sistema TDD, necesita sólo un canal de 5 Mhz para operar, ya que no necesita otro
canal “pareja”. TDD separa el tráfico de subida y bajada gracias a los time-slots.
Proyecto Fin de Carrera. Ingeniería Informática
119
La diferencia entre UMTS FDD y TDD son sólo evidentes en los niveles bajos, ya que
en las capas más altas, la forma de operar es la misma en los dos sistemas.
La capa física WCDMA está estructurada en tramas de radio, cada una de ellas de 10ms
de duración. Estas tramas están divididas en 15 slots como puede verse en la figure
3.40.
Figura 3.40 – Estructura de la trama de radio UMTS
TDD no debería ser considerado como un sistema independiente, sino como un
complemento para FDD para proporcionar zonas de cobertura a alta velocidad.
3.4.4. QoS en UMTS
Según el ITU-T, QoS es “el rendimiento del servicio, que determina el grado de
satisfacción de un usuario con dicho servicio”. El usuario de un servicio no está
interesado en la forma en la que le funciona el servicio, tan solo le interesará que el
servicio funcione de forma satisfactoria para sus intereses. Así, desde el punto de vista
del usuario, la QoS significa si la red funciona correctamente o no, esto es importante
para los operadores de red, ya que servicios que no ofrezcan calidad puede que no sean
usados por los usuarios o lo que es peor para ellos, que los busquen en otros operadores
que si ofrezcan calidad de servicio.
Movicuo
120
Para UMTS, se definen varias clases distintas de QoS y un conjunto estándar de bit
rates, que se muestran en las tablas siguientes:
Nombre Retardo Almacenamiento Modo Bit Rate
Conversational Mínimo y fijo No permitido Simétrico Garantizado
Streaming Mínimo variable Permitido Asimétrico Garantizado
Interactive Moderado
variable
Permitido Asimétrico No garantizado
Background Alto variable Permitido Asimétrico No garantizado
Bit rate Comentario Tipo de cobertura
144 kbps Velocidad de pico
para la
transferencia de
paquetes
Zonas rurales, a
velocidades rápidas
(vehículos), en
exteriores
384 kbps Velocidad de pico
para la
transferencia de
paquetes
Zona urbana, en
vehículos, en
exteriores
2 Mbps Velocidad de pico
para la
transferencia de
paquetes
Centro urbano, a
velocidad de a pie, en
interiores
Las redes de 3G ofrecen distintos servicios, cada uno de ellos requiere su propia QoS,
por ejemplo, una video-llamada puede consistir en voz, vídeo y otros servicios, que
tienen que tener su propia QoS.
En el ámbito de 3G, la QoS es necesaria para muchas conexiones extremo a extremo.
Esto significa que garantizar esta QoS extremo a extremo, implica garantizarla en cada
una de las zonas de la red.
Proyecto Fin de Carrera. Ingeniería Informática
121
Figura 3.41 – Comparativa del throughput de las tecnologías móviles
3.4.5. Canales en UMTS
En UMTS pueden distinguirse tres tipos de canales, según la capa a la que pertenezcan:
capa lógica, capa de transporte y capa física.
Figura 3.42 – Tipos de canales en UMTS
Movicuo
122
Un canal lógico es un flujo de información que está dedicado a la transferencia de un
tipo concreto de información sobre el interfaz aéreo. Un canal de transporte es la forma
de transportar un canal lógico entre el UE y RNC. Un canal físico es el canal
propiamente dicho en el interfaz aéreo, definido por un código y una frecuencia
WCDMA.
3.4.6. Protocolo del interfaz aéreo
El interfaz de radio es una estructura organizada en capas que proporciona la conexión
entre el dispositivo móvil y el RNC. El protocolo tiene tres niveles que
aproximadamente coinciden con las tres capas inferiores del modelo OSI (nivel físico,
nivel de enlace y nivel de red.
El nivel físico está formado por WCDMA y ATM. El nivel de enlace lo componen las
subcapas MAC (Media Access Control), RLC (Radio Link Control) y PDCP (Packet
Data Convergence Protocol) y BMC (Broadcast/Multicast Control). El nivel PDCP es
utilizado cuando hay envío de paquetes de datos IP.
La capa de red consiste en MM (Mobility Management), CM (Connection Management
y SM (Session Management), entre el UE y el núcleo de la red.
El plano de usuario es complementado por un plano de control. El plano de control
también utiliza las capas MAC y RLC, sin embargo, tiene un protocolo adicional,
situado en la parte inferior del nivel tres, conocido como RRC (Radio Resource
Control). RRC es el protocolo de señalización que opera entre el usuario y el RNC.
En UMTS, el nivel físico pasa por dos “etapas”: el interfaz aéreo Uu que consiste en
WCDMA y el interfaz Iub, que consiste en el transporte ATM y sus respectivos niveles
físicos.
Proyecto Fin de Carrera. Ingeniería Informática
123
3.4.7. Control de potencia
El control de potencia en WCDMA aumenta el número de usuarios por portadora al
disminuir el nivel de interferencia. Esto se debe a que se toman 1500 mediciones de la
potencia por segundo, y modificando la potencia con la que transmiten tanto el móvil
como la radio base, gracias a esto los niveles de interferencia son muy bajos por lo que
el número de usuarios puede incrementar.
Además de disminuir el nivel de interferencia, con el control de potencia se presenta un
fenómeno llamado cell breathing. Cell Breathing significa que dependiendo del número
de usuarios, el tamaño de la célula puede variar, mientras con muchos usuarios el
tamaño de la célula será menor, con menos usuarios en el sistema la cobertura será
mucho mayor.
Movicuo
124
Proyecto Fin de Carrera. Ingeniería Informática
125
4. GRPS en un sistema Linux
Al igual que otros sistemas operativos, los sistemas Linux son capaces de soportar
tecnologías de última generación (nuestro caso serán tecnologías móviles). En este
apartado se dan detalles de cómo Linux, y en concreto GNU/LinEx es capaz de soportar
conexiones GPRS de forma satisfactoria, siguiendo las recomendaciones de los
estándares publicados por la 3GPP, y de la forma que se ha explicado en el apartado “3.
Situación tecnológica actual”.
4.1. Introducción
GPRS es una tecnología comunicaciones móviles de 2.5G. Como se ha ido viendo a lo
largo del proyecto, la característica fundamental que introdujo GPRS frente al resto de
tecnologías fue el acceso a través de una red de conmutación de paquetes, que presenta
mejores prestaciones para una red de datos. GSM, con su conmutación de circuitos, era
una buena solución para las redes móviles de voz, pero la incorporación de nuevos
servicios como el acceso a Internet a través del móvil, propició el cambio.
De todos modos, durante el año 2000, otra tecnología que permitía el acceso a Internet a
través de un dispositivo móvil se extendió por todo el mundo. Esta tecnología era WAP
(Wireless Application Protocol), pero pronto se vio que era lenta, cara y nada intuitiva
de utilizar. El hecho, es que la mayoría de las características de WAP sobre GSM de las
que los usuarios se quejaban, no eran debidas a las características de WAP, sino que
esos problemas eran típicos de las redes de conmutación de circuitos. Una conexión de
circuitos conmutados funciona como una llamada telefónica. Se hace una llamada al ISP
(Internet Service Provider) y se tienen 9.6 Kbps mientras que estemos conectados (y no
se comparte esa capacidad con nadie).
Para algunas aplicaciones de streaming de audio, esta solución puede ser buena (aunque
la mayoría de las aplicaciones de streaming no tienen un bit rate constante). Para
sesiones como la navegación WAP, sin embargo, la conexión es muy irregular y con
Movicuo
126
picos de transferencia, por lo que la conmutación de circuitos es ineficiente tanto para el
usuario como para el operador.
La situación que se producía con el uso de WAP (y en general, con el uso de tecnologías
de conmutación de circuitos) para el acceso a Internet se muestra en la figura siguiente,
en la que un canal de radio, time slot 2, es asignado al usuario y que realiza una
trasferencia de datos. El usuario está pagando el mismo dinero cuando se envía la
máxima capacidad del canal y cuando no se envía nada.
Figura 4.1 – Uso de un slot durante una sesión WAP
La introducción de paquetes de datos en una red, no sólo resuelve estos problemas, sino
que permite a los usuarios compartir los recursos. De este modo, no se estará
introduciendo ninguna carga en la red cuando no se envíen ni reciban paquetes. Con los
paquetes de datos, los usuarios no solo comparten la capacidad entre ellos, sino que
también la comparten con los circuitos conmutados de voz y datos de otros usuarios.
TS6
TS5
TS4
TS3
TS2
TS1
TS0
TS7
Throughput (Time Slots)
Tiempo
Ráfagas de datos
Sesión
Proyecto Fin de Carrera. Ingeniería Informática
127
En la figura 4.2 se muestra esta capacidad, donde dos usuarios de GPRS comparten los
dos primeros time slots. Dos o más usuarios que tuvieran el mismo uso podrían
probablemente haber compartido los mismos time slots sin notar pérdida de velocidad
ninguno de ellos. También se destinan cinco canales a circuitos conmutados durante
este periodo, y los usuarios que los utilicen no se verán afectados por las sesiones de
GPRS.
Figura 4.2 – Compartición de time-slots en GPRS
Esta característica beneficia también al operador, que puede dar servicio a más usuarios
dentro de la misma red, ya que ahora se podrán utilizar partes de la red que no podían
utilizarse antes.
El throughput de GPRS es, teóricamente 170 Kbps. Este valor es una referencia, ya que
se alcanzarían si se utilizaran los ocho time slots, si ningún otro usuario estuviera
compartiéndolo, y si no existieran códigos de protección. En realidad, el terminal
TS6
TS5
TS4
TS3
TS2
TS1
TS0
TS7
Throughput (Time Slots)
Tiempo
Time-Slots dedicados a llamadas
Paquetes de datos generados por el usuario 1
Paquetes de datos generados por el usuario 2
Movicuo
128
normalmente limitará este throughput. Hay definidas 29 configuraciones para los
terminales GPRS que indican según se repartan los time slots para subida y bajada
(uplink y downlink).
NOTA: Las distintas configuraciones se explican en el apartado 3.3.7 Tipos de
terminales.
La capacidad por time slot varía (de 9 a 20 Kbps) dependiendo de la codificación que se
utilice. Para los teléfonos GPRS, donde la limitación de consumo de potencia es un
factor clave, las configuraciones más comunes son del tipo 4+1, que significa que se
utilizan cuatro time slots de bajada y uno sólo de subida, debido a la generación de calor
que se produce y el consiguiente consumo de batería, que también será mayor cuanto
mas alto sea el bit rate. Este es el tipo de dispositivo que se va a utilizar para las pruebas
de conexión a GPRS. Los dispositivos de transmisión consumen la energía generada por
la batería, aunque mucha de la energía generada es perdida en forma de calor. Por eso,
es difícil construir un terminal que utilice los 8 canales de subida y los 8 de bajada, ya
que el consumo de energía sería enorme y el calor desprendido sería insoportable.
También hay otros tipos de limitaciones físicas debido al uso de los transceiver, pero la
explicada anteriormente parece la más importante.
Esta es la situación concreta en la que nos encontramos y que está desarrollada de forma
mucho más amplia en la sección 3. Situación tecnológica actual.
4.2. Componentes de un “sistema” móvil
A lo largo del proyecto he ido llamando dispositivo móvil, terminal o simplemente
móvil, a lo que ahora denominaremos “sistema móvil”. Hago esta distinción porque a
partir de esta sección, nuestro “sistema móvil” no solo será el teléfono, sino la unión del
ordenador con teléfono. Ya veremos como realizar la comunicación entre ellos, para lo
cual será necesario distinguir las partes con las que se interactúan.
Proyecto Fin de Carrera. Ingeniería Informática
129
Por tanto, tendremos:
• TE (Terminal Equipment): Es el dispositivo en el que están las aplicaciones y la
interacción con el usuario.
• MT (Mobile Terminal): Es la parte que conecta a la red.
Cuando el TE y el MT estén físicamente separados, es decir, cuando utilicemos el
ordenador como interfaz con el usuario y el teléfono móvil para realizar el acceso a
Internet a través de GPRS, el teléfono actuará como un puente a Internet (módem).
En este caso, al interfaz entre el ordenador y el teléfono lo llamaremos interfaz R. A
continuación se explica su uso. En la figura 4.3, aparecen los protocolos utilizados tanto
por el ordenador (TE), como por el teléfono móvil (MT), y los interfaces usados para
conectar tanto los dispositivos TE y MT, como el MT a la red.
A la hora de establecer una conexión, lo primero que tendremos que hacer es conectar
los dispositivos en la capa física. En nuestro caso utilizaremos un cable al puerto USB
del ordenador. Es necesario tener los módulos necesarios para que el sistema operativo
(en nuestro caso GNU/LinEx) sea capaz de reconocer dicha conexión física entre el TE
y el MT (ordenador y teléfono móvil).
El siguiente paso, es levantar una conexión Point-to-Point Protocol (PPP) entre los
dispositivos. PPP está implementado en la mayoría de los sistemas operativos, entre
ellos, Debian (y GNU/LinEx). PPP crea un interfaz de comunicación hacia las capas
inferiores y permite a la capa IP comunicarse con la red de forma transparente. Además
realiza algunas optimizaciones, como evitar el envío de información redundante. PPP es
un protocolo que se utiliza en la mayoría de conexiones a través del módem para la
conexión con el servidor de acceso.
Movicuo
130
Figura 4.3 – Protocolos en la conexión PPP entre el móvil y el ordenador
4.3. Acceso a capas inferiores. Comandos AT.
Una de las características más interesantes en la comunicación entre el MT y el TE, es
el acceso a las capas inferiores mediante los comandos AT. Para proporcionar a los
desarrolladores el acceso al hardware del terminal GPRS y a las propiedades de la red
directamente, el estándar GPRS define una serie de comandos AT (ATtention
commands). Los comandos AT han sido (y son) desarrollados con la recomendación
ITU-T V.25ter (Serial asynchronous automatic dialing and control), con el objetivo de
dar un conjunto de comandos que el sistema de comunicaciones debe ofrecer a las capas
superiores.
Proyecto Fin de Carrera. Ingeniería Informática
131
Por lo tanto, muchos de los comandos AT son también usados en GSM y UMTS, así
como en los módems tradicionales. El conjunto de comandos AT que se han añadido a
los comandos tradicionales de control de módem, se denominan AT+ o comandos AT
extendidos. El estándar del ETSI GSM 07.07, Release 1997, describe el conjunto de
comandos AT+ para los terminales GSM, incluyendo HSCSD y GPRS.
En las especificaciones, el MT (Mobile Terminal) está dividido en TA (Terminal
Adaptor) y ME (Mobile Equipment). La idea es que el TA es el que recibe e interpreta
los comandos AT, pero en este proyecto, no haremos distinción entre el TA y el ME, ya
que los tendremos en el mismo dispositivo (el móvil), mientras que el TE será el
ordenador. También sería posible tener el TA en el TE o los tres elementos separados,
pero estas situaciones no nos interesan.
Figura 4.4 – Elementos que intervienen en el intercambio de comandos AT
Los comandos AT que podemos enviar son tanto los básicos (utilizados en los módem
tradicionales y definido en V.25ter), como los extendidos. Estos últimos utilizan las
reglas sintácticas de los comandos extendidos. Todos los comandos extendidos tienen
una forma “test” (poniendo al final “=?”, ya veremos ejemplos), para comprobar la
existencia del comando y dar información sobre el tipo de sus parámetros.
Los comandos, tienen también otra forma “read” (“?”) que indica el actual valor de los
subparámetros.
Así, la estructura básica de los comandos AT y AT+ es la siguiente:
TE
TA
ME
Comandos AT
Respuestas
Control del ME
Estado del ME
Usuarios y aplicaciones RED
Mensajes de la red MTTE
Movicuo
132
Figura 4.5 – Estructura básica de los comandos AT y AT+
Si la respuesta en modo verboso está activada, (con el comando V1), y todos los
comandos enviados han sido interpretados correctamente, el resultado que se envíe
desde el TA al TE será: <CR><LF>OK<CR><LF>, donde CR es el retorno de carro y
LF es el salto de línea. Si por el contrario está activada la respuesta numérica (con el
comando V0), el resultado que se recibe será: 0<CR>
Cuando los valores de los subparámetros de un comando no sean aceptados por el TA (o
el comando sea inválido), el resultado <CR><LF>ERROR<CR><LF> será enviado al
TE y ningún comando enviado en la misma línea será procesado. Si la respuesta
numérica está activada, el resultado recibido será 4<CR>. La respuesta ERROR (o 4),
puede ser reemplazada por +CME ERROR: <err> cuando el comando no sea procesado
debido a un error relacionado con el MT.
4.4. Conexión a la red
Veamos que ocurre cuando un teléfono móvil (GSM con funcionalidad GPRS), se
conecta a la red.
Proyecto Fin de Carrera. Ingeniería Informática
133
En nuestro caso, tanto el MT como el TE están en el teléfono. El dispositivo de prueba
es un teléfono móvil de clase B, multislot tipo 8 (4+1). En primer lugar necesita decirle
a la red que puede hacer y recibir tanto conexiones GSM como GPRS. Este
procedimiento lo hemos llamado Attach durante todo el proyecto y es similar para GSM
y GPRS.
El Attach GPRS crea un enlace lógico entre el SGSN y el MS. Esta tarea es realizada
siguiendo los siguientes pasos:
1. El MS envía una petición Attach al SGSN
2. El SGSN comprueba si conoce al MS e intenta encontrar su número de
identificación único IMSI. Si el MS no es conocido, le preguntará al SGSN
antiguo (el de la célula en la que estuviera anteriormente)
3. Si este antiguo SGSN tampoco conoce al MS, este envía un mensaje de error. El
nuevo SGSN después pregunta al MS por su IMSI. Uno podría pensar que sería
más eficiente preguntar al MS directamente, pero el envío del IMSI por el aire es
generalmente evitado por razones de seguridad.
4. El SGSN realiza una autenticación del MS
5. Si el MS se encuentra en una nueva área de servicio, el HLR es actualizado.
6. Si el MS actualmente está en una nueva área de localización, el MSC/VLR es
actualizado.
7. El SGSN del dice al MS acerca del TLLI (Temporary Location Link Identifier)
que se le ha asignado. TLLI es utilizado a lo largo de la sesión GPRS como un
identificador para el enlace lógico entre el MS y el SGSN.
Es posible realizar el Attach combinado para GPRS/IMSI y hacer al teléfono visible
tanto para voz como para paquetes de datos al mismo tiempo.
Lo contrario de un Attach GPRS lo llamaremos Detach GPRS, que elimina el terminal
GPRS de la red. Esto ocurre habitualmente cuando se apaga el teléfono, al igual que el
Attach se produce normalmente al encenderlo.
Movicuo
134
Para ejecutar el Attach (o detach) a la red, se utiliza el comando AT+CGATT. Si el MT
ya está en el mismo estado que se solicita, el comando es ignorado y se devuelve un
OK. Si el attach o detach no puede llevarse a cabo, tendremos como respuesta un
ERROR o +CME ERROR.
Cualquier contexto PDP activado es automáticamente desactivado si el estado pasa a
detach.
El parámetro necesario para la ejecución del comando AT+CGATT es:
• Estado: Es el valor que queremos solicitar para indicar si es un attach o detach.
o 0 – Detach
o 1 – Attach
Así, el formato básico del comando es: +CGATT= [<estado>]
Una vez que el enlace entre el MS y el SGSN ha sido establecido, el móvil necesita una
dirección IP y otros parámetros de conexión. Esta tarea es realizada mediante la
activación del contexto PDP (Packet Data Protocol). El contexto PDP puede ser visto
como un registro software que mantiene parámetros que son relevantes para una
conexión concreta. Esta información incluye los protocolos que serán utilizados (IP o
X25), la dirección IP (si se usa el protocolo IP), la QoS (o mejor dicho, su perfil), e
información sobre si utilizar compresión. Los parámetros deseados del contexto PDP,
pueden ser establecidos utilizando comandos AT.
La activación del contexto PDP hace que el dispositivo GPRS sea visible para el GGSN
correspondiente, que hace posible conexiones externas.
Los siguientes pasos muestran el procedimiento de activación del contexto PDP
(teniendo en cuenta que anteriormente ya se produjo el Attach).
1. El MS envía una petición de contexto PDP al SGSN
Proyecto Fin de Carrera. Ingeniería Informática
135
2. Funciones de seguridad pueden ser ejecutadas entre el MS y el SGSN, que
validarán la petición
3. El SGSN
a. Comprueba la suscripción
b. Comprueba la QoS, que afecta al precio del servicio.
c. Envía información al GGSN acerca de cómo alcanzar el MS
d. Configura un enlace lógico al GGSN estableciendo un túnel
4. El SGSN contacta con un servidor RADIUS (Remote Access Dial-In User
Service) dentro de la red del operador y consigue una dirección IP para el MS.
5. La dirección IP es enviada de vuelta al MS
Para la activación del contexto PDP, el estándar GPRS define el comando
AT+CGDCONT. Este comando permite indicarle a la red los valores utilizados para
establecer un contexto PDP. El número de contextos PDP que pueden existir al mismo
tiempo en un estado, se puede conocer con AT+GDCONT=?. La ejecución del
comando AT+CGDCONT? nos devuelve la configuración actual para cada contexto
definido.
Así, el comando CGDCONT presenta el siguiente formato:
+CGDCONT=[<cid> [,<PDP_type> [,<APN> [,<PDP_addr> [,<d_comp> [,<h_comp> [,<pd1> [,…[,pdN]]]]]]]]]
Los parámetros son los siguientes:
• CID (PDP Context Identifier): Es un valor numérico que indica un identificador
de contexto concreto. El parámetro es local al interfaz TE-MT y es utilizado en
otros comandos relacionados con el contexto PDP. El rango de los valores
permitidos (valor mínimo = 1) es devuelto por el comando cgdcont=?
• PDP_type (Packet Data Protocol Type): Es una cadena que indica el tipo de
protocolo de paquete de datos utilizado, y puede ser uno de los siguientes:
o X.25: ITU-T/CCITT X.25 de nivel 3 (obsoleto)
o IP: Protocolo de Internet (IETF STD 5)
o IPV6: Protocolo de Internet versión 6 (IETF RFC 2460)
Movicuo
136
o OSPIH: Internet Hosted Octect Stream Protocol (obsoleto)
o PPP: Protocolo Punto a Punto (IETF STD 51)
• APN (Access Point Name): Este parámetro es una cadena que hace referencia al
nombre lógico utilizado para seleccionar el GGSN de la red de paquete de datos
externa.
• PDP_address: Cadena que identifica al MT en el espacio de direcciones PDP. Si
el valor del parámetro se omite, el valor será proporcionado por el TE durante el
procedimiento de activación PDP, o si falla, se hará una petición de dirección
dinámica. La ejecución del comando cgdcont? devuelve una cadena vacía
incluso si se ha asignado una dirección durante la activación PDP. Para
comprobar la dirección asignada, puede utilizarse el comando +CGPADDR.
• d_comp: Es un número que controla la compresión de datos PDP (aplicable
únicamente a SNCDP), este parámetro puede tener los siguientes valores:
o 0 – Desactivado (valor por defecto)
o 1 – Activado (Compresión elegida por el operador)
o 2 – V.42bis
o 3 – V.44
• h_comp: Parámetro numérico que indica la compresión de la cabecera PDP.
Puede tener los siguientes valores:
o 0 – Desactivado (valor por defecto)
o 1 – Activado (Compresión elegida por el operador)
o 2 – RFC 1144 (aplicable únicamente a SNDCP)
o 3 – RFC 2507
o 4 – RFC 3095 (aplicable únicamente a PDCP
• pd1, …, pdn: Cero o n cadenas cuyo significado es específico de cada
PDP_type.
Un Attach GPRS seguido por una activación de contexto PDP se muestra en la figura
siguiente. En la figura, el TE puede ser un ordenador que envía comandos AT.
NOTA: El estándar define el comando AT+CGACT utilizado para activar o desactivar
un determinado contexto PDP. Utilizaremos este comando durante la activación de la
conexión para indicar el contexto que vamos a utilizar. El formato del comando es:
Proyecto Fin de Carrera. Ingeniería Informática
137
+CGACT=[<estado> [,<cid>[,<cid>[,…]]]]
Donde estado indica el valor que tiene el contexto PDP (0 - desactivado, 1 – activado),
y cid indica el contexto PDP concreto que se desea activar.
Figura 4.6 – Activación del contexto PDP a través de comandos AT
Ahora el usuario GPRS estará preparado para enviar y recibir paquetes. Este método es
una forma de que el MS consiga una dirección IP, pero puede haber otras formas, en
todo caso, la explicada aquí es la más común.
Las siguientes alternativas son posibles:
• Direcciones IP dinámicas: El GGSN asigna una IP dinámica de su propio rango
de direcciones.
• Direcciones IP dinámicas: El GGSN pregunta a un ISP por una dirección IP, que
normalmente es realizado a través de un servidor RADIUS. El ISP puede ser el
operador móvil, o una entidad externa.
• Direcciones IP estáticas: El SGSN obtiene una dirección IP del HLR (de la
misma forma que obtiene el resto de información).
Movicuo
138
Esta primera parte ha dado un conocimiento general de cómo activar una conexión
GPRS a través de comandos AT+. En el proyecto Movicuo, esta activación se ha
realizado desde el sistema operativo GNU/LinEx, aunque la metodología seguida es
similar para el resto de sistemas Linux.
Los comandos AT extendidos utilizados en el proyecto, aparecen en el estándar ETSI
TS 127 007.
4.5. GPRS sobre GNU/LinEx
Como parte del proyecto AGILA (http://patanegra.unex.es/agila), en el que uno de sus
objetivos es soportar sobre el sistema LinEx las comunicaciones inalámbricas mediante
la unión del ordenador (portátil) con el teléfono móvil GPRS, se ha investigado acerca
del funcionamiento de GPRS sobre LinEx (y sistemas Linux en general). Ahora
veremos como GPRS puede ser un método muy útil para el acceso a Internet desde este
sistema operativo, ya que en cualquier momento en el que tengamos cobertura en
nuestro móvil, podremos acceder a Internet de la forma que se indica.
Es necesario un teléfono GSM con soporte GPRS para utilizar este servicio. Además el
operador al que se esté suscrito, deberá también disponer de él. Actualmente las
principales operadoras de telefonía móvil en Europa, dan soporte para GPRS, por lo que
este requisito, normalmente, no será un impedimento para su uso. En España, las
principales compañías ofrecen el servicio GPRS, por lo que, tanto si somos clientes de
Amena como si lo somos de Telefónica Movistar o Vodafone, podremos tener acceso al
servicio GPRS.
En nuestro caso concreto, estaremos suscritos al servicio GPRS de Vodafone. Más
adelante indicaremos algunos parámetros necesarios para realizar la conexión con esta
empresa, aunque de la misma forma se puede realizar dicha conexión con Amena,
Movistar, o cualquier otra, sin más que conocer los datos que deben ser proporcionados
por cada operador.
Proyecto Fin de Carrera. Ingeniería Informática
139
El caso en el que nos estaremos moviendo, es el que se ve en la siguiente estructura.
Figura 4.7 – Estructura de GPRS con la incorporación del ordenador
Aquí, utilizaremos PPP (Point to Point Protocol) desde el PC al teléfono y el teléfono
tunela paquetes IP a un proveedor de Internet.
Para crear una conexión, habrá que comunicarse con el teléfono utilizando los
comandos AT que se explicaron en el apartado anterior, y enviar el comando de llamada
ATD, que iniciará una conexión PPP.
En nuestro caso particular, disponemos de un PDA iPAQ HP6300 series con su cable de
datos USB y un teléfono móvil Motorola C353 (también con su cable de datos USB). El
sistema operativo que vamos a utilizar es LinEx2004 r1 (Debian Sarge).
El PDA iPAQ HP6300 dispone de un teléfono con tecnología GPRS. Este dispositivo
viene integrado con el sistema operativo Microsoft Windows CE. En principio, si
siguiera el estándar, respondería a los comandos AT+ que se le envíen.
4.5.1. Módulos del sistema operativo - Nivel Físico
Para que LinEx reconociera el PDA no hubo que instalar ningún módulo (no es
necesario sincronizarlo, sino tan solo reconocerlo). Una vez reconocido el PDA, había
que intentar comunicarse con él a través de comandos AT. Después de multitud de
intentos de realizar una simple comunicación, en la que el PDA respondiera a un
comando básico como “ATZ”, se dio por imposible esta tarea. El autor de este proyecto
Movicuo
140
se puso en contacto con el servicio técnico de HP tanto el de Estados Unidos como el de
España. En ninguno de los dos servicios técnicos dieron respuesta a esta situación,
pasando el problema al sistema operativo, e indicándome que me pusiera en contacto
con el servicio técnico de Microsoft Windows.
Ante esta respuesta se decidió abandonar la opción del PDA que disponíamos, porque
ya antes de comenzar estaban surgiendo muchos problemas de compatibilidad con el
estándar, algo que podría hacer que el desarrollo se centrara en un dispositivo
específico, separándome mucho del objetivo de este proyecto. AGILA es el acrónimo de
“Acceso Generalizado a Internet desde LinEx Avanzado”, no parece lógico realizar las
pruebas sobre un dispositivo que no sigue, en principio, las normas de los estándares, y
que en lugar de generalizar, lo único que supondría sería concretizar el acceso desde un
dispositivo muy particular y muy poco común frente a la gran mayoría de usuarios
potenciales de GPRS, que disponen de un teléfono móvil para el posible acceso a través
de esta tecnología.
Dado que se disponía de otro dispositivo con tecnología GPRS (el teléfono móvil
Motorola C353), se probó, al igual que se realizó con el PDA, si el sistema operativo
GNU/LinEx detectaba el teléfono cuando se conectaba al ordenador a través del cable
USB. Ante el envío del comando “ATZ”, se obtuvo una respuesta inmediata del
teléfono, “OK”, lo que significaba que el sistema operativo era capaz de dialogar con el
teléfono móvil. El diálogo a través de comandos AT, lo veremos con detalle en
secciones posteriores.
Los pasos dados hasta este punto se describen a continuación con más detalle:
Al conectar el cable de datos al puerto USB con el teléfono encendido a GNU/LinEx, se
pueden ver los siguientes mensajes de log, accesibles desde el fichero /var/log/messages
o a través del comando dmesg desde la consola de LinEx:
linex-K7mZhx kernel: usb 4-2: new full speed USB device using
address 8
linex-K7mZhx kernel: cdc_acm 4-2:1.0: ttyACM0: USB ACM device
Proyecto Fin de Carrera. Ingeniería Informática
141
linex-K7mZhx usb.agent[4930]: cdc-acm: loaded successfully
linex-K7mZhx kernel: usbcore: registered new driver cdc_acm
linex-K7mZhx kernel: drivers/usb/class/cdc-acm.c: v0.23:USB
Abstract Control Model driver for USB modems and ISDN adapters
Esto significa que LinEx ha detectado un nuevo dispositivo USB, y que ha cargado el
módulo cdc-acm, que es el necesario para interactuar con el teléfono móvil. A este
dispositivo se puede acceder desde /dev/ttyACM0.
Para conocer los módulos de los que dispone el sistema operativo, podemos ejecutar el
comando modprobe –l. Sabiendo que módulo necesita el teléfono, podremos conocer si
está soportado por LinEx o no.
4.5.1.1. Módulo CDC-ACM
El módulo cdc-acm (Comunication Device Class – Abstract Control Model) se carga
cada vez que se conecta el cable USB del teléfono Motorola C353, que es el que se
utiliza para realizar las pruebas en este proyecto.
En este apartado se da una descripción detallada de este módulo.
Usando un modelo abstracto de control (ACM), el dispositivo USB entiende los
comandos AT estándares V.25ter. El dispositivo contiene un micro-controlador que
gestiona los comandos AT y los controles de transmisión. El dispositivo utiliza dos
interfaces, el “Data Class” y el “Communication Class”, de la forma que aparecen en la
figura 4.8.
Movicuo
142
Figura 4.8– Estructura física del módulo CDC-ACM
4.5.2. Interacción con el teléfono. Comandos AT.
Una vez reconocido el teléfono, lo que haremos será comprobar si responde a los
comandos AT.
Para comprobar esto, podemos hacerlo de varias formas, utilizando /dev/ttyACM0
directamente para acceder al dispositivo, o a través de un programa de comunicaciones
como Minicom. Veamos las dos opciones.
1. Utilizar /dev/ttyACM0 directamente: Para comunicarnos de esta forma, abrimos
dos terminales (consola). En una de ella lo que haremos será enviar el comando
ATZ al móvil, mientras que en la otra esperaremos por la respuesta que devuelva
el teléfono. Así, en uno de los terminales, escribimos el siguiente comando:
cat /dev/ttyACM0
Proyecto Fin de Carrera. Ingeniería Informática
143
Que hará que se mantenga en espera de una respuesta del dispositivo ttyACM0
(nuestro móvil).
En el otro terminal, enviaremos el comando ATZ, para eso tendremos que
escribir:
echo “ATZ” > /dev/ttyACM0
Cuando ejecutemos este comando, en el primer terminal aparecerá lo siguiente:
linex:/# cat /dev/ttyACM0
ATZ
OK
Así, ya sabemos que LinEx es capaz de conversar con el teléfono móvil.
2. Utilizando Minicom: Esta es una herramienta que nos va a permitir dialogar con
el teléfono a través de comandos AT (similar a HyperTerminal). Para instalarlo
en GNU/LinEx, basta con introducir el comando apt-get install minicom. Para
arrancarlo, escribimos minicom desde el terminal y accedemos a la pantalla
principal del programa. Si queremos “hablar” con el teléfono, lo primero es crear
un enlace al módem de la siguiente forma:
ln –sf /dev/ttyACM0 /dev/modem
Nosotros le indicamos que el módem está conectado a /dev/ttyACM0, por lo
tanto, si estuviera conectado en otro sitio, habría que indicarlo del mismo modo.
A partir de ahora, cada vez que iniciemos el programa, buscará en la dirección
indicada (/dev/ttyACM0). Al ejecutar Minicom, simplemente tendremos que
escribir los comandos AT que queramos enviarle al módem (el teléfono) y él
responderá.
Movicuo
144
4.5.3. Activar conexión PPP
Una vez que el sistema operativo y el dispositivo se “reconocen” y son capaces de
dialogar a través de comandos AT, el siguiente paso, será levantar una conexión Point-
to-Point Protocol (PPP) entre los elementos (ordenador y teléfono).
PPP es el protocolo utilizado para establecer enlaces a Internet sobre módems de
marcado, conexiones DSL, y muchos otros tipos de enlace punto a punto, entre las que
se encuentra también un módem GPRS. El demonio pppd trabaja junto con el driver del
núcleo PPP para establecer y mantener un enlace PPP con otro sistema (peer) y para
negociar la dirección IP para cada extremo del enlace. pppd puede también realizar
tareas de autenticación.
En el siguiente apartado, se dan mas detalles del protocolo PPP.
Nosotros utilizaremos PPP para obtener la dirección IP y para autentificarnos a la red.
El protocolo punto a punto en Linux acepta multitud de opciones que pueden
encontrarse en el manual on-line (man pppd). En nuestro caso, iremos explicando cada
opción utilizada.
Las opciones pueden tomarse de un fichero o de la línea de comandos. Por defecto, las
opciones a utilizar por el demonio pppd estarán en los ficheros /etc/ppp/options,
~/.ppprc y /etc/ppp/options.ttyname, en ese orden. Si utilizamos la opción de pppd:
file nombre_fichero_opciones
Las opciones se tomarán de ese fichero. Hay que tener en cuenta que el usuario que
ejecute esta opción deberá tener, al menos, permisos de lectura sobre el archivo
nombre_fichero_opciones.
Un aspecto muy importante es la autenticación. Para conectarnos a la red GPRS de
Vodafone (compañía a la que estamos suscritos), necesitaremos una serie de parámetros
Proyecto Fin de Carrera. Ingeniería Informática
145
que deben ser proporcionados por la propia compañía. Entre esos parámetros, aparecen
un nombre de usuario y una contraseña.
La autenticación hace que el cliente envíe su nombre de usuario junto a algún tipo de
información secreta que haga creer al servidor (el operador de telefonía que proporciona
el servicio) que somos quien decimos ser. Normalmente, la información secreta será el
password, aunque para el acceso a la red GPRS tanto el nombre de usuario como el
password son públicos y cualquiera puede conocerlos. Los parámetros de autenticación
a la red GPRS de Vodafone son los siguientes:
Nombre de usuario: vodafone
Contraseña: vodafone
NOTA. Los parámetros de autenticación para Amena y Telefónica Movistar pueden
obtenerse contactando con el servicio de atención al cliente de cada operadora, ya que
estos valores son públicos.
Actualmente, pppd soporta tres protocolos de autenticación:
• Password Authentication Protocol (PAP): Este protocolo implica que el cliente
envíe su nombre de usuario y su password en forma de texto al servidor para
autentificarse.
• Challenge Handshake Authentication Protocol (CHAP): El servidor es el que
inicia la autenticación enviando un paquete al cliente en el que irá el nombre del
propio servidor. El cliente debe dar una respuesta que incluya su nombre mas un
valor hash que saldrá de la clave secreta y el paquete que recibió del servidor.
• Extensible Authentication Protocol (EAP): Este protocolo soporta el tipo de
autenticación CHAP explicada en el punto anterior, y también el mecanismo
SRP-SHA1, que es resistente a ataques basados en diccionario y no requiere un
password de texto plano en la parte servidora.
Pppd almacena los “secretos” que utilizará en la autenticación en ficheros:
Movicuo
146
• /etc/ppp/pap-secrets cuando se use PAP
• /etc/ppp/chap-secrets si utilizamos CHAP, MS-CHAP, MS-CHAPv2 y EAP
MD5-Challenge
• /etc/ppp/srp-secrets para EAP SRP-SHA1.
Todos estos ficheros siguen el mismo formato. Cada línea de estos ficheros contendrá
un “secreto” específico para un cliente y un servidor en particular. Cada línea tendrá al
menos tres campos: El nombre del cliente, el nombre del servidor y el “secreto”. Estos
campos pueden ir seguidos de una lista de direcciones IP que el cliente puede usar
cuando se realice la conexión al servidor específico.
Para el caso de GPRS, utilizaremos el protocolo PAP para la autenticación. No será
necesario que utilicemos el fichero /etc/ppp/pap-secrets, ya que los parámetros de
autenticación los indicaremos a través de las opciones de pppd user y password (esto lo
veremos más adelante).
La autenticación debe estar completada antes de que IPCP (o cualquier otro protocolo
de control de red) pueda iniciarse. Si la autenticación falla, pppd dará por terminado el
enlace (cerrando el protocolo LCP). Si IPCP negocia una dirección IP que no es
correcta para el host remoto, IPCP se cerrará. Los paquetes IP pueden ser enviados o
recibidos sólo cuando IPCP está abierto.
Una vez que la negociación IPCP se completa de forma correcta, pppd informará al
kernel de la dirección local y remota para el interfaz ppp. Esto es suficiente para crear
una ruta al enlace remoto final, que permitirá intercambiar paquetes IP.
Esta es la secuencia que teóricamente debe producirse para activar el protocolo PPP
entre el ordenador y el teléfono móvil, y que permitirá enviar al ordenador los paquetes
IP que lleguen al teléfono de la red GPRS.
Ahora veremos que esta secuencia se sigue al conectar a GPRS a través del teléfono
móvil.
Proyecto Fin de Carrera. Ingeniería Informática
147
Antes se comentó que era necesario ejecutar ciertos comandos para activar el contexto
PDP. Estos comandos se ejecutarán al levantar el interfaz PPP. La secuencia de
conexión que habrá que marcar para conectarse al servicio es (para Vodafone):
Fichero “CONECTAR” '' AT&F TIMEOUT 240 OK ATV1 OK AT+CGATT=1 OK 'AT+CGDCONT=2,"IP","airtelnet.es"' OK ATS=0 OK AT+CGQREQ=2,1,1,1,9,18 OK AT+CGQMIN=2,1,3,3,6,18 OK AT+CGACT=1,2 OK ATDT*99***2# TIMEOUT 30 CONNECT ""
Estos comandos serán los que ppp necesite para iniciar la conexión. El formato que
sigue esta secuencia es la siguiente: La parte izquierda de la línea será lo que se espera
recibir y la parte derecha de la línea es el comando que se envía. Así, por ejemplo,
cuando enviemos ATV1 (tercera línea), esperaremos recibir un OK (cuarta línea) y será
entonces cuando enviemos el comando AT+CGATT, y así hasta el final, que
recibiremos CONNECT.
Así, el significado de los comandos que conforman este procedimiento es:
AT&F Reestablece los parámetros que por defecto vienen de fábrica.
ATV1 Devolver códigos de resultado en modo verbal.
AT+CGATT Como ya se explicó, este es el comando que se utiliza para realizar el
Attach a la red.
AT+CGDCONT Como ya se vio en el apartado 4.4 Conexión a la red, el formato del
comando es:
Movicuo
148
+CGDCONT=[<cid> [,<PDP_type> [,<APN> [,<PDP_addr> [,<d_comp> [,<h_comp> [,<pd1> [,…[,pdN]]]]]]]]]
Este comando especifica un contexto PDP identificado por el <cid>. Se indica que IP
será el tipo de protocolo de paquete de datos y airtelnet.es es el APN (Access Point
Name) o punto de acceso al que nos conectamos
AT+CGQREQ Este comando permite al TE indicar el perfil de QoS que se utilizará
cuando el MT envíe un mensaje de solicitud de activación del contexto PDP a la red. El
comando especifica un perfil para el contexto identificado por el parámetro cid. El perfil
de QoS está formado por los parámetros propios de GPRS, cada uno de los cuales tiene
un conjunto de valores propio. Veamos cada parámetro y sus posibles valores:
• Clase de precedencia (o prioridad): Puede tener los siguientes valores:
o 0: Prioridad establecida por el operador, si se omite su valor tendrá esta
por defecto.
o 1: Prioridad alta: Los datos con esta prioridad se procesan antes que los
de la clase 2 y 3
o 2: Prioridad normal: Tiene preferencia frente a la clase 3
o 3: Prioridad baja.
Estos valores sólo se tendrán en cuenta en determinadas circunstancias de
congestión en la red, en la que los paquetes que se descarten antes, serán los
de las prioridades más bajas.
• Clase de retardo: Es un parámetro que puede tener los valores:
o 0: Valor establecido por la red.
o 1: Retardo menor
o 2: Retardo medio
o 3: Retardo mayor
o 4: Retardo Best effort: No se especifican los valores que puede tener el
retardo.
• Fiabilidad: Indica el ratio de errores. Hay cuatro posibles valores
o 0: Valor establecido por la red
o 1: Probabilidad de errores muy baja. Indicada para aplicaciones sensibles
a errores y con ninguna tolerancia a ellos.
Proyecto Fin de Carrera. Ingeniería Informática
149
o 2: Probabilidad de errores baja. Indicada para aplicaciones que no tienen
tráfico en tiempo real, que normalmente no pueden permitirse pérdida de
datos
o 3: Probabilidad de errores media. Para aplicaciones tolerantes a errores
que no generan tráfico en tiempo real.
o 4: Probabilidad de errores media-alta. Para aplicaciones que generan
tráfico en tiempo real que pueden permitirse pérdidas de errores
o 5: Probabilidad de errores alta. Para aplicaciones con tráfico en tiempo
real, que no son sensible a errores.
• Throughput de pico: Parámetro que indica la velocidad máxima que se puede
alcanzar. Puede tener los valores siguientes:
o 0: Valor establecido por la red
o 1: Hasta 8 kbit/s
o 2: Hasta 16 kbit/s
o 3: Hasta 32 kbit/s
o 4: Hasta 64 kbit/s
o 5: Hasta 128 kbit/s
o 6: Hasta 256 kbit/s
o 7: Hasta 512 kbit/s
o 8: Hasta 1024 kbit/s
o 9: Hasta 2048 kbit/s
• Throughput medio: Indica la velocidad promedio de la conexión. Esta velocidad
se mide en octetos a la hora, pero para cada valor daremos su equivalencia a una
medida más común.
o 0: Valor establecido por la red.
o 1: 100 (0’22 bit/s)
o 2: 200 (0’44 bit/s)
o 3: 500 (1’11 bit/s)
o 4: 1000 (2’2 bit/s)
o 5: 2000 (4’4 bit/s)
o 6: 5000 (11’1 bit/s)
o 7: 10000 (22’2 bit/s)
o 8: 20000 (44’4 bit/s)
Movicuo
150
o 9: 50000 (111’1 bit/s)
o 10: 100000 (0’22 kbit/s)
o 11: 200000 (0’44 kbit/s)
o 12: 500000 (1’11 kbit/s)
o 13: 1000000 (2’22 kbit/s)
o 14: 2000000 (4’4 kbit/s)
o 15: 5000000 (11’1 kbit/s)
o 16: 10000000 (22’2 kbit/s)
o 17: 20000000 (44’4 kbit/s)
o 18: 50000000 (111’1 kbit/s)
o 31: Best effort. Valor no especificado.
Así, el formato del comando es:
+CGQREQ=[<cid> [,<prioridad > [,<retardo> [,<fiabilidad.> [,<pico> [,<medio>]]]]]]
En el ejemplo, por tanto, la solicitud que se realiza es:
• Prioridad: Clase 1 (la más alta)
• Retardo: Clase 1 (el mejor)
• Fiabilidad: Clase 1 (la de menor probabilidad de errores)
• Throughput máximo: 2Mbps
• Throughput medio: 111 kbps
AT+CGQMIN Este comando permite al TE especificar un perfil mínimo aceptable
de QoS que es comparado por el MT frente al perfil negociado en el mensaje de
“activación de contexto PDP aceptada”.
El formato del comando es:
+CGQMIN=[<cid> [,<prioridad > [,<retardo> [,<fiabilidad.> [,<pico> [,<medio>]]]]]]
Donde los parámetros tienen el mismo significado que en el caso del comando
+CGQREQ.
Proyecto Fin de Carrera. Ingeniería Informática
151
La petición realizada en el ejemplo es:
• Prioridad: Clase 1 (la más alta)
• Retardo: Clase 3 (la de mayor retardo)
• Fiabilidad: Clase 3 (la de mayor probabilidad de errores)
• Throughput máximo: 256 Kbps
• Throughput medio: 111 kbps
AT+CGATT Activa el contexto PDP indicado.
ATD Comando que realiza la llamada al ISP. En este caso el número ha sido
proporcionado por Vodafone. La ejecución de este comando comienza la conexión
PPP/IP al teléfono. El número 2 situado antes de la almohadilla final, se refiere al CID
que tenemos asignado para el acceso a Internet.
Estos comandos estarán en un fichero que llamaremos desde la línea de comandos al
ejecutar el comando pppd para conectar. Ese fichero se llama conectar.
Al igual que tenemos los comandos de conexión, tendremos los de desconexión, así
tendremos otro fichero llamado disconnect que tendrá la siguiente secuencia de
comandos:
Fichero “DESCONECTAR” SAY "\nDisconnecting...\n"
"" "\K"
"" "+++ATH"
SAY "\nDisconnected.\n"
Si se desea finalizar la conexión, tras desactivar el cliente PPP se debe enviar la cadena
de caracteres +++ con el fin de que el módem cambie de modo datos a modo comandos
AT. Una vez que ha cambiado de modo se cuelga la conexión mediante el comando
ATH (colgar llamada).
Movicuo
152
Por último, el fichero con las opciones de ppp será un fichero llamado opciones-
conexion-gprs que estará formado por las siguientes opciones: # # Script de opciones de conexión para GNOME GPRS # # Activa el modo debug debug # Puerto de la conexion /dev/ttyACM0 # Velocidad 460800 # Uso del flujo de control (RTS/CTS) para controlar el flujo en el puerto crtscts # Utilizar las lineas de control del modem modem # Indica que pppd deberia crear un fichero de bloqueo para el dispositivo para garantizar acceso exclusivot al mismo lock # Con esta opcion, pppd aceptará todos los caracteres de control de la pareja receive-all # Desactiva el campo del protocolo de la negociación de la compresion tanto en la direccion de emision como en la recepcion nopcomp # Desactiva la compresion Address/Control en ambos sentidos noaccomp # Desactiva la negociacion del numero magico. Con esta opcion, pppd no puede detectar una linea loop-back noaccomp # Desactiva la negociacion del protocolo de control de compresion (CCP) noaccomp # Desactiva la compresion de la cabecera TCP/IP, usando el metodo Van Jacobson, en ambos sentidos noaccomp # Desactiva la opcion de compresion connection-ID en el estilo Van Jacobson de compresion de la cabecera compresion de la cabecera TCP/IP, usando el metodo Van Jacobson, en ambos sentidos novjccomp # No detach del terminal de control nodetach
Proyecto Fin de Carrera. Ingeniería Informática
153
# Desactiva el comportamiento por defecto cuando no se especifica una direccion IP noipdefault # Esta opcion hace que pppd cree una ruta default cuando IPCP se active, y la borra cuando el enlace se termina defaultroute # Indica el nombre de usuario y password utilizados para la autenticacion user vodafone password vodafone # Pregunta a la pareja por las direcciones de los dos servidores DNS usepeerdns # Script de conexion connect '/usr/sbin/chat -e -f /root/.gnome-gprs/conectar -v' # Script de desconexion disconnect '/usr/sbin/chat -e -f /root/.gnome-gprs/desconectar -v'
Estas opciones serán las que establecerán algunas opciones de la conexión PPP.
Una vez que tenemos los comandos de conexión (en el fichero conectar), los comandos
de desconexión (en el fichero desconectar) y las opciones de PPP (en el fichero
opciones-conexion-gprs), para comenzar la conexión escribimos desde la línea de
comandos:
# pppd file opciones-conexion-gprs
Con este comando lo que estamos haciendo es lanzar PPP con las opciones que se
indican en el fichero que sigue a file, es decir, opciones-conexion-gprs.
La ejecución de este proceso, dará la siguiente salida:
AT&F OK ATV1 OK AT+CGATT=1 OK AT+CGDCONT=2,"IP","airtelnet.es" OK ATS0=0 OK
Movicuo
154
AT+CGQREQ=2,1,1,1,9,18 OK AT+CGQMIN=2,1,3,3,6,18 OK AT+CGACT=1,2 OK +MBAN: Copyright 2000-2002 Motorola, Inc. ATDT*99***2# CONNECT Serial connection established. using channel 10 Using interface ppp0 Connect: ppp0 <--> /dev/ttyACM0 sent [LCP ConfReq id=0x1 <asyncmap 0x0>] rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>] rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xa9e45> <pcomp> <accomp>] sent [LCP ConfRej id=0x1 <magic 0xa9e45> <pcomp> <accomp>] rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth pap>] sent [LCP ConfAck id=0x2 <asyncmap 0x0> <auth pap>] sent [LCP EchoReq id=0x0 magic=0x0] sent [PAP AuthReq id=0x1 user="vodafone" password=<hidden>] rcvd [LCP EchoRep id=0x0 magic=0x0] rcvd [PAP AuthAck id=0x1] PAP authentication succeeded sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] rcvd [IPCP ConfNak id=0x1 <addr 212.166.151.190> <ms-dns1 212.73.32.3> <ms-dns3 212.73.32.67>] sent [IPCP ConfReq id=0x2 <addr 212.166.151.190> <ms-dns1 212.73.32.3> <ms-dns3 212.73.32.67>] rcvd [IPCP ConfAck id=0x2 <addr 212.166.151.190> <ms-dns1 212.73.32.3> <ms-dns3 212.73.32.67>] rcvd [IPCP ConfReq id=0x3 <addr 192.168.100.101>] sent [IPCP ConfAck id=0x3 <addr 192.168.100.101>] not replacing default route to eth0 [158.49.113.5] Cannot determine ethernet address for proxy ARP local IP address 212.166.151.190 remote IP address 192.168.100.101 primary DNS address 212.73.32.3 secondary DNS address 212.73.32.67 Script /etc/ppp/ip-up started (pid 5735) Script /etc/ppp/ip-up finished (pid 5735), status = 0x0 Terminating on signal 2. Connect time 0.1 minutes. Sent 0 bytes, received 0 bytes. Script /etc/ppp/ip-down started (pid 5765) sent [LCP TermReq id=0x2 "User request"] rcvd [LCP TermAck id=0x2 "User request"] Connection terminated. Disconnecting...
Proyecto Fin de Carrera. Ingeniería Informática
155
Disconnected. Serial link disconnected. Waiting for 1 child processes... script /etc/ppp/ip-down, pid 5765 Script /etc/ppp/ip-down finished (pid 5765), status = 0x0
En esta salida, se ve toda la secuencia que sigue una conexión PPP, desde que comienza
hasta que finaliza. A continuación se explica todo este proceso:
En primer lugar, se realiza la conexión PPP para activar el interfaz entre el móvil y el
ordenador
Connect: ppp0 <--> /dev/ttyACM0
Luego, aparece el protocolo LCP (Link Control Protocol), que es un protocolo que
forma parte de PPP. En las comunicaciones PPP, tanto los dispositivos emisores como
los receptores envían paquetes LCP para determinar información específica que será
necesaria para la transmisión de datos.
LCP comprueba la identidad del dispositivo enlazado y si acepta o rechaza al otro
dispositivo, comprueba también el tamaño de paquete aceptable para la transmisión,
buscar errores de configuración y puede terminar el enlace si no está satisfecho con los
parámetros negociados. Los datos no pueden ser transmitidos por la red hasta que los
paquetes LCP determinen que el enlace es aceptable.
Una vez que el protocolo LCP termina su función, pasamos a ejecutar otro protocolo, en
este caso el de autenticación PAP. Como podemos ver en la salida generada, su
comprobación se ha realizado correctamente.
Una vez realizada la autenticación, comienza el protocolo IPCP. Se irán intercambiando
mensajes hasta que varios parámetros se establezcan, y se mostrarán las direcciones
negociadas y las direcciones de los servidores DNS que la red GPRS nos envía.
Movicuo
156
En ese momento podremos acceder a Internet normalmente, pero lo estaremos haciendo
a través de la red GPRS de Vodafone, a la que nos conectamos mediante el teléfono
móvil, que actúa como módem.
Finalmente, cuando ya no queramos navegar más, se cierra la conexión y se muestran
algunos resultados estadísticos de la misma.
El siguiente diagrama muestra el intercambio de principal de mensajes realizado para la
conexión:
Proyecto Fin de Carrera. Ingeniería Informática
157
Figura 4.9 – Intercambio de mensajes para la activación de GPRS usando PPP
INICIADOR NO INICIADOR
Inicia la configuración LCP
Procesa la petición de configuración LCP
Configure-Request
Configure-AckFinaliza la configuración LCP
Inicia el test Loopback Echo-Request
Responde al test
Confirma el funcionamiento del enlace
Echo-Reply
Finalización del enlace
Inicia la autenticación Comprueba el nombre de usuario y password
recibido
Autentícate-Request
Authenticate-Ack Ya estamos autenticados
Autenticación
Establecimiento del enlace NCP (IPCP)
Establecimiento del enlace LCP
Comprobación del enlace LCP
Inicia la configuración IPCP
Procesa la petición de configuración IPCP
IPCP Configure-Request
IPCP Configure-Ack Finaliza la configuración IPCP
Envío y recepción de datos IP
Recibe la petición de cierre. Se lo indica al otro
dispositivo Cierra el enlace
LCP Terminate-Request
LCP Terminate-Ack Enlace finalizado
Movicuo
158
Si miramos los mensajes del núcleo, tendremos:
gnuLinEx pppd[5374]: pppd 2.4.2 started by root, uid 0
gnuLinEx pppd[5374]: Serial connection established.
gnuLinEx pppd[5374]: Using interface ppp0
gnuLinEx pppd[5374]: Connect: ppp0 <--> /dev/ttyACM0
gnuLinEx pppd[5374]: PAP authentication succeeded
gnuLinEx pppd[5374]: local IP address 62.87.74.75
gnuLinEx pppd[5374]: remote IP address 192.168.100.101
gnuLinEx pppd[5374]: primary DNS address 212.73.32.3
gnuLinEx pppd[5374]: secondary DNS address 212.73.32.67
gnuLinEx pppd[5374]: Terminating on signal 2.
gnuLinEx pppd[5374]: Connect time 0.5 minutes.
gnuLinEx pppd[5374]: Sent 874 bytes, received 2025 bytes.
gnuLinEx pppd[5374]: Connection terminated.
gnuLinEx pppd[5374]: Serial link disconnected.
gnuLinEx pppd[5374]: Exit.
Que también mostrará, aunque con menos detalles, la secuencia de la conexión
realizada.
4.6. Protocolo Punto a Punto (PPP)
Uno de los protocolos fundamentales para realizar la conexión GPRS sobre
GNU/LinEx, según se ha visto en los apartados anteriores, es PPP. Aunque ya se ha
hablado de algunas de sus características, en este punto se explica detalladamente su
funcionamiento, prestando especial atención a los formatos y los tipos de tramas de los
sub-protocolos que lo componen.
4.6.1. Introducción
La historia de PPP se remonta a finales de los 80, cuando SLIP era el estándar de facto
para las comunicaciones serie IP. El primer documento del IETF relacionado con PPP
Proyecto Fin de Carrera. Ingeniería Informática
159
fue el RFC 1134, publicado en 1989. Este RFC no es el estándar, sino una propuesta
para lo que debería ser PPP, que se definió en el RFC 1171, en 1990. Este documento
ha sido revisado en numerosas ocasiones y muchos otros documentos se han utilizado
para completarlo y definir los protocolos que componen PPP.
El IETF pensó, que en lugar de desarrollar PPP desde cero, podría utilizarse como base
el protocolo HDLC (ISO High-Level Data Link Control), que fue desarrollado
inicialmente por IMB. HDLC ya provenía del protocolo SDLC (Synchronous Data Link
Control). Los desarrolladores PPP adaptaron su estructura de trama y parte de su
funcionamiento general del protocolo HDLC.
4.6.2. Arquitectura
PPP es un protocolo orientado a la conexión que permite enlaces sobre el nivel dos de
distintas conexiones de nivel físico. Soporta tanto líneas síncronas como asíncronas, y
puede operar en modo half-duplex o full-duplex. Fue diseñado para transportar tráfico
IP pero es común permitir que cualquier tipo de datagrama de la capa de red sea enviado
sobre una conexión PPP.
Como su nombre indica, está diseñado para conexiones punto a punto entre dos
dispositivos y supone que las tramas son enviadas y recibidas en el mismo orden.
PPP se ajusta a la capa de enlace (y física) en el modelo TCP/IP, como muestra la
imagen siguiente.
Movicuo
160
Figura 4.10 – Protocolo PPP vs OSI
4.6.3. Componentes y funcionamiento general
Podemos distinguir en el protocolo PPP tres componentes principales:
• Método de Encapsulación PPP: El trabajo principal de PPP es coger mensajes de
las capas superiores como datagramas IP y encapsularlos para transmitirlos
sobre la capa física que se encuentra justo debajo. Para esto, PPP define un
formato de trama especial basado en la trama utilizada en el protocolo HDLC.
La trama PPP ha sido especialmente diseñada para ser de tamaño reducido y
contener solo campos simples para maximizar la eficiencia en términos del
ancho de banda y la velocidad en el procesamiento.
• Link Control Protocol (LCP): El protocolo LCP es responsable de establecer,
mantener y finalizar el enlace entre los dispositivos. Es un protocolo flexible y
extensible que permite el intercambio de muchos parámetros para la
7
6
5
3
2
4
1
Aplicación
Presentación
Sesión
Transporte
Red
Enlace
Físico
Arquitectura del Modelo OSI
7
6
5
3
2
4
1
Protocolos de niveles
superiores
TCP / UDP
IP
PPP
Físico (Conexión serie, módem, RDSI,…)
Arquitectura de PPP
Proyecto Fin de Carrera. Ingeniería Informática
161
configuración, para asegurar que ambos dispositivos están de acuerdo en cómo
el enlace debe ser utilizado.
• Network Control Protocols (NCPs): PPP soporta la encapsulación de muchos
tipos de datagramas del nivel tres. Algunos de ellos requieren una configuración
adicional antes de que el enlace pueda ser activado. Después de la configuración
del enlace a cargo de LCP, el control es pasado al NCP específico para el
protocolo de nivel tres que vaya a ser transferido en el en lace PPP. Por ejemplo,
cuando se transfiere IP sobre PPP, el NCP utilizado es el Internet Protocol
Control Protocol (IPCP).
PPP no es un protocolo simple, sino un conjunto de muchos de ellos. La arquitectura
básica de PPP fue diseñada, entre otras cosas, para permitir extensiones sencillas. Por
esto, el funcionamiento de PPP no está definido en un único estándar. Al igual que
TCP/IP, los protocolos PPP son descritos en una serie de RFCs. Estos son actualizados
regularmente.
El hecho de que PPP incluya decenas de protocolos, hace que parezca realmente
complejo. En realidad, la forma de operar de PPP es bastante sencilla. La existencia de
todos esos protocolos permiten, como ya dijimos, que PPP sea flexible y extensible.
El funcionamiento general de PPP implica tres pasos básicos. Comenzando en un estado
donde no hay ningún enlace PPP entre los dispositivos, las operaciones que habrá que
realizar para activar dicho enlace PPP serán:
1. Configuración y puesta a punto del enlace: Antes de que los dos dispositivos
puedan intercambiar información, deberán levantar un enlace entre ellos.
Durante su puesta a punto, todos los parámetros necesarios para gestionar el
funcionamiento del enlace son acordados por los dos dispositivos. El protocolo
LCP comienza este proceso, ayudándose de los protocolos que sean necesarios,
como por ejemplo los de autenticación. Una vez que el enlace está activado, se
pasa el control al protocolo NCP apropiado (según la tecnología utilizada en el
nivel tres).
Movicuo
162
2. Funcionamiento del enlace: Los dispositivos en el enlace lo utilizan para enviar
datagramas. Cada dispositivo realizará el envío cogiendo los datagramas del
nivel superior, encapsulándolos y enviándolos a través de la capa física. A la
hora de recibir información, las tramas PPP se toman de la propia capa física, se
quita la cabecera PPP y se pasa el datagrama a la capa superior. Puede que en
este paso se utilicen también otros protocolos como CCP para realizar la
compresión.
3. Terminación del enlace: Cuando cualquiera de los dos dispositivos decidan
finalizar la comunicación, el enlace terminará.
La imagen siguiente muestra una visión general del funcionamiento del protocolo PPP.
Figura 4.11 – Funcionamiento general de PPP
La puesta a punto del enlace es el paso más complicado de los tres descritos, ya que
implica negociar muchos parámetros y opciones del enlace.
Ahora veremos con más detalle estos aspectos.
No hay enlace
Puesta a punto y configuración del
enlace
Enlace en funcionamiento
Enlace finalizado
Conexión de nivel físico establecida
Negociación LCP correcta
Fallo en el enlace o petición de cierre
Fin del enlace completado
Negociación LCP no aceptada
Proyecto Fin de Carrera. Ingeniería Informática
163
El proceso de establecer, utilizar y cerrar un enlace PPP se describe en el estándar como
una serie de estados o fases. En la figura 4.12 se muestra un diagrama en la que
aparecen estos estados y sus relaciones.
Figura 4.12 – Estados de un enlace PPP
La conexión PPP entre dos dispositivos comienza en el estado enlace muerto y avanza
por tres fases intermedias hasta que el enlace está completamente operativo, como
muestra el flujo del diagrama anterior. Este permanecerá en la fase de enlace abierto
hasta terminar.
Veamos una descripción de cada estado.
Estado enlace muerto
Enlace muerto
Establecimiento del enlace
Autenticación Enlace finalizado
Conexión de nivel físico establecida
Negociación LCP correcta
Fin del enlace completado
Negociación LCP no aceptada
Protocolo de nivel de red
Enlace abierto
Fallo en el enlace o petición de cierre
Autenticación satisfactoria
Autenticación incorrecta
Configuración NCP correcta
Sin enlaces entre los dispositivos
Enlace LCP autenticado
Enlace LCP
Enlace físico
Enlaces NCP y LCP autenticados
Movicuo
164
El enlace PPP siempre comienza y termina en este estado. Representa la situación en la
que ningún enlace físico se ha establecido entre los dos dispositivos. Permanecerá en
esta situación hasta que el enlace de la capa física se establezca, momento en el que se
avanza al estado Establecimiento del enlace.
Estado Establecimiento del enlace La capa física está conectada y el protocolo LCP lleva a cabo la puesta a punto del
enlace. El dispositivo A (llamaremos A y B a los dos dispositivos) envía un mensaje
Configuration Request a B, especificando los parámetros que querría utilizar. Si el
dispositivo B está de acuerdo, responderá con un asentimiento. En el caso de que B no
esté de acuerdo, devolverá un asentimiento negativo, informando al dispositivo A que
no acepta. A puede entonces intentar otra petición con unos parámetros diferentes, en
espera de que B los acepte.
Si A y B llegan a un acuerdo, el estado del enlace será considerado LCP abierto, y
evoluciona a la fase de Autenticación. Si no se pusieran de acuerdo, el enlace físico se
cerraría y volveríamos a la fase Enlace muerto.
Estado Autenticación En muchos casos como el de las conexiones GPRS, el dispositivo tiene que ser
autenticado antes de permitir la conexión. En este caso, se utilizará el protocolo PAP
(PPP Authentication Protocol).
Cuando la autenticación sea correcta, el enlace sigue a la fase “protocolo de nivel de
red”. Si por el contrario no es correcta, el enlace falla y se hace la transición a la fase
enlace finalizado.
Estado Protocolo de nivel de red Una vez que el enlace ha sido configurado y la autenticación completada, la apertura del
enlace LCP ha finalizado. Ahora, la configuración específica del protocolo de la capa de
red invocará al NCP apropiado, en el caso de la conexión a Internet a través de GPRS,
el protocolo de nivel de red es IP, por tanto el NCP adecuado es el protocolo IPCP.
Proyecto Fin de Carrera. Ingeniería Informática
165
Después, el enlace pasará al estado enlace abierto.
Estado Enlace abierto En este estado, el enlace LCP y NCP están abiertos y en funcionamiento. Los datos
podrán ser enviados por el NCP.
El enlace puede terminar en cualquier momento por cualquiera de los dos dispositivos
por varias razones. Estas pueden ser: solicitud del usuario (cuando por ejemplo, se pulse
un botón de desconexión), problemas en la calidad del enlace (debido por ejemplo a
ruidos), o por alguna otra razón. Cuando esto ocurre, el enlace LCP se rompe y el enlace
transiciona a la fase enlace finalizado
Estado Enlace finalizado El dispositivo pone fin al enlace enviando una trama LCP especial de terminación, y el
otro dispositivo la asiente. El enlace entonces vuelve a la fase Enlace muerto. En el caso
en el que la terminación fuera por petición y la conexión de la capa física estuviera aún
activa, PPP debe expresamente comunicar a la capa física la terminación de la conexión.
Para cubrir todos estos aspectos, son necesarios muchos protocolos, los cuales,
componen “un todo” que es PPP.
Los protocolos que se utilizarán durante las conexiones GPRS, se detallan en los
apartados siguientes.
4.6.4. LCP (PPP Link Control Protocol)
De todos los protocolos que componen el conjunto PPP, el más importante es el
protocolo LCP (Link Control Protocol). LCP es el responsable de que todo funcione
correctamente, y de supervisar, de algún modo, las acciones de otros protocolos.
Movicuo
166
Podemos decir que PPP es un protocolo que realiza “enlaces”. LCP sería entonces el
encargado de controlar dichos enlaces. Si pensamos en la forma de actuar de LCP,
podemos distinguir tres “estados” en el que el protocolo juega un papel relevante:
• Configuración del enlace: Este será el proceso de puesta a punto y negociación
del enlace.
• Mantenimiento del enlace: Proceso de gestión de un enlace abierto.
• Terminación del enlace: Proceso de cierre de un enlace existente cuando ya no
se vaya a utilizar.
Cada una de estas actividades corresponde a una de las fases de la vida de un enlace
PPP. La configuración del enlace se lleva a cabo durante la fase inicial Establecimiento
del enlace; el mantenimiento del enlace se produce mientras el enlace está abierto, y la
terminación, evidentemente, aparece en la fase enlace finalizado.
El diagrama de la figura 4.13 proporciona una visión global de los mensajes
intercambiados por LCP durante las distintas fases de la conexión PPP.
La configuración del enlace se muestra como un intercambio simple de Configure-
Request y Configure-Ack. Después de que otros protocolos actúen para realizar la
autenticación, y se configure el NCP, el enlace estará en la fase de enlace abierto. En el
diagrama, los mensajes Echo-Request y Echo-reply se utilizan en primer lugar para
probar el enlace, seguido por los datos enviados y recibidos por ambos dispositivos.
Proyecto Fin de Carrera. Ingeniería Informática
167
Figura 4.13 – Intercambio de mensajes LCP
Finalmente, el enlace se finaliza con el intercambio de los mensajes Terminate-Request
y Terminate-Ack
Los dispositivos utilizan LCP para controlar el enlace PPP enviando mensajes
especiales LCP de un extremo a otro del enlace físico. Esos mensajes se llaman tanto
paquetes LCP como tramas LCP. Mientras que los estándares utilizan paquetes, el
término trama es mejor ya que los mensajes de la capa dos normalmente, son
denominados así.
Hay once tipos de tramas LCP distintas definidas en el documento del estándar que
define PPP, que son divididos en tres grupos que corresponden con los tres estados
diferenciados antes. Cuatro tipos de tramas LCP son utilizados para la configuración del
enlace, cinco para el mantenimiento, y dos para el cierre. A continuación veremos como
se utilizan estas tramas en las tres actividades principales en las que participa LCP.
INICIADOR NO INICIADOR
Inicia la configuración LCP
Procesa la petición de configuración LCP
Configure-Request
Configure-AckFinaliza la configuración LCP
Autenticación y negociación NCP
Inicia el test Loopback Echo-Request
Responde al test
Confirma el funcionamiento del enlace
Echo-Reply
Envío y recepción de datos una vez que el enlace está operativo
Realiza una petición de cierre Terminate-Request
Cierre del enlace
Enlace finalizado Terminate-Ack
Movicuo
168
4.6.4.1. Configuración del enlace LCP
La configuración del enlace, podría decirse que es el trabajo principal que realiza LCP
en PPP. Durante la fase Establecimiento del enlace, se producirá el intercambio de
tramas LCP, las cuales permitirán a los dos dispositivos conectados, negociar las
condiciones bajo las cuales funcionará el enlace. Este procedimiento lo analizaremos
ahora detenidamente, y puede verse gráficamente en el diagrama que aparece a
continuación.
Figura 4.14 – Diagrama de uso de LCP
Receptor procesa el mensaje Configure-Request
¿Todas las opciones tienen
valores correctos?
¿Todas las opciones son reconocidas?
El receptor envía el mensaje Configure-Nak
El receptor envía el mensaje Configure-Reject
El emisor reconfigura sus parámetros de conexión
El emisor envía el mensaje Configure-Request
El receptor envía el mensaje Configure-Ack
El emisor recibe el Configure-Ack
El dispositivo pasa al estado de Autenticación
No
Si
Si
No
Proyecto Fin de Carrera. Ingeniería Informática
169
El proceso comienza con la creación de una trama Configure-Request por parte del
dispositivo que comienza la comunicación (al que llamaremos A), la cual contendrá un
número de parámetros de configuración del enlace. Estos parámetros serán los que A
desearía para el enlace.
Según el RFC 1661 (que es el documento principal de especificación de PPP), los
“parámetros” de configuración que el dispositivo iniciador puede especificar en su
petición son los siguientes:
• Maxium Receive Unit (MRU): Tamaño máximo del datagrama
• Protocolo de autenticación: Tipo de protocolo de autenticación que se desea
utilizar (si se va a utilizar alguno)
• Protocolo de calidad: Indica si se permitirá monitorizar la calidad del enlace, y
que protocolo utilizar (LRQ es el que está actualmente definido)
• Número mágico: Se utiliza para detectar ciertas anomalías en la conexión
• Compresión de los campos: Permite especificar si se quiere usar los campos
comprimidos (8 bits) en las tramas de datos PPP, en lugar de los campos de 16
bits normales.
• Address and Control Field Compression (ACFC): Similar a la opción de
compresión, pero se utiliza para comprimir los campos dirección (Address) y
control (Control). Al igual que en el caso anterior, esta compresión puede
utilizarse para algunos ahorros en ancho de banda.
Una vez que A envía su petición, el otro dispositivo (al que llamaremos B) recibirá la
trama Configure-Request y la procesa, lo que dará lugar a tres posibles respuestas:
1. Si todas las opciones son aceptables y está de acuerdo con ellas, el dispositivo B
envía de vuelta una trama Configure-Ack, completando así la negociación.
2. Si todas las opciones que A envía son válidas y B las reconoce perfectamente,
pero no acepta los valores enviados por A, entonces B devolverá una trama
Configure-Nak. Este mensaje incluirá una copia de cada parámetro de
configuración que B no ha aceptado.
Movicuo
170
3. Si alguna de las opciones que A envía no son reconocidas por B, o son
conocidas pero las considera inaceptables e innegociables, devolverá una trama
Configure-Reject que contendrá cada uno de los parámetros innegociables.
La diferencia entre Configure-Nak y Configure-Reject es que, aunque ambas podrían
utilizarse para negociar los parámetros, la segunda es mucho más tajante a la hora de
denegar un valor para un parámetro. Configure-Nak por su parte indica el desacuerdo en
uno o varios parámetros pero en cambio, su valor podría negociarse. Por ejemplo si A
hace una petición en la que propone a PAP como protocolo de autenticación y la envía a
B, pero este quiere utilizar CHAP, entonces devolverá una trama Configure-Nak. Si en
cambio B no soporta autenticación, enviará una trama Configure-Reject.
4.6.4.2. Mantenimiento del enlace LCP
Una vez que el enlace ha sido negociado, LCP pasa el control al protocolo de
autenticación o al NCP, según corresponda.
Así, la configuración del enlace se completará si es necesario y pasará al estado abierto.
Los mensajes LCP pueden ser utilizados para gestionar o depurar el enlace:
• Code-Reject y Protocol-Reject: Estas tramas se usan para proporcionar feedback
cuando un dispositivo recibe una trama inválida debido, a un código LCP no
reconocido, o a un identificador de protocolo incorrecto respectivamente.
• Echo-Request, Echo-Reply y Discard-Request: Con estas tramas podremos
testear el enlace.
Finalmente, cuando el enlace está preparado para cerrarse, LCP lo finaliza. El
dispositivo que inicie este cierre, envía una trama Terminate-Request. El otro
dispositivo responde con un Terminate-Ack. Una petición de terminación indica que el
dispositivo que la emite necesita cerrar el enlace, y dicha petición no podrá ser
denegada.
Proyecto Fin de Carrera. Ingeniería Informática
171
El estándar RFC 1570 (PPP LCP Extensions), también define dos nuevos tipos de
mensajes. El mensaje Identification se utiliza para permitir a un dispositivo identificarse
al otro y el otro mensaje, Time-Remaining, permite a un dispositivo decirle al otro
cuanto tiempo queda de la sesión actual.
4.6.5. Procolo de control de red PPP (IPCP)
Como se ha dicho ya en varias ocasiones, PPP es una tecnología muy potente, debido a
su flexibilidad. Aunque inicialmente, fue creado con la idea de transportar datagramas
IP, PPP es capaz de tomar datos de distintos tipos desde las capas de red. El permitir
que PPP soporte muchos protocolos del nivel de red, hace que el protocolo deba
conocer a cada uno de ellos. Si se utilizara sólo el protocolo LCP para la configuración
del enlace, éste debería conocer todas las características de los protocolos de nivel tres
que podrían estar por encima en la pila de protocolos. Esto significaría que LCP debería
actualizarse cada vez que un nuevo protocolo de red fuera definido, o que alguno de los
existentes fuera modificado.
En lugar de utilizar esta solución en la que LCP haría todo el trabajo, PPP está diseñado
de forma modular para el establecimiento de la conexión, lo que significa que LCP hará
el trabajo básico y después de la autenticación, pasará el control a un protocolo NCP
(Network Control Protocol), que ya sí que será específico según el protocolo que exista
de nivel tres. NCP negociará los parámetros particulares para el protocolo
correspondiente de nivel de red. Cada tecnología de nivel de red tendrá un NCP
específico, definido en un RFC. La forma de llamar a estos documentos, normalmente
sigue el siguiente patrón: “The PPP -nombre del protocolo de nivel tres- Control
Protocol”, como por ejemplo “The PPP Internet Protocol Control Protocol”, que será el
NCP específico para el protocolo IP.
4.6.5.1. Funcionamiento de NCP
Cada NCP funciona de forma similar a LCP. Así, al igual que ocurría anteriormente, el
NCP realiza funciones para el establecimiento, mantenimiento y fin del enlace. Cada
Movicuo
172
NCP utiliza un subconjunto de siete mensajes definidos en LCP y lo usa de forma
similar a como lo hacía LCP. Estos mensajes son:
• Configuración del enlace: El proceso de negociación de parámetros del enlace
NCP (una vez que el enlace LCP está activo), es realizado utilizando Configure-
Request, Configure-Ack, Configure-Nak y Configure-Reject, de la misma forma
que en LCP (lo que cambiará obviamente, serán los parámetros negociados).
• Mantenimiento del enlace: Se enviará Code-Reject, para indicar valores
inválidos en la trama NCP.
• Terminación del enlace: Un enlace NCP puede finalizar utilizando Terminate-
Request y Terminate-Ack.
Para este proyecto, tan sólo utilizaremos un NCP que será IPCP, ya que los datos que se
envíen a través del enlace PPP serán datagramas IP. Por tanto, se explicará este
protocolo que será el que se aparecerá en las comunicaciones GPRS.
4.6.5.2. IPCP (Internet Protocol Control Protocol)
Cuando PPP deba transportar datagramas IP, el protocolo utilizado en la fase “protocolo
de nivel de red”, será IPCP. La configuración se hace usando los cuatro mensajes
“Configure-”. Para IP hay dos parámetros de configuración que pueden especificarse en
un mensaje Configure-Request.
• Protocolo de compresión IP: Permite a los dispositivos negociar el uso de la
compresión “Van Jacobson TCP/IP header compresion”. Esto comprime el
tamaño de las cabeceras TCP e IP para mejorar el ancho de banda.
• Dirección IP: Permite al dispositivo enviar el Configure-Request para
especificar una dirección IP que quiere usar, o para pedir al otro dispositivo que
nos proporcione una. Esto es lo que se hace al conectar a una red GPRS, pedir
una dirección de red al proveedor del servicio.
Proyecto Fin de Carrera. Ingeniería Informática
173
Al igual que pasaba antes, el dispositivo que recibe el mensaje puede devolver los
mensajes Configure-Ack, Configure-Nak o Configure-Reject que tendrán el mismo
significado que en LCP.
Una vez que la configuración se completa, los datos se pueden enviar al protocolo del
nivel tres que corresponda, según el NCP negociado. En nuestro caso sabemos que el
protocolo de nivel tres será IP. Esto estará indicado en el campo Protocol de la trama de
datos PPP que contenga a los datos provenientes del nivel de red.
A continuación se muestra otra figura en la que aparece el intercambio de mensajes que
aclara el funcionamiento del protocolo IPCP.
INICIADOR NO INICIADOR
Inicia la configuración IPCP
Procesa la petición de configuración IPCP
IPCP Configure-Request
IPCP Configure-Ack Finaliza la configuración IPCP
Establecimiento y autenticación del enlace LCP
Envío y recepción de datos IP
Recibe la petición de cierre IP. Se lo indica al otro
dispositivo Finaliza el enlace IP
IPCP Terminate-Request
IPCP Terminate-Ack Finaliza la configuración IPCP
Envío y recepción de otros datos que ya no son IP
Recibe la petición de cierre. Se lo indica al otro
dispositivo Finaliza el enlace
LCP Terminate-Request
LCP Terminate-Ack Finaliza la configuración IPCP
Movicuo
174
Figura 4.15 – Intercambio de mensajes IPCP
4.6.6. Protocolo de autenticación de PPP (PAP)
PPP se diseñó para proporcionar conectividad a nivel dos sobre distintas tecnologías de
nivel físico, algunas de las cuales son más sensibles a la seguridad que otras.
El conjunto de protocolos PPP incluyen protocolos de autenticación para su uso
opcional cuando sea necesario. Durante la activación del enlace a cargo de LCP, los dos
dispositivos pueden negociar el uso de protocolos de autenticación. Si están de acuerdo,
después de que LCP esté activo, pueden intercambiar mensajes para verificar la
identidad del dispositivo que inicia la comunicación. Solo si la autenticación es correcta
se podrá continuar con el resto de configuración.
PPP define, inicialmente, dos protocolos de autenticación, PAP (Password
Authentication Protocol) y CHAP (Challenge Handshake Authentication Protocol).
En las comunicaciones GPRS debemos utilizar PAP para realizar la autenticación, ya
que como ahora veremos, se adapta perfectamente a nuestras necesidades.
PAP es un protocolo de autenticación, cuyo funcionamiento consiste en dos pasos
básicos, los cuales se definen a continuación:
• Petición de autenticación: El dispositivo que inicia la comunicación envía un
mensaje Authenticate-Request que contiene el nombre y el password.
• Respuesta de autenticación: El dispositivo al que le llega la petición, mirará el
nombre y el password del mensaje recibido y decide si aceptar dicho dispositivo
o no. Si acepta, enviará de vuelta un mensaje Authenticate-Ack. Si no acepta,
responderá con un mensaje Authenticate-Nak.
Proyecto Fin de Carrera. Ingeniería Informática
175
Figura 4.16 – Intercambio de mensajes PAP
Como se ve, el mecanismo es sencillo. El problema es que PAP transmite el nombre de
usuario y la contraseña como texto por la red. Esto no es nada seguro ya que podrían
capturar nuestra contraseña con el problema que esto conlleva.
Para el caso de GPRS, esto no es ningún problema, ya que el nombre de usuario y la
contraseña son públicos y cualquiera puede obtener estos datos sin más que pedírselos
al operador correspondiente. Para los proveedores de la red GPRS, cuantas más
personas accedan a su red, mayor será su ganancia, de forma que no hay ningún
problema en que los datos no estén cifrados.
4.6.7. Formatos de las tramas PPP
PPP está formado por distintos protocolos, utilizados para enviar tanto datos como
información de control de diferentes formas. Cada uno de estos paquetes de información
irá en los mensajes (tramas), los cuales siguen un formato de trama determinado.
INICIADOR NO INICIADOR
Inicia la autenticación Comprueba el nombre de usuario y password
recibido
Autentícate-Request
Authenticate-Ack o Authenticate-NakSi todo ha ido bien, ya estamos
autenticados, si no, habrá que intentarlo de nuevo
Establecimiento del enlace LCP
Establecimiento del enlace NCP, funcionamiento normal
Movicuo
176
PPP comienza con un formato de trama general que abarca a todas las tramas enviadas
en el enlace, y luego incluye formatos más específicos para distintos propósitos.
Entendiendo estos formatos, se comprenderá más fácilmente el funcionamiento de los
protocolos PPP.
Veremos los formatos de trama más comúnmente utilizados para el envío de datos e
información de control sobre PPP. Se comienza explicando el formato general utilizado
por todas las tramas PPP. Después se listan las tramas específicas utilizadas por LCP y
PAP.
4.6.7.1. Formato general de las tramas PPP
Todos los mensajes enviados a través de PPP pueden ser, o datos o información de
control. Por datos entendemos la información de las capas superiores (datagramas) que
se transportarán por el enlace. La información de control se utiliza para gestionar el
funcionamiento de varios protocolos PPP. Aunque en PPP podemos encontrar muchos
protocolos, y por tanto muchos tipos de tramas, a un nivel superior todas ellas se ajustan
a un formato general de trama.
El funcionamiento básico de PPP está basado en el protocolo HDLC (High Level Data
Link Control). De hecho, la estructura de las tramas PPP utilizan el mismo formato
básico de trama que HDLC, hasta el punto de que se incluyen algunos campos que no
son estrictamente necesarios en PPP. El principal cambio es la inclusión de un nuevo
campo que indica el protocolo de los datos encapsulados. La estructura general de las
tramas PPP están definidas en el RFC 1662 y se muestra en la siguiente figura.
Proyecto Fin de Carrera. Ingeniería Informática
177
Figura 4.17 – Formato general de la trama PPP
Los campos de la esta trama tienen el siguiente significado:
Campo Tamaño (Bytes) Descripción
Flag 1
Indica el comienzo de una trama PPP. Tiene el valor “01111110” en binario
Dirección
1
En HDLC esta es la dirección del destinatario de la trama, pero en PPP tenemos un enlace directo entre dos dispositivos, por lo que este campo no tiene un significado real. Se establece a “11111111” que es equivalente a broadcast.
Control 1
Este campo se usa en HDLC para distintos propósitos, pero en PPP se establece a “00000011”
Protocolo 2
Indica el protocolo del datagrama encapsulado en el campo información de la trama.
Información Variable Cero o más bytes de payload que contienen datos o información de control, dependiendo del tipo de la trama. Para las tramas de datos, los datagramas de la capa de red se encapsulan en este campo. Para las tramas de control, los campos de información de control son situados aquí.
Relleno Variable En algunos casos, es necesario añadir algunos bytes de añadido para alcanzar el tamaño de la trama PPP.
Flag (01111110) Dirección (11111111) Control (00000011) Protocolo (Primer byte)
Protocolo (Segundo byte)
Relleno
Relleno
FCS (Comprobación) Flag (01111110)
INFORMACIÓN
0 8 16 24 32
Movicuo
178
Campo Tamaño (Bytes) Descripción
FCS 2 (ó 4) Frame Check Sequence es una suma de comprobación para proporcionar protección contra errores en la transmisión. Es similar al código CRC utilizado en otros protocolos de nivel dos, como el usado en Ethernet. Pueden ser de 16 ó 32 bits (por defecto 16 bits).
Este campo se calcula con los campos Dirección, control, protocolo, información y los campos padding.
Flag 1
Indica el fin de una trama PPP. Siempre tiene el valor binario “01111110”.
4.6.7.1.1. Rangos y valores del campo protocolo
El campo protocolo es el principal indicador del tipo de trama para el dispositivo que la
recibe. Para la trama de datos es el protocolo de nivel de red que creó el datagrama,
mientras que para las tramas de control, el protocolo PPP que creó el mensaje de
control.
Hay decenas de protocolos de nivel de red y protocolos de control PPP, y sus
correspondientes valores para el campo Protocolo. El estándar PPP define cuatro rangos
para organizar estos valores, como se muestra en esta tabla:
Rango del campo (Hex) Descripción
0000-3FFF Datagramas de la capa de red encapsulados que tienen asociado un NCP. En este caso, las tramas de control del NCP correspondiente utilizan un valor para el campo Protocolo que se calcula añadiendo 8 al primer octeto del valor Protocolo de la capa de red. Por ejemplo, IP es el valor 0021, y la trama de control de IPCP utiliza el valor 8021.
4000-7FFF Datagramas encapsulados de los protocolos que no tienen asociado un NCP
8000-BFFF Tramas de control NCP que corresponde al valor de Protocolo del nivel de red en el rango 0000-3FFF
Proyecto Fin de Carrera. Ingeniería Informática
179
Rango del campo (Hex) Descripción
C000-FFFF Tramas de control utilizadas por LCP, utilizadas por protocolos como PAP o CHAP.
El estándar también define que el valor del campo Protocolo debe seguir una regla: El
primer octeto es impar y el segundo es par. Así, 0x0021 es un valor válido, pero 0x0121
y 0x0120 no lo son.
La lista completa de los valores del campo Protocolo es mantenida por la organización
IANA (Internet Assigned Numbers Authority).
4.6.7.2. Formato de las tramas de control PPP y formato de las opciones.
El formato de trama general es utilizado por todos los tipos de trama definidos en PPP.
Dentro de ese formato, el campo información lleva encapsulado datos de usuario del
nivel tres, o mensajes de control. Esos mensajes de control contienen información
específica que es utilizada para configurar, gestionar y romper enlaces PPP.
Como hemos visto, hay muchos protocolos de control PPP: LCP, los NCP (el que nos
interesa es IPCP), PAP, y algunos otros.
Cada protocolo de control utiliza los mensajes de control de distinto modo pero hay
mucha similitud entre los mensajes de muchos de ellos. Esto es porque la mayoría de
los protocolos de control son un “subconjunto” adaptado de LCP.
Por lo tanto, las tramas de control tienen un formato común que se adecuan al formato
general de la trama PPP. Ese formato es el siguiente:
Campo Tamaño (bytes) Descripción
Código 1 Indica el tipo de mensaje de control
Movicuo
180
Campo Tamaño (bytes) Descripción
Identificador
1
Utilizado para “unir” las peticiones con las respuestas. Cuando una petición se envía, se genera un identificador que debe ser igual a la que se devuelva en la respuesta
Longitud
2
Longitud de la trama de control. Es necesario ya que el campo Datos es de longitud variable. Se especifica en bytes e incluye a todos los campos en la trama (Código, Identificador, Longitud y Datos)
Datos Variable Contiene información específica del tipo del mensaje.
Esta estructura es el payload de una trama PPP, lo que significa que se sitúa en el campo
Información de una trama PPP como muestra la figura 4.18. Así, el campo Longitud es
igual al tamaño del campo Información en la trama PPP. El campo Protocolo de una
trama de control será el protocolo que generó la trama de control (0xC021 para una
trama LCP).
Figura 4.18 – Formato de las tramas de control PPP con opciones
4.6.7.2.1. Mensajes de control PPP y valores del campo Código
El campo Código indica el tipo de trama dentro de un particular protocolo de control.
Algunos protocolos tienen un conjunto de códigos únicos utilizados sólo por ellos. Los
códigos se muestran a continuación:
Flag (01111110) Dirección (11111111) Control (00000011) Protocolo (Primer byte)
Protocolo (Segundo byte)
Relleno
Relleno
FCS (Comprobación) Flag (01111110)
DATOS
0 8 16 24 32
Código (tipo) Identificador Longitud (Primer byte)
Longitud (Segundo byte)
Proyecto Fin de Carrera. Ingeniería Informática
181
Valor del campo código Mensaje de control
1 Configure-Request
2 Configure-Ack
3 Configure-Nak
4 Configure-Reject
5 Terminate-Request
6 Terminate-Ack
7 Code-Reject
8 Protocol-Reject
9 Echo-Request
10 Echo-Reply
11 Discard-Request
12 Identification
13 Time-Remaining
14 Reset-Request
15 Reset-Ack
El contenido del campo de datos depende del tipo de mensaje. En algunos casos, no es
necesario enviar más datos, en cuyo caso el campo Datos puede omitirse. En otros
mensajes de control, llevará información relevante al tipo del mensaje. Por ejemplo, un
mensaje Code-Reject lleva en el campo Datos una copia de la trama que fue rechazada.
4.6.7.2.2. Formato de Opciones de los mensajes de control
Los distintos mensajes tipo “Configure-” son utilizados para configurar las opciones (o
parámetros) en LCP y en los otros protocolos de control. En los campos de Datos,
llevan una o varias opciones que son específicas para el protocolo que las utilice.
En la imagen 4.19 se muestra como estas opciones, que pueden variar en su longitud, se
sitúan en el campo de Datos de un mensaje de control PPP.
Movicuo
182
Figura 4.19 – Formato de las opciones en tramas de control PPP
Aunque las opciones sean distintas, se utilizará el mismo formato básico que se describe
a continuación:
Campo Tamaño (Bytes)
Descripción
Tipo 1
Indica el tipo del parámetro. El conjunto de los valores para este campo son únicas en cada protocolo.
Longitud 1 Longitud de las opciones en Bytes
Datos Variable Contiene los datos específicos para las opciones de configuración
Figura 4.20 – Formato de las opciones
En esta última parte se ha mostrado el formato general utilizado por los distintos
protocolos de control.
0 8 16 24 32
Tipo Longitud
Datos de la opción
Flag (01111110) Dirección (11111111) Control (00000011) Protocolo (Primer byte)
Protocolo (Segundo byte)
Relleno
Relleno
FCS (Comprobación) Flag (01111110)
Opción 1
Otras opciones o datos
0 8 16 24 32
Código (tipo) Identificador Longitud (Primer byte)
Longitud (Segundo byte)
Proyecto Fin de Carrera. Ingeniería Informática
183
Las partes más importantes se pueden resumir en los siguientes puntos:
• El mismo formato general de la trama PPP es utilizada para todas, incluyendo
las tramas de control. Su campo de Información contiene el payload, en el que
irá el mensaje de control (cuando la trama sea de control).
• La trama de control está estructurada usando el formato general. El valor Código
indica el tipo de trama de control para cada protocolo concreto. El campo Datos
es de longitud variable y contiene los datos para esa trama de control, que en
algunos casos puede contener uno o más parámetros de configuración.
• Para las tramas de control de configuración como Configure-Request y
Configure-Ack, el campo de Datos contiene un conjunto de opciones
encapsuladas. Cada opción tiene su propio subcampo de Datos que contiene los
datos específicos de dicha opción.
Para aclarar más aún estos conceptos, daremos ejemplos de los formatos de la trama
LCP y PAP.
4.6.7.3. Formato de las tramas LCP
Antes hemos visto el formato general utilizado por varios protocolos de PPP que
intercambian mensajes de control. El protocolo de control más importante es LCP (Link
Control Protocol). Además se utiliza como base para otros muchos protocolos de
control.
Existen muchas tramas distintas LCP, en concreto 13. Al tener muchos campos en
común, no vamos a explicar una por una cada una de esas tramas, ya que son bastante
parecidas y comparten muchos campos.
Veremos una explicación de cada una de esas trece tramas y el valor de sus campos, que
son las siguientes:
Movicuo
184
Tipo de Trama
Campo Código
Campo Identificador Campo Longitud
Campo de Datos
Configure-Request
1
Nuevo valor generado por cada trama
4+Longitud total incluyendo las opciones de configuración
Las opciones de configuración a negociar en el enlace
Configure-Ack
2
Copiado del campo Identificador de la trama Configure-Request de la cual esta es la trama de respuesta
4+Longitud total incluyendo las opciones de configuración
Opciones de configuración que son aceptadas.
Configure-Nak
3
Copiado del campo Identificador de la trama Configure-Request de la cual esta es la trama de respuesta
4+Longitud total incluyendo las opciones de configuración
Opciones de configuración que son asentidas negativamente
Configure-Reject
4
Copiado del campo Identificador de la trama Configure-Request de la cual esta es la trama de respuesta
4+Longitud total incluyendo las opciones de configuración
Opciones que son rechazadas
Terminate-Request
5
Nuevo valor generado para cada trama
4 (o más si se incluyen datos extra)
No es necesario
Terminate-Ack
6
Copiado del campo Identificador de la trama Terminate-Request a la que valida
4 (o más si se incluyen datos extra)
No es necesario
Code-Reject
7
Nuevo valor generado por cada trama
4+Longitud de la trama rechazada
Copia de la trama LCP que es rechazada (no la trama PPP completa, solo su campo Información)
Proyecto Fin de Carrera. Ingeniería Informática
185
Tipo de Trama
Campo Código
Campo Identificador Campo Longitud
Campo de Datos
Protocol-Reject
8
Nuevo valor generado por cada trama
6+Longitud de la trama rechazada
Los primeros dos bytes contienen el valor del campo Protocolo de la trama rechazada. El resto contiene una copia del campo Información de la misma trama.
Echo -Request
9
Nuevo valor por cada trama generada
8 (o más si se incluyen datos extra)
Contiene un número mágico de 4-bytes si se ha negociado, si no, se pone a cero.
Puede también contener datos adicionales.
Echo-Reply
10
Copiado del campo Identificador de la trama a la que responde.
8 (o más si se incluyen datos extra)
Contiene un número mágico de 4-bytes si se ha negociado, si no, se pone a cero.
Puede también contener datos adicionales.
Discard-Request
11
Nuevo valor generado para cada trama
8 (o más si se incluyen datos extra)
Contiene un número mágico de 4-bytes si se ha negociado, si no, se pone a cero.
Puede también contener datos adicionales.
Identificación
12
Nuevo valor para cada trama
8 (o más si se incluyen datos extra)
Contiene un número mágico de 4-bytes si se ha negociado, si no, se pone a cero.
Puede también contener datos adicionales.
Movicuo
186
Tipo de Trama
Campo Código
Campo Identificador Campo Longitud
Campo de Datos
Time-Remaining
13
Nuevo valor para cada trama
12 (o más si se incluyen datos extra)
Contiene un número mágico de 4-bytes si se ha negociado, si no, se pone a cero.
Puede también contener datos adicionales.
También un valor de 4-bytes que indican el numero de segundos que quedan en la sesión actual. Un valor de todos unos significa que la sesión no finalizará.
Las tramas 5, 6, 9, 10, 11, 12 y 13 permiten datos adicionales en el campo de Datos
cuyo uso no está definido claramente por el protocolo. El estándar PPP dice que estos
datos pueden ser cero o más octetos que contienen datos no interpretados para uso del
emisor, y pueden consistir en cualquier valor binario.
Todas las tramas LCP son encapsuladas en tramas PPP situándolas en el campo de
Información. El campo protocolo tendrá el valor 0xC021 para LCP.
4.6.7.4. Formato de la trama PAP
PAP es un protocolo de control que utiliza el mismo formato de trama básico ya
descrito. Sin embargo, como tiene un propósito distinto a LCP, utiliza un conjunto de
tramas distintas, con sus propios valores del campo Código.
PAP utiliza tres tramas distintas, que ahora veremos. Authenticate-Request tiene un
formato mientras que las otras dos tramas tienen dos tramas distintas. Ambos formatos
se muestran en las figuras 4.21 y 4.22, tras explicar cada trama.
Tipo de Trama
Campo Código
Campo Identificador
Campo Longitud
Campo de Datos
Proyecto Fin de Carrera. Ingeniería Informática
187
Tipo de Trama
Campo Código
Campo Identificador
Campo Longitud
Campo de Datos
Authenticate-Request
1
Valor nuevo para cada trama
6+Longitud del Peer-ID + Longitud del password
Valores del nombre de usuario y la contraseña. Esto se envía en los subcampos:
Longitud de Peer-ID (1 byte): Longitud del campo Peer-ID en bytes.
Peer-ID: Campo de tamaño variable, indica el nombre de usuario.
Longitud del Password (1 byte): Longitud del campo password en bytes.
Password: Campo de tamaño variable que contiene la contraseña del usuario a autenticar.
Authenticate-Ack
2
Autenticate-Nak
3
Copiado del campo Identificador de la trama a la que responde
5 + Longitud del mensaje
Contiene un subcampo de longitud del mensaje de un byte, que indica la longitud del subcampo Mensaje que lo sigue. Este campo Mensaje contiene una cadena de datos, que se usa para indicar si la autenticación fue correcta o falló.
Las siguientes figuras son los tres tipos de tramas posibles para el protocolo PAP. Como
se ve en la tabla y se demuestra en las figuras, las tramas Authenticate-Ack y
Authenticate-Nak tienen el mismo formato:
Movicuo
188
Figura 4.21 – Formato de la trama PAP Authenticate-Request
Figura 4.22 – Formato de las tramas PAP Authenticate-Ack y Authenticate-Nak
Flag (01111110) Dirección (11111111) Control (00000011) Protocolo (Primer byte)
Protocolo (Segundo byte)
Relleno
Relleno
FCS (Comprobación) Flag (01111110)
0 8 16 24 32
Código (tipo) Identificador Longitud (Primer byte)
Longitud (Segundo byte)
Longitud del Mensaje
MENSAJE
Flag (01111110) Dirección (11111111) Control (00000011) Protocolo (Primer byte)
Protocolo (Segundo byte)
Relleno
Relleno
FCS (Comprobación) Flag (01111110)
0 8 16 24 32
Código (tipo) Identificador Longitud (Primer byte)
Longitud (Segundo byte)
Longitud Peer-ID Peer-ID
Peer-ID Longitud Password Password
Password
Proyecto Fin de Carrera. Ingeniería Informática
189
5. Propuesta de solución de conexión GPRS sobre LinEx. GNOME-GPRS.
5.1. Especificación
Una vez estudiada la situación actual de las comunicaciones móviles y definido el vacío
que pretendemos suplir, se han detectado los distintos requisitos que nuestra
herramienta debe cumplir:
• Debe permitir la conexión a Internet a través de la red GPRS.
• Debe proporcionar una interfaz sencilla para que cualquier usuario pueda utilizar
esta herramienta, así conseguiremos que LinEx no sea una barrera para el acceso
a Internet a través de la tecnología GPRS, sino más bien una lanzadera para su
uso generalizado.
• Deberá regirse por las características que siguen las aplicaciones de
GNU/LinEx, y en general, las aplicaciones de software libre.
• Debe proporcionar facilidades en la instalación y configuración de la propia
herramienta.
• Deberá, en la medida de lo posible, dar información sobre la situación de la
conexión (a través de gráficas, velocidad, datos transmitidos,…).
• Deberá permitir la configuración de parámetros de la conexión para usuarios
avanzados.
• Deberá estar bien documentado, ya que son posibles innumerables mejoras,
principalmente el acceso a través de otras tecnologías de última generación que
puedan surgir.
• Todo el software generado y la documentación, será libre, de forma que el
conocimiento adquirido en esta investigación pueda ser aprovechado por otros
investigadores, así como el desarrollo podrá servir para la evolución tecnológica
de la que todos podremos beneficiarnos.
Movicuo
190
Con estas premisas, la solución al desarrollo software del problema planteado nos lleva
a considerar varias alternativas:
Alternativa 1: Script perl
La primera opción es elegir un lenguaje interpretado tipo script como perl, que permite
la integración de muchos módulos que extienden su funcionalidad. En concreto, el
módulo Tk permite utilizar interfaces gráficos a los scripts de Perl. Esto hace que el
script no sea únicamente ejecutado a través de la línea de comandos, sino con un
entorno que permite dar facilidades al usuario.
Realizar software con un lenguaje interpretado como Perl, tiene sus pros y sus contras.
Para este caso concreto, en el que la conexión GPRS debe ser controlada y
“monitorizada” cada segundo, esto puede suponer un problema.
Alternativa 2: Java o Mono
En primer lugar, hay que considerar a Java como una de las mejores alternativas a la
hora de desarrollar un software, sobre todo por su portabilidad. Existen varios IDE de
desarrollo para sistemas Linux muy completos como Eclipse o Net Beans y también
Java Builder aunque éste es propietario (Borland).
Hay que considerar el tipo de desarrollo que se va a realizar. Nuestro software va a ser
muy dependiente de la plataforma, por lo que la ventaja de la portabilidad, no nos va a
servir de nada.
Por su parte, Mono es una nueva plataforma de desarrollo, que implementa .NET libre
para sistemas Linux. Además, Mono tiene el apoyo de empresas como Ximian, que
aseguran la evolución de entornos de desarrollo como MonoDevelop. El lenguaje
utilizado si se elige esta alternativa es C#, ya que el autor tiene experiencia con él. Una
de las ventajas de la plataforma .NET y Mono en este caso, es que los programas
desarrollados con esta tecnología son portables a cualquier sistema que implemente el
Framework .NET. De la misma forma que ocurría con Java, la portabilidad en nuestro
Proyecto Fin de Carrera. Ingeniería Informática
191
caso no va a ser aprovechada ya que la aplicación parece claro que va a ser dependiente
de un sistema Linux.
Alternativa 3: Programación C/C++ bajo GNOME. GTK+
Como última alternativa, se plantea la posibilidad de realizar el desarrollo utilizando
programación GNOME, algo nuevo para el autor del proyecto.
Para realizar proyectos de este tipo, existen entornos de programación muy buenos
como Anjuta, al que se le puede integrar Glade, una herramienta que permite el
desarrollo de interfaces de usuario de una forma muy sencilla.
El desarrollo de aplicaciones GNOME se basa en el uso de librerías básicas como glib,
gtk, libglade, etc..., de las que se puede encontrar una completa referencia en la web del
proyecto GNOME.
Decisión:
Finalmente se ha decidido elegir la alternativa 3, por varias razones que a continuación
se explican:
• Movicuo es un proyecto que tiene una relación directa con el sistema
GNU/LinEx en particular, y Debian en general. Estos sistemas utilizan como
entornos de escritorio GNOME, y además si nos fijamos en las aplicaciones que
contiene GNU/LinEx, veremos que muchas de ellas están desarrolladas
siguiendo esta solución.
• La integración de la aplicación con el entorno es total, ya que las aplicaciones
desarrolladas de esta forma, tendrán un aspecto común, según el tema que tenga
establecido GNOME. Si se cambia de tema, automáticamente la aplicación
cambia de aspecto, lo que hace que el programa se vea como parte del sistema y
no rompa con él.
• Que el código sea compilado y no interpretado mejora el rendimiento, la primera
alternativa tenía una grave limitación en este sentido, además de que tras
estudiar las posibilidades que ofrecía Perl/Tk, todo el interfaz del usuario había
Movicuo
192
que realizarlo de forma manual, creando los widgets, situándolos en la pantalla,
modificándolos, etc.
5.2. Estudio de viabilidad
En este apartado se presenta el estudio realizado acerca de la factibilidad del proyecto
desde tres puntos de vista: Económico, operacional y técnico. Lo que obtendremos con
ello, será una visión de “alto nivel” de la totalidad del proyecto a realizar.
A continuación se presentan los resultados obtenidos de cada uno de estos apartados.
Viabilidad técnica
Desde el punto de vista técnico, este proyecto depende de algunos programas muy
concretos y de un lenguaje de programación que permita el desarrollo e implementación
de nuestra solución.
En este proyecto, el desarrollo de una herramienta de conexión GPRS va directamente
ligado al protocolo punto a punto (PPP). En sistemas como GNU/LinEx, existe el
demonio pppd, que es un programa que permanece ejecutándose continuamente en
segundo plano para dar servicio a las conexiones punto a punto.
Para la implementación de la herramienta, se ha optado por el lenguaje C. Existe gran
variedad de entornos de programación para este lenguaje sobre sistemas Linux. El que
se ha utilizado en este proyecto es Anjuta, y para el desarrollo del interfaz gráfico,
Glade.
De esta forma, los programas de los que dependemos y el lenguaje de programación
elegido serían técnicamente viables con estas aplicaciones:
• PPPD: Demonio que gestiona los enlaces PPP, encargándose de establecerlos,
mantenerlos y cerrarlos.
Proyecto Fin de Carrera. Ingeniería Informática
193
• Anjuta: Entorno de desarrollo C/C++ libre que facilita la implementación de
proyectos software.
• Glade: Aplicación para el desarrollo de interfaces de usuario que se integra
fácilmente con Anjuta, facilitando la unión entre la implementación y el diseño
del programa. Genera ficheros XML con toda la información del interfaz, lo que
permite su independencia del lenguaje de programación que lo controla.
• GNOME, GTK+, glib: Librerías que se van a utilizar a lo largo del desarrollo.
La documentación de las APIs se encuentran publicadas de forma libre en la
web de GNOME, lo que facilita su uso.
• RRDtool: Esta es una herramienta libre que permite almacenar y mostrar datos
(a través de gráficas) que se producen a través del tiempo. RRDtool significa
“herramienta de bases de datos en Round Robin”. Permite crear una base de
datos (*.rrd), guardar los datos en ella, recuperarlos y crear gráficos en distintos
formatos. Al igual que en Movicuo, esta herramienta es de uso común entre
aplicaciones libres que necesitan monitorizar el tráfico producido en una red.
Uno de esos programas es Ourmon, uno de los monitorizadores de redes más
completos en la actualidad (en el apartado “5.2.2. Manual del programador” de
este proyecto, se explica cómo se utiliza RRDtool en Movicuo, concretamente
en la aplicación desarrollada GNOME-GPRS para generar las gráficas de la
conexión).
Para realizar las pruebas, disponemos de varios equipos con distintas versiones del
sistema operativo para el que desarrollaremos la aplicación:
• Linex Woody 3.0r2
• Linex 2004
• Linex 2004r1 (Sarge)
Todas las herramientas que se utilizan en el proyecto se distribuyen de forma libre,
además de los sistemas operativos que se van a utilizar como base para las pruebas. Por
tanto, desde el punto de vista técnico, no habrá ningún problema para el desarrollo del
proyecto.
Movicuo
194
Viabilidad económica Dado el carácter de este proyecto, esta situación está asegurada. El proyecto completo
es llevado a cabo por un estudiante durante su último año de carrera. En todo caso, este
PFC surge a partir de un proyecto de investigación (AGILA) en el que el autor colabora,
el cual está patrocinado por la Conserjería de Educación, Ciencia y Tecnología de la
Junta de Extremadura, dentro del II Plan Regional de Investigación, desarrollo
tecnológico e innovación de Extremadura. Así, el proyecto tiene una financiación que
asegura que sea económicamente viable.
Viabilidad operacional Aunque la tecnología con la que se va a trabajar tiene una complejidad alta (descrita en
el apartado 3. Situación tecnológica actual), y el proyecto es muy novedoso al utilizar
tecnologías actuales como GPRS, esta viabilidad debe cumplirse, ya que este es un
Proyecto Final de Carrera de Ingeniería Informática, y la experiencia y formación del
autor de este proyecto, después de cinco años de estudio y desarrollo de otros proyectos
aseguran esta capacidad.
5.2.1. Análisis de costes.
Antes de comenzar a desarrollar el análisis de costes, debemos realizar una serie de
supuestos, ya que el proyecto será desarrollado por una única persona que no tiene
asignado un sueldo para éste proyecto en concreto. Así, simularemos que la única
persona encargada del proyecto ocupará el puesto de Analista-Desarrollador, por el cual
realizará todas las tareas que se requieran, teniendo un sueldo de 15 €/hora, mientras
que la jornada laboral vendrá indicada en cada fase.
NOTA: No en todas las fases se han trabajado las mismas horas a la semana, ya
que el autor del proyecto es un alumno, que ha tenido que compaginar el
proyecto con sus estudios de Ingeniería en Informática. En cada fase se indicarán
las horas trabajadas semanales. Las etapas iniciales tendrán menos carga de
trabajo, mientras que las últimas tendrán cargas de hasta 40 horas semanales,
Proyecto Fin de Carrera. Ingeniería Informática
195
debido a que en las últimas etapas del proyecto, el autor podía dedicarse casi por
completo a su desarrollo.
Por otra parte, el carácter de este proyecto hará que no se esperen beneficios
económicos, ya que la herramienta desarrollada va dirigida a la comunidad del software
libre, en particular a GNU/LinEx. Así, los beneficios que se obtengan serán distintos al
económico.
Como ya se ha indicado, este PFC queda encuadrado dentro del marco del proyecto
AGILA (http://patanegra.unex.es/agila), del “II Plan regional de investigación,
desarrollo tecnológico e innovación de Extremadura”, patrocinado por la Conserjería de
Educación, Ciencia y Tecnología de la Junta de Extremadura.
El proyecto AGILA comienza en Abril de 2004, por tanto se va a considerar el
comienzo del proyecto fin de carrera en esta fecha ya que la relación entre ambos es
inseparable.
5.2.1.1. Plan de desarrollo. Etapas del proyecto
Como todo proyecto, éste PFC ha seguido unas fases, que si bien no ha seguido una
metodología específica, si podemos asociarlas a las etapas del ciclo de vida
estructurado.
A continuación veremos las etapas identificadas con un estudio de costes para cada una
de ellas.
Como comienzo del proyecto, tomaremos la fecha de 19 de Abril de 2005.
Fase 0. Fase Previa Esta etapa es la primera que se realiza en el proyecto. Comienza cuando el autor se
incorpora al proyecto AGILA (19 de Abril de 2005), y dada la extensión e importancia
Movicuo
196
del proyecto, el primer objetivo será la creación de una página web desde la que se
describa el proyecto y se muestre el trabajo realizado.
También en esta fase será necesario preparar el equipo con el que cuenta el proyecto,
para que sea la base de las pruebas y desarrollos futuros.
En esta fase, se ha tenido una jornada laboral de 15 horas a la semana (3 horas diarias).
El resultado de esta fase será la web http://patanegra.unex.es/agila, así como la
instalación de GNU/LinEx Woody 3.0 r1 y Red Hat 9 en el ordenador recibido para el
proyecto, que tiene las siguientes características:
• Procesador Intel Pentium IV a 2800
• 2 Módulos de memoria RAM de 512 MB a 333 de velocidad
• 120 GB de Capacidad
• Tarjeta Gráfica NVidia GeForce FX 5200
• Teclado y ratón inalámbricos
• Módem interno
FASE 0 Datos Estimados Datos Reales Diferencia con la estimación
Comienzo 19 de Abril de 2004 19 de Abril de 2004 0 días Fin 19 de Mayo de 2004 19 de Abril de 2004 0 días Duración (días * horas diarias)
23 * 3 = 69 23 * 3 = 69 0 horas
Coste 69 * 15 = 1035 € 69 * 15 = 1035 € 0 €
Fase 1. Estudios iniciales Esta etapa inicial puede considerarse como la fase 1 del ciclo de vida estructurado
“Estudio del problema”. Comienza a partir de la fase anterior (20 de Mayo de 2004),
una vez que se tiene la web del proyecto y el ordenador con el que se va a trabajar. El
objetivo ahora es analizar y evaluar de forma profunda de las características de
conectividad y seguridad soportadas por GNU/LinEx.
En esta fase, se tiene una jornada laboral de 20 horas a la semana (4 horas diarias).
Proyecto Fin de Carrera. Ingeniería Informática
197
La salida de esta fase son los documentos:
• Seguridad en el sistema operativo GNU/LinEx.
• Conectividad proporcionada por el sistema operativo GNU/LinEx.
Estos documentos se encuentran disponibles en la web del proyecto AGILA:
http://patanegra.unex.es/agila.
FASE 1 Datos Estimados Datos Reales Diferencia con la estimación
Comienzo 20 de Mayo de 2004 20 de Mayo de 2004 0 días Fin 31 de Julio de 2004 31 de Agosto de 2004 + 10 días Duración (días * horas diarias)
52 * 4 = 208 62 * 4 = 248 + 40 horas
Coste 208 * 15 = 3120 € 248 * 15 = 3720 € + 600 €
Como se observa en la tabla, en esta fase se ha producido un retraso de 18 días
laborables (entre el 20 de Julio y el 31 de Agosto), ya que del 15 al 31 de Agosto no se
trabajó al estar de vacaciones.
Este retraso se debe a que se encontraron algunas complicaciones al entrar en detalle de
la conectividad y seguridad del sistema GNU/LinEx.
Fase 2. Evaluación de la conectividad Esta fase está muy relacionada con la salida de la anterior, ya que los documentos
generados en la anterior etapa servirán como base para evaluar las posibilidades de
conectividad del sistema operativo GNU/LinEx.
El objetivo de esta fase es la evaluación del rendimiento de distintas tecnologías
soportadas por LinEx, como son:
• RTC
• RDSI
• ADSL
Movicuo
198
La salida de esta fase es la revisión de los documentos generados en la etapa anterior, y
su ampliación, para recoger las pruebas realizadas.
Durante esta fase, se tiene una jornada laboral de 20 horas a la semana (4 horas diarias).
FASE 2 Datos Estimados Datos Reales Diferencia con la estimación
Comienzo 1 de Septiembre de 2004
20 de Mayo de 2004 0 días
Fin 31 de Octubre de 2004
10 de Octubre de 2004
- 12 días
Duración (días * horas diarias)
42 * 4 = 168 28 * 4 = 112 - 56 horas
Coste 168 * 15 = 2520 € 112 * 15 = 1680 € - 840 €
El adelanto resultante al finalizar la fase es debido a que una de las tecnologías a evaluar
como RDSI, no fue posible realizarla ya que no fue posible encontrar una red de estas
características para evaluarla sobre LinEx.
Fase 3: Estudio de la tecnología de comunicaciones móviles Una vez evaluadas distintas tecnologías de comunicación sobre GNU/LinEx, en esta
fase comenzamos a estudiar las tecnologías sobre las que versa este PFC. El estudio de
las tecnologías móviles de última generación (GSM, GPRS y UMTS), y la situación
actual en la que se encuentra son el objetivo de esta fase.
La salida de esta etapa es un documento de estado de las comunicaciones móviles de
última generación y una presentación sobre este mismo tema que el autor expuso en la
asignatura “Comunicaciones en Banda Ancha”.
Ambos documentos están disponibles en la web del proyecto AGILA
(http://patanegra.unex.es/agila).
El ritmo de trabajo en esta fase será también de 4 horas diarias (20 horas semanales).
Proyecto Fin de Carrera. Ingeniería Informática
199
FASE 3 Datos Estimados Datos Reales Diferencia con la estimación
Comienzo 11 de Octubre de 2004
11 de Octubre de 2004
0 días
Fin 22 de Diciembre de 2004
22 de Diciembre de 2004
0 días
Duración (días * horas diarias)
47 * 4 = 188 47 * 4 = 188 0 horas
Coste 188 * 15 = 2820 € 188 * 15 = 2820 € 0 €
En esta fase no hubo desfase de fechas, y todo fue según lo previsto.
Debido a la alta complejidad de las tecnologías que forman parte de este proyecto
(protocolos, componentes, funcionamiento, etc), el estudio de ellas, ha resultado una
tarea a la que se han dedicado muchas horas, no sólo en esta fase, sino que el autor a lo
largo de todo el proyecto, ha ido investigando acerca de estas tecnologías. Por tanto, en
esta fase, el documento generado es un estudio inicial del estado del arte, que a lo largo
del proyecto se ha ido completando y mejorando.
Fase 4. Análisis de la tecnología en LinEx Una vez estudiado el estado actual de la tecnología que pretendemos implantar en
GNU/LinEx, en esta fase se realiza un análisis exhaustivo de la forma de llevar esto a
cabo.
Esta fase responderá a la misma pregunta que la etapa de Análisis, en el ciclo de vida
estructurado: “¿Qué debe hacerse para resolver el problema?”.
También comenzará a dar respuestas a la pregunta relacionada con la fase de diseño del
sistema, “¿Cómo se resuelve el problema?”
Hay que tener en cuenta que la tecnología con las que vamos a trabajar es totalmente
novedosa para el sistema GNU/LinEx.
En esta etapa ya conocemos como funciona la tecnología pero no sabemos cómo
implementarlo. A lo largo de la fase se van conociendo algunos detalles a través de la
Movicuo
200
lectura de los distintos estándares y libros especializados, y se irán probando sobre el
sistema.
Además, a medida que se van conociendo nuevos detalles de las tecnologías que no
detectamos en la fase anterior, se irá revisando el documento que se generó en dicha
etapa, para ir completándolo.
En esta fase, se ha aumentado el ritmo de trabajo a 6 horas diarias (30 horas semanales).
FASE 4 Datos Estimados Datos Reales Diferencia con la estimación
Comienzo 23 de Diciembre de 2005
23 de Diciembre de 2005
0 días
Fin 28 de Febrero de 2005
15 de Marzo de 2005 + 11 días 0 días (ver NOTA)
Duración (días * horas diarias)
42 * 6 = 252 53 * 6 = 318 252 horas (ver NOTA)
+ 66 horas 0 horas (ver NOTA)
Coste 168 * 15 = 3780 € 318 * 15 = 4770 € 3780 € (ver NOTA)
990 € 0 € (ver NOTA)
NOTA: En la tabla se observa como ha habido un retraso de 11 días. Este retraso
se debe a algunos días no trabajados en las vacaciones de navidad y otros en la
convocatoria de exámenes de febrero, en la que el autor se examinó de varias
asignaturas de 5º de Ingeniería Informática. Por tanto, estos días de retraso no
aumentarán el coste del proyecto, ya que es como si los considerásemos no
laborables.
Fase 5. Diseño En esta etapa, se realizará el diseño del sistema. Abarca tanto el final de la fase de
“Diseño del Sistema”, como la fase completa de “Diseño Detallado” del ciclo de vida
estructurado.
A partir de las investigaciones realizadas en la fase anterior, vamos a aplicarlas para esta
etapa. Ya se conoce la tecnología a utilizar para la implantación de GPRS sobre
Proyecto Fin de Carrera. Ingeniería Informática
201
GNU/LinEx, y podremos establecer la solución a utilizar para resolver el problema que
nos ocupa.
En esta fase, se vuelve a aumentar el ritmo de trabajo, y se dedicarán 8 horas diarias (40
horas semanales)
FASE 5 Datos Estimados Datos Reales Diferencia con la estimación
Comienzo 16 de Marzo de 2005 23 de Diciembre de 2005
0 días
Fin 1 de Mayo de 2005 5 de Mayo de 2005 + 2 días Duración (días * horas diarias)
27 * 8 = 216 29 * 8 = 232 + 16 horas
Coste 216 * 15 = 3240 € 232 * 15 = 3480 240 €
Fase 6. Implementación En esta fase ya se escribe el código que permita la implantación de GPRS en
GNU/LinEx.
La etapa coincide con la fase de Implementación del ciclo de vida estructurado.
Utilizaremos la salida de las fases anteriores para desarrollar la aplicación.
En esta fase, la carga de trabajo aumenta en horas y en días. El incremento sube hasta
10 horas diarias, y 6 días a la semana (se trabajará el sábado), por lo que se dedican 60
horas semanales.
FASE 6 Datos Estimados Datos Reales Diferencia con la estimación
Comienzo 6 de Mayo de 2005 6 de Mayo de 2005 0 días Fin 18 de Junio de 2005 20 de Junio de 2005 + 1 día Duración (días * horas diarias)
38 * 10 = 380 39 * 10 = 390 + 10 horas
Coste 380 * 15 = 5700 390 * 15 = 5850 150 €
Fase 7. Pruebas
Movicuo
202
Esta etapa se corresponde completamente con la fase de pruebas del sistema del ciclo de
vida estructurado. Trataremos de comprobar y/o corregir:
• Funcionamiento esperado del sistema.
• Robustez del sistema.
• Facilidad de uso.
• Corrección de errores.
• Integrar la documentación
En esta fase, la carga de trabajo se mantiene con respecto a la anterior, es decir, 10 horas
diarias, y 6 días a la semana, por lo que se dedican 60 horas semanales.
Al ser esta la última etapa del proyecto, la documentación se finaliza en esta fase,
aunque durante todo el proyecto se ha ido realizando una memoria para que llegado este
momento, no haya que escribir toda la documentación. Por tanto, en esta fase, se genera
la documentación definitiva.
FASE 7 Datos Estimados Datos Reales Diferencia con la estimación
Comienzo 21 de Junio de 2005 21 de Junio de 2005 0 días Fin 2 de Julio de 2005 2 de Julio de 2005 + 0 días Duración (días * horas diarias)
11 * 10 = 110 11 * 10 = 110 + 0 horas
Coste 110 * 15 = 1650 110 * 15 = 1650 0 €
5.2.1.2. Datos globales
5.2.1.2.1. Costes y duración estimados
El coste estimado total ha sido de €, de los que han correspondido a cada fase los
siguientes:
FASE COSTE ESTIMADO
0 1.035 €
1 3.120 €
Proyecto Fin de Carrera. Ingeniería Informática
203
2 2.520 €
3 2.820 €
4 3.780 €
5 3.240 €
6 5.700 €
7 1.650 €
TOTAL 23.865 €
En la siguiente figura se muestran gráficamente los porcentajes de costes por fase.
0
1000
2000
3000
4000
5000
6000
Fase0
Fase1
Fase2
Fase3
Fase4
Fase5
Fase6
Fase7
Coste estimado
Figura 5.1 – Coste de cada etapa del desarrollo
Con respecto a la duración de cada fase, vamos a analizarla según las horas dedicadas y
no según los días, ya que como se ha explicado, no en todas las fases se dedicará el
mismo número de horas al día.
El gráfico de la duración de cada etapa es el siguiente:
Movicuo
204
050
100150200250300350400
Fase0
Fase2
Fase4
Fase6
Duración estimada (horas)
Figura 5.2 – Duración de cada etapa del desarrollo
Según las gráficas de las figuras 5.1 y 5.2, la fase 6, “Implementación”, es la que más
carga de trabajo tiene. Es lógico que esto sea así, ya que en la fase 6 se tiene que escribir
el código fuente de la aplicación. Aunque las especificaciones ya se han dado en las
etapas anteriores para minimizar el trabajo en esta fase, el tipo de programación
utilizada para desarrollar la herramienta ha sido nueva para el autor, que ha dedicado un
tiempo a aprender a manejarse con la programación en GNOME.
5.2.1.2.2. Costes y duración reales
El coste real que ha supuesto finalmente el proyecto es de €, de los que han
correspondido a cada fase los siguientes:
FASE COSTE REAL
0 1.035 €
1 3.720 €
2 1.680 €
3 2.820 €
4 3.780 €
5 3.480 €
6 5.850 €
7 1.650 €
TOTAL 24.015 €
Proyecto Fin de Carrera. Ingeniería Informática
205
A continuación mostramos una gráfica que comparan los datos de coste real y el
estimado.
0
1000
2000
3000
4000
5000
6000
Fase0
Fase1
Fase2
Fase3
Fase4
Fase5
Fase6
Fase7
Coste realCoste estimado
Figura 5.3 – Coste real y coste estimado del proyecto
De la misma forma, podemos obtener un gráfico que muestre la diferencia entre las
duraciones estimadas y reales.
050
100150200250300350400
Fase0
Fase2
Fase4
Fase6
Duración real (horas)Duración estimada (horas)
Figura 5.4 – Duración real y estimada del proyecto
La comparativa entre los datos reales y los estimados, muestran que las previsiones se
han cumplido en la mayoría de los casos. En los casos en los que ha aparecido un
desfase, éste es pequeño y no muy significativo. Finalmente, si comparamos el coste
estimado total y el coste real final, la diferencia es insignificante, así que podemos decir
que el resultado del análisis ha sido más que aceptable.
Movicuo
206
0
5000
10000
15000
20000
25000
Coste total realCoste total estimado
Figura 5.5 – Coste real y estimado del proyecto
5.3. Manual del programador
5.3.1. Introducción
Este manual del programador explica el funcionamiento interno de GNOME-GPRS, de
forma que cualquier desarrollador que quiera mejorar la herramienta tiene en esta guía
una referencia básica del programa.
GNOME-GPRS es una implementación que permite el uso de conexiones GPRS a
Internet en un sistema GNU/LinEx y sistemas Linux en general.
Está desarrollado bajo un entorno GNOME y utilizando librerías propias de este
entorno, como glib, gtk o libglade.
En el capítulo 3 de este proyecto se describe la tecnología GPRS sobre la que funciona
la aplicación. Ésta tiene como base GSM, y ambas forman un conjunto bastante
complejo. Además, su implantación y su integración en un sistema operativo como
GNU/LinEx, no ha resultado sencillo. Se recomienda conocer la tecnología, o al menos,
su forma de funcionamiento básico. Además, la lectura del capítulo 4, en la que se
explica cómo realizar conexiones GPRS en sistemas Linux, puede servir de gran ayuda
para comprender mejor el código de GNOME-GPRS.
Proyecto Fin de Carrera. Ingeniería Informática
207
En el manual de usuario de la aplicación puede encontrar información básica acerca de
su uso, por lo que una introducción más general puede encontrarse en dicho manual.
GNOME-GPRS ha sido desarrollado utilizando Anjuta como entorno de programación
y Glade como diseñador de interfaces de usuario, ya que ambas aplicaciones se integran
perfectamente para permitir el desarrollo de aplicaciones GNOME usando las librerías
propias de este sistema.
Así, el lenguaje que se ha utilizado para desarrollar la aplicación es C, que es el
utilizado comúnmente en este tipo de aplicaciones GNOME. El interfaz de usuario
generado por Glade, está escrito en XML, por lo que se independiza del lenguaje de
programación utilizado en el programa, es decir, con el fichero gnome-gprs.glade
(fichero XML), podremos generar un programa con el mismo interface de usuario que
GNOME-GPRS, pero escrito por ejemplo en C# (si usamos MonoDevelop), o python, o
cualquier otro lenguaje que lo permita.
5.3.2. Desarrollo de aplicaciones GNOME
GNOME es el acrónimo de “GNU's Not Unix Network Object Model Environment”. Es
un proyecto que tiene como objetivo proporcionar a los usuarios de sistemas Linux, un
entorno amigable, pero que sea a la vez potente.
La arquitectura de GNOME es lo que proporciona su gran funcionalidad. El conjunto de
herramientas base en GNOME se llaman GTK+ (the GIMP toolkit). Entender qué es y
cómo funciona GTK es necesario para comprender cómo funcionan los programas
GNOME. GTK+ es un conjunto de herramientas orientadas a objetos, utilizada para
crear aplicaciones independientes de GNOME.
GTK es una biblioteca para crear interfaces gráficos. GTK es fundamentalmente un API
orientado a objetos escrito en C, usando la idea de clases y retrollamadas (callback) a
funciones. Otro componente es Glib, que contiene funcionalidad adicional.
Movicuo
208
GTK tiene soporte para muchos lenguajes de programación, C, C++, Perl, Python, etc.
Los toolkits como GTK son colecciones de Widget, que a su vez son los controles de
interfaz de usuario como botones, cajas de diálogo y otros objetos.
Como puede imaginarse, tanto GNOME como GTK+ son proyectos muy amplios que
salen del ámbito de Movicuo, por lo que se aconseja que los desarrolladores que vayan a
utilizar GNOME-GPRS, aprendan acerca del funcionamiento de estas APIs.
La mayoría de la documentación que se puede encontrar sobre la programación
GNOME es libre y puede consultarse a través de Internet. Las referencias que el autor
de este proyecto aconseja son las siguientes:
• Glib reference manual (http://developer.gnome.org/doc/API/2.0/glib/index.html)
• Libglade reference manual
(http://developer.gnome.org/doc/API/2.0/libglade/index.html)
• GTK+ reference manual
(http://developer.gnome.org/doc/API/2.0/gtk/index.html)
• GTK+ 2.0 Tutorial (http://www.gtk.org/tutorial/)
5.3.3. Cómo programar conexiones GPRS en Linux
Para entender el funcionamiento interno de GNOME-GPRS, además de conocer el
funcionamiento de las librerías GNOME, GTK, Glib, ..., hay que saber cómo se realiza
una conexión GPRS en un sistema Linux.
GNOME-GPRS surge a partir del Proyecto Final de Carrera de Ingeniería Informática
Movicuo, el cual tiene entre sus objetivos implantar GPRS en un sistema GNU/LinEx,
para permitir conexiones a Internet a través de esta tecnología. Esto podrá permitir que
los usuarios de este sistema obtengan la máxima movilidad a la hora de navegar por la
red.
Proyecto Fin de Carrera. Ingeniería Informática
209
En la documentación de este proyecto se explica detalladamente la conexión a la red
GPRS para el acceso a Internet, por lo que recomiendo al lector que lea el apartado
cuatro del Proyecto Movicuo, titulado “GPRS en un sistema Linux”.
5.3.4. Especificaciones lógicas del sistema
El programa se ha desarrollado utilizando varios módulos que se comunican según las
estructuras que se definen a continuación.
Hay que tener en cuenta que esta aplicación ha sido programada bajo un entorno en el
que, al menos el autor, no ha tenido mucha experiencia anteriormente. Por ello, se ha
seguido una estructura sencilla que permitiera la conexión entre todos los módulos.
En la aplicación, el módulo gprs.h, contiene prácticamente todas las estructuras de datos
utilizadas y las definiciones de funciones y procedimientos necesarios. En una primera
aproximación, vamos a ver como se comunica el módulo principal (main.c), con este
módulo gprs.h:
Figura 5.6 – Primera aproximación a la estructura de la aplicación
En una segunda aproximación, veremos como se comportan el resto de módulos con
respecto a gprs.h. Este módulo será el nexo de unión entre todos los demás de GNOME-
GPRS. Veamos:
main.c
gprs.h
Movicuo
210
Figura 5.7 – Estructura general de la aplicación
Como se observa, todos los módulos dependen de gprs.h, que es donde se encuentran
las definiciones de las estructuras de datos que gobiernan la aplicación además de la
interfaz de los procedimientos y funciones utilizados en el programa.
Esta es una aproximación a la aplicación, ya que los módulos que aparecen en la figura
anterior son explicados con detalle en las secciones siguientes.
5.3.5. Estructuras de datos
Como se ha dicho, prácticamente todas las estructuras de datos de la aplicación se
encuentran en el fichero gprs.h. En este apartado vamos a explicar las más significativas
para que no haya duda sobre su utilidad.
Se comentan según su aparición en el fichero.
gprs.h
eggtrayicon.h eggtrayicon.c ppal.c
configuracion.c Log.c
conectando.c
Graficas.c
ficheros.c
detalles.c
deteccion_salidas.c
conectado.c
notificacion.c
Ppp_salidas.c
Proyecto Fin de Carrera. Ingeniería Informática
211
En primer lugar, definimos de forma explícita nuevos tipos de datos utilizando typedef.
En realidad no creamos nuevas clases de datos, sino que definimos un nuevo nombre
para un tipo existente. Esos tipos existentes son los que vamos a definir como
estructuras.
Las estructuras (struct) son colecciones de variables que se referencian bajo un único
nombre, proporcionando un medio eficaz de mantener junta la información relacionada.
Esta información en nuestro caso se relaciona de la forma que se explica a continuación.
Definiremos una nueva estructura para cada ventana de la aplicación, de forma que
tengamos una para la ventana principal, otra para la ventana de configuración, otra para
la ayuda, ... y así para todas las ventanas, es decir:
struct _win_ppal {
GtkWidget *window;
GtkWidget *label_proveedor_ppal;
GtkWidget *label_puerto_ppal;
GtkWidget *entrada_proveedor_ppal;
GtkWidget *entrada_puerto_ppal;
GtkWidget *boton_conectar;
GtkWidget *boton_graficas;
};
Esta es la estructura definida para la ventana principal. Definimos un nuevo Widget Gtk
para cada uno de los elementos del interfaz que componen la ventana y de los que
tendremos que modificar alguna característica. Todos serán GtkWidget, ya que en GTK,
la clase de la que heredan todos los botones, entradas de texto, y el resto de
componentes, es de la citada GtkWidget.
En el ejemplo, si observamos la ventana que se genera con Glade, se ve como muchos
de los elementos que aparecen en el interfaz, aparecen en la estructura
Movicuo
212
Figura 5.8 – Ventana inicial de GNOME-GPRS
Esto es así porque todos los elementos que la forman, modificarán alguna de sus
propiedades a lo largo de la ejecución del programa. El elemento
“entrada_puerto_principal” que es la entrada de texto asociada al puerto de conexión del
teléfono, cambiará por ejemplo su sensibilidad (que esté habilitado o no), el texto que
contiene, etc...
Los elementos que están en el interfaz y no están en la estructura, es porque no
modifican ninguna de sus propiedades en todo el programa. Así, el botón de ayuda, por
ejemplo, quedará igual durante todo el programa, por eso no se declara aquí.
De la misma forma que se ha explicado para la ventana principal se hace para:
• Ventana conectando
• Ventana conectado
• Ventana log
• Ventana detalles
• Ventana configuración
• Ventana ayuda
• Ventana acercade
• Ventana de análisis de las gráficas
• Los elementos a integrar en el área de notificación
• Ejecución del proceso PPP
Proyecto Fin de Carrera. Ingeniería Informática
213
• Proceso de detección del teléfono
• El programa en su conjunto (GNOMEGPRS)
En esta lista, además de cada una de las ventanas, aparece una estructura para el área de
notificación. Esto se realiza para tener “juntos” a todos los elementos que son necesarios
para la integración en el área de notificación.
También hay dos estructuras necesarias a la hora de definir procesos: Uno será el
proceso principal PPP que se lanza al conectar, y otro es el proceso wvdial que se
ejecuta cuando se quiere detectar el teléfono de forma automática.
El proceso PPP tiene la siguiente estructura:
struct _proceso_PPP{
const char *cmd[20];
int out_pipe;
int err_pipe;
int in_pipe;
int pid;
GError *error;
guint out_tag;
guint err_tag;
GIOChannel *out;
GIOChannel *err;
};
Se ve, como el “proceso_PPP” va a tener los elementos propios de los procesos UNIX,
un comando que lo ejecuta, un pid, distintos elementos para su salida estándar y otros
tantos para su salida con error. Esta es una de las estructuras más complejas que forman
parte de GNOME-GPRS.
De forma similar se define el proceso de detección.
Movicuo
214
La estructura del programa completo está compuesta por cada una de las estructuras
individuales que se han definido:
struct _GNOMEGPRS{
GnomeProgram *app;
GladeXML *xml;
/* interface */
win_ppal ventana_ppal;
win_conectando ventana_conectando;
win_conectado ventana_conectado;
win_log ventana_log;
win_detalles ventana_detalles;
win_configuracion ventana_configuracion;
win_ayuda ventana_ayuda;
win_acercade ventana_acercade;
win_graficas ventana_graficas;
GtkWidget *detectar;
GtkWidget *configurar;
area_notificacion notificacion;
gboolean acoplar;
gboolean conectado;
GtkIconFactory *icon_factory;
};
En esta estructura aparecen los elementos que componen el programa completo.
Todas estas estructuras de datos van a permitir que el programa se gestione de una
forma sencilla, ya que modificar una ventana, simplemente implica incluir un Widget
Gtk en su estructura correspondiente (Veremos que además, para cada elemento hay que
utilizar el método glade_xml_get_widget de la librería libglade).
5.3.6. Módulos
Proyecto Fin de Carrera. Ingeniería Informática
215
Como se ve en el apartado de “Especificación lógica del sistema”, el programa está
compuesto por el módulo gprs.h que define las estructuras de datos a utilizar y que se ha
explicado en el apartado de “Estructuras de datos”, y varios ficheros que son (por orden
alfabético):
• Ayuda.c
• Conectado.c
• Conectando.c
• Configuración.c
• Detalles.c
• Detección_salidas.c
• Eggtrayicon.c
• Eggtrayicon.h
• Ficheros.c
• Gráficas.c
• Log.c
• Main.c
• Notificacion.c
• ppal.c
• ppp_salidas.c
En este apartado se explica detalladamente cada uno de ellos para facilitar la labor al
desarrollador que quiera realizar alguna modificación.
Comenzaremos por el módulo principal main.c
NOTA: A lo largo de todo el manual se hace referencia a los ficheros de
configuración. Siguiendo la forma de trabajar de las aplicaciones GNOME (y las
aplicaciones de Linux), el programa crea un directorio oculto llamado gnome-
gprs que cuelga del directorio del usuario.
Movicuo
216
$home/.gnome-gprs/
5.3.6.1. Main
El módulo principal (en el que se aparece el método main), se encarga de inicializar las
variables y de integrar Glade con GNOME. Veamos como se realiza esto:
Una de las primeras sentencias que se ejecuta es:
gnome_gprs.app = gnome_program_init (PACKAGE, VERSION,
LIBGNOMEUI_MODULE, argc, argv, GNOME_PARAM_APP_DATADIR,
PACKAGE_DATA_DIR,NULL);
gnome_program_init se utiliza para integrar los widgets que se construyen con GTK.
Así se inicializa la aplicación GNOME cuando estamos utilizando la librería libglade. Si
no se utilizara libglade, la inicialización sería con gtk_init.
Luego aparecen una serie de líneas:
bindtextdomain (GETTEXT_PACKAGE, PACKAGE_LOCALE_DIR);
bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8");
textdomain (GETTEXT_PACKAGE);
Relacionadas con el soporte gettext, una librería GNU utilizada para localización e
internacionalización de los programas. La internacionalización debe ser una de las
mejoras que se planteen para GNOME-GPRS en próximas versiones.
Tras inicializar los valores de las variables, tendremos que realizar los pasos descritos a
continuación, necesarios para relacionar el interfaz desarrollado en glade con el código
de la aplicación:
Proyecto Fin de Carrera. Ingeniería Informática
217
• Cargamos el interfaz de usuario:
gnome_gprs.xml = glade_xml_new (PACKAGE_SOURCE_DIR"/gnome-
gprs.glade", NULL, NULL);
• Conectamos las señales definidas en el interfaz
glade_xml_signal_autoconnect (gnome_gprs.xml);
• Para cada Widget que vayamos a utilizar en el programa, debemos relacionarlo
con el nombre del widget que se definió en glade y que está en el fichero XML
con la extensión .glade. Por ejemplo, para la entrada de texto del puerto de la
ventana principal, ligamos la variable que teníamos en la estructura de la
ventana principal con el nombre que tiene en el fichero XML generado por
glade.
gnome_gprs.ventana_ppal.entrada_puerto_ppal = glade_xml_get_widget
(gnome_gprs.xml, "entrada_puerto_ppal");
• Finalmente, se lanza gtk_main();, que ejecuta el bucle de eventos. Esto significa
que una vez que se haya realizado la llamada a gtk_main, se cede todo el control
de la aplicación a GTK. Es decir, gtk_main no retorna hasta que se haga una
llamada a gtk_main_quit, que como su nombre indica, termina el bucle de
eventos GTK+. gtk_main_quit se ejecuta en cuando se pulse el botón Salir de la
ventana principal de la aplicación.
Movicuo
218
Esta es la estructura del programa principal de la aplicación, que es la estructura general
de un programa GNOME, usando las librerías GTK+ y libglade.
5.3.6.2. Ppal
Este es el módulo que gestiona la ventana principal. El único aspecto a destacar es el
evento que se lanza al pulsar el botón conectar. En ese momento, se crean los ficheros
de conexión según los valores que tenga el fichero de configuración en el directorio
.gnome-gprs en el directorio home del usuario. Los cuatro ficheros que se crean son:
• Configuracion.tmp: Es un fichero temporal que contiene la configuración de
gnome-gprs, y que se utiliza para realizar la conexión. Una vez se haya
conectado, el fichero pasará a ser Configuracion.conf, que se utilizará para
posteriores ejecuciones del programa, ya que sólo se guarda la configuración si
es correcta (es como un fichero “estable”), y la única forma de saber si es
correcta o no, es saber si con dicha configuración se ha llegado a conectar o no.
En el caso de que la conexión no se realizara correctamente, no se crea el
archivo Configuracion.conf, y la próxima vez que se ejecute el programa,
GNOME-GPRS tendrá que volver a ser configurado.
• Conectar: Es el fichero que se utiliza para realizar la conexión PPP. Contiene los
comandos AT que se van a negociar.
• Desconectar: Es el fichero que se encarga de enviar la cadena de desconexión.
Forma parte de la conexión PPP.
• Opciones-conexion-gprs: El tercer fichero utilizado por PPP. Aquí aparecen las
opciones de la conexión PPP, como el puerto utilizado, la velocidad, etc... y
tendrá referencias a los ficheros Conectar y Desconectar.
A continuación se ejecuta el proceso PPP. Para hacer esto, se utiliza una llamada a un
método de la API de Glib, una librería del núcleo de GTK y GNOME.
Proyecto Fin de Carrera. Ingeniería Informática
219
Gboolean g_spawn_async_with_pipes (const gchar *working_directory,
gchar **argv,
gchar **envp,
GSpawnFlags flags,
GSpawnChildSetupFunc child_setup,
gpointer user_data,
GPid *child_pid,
gint *standard_input,
gint *standard_output,
gint *standard_error,
GError **error);
Esta llamada ejecuta un programa hijo de forma asíncrona (el programa no se bloquea
esperando que el hijo acabe).
El programa hijo se especifica por el único argumento que será proporcionado, argv,
que debe ser un array de strings terminadas en NULL, para ser pasados como un vector
de argumentos al hijo.
La primera cadena en argv es el nombre del programa a ejecutar. Por defecto, el nombre
del programa debe ser un path completo.
Sólo se buscará en la variable PATH si pasamos la bandera
G_SPAWN_SEARCH_PATH.
Devuelve TRUE si todo va correctamente o FALSE si ocurre algún error
Es decir, el código que genera el proceso PPP es:
home = g_get_home_dir ();
fichero_ppp = g_build_filename (home, ".gnome-gprs", "opciones-
conexion-gprs", NULL);
Movicuo
220
i = 0;
proc_ppp.cmd[i++] = "pppd";
proc_ppp.cmd[i++] = "file";
proc_ppp.cmd[i++] = fichero_ppp;
proc_ppp.cmd[i++] = NULL;
if (!g_spawn_async_with_pipes (NULL,
(char **)proc_ppp.cmd,
NULL,
G_SPAWN_SEARCH_PATH,
NULL,
NULL,
&proc_ppp.pid,
&proc_ppp.in_pipe,
&proc_ppp.out_pipe,
&proc_ppp.err_pipe,
&proc_ppp.error)) {
g_warning (_("GNOME GPRS: El comando ha fallado: %s\n"),
proc_ppp.error->message);
g_error_free (proc_ppp.error);
proc_ppp.error = NULL;
} else {
// salida estándar
proc_ppp.out = g_io_channel_unix_new (proc_ppp.out_pipe);
g_io_channel_set_encoding (proc_ppp.out, NULL, NULL);
proc_ppp.out_tag = g_io_add_watch (proc_ppp.out,
(G_IO_IN | G_IO_HUP | G_IO_ERR),
on_salida_ppp,
NULL);
g_io_channel_unref (proc_ppp.out);
// salida de error
proc_ppp.err = g_io_channel_unix_new (proc_ppp.err_pipe);
g_io_channel_set_encoding (proc_ppp.err, NULL, NULL);
proc_ppp.err_tag = g_io_add_watch (proc_ppp.err,
(G_IO_IN | G_IO_HUP | G_IO_ERR),
on_error_ppp,
NULL);
g_io_channel_unref (proc_ppp.err);
Proyecto Fin de Carrera. Ingeniería Informática
221
}
Como se ve en el fragmento de código anterior, la estructura de datos definida en gprs.h
para el proceso PPP, toma aquí los valores correspondientes. La forma de realizar
conexiones GPRS en sistemas Linux a través de PPP, se ha explicado en el apartado 4
de este proyecto. Para entender mejor cómo se realiza la llamada y que ocurre una vez
que se lanza el proceso, se aconseja leer el capítulo citado.
5.3.6.3. Conectado
Una vez que estemos conectados, el control lo tendrá este módulo. Su principal
funcionalidad es la de detener la conexión de forma correcta, y la de ir actualizando
todos los datos informativos periódicamente.
Para detener la conexión, tan sólo hará falta el pid del proceso PPP, ya que matando ese
proceso se desencadena la detención. En la estructura de datos del proceso PPP que está
en gprs.h, uno de los campos es el pid. Con ese valor, simplemente tendremos que
hacer:
kill (proc_ppp.pid,2);
Esta sentencia mata el proceso ppp lanzado para realizar la conexión y se desencadena
la detención, que procesa el fichero Desconectar, creado cuando se pulsó conectar en la
ventana principal, y que tiene la secuencia de cierre.
Pero más interesante y compleja es la función encargada de actualizar la información de
la conexión periódicamente. La función se llama temporizador, y se divide en varias
partes bien diferenciadas.
Movicuo
222
Primero obtiene los valores del interfaz, paquetes de entrada, paquete de salida, bytes de
entrada y bytes de salida. Estos valores nos lo da una función que se encuentra en el
módulo detalles.c, que se explicará más adelante, pero básicamente lee los datos de un
fichero en el que se encuentra esta información.
Una vez tengamos los datos, hay que comprobar, con la información obtenida, si
estamos parados, enviando, recibiendo, o enviando y recibiendo información a la red.
Esto lo sabemos comparando los valores de los bytes que teníamos justo antes (1
segundo antes), con los que hay en este momento. Así, si ahora hay mas bytes recibidos
que antes, sabemos que estamos recibiendo, y si hay más bytes enviados que antes,
sabemos que estamos enviando. Si hubiera los mismos bytes enviados y recibidos que
en el instante anterior, estaremos parados.
Según el estado en el que nos encontramos, se lleva a cabo la actualización de la
ventana de información de la conexión. Se actúa prácticamente de la misma forma para
los cuatro estados posibles, con ligeras diferencias:
• Enviando y recibiendo: Actualizamos tanto los valores de entrada como los de
salida según la información recibida.
• Enviando: Actualizamos el valor de velocidad de subida según la información
recibida, y el valor de la velocidad de bajada es 0.
• Recibiendo: Se actualiza el valor de la velocidad de bajada con los datos
obtenidos y el valor de la velocidad de subida es 0.
• Parado: Los valores de la velocidad, tanto de subida y de bajada es 0.
Para los cuatro estados, si el soporte de gráficas está activado, ésta se actualiza con los
valores que acabamos de explicar.
Por último, se actualizan los valores de los paquetes enviados y recibidos, y las
direcciones IP tanto la que nos han asignado, como a la que estamos conectados. El
mecanismo para averiguar las direcciones IP es muy interesante, pero se explicará en el
módulo en el que está implementado, que es Conectado.c
Proyecto Fin de Carrera. Ingeniería Informática
223
5.3.6.4. Configuración
Este módulo es el encargado de manejar todos los eventos que se produzcan mientras
que el usuario se encuentre en la ventana de configuración modificando las opciones
(cambiando los combo-box, los radiobuttons, los checkbuttons, etc...).
Pero además está el proceso de detección del teléfono que es la parte más interesante de
este módulo.
Para detectar el teléfono, se va a utilizar wvdialconf, que es una herramienta utilizada
para la detección de módems, además de dar su bit rate máximo y el puerto al que está
conectado. En principio, wvdialconf genera un fichero de configuración para realizar
una conexión a través de wvdial, pero GNOME-GPRS sólo necesita la primera parte,
detección del puerto y de la velocidad.
A wvdialconf se le pasa un parámetro que es el nombre del fichero en el que va a
escribir la configuración. Como GNOME-GPRS no va a necesitar este archivo, el
parámetro que le pasamos es /dev/null (en sistemas Linux, esto es una especie de
“papelera”).
Al igual que se explicó para lanzar el proceso PPP, se utiliza
g_spawn_async_with_pipes, para lanzar el proceso de forma asíncrona.
i = 0;
proc_deteccion.cmd[i++] = "wvdialconf";
proc_deteccion.cmd[i++] = "/dev/null";
proc_deteccion.cmd[i++] = NULL;
if (!g_spawn_async_with_pipes (NULL,
(char **)proc_deteccion.cmd,
NULL,
G_SPAWN_SEARCH_PATH,
Movicuo
224
NULL, NULL,
&proc_deteccion.pid,
&proc_deteccion.in_pipe,
&proc_deteccion.out_pipe,
&proc_deteccion.err_pipe,
&proc_deteccion.error)) {
g_warning (_("GNOME GPRS: Error, fallo en el comando: %s\n"),
proc_deteccion.error->message);
g_error_free (proc_deteccion.error);
proc_deteccion.error = NULL;
} else {
// Salida estándar
proc_deteccion.out = g_io_channel_unix_new (proc_deteccion.out_pipe);
g_io_channel_set_encoding (proc_deteccion.out, NULL, NULL);
proc_deteccion.out_tag = g_io_add_watch (proc_deteccion.out,
(G_IO_IN | G_IO_HUP | G_IO_ERR),
on_salida_deteccion,
NULL );
g_io_channel_unref (proc_deteccion.out);
//Salida de error
proc_deteccion.err = g_io_channel_unix_new (proc_deteccion.err_pipe);
g_io_channel_set_encoding (proc_deteccion.err, NULL, NULL);
proc_deteccion.err_tag = g_io_add_watch (proc_deteccion.err,(G_IO_IN
| G_IO_HUP | G_IO_ERR),
on_error_deteccion,
NULL );
g_io_channel_unref (proc_deteccion.err);
}
La estructura de datos proc_deteccion está definida en gprs.h.
5.3.6.5. Detalles
Este es el módulo gestionar la ventana de información de la conexión. También es el
encargado de leer los valores estadísticos de la conexión que se van a mostrar, y que se
pasan a otros módulos (como a “conectado”).
Proyecto Fin de Carrera. Ingeniería Informática
225
Los datos y los paquetes enviados y recibidos, se toman del fichero /proc/net/dev. Este
archivo tiene el siguiente formato:
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo:41165020 233560 0 0 0 0 0 0 41165020 233560 0 0 0 0 0 0
eth0:30880893 257761 0 0 0 0 0 0 6692724 67243 0 0 0 21251 0 0
eth1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
wlan0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ppp0: 54 3 0 0 0 0 0 0 91 5 0 0 0 0 0 0
Como se ve, para cada interfaz nos da los bytes y los paquetes recibidos y transmitidos.
GNOME-GPRS saca los datos de información de la conexión de este fichero, que se va
actualizando continuamente.
La función get_detalles_transferencia, abre este fichero y lee las líneas hasta que
encuentra el interfaz que se está utilizando en la conexión PPP, y procesa la línea, para
quedarnos con los datos que nos interesan.
Para obtener los datos relativos a las direcciones IP, la función get_detalles_direccion
hace uso de los sockets. Para resolver el valor de las direcciones, se abre uno para el
dominio de Internet
socket (AF_INET, SOCK_DGRAM, 0)
En el buffer irá recibiendo estructuras ifreq, cuya definición aparece a continuación:
Movicuo
226
struct ifreq
{
char ifr_name[IFNAMSIZ];/* Nombre de la interfaz */
union {
struct sockaddr ifr_addr;
struct sockaddr ifr_dstaddr;
struct sockaddr ifr_broadaddr;
struct sockaddr ifr_netmask;
struct sockaddr ifr_hwaddr;
short ifr_flags;
int ifr_ifindex;
int ifr_metric;
int ifr_mtu;
struct ifmap ifr_map;
char ifr_slave[IFNAMSIZ];
char ifr_newname[IFNAMSIZ];
char * ifr_data;
};
Los elementos ifr_addr, e ifr_dstaddr, nos darán las direcciones IP local y la del destino
respectivamente para esta conexión.
5.3.6.6. Deteccion_salidas
Cuando en el módulo “Configuración” se vio la forma de lanzar el proceso wvdialconf
utilizando g_spawn_async_with_pipes, había que indicarle que métodos se usaban para
la salida estándar y para la salida de error. Esos eran on_salida_deteccion y
on_error_deteccion respectivamente, y están definidos en este módulo.
Así, la salida que vaya generando el proceso se va gestionando con la función
on_salida_detección. En él, vamos leyendo todas las salidas, para ver si se ha
encontrado un módem USB, un módem serie o no se ha encontrado módem.
Proyecto Fin de Carrera. Ingeniería Informática
227
Cuando el módem sea detectado, también podremos conocer su velocidad y el puerto al
que está conectado, ya que wvdialconf da esa información.
En la salida de error del proceso, gestionada por on_error_deteccion, no se espera
ningún mensaje ya que, en principio, este proceso no ha dado ningún problema en todo
el tiempo que se ha estado utilizando GNOME-GPRS.
5.3.6.7. Eggtrayicon
Este módulo hay que decir que no ha sido desarrollado por el autor de la aplicación,
sino que se ha obtenido de Internet, ya que es una librería de libre distribución (software
libre licenciado bajo GPL).
EggtrayIcon se utiliza para colocar un Widget GTK en el área de notificación del
escritorio de GNOME.
EggtrayIcon.h es la cabecera y tiene las interfaces de los métodos utilizados en
EggtrayIcon.c, que es donde se implementan.
A lo largo del programa (especialmente en el módulo Notificación), se llama a
funciones de este módulo.
5.3.6.8. Ficheros
En este módulo se gestionan los ficheros que se van a crear y a utilizar durante la
ejecución de GNOME-GPRS.
Hay varias funciones que realizan este cometido:
• Leer_configuracion: A partir del fichero de configuración, va rellenando las
opciones de GNOME-GPRS, según los valores que lee del archivo.
Movicuo
228
• Escribir_configuracion: Realiza la operación contraria, es decir, a partir de las
opciones de GNOME-GPRS realiza un fichero de configuración.
• Crear_ficheros_conexión: A partir de las opciones del programa crea un fichero
de configuración temporal, y los tres ficheros necesarios para la conexión PPP:
Conectar, desconectar y opciones-conexion-gprs.
• Crear_ficheros_rrd: El soporte de gráficas es proporcionado por una
herramienta rrdtool. Tenemos que crear los scripts que van a crear la gráfica, van
a insertar los valores y que van a generar la gráfica a partir de esos valores. Estos
ficheros son: crear.sh, insertar.sh y grafica.sh respectivamente.
Como se ha comentado, GNOME-GPRS utiliza varios ficheros temporales que se
utilizan durante la ejecución del programa, y que se almacenan en un directorio oculto
que cuelga del directorio local de cada usuario. Uno de los más importantes es el fichero
configuracion.conf (que tiene la misma estructura que configuración.tmp). Veamos
cómo está organizado este fichero y que valores puede tener cada uno de los campos
que contiene.
Los ficheros de configuración son archivos de texto, que en cada línea almacenan el
valor de una opción de GNOME-GPRS. El objetivo de estos ficheros es que el usuario
configure el programa una vez, y cuando éste funciones correctamente, ya las próximas
veces al ejecutar la aplicación, se cargarán esas opciones de forma automática, porque
en principio, un mismo usuario utilizará las mismas opciones de configuración durante
mucho tiempo, al menos hasta que cambie de dispositivo o de operadora.
El fichero configuracion.conf tiene el siguiente aspecto:
# Fichero de configuración de GNOME - GPRS # Generado automáticamente por la aplicación # Se aconseja no modificar este fichero manualmente Puerto = /dev/ttyACM0 Tipo = USB Velocidad = 460800 Compañia = Vodafone Nombre usuario = vodafone Contraseña = vodafone DNS dinamica = 1
Proyecto Fin de Carrera. Ingeniería Informática
229
Minimizar = 0 Integrar = 0 Activar QoS = 1 Soporte graficas = 1 Directorio = /root/graficas Activar control de flujo por hw = 0 Activar compresión de datos = 0 Prioridad = 1 Retardo = 1 Fiabilidad = 1 Throughput pico = 9 Throughput medio = 18 Pri_min = 1 Ret_min = 3 Fiab_min = 3 Thr_pico_min = 6 Thr_medio_min = 18 ;Fin de la configuracion
Cada línea guarda el valor de una opción del programa. Vamos a analizar cada una de
ellas por separado:
• Puerto: Nos dice dónde se conecta el teléfono al sistema. En el ejemplo es
/dev/ttyACM0.
• Tipo: Este campo no se utiliza para ninguna función relevante, pero el valor se
almacena para posibles usos en evoluciones del programa. Indica como es la
conexión. Por ahora se permiten conexiones Serie y USB.
• Velocidad: Este es el ratio que se puede llegar a utilizar en la conexión del
dispositivo con el ordenador. Se mide en bps. Hay que tener claro que no va a
ser la velocidad de la conexión a Internet.
• Compañía: Es el operador al que estamos suscritos, y que nos ofrece el servicio
GPRS para conectar a su red.
• Nombre de usuario y contraseña: Valores necesarios para la autenticación y que
son públicos, es decir, no tendremos una clave propia, sino la misma que todos
los que utilicen el servicio.
• DNS dinámica: Puede tener los valores de 0 y 1. Si es 0 quiere decir, que se usan
DNS manuales, por lo que en el fichero deben aparecer los campos DNS1 y
DNS2 que son las direcciones IP de cada uno de estos servidores. Si DNS
dinámica es 1, significa que las direcciones son solicitadas a la red durante la
Movicuo
230
negociación, por lo que los campos DNS 1 y DNS 2 no aparecen en el fichero de
configuración.
• Minimizar e Integrar: Valores booleanos (0 ó 1) que van a indicar el aspecto de
la aplicación una vez se realice la conexión.
• Activar QoS: Otro valor booleano que si está activado significa que se va a
realizar la conexión solicitando los valores de la QoS establecidas en el
programa. Si está desactivado, la conexión no realiza ninguna petición de QoS.
Los parámetros utilizados en el caso de que se active la QoS, son: prioridad,
retardo, fiabilidad, throughput máximo y throughput medio. Estos valores
aparecen en el fichero de configuración con su valor determinado. Estarán dos
veces, la primera aparición es de la QoS solicitada y la siguiente de la QoS
mínima. Los posibles valores de cada campo son:
o Prioridad: Entre 0 y 3
o Retardo: Entre 0 y 4
o Fiabilidad: Entre 0 y 5
o Throughput máximo: Entre 0 y 9
o Throughput medio: Valores entre 0 y 18 y el valor 31
El significado de cada uno de ellos, ya está explicado en otro punto del proyecto,
concretamente en el apartado “4.5.3 Activar conexión PPP”.
Además de los ficheros de configuración, se usan otros archivos, como los de
generación de gráficas que son scripts que interactúan con la herramienta rrdtool. Se
generan tres ficheros, uno para la creación de la base de datos rrd en la que van a
introducirse los datos, otro para la inserción de valores en la base de datos y un último
script para la generación de la gráfica a partir de los datos de la base de datos rrd.
Script crear.sh
#!/bin/bash\n rrdtool create /home/.gnome-gprs/gprs.rrd \\\n --step=1 \\\n DS:bajada:GAUGE:50:0:2100 \\\n DS:subida:GAUGE:50:0:2100 \\\n
Proyecto Fin de Carrera. Ingeniería Informática
231
RRA:AVERAGE:0.5:1:600 \\\n RRA:MAX:0.5:1:600 \\\n RRA:MIN:0.5:1:600 \n
Script insertar.sh
#!/bin/bash\n rrdtool update %s N:$1:$2 \n echo \"$(date +%s)\" >> /root/.gnome-gprs/comienzo.tmp",aux);
Script grafica.sh
#!/bin/bash\n read comienzo < $HOME/.gnome-gprs/comienzo.tmp\n ultimo=`rrdtool last $HOME/.gnome-gprs/gprs.rrd`\n rrdtool graph $1/veloc_gprs.png --start $comienzo-10sec --end $ultimo+10sec \\\n --imgformat PNG --title \"Velocidad de la conexion GPRS\" \\\n --vertical-label \"Kb/s\" \\\n --heigh 200 --width 300 \\\n DEF:veloc_bajada=$HOME/.gnome-gprs/gprs.rrd:bajada:AVERAGE \\\n DEF:veloc_subida=$HOME/.gnome-gprs/gprs.rrd:subida:AVERAGE \\\n LINE2:veloc_bajada#0000FF:\"Velocidad de bajada\" \\\n LINE2:veloc_subida#00FF00:\"Velocidad de subida\"
De todos los ficheros que se utilizan durante la ejecución de GNOME-GPRS, al cerrar
el programa tan sólo se conserva el fichero configuracion.conf en el caso de que la
conexión se haya establecido, ya que en el caso contrario, no nos interesa salvar una
configuración que no ha permitido conectar.
5.3.6.9. Notificación
Este módulo es el que se encarga de interactuar con EggtrayIcon, y de hacer todo lo
relacionado con la integración de GNOME-GPRS en el área de notificación.
Movicuo
232
Las funciones más importantes son las que inicializan la notificación, la actualizan, la
muestran y muestran el menú desplegable que aparece al pulsar el botón izquierdo sobre
él.
La inicialización hay que declarar todos los Widgets que se van a utilizar, y conectar sus
señales de forma manual. Para eso se utiliza la función:
g_signal_connect (G_OBJECT (gnome_gprs.notificacion.box),
"button_press_event", G_CALLBACK (on_evento_notificacion_bpress),
NULL);
que llama a on_evento_notificacion_bpress, cuando se produce el evento
“button_press_event”.
Esta función utiliza muchas funciones GTK de bajo nivel, así que, se recomienda mirar
el código de la aplicación cuando se haya leído algún manual de funcionamiento de la
API de GTK. La documentación oficial que se encuentra disponible desde la página
oficial de GNOME es el mejor manual que se puede encontrar y puede verse en la web:
http://developer.gnome.org/doc/API/2.0/gtk
La función que actualiza el botón del área de notificación recibe un parámetro que le
indica el estado en el que se encuentra la conexión (parado, enviando, recibiendo o
enviando/recibiendo). En función del valor recibido se pone el icono del estado
correspondiente, utilizando la función:
gtk_image_set_from_stock (GTK_IMAGE (gnome_gprs.notificacion.pixmap),
"sending",
GTK_ICON_SIZE_LARGE_TOOLBAR);
La función que controla las pulsaciones de ratón sobre el icono del área de notificación,
utiliza la siguiente sentencia para mostrar el menú que aparece al pulsar con el botón
derecho sobre él:
Proyecto Fin de Carrera. Ingeniería Informática
233
gtk_menu_popup (GTK_MENU (gnome_gprs.notificacion.menu),
NULL, NULL, NULL, NULL, event->button, event->time);
Este es el módulo que utiliza las librerías GTK de más bajo nivel, ya que el resto del
interfaz se ha diseñado a través de Glade.
5.3.6.10. PPP_salidas
Este módulo es similar a “detección_salidas”, ya que ambos gestionan la evolución de
procesos. En este caso, se controlan las salidas estándar y de error del proceso PPP
lanzado para crear la conexión GPRS.
Al igual que entonces, tendremos los métodos on_salida_ppp y on_error_ppp, que se
utilizaban en la llamada g_spawn_async_with_pipes del módulo ppal.
Las situaciones que se controlan con el método de la salida estándar son:
• Negociación de parámetros AT
• Conexión con el teléfono establecida
• Realizando autenticación
• Autenticación correcta
• Conexión realizada: Desencadena una serie de acciones como la integración en
el área de notificación si el usuario estableció esa opción, comienzo del
temporizador de conexión, y otras tareas menores.
• Control de errores en la comunicación debidos, bien a una negociación
incorrecta de parámetros de la QoS, o a un fallo de la conexión física por
haberse apagado el teléfono o haberse desconectado el cable.
• Conexión finalizada
La salida de error puede producir algunas otras situaciones, como:
Movicuo
234
• El teléfono no responde
• Imposible acceder al teléfono
En definitiva, en este módulo deben ir todas las comprobaciones que se necesiten para
detectar la situación en la que se encuentra la conexión y sus posibles fallos.
5.4. Guía de instalación y puesta en marcha
Para instalar el programa, es necesario en primer lugar, obtener el fichero gnome-
gprs.tar.gz donde se encuentra el código fuente del programa. Este archivo se puede
obtener del CD que acompaña a este manual, o bien descargarlo de la web:
http://patanegra.unex.es/agila/.
Una vez que tengamos el fichero en nuestro ordenador, la instalación se ha simplificado
para que resulte sencilla. Tan sólo habrá que realizar los siguientes pasos desde una
consola (terminal).
1. Se descomprime el fichero .tar.gz que nos hemos descargado en un directorio
temporal (supondremos que el fichero se encuentra en ese directorio):
#cd tmp #tar xvfz ./gnome-gprs.tar.gz
2. Una vez descomprimido el código fuente, realizamos la conexión:
#./instalar
A partir de ese momento, se desencadena el proceso de instalación de la aplicación.
Una vez que se ha ejecutado con éxito el comando anterior, el programa ya está
instalado en el sistema. Para comprobarlo y comenzar la ejecución de GNOME-
GPRS, simplemente tendremos que escribir en la consola:
#gnome-gprs
Proyecto Fin de Carrera. Ingeniería Informática
235
Y aparecerá la ventana inicial del programa. El programa de instalación crea un
acceso directo en el escritorio, por lo que también se puede acceder al programa
pulsando simplemente sobre el icono de GNOME-GPRS.
A continuación se van a explicar los procesos que se generan al ejecutar ./instalar, para
saber en todo momento que está ocurriendo. El script instalar, lo único que hace es
“unir” en uno sólo, los pasos típicos de compilación e instalación de una aplicación en
Linux, a partir de los ficheros fuente, además de copiar en el directorio correspondiente,
las imágenes que se utilizan en la aplicación. Estos comandos son:
#./configure #make
#make install (este posiblemente será necesario hacerlo como administrador del sistema). #cp –R ./pixmaps /usr/local/share/gnome-gprs #Comandos de creación del acceso directo.
Si algo fallara en el proceso de compilación o ejecución, puede obtener información
adicional en el archivo INSTALL que aparece tras la descompresión. En este fichero se
suministra información detallada acerca de estos procesos. Para ello, se ejecuta:
#less INSTALL
Las librerías que se necesitan para instalar GNOME-GPRS, puede que ya estén
instaladas en el sistema, ya que no utilizan librerías “comunes”. De todas formas, si
alguna no estuviera instalada, bastaría con acudir al programa de manejador de paquetes
de su distribución (en el caso de GNU/LinEx, este programa es synaptic) que ofrecen
facilidades de instalación de paquetes.
Al ejecutar ./instalar, el comando ./configure, descubriría si faltara alguno de estos
componentes, y se mostraría cual es.
En GNU/LinEx hay una forma muy sencilla de instalar los paquetes a través de apt-get.
Simplemente con escribir apt-get install nombre_paquete, comenzaría el proceso de
instalación.
Movicuo
236
NOTA: GNOME-GPRS utiliza una herramienta externa para realizar gráficas de
las conexiones. Esta aplicación es rrdtool, y puede instalarse de forma sencilla
en GNU/LinEx ejecutando:
#apt-get install rrdtool
Una vez finalizada la instalación, ya podrá activar el soporte de gráficas en la
configuración de GNOME-GPRS.
5.4.1. Posibles problemas durante la instalación
Si al realizar la instalación se produjo algún problema, seguramente este aparecería
durante la comprobación de librerías y dependencias del programa. A continuación se
muestran algunos errores comunes que se pueden producir al realizar la instalación,
acompañados de las soluciones correspondientes:
1. Si durante la comprobación de las dependencias, aparece el siguiente error:
#checking how to run the C++ preprocessor /lib/cpp #configure:error: C++ preprocessor “/lib/cpp” fails sanity check #see ‘config.log’ for more details
Significa que no tenemos instalado el compilador de C/C++ necesario para
realizar el proceso. Este error suele ocurrir al instalar la aplicación sobre
GNU/LinEx 2004, ya que no trae este componente de serie. Para solucionar este
problema, simplemente se instala el paquete g++ de la siguiente forma:
#apt-get install g++
2. También puede producirse otro error al comprobar las librerías de las que
depende GNOME-GPRS, por ejemplo, si aparece el siguiente error:
#No package ‘libgnomeui-2.0’ found
Proyecto Fin de Carrera. Ingeniería Informática
237
Nos está avisando de que el paquete libgnomeui no se encuentra instalado. Para
resolver este conflicto, lo instalamos:
#apt-get install libgnomeui-dev
De la misma forma se resolverían los problemas de dependencias con otros
paquetes.
5.5. Manual del usuario
5.5.1. Introducción
GNOME-GPRS es una aplicación que permite la conexión Internet, a través de la red
GPRS, desde un ordenador, utilizando como módem un teléfono móvil.
Con este software, podrá acceder a Internet desde cualquier lugar, sin más que conectar
su móvil (con servicio GPRS) al ordenador.
5.5.2. Entorno de trabajo
El entorno de trabajo de la aplicación ha sido diseñado con el objetivo de proporcionar
sencillez al usuario. Al ejecutar GNOME-GPRS, aparecerá la pantalla principal de la
herramienta, a partir de la cual se puede acceder al resto de opciones del programa.
5.5.3. Ejecución del programa por primera vez
GNOME-GPRS utiliza ficheros de configuración para establecer las opciones preferidas
de cada usuario. Cuando se ejecute el programa por primera vez, estos ficheros de
configuración no tendrán almacenada ninguna información, por lo que al lanzar la
aplicación aparece un mensaje indicando esta situación. Este mensaje puede observarse
en la figura 5.9.
Movicuo
238
Figura 5.9 – Mensaje inicial de GNOME-GPRS
5.5.4. Ventana principal
La ventana principal del programa tiene el un aspecto sencillo. Tras ejecutar el
programa por primera vez, o en general, cuando GNOME-GPRS no este correctamente
configurado, esta ventana aparece con el siguiente aspecto:
Figura 5.10 – Ventana principal de GNOME-GPRS
En la imagen se ve como muchos de los componentes de la pantalla están desactivados.
Esto quiere decir que el programa no conoce su valor, por tanto, los desactiva hasta que
no sean correctos.
Proyecto Fin de Carrera. Ingeniería Informática
239
Los componentes Proveedor y Puerto, que son entradas de texto no modificables, están
desactivadas hasta que no se configure el programa. De la misma forma, los botones
“Conectar” y “Analizar gráficas” están también desactivados. Más adelante veremos el
significado en detalle de estos botones.
En la parte inferior de la ventana GNOME-GPRS, aparecen tres botones, que sí están
activados, éstos son: Ayuda, Configuración y Salir. Al igual que antes, el significado de
cada uno de ellos se verá en detalle en las próximas secciones.
5.5.4.1. Botón “Salir” Al pulsar este botón, el usuario abandona la aplicación GNOME-GPRS y se cierran
todas las ventanas del programa que pudieran estar abiertas.
5.5.4.2. Botón “Ayuda”
Aunque GNOME-GPRS sea sencillo e intuitivo de utilizar, puede que un usuario en un
momento dado, no entienda alguna opción básica del programa. En ese caso, puede
acceder a la sección de ayuda a través de este botón.
NOTA: Hay que tener en cuenta, que algunas opciones son para usuarios
avanzados que tienen conocimientos de redes, ya que por ejemplo, el significado
de la calidad de servicio (QoS) no se explica con detalle en la ayuda del
programa, sino que se explica en este manual de usuario. Se ha optado por la
explicación en el manual y no en el programa porque un exceso de información
en una ventana no haría más que “saturar” al usuario.
La Ayuda se divide en cuatro pantallas, cada una de ellas explica el uso básico de un
determinado aspecto del programa.
Las cuatro pantallas de ayuda se muestran en las figuras siguientes (5.11, 5.12, 5.13 y
5.14):
Movicuo
240
Pestaña 1: Ayuda de GNOME-GPRS
Figura 5.11 – Ayuda de GNOME-GPRS
Pestaña 2: Ventana inicial
Proyecto Fin de Carrera. Ingeniería Informática
241
Figura 5.12 – Ayuda para la ventana inicial de GNOME-GPRS
Pestaña 3: Configuración
Movicuo
242
Figura 5.13 – Ayuda para la Configuración de GNOME-GPRS
Pestaña 4: Conectarse
Figura 5.14 – Ayuda para realizar la conexión a través de GNOME-GPRS
Como se ve en las cuatro imágenes anteriores, la parte inferior de la ventana es común
para todas ellas. Los dos botones que aparecen son “Acerca de” y “Cerrar”.
Cerrar, como su nombre indica, únicamente cierra la ventana de Ayuda, y vuelve de
nuevo a la pantalla principal del programa
Si se pulsa el botón “Acerca de”, aparecerá una nueva ventana típica en este tipo de
programas, en la que se ve la licencia con la que se distribuye y el autor del software.
Esta ventana se observa en la imagen 5.15.
Proyecto Fin de Carrera. Ingeniería Informática
243
Figura 5.15 – Ventana Acerca de…
Como se dijo, esta ventana da información del programa, su licencia y si pulsamos en
los créditos, mostrará los datos del autor del programa. La pantalla de créditos es:
Figura 5.16 – Créditos de GNOME-GPRS
En la pestaña de créditos se puede leer el nombre del autor y su dirección de correo por
si algún usuario quiere ponerse en contacto con él.
Movicuo
244
5.5.4.3. Botón “Configuración”
Al pulsar sobre el botón “Configuración” en la pantalla principal, accederemos a una de
las partes fundamentales de GNOME-GPRS, ya que para poder realizar la conexión, es
necesario seleccionar las preferencias.
Lo primero que veremos al acceder a esta sección del programa será una ventana con
cuatro pestañas, que definen cuatro tipos de opciones bien diferenciadas. Veamos cada
una de ellas por separado.
PARÁMETROS OBLIGATORIOS:
Este apartado de la configuración permitirá establecer las opciones mínimas sin las
cuales no se puede conectar. Hay que tener en cuenta que tan sólo configurando
correctamente estas opciones, la conexión se puede realizar sin ningún problema,
aunque si hacemos eso, no estaremos aprovechando todas las posibilidades que permite
GNOME-GPRS.
La imagen 5.17 muestra la ventana que permite la configuración de las opciones básicas
del programa.
Proyecto Fin de Carrera. Ingeniería Informática
245
Figura 5.17 – Ventana de configuración de los parámetros obligatorios
La ventana está claramente dividida en dos partes, la parte superior en la que se
configura el dispositivo (teléfono móvil) que tenemos conectado, y la parte inferior en la
que se configura el operador con el que se va a conectar (hay que estar dado de alta en
el servicio GPRS)
Para configurar el teléfono, debemos rellenar tres campos, aunque todos ellos pueden
ser rellenados de forma automática por GNOME-GPRS. Veamos primero la forma
manual.
Movicuo
246
La primera opción es seleccionar el puerto al que está conectado el dispositivo.
Podemos introducir el puerto directamente, aunque se aconseja seleccionarlo de la lista
desplegable, que contiene los siguientes posibles valores:
/dev/ttyS0
/dev/ttyS1
/dev/ttyS2
/dev/ttyS3
/dev/ttyS4
/dev/ttyACM0
/dev/ttyACM1
/dev/ttyACM2
/dev/ttyACM3
/dev/ttyACM4
/dev/ttyACM5
/dev/ttyACM6
/dev/ttyACM7
/dev/ttyUSB0
/dev/ttyUSB1
/dev/ttyUSB2
/dev/ttyUSB3
/dev/ttyUSB4
/dev/ttyUSB5
/dev/ttyUSB6
/dev/ttyUSB7
Los usuarios que estén acostumbrados a utilizar sistemas Linux, sabrán que la forma de
denominar a los puertos es a través de un “fichero” que cuelga de /dev, que será el
encargado de controlarlo.
Si seleccionamos alguno de estos puertos desde la lista desplegable, el segundo campo a
rellenar (Tipo de puerto), será automáticamente establecido como Serie o USB, que
significa el tipo de cable que conecta el teléfono con el ordenador.
Proyecto Fin de Carrera. Ingeniería Informática
247
La tercera opción es la velocidad soportada por el cable que realiza la conexión entre el
móvil y el ordenador. Este valor establece un límite superior en la conexión, es decir, si
elegimos la velocidad 9600 bps (9'37 kbps), quiere decir que los datos que lleguen al
teléfono de la red GPRS serán enviados al ordenador a una velocidad máxima de 9'37
kbps. Si la red en un momento dado, enviara datos al teléfono a mayor velocidad, por
ejemplo, a 20 kbps, no podrán enviarse los datos al ordenador a ese ritmo, y por tanto, el
límite máximo de la velocidad lo fijaría el cable de conexión y no la red GPRS.
La configuración de estos tres valores puede no ser sencilla. Por eso, se ha diseñado una
forma automática de realizarla que libera al usuario de esta tarea. Existe un botón
“Detectar”, que rellena los tres campos con los valores correctos. Si pulsamos sobre este
botón y el teléfono está conectado al ordenador, aparece la siguiente ventana:
Movicuo
248
Figura 5.18 – Proceso de detección del teléfono
Que rellenará los tres campos de la parte de Dispositivo, con el valor devuelto por el
teléfono. Si al pulsar sobre “Detectar”, no se encuentra ningún teléfono conectado al
sistema, aparece otra ventana de información advirtiendo de esta situación, en cuyo caso
no se rellena ningún campo.
Figura 5.19 – Posible resultado de la detección del teléfono
NOTA: Si en algún caso el teléfono estuviera conectado al ordenador, y no fuera
detectado, puede ser debido a varias razones:
• Asegúrese de que el teléfono no está apagado
Proyecto Fin de Carrera. Ingeniería Informática
249
• Puede que el sistema operativo no haya sido capaz de cargar el módulo
necesario para un determinado dispositivo. GNOME-GPRS detectará los
dispositivos que el sistema operativo sea capaz de reconocer. Si esto ocurre,
debe instalar el módulo necesario para su teléfono.
Una vez configurada la parte del dispositivo en los parámetros obligatorios, es necesario
que se den valores relacionados con el proveedor del servicio al que está suscrito, y que
le ofrece el servicio GPRS.
De nuevo tendremos otros tres valores para rellenar: Compañía, Nombre de usuario y
Contraseña. La compañía es el nombre del operador con el que queremos conectar,
mientras que el nombre de usuario y la contraseña son valores necesarios para la
autenticación a la red. Estos valores se pueden obtener simplemente llamando al
servicio de atención al cliente del operador correspondiente, aunque cuando elija el
valor Compañía desde el menú desplegable, tanto el Nombre de usuario como la
Contraseña se rellenan de forma automática con los valores correctos.
Por ahora, se han incluido las tres operadoras más importantes que trabajan en España,
como son: Vodafone, Amena y Telefónica Movistar. En las siguientes versiones de la
aplicación se espera contar con más operadoras, incluso se espera introducir la mayoría
de empresas telefónicas de Europa que ofrezcan el servicio GPRS.
PARÁMETROS AVANZADOS
Si ya se han rellenado los parámetros obligatorios, las siguientes opciones a configurar
son los parámetros avanzados, esta pestaña se muestra en la imagen 5.20.
Movicuo
250
Figura 5.20 – Configuración de los parámetros avanzados de GNOME-GPRS
Esta pestaña está dividida en cinco partes (DNS, Aspecto al conectar, QoS, Opciones de
las gráficas y Otros parámetros), que se explican detalladamente a continuación.
En la parte superior de la ventana está el apartado de los servidores DNS.
Estos servidores son una especie de “Páginas amarillas” de Internet, que nos permiten
utilizar nombres en lugar de direcciones IP. Es decir, si no tuviéramos servidores DNS,
tendríamos que escribir en la barra de direcciones del navegador su dirección numérica
216.239.59.99, en lugar del sencillo www.google.es y así para todas los sitios web que
quisiéramos visitar.
Proyecto Fin de Carrera. Ingeniería Informática
251
Encontramos una casilla de activación llamada Permitir DNS dinámica. Si está activada,
las direcciones IP de los servidores DNS son configuradas durante la activación de la
conexión, sin embargo, si desactivamos esta casilla, se habilitan tanto DNS 1 como
DNS 2 para que introduzcamos las direcciones IP de estos servidores.
Después de los DNS, aparece un apartado llamado “Aspecto al conectar”, que contiene
dos casillas de activación, y que establece el comportamiento de GNOME-GPRS una
vez que se realice la conexión.
La primera opción es Minimizar. Si la activamos, cuando nos conectemos, la ventana
GNOME-GPRS se minimiza y se lleva a la barra de ventanas. Cuando esté desactivada
y se realice la conexión, no se minimiza la ventana del programa y se quedará en el
centro de la pantalla como veremos después.
La segunda opción es “Integrar en el área de notificación”. Esta es muy útil cuando uno
esté acostumbrado al uso de la aplicación ya que cuando nos conectemos, las ventanas
de GNOME-GPRS desaparecerán y se crea únicamente un pequeño icono en el área de
notificación del panel del escritorio. Su aspecto será el siguiente:
Figura 5.21 – GNOME-GPRS integrado en el área de notificación
De esta forma, no queda ninguna ventana abierta de GNOME-GPRS, y tan sólo
tendremos un pequeño botón que irá cambiando según estemos enviando datos,
recibiéndolos o ambas cosas a la vez. Esto lo vemos detenidamente en apartados
posteriores.
Tras la configuración del aspecto, aparece el apartado dedicado a la calidad del servicio
QoS. Únicamente tendremos que decirle al programa si queremos activar la QoS o no.
Si decidimos activarla, tendremos que configurar las últimas dos pestañas de la ventana
QoS solicitada y QoS mínima. Si está desactivada, los valores de estas dos últimas
pestañas serán ignorados.
Movicuo
252
La Calidad de Servicio es “el rendimiento del servicio, que determina el grado de
satisfacción de un usuario de dicho servicio”, es decir, la QoS significa si la red
funciona correctamente o no. GPRS es una tecnología que es capaz de ofrecer esta
característica. Podemos seleccionar cuatro tipos de parámetros de calidad de servicio
que queremos que la red nos ofrezca: Prioridad, retardo, fiabilidad, velocidad máxima y
velocidad media.
La configuración de la Calidad de Servicio se explica en más adelante cuando acabemos
de definir las “Opciones avanzadas”.
Tras la QoS, GNOME-GPRS nos da la posibilidad de configurar las “Opciones de las
gráficas”. La aplicación nos permite ver gráficas durante la conexión para comprobar la
velocidad de subida y bajada de forma sencilla, rápida e intuitiva.
Si se activa la casilla de soporte de gráficas, se habilita una entrada de texto para
introducir la ruta completa del directorio en el que se van a almacenar las gráficas
generadas. Esto permitirá que una vez acabada la conexión podamos ver la gráfica para
analizarla. Para seleccionar el directorio, podemos hacer uso de otra facilidad de
GNOME-GPRS. Pulsando sobre examinar, tendremos acceso a un diálogo que nos
permite seleccionar un directorio (o incluso crearlos nuevos) del sistema.
Proyecto Fin de Carrera. Ingeniería Informática
253
Figura 5.22 – Diálogo de búsqueda de directorio
Para poder utilizar las gráficas, GNOME-GPRS hace uso de una herramienta externa:
RRdtool. Esto significa que hay que tenerla instalada para poder activar el soporte de
gráficas. GNU-LinEx no trae por defecto esta aplicación, pero es muy sencilla y rápida
de instalar. Tan solo escribiendo desde la línea de comandos:
apt-get install rrdtool
Esto instala la herramienta rrdtools que ocupa poco espacio (unos 3 Mb). No será
necesario configurar nada más.
Por último, en parámetros avanzados podremos configurar “Otros parámetros”. Aquí
podremos seleccionar dos opciones:
Movicuo
254
Activar control del flujo por hardware: Activando esta opción, estaremos permitiendo
una mejor comunicación entre el ordenador y el teléfono, ya que se usarán las señales
RTS y CTS en el interfaz entre ambos dispositivos.
Activar compresión de datos: Permite utilizar la compresión de la cabecera TCP/IP para
una mejor eficiencia de la transmisión.
QoS SOLICITADA
Hemos visto que una de las opciones de los parámetros avanzados es la activación de la
QoS. La QoS en GPRS define cuatro parámetros: Prioridad, retardo, fiabilidad,
throughput máximo y throughput medio. Tanto en este apartado como en el de QoS
mínima, hacemos referencia a estos parámetros que se explican a continuación:
Prioridad: También llamada precedencia, indica la prioridad con la que los datos de la
conexión van a ser tratados por la red. Normalmente, la red gestiona todos los datos de
la misma forma independientemente de la prioridad que tengan, excepto en ciertas
situaciones anormales (descartes de paquetes), en las que aquellos paquetes con
prioridades más bajas serán los primeros en ser descartados. Podremos elegir entre
cuatro valores:
• Prioridad alta: Los datos enviados con esta prioridad son los últimos en ser
descartados cuando se produzcan situaciones de congestión en la red.
• Prioridad media: Los paquetes que tienen esta prioridad se descartan antes que
los de prioridad alta pero después de los de prioridad baja.
• Prioridad baja: Estos datos serán los primeros en ser descartados, por delante de
la prioridad media y alta.
• Prioridad establecida por la red: Seleccionando este valor, permitimos a la red
que seleccione nuestra prioridad en función de los recursos libres y la capacidad
que tenga en ese momento.
Proyecto Fin de Carrera. Ingeniería Informática
255
Figura 5.23 – Configuración de la prioridad de la QoS solicitada
Retardo: Este parámetro establece el tiempo máximo para la transferencia de un paquete
de datos en la red GPRS. La clase de retardo 1, será la que establezca un menor tiempo
para la transferencia, mientras que la clase 3 será la que permita un tiempo mayor. La
clase 4 (best effort) no garantiza ningún tiempo para el retardo.
Movicuo
256
Figura 5.24 – Configuración del retardo de la QoS solicitada
Fiabilidad: La fiabilidad está definida en términos de errores residuales. Para cada
aplicación concreta se elige una u otra clase, dependiendo de la tasa de error y la
tolerancia a los errores de dicha aplicación. Si la aplicación tiene una menor tasa de
error y es sensible a errores, debemos elegir la clase de fiabilidad 1. Las clases de
fiabilidad bajas (como la 1 y la 2), no podrá ser tráfico en tiempo real, ya que para este
tipo de tráfico están las clases de fiabilidad más altas (como la 4 y la 5), que serán poco
sensibles a los errores y serán capaces de tolerarlos.
Proyecto Fin de Carrera. Ingeniería Informática
257
Figura 5.25 – Configuración de la fiabilidad de la QoS solicitada
Throughput máximo: Este valor indica la velocidad máxima que puede alcanzar la
conexión GPRS. Hay que tener en cuenta, que los valores más altos de la velocidad no
estarán soportados por la mayoría de las operadoras de ofrecen servicio GPRS.
GPRS no garantiza que se alcancen estos valores, ya que dependerá de los recursos
disponibles en la red y de las características del dispositivo con el que se realiza la
conexión.
Movicuo
258
Figura 5.26 – Configuración del throughput máximo de la QoS solicitada
Throughput medio: Este valor indica la velocidad media de la conexión. De los dos
valores que aparecen en cada opción, el primero son bytes/hora (el estándar GPRS
define así este parámetro), mientras que el segundo da esa misma cantidad medida en
Kbits/s, que es una medida mucho más normal. Aunque se puedan alcanzar velocidades
máximas mayores, la media de la conexión será mas baja debido a la naturaleza de las
aplicaciones, que emiten tráfico "a ráfagas". Al igual que en el retardo, Best effort no
garantiza ninguna velocidad concreta
Proyecto Fin de Carrera. Ingeniería Informática
259
Figura 5.27 – Configuración del throughput medio de la QoS solicitada
QoS MÍNIMA
Con la QoS solicitada, le indicamos a la red cuales son los valores de QoS que nos
gustaría tener. Luego la red puede darnos o no esos valores requeridos en función de la
disponibilidad de recursos que tenga, del número de usuarios conectados y muchos
factores más de los que depende la negociación.
Sin embargo, la QoS mínima va un paso más allá y establece los cinco valores de
Calidad de Servicio mínimos sin los cuales no se podrá realizar la conexión.
Por ejemplo, si seleccionamos todos los valores más altos de QoS mínima, es decir:
Movicuo
260
• Prioridad alta
• Retardo 1 (el mejor)
• Fiabilidad 1 (menor tasa de error)
• Throughput máximo de 2048 kbps
• Throughput medio de 111 kbps
Y realizamos la conexión con estos valores, lo normal es que la red no pueda ofrecernos
estas tasas, por lo que durante la negociación de los parámetros no se llegará a un
acuerdo entre el teléfono móvil y la red, y la conexión será rechazada. Esto lo podremos
ver ya que aparecerá un mensaje como este:
Figura 5.28 – Mensaje de error al conectar.
Este mensaje puede aparecer en otras ocasiones sin que la QoS sea la culpable del
rechazo, pero lo normal es que sea por esta razón.
Los valores de QoS mínima y QoS solicitada no podrán ser contradictorios, por eso al ir
seleccionando los valores de QoS mínima, se irán desactivando los valores que no se
puedan elegir en la pestaña de QoS solicitada. Por ejemplo, si tenemos en QoS
solicitada un valor de Throughput medio de 4'4 kbps y en QoS mínima establecemos el
valor de 22 kbps, entonces todos los valores menores de 22 kbps en la QoS solicitada
son deshabilitados y se pone como activo el valor de 22 kbps, ya que no es lógico
pedirle a la red una velocidad media más baja de la que le exigimos.
En resumen, los parámetros de QoS mínima son un límite inferior para los parámetros
de QoS solicitada.
Proyecto Fin de Carrera. Ingeniería Informática
261
A continuación aparecen las imágenes de los parámetros de calidad de servicio de “QoS
mínima”. Como se puede ver, son similares a los de “QoS solicitada”
Prioridad:
Figura 5.29 – Configuración de la prioridad de la QoS mínima
Retardo:
Movicuo
262
Figura 5.30 – Configuración del retardo de la QoS mínima
Fiabilidad:
Proyecto Fin de Carrera. Ingeniería Informática
263
Figura 5.31 – Configuración de la fiabilidad de la QoS mínima
Throughput máximo:
Movicuo
264
Figura 5.32 – Configuración del throughput máximo de la QoS mínima
Throughput medio:
Proyecto Fin de Carrera. Ingeniería Informática
265
Figura 5.33 – Configuración del throughput medio de la QoS mínima
POSIBLES ERRORES DE CONFIGURACIÓN
Hasta aquí, se han explicado las opciones de configuración de GNOME-GPRS, aunque
es posible que esa configuración seleccionada produzca errores. El programa controla
que todos los parámetros necesarios sean introducidos sin ninguna contradicción, y es
tarea del usuario introducirlos correctamente.
Estos errores se producen cuando el usuario pulsa el botón Aceptar en la ventana de
configuración. Entonces, si se ha detectado algún error en la configuración, aparece una
ventana que nos lo indica. Veamos los posibles casos de error:
Movicuo
266
Error en la configuración del puerto: Si no indicamos el puerto al que está conectado el
teléfono móvil, GNOME-GPRS no sabrá donde buscarlo, y mostrará el error que
aparece en la siguiente imagen:
Figura 5.34 – Error en la configuración del puerto
Error en la configuración de la velocidad: Si no damos un valor a la velocidad a la que
se debe conectar el teléfono con el ordenador, se muestra un error.
Figura 5.35 – Error en la configuración de la velocidad
Error en la configuración del operador: Este error aparece si el campo compañía de la
pestaña parámetros básicos no hay ningún nombre.
Figura 5.36 – Error en la configuración del operador
Error en la configuración del nombre de usuario: Si se queda vacío el campo Nombre de
usuario, se muestra:
Proyecto Fin de Carrera. Ingeniería Informática
267
Figura 5.37 – Error en la configuración del nombre de usuario
Error en la configuración de la contraseña: Si se queda vacío el campo Contraseña, se
indica de la siguiente forma:
Figura 5.38 – Error en la configuración de la contraseña
Error en la configuración de los servidores DNS: Si desactiva la casilla “Permitir DNS
dinámica”, deberá introducir manualmente las direcciones IP de los servidores DNS. En
caso de que no lo haga, se muestra un mensaje advirtiéndolo.
Figura 5.39 – Error en la configuración de los servidores DNS
Error en la configuración del soporte de gráficas: Si se activa la casilla “Activar soporte
de gráficas”, se deberá introducir un directorio en el que almacenarlas. Si no se
introduce un directorio, se muestra un mensaje advirtiéndolo.
Movicuo
268
Figura 5.40 – Error en la configuración del directorio de las gráficas
Error en la configuración del soporte de gráficas-rrdtool: Si al igual que en el caso
anterior, la casilla “Activar soporte de gráficas” estuviera activada, pero la herramienta
rrdtool que presta ese soporte no está instalada en el sistema, se mostraría un nuevo
mensaje indicando esta situación:
Figura 5.41 – Error en la configuración. La herramienta rrdtool no está instalada
5.5.4.4. Botón “Conectar”
El botón conectar inicialmente se encuentra deshabilitado, y no se puede pulsar. Se
mantendrá en esta situación hasta que la GNOME-GPRS esté configurado
correctamente. Así, una vez que la configuración es válida, este botón se habilita
permitiendo que sea pulsado.
Proyecto Fin de Carrera. Ingeniería Informática
269
Figura 5.42 – GNOME-GPRS configurado
Cuando se pulsa el botón, comienza el proceso de conexión a la red GPRS. El programa
debe negociar con la red la configuración elegida, para llegar a un acuerdo. Podremos
conocer el estado en el que se encuentra GNOME-GPRS a través de los mensajes que se
muestran en la ventana “Conectando”. La secuencia de mensajes en esta ventana que
veremos normalmente es la que se aparece en las siguientes imágenes.
Primero aparece el mensaje de que estamos conectando:
Figura 5.43 – Secuencia de conexión. Primer mensaje
Luego se establece la conexión entre el ordenador y el teléfono
Figura 5.44 – Secuencia de conexión. Segundo mensaje
Movicuo
270
Finalmente se negocian los parámetros con la red
Figura 5.45 – Secuencia de conexión. Tercer mensaje
Si todo ha ido bien, al finalizar la negociación estaremos conectados, y una ventana
aparece indicándolo, pero esto lo veremos más adelante. Vamos a ver qué otras
posibilidades permite GNOME-GPRS mientras conectamos.
Como se ve en las tres imágenes que explican la secuencia de activación, en la ventana
que da los mensajes, hay dos botones, “Log” y “Cancelar”.
Cancelar: Detiene el proceso de conexión a la red y vuelve a la pantalla principal de
GNOME-GPRS.
Log: Durante la conexión, tanto el teléfono como la red intercambian mensajes.
Pulsando sobre este botón, veremos el intercambio de dichos mensajes. Las dos
imágenes siguientes muestran el Log durante la conexión y el Log una vez finalizada.
Proyecto Fin de Carrera. Ingeniería Informática
271
Figuras 5.46 y 5.47 – Log durante la conexión y Log una vez establecida la conexión
Como se decía, una vez finalizada toda la negociación, la ventana “Conectando”
desaparece y aparece la ventana “Conectado”, que tiene el siguiente aspecto:.
Figura 5.48 – GNOME-GPRS está conectado a Internet
A través de esta ventana, podemos dar por finalizada la conexión y salir (pulsando sobre
el botón “Detener”), o bien acceder a la información de la actual conexión (pulsando
sobre el botón “Información”).
Los datos de la conexión que podemos conocer si pulsamos el botón información son:
Movicuo
272
• Interfaz: Los sistemas Linux, utilizan interfaces de red cuando realizan alguna
conexión. Este campo nos dice el que está siendo usado.
• Estado: Dirá si estamos parados, enviando información, recibiendo información,
o enviando y recibiendo a la vez.
• Velocidad (bajada): Muestra a qué velocidad de descarga está funcionando la
conexión en cada instante. Este valor se refresca cada segundo, y muestra la
velocidad en kb/s.
• Velocidad (subida): Similar al campo anterior, pero indica la velocidad de
subida.
• Dirección IP
• Destino: Dirección IP de la máquina a la que nos hemos conectado, y que nos
proporciona el servicio GPRS.
• Datos recibidos: Cantidad de información, en Kb, que nos han enviado.´
• Datos enviados: Cantidad de información, en Kb, que hemos enviado a la red.
• Paquetes recibidos: Número de paquetes, en este caso IP, que se han recibido de
la red.
• Paquetes enviados: Número de paquetes IP que se han enviado a la red.
• Gráfica de la velocidad de la conexión: Imagen que evoluciona en tiempo real,
mostrando la velocidad que se alcanza en cada momento. Será necesario tener
activado el soporte de gráficas, y haber instalado el paquete rrdtool.
Si se ha elegido el soporte de gráficas, en esta ventana de información aparece un
gráfico que indica constantemente la velocidad de la conexión. Esta ventana se muestra
en la figura 5.49.
Proyecto Fin de Carrera. Ingeniería Informática
273
Figura 5.49 – Información de la conexión con soporte de gráficas activado
Sin embargo, si no se ha activado el soporte de gráficas, la ventana de información
cambia según se muestra en la figura 5.50.
Movicuo
274
Figura 5.50 – Información de la conexión
Sus posibles estados son:
• Parado, no se envía ni recibe nada: El botón que aparece indica este estado
mediante dos flechas rojas.
• Enviando: El botón pasa a ser una flecha verde cuyo sentido indica la dirección
de subida.
• Recibiendo: El botón es una flecha verde cuyo sentido indica la dirección de
bajada.
Proyecto Fin de Carrera. Ingeniería Informática
275
• Enviando y recibiendo: El botón tiene dos flechas, una de subida y otra de
bajada y son de color verde.
El botón del área de notificación nos dará acceso también a varias opciones, según la
forma en la que lo pulsemos. Cuando lo pulsemos una vez con el botón izquierdo,
aparecerá la ventana “Conectado”, y al volver a pulsarla desaparece esta ventana. Al
pulsar con el botón derecho, se muestra un menú que tiene varias opciones:
• Log de la conexión: Muestra la ventana de Log que se mostró anteriormente.
• Detalles: Desde esta opción se accede a la ventana de información de la
conexión que se explicó antes.
• Desconectar: Da por finalizada la conexión.
Si mientras se está conectado, el teléfono se apaga o el cable se desconecta, la conexión
se cierra, y se muestra un mensaje indicando esta situación:
Figura 5.51 – Mensaje de error durante la conexión
5.5.4.5. Botón “Analizar gráficas”
Una vez finalizada la conexión, GNOME-GPRS nos permite analizar su evolución a
través de una gráfica. Podremos acceder a ella ya que el botón de la ventana principal
“Analizar gráficas” se activa cuando finaliza una conexión.
Movicuo
276
Figura 5.52 – Ventana principal tras conectar
Si se pulsa sobre este botón, se accede a una pantalla sencilla que contiene la imagen
final de la citada gráfica
Figura 5.53 – Ventana para analizar la gráfica de la conexión
Proyecto Fin de Carrera. Ingeniería Informática
277
5.6. Estudio práctico. Resultados
Para comprobar el correcto funcionamiento de la aplicación, se han realizado pruebas
prácticas con GNOME-GPRS para evaluar tanto la aplicación desarrollada, como la red
GPRS.
A través de estas pruebas y comprobando los resultados, analizaremos si el estudio de la
tecnología realizado en el apartado 3.3 de este proyecto, se corresponde con situaciones
reales. Con GNOME-GPRS las conexiones se van a realizar a Internet, por lo tanto, hay
que tener en cuenta esta situación a la hora de valorar los resultados. También hay que
decir que el módem (teléfono) utilizado ha sido un Motorola c353, un dispositivo clase
B multislot clase 8 (4+1), que como se explicó en el apartado “3.3.7 Tipos de
terminales”, utiliza 4 time-slots de bajada y uno de subida. Este es un dispositivo
bastante genérico ya que en la actualidad, la mayoría de los dispositivos son clase B y
tipo multislot clase 8 (4+1), debido al elevado coste de los de clase A.
Se han realizado varias pruebas que deben resultar concluyentes, y que se describen en
los apartados siguientes.
5.6.1. Caso 1. Tráfico constante sin QoS
El primer caso que se plantea en este estudio práctico es el análisis de una conexión con
un tráfico a Internet lo más invariable posible. Es decir, vamos a ver que ocurre cuando
se navega por Internet y esa conexión se “estabiliza”.
En principio, la transferencia de un fichero de gran tamaño, es uno de los casos en los
que la velocidad se muestra más constante. Antes de ver los resultados, se muestran las
opciones más importantes con las que se ha configurado GNOME-GPRS para esta
conexión.
Movicuo
278
Opción Valor Tipo de puerto USB
Velocidad conexión PPP 460800 bps
Operadora Vodafone
DNS dinámica SI
QoS activada NO
Control de flujo por Hw
activado
NO
Compresión de datos
activada
NO
La conexión realizada ha sido a
http://patanegra.unex.es/agila/archivo/comunicaciones_moviles_cba.zip, un fichero con
un tamaño aproximado de 1 MB.
La gráfica resultante de esta conexión es la siguiente:
Figura 5.54 – Gráfica de la conexión “estable” sin QoS
Proyecto Fin de Carrera. Ingeniería Informática
279
El eje Y indica el valor de la velocidad medida en kbps, mientras que el eje X es el
tiempo. Cada bloque vertical delimitado por dos líneas (verticales) punteadas, equivalen
a 30 segundos.
La velocidad de bajada mantiene una situación más o menos estable alrededor de los 45
kbps, con subidas hasta los 56 kbps y bajadas hasta los 11 kbps aproximadamente,
mientras que la velocidad de subida se mantiene durante toda la conexión por debajo de
los 5 kbps. Esto significa que hay grandes oscilaciones en la velocidad de bajada.
Nos fijaremos primero en la velocidad de subida que es mucho menor con respecto a la
de bajada. Por las características del terminal, esto es lógico, ya que el teléfono que se
utiliza para las pruebas utiliza tan sólo un slot de subida frente a cuatro de bajada. Más
adelante veremos que cada slot permite velocidades entre 9 y 20 kbps. En el tráfico de
Internet, el envío a la red es muy bajo, ya que principalmente, se emiten asentimientos y
mensajes de control, que son de tamaño mucho menor que los que la red envía al móvil.
Con respecto a la velocidad de bajada, las variaciones que se observan, son propias del
tráfico best effort de Internet, que también se verán acentuadas al transmitir sobre una
red GPRS, veamos porqué. En el capítulo 3, durante el estudio del interfaz aéreo de
GPRS, ya se comentó cómo el tráfico de varios usuarios puede compartir los recursos
de un mismo time-slot (bloques de 114 x 4 = 456 bits), algo que no ocurría en GSM.
Además, el tráfico generado por las llamadas (GSM) es priorizado frente al de datos
GPRS, en el sentido de que ocupa los recursos a menos que estos estén reservados
explícitamente para GPRS.
Para los usuarios de GPRS, los time-slots que no estén siendo utilizados por conexiones
GSM, son recursos disponibles que podrán compartir. Esto hace que la velocidad
alcanzada por una sesión de datos GPRS dependa mucho del resto de usuarios que
tienen necesidad de transmitir en la misma célula de cobertura, sobre todo los que lo
hacen a través de GSM (llamadas telefónicas). Es totalmente lógico que la velocidad
varíe mucho en conexiones GPRS, ya que en un momento dado, cuando hay muchos
usuarios de GSM conectados, la velocidad que alcanzaremos será baja debido a que los
slots están ocupados en esas llamadas. Sin embargo, en un momento inmediatamente
Movicuo
280
posterior, una de esas llamadas termina, liberando así uno de los slots ocupados, que
será utilizado por la conexión de datos GPRS que podrá aumentar la velocidad, hasta
que se produce otra llamada GSM, que “coge” de nuevo el slot, reduciendo otra vez la
velocidad de GPRS, y produciendo la misma situación.
La velocidad alcanzada en esta prueba, está en torno a los 45 kbps (con picos hasta los
56 kbps), mientras que a lo largo del proyecto se ha ido diciendo que el throughput
máximo alcanzado para GPRS podía llegar aproximadamente a los 170 kbps
(concretamente 171’2 kbps). Esta velocidad se alcanzaría en un estado ideal en el que se
cumplieran estos factores:
• Que no haya otras llamadas ni conexiones de datos en la célula en la que nos
encontramos (recordemos que el tráfico de las llamadas GSM tendrán prioridad
a la hora de asignar recursos frente a las conexiones de datos GPRS).
• Que los 8 time slots disponibles de una trama son asignados a un único usuario
al mismo tiempo y nadie más puede compartirlos
• Que no se utilice un esquema de codificación demasiado protector, ya que eso
provoca una menor tasa de velocidad.
En nuestro caso, la segunda premisa ya no se cumple, ya que en lugar de utilizar los 8
time slots, tan sólo vamos a disponer de la mitad, por limitaciones del terminal
utilizado. La capacidad de cada uno de estos time-slots varía entre 9 y 20 kbps
dependiendo del último factor, el esquema de codificación utilizado. Además la primera
premisa se cumplirá en muy raras ocasiones, y además no dependerá de nosotros, por lo
que el throughput que se alcance, no podrá ser asegurado en todas las conexiones.
Para el terminal que se está utilizando, cada time-slot tiene una capacidad aproximada
de 14’4 kbps ya que se está utilizando el esquema de codificación CS3. Una operación
sencilla nos da que la máxima capacidad del dispositivo es de 57’6 kbps de bajada y
14’4 kbps de subida. Recordemos las velocidades que se proporcionaban con cada uno
de los esquemas de codificación:
Proyecto Fin de Carrera. Ingeniería Informática
281
Esquema de
codificación
Bit rate
(kbps)
Bit rate - datos de
usuario (kbps)
CS-1 9’05 8
CS-2 13’4 12
CS-3 15’6 14’4
CS-4 21’4 20
Hay que tener en cuenta que otro posible “freno” a la velocidad podría venir impuesto
por la velocidad de la conexión PPP entre el teléfono móvil y el ordenador. Según la
configuración de GNOME-GPRS, esta velocidad es de 460800 bps, o lo que es lo
mismo, 450 kbps, por lo que esta opción no provocará ningún problema de velocidad
para la conexión.
Por tanto, si según la gráfica alcanzamos una velocidad de 56 kbps, y la velocidad
teórica máxima que podemos alcanzar con el dispositivo utilizado es de 57’2 kbps,
podemos decir que tanto la aplicación realiza bien su trabajo como que la red nos ofrece
el servicio que se esperaba.
5.6.2. Caso 2. Tráfico constante con QoS
Tras la primera prueba, en la que hemos obtenido un resultado razonable, es necesario
comprobar si la activación de la QoS, en esta situación influye para mejorar las
prestaciones de la conexión.
Al igual que en el caso anterior, se va a indicar en primer lugar, las opciones de
configuración de GNOME-GPRS.
Opción Valor Tipo de puerto USB
Velocidad conexión PPP 460800 bps
Operadora Vodafone
Movicuo
282
DNS dinámica SI
QoS activada SI
Control de flujo por Hw
activado
NO
Compresión de datos activada NO
Esta configuración únicamente cambia frente a la del primer caso en que la QoS está
activada, por tanto, también hay que indicar tanto la QoS solicitada como la QoS
mínima establecida.
Parámetro de QoS
solicitada
Valor
Prioridad Clase 1 (valor más
alto)
Retardo Clase 1 (retardo más
bajo)
Fiabilidad Clase 1 (menor tasa
de errores posible)
Throughput máximo Hasta 2048 kbps
Throughput medio 50.000.000
bytes/hora = 111
kbps
Parámetro de QoS
mínima
Valor
Prioridad Clase 1 (valor más
alto)
Retardo Clase 3 (retardo mas
alto)
Fiabilidad Clase 3 (tasa de
errores media)
Throughput máximo Hasta 256 kbps
Throughput medio 50.000.000
bytes/hora = 111
kbps
Proyecto Fin de Carrera. Ingeniería Informática
283
Se han utilizado estos valores de QoS ya que es el máximo valor que acepta. Para la
QoS solicitada, puede comprobarse que se han elegido los mejores valores en todos los
parámetros. De esta negociación no podemos esperar mucho, por eso en la QoS mínima
se reducen las pretensiones, aunque es una QoS aceptable.
Para comprobar el efecto de la QoS en la conexión, se ha hecho lo mismo que en el caso
1, de forma que sus resultados puedan ser comparables.
La gráfica obtenida en este caso es:
Figura 5.55 – Gráfica de la conexión “estable” con QoS
Se puede observar, que la velocidad de bajada se estabiliza, en cierto modo, en el valor
de 45 kbps (igual que en el primer caso), mientras que la velocidad de subida no pasa de
los 5 kbps (igual que en el primer caso). Los picos máximos llegan a los 56 kbps,
mientras que los menores bajan hasta los 22 kbps. Estos valores son similares a los
obtenidos en el caso 1, si acaso los picos más bajos se reducen.
Es lógico que esto sea así, ya que según la QoS negociada, la red va a ser capaz de
ofrecernos una velocidad media de 111 kbps, por lo que durante la conexión, tendremos
Movicuo
284
los slots necesarios para alcanzar esta velocidad. De esta forma, GPRS no debería tener
tantos problemas en la asignación de slots como los explicados para el caso 1. De todos
modos, aunque se haya negociado un throughput medio (mínimo) de 111 kbps y una
velocidad de pico (mínima) de hasta 256 kbps, el dispositivo que se utiliza para las
pruebas no permite alcanzar esa velocidad. Esto hace que no se pueda llegar a ninguna
conclusión acerca del efecto de la QoS en la velocidad, ya que por mucho que la red nos
ofrezca, no pasaremos de los 57’2 kbps que tiene de límite el móvil como se explica al
final del caso 1. El límite de la velocidad, en este caso, viene impuesto por el dispositivo
y no por la red GPRS.
5.6.3. Caso 3. Tráfico a ráfagas sin QoS
Una vez analizado el caso de una conexión con tráfico “constante”, veamos que ocurre
con un tipo de conexión mucho más típica en la navegación por Internet, el tráfico a
ráfagas.
Normalmente, la navegación por Internet implica que en un momento determinado, al
cargar una página, se necesiten muchos recursos, pero puede que en un instante
posterior, cuando la página está cargada, todos esos recursos sean liberados. Cuando la
página está cargada, el usuario normalmente tardará un tiempo en necesitar de nuevo
recursos ya que estará leyendo la página cargada. Este proceso provoca este tipo de
tráfico a ráfagas.
A lo largo de todo el proyecto, se ha ido viendo que las redes de conmutación de
paquetes como GPRS es buena para este tipo de tráfico, ya que en los momentos en los
que el usuario no necesite recursos, estos podrán ser utilizados por otros, por lo que
nadie monopoliza la red, que es gestionada de una forma mucho más eficiente que como
se hacía con las redes de conmutación de circuitos, en las que el usuario que tenía
asignado un recurso, no lo liberaba hasta que no finalizara la conexión, incluso aunque
no generase tráfico (durante los silencios de las llamadas).
Proyecto Fin de Carrera. Ingeniería Informática
285
Veamos las opciones de GNOME-GPRS que se han establecido para realizar la
conexión de la prueba.
Opción Valor Tipo de puerto USB
Velocidad conexión PPP 460800 bps
Operadora Vodafone
DNS dinámica SI
QoS activada NO
Control de flujo por Hw
activado
NO
Compresión de datos
activada
NO
A partir de esta configuración y generando el tráfico de la forma anteriormente
explicada, se ha obtenido la siguiente gráfica:
Figura 5.56 – Gráfica de la conexión “a ráfagas” sin QoS
Si esta gráfica la comparamos con las obtenidas para los casos 1 y 2, vemos que
realmente es muy distinta, aunque los picos máximos de velocidad sean similares,
llegándose a alcanzar los 55 kbps. Sin embargo, en esta conexión no podemos decir que
Movicuo
286
la velocidad se mantiene “estable” en ningún momento. Tanto el tráfico de bajada como
el de subida, se muestran muy cambiantes, teniendo los picos en los momentos en los
que se carga la página web, y descansando en los momentos siguientes, para volver a
otro pico que significa que otra web es solicitada.
Ahora la velocidad de subida es mucho más alta que en los dos primeros casos. Esto es
porque entonces, tan sólo había que enviar a la red asentimientos y algún mensaje de
control. En este caso, además de lo que se enviaba antes, transmitiremos otros datos
como los nombres de usuario y contraseñas del correo electrónico (que si van cifradas
ocupan más tamaño), mensajes que se escriben en foros, datos que escribimos en
formularios, juegos a través de Internet, … Es decir, al tener que interactuar en muchas
páginas web, la información que se envía a la red es necesariamente mayor que en los
casos anteriores.
5.6.4. Caso 4. Tráfico a ráfagas con QoS
En esta prueba se genera el mismo tipo de tráfico que en el caso anterior, un tráfico a
ráfagas típico en las conexiones a Internet.
La diferencia es que ahora, la configuración de GNOME-GPRS cambia para activar la
QoS. Las opciones de GNOME-GPRS por tanto, son las que se muestran en la tabla
siguiente:
Opción Valor Tipo de puerto USB
Velocidad conexión PPP 460800 bps
Operadora Vodafone
DNS dinámica SI
QoS activada SI
Control de flujo por Hw
activado
NO
Compresión de datos activada NO
Proyecto Fin de Carrera. Ingeniería Informática
287
Al tener activada la QoS, se han establecido valores tanto para los parámetros de la QoS
solicitada como para la QoS mínima, que son:
Parámetro de QoS
solicitada
Valor
Prioridad Clase 1 (valor más
alto)
Retardo Clase 1 (retardo más
bajo)
Fiabilidad Clase 1 (menor tasa
de errores posible)
Throughput máximo Hasta 2048 kbps
Throughput medio 50.000.000
bytes/hora = 111
kbps
Parámetro de QoS
mínima
Valor
Prioridad Clase 1 (valor más
alto)
Retardo Clase 3 (retardo mas
alto)
Fiabilidad Clase 3 (tasa de
errores media)
Throughput máximo Hasta 256 kbps
Throughput medio 50.000.000
bytes/hora = 111
kbps
Al realizar la conexión con esta configuración, y generando el tráfico antes explicado,
GNOME-GPRS genera la siguiente gráfica:
Movicuo
288
Figura 5.57 – Gráfica de la conexión “a ráfagas” con QoS
A primera vista, en esta gráfica se destaca por encima del resto la forma que sigue la
velocidad tanto de subida como de bajada, que van formando picos que llegan a
máximos en la bajada que superan los 56 kbps.
Realmente, no se puede apreciar mucha diferencia con el caso anterior, en el que no
había QoS, pero tanto el throughput medio como el máximo negociados, no se van a
poder alcanzar porque el dispositivo no lo va a permitir, como se decía en el primer caso
de este estudio práctico.
En esta gráfica parece que los picos altos son más frecuentes. Hay que ser muy
cuidadoso con sacar una conclusión de dependencia de este hecho con las conexiones
con QoS, ya que la frecuencia de picos altos puede depender de muchos factores que no
tienen nada que ver con la QoS, como los elementos multimedia que contenga una
página web (no es lo mismo cargar texto que imágenes), el tiempo que se tarda en
consultar otra página, etc.
El autor de este proyecto no tiene suficientes argumentos para asegurar que este hecho
es propio de las conexiones con QoS, aunque según las pruebas realizadas, parece que
Proyecto Fin de Carrera. Ingeniería Informática
289
existe alguna relación. Sería lógico que fuera así, ya que al tener activada la QoS, la red
nos debe “asegurar” los slots suficientes para alcanzar la velocidad media y de pico
negociada, que en este caso son de 111 y 256 kbps respectivamente.
5.6.5. Caso 5. Estudio de los retardos en conexiones GPRS
En los cuatro casos prácticos anteriores, se ha estado analizando principalmente cómo
responde el throughput en distintos casos reales. A lo largo del proyecto se ha hablado
en varias ocasiones de los parámetros de la calidad de servicio. Además del throughput
máximo y throughput medio, otro parámetro es el retado. En este “Caso 5”, se estudia el
comportamiento del retardo en las conexiones, que nos permite comprobar cual es su
variabilidad o jitter.
Al realizar la conexión, GNOME-GPRS permite elegir entre 5 clases de retardo
distintas, que son las cuatro clases que define el estándar, más la clase 0 que significa
que el valor es establecido por la red, en función de su capacidad y sus recursos
disponibles en ese momento.
Valores máximos del retardo
Tamaño SDU: 128 bytes Tamaño SDU: 1024 bytes
Clase de retardo
Retardo medio en
la transferencia
(segundos)
Retardo del
95% (seg.)
Retardo medio en la
transferencia
(segundos)
Retardo del
95% (seg.)
Clase 0 Valores establecidos por la red (según su capacidad)
Clase 1 < 0’5 < 1’5 < 2 < 7
Clase 2 < 5 < 25 < 15 < 75
Clase 3 < 50 < 250 < 75 < 375 Clase 4 (best effort) No especificado
En este caso práctico, analizaremos la influencia de la QoS y del tamaño del paquete en
el retardo. Los valores de los retardos que aparecen en la tabla, se refieren
Movicuo
290
exclusivamente, a los tiempos dentro de la red GPRS, por lo que una vez fuera de ella,
no se asegura ningún valor.
Para calcular el retardo de la transmisión, se utiliza la herramienta ping, que nos
indicará el RTT (Round Trip Time), o tiempo de ida y vuelta, para un paquete. En este
caso, se ha utilizado ping contra la máquina patanegra.unex.es, que se encuentra en la
escuela politécnica de Cáceres. Dado que los valores de QoS del retardo que define el
estándar hacen referencia al tiempo máximo de transferencia para un único paquete de
datos dentro de la red GPRS, los valores mostrados en la tabla anterior nos servirán
únicamente como referencia, ya que al realizar el ping sobre una máquina perteneciente
a una red externa, estos valores dejan de tener validez.
Por tanto, en esta prueba se ve cómo afecta la calidad de servicio al retardo,
comparando conexiones en las que se activa la QoS, con otras que no la tengan
establecida.
Se han realizado dos conexiones, una con QoS y otra sin QoS. Al igual que en los casos
anteriores, se indican los parámetros establecidos en GNOME-GPRS para cada una de
ellas.
Conexión sin QoS
Opción Valor Tipo de puerto USB
Velocidad conexión PPP 460800 bps
Operadora Vodafone
DNS dinámica SI
QoS activada NO
Control de flujo por Hw
activado
NO
Compresión de datos
activada
NO
Conexión con QoS
Opción Valor Tipo de puerto USB
Proyecto Fin de Carrera. Ingeniería Informática
291
Velocidad conexión PPP 460800 bps
Operadora Vodafone
DNS dinámica SI
QoS activada SI
Control de flujo por Hw
activado
NO
Compresión de datos activada NO
“QoS solicitada” para la conexión con QoS
Parámetro de QoS
solicitada
Valor
Prioridad Clase 1 (valor más alto)
Retardo Clase 1 (retardo más bajo)
Fiabilidad Clase 1 (menor tasa de
errores posible)
Throughput máximo Hasta 2048 kbps
Throughput medio 50.000.000 bytes/hora =
111 kbps
“QoS mínima” para la conexión con QoS
Parámetro de QoS
mínima
Valor
Prioridad Clase 1 (valor más alto)
Retardo Clase 3 (retardo mas alto)
Fiabilidad Clase 3 (tasa de errores
media)
Throughput máximo Hasta 256 kbps
Throughput medio 50.000.000 bytes/hora =
111 kbps
Para cada conexión se han realizado cuatro ráfagas de pings a patanegra.unex.es, en los
que cambia el tamaño del paquete, que será de 56Bytes, 128 bytes, 512 bytes y 1024
bytes.
Se van a ir presentando los datos para cada uno de los tamaños
Movicuo
292
56 BYTES
El resultado de la ejecución de
ping patanegra.unex.es
proporciona los siguientes datos:
Conexión sin QoS Conexión con QoS
RTT mínimo 716’6 ms 690’8 ms
RTT medio 773’6 ms 789’9 ms
RTT máximo 838’8 ms 917’9 ms
% paquetes
perdidos
4% 4%
Estos datos pueden verse de forma más detallada en la siguiente gráfica:
Figura 5.58 – RTT producidos por paquetes de 56 Bytes
128 BYTES
El resultado de la ejecución de
Proyecto Fin de Carrera. Ingeniería Informática
293
ping –s 128 patanegra.unex.es
proporciona los siguientes datos:
Conexión sin QoS Conexión con QoS
RTT mínimo 804’9 ms 808’9 ms
RTT medio 842 ms 840’3 ms
RTT máximo 868’7 ms 860’9 ms
% paquetes
perdidos
14% 4%
Estos datos pueden verse gráficamente en la figura 5.59.
Figura 5.59 – RTT producidos por paquetes de 128 Bytes
512 BYTES
El resultado de la ejecución de
ping –s 512 patanegra.unex.es
proporciona los siguientes datos:
Movicuo
294
Conexión sin QoS Conexión con QoS
RTT mínimo 1210’7 ms 1243’8 ms
RTT medio 1313’3 ms 1325’7 ms
RTT máximo 1572’9 ms 1486’9 ms
% paquetes
perdidos
0% 4%
Estos datos pueden verse de forma más detallada en la siguiente gráfica:
Figura 5.60 – RTT producidos por paquetes de 512 Bytes
1024 BYTES
El resultado de la ejecución de
ping –s 1024 patanegra.unex.es
proporciona los siguientes datos:
Conexión sin QoS Conexión con QoS
RTT mínimo 1771’9 ms 1790’8 ms
Proyecto Fin de Carrera. Ingeniería Informática
295
RTT medio 2232’6 ms 2166’9 ms
RTT máximo 2831’0 ms 2672’5 ms
% paquetes
perdidos
4% 9%
Esta información se observa con más claridad en la gráfica 5.61.
Figura 5.61 – RTT producidos por paquetes de 1024 Bytes
Según se puede ver en cada una de las gráficas mostradas y en las tablas de los datos
estadísticos, la diferencia entre los valores de las conexiones con QoS es mínimo frente
a los valores de aquellas sin QoS.
La variabilidad del retardo o jitter que se produce en estas conexiones, es aceptable.
Hay que tener en cuenta que en estas conexiones, el tráfico ha recorrido tanto la red
GPRS, como otro tipo de redes externas como Ethernet hasta llegar a la máquina a la
que se ha realizado el ping (patanegra.unex.es). Por tanto, el análisis del jitter, debe
hacerse con precaución, ya que no sólo afecta la red GPRS al valor de este parámetro,
sino todas las redes por las que pasa. A pesar de esto, el jitter producido en las pruebas
Movicuo
296
puede considerarse aceptable. Para cada una de las conexiones realizadas, la diferencia
entre el retardo máximo y el retardo mínimo no es muy alta. A medida que el tamaño
del paquete es mayor, el jitter producido también es más alto, pero dentro de unos
valores aceptables.
Para las conexiones sin QoS, el valor del retardo máximo cuando se envían paquetes de
1024 bytes (hay que sumar la cabecera ICMP, que es el protocolo que utiliza ping), es
de 2831 ms. Este es el tiempo de ida y vuelta, por lo tanto, podemos suponer que el
tiempo de ida es la mitad, 1415 ms aproximadamente.
Para las conexiones con QoS, el retardo máximo al enviar paquetes de 1024 octetos es
de 2672 ms. De la misma forma que antes, suponemos que el tiempo de ida y el de
vuelta son iguales, por lo que cada uno tiene un valor de 1336 ms. Si nos fijamos en la
tabla de los valores del parámetro de QoS “Clase de retardo”, el valor máximo que se
permite para la clase 3, que es la QoS con la que se ha realizado la conexión, es de 75
segundos.
Evidentemente, este valor es excesivo, y nunca se va a llegar a él, pero así está
establecido en el estándar, y por tanto, estamos dentro de los límites correctos. Todo
esto, teniendo en cuenta, que los valores de la tabla “Clase de retardo”, sólo valen para
la transferencia de los paquetes dentro de la red GPRS. Aún saliendo de la red GPRS
para acceder a patanegra.unex.es, estaríamos cumpliendo con el valor máximo
permitido.
No se ha encontrado prácticamente ninguna diferencia en el valor del retardo, entre la
conexión con QoS y sin QoS. Esto significa que la red tiene una buena respuesta para la
conexión en la que no hay QoS. Esto podría ser debido a una baja carga en la red en ese
momento, pero tras realizar todas las pruebas, esta no parece ser la razón fundamental, y
debemos suponer, que para una baja QoS en el retardo (Clase 3), éste no se distingue
prácticamente nada del valor que se produce cuando la conexión no tiene calidad de
servicio.
Proyecto Fin de Carrera. Ingeniería Informática
297
La red GPRS de Vodafone, no nos ha permitido realizar una conexión con un valor en
el retardo (“QoS mínima”) mejor que el de la clase 3, por lo que no se ha podido ver el
comportamiento del valor del retardo, con unos tiempos mucho más razonables y
normales que el de 75 segundos con el tamaño de 1024 bytes.
A continuación se muestra la gráfica generada por GNOME-GPRS, durante la
realización de estas pruebas. En este caso la gráfica corresponde a la conexión en la que
se han tomado los datos del retardo con QoS. Se puede observar perfectamente las
cuatro ráfagas de pings realizados. En primer lugar se realizan los de 56 Bytes (más las
cabeceras), luego los de 512 (más las cabeceras), los de 128 octetos, y finalmente los de
1024 bytes.
Con esto, se ha querido volver a demostrar que GNOME-GPRS genera las gráficas de
forma correcta.
Figura 5.62 – Gráfica generada por GNOME-GPRS en la que se comprueban las ráfagas de pings
5.7. Web del proyecto
Movicuo es un Proyecto Final de Carrera de Ingeniería Informática realizado con el
ánimo de servir de base para futuros proyectos relacionados con las tecnologías móviles
de última generación sobre sistemas Linux.
Movicuo
298
Para hacer accesible tanto la documentación como la herramienta GNOME-GPRS, se ha
creado una página web del proyecto en la siguiente dirección:
http://patanegra.unex.es/agila/movicuo
En esta página se encontrarán las actualizaciones de Movicuo, y se podrá descargar el
material asociado a él. Desde esta web también se podrá poner en contacto con el autor
del proyecto.
Proyecto Fin de Carrera. Ingeniería Informática
299
6. Conclusiones
Las comunicaciones inalámbricas en general, y las móviles en particular, tienen cada día
más beneficios. Parece claro que la libertad de movimiento que permite este tipo de
tecnologías no puede ser alcanzada por las redes de comunicaciones tradicionales,
aunque también es evidente que no serán utilizadas para el mismo propósito.
Incluso entre las propias redes de comunicaciones móviles es difícil realizar una
comparación, ya que casi todas tienen propósitos diferentes. Por ejemplo, si nos
centramos en GSM y GPRS, que son las tecnologías de 2G y 2.5G más importantes,
decir cual de ellas es mejor no tendría ningún sentido, ya que el uso que se le da a GSM
no tiene nada que ver con el que tiene GPRS.
GSM es una red de conmutación de circuitos utilizada para comunicaciones de voz, al
estilo de las redes telefónicas tradicionales, mientras que GPRS es una red de
conmutación de paquetes cuyo objetivo es mejorar la transmisión de otro tipo de datos
que no son voz. Ambas tecnologías tienen una eficiencia más que aceptable si se
utilizan para los propósitos para las que fueron diseñadas, mientras que si se utilizan
para otros cometidos, su rendimiento es realmente bajo. El ejemplo más claro de esta
situación es WAP, una tecnología diseñada para el acceso a Internet a través de la red
GSM, que fue un verdadero fracaso por culpa de la red sobre la que estaba
implementada.
Con esto, quiero decir que las tecnologías móviles han ido integrando nuevos servicios
a medida que se han ido necesitando, pero partiendo de la infraestructura existente.
Debemos ver el avance en el campo de las comunicaciones móviles como una
“evolución” y no “revolución”. Si llegamos a entender esto, seremos capaces de
comprender la forma de actuar de las organizaciones de estandarización.
En mi opinión, es ilógico intentar comprender qué es y cómo funciona GPRS sin
conocer GSM, de la misma forma que no parece adecuado trabajar con UMTS sin saber
la forma de actuar de GPRS y GSM.
Movicuo
300
Desde el punto de vista práctico, al no poder explotar todas las capacidades de la red,
por no tener un dispositivo lo suficientemente potente, no se ha podido comprobar cual
es el límite real que pone la red GPRS, aunque hay que decir, que el dispositivo es del
tipo más común que se encuentra ahora mismo en el mercado, por lo que los resultados
de este estudio son totalmente válidos para la mayoría de los casos.
El dispositivo que tenemos, permite un throughput máximo de 57’2 kbps según se
explicó en el caso 1 del estudio de resultados de GNOME-GPRS. Esta velocidad no
permite que “exprimamos” las capacidades de la red GPRS para ver cuando comienza a
flaquear, que hubiera sido lo deseable, pero se han llegado a unas conclusiones que
coinciden totalmente con los aspectos teóricos explicados en la primera parte de este
proyecto, y que de alguna forma, han validado la aplicación desarrollada ya que genera
los resultados esperados.
A pesar de obtener los resultados esperados, hay que tener en cuenta la complejidad de
la tecnología con la que GNOME-GPRS realiza la conexión a Internet. El trabajar con
la red “real” hace que los resultados obtenidos sean más valiosos, pero según se ha visto
en el apartado 3, en el que se describe la situación actual de la tecnología, y en el
apartado 5.3, en el que aparecen resultados prácticos, GPRS depende de muchos
factores que dificulta su interpretación. De hecho, la mayoría de estos factores son
externos e imposible de controlar por nosotros. Conocer el número de usuarios que
están registrados en la misma célula que nosotros, saber el número de slots (recursos)
que en cada momento tenemos asignados, comprobar el efecto de los parámetros de la
QoS al ir conectándose nuevos usuarios progresivamente, y otras muchas situaciones
que han sido incontrolables durante la realización de este proyecto, permitirían que el
análisis de los resultados fuera mucho más completo.
Con todo lo dicho, se puede concluir, que tanto la investigación realizada como el
desarrollo (GNOME-GPRS), completan un proyecto que puede y debe ser la base para
otros estudios posteriores encaminados a UMTS.
Proyecto Fin de Carrera. Ingeniería Informática
301
7. Líneas de investigación futuras
Movicuo es un proyecto que inicia el camino para el desarrollo de tecnologías de última
generación en entornos Linux.
Al principio del proyecto se daban varios datos para dar una visión de la velocidad con
la que evolucionan estas tecnologías. Es sorprendente que en apenas 13 años, GSM
haya conseguido más de un mil millones de clientes en todo el mundo.
Tenemos delante de nosotros una evolución realmente sorprendente. La tecnología con
más clientes es GSM, y, sin embargo, ya ha evolucionado varias veces, si contamos que
GPRS y UMTS surgen a partir de ella.
Movicuo es un proyecto que se centra principalmente en GPRS, tanto en la parte de
investigación como en el desarrollo realizado.
Como se ha ido viendo a lo largo del proyecto, GPRS es una evolución de GSM. Estas
tecnologías son bastante complejas, por eso, un proyecto de este tipo puede ayudar a los
desarrolladores a investigar en las tecnologías de última generación de comunicaciones
móviles, tomando como base este proyecto. Un proyecto sobre comunicaciones móviles
no debería tener fin, y eso es lo que le ocurre a Movicuo, ya que estas tecnologías no
dejarán de evolucionar, y los sistemas Linux, deben estar dotados de estas posibilidades.
Parece claro por tanto, que este proyecto no debería acabar aquí. El siguiente paso es
lógico que vaya dirigido a las redes de tercera y cuarta generación, en concreto, a
UMTS.
Sin duda, UMTS aún no ha llegado a dar todo su potencial en nuestro país. El problema
ocasionado por la instalación de las antenas, ha supuesto que se haya retrasado.
Actualmente en España hay 25.000 antenas, y se necesitan, al menos, otras 10.000 para
atender las necesidades de cobertura que necesita la telefonía UMTS. El pasado 14 de
Junio de 2005, las operadoras móviles y los Ayuntamientos han llegado a un acuerdo
para colaborar en el despliegue de antenas de móviles.
Movicuo
302
Esto puede provocar que en un plazo relativamente corto, UMTS sea la tecnología de
referencia, por lo que Movicuo debe ser adaptado a estas situaciones de evolución
constante. El software GNOME-GPRS es un proyecto de libre distribución, que solventa
el vacío de conectividad a Internet de los sistemas Linux a través de tecnologías móviles
de última generación, pero en poco tiempo, éstos sistemas en general, y GNU/LinEx en
particular necesitarán de otras evoluciones que permitan a sus usuarios el uso de las
nuevas tecnologías que aparezcan en el mercado.
GNOME-GPRS puede y debe ser el punto de partida desde donde comenzar el
desarrollo para permitir todas estas posibilidades.
Proyecto Fin de Carrera. Ingeniería Informática
303
8. Bibliografía
8.1. Libros
• J. Bannister, P. Mather, S. Coope. Convergence Technologies for 3G Networks: IP, UMTS, EGPRS and ATM. John Wiley & Sons. 2004.
• G. Heinne, H. Sagcob. GPRS: Gateway to third generation Mobile Networks.
Artech House. 2003.
• C. Andersson. GPRS and 3G Wíreless Applications. John Wiley & Sons. 2001.
• G. Sanders, L. Thorens, M. Reisky, O. Rulik, S. Deylitz. GPRS Networks.
John Wiley & Sons. 2003.
• T. Jalonen, J. Romero, J. Melero. GSM, GPRS and EDGE Performance: Evolution Towards 3G/UMTS. John Wiley & Sons. 2003.
• A. Brand, H. Aghvami. Multiple Access Protocols for Mobile
Communications: GPRS, UMTS and Beyond. John Wiley & Sons. 2002.
• B. Walke, P. Seidenberg, M.P. Althoff. UMTS: The Fundamentals. John Wiley & Sons. 2003.
• R.Moya, A. Del Castillo, R. Majadas, G. Oriol, G. Robles, Y. Moreno, A.
Cazorla, G. Poo-Caamaño, A. Sánchez Acosta, R. Pérez Cubero, C.
Garnacho, J. Pereira, A.Santiago, A.Valdés, C. Saavedra. Programación en el
entorno GNOME. The GNOME foundation. 2002
• J. González Barahona, J. Seoane Pascual, G. Robles. Software Libre.
Fundació per a la Universitat Oberta de Catalunya. 2003.
8.2. Artículos • C. Bettstetter, H-J Vögel, J. Eberspächer. GSM Phase 2+. General Packet Radio
Service. GPRS: Architecture, Protocols, and Air Interface. Universidad de Munich. 1999.
Movicuo
304
• An Introduction to the Vodafone GPRS environment and supported services. Vodafone. 2000.
• D. Staehle, K. Leibnitz, K. Tsipotis. QoS of Internet Access with GPRS.
Universidad de Wurzburg. 2002.
• O. T. W. Yu. End to End Adaptive QoS Provisioning over GPRS Wireless Mobile Network. Universidad de Illinois. 2003
• Nokia. AT Command Set For Nokia GSM and WCDMA Products. Forum Nokia.
2004.
• R. Montañana. Ethernet: de 2,94 A 1000 Mbps en 25 años Primera Parte: La Historia. Boletín Red-Iris. Diciembre 1998 - Enero 1999.
• H. Montes, G. Gómez, D. Fernandez. An End-to-End QoS framework for
multimedia streaming services in 3G Networks. Universidad de Málaga. 2002.
• S. Hoff, M. Meyer, J. Sachs. Analisis of the General Packet Radio Service (GPRS) of GSM as Access to the Internet. Ericsson Eurolab Deutschland. 1998.
• N. R. Prasad. GSM Evolution towards Third Generation UMTS/IMT2000.
Lucent Technologies. 1999.
• V.A. Chitre, J.N. Daigle. IP Traffic over GPRS – An Internet Service Oriented Análisis. Centre for Gíreles Communications. University of Mississippi. 1999.
• S. S. Chakraborty. Mobile Multimedia: In Context to ATM Transport and
GSM/GPRS Mobile Access Networks. Communication Laboratory, Faculty of E.E., Helsinki University of Technology. 1996
• J. Sevanto. Multimedia Messaging Service for GPRS and UMTS. Nokia
Telecommunications. 2000.
• C. Ferrer, M. Oliver. Overview and Capacity of the GPRS (General Packet Radio Service). Applied Maths & Telematics, Universitat Politècnica de Catalunya. 1998.
• M. Meyer. TCP Performance over GPRS. Ericsson Eurolab Deutschland. 1999.
• J. Ho, Y. Zhu, S. Madhavapeddy. Throughput and Buffer Análisis for GSM
General Packet Radio Service (GPRS). Nortel Networks. 1999.
• Yi-Bing Lin, Yieh-Ran Haung, Yuan-Kai Chen, Imrich Chlamtac. Mobility management: from GPRS to UMTS. John Wiley & Sons. Agosto de 2001.
• A. Al-Adnani, C. Nicolacacos. UMTS Security Architecture. Panasonic. Mayo
de 1999.
Proyecto Fin de Carrera. Ingeniería Informática
305
• R. Kalden, I. Meirick, M. Meyer. Wireless Internet Access Based on GPRS. Ericsson Eurolab Deutschland. 2000.
• 2G/2.5G/3G Roaming (Version 3.1.1). GSM Association. Abril de 2004.
• P. Rysavy. Capacidades de datos para la evolución GSM a UMTS. Rysavy
Research. Noviembre de 2002
8.3. Estándares
• ETSI TS 03.64. Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Overall description of the GPRS radio interface; Stage 2.
• ETSI TS 04.60. 3rd Generation Partnership Project; Technical Specification
Group GSM/EDGE Radio Access Network; General Packet Radio Service (GPRS); Mobile Station (MS) – Base Station System (BSS) interface; Radio Link Control/Médium Access Control (RLC/MAC) protocol (Release 98).
• ETSI TS 04.64. 3rd Generation Partnership Project; Technical Specification
Group Core Network; Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Mobile Station – Serving GPRS Support Node (MS – SGSN) Logical Link Control (LLC) layer specification (Release 98).
• ETSI TS 04.65. Digital cellular telecommunications system (Phase 2+);
General Packet Radio Service (GPRS); Mobile Station (MS) – Serving GPRS Support Node (SGSN); Subnetwork Dependent Convergence Protocol (SNDCP).
• ETSI TS 05.01. 3rd Generation Partnership Project; Technical Specification
Group GSM/EDGE Radio Access Network; Physical Layer on the Radio Path; General Description (Release 98).
• ETSI TS 05.02. 3rd Generation Partnership Project; Technical Specification
Group GSM/EDGE Radio Access Network; Multiplexing and Multiple Access on the Radio Path (Release 1998).
• ETSI TS 07.07. Digital cellular telecommunications system (Phase 2+); AT
Command set for GSM Mobile Equipment (ME).
• ETSI TS 08.14. Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Base Station System (BSS) – Serving GPRS Support Node (SGSN) interface; Gb Interface Layer 1.
Movicuo
306
• ETSI TS 08.16. Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS). Base Station System (BSS) – Serving GPRS Support Node (SGSN) Interface; Network Service.
• ETSI TS 08.18. 3rd Generation Partnership Project; Technical Specification
Group GSM EDGE Radio Access Network; General Packet Radio Service (GPRS); Base Station Syste (BSS) – Serving GPRS Support Node (SGSN); BSS GPRS Protocol.
• ETSI TS 23.060. 3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; General Packet Radio Service (GPRS) Service description; Stage 2.
• ETSI TS 23.107. 3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; Quality of Service (QoS) concept and architecture.
• ETSI TS 27.007. Digital cellular telecommunications system (Phase 2+);
Universal Mobile Telecommunications System (UMTS); AT command set for User Equipment (UE).
• RFC 1171. Point-to-Point Protocol for the transmisión of multi-protocol
datagrams over Point-to-Point links.
• RFC 1661. The Point-to-Point Protocol (PPP).
8.4. Rerefencias en Internet
• GSM World. http://www.gsmworld.com
• UMTS Forum. http://www.umtsforum.net/
• Organización 3GPP. http://www.3gpp.org/
• ETSI (European Telecommunications Standards Institute).
http://www.etsi.org/
• GPRS HOWTO. http://turtiainen.dna.fi/GPRS-HOWTO
• Ross Barkman’s GPRS Info Page http://www.taniwha.org.uk/gprs.html
Proyecto Fin de Carrera. Ingeniería Informática
307
• Portal GNU/LinEx. http://www.linex.org
• Proyecto GNOME. http://www.gnome.org
• Zona de desarrolladores GNOME. http://developer.gnome.org
• GNOME Hispano. http://www.es.gnome.org
• IDE Anjuta. http://www.anjuta.org
• Glade. http://glade.gnome.org
• RRDTOOL. http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
Movicuo
308
Proyecto Fin de Carrera. Ingeniería Informática
309
9. Anexo 9.1. Licencia GNU
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Movicuo
310
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you
Proyecto Fin de Carrera. Ingeniería Informática
311
provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Movicuo
312
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
Proyecto Fin de Carrera. Ingeniería Informática
313
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Movicuo
314
END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
one line to give the program's name and an idea of what it does. Copyright (C) yyyy name of author This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. signature of Ty Coon, 1 April 1989
Proyecto Fin de Carrera. Ingeniería Informática
315
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.
9.2. Licencia de documentación libre GNU
GNU Free Documentation License Version 1.2, November 2002
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or non commercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
Movicuo
316
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine- generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following
Proyecto Fin de Carrera. Ingeniería Informática
317
text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or non commercially, provided that this License, the copyright notices, and the license notice saying this License appliesto the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
Movicuo
318
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to live them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
Proyecto Fin de Carrera. Ingeniería Informática
319
K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalents are not considered part of the section titles. M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties-- for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or simply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
Movicuo
320
In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements". 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other Documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
Proyecto Fin de Carrera. Ingeniería Informática
321
9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
Movicuo
322