MOVICUO COMUNICIONES MÓVILES DE ÚLTIMA …gitaca.unex.es/agila/movicuo/archivos/Documentacion_MOVICUO.pdf · RNC (Radio Network ... ..... 115 3.4.2.1.3. 3GMSC (3G Mobile Switching

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.

[email protected]

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


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


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


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


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


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


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


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


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.


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


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


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


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.


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


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.


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


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


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.


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á


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.


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


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.


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


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.


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:


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.


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.


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


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.


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.


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


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:


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.


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.


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


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


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


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.


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.


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.


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.


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


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


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


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.


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.


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).


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


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.


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


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.


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.


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.


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,


de errores limitada, y

buena tolerancia a errores

Clase 3 10-2 10-5 10-5 10-2 No sensible a errores, sin


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


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.


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


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.


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


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.


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.


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.


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.


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


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


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.


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.


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.


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


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:


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.


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


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


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


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.


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.


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








• 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.


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


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...


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:


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.


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


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


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


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.


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.


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.


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


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.


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.


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.


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.


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.


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.


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


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:



Relleno

Relleno


DATOS

0 8 16 24 32

Código (tipo) Identificador Longitud (Primer byte)

Longitud (Segundo byte)


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



Relleno

Relleno


Opción 1

Otras opciones o datos

0 8 16 24 32




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


Opciones de configuración que son aceptadas.

Configure-Nak

3



Opciones de configuración que son asentidas negativamente

Configure-Reject

4



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


No es necesario

Code-Reject

7


4+Longitud de la trama rechazada

Copia de la trama LCP que es rechazada (no la trama PPP completa, solo su campo Información)


185

Tipo de Trama

Campo Código


Campo de Datos

Protocol-Reject

8


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


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.




Discard-Request

11

Nuevo valor generado para cada trama




Identificación

12

Nuevo valor para cada trama




Movicuo

186

Tipo de Trama

Campo Código


Campo de Datos

Time-Remaining

13

Nuevo valor para cada trama




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


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



Relleno

Relleno


0 8 16 24 32



Longitud del Mensaje

MENSAJE



Relleno

Relleno


0 8 16 24 32



Longitud Peer-ID Peer-ID

Peer-ID Longitud Password Password

Password


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


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.


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,


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).


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.


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).


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).


199


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


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).


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)


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


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)


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.


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.


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 €


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 €


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


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.


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.


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


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


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


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:


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.


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,


on_error_ppp,

NULL);

g_io_channel_unref (proc_ppp.err);


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


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,


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”).


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.


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


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


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:


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


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


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


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.


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


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.


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.


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.


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


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.


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.


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.


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.


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


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.


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:


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:


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:


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.


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.


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.


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.


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


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


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:


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.



Operadora Vodafone

Movicuo

282

DNS dinámica SI

QoS activada SI


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


alto)

Retardo Clase 3 (retardo mas

alto)

Fiabilidad Clase 3 (tasa de

errores media)



bytes/hora = 111

kbps


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).


285

Veamos las opciones de GNOME-GPRS que se han establecido para realizar la

conexión de la prueba.



Operadora Vodafone

DNS dinámica SI

QoS activada NO


activado

NO


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:



Operadora Vodafone

DNS dinámica SI

QoS activada SI


activado

NO



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


alto)

Retardo Clase 1 (retardo más

bajo)

Fiabilidad Clase 1 (menor tasa

de errores posible)



bytes/hora = 111

kbps

Parámetro de QoS

mínima

Valor


alto)

Retardo Clase 3 (retardo mas

alto)

Fiabilidad Clase 3 (tasa de

errores media)



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


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



Operadora Vodafone

DNS dinámica SI

QoS activada NO


activado

NO


activada

NO

Conexión con QoS



291


Operadora Vodafone

DNS dinámica SI

QoS activada SI


activado

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 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 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



293

ping –s 128 patanegra.unex.es




RTT medio 842 ms 840’3 ms


% paquetes

perdidos

14% 4%

Estos datos pueden verse gráficamente en la figura 5.59.


512 BYTES




Movicuo

294





% paquetes

perdidos

0% 4%

Estos datos pueden verse de forma más detallada en la siguiente gráfica:


1024 BYTES







295



% paquetes

perdidos

4% 9%

Esta información se observa con más claridad en la gráfica 5.61.


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.


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.


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.


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.


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.


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).


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).


Group GSM/EDGE Radio Access Network; Physical Layer on the Radio Path; General Description (Release 98).


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.


Group GSM EDGE Radio Access Network; General Packet Radio Service (GPRS); Base Station Syste (BSS) – Serving GPRS Support Node (SGSN); BSS GPRS Protocol.


Group Services and System Aspects; General Packet Radio Service (GPRS) Service description; Stage 2.


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


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


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


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.


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


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


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.


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.


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