anÁlisis de desempeÑo de una celda celular gsm con …

ANÁLISIS DE DESEMPEÑO DE UNA CELDA CELULAR GSM CON TRÁFICO DE VOZ

HETEROGÉNEO

LINA PATRICIA ÁVILA MARTÍNEZ

JUAN DIEGO RODRÍGUEZ REMOLINA

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA

DEPARTAMENTO DE ELECTRÓNICA BOGOTÁ D.C. MAYO DE 2010

ANÁLISIS DE DESEMPEÑO DE UNA CELDA CELULAR GSM CON TRÁFICO DE VOZ

HETEROGÉNEO

LINA PATRICIA ÁVILA MARTÍNEZ JUAN DIEGO RODRÍGUEZ REMOLINA

Trabajo de grado para optar por el título de Ingeniero Electrónico

Director: LUIS JAVIER LÓPEZ GONZÁLEZ

Ingeniero Electrónico, MSc.

Asesor: CARLOS IVAN PAÉZ RUEDA

Ingeniero Electrónico, MSc.

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA

DEPARTAMENTO DE ELECTRÓNICA BOGOTÁ D.C. MAYO DE 2010

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERÍA

DEPARTAMENTO DE ELECTRÓNICA

RECTOR MAGNÍFICO: JOAQUÍN SÁNCHEZ GARCÍA S. J.

DECANO ACADÉMICO: Ing. FRANCISCO J. REBOLLEDO M.

DECANO DEL MEDIO UNIVERSITARIO: SERGIO BERNAL RESTREPO S. J.

DIRECTOR DE CARRERA: Ing. JUAN MANUEL CRUZ.

DIRECTOR DEL TRABAJO DE GRADO: Ing. LUIS JAVIER LÓPEZ GONZÁLEZ

Nota de aceptación

______________________

______________________

______________________

_____________________

Presidente del Jurado

_____________________

Jurado

_____________________

Jurado

Bogotá 28 Mayo 2010

ARTÍCULO 23 DE LA RESOLUCIÓN N° 13 DE JUNIO DE 1946

“La universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus trabajos de

grado. Solo velara porque no se publique nada contrario al dogma y la moral católica y porque los trabajos

no contengan ataques o polémicas puramente personales. Antes bien que se vea en ellos el anhelo de

buscar la verdad y la justicia”

DEDICATORIA

A mi madre y a mi novio,

Que con su ejemplo

Siempre me enseñaron el camino a seguir

Y con su apoyo,

Fueron la roca que me sostuvo

Para nunca desfallecer.

Lina

Para mi familia

En especial a mi Madre

Que siempre me lo ha dado todo

Y es ejemplo de vida a seguir.

A mi novia, de la que cada día aprendo más

Y la cual me hace ser una mejor persona.

Con todo mi corazón

Juan Diego

AGRADECIMIENTOS

Al director de Trabajo de grado, Luis Javier López, le agradecemos que con su sabiduría, experiencia, paciencia y compromiso fue un excelente guía y apoyo incondicional.

Al asesor de Trabajo de grado, Carlos Iván Páez, a quien admiramos por ser ejemplo de disciplina, le agradecemos por brindarnos su confianza y sus conocimientos con tan excelente metodología.

Y en general, a nuestras familias y amigos, por contribuir en el feliz término de éste proyecto.

Tabla de Contenido

1. INTRODUCCIÓN ........................................................................................................................... 1

2. MARCO TEÓRICO ......................................................................................................................... 2

2.1. GSM ......................................................................................................................................... 2

2.1.1. Arquitectura....................................................................................................................... 2

2.1.2. Esquema de acceso múltiple .............................................................................................. 5

2.1.3. Protocolos y Modelo OSI ................................................................................................... 6

2.2. Sistemas de espera .................................................................................................................... 7

2.2.1. Planteamiento General ....................................................................................................... 7

2.2.2. Notación Kendall ............................................................................................................... 9

2.2.3. Definición de variables ...................................................................................................... 9

2.2.4. Sistema de Espera M/M/n/n ............................................................................................. 10

2.3. Simulación .............................................................................................................................. 12

2.3.1. Simulación mediante eventos discretos. ........................................................................... 13

2.3.2. Herramienta de Simulación .............................................................................................. 15

2.3.3. Análisis estadístico .......................................................................................................... 18

2.3.3.1. Estimador de la media muestral ............................................................................... 18

2.3.3.2. Intervalo de confianza ............................................................................................. 19

2.3.3.3. Prueba de Kolmogorov-Smirnov para datos continuos ............................................. 21

3. ESPECIFICACIONES ................................................................................................................... 23

3.1. Descripción General y Diagrama en Bloques ........................................................................... 23

4. DESARROLLO ............................................................................................................................. 25

4.1. Implementación del modelo de simulación .............................................................................. 25

4.1.1. Fuente ............................................................................................................................. 25

4.1.1.1. Fuente.h .................................................................................................................. 25

4.1.1.2. Fuente.cc ................................................................................................................. 26

4.1.2. Switch ............................................................................................................................. 27

4.1.2.1. Switch.h .................................................................................................................. 27

4.1.2.2. Switch.cc ................................................................................................................ 27

4.1.3. Servidor ........................................................................................................................... 28

4.1.3.1. Servidor.h ............................................................................................................... 29

4.1.3.2. Servidor.cc .............................................................................................................. 29

4.1.4. Sumidero ......................................................................................................................... 30

4.1.4.1. Sumidero.h .............................................................................................................. 30

4.1.4.2. Sumidero.cc ............................................................................................................ 31

4.2. Protocolo de comunicación ..................................................................................................... 31

4.3. Configuración ......................................................................................................................... 34

4.4. M/M/1/1 ................................................................................................................................. 35

4.5. Validación .............................................................................................................................. 39

5. ANÁLISIS DE RESULTADOS ..................................................................................................... 46

5.1. Escenarios de Análisis ............................................................................................................. 49

5.1.1. Sistema homogéneo vs. Sistema heterogéneo ................................................................... 49

5.1.2. Comparación de resultados con el modelo de Xian Liu .................................................... 52

5.1.3. Caso Particular: Análisis de información suministrada por un operador de telefonía móvil colombiano ............................................................................................................ 53

6. CONCLUSIONES ......................................................................................................................... 56

7. BIBLIOGRAFÍA ........................................................................................................................... 57

8. ANEXOS ....................................................................................................................................... 59

Lista de Figuras

Figura 1. Porcentaje de suscriptores por tecnología .................................................................................. 1

Figura 2. Arquitectura de PLMN .............................................................................................................. 3

Figura 3. División de las bandas de frecuencia en GSM-900 ..................................................................... 5

Figura 4. Arquitectura de los protocolos de GSM ..................................................................................... 6

Figura 5. Estación de servicio con c servidores ......................................................................................... 7

Figura 6. Componentes básicos de un sistema de espera simple ................................................................ 8

Figura 7. Variables utilizadas en el análisis de un sistema de espera simple. ............................................. 9

Figura 8. Formas de estudiar un sistema ................................................................................................. 12

Figura 9. Diagrama de flujo de control para avance en el tiempo por próximo evento ............................. 14

Figura 10. Módulos simples y compuestos ............................................................................................. 16

Figura 11. Interacción entre las funciones del cSimpleModule ................................................................ 17

Figura 12. Densidad normal unitaria....................................................................................................... 20

Figura 13. Significado del parámetro estadístico de la prueba de Kolmogorov – Smirnov. ...................... 21

Figura 14. Esquema de la celda a analizar .............................................................................................. 23

Figura 15. Descripción de entradas y salidas en el modelo de la celda .................................................... 24

Figura 16. Estructura del modelo ............................................................................................................ 24

Figura 17. Función Inicialización del Bloque Fuente .............................................................................. 26

Figura 18. Función Handle Message del Bloque Fuente.......................................................................... 26

Figura 19. Función Inicialización del Bloque Switch .............................................................................. 27

Figura 20. Función Handle Message del Bloque Switch ......................................................................... 28

Figura 21. Función Finish del Bloque Switch ......................................................................................... 28

Figura 22. Función Inicialización del Bloque Servidor ........................................................................... 29

Figura 23. Función Handle Message del Bloque Servidor ....................................................................... 30

Figura 24. Función Finish del Bloque Servidor ....................................................................................... 30

Figura 25. Función Inicialización del Bloque Sumidero .......................................................................... 31

Figura 26. Función Handle Message del Bloque Sumidero ..................................................................... 31

Figura 27. Descripción de los archivos .ned ............................................................................................ 32

Figura 28. Protocolo de comunicación.................................................................................................... 33

Figura 29. Experimentos en omnetpp.ini ................................................................................................ 34

Figura 30. Parámetros en omentpp.ini .................................................................................................... 34

Figura 31. Promedio acumulado de la Probabilidad de bloqueo para 500000 llamadas procesadas .......... 36

Figura 32. Promedio acumulado de la probabilidad de bloqueo para 150 corridas ................................... 37

Figura 33. Histograma de los valores de la probabilidad de bloqueo para 100 corridas ............................ 37

Figura 34. Comparación de la función de distribución empírica y la función de distribución supuesta .... 38

Figura 35: Diagrama de flujo para llevar a cabo una simulación. ............................................................ 39

Figura 36: Interfaz grafica del archivo .anf ............................................................................................. 40

Figura 37: Diagrama de flujo para exportar los resultados de una simulación. ......................................... 41

Figura 38: Diagrama de flujo para llevar a cabo una realización ............................................................. 42

Figura 39: Probabilidad de Bloqueo Vs Carga de tráfico del sistema (Eb) para diferente número n de servidores. Escala Logarítmica. ............................................................................................ 43

Figura 40: Probabilidad de Bloqueo Vs Carga de tráfico del sistema (Eb) para diferente número n de servidores. Escala Logarítmica. ............................................................................................ 43

Figura 41: Probabilidad de Bloqueo Vs Carga de tráfico por servidor (ρ) para diferente número n de servidores. Escala lineal. ...................................................................................................... 44

Figura 42: Probabilidad de Bloqueo Vs Carga de tráfico por servidor (ρ) para diferente número n de servidores. Escala logarítmica. ............................................................................................. 45

Figura 43. Histograma del tiempo entre arribos para los usuarios de tipo Handover ................................ 47

Figura 44. Histograma de la duración de las llamadas para los usuarios de tipo Handover....................... 47

Figura 45. Probabilidad de bloqueo para sistemas homogéneos y heterogéneos ...................................... 50

Figura 46. Número esperado de canales ocupados para sistemas homogéneos y heterogéneos ................ 51

Figura 47. Probabilidad de bloqueo para el modelo de Xian. .................................................................. 52

Figura 48. Probabilidad de bloqueo en función del número de servidores para un ejemplo de tasas de un operador de telefonía móvil colombiano. ......................................................................... 54

Figura 49. Escenario 1 y escenario 3. ..................................................................................................... 55

Lista de Tablas

Tabla 1: Valores para α−1c .................................................................................................................... 22

Tabla 2: Equivalencias entre la simulación i con la probabilidad de bloqueo ........................................... 41

Tabla 3: Equivalencias entre un experimento MMnn_X con el número de servidores. ............................ 42

Tabla 4. Porcentajes utilizados para el cálculo de las tasas de arribo. ...................................................... 48

Tabla 5. Valores mínimos y máximos de cada una de las tasas de arribo para diferente número de servidores ............................................................................................................................... 48

Tabla 6. Número esperado de canales ocupados para una probabilidad de bloqueo aproximadamente del 4%..................................................................................................................................... 51

Tabla 7. Comparación de resultados Escenario 2. ................................................................................... 53

Tabla 8. Carga de tráfico y probabilidad de bloqueo para los datos de un operador de telefonía móvil .... 54

Tabla 9. Porcentaje de disminución de la probabilidad de bloqueo del análisis heterogéneo frente al homogéneo. ............................................................................................................................ 55

1

1. INTRODUCCIÓN

Hoy en día, la posibilidad de intercambiar información es un hecho cada vez más importante que se ve reflejado en el constante esfuerzo por mejorar las redes de telecomunicaciones. El incremento de usuarios de telefonía móvil es un factor que se manifiesta a nivel mundial, dando lugar a la competencia entre diferentes sistemas digitales en el mercado, donde claramente prevalece la tecnología GSM (Global System for Mobile Communications), como se detalla en la Figura 1, valores tomados de [1].

Figura 1. Porcentaje de suscriptores por tecnología

Fuente: Presentación propia de los autores

Los sistemas de comunicación se han vuelto cada vez más complejos, por tanto se ve la necesidad de plantear diferentes modelos que permitan analizar el desempeño de la celda celular, donde la capacidad y la cobertura, son características relevantes en el constante esfuerzo por mejorar la calidad del servicio prestado a los usuarios. Dicho esfuerzo, se ve reflejado en el análisis de medidas de desempeño como la probabilidad de bloqueo, la tasa de error y la relación de señal a ruido, entre otras.

Gran parte de los estudios realizados en este campo, tienen como soporte modelos de simulaciones y soluciones numéricas a través de cadenas de Markov que difieren según el escenario [2]. Teniendo en cuenta, que la evaluación de investigaciones orientadas al desarrollo de la red demanda mucho tiempo, y que idealmente se busca la menor cantidad de riesgo posible, una excelente opción es la utilización de modelos de computación que permitan probar las ideas propuestas en camino a la optimización de la red.

El aumento del tráfico que circula por las redes es un reflejo del incremento de usuarios, mientras que la complejidad de éstas conlleva al análisis del tráfico heterogéneo, el cual se refiere a la diversidad tanto en las tasas de arribo (λ) de los usuarios al sistema como en las tasas de servicio (µ) del mismo. La mayoría de los sistemas de comunicaciones digitales, incluyendo la tecnología GSM deben ser capaces de soportar un tráfico heterogéneo y cuantificar la capacidad del sistema ante él. La importancia de nuestro proyecto radica en el hecho de que hoy en día los operadores de telefonía móvil ofrecen diversas modalidades de suscripción dirigidas a usuarios con necesidades y posibilidades diferentes, lo cual implica que se tenga un tráfico de voz heterogéneo que demanda herramientas de análisis y diseño para redes celulares con dichas características [3].

El objetivo principal de éste documento es presentar un modelo de simulación de una celda celular GSM como un sistema de espera, analizando su desempeño bajo un tráfico de voz heterogéneo. Para lo cual se requiere especificar y evaluar los parámetros de desempeño que van a ser medidos; definir el modelo que representa dicha celda, validándolo a través de simulaciones desarrolladas en un simulador de propósito

2

general por eventos discretos; para finalmente, realizar el análisis correspondiente a partir de los resultados obtenidos en la simulación. Por lo tanto, el documento incluye información relacionada con la tecnología GSM, las bases teóricas de los sistemas de espera y de los modelos de simulación. Una vez explicados los conceptos y el desarrollo del modelo, se procede a la validación del mismo para un tráfico de voz homogéneo a través de la comparación de los resultados simulados con las bases teóricas expuestas. Finalmente se dan a conocer los resultados obtenidos para un tráfico heterogéneo bajo tres escenarios de análisis diferentes.

2. MARCO TEÓRICO

2.1. GSM

En 1982 fue usado por primera vez al acrónimo GSM (Groupe Spécial Mobile), como un grupo encargado de estudiar y desarrollar un nuevo estándar de comunicaciones que internacionalizará la tecnología en los países involucrados. Fue hasta 1991, que surgieron los primeros servicios comerciales de GSM, siendo éste mismo año el cambio en su significado a Global System for Mobile Communications [4].

2.1.1. Arquitectura

La idea básica de una red celular es la partición del rango de frecuencias disponibles, para asignar solamente una parte del espectro de frecuencia a cada una de las BTS (Base Transceiver Station). En general, GSM es una tecnología que puede ser vista como una estructura para el estudio de funciones y asuntos específicos en las comunicaciones celulares. Es así como una red GSM está dividida en tres partes principales: MS (Mobile Station), BSS (Base Station Subsystem) y NSS (Network Switching Subsystem), donde cada una de ellas está compuesta por algunas entidades funcionales [5], y todas juntas forman una red PLMN (Public Land Mobile Network) como se muestra en la Figura 2.

Una idea general de los subsistemas de GSM se describe a continuación [4] y [5]:

1. MS (Mobile Station): Está formado por una tarjeta llamada SIM (Subscriber Identity Module), la cual es insertada en un ME (Mobile Equipment). • SIM (Subscriber Identity Module): Es una tarjeta inteligente cuya función principal es

almacenar información tal como números de identificación personal, números telefónicos y el lenguaje; lo cual no implica que los datos guardados sean solo del subscriptor. La SIM contiene una identificación conocida como IMSI (International Mobile Subscriber Identity), que le ofrece al usuario un código secreto de autentificación. Adicionalmente, determina el número de llamadas facturadas a un subscriptor y es la que permite la conexión del equipo a la red, es decir, si la tarjeta no es insertada en el celular, las únicas llamadas permitidas son a los números de emergencia. Finalmente, es gracias a la SIM, que un usuario puede cambiar de equipo celular conservando su número y su directorio.

• ME (Mobile Equipment): Es el equipo móvil que al insertarle la SIM forma el único elemento del sistema con el que la mayoría de los usuarios tienen contacto directo.

La MS debe tener implementadas también las funciones que conoce el BTS, entre las cuales se encuentra el proceso de modulación, demodulación, codificación, decodificación, y asuntos relacionados con la potencia consumida por la batería, capacidad de envió de mensajes y disponibilidad de algoritmos de cifrado.

2. BSS (Base Station Subsystem)

entre el MS y los servicios prestados por el MSC por los elementos que se describen a continuación: • BTS: Por un lado, provee la conexión física de la MS a la red a través de la interfaz de aire.

Mientras que hacia el otro lado, la BTS está conectado a la BSC medio de la interfaz MS y de manejar los dispositivos para la transmisión y recepción de radio, incluyendo la antena de la estación base en una celda.El BTS está dividido de la siguiente maner(TRX), que está formado por una parte de baja frecuencia para el procesamiento de señales digitales, y otra de alta frecuencia para la modulación y demodulación GMSK mínimum shift keying)

el cual permite que se procesen en el BTS los comandos dados por el BSC o el MSC, reportándoles los resultados obtenidos; gracias al centro de gestión y mantenimiento (OMC) se puede contar con lalas frecuencias de los filtros a la entrada y a la salida usados para limitar el ancho de banda de las señales recibidas y transmitidas. Para garantizar una cobertura óptima se tienen dconfiguraciones de BTS dependiendo de la carga y el comportamiento del subscriptor, entre las más comunes se encuentran: la configuración estándar, que se basa en la asignación de un determinado número de BTSs a una zona específica; la configurac

3

Figura 2. Arquitectura de PLMN

Fuente: Modificado de [4]

(Base Station Subsystem): Es el encargado de proveer y gestionar los caminos de transmisión entre el MS y los servicios prestados por el MSC (Mobile service Switching Center)

por los elementos que se describen a continuación:

BTS: Por un lado, provee la conexión física de la MS a la red a través de la interfaz de aire. Mientras que hacia el otro lado, la BTS está conectado a la BSC (Base Station Controller)

interfaz Abis. Es la estación encargada de los protocolos de enlace de radio con el MS y de manejar los dispositivos para la transmisión y recepción de radio, incluyendo la antena de la estación base en una celda. El BTS está dividido de la siguiente manera: Primero, el módulo de transmisión y recepción (TRX), que está formado por una parte de baja frecuencia para el procesamiento de señales digitales, y otra de alta frecuencia para la modulación y demodulación GMSK mínimum shift keying). En segundo lugar, se encuentra el módulo de gestión y mantenimiento, el cual permite que se procesen en el BTS los comandos dados por el BSC o el MSC, reportándoles los resultados obtenidos; gracias al centro de gestión y mantenimiento (OMC) se puede contar con la generación de reloj interna en el BTS, además de tener el control de las frecuencias de los filtros a la entrada y a la salida usados para limitar el ancho de banda de las señales recibidas y transmitidas. Para garantizar una cobertura óptima se tienen dconfiguraciones de BTS dependiendo de la carga y el comportamiento del subscriptor, entre las más comunes se encuentran: la configuración estándar, que se basa en la asignación de un determinado número de BTSs a una zona específica; la configurac

: Es el encargado de proveer y gestionar los caminos de transmisión (Mobile service Switching Center). Está formado

BTS: Por un lado, provee la conexión física de la MS a la red a través de la interfaz de aire. (Base Station Controller) por

Es la estación encargada de los protocolos de enlace de radio con el MS y de manejar los dispositivos para la transmisión y recepción de radio, incluyendo la

a: Primero, el módulo de transmisión y recepción (TRX), que está formado por una parte de baja frecuencia para el procesamiento de señales digitales, y otra de alta frecuencia para la modulación y demodulación GMSK (Gaussian

do lugar, se encuentra el módulo de gestión y mantenimiento, el cual permite que se procesen en el BTS los comandos dados por el BSC o el MSC, reportándoles los resultados obtenidos; gracias al centro de gestión y mantenimiento (OMC)

generación de reloj interna en el BTS, además de tener el control de las frecuencias de los filtros a la entrada y a la salida usados para limitar el ancho de banda de las señales recibidas y transmitidas. Para garantizar una cobertura óptima se tienen diferentes configuraciones de BTS dependiendo de la carga y el comportamiento del subscriptor, entre las más comunes se encuentran: la configuración estándar, que se basa en la asignación de un determinado número de BTSs a una zona específica; la configuración sombrilla, la cual

4

consiste en una BTS con una alta potencia de transmisión y una antena instalada muy por encima del suelo que sirve de “sombrilla” a un número de BTSs con potencia de transmisión baja y diámetros pequeños; y la configuración sectorizada, que se refiere a varias BTSs yuxtapuestas en un sitio, pero sus antenas solo cubren un área de 120 ó 180 grados.

• BSC (Base Station Controller): Es la estructura interna y de organización del BSS. Por un lado, está conectado al BTS a través de la interfaz “Abis”, mientras que por el otro está al MSC por medio de la interfaz “A”. Maneja los recursos de radio de una o más BTS’s, incluyendo configuración de radio canales, saltos en frecuencias y procesos de handover

1.

• TRAU (Transcoding Rate and Adaptation Unit): Es la unidad encargada junto con el MS, de hacer posible la compresión de datos, que a su vez es un indicador de cuantas llamadas pueden llevarse a cabo usando un determinado ancho de banda, lo que se traduce en un control sobre la eficiencia de la red.

3. NSS (Network Switching Subsystem): Es fundamental en el desarrollo de cualquier red celular, ya que tiene la responsabilidad de completar el conjunto de funciones de control y de datos requeridas para establecer las llamadas. Para lo cual está constituida de la siguiente forma: • MSC (Mobile Services Switching Center): Su principal tarea se basa en el enrutamiento de las

llamadas entrantes y salientes así como la correspondiente asignación de canales en la interfaz A, es decir, entre sus funciones se encuentra desarrollar y controlar el handover entre MSCs.

• HLR (Home Location Register) y AuC (Authentication Center): Puede ser vista como una base de datos que maneja un gran número de subscriptores y que tiene tiempos de acceso que deben ser lo más cortos posibles, pues entre más rápido se obtenga respuesta de la base de datos, más rápido puede ser conectada la llamada. Esta base de datos contiene información administrativa de cada abonado registrado en la correspondiente red GSM. El centro de autenticación (AuC), es una base de datos protegida, que contiene una copia del código secreto que fue almacenado en la tarjeta SIM, el cual es usado para autenticación y cifrado sobre el canal de radio.

• VLR (Visitor Location Register): Al igual que el HLR, es una base de datos, pero sus funciones son más dinámicas que estáticas, lo que lo diferencia del HLR. Al registro VLR le es asignada un área geográfica limitada, de tal forma que almacena toda la información dinámica relacionada con este lugar; mientras que el HLR maneja todas las tareas que son independientes de la ubicación del subscriptor.

• EIR (Equipment Identity Register): Es también una base de datos que guarda información de todos los equipos móviles (ME) válidos en la red, donde cada teléfono es identificado por su IMEI (International Mobile Equipment Identity), el cual puede ser bloqueado en el momento de ser reportado como robado. Además guarda la ubicación de las estaciones móviles (MS) relacionadas anteriormente.

La topología de la NSS es más flexible que la estructura del BSS, es así como un MSC puede usar un VLR común, el número de HLRs necesarios es determinado por el número de subscriptores y el uso de EIR es opcional.

1 Es el proceso que involucra un cambio de celda debido a la movilidad del subscriptor.

2.1.2. Esquema de acceso múltiple

Como el espectro de radio es un recurso limitado compartido por todos los usuarios, se requiere un método que divida el ancho de banda entre la mayor cantidad de usuarios posible. El método utilizado en GSM es una combinación de TDMA y FDMA Multiple Access), donde los canales de radio se basan en una estructura TDMA que es sub-bandas de múltiple frecuencia

Dos bandas de frecuencia están definidas para GSMenlaces uplink

2, así como la banda de 935dos bandas más disponibles para GSM1880 MHz. Cada una de las bandas de GSM374 portadoras, que en ambos casos están separadas por 200 kHz. Una o varias frecuencias portadoras son asignadas a un BSS.

Cada una de las frecuencias de radio está dividida en 26 tramas de 4.615 ms (usando un esquema TDMA), cada una de las cuales se subdivide en 8 intervalos de tiempo llamados canales: un canal físico es formado por la rtramas, mientras que un canal lógico refleja el tipo especial de las bandas de frecuencia de GSMFigura 3.

Los canales lógicos pueden ser de tráfico ó de control. Los canales de tráfico (TCH) son recursos disponibles para el usuario, pueden ser utilizados Rate

4 (TCH/F) ó Half Rate5

controlan a los canales de tráfico.

2 Se refiere a comunicación de la estación móvil (MS) a la estación base (BTS).3 Se refiere a comunicación de la estación base (BTS) a la 4 Canal que soporta tasas de bits de 13kbps (para voz) y 9.6kbps, 4.8kbps ó 2.4kbps (para datos)

5

Esquema de acceso múltiple

Como el espectro de radio es un recurso limitado compartido por todos los usuarios, se requiere un cho de banda entre la mayor cantidad de usuarios posible. El método utilizado en

GSM es una combinación de TDMA y FDMA (Time Division Multiple Access / Frequency Division

, donde los canales de radio se basan en una estructura TDMA que es bandas de múltiple frecuencia [6].

Dos bandas de frecuencia están definidas para GSM-900 [7]: la banda de 890, así como la banda de 935-960 MHz es usada para downlink

3

dos bandas más disponibles para GSM-1800, una de 1710 MHz a 1785 MHz y la otra de 1805 MHz a 1880 MHz. Cada una de las bandas de GSM-900 está dividida en 124 portadoras y las de GSM374 portadoras, que en ambos casos están separadas por 200 kHz. Una o varias frecuencias portadoras son

Cada una de las frecuencias de radio está dividida en 26 tramas de 4.615 ms (usando un esquema TDMA), cada una de las cuales se subdivide en 8 intervalos de tiempo llamados time slotscanales: un canal físico es formado por la recurrencia de un time slot en particular en cada una de las tramas, mientras que un canal lógico refleja el tipo especial de información llevada en él de las bandas de frecuencia de GSM-900, y la representación de un canal físico y lógico se muestra en la

Figura 3. División de las bandas de frecuencia en GSM-900


Los canales lógicos pueden ser de tráfico ó de control. Los canales de tráfico (TCH) son recursos disponibles para el usuario, pueden ser utilizados para voz ó datos y tienen dos formas de servicio:

(TCH/H). Los canales de control sirven para señalización y son los que controlan a los canales de tráfico.

Se refiere a comunicación de la estación móvil (MS) a la estación base (BTS).

Se refiere a comunicación de la estación base (BTS) a la estación móvil (MS).

Canal que soporta tasas de bits de 13kbps (para voz) y 9.6kbps, 4.8kbps ó 2.4kbps (para datos)

Como el espectro de radio es un recurso limitado compartido por todos los usuarios, se requiere un cho de banda entre la mayor cantidad de usuarios posible. El método utilizado en

(Time Division Multiple Access / Frequency Division

, donde los canales de radio se basan en una estructura TDMA que es implementada en

]: la banda de 890-915 MHz es usada para 3. Adicionalmente, se tienen

1710 MHz a 1785 MHz y la otra de 1805 MHz a 900 está dividida en 124 portadoras y las de GSM-1800 en

374 portadoras, que en ambos casos están separadas por 200 kHz. Una o varias frecuencias portadoras son

Cada una de las frecuencias de radio está dividida en 26 tramas de 4.615 ms (usando un esquema TDMA), time slots. Hay dos tipos de

en particular en cada una de las de información llevada en él [6]. La división

900, y la representación de un canal físico y lógico se muestra en la

Los canales lógicos pueden ser de tráfico ó de control. Los canales de tráfico (TCH) son recursos para voz ó datos y tienen dos formas de servicio: Full

sirven para señalización y son los que

Canal que soporta tasas de bits de 13kbps (para voz) y 9.6kbps, 4.8kbps ó 2.4kbps (para datos)

6

Los canales lógicos son mapeados en canales físicos y es así como los canales de tráfico TCH/F son definidos como un grupo de 26 tramas de las cuales 24 son para datos o voz, una para SACCH y la otra normalmente no es usada. De tal forma que un time slot de la trama correspondiente a SACCH controla a un canal físico, que es por ejemplo el grupo de todos los segundos time slots de cada una de las 24 tramas de voz o datos, es decir, cada SACCH es dedicado a uno de los ocho TCH. Adicionalmente, existe una estructura de 51 tramas usada para el seguimiento de canales de señalización y control. Ver Figura 3.

2.1.3. Protocolos y Modelo OSI

Por otro lado, la arquitectura de los protocolos de GSM está dividida en tres capas principales que utilizan ciertos protocolos dependiendo de la interfaz, tal y como se muestra en la Figura 4. Dichas capas se describen a continuación [4], [5] y [6]:

Figura 4. Arquitectura de los protocolos de GSM


1. La capa física, utiliza en la interfaz de aire la estructura TDMA discutida previamente, mientras que en la interfaz “A” recurre a MTP (Message Transfer Part), el cual trabaja sobre las tres capas (MTP 1, MTP 2, MTP 3) y en general es el encargado de transportar y direccionar bits entre dos nodos, suministrando los medios eléctricos y físicos para la transmisión (MTP 1) y definiendo la estructura de la trama de los diferentes mensajes (MTP 2).

2. La capa de enlace, en la interfaz de aire usa el protocolo LAPDm (Link Access Protocol for D-channel modified), que es una versión modificada del LAPD, pues se dejan de utilizar algunos campos de la estructura del mensaje tal como el FCS (Frame Check Sequence) porque la detección y corrección de errores ahora es desarrollada por la codificación y decodificación de canal. LAPDm provee las bases de la señalización en la interfaz de aire, incluyendo funciones para el control de flujo, el control de secuencia y la detección de errores. Información más detallada de éste protocolo se encuentra en [4] y [8]. En la interfaz “A”, la capa de enlace utiliza MTP 2, que incluye además de las funciones previamente descritas el transporte confiable de los mensajes de señalización.

3. La capa de mensaje es llamada de ésta forma para que no se presenten confusiones con la capa 3 del modelo OSI. Esta capa se divide en tres subcapas:

5 Canal que soporta tasas de bits de 6.5kbps (para voz) y 4.8kbps ó 2.4kbps (para datos)

RR

LAPDm

TDMA

LAPDm

TDMA

MTP 2

MTP 1

MTP2

MTP 1

BSSAPSCCPMTP 3

MM

RR

CM

BSSMAPSCCPMTP 3

MS

BTS BSC

MSC

Interfaz de aire Interfaz “A”

CM DTA

MM P

CAPA 2

CAPA 1

CAPA 3

• RR (Radio Resource Management)

canales lógicos y físicos en la interfaz de aire y es el encargado de transmitir información de señalización relacionada con las llamadas. RR es implementado sobre el enlace entre el MS y el BTS, por lo que solo es utilizado en la interfaz de aire. En la interfaz “A”, ésta subcapa recurre al protocolo BSSAP Application Part)

éste a su vez necesita de los servicios prestados por MTP 3, ya que SCCP permidireccionamiento inclusive a través de muchos nodos y ciudades. BSSAP tiene dos partes: BSSMAP (Base Station Subsystem Management Application Part)

que fueron RR y los que se usan para tareas de control intercambiados entre ey, DTAP (Direct Transfer Application Part)

el MS y el MSC.

• MM (Mobility Management)

de forma transparente entre el MS y el NSS. Ela red informada acerca de la movilidad de los subscriptores, así como aspectos relacionados con la autentificación y la seguridad. En general, el BSS no procesa mensajes MM.

• CM (Connection Management)

de servicios suplementarios como SMS llamadas, lo cual incluye funciones como establecimiento de la llamada y selección del tipo de servicio.

2.2. Sistemas de espera

La teoría de sistemas de espera es una técnica fundamental para modelar y analizar el desempeño de cualquier sistema o proceso. Históricamente, estos modelos han sido utilizados en problemas de diseño telefónico tradicional como centrales de conmuExchange), entre otros. Un sistema con una o múltiples estaciones de servicio consiste en una cola de almacenamiento de tamaño finito o infinito y uno a más servidores idénticos, como se muestra en Figura 5.

2.2.1. Planteamiento General

Un servidor puede atender a una única entidad a la vez, por lo cual, el estado del servidor puede ser ocupado o desocupado. Si todos los servidores se encuentran ocsistema, dicha entidad es almacenada en la cola, mientras disponga de espacio, y espere su turno; de lo contrario, la entidad es rechazada. Una vez sea atendida una de las entidades en servicio, ésta sale del

7

(Radio Resource Management): Supervisa el establecimiento del enlace, administra los lógicos y físicos en la interfaz de aire y es el encargado de transmitir información de

señalización relacionada con las llamadas. RR es implementado sobre el enlace entre el MS y el BTS, por lo que solo es utilizado en la interfaz de aire. En la interfaz “A”, ésta subcapa recurre al protocolo BSSAP Application Part), el cual es soportado gracias a SCCP (Signaling Connection Control Part)

éste a su vez necesita de los servicios prestados por MTP 3, ya que SCCP permidireccionamiento inclusive a través de muchos nodos y ciudades. BSSAP tiene dos partes:

(Base Station Subsystem Management Application Part)

que fueron RR y los que se usan para tareas de control intercambiados entre e(Direct Transfer Application Part) que comprende los mensajes intercambiados por

(Mobility Management): Utiliza el canal proporcionado por RR para intercambiar datos de forma transparente entre el MS y el NSS. Entre sus ocupaciones se encuentra el mantener a la red informada acerca de la movilidad de los subscriptores, así como aspectos relacionados con la autentificación y la seguridad. En general, el BSS no procesa mensajes MM.

(Connection Management): Provee comunicación entre el MS y el NSS. Es responsable de servicios suplementarios como SMS (Short Message Service)llamadas, lo cual incluye funciones como establecimiento de la llamada y selección del tipo

La teoría de sistemas de espera es una técnica fundamental para modelar y analizar el desempeño de cualquier sistema o proceso. Históricamente, estos modelos han sido utilizados en problemas de diseño telefónico tradicional como centrales de conmutación, celdas inalámbricas de voz, y PBX

, entre otros. Un sistema con una o múltiples estaciones de servicio consiste en una cola de almacenamiento de tamaño finito o infinito y uno a más servidores idénticos, como se muestra en

Figura 5. Estación de servicio con c servidores


Planteamiento General

Un servidor puede atender a una única entidad a la vez, por lo cual, el estado del servidor puede ser ocupado o desocupado. Si todos los servidores se encuentran ocupados cuando una nueva entidad llega al sistema, dicha entidad es almacenada en la cola, mientras disponga de espacio, y espere su turno; de lo contrario, la entidad es rechazada. Una vez sea atendida una de las entidades en servicio, ésta sale del

: Supervisa el establecimiento del enlace, administra los lógicos y físicos en la interfaz de aire y es el encargado de transmitir información de

señalización relacionada con las llamadas. RR es implementado sobre el enlace entre el MS y

En la interfaz “A”, ésta subcapa recurre al protocolo BSSAP (Base Station Subsystem (Signaling Connection Control Part) y

éste a su vez necesita de los servicios prestados por MTP 3, ya que SCCP permite el direccionamiento inclusive a través de muchos nodos y ciudades. BSSAP tiene dos partes:

(Base Station Subsystem Management Application Part) que incluye los mensajes que fueron RR y los que se usan para tareas de control intercambiados entre el BSC y el MSC;

que comprende los mensajes intercambiados por

: Utiliza el canal proporcionado por RR para intercambiar datos ntre sus ocupaciones se encuentra el mantener a

la red informada acerca de la movilidad de los subscriptores, así como aspectos relacionados con la autentificación y la seguridad. En general, el BSS no procesa mensajes MM.

ee comunicación entre el MS y el NSS. Es responsable (Short Message Service) y de un control general de

llamadas, lo cual incluye funciones como establecimiento de la llamada y selección del tipo

La teoría de sistemas de espera es una técnica fundamental para modelar y analizar el desempeño de cualquier sistema o proceso. Históricamente, estos modelos han sido utilizados en problemas de diseño

tación, celdas inalámbricas de voz, y PBX (Private Branch

, entre otros. Un sistema con una o múltiples estaciones de servicio consiste en una cola de almacenamiento de tamaño finito o infinito y uno a más servidores idénticos, como se muestra en la

Un servidor puede atender a una única entidad a la vez, por lo cual, el estado del servidor puede ser upados cuando una nueva entidad llega al

sistema, dicha entidad es almacenada en la cola, mientras disponga de espacio, y espere su turno; de lo contrario, la entidad es rechazada. Una vez sea atendida una de las entidades en servicio, ésta sale del

8

sistema, y una de las que se encuentran en espera es seleccionada, según una disciplina de servicio, para ser atendida por uno de los servidores.

Figura 6. Componentes básicos de un sistema de espera simple


Un sistema de espera como el de la Figura 6 es caracterizado por los siguientes elementos:

• Proceso de arribo: Indica la distribución probabilística que siguen las entidades cuando éstas llegan al sistema. Uno de los procesos de arribo más común es el llamado proceso de Poisson, el cual tiene la característica que los tiempos entre arribos forman una secuencia de variables aleatorias independientes e idénticamente distribuidas (IID) de tipo exponencial. Algunas propiedades especiales de los procesos de Poisson puede encontrarse en [10].

• Tiempo de servicio: Usualmente se asume que los tiempos de servicio son variables aleatorias independientes e idénticamente distribuidas que hacen referencia al tiempo que una entidad utiliza el servidor. La distribución más común es la de tipo exponencial.

• Número de servidores: Establece el número de servidores idénticos que se encuentran en el sistema. A

cada servidor se le asigna una única entidad.

• Capacidad del sistema: Determina el número total de entidades que el sistema puede recibir, incluyendo las entidades esperando a ser atendidas y aquellas que se encuentran en servicio. Por ende, dicho valor está directamente relacionado con la capacidad de almacenamiento de la cola y puede ser tanto finito como infinito (muy grande en el sentido práctico).

• Tamaño de la población: Hace referencia al número total de entidades que eventualmente puedan

llegar a utilizar el sistema. Una vez más, dicho número puede ser finito o infinito, si el potencial de entidades es muy grande.

• Disciplina de servicio: Especifica el orden en el cual las entidades son atendidas por los servidores. La

disciplina que más se utiliza es aquella en la cual la primera entidad en llegar al sistema es la primera en ser atendida, conocida como FCFS (First Come First Served). Otras disciplinas de servicio se pueden encontrar en [9].

9

2.2.2. Notación Kendall

Los parámetros descritos anteriormente caracterizan un sistema de espera simple y pueden abreviarse según la notación Kendall de la forma A/S/n/B/K/SD [10], donde cada una de las letras corresponde a cada uno de los parámetros. Así que, A es la distribución del tiempo entre arribos, S es la distribución de los tiempos de servicio, n es el número de servidores, B es la capacidad del sistema, K es el tamaño de la población y SD es la disciplina de servicio. En caso que se omitan las letras B y/o K, implica que las cantidades tienen un valor infinito; adicionalmente, si no se menciona la disciplina de servicio, es porque se estará considerando de tipo FCFS.

La distribución del tiempo entre arribos y de los tiempos de servicio se denotan generalmente con los siguientes símbolos [9] y [10]:

M – Variable aleatoria Exponencial. Ek – Variable aleatoria Erlang con parámetro k. D – Variable determinística. G – Variable aleatoria arbitraria.

Históricamente se acepta la letra “M” para la variable aleatoria exponencial ya que esta es la única que no tiene memoria (Memoryless). Un detallado estudio de las variables aleatorias Exponencial y Erlang se presenta en [10] capitulo 29. Otro tipo de distribuciones se pueden encontrar en [9].

2.2.3. Definición de variables

Los sistemas de espera simples pueden ser analizados mediante las variables que se detallan en la Figura 7. Algunas de ellas, son variables aleatorias, por lo tanto, conceptos como el valor esperado y la varianza serán tenidos en cuenta.

Figura 7. Variables utilizadas en el análisis de un sistema de espera simple.

Fuente. Modificado de [10]

10

• λ = tasa promedio de arribo. • µ = tasa promedio de servicio. • τ = tiempo entre arribos. • s = tiempo de servicio de un servidor. • nt = número de entidades en el sistema. • nq = número de entidades en la cola. • ns = número de entidades en servicio. • r = tiempo que se demora una entidad en el sistema. • w = tiempo que se demora una entidad en la cola.

El valor esperado de los tiempos de arribo se denota como [ ]τE , el cual define la tasa de arribo λ como el inverso de [ ]τE . Análogamente, el valor esperado de los tiempos de servicio se denota como [ ]sE y define la tasa de servicio µ como el inverso de [ ]sE . La relación entre λ y µ se conoce como la carga de tráfico ofrecida por el sistema (a), representa la cantidad de entidades promedio que están siendo atendidas por todos los servidores y su unidad de medida es Erlang6. De esta forma, la relación entre a y el número de servidores define la carga de tráfico ofrecida por servidor (ρ). Por lo tanto, las ecuaciones (1) y (2) describen dichas cargas.

µλ=a (1)

n

a=ρ (2)

Para el caso de sistemas de espera con una capacidad de almacenamiento infinita se debe tener en cuenta la estabilidad del sistema, que se obtiene cuando estrictamente se cumple que 1≤ρ . Lo cual significa que en promedio, el número de entidades que llegan al sistema de tiempo debe ser menor al número de entidades que pueden ser procesadas por el mismo, dando lugar a la condición (3).

µλ n≤ (3)

Los sistemas de espera con capacidad de almacenamiento finita no pueden ser inestables, ya que las entidades son rechazadas cuando el número de entidades en el sistema exceda la capacidad del mismo.

2.2.4. Sistema de Espera M/M/n/n

El modelo de una celda celular GSM con tráfico de voz heterogéneo, es basado en un sistema de espera M/M/n/n según la notación Kendall, el cual indica que [10]:

• M. El arribo de llamadas al sistema sigue un proceso de tipo Poisson, lo cual implica, que el intervalo de tiempo entre dos llamadas consecutivas que ingresan al sistema sigue una distribución de tipo exponencial.

• M. La distribución del tiempo de servicio también es de tipo exponencial, tiempo que corresponde a la duración de una llamada activa.

• n. Se tienen n servidores, en donde cada uno de ellos está vinculado a un canal de transmisión.

• n. La capacidad del sistema es de n llamadas, que corresponden a aquellas que están recibiendo servicio, ya que se intuye que el modelo de simulación no incluye cola.

6 Erlang: Intensidad de tráfico en los sistemas de Telecomunicaciones.

11

• El tamaño de la población es infinito, lo cual indica que el número de personas potenciales que pueden ingresar al sistema es muy grande.

• La disciplina de servicio que se lleva a cabo es FCFS, especificando el orden en el cual las llamadas son atendidas, es decir, la primera llamada que ingrese al sistema es la primera en ser atendida por un servidor.

En resumen, se puede afirmar que el modelo M/M/n/n representa un sistema de espera que no tiene cola, es decir, las llamadas que antes esperaban para ser atendidas cuando todos los servidores se encontraban ocupados, ahora serán bloqueadas. Por lo cual, la probabilidad de que existan llamadas rechazadas, se calcula matemáticamente a través de la ecuación (3) conocida como la fórmula de Erlang B [10]:

( )[ ]∑=

=n

j

j

n

B

ja

naP

0

!/

!/)( (3)

Debido a dichas pérdidas, se deben tener en cuenta tres cargas de tráfico diferentes: Ofrecida (a), bloqueada (aBloqueada) y cursada (aCursada), las cuales cumplen la relación dada por la ecuación (4)

BloqueadaCursada aaa += (4)

Y se encuentran definidas en las ecuaciones (5) y (6)

)1( BCursada Paa −= (5)

BBloqueada aPa = (6)

Buscando determinar el valor esperado de la variable aleatoria B, que denota el número de servidores ocupados se lleva a cabo la siguiente demostración tomada de [11].

Sean nρ la probabilidad en estado estacionario de que haya n entidades en el sistema y 0ρ la proporción

del tiempo en que el sistema se encuentra libre, representadas en las ecuaciones (7) y (8).

( )0!

ρρn

an

n = (7) ( )

1

00 !

−

=

= ∑

c

k

k

k

aρ (8)

El número esperado de servidores ocupados estará dado por:

{ }

( )( )

( ) ( )( )

( )

( ) ( ) ( ) ( )

( )( ) (9) 1

1!

!!

!1

!1

1

!

!

00

000

1

!1

0

10

1

B

c

n

n

c

n

ncc

n

n

c

n

n

c

n

n

c

n

n

Pa

n

a

c

a

n

aa

n

aa

nn

n

n

an

nBE

−=

==

−=

−=

−==

=

∑∑∑

∑

∑

∑

===

=

−=

=

ρρρ

ρ

ρ

ρ

Por lo tanto, { }BE es igual a la carga de tráfico cursada, resultado que será tenido en cuenta en el análisis del modelo.

2.3. Simulación

La programación matemática, la estadística y la simulación, son tres de las técnicas más usadas para la gestión de la ciencia. Siendo la simde diferentes procesos del mundo real, evaluar el modelo numéricamente y recolectar información para estimar las características deseadas del modelo.

Usualmente un proceso es también llaminteractúan entre sí para cumplir una determinada tarea y llevar a cabo un fin específico. Dichas interacciones toman la forma de relaciones tanto matemáticas como lógicas que constituyen un modeldescriben el comportamiento del sistema. Adicionalmente, las entidades son caracterizadas por valores llamados atributos que hacen parte del estado del sistema, el cual a su vez es el conjunto de variables necesarias para describir el sistema en un tie

El estudio de un sistema resulta necesario cuando se desea obtener información acerca de las relaciones entre los diversos componentes, o para predecir el desempeño del mismo bajo nuevas condicioneFigura 8 muestra diferentes formas en las que un sistema puede ser estudiado. Una detallada comparación de las diferentes formas de estudiar un sistema se puede encontrar en

Cuando el modelo del sistema es lo spreferible estudiar el sistema de ésta manera y no a través de la simulación, ya que la solución analítica permite obtener información exacta del sistema por medio de métodos matemáticoestadística y la probabilidad. Por el contrario, el estudio a través de la simulación permite analizar modelos más complejos, a una mayor velocidad y disminuyendo tanto el tiempo como los altos costos que involucra la implementación dse llevará a cabo por medio de una simulación, éste se denominará como un modelo de simulación.

El modelo de simulación a considerar es: discreto, dinámico y estocástico, por lo que s“modelo de simulación mediante eventos discretos”. Sus características se describen a continuación:

12

es igual a la carga de tráfico cursada, resultado que será tenido en cuenta en el análisis

La programación matemática, la estadística y la simulación, son tres de las técnicas más usadas para la gestión de la ciencia. Siendo la simulación una poderosa herramienta que permite emular las operaciones de diferentes procesos del mundo real, evaluar el modelo numéricamente y recolectar información para estimar las características deseadas del modelo.

Usualmente un proceso es también llamado sistema, y se define como la colección de entidades que interactúan entre sí para cumplir una determinada tarea y llevar a cabo un fin específico. Dichas interacciones toman la forma de relaciones tanto matemáticas como lógicas que constituyen un modeldescriben el comportamiento del sistema. Adicionalmente, las entidades son caracterizadas por valores llamados atributos que hacen parte del estado del sistema, el cual a su vez es el conjunto de variables necesarias para describir el sistema en un tiempo determinado, en relación con los objetivos de estudio.

El estudio de un sistema resulta necesario cuando se desea obtener información acerca de las relaciones entre los diversos componentes, o para predecir el desempeño del mismo bajo nuevas condicione

muestra diferentes formas en las que un sistema puede ser estudiado. Una detallada comparación de las diferentes formas de estudiar un sistema se puede encontrar en [12].

Figura 8. Formas de estudiar un sistema

Fuente. Modificada de [12]

Cuando el modelo del sistema es lo suficientemente simple, la solución analítica es viable y eficiente, es preferible estudiar el sistema de ésta manera y no a través de la simulación, ya que la solución analítica permite obtener información exacta del sistema por medio de métodos matemáticoestadística y la probabilidad. Por el contrario, el estudio a través de la simulación permite analizar modelos más complejos, a una mayor velocidad y disminuyendo tanto el tiempo como los altos costos que involucra la implementación del sistema. Una vez se determine que el estudio de un modelo matemático se llevará a cabo por medio de una simulación, éste se denominará como un modelo de simulación.

El modelo de simulación a considerar es: discreto, dinámico y estocástico, por lo que s“modelo de simulación mediante eventos discretos”. Sus características se describen a continuación:

es igual a la carga de tráfico cursada, resultado que será tenido en cuenta en el análisis

La programación matemática, la estadística y la simulación, son tres de las técnicas más usadas para la ulación una poderosa herramienta que permite emular las operaciones

de diferentes procesos del mundo real, evaluar el modelo numéricamente y recolectar información para

ado sistema, y se define como la colección de entidades que interactúan entre sí para cumplir una determinada tarea y llevar a cabo un fin específico. Dichas interacciones toman la forma de relaciones tanto matemáticas como lógicas que constituyen un modelo y describen el comportamiento del sistema. Adicionalmente, las entidades son caracterizadas por valores llamados atributos que hacen parte del estado del sistema, el cual a su vez es el conjunto de variables

mpo determinado, en relación con los objetivos de estudio.

El estudio de un sistema resulta necesario cuando se desea obtener información acerca de las relaciones entre los diversos componentes, o para predecir el desempeño del mismo bajo nuevas condiciones. La

muestra diferentes formas en las que un sistema puede ser estudiado. Una detallada comparación

uficientemente simple, la solución analítica es viable y eficiente, es preferible estudiar el sistema de ésta manera y no a través de la simulación, ya que la solución analítica permite obtener información exacta del sistema por medio de métodos matemáticos como el cálculo, la estadística y la probabilidad. Por el contrario, el estudio a través de la simulación permite analizar modelos más complejos, a una mayor velocidad y disminuyendo tanto el tiempo como los altos costos que

el sistema. Una vez se determine que el estudio de un modelo matemático se llevará a cabo por medio de una simulación, éste se denominará como un modelo de simulación.

El modelo de simulación a considerar es: discreto, dinámico y estocástico, por lo que se denomina “modelo de simulación mediante eventos discretos”. Sus características se describen a continuación:

13

• Un modelo de simulación es discreto si las variables de estado cambian instantáneamente en puntos separados del tiempo.

• Un modelo de simulación dinámico representa un sistema que evoluciona a través del tiempo, es decir, la variable de tiempo debe ser considerada.

• Un modelo de simulación es estocástico si alguna de las variables de entrada al sistema es aleatoria, lo que produce por sí mismo una salida aleatoria del sistema.

En una simulación, los números aleatorios son producidos usando algún algoritmo en particular, el cual toma un valor de semilla y realiza los cálculos determinísticos necesarios para producir tanto el número aleatorio como la nueva semilla. De no ser así, al comenzar la simulación desde un mismo valor de semilla, la secuencia de números aleatorios producida por el algoritmo será siempre la misma.

Dichos algoritmos se denominan generadores de números aleatorios, RNGs por sus siglas en Ingles, y producen enteros distribuidos uniformemente en un rango específico, usualmente entre 0 ó 1 y 232. Se utilizan transformaciones matemáticas para producir los números aleatorios correspondientes a una distribución probabilística específica.

2.3.1. Simulación mediante eventos discretos.

Las variables y los eventos son los elementos fundamentales en una simulación mediante eventos discretos. Un evento se refiere a una ocurrencia instantánea en el tiempo que puede llegar a cambiar el estado del sistema, y en dicho caso, los valores de las variables deben ser actualizadas. En general, las variables que se utilizan con mayor frecuencia según [13] son:

• Estado del sistema: Son la colección de las variables de estado necesarias para describir el sistema en un tiempo específico.

• Tiempo: Es la variable que especifica el valor del tiempo actual de la simulación. Usualmente es llamada simulation clock.

• Contadores estáticos: Son variables que almacenan información acerca del funcionamiento del sistema, mantienen un conteo del número de veces que ocurren ciertos eventos.

Debido a la dinámica del modelo de simulación, se debe llevar un seguimiento continuo de la variable de tiempo a medida que la simulación avanza, así mismo, es necesario un mecanismo que permita actualizar dicha variable. Históricamente, se han sugerido dos principales métodos que permiten avanzar en el tiempo de un valor a otro: incremento fijo (fixed-increment time advance) y próximo evento (next-event

time advance). La mayoría de los lenguajes de propósito general y de las herramientas de simulación utilizan el mecanismo de avance en el tiempo por próximo evento, razón por la cual, dicha aproximación será de principal interés. Una breve descripción del avance en el tiempo por incremento fijo se puede encontrar en [12] apéndice 1A.

El avance en el tiempo por próximo evento consiste en adelantar la variable de tiempo (simulation clock) al instante de ocurrencia del evento más próximo. Para ello, debe definirse un nuevo componente del modelo de simulación conocido como lista de eventos, la cual contiene los tiempos en los cuales éstos han de ocurrir. Una vez la variable sea inicializada en cero y los tiempos de ocurrencia de los próximos eventos sean generados, la variable simulation clock es adelantada al tiempo en el cual el evento futuro más inminente ha de suceder, y tanto el estado del sistema como la lista de eventos son actualizados. Este proceso repetitivo continúa hasta que eventualmente se cumpla alguna condición de interrupción.

La organización lógica y estructurada entre los compdepuración de errores y futuros cambios en el código de programación con mayor facilidad. Dicha organización se puede esquematizar en un diagrama general de las relaciones lógicas entre los componentes, o también llamado flujo de control como se observa en la el uso de los siguientes componentes que comparten la mayoría de loeventos discretos:

• Programa principal: Un subprograma que invoca las demás rutinas para cumplir tareas específicas. Comprueba cuando la simulación debe acabarse según la condición de interrupción.

• Rutinas de librerías: Un diferentes funciones de distribución previamente definidas en el modelo de simulación.

• Rutina de inicialización: Un subprograma que inicializa todas las variables del modelo de simulacióa un valor, en general, dicho valor es igual a cero.

• Rutina de tiempo: Un subprograma que determina cual es el próximo evento de la lista de eventos y avanza el simulation clock

• Rutina de evento: Un subprograma

ocurre. Debe haber una rutina por cada tipo de evento.

• Generador de reportes: Un subprograma que estima los parámetros de desempeño del modelo de simulación a partir de los contadores est

Figura 9. Diagrama de flujo de control para avance en el tiempo por próximo evento

14

La organización lógica y estructurada entre los componentes del modelo de simulación permite la depuración de errores y futuros cambios en el código de programación con mayor facilidad. Dicha organización se puede esquematizar en un diagrama general de las relaciones lógicas entre los

llamado flujo de control como se observa en la Figura el uso de los siguientes componentes que comparten la mayoría de los modelos de simulación mediante

Programa principal: Un subprograma que invoca las demás rutinas para cumplir tareas específicas. Comprueba cuando la simulación debe acabarse según la condición de interrupción.

Rutinas de librerías: Un conjunto de subprogramas usados para generar variables aleatorias de diferentes funciones de distribución previamente definidas en el modelo de simulación.

Rutina de inicialización: Un subprograma que inicializa todas las variables del modelo de simulacióa un valor, en general, dicho valor es igual a cero.

Rutina de tiempo: Un subprograma que determina cual es el próximo evento de la lista de eventos y simulation clock al tiempo en el cual dicho evento ocurre.

Rutina de evento: Un subprograma que actualiza el estado del sistema cuando un evento en particular ocurre. Debe haber una rutina por cada tipo de evento.

Generador de reportes: Un subprograma que estima los parámetros de desempeño del modelo de simulación a partir de los contadores estáticos.

. Diagrama de flujo de control para avance en el tiempo por próximo evento

Fuente. Modificada de [12]

onentes del modelo de simulación permite la depuración de errores y futuros cambios en el código de programación con mayor facilidad. Dicha organización se puede esquematizar en un diagrama general de las relaciones lógicas entre los

Figura 9. Para ello, es importante s modelos de simulación mediante

Programa principal: Un subprograma que invoca las demás rutinas para cumplir tareas específicas. Comprueba cuando la simulación debe acabarse según la condición de interrupción.

conjunto de subprogramas usados para generar variables aleatorias de diferentes funciones de distribución previamente definidas en el modelo de simulación.

Rutina de inicialización: Un subprograma que inicializa todas las variables del modelo de simulación

Rutina de tiempo: Un subprograma que determina cual es el próximo evento de la lista de eventos y

que actualiza el estado del sistema cuando un evento en particular

Generador de reportes: Un subprograma que estima los parámetros de desempeño del modelo de

. Diagrama de flujo de control para avance en el tiempo por próximo evento

15

El diagrama de flujo de la Figura 9 muestra el proceso que una entidad común debe experimentar a medida que fluye a través del sistema. Una breve descripción de dicho proceso se presenta a continuación.

En general, cualquier simulación comienza con el programa principal invocando la rutina de inicialización, donde la variable simulation clock es inicializada en cero, junto a los contadores estáticos, el estado del sistema y la lista de eventos. El control lo toma nuevamente el programa principal y este invoca la rutina de tiempo para determinar cual tipo de evento es el más inminente, se avanza el simulation clock al tiempo en que el evento tipo i ocurre y se regresa el control al programa principal; éste, invoca la rutina del evento tipo i donde suceden las siguientes eventualidades, se actualizan tanto el estado del sistema como los contadores estáticos, se invoca la rutina de librería para generar los tiempos de ocurrencia de los futuros eventos y se actualiza la lista de eventos. Una vez se lleve a cabo este proceso, se procede a comprobar si la condición de interrupción se satisface; de ser así, el generador de reportes es invocado para estimar los parámetros de desempeño deseados y se termina la simulación; de lo contrario, el control es pasado una vez más al programa principal quien comienza el proceso nuevamente invocando la rutina de tiempo. Este ciclo debe repetirse hasta que dicha condición sea cumplida.

En conclusión, un sistema real puede ser representado a través de un modelo de simulación mediante eventos discretos y debe ser implementado en una herramienta de simulación para estimar los parámetros de interés.

2.3.2. Herramienta de Simulación

OMNeT++ 4.0 [14] es una herramienta de simulación basada en programación orientada a objetos (OO), que permite emular el comportamiento de sistemas reales, representados a través de un modelo de simulación mediante eventos discretos. El proceso de instalación se describe en el Anexo 8.1.

Una de sus principales ventajas es que la implementación de modelos de simulación se puede realizar anidando diferentes componentes, también llamados módulos, los cuales a su vez pueden ser reutilizados a lo largo de la simulación. El uso de su arquitectura genérica, ha permitido que la herramienta sea implementada a gran escala en el ámbito de las telecomunicaciones, donde su uso se ha extendido enormemente al modelamiento de diferentes sistemas. Algunos ejemplos son:

• Modelos de sistemas de comunicación tanto cableada como inalámbrica. • Modelos de protocolos. • Modelos de sistemas de espera (Queueing networks).

El modelo de simulación que se implementa en OMNeT++ 4.0 es llamado Network y consiste en módulos que se comunican entre sí intercambiando mensajes. Dichos módulos, son programados en C++ y poseen cierto grado de jerarquía. Los módulos activos, llamados módulos simples, se encuentran en el nivel de jerarquía más bajo y contienen los algoritmos del modelo. Ver Figura 10.

Los módulos compuestos son aquellos que contienen sub-módulos, los cuales pueden ser a su vez tanto módulos simples como compuestos, haciendo que el número de niveles de jerarquía no esté limitado. El módulo del sistema (Network), es en sí mismo un módulo compuesto con el mayor nivel de jerarquía.

Tal como se muestra en la Figura 10, la conexión entre los diferentes módulos se lleva a cabo a través de una interfaz llamada compuerta, ó también conocida como gate, la cual puede ser de entrada o de salida. Cada conexión, llamada enlace, se crea dentro de un solo nivel de jerarquía. Al interior de un módulo compuesto, son permitidas dos conexiones: entre las compuertas de dos sub-módulos; y entre la compuerta de un sub-módulo y la compuerta de un módulo compuesto. Por el contrario, a través de los niveles de jerarquía las conexiones no son permitidas ya que inhabilita al modelo para que sea reutilizado.

Debido a la estructura jerárquica del modelo, los mensajes viajan a través de una serie de enlaces que comienzan y terminan en módulos simples, a dicho camino de inicio a fin se le denomina motivo, los módulos compuestos actúan de forma transparente a la transmisión de mensajes entre su interior y exterior. A cada uno de los enlaces, le puede ser asignado diferentes parámetros como: retardo de propagación7, la tasa de bitdel modelo sea más aproximado al desempeño real del sistema.

En una simulación, los mensajes pueden representar entidades como tramas, paquetes, usuarios, clientes, llamadas, etc., según el modelo de simulación. Estos viajan a través de una ruta por medio de diferentes enlaces y compuertas (gates), y cuyo destino puede llegar a ser el mismo módulo simple que lo envía, o uno diferente. Los mensajes contienen tanto información acerca de la occomo información arbitraria.

Un modelo en OMNeT++ 4.0 consta de las siguientes extensiones para los archivos:

• Archivo .ned: Incluye la descripción de la estructura de módulos con sus respectivos parámetros, compuertas (gates), etc. Los archivos NED un editor de texto como en modo gráfico.

• Archivos .h/.cc: Son las fuentes de los módulos simples y son escritos en C++.

• Archivo .ini: Es un archivo en el que se lleva a cabinformación de entrada como parámetros de los módulos, generadores de números aleatorios y el tiempo de la simulación, entre otros.

• Archivo .msg: Son definiciones de mensaje que OMNeT++ 4.0 traduce en cla

El sistema de simulación provee los siguientes componentes:

• Núcleo de simulación (Simulation Kernel)

librerías que contienen las diferentes clases.

7 Se refiere a la cantidad de tiempo que el mensaje tarda cuando é8 Permite establecer el tiempo de transmisión de un paquete. Las unidades son bis/segundos.9 Especifica la probabilidad que un bit sea transmitido de manera incorrecta a través del canal.

16

Figura 10. Módulos simples y compuestos


Debido a la estructura jerárquica del modelo, los mensajes viajan a través de una serie de enlaces que comienzan y terminan en módulos simples, a dicho camino de inicio a fin se le denomina motivo, los módulos compuestos actúan de forma transparente a la transmisión de mensajes entre su interior y exterior. A cada uno de los enlaces, le puede ser asignado diferentes parámetros como: retardo

, la tasa de bit8 y la tasa de error de bit9. Estas medidas permiten que el comportamiento del modelo sea más aproximado al desempeño real del sistema.

En una simulación, los mensajes pueden representar entidades como tramas, paquetes, usuarios, clientes, l modelo de simulación. Estos viajan a través de una ruta por medio de diferentes

), y cuyo destino puede llegar a ser el mismo módulo simple que lo envía, o uno diferente. Los mensajes contienen tanto información acerca de la ocurrencia del evento (


Archivo .ned: Incluye la descripción de la estructura de módulos con sus respectivos parámetros, , etc. Los archivos NED (Network Description) pueden ser desarrollados tanto en

un editor de texto como en modo gráfico.

Archivos .h/.cc: Son las fuentes de los módulos simples y son escritos en C++.

Archivo .ini: Es un archivo en el que se lleva a cabo la configuración de la simulación, especificando información de entrada como parámetros de los módulos, generadores de números aleatorios y el tiempo de la simulación, entre otros.

Archivo .msg: Son definiciones de mensaje que OMNeT++ 4.0 traduce en cla

El sistema de simulación provee los siguientes componentes:

(Simulation Kernel): Contiene el código que controla la simulación y el de las librerías que contienen las diferentes clases.

Se refiere a la cantidad de tiempo que el mensaje tarda cuando éste viaja a través del canal.

Permite establecer el tiempo de transmisión de un paquete. Las unidades son bis/segundos.

Especifica la probabilidad que un bit sea transmitido de manera incorrecta a través del canal.

Debido a la estructura jerárquica del modelo, los mensajes viajan a través de una serie de enlaces que comienzan y terminan en módulos simples, a dicho camino de inicio a fin se le denomina ruta. Por tal motivo, los módulos compuestos actúan de forma transparente a la transmisión de mensajes entre su interior y exterior. A cada uno de los enlaces, le puede ser asignado diferentes parámetros como: retardo

. Estas medidas permiten que el comportamiento

En una simulación, los mensajes pueden representar entidades como tramas, paquetes, usuarios, clientes, l modelo de simulación. Estos viajan a través de una ruta por medio de diferentes

), y cuyo destino puede llegar a ser el mismo módulo simple que lo envía, o urrencia del evento (timestamp)


Archivo .ned: Incluye la descripción de la estructura de módulos con sus respectivos parámetros, pueden ser desarrollados tanto en

Archivos .h/.cc: Son las fuentes de los módulos simples y son escritos en C++.

o la configuración de la simulación, especificando información de entrada como parámetros de los módulos, generadores de números aleatorios y el

Archivo .msg: Son definiciones de mensaje que OMNeT++ 4.0 traduce en clases C++.

: Contiene el código que controla la simulación y el de las

te viaja a través del canal.

Permite establecer el tiempo de transmisión de un paquete. Las unidades son bis/segundos.

Especifica la probabilidad que un bit sea transmitido de manera incorrecta a través del canal.

17

• Interfaces del usuario: Su objetivo es permitir al usuario observar lo que sucede en el interior del modelo, para controlar la ejecución de la simulación e intervenir modificando variables u objetos dentro del modelo

Los datos obtenidos a través de la simulación pueden ser almacenados en dos tipos de estructuras: vectores y/o escalares, los cuales pueden ser exportados para su posterior análisis en programas como Excel, Matlab, entre otros.

De la clase básica cModule, se derivan las clases cCompoundModule y cSimpleModule; ésta última se puede subdividir en más clases que permiten la creación de diferentes tipos de módulos simples y para que sea útil, ésta requiere de las siguientes funciones:

• Void initialize ( ): Es la función de inicialización, en la cual OMNeT++ 4.0 construye el modelo (network), creando los módulos simples y compuestos necesarios y conectándolos de acuerdo a las especificaciones hechas en el archivo .ned. Cuando el módulo es creado, es llamada la función “constructor”, como parte del proceso de configuración del modelo. Mientras que, la función initialize ( ) es llamada antes que la simulación se empiece a ejecutar.

• Void handleMessage ( ): Esta función es llamada durante el procesamiento de un evento. Básicamente, es un método invocado por el simulation kernel cuando el modulo recibe un mensaje. Sus ventajas incluyen un menor consumo de memoria y una mayor velocidad.

• Void activity ( ): Al igual que handleMessage( ) es una función en la que se describe el comportamiento del modelo, permitiendo el procesamiento de un evento, así que para cada módulo simple el usuario debe definir una de estas funciones solamente. La mayor ventaja de activity( ) es que no requiere la utilización de la función initialize( ), pero entre sus desventajas se encuentran su limitada escalabilidad y sus largos tiempos de ejecución. En la mayoría de los casos los beneficios ofrecidos por handleMessage( ) hacen de ésta la mejor opción.

• Void finish ( ): Es invocada cuando la simulación termina de manera exitosa y comúnmente usada en la recopilación de las estadísticas durante la simulación. Es una función que no borra nada ni cancela los temporizadores; todo el proceso de limpieza es realizado por el “destructor”, el cual es invocado después de la función finish( ).

Figura 11. Interacción entre las funciones del cSimpleModule


18

La interacción de las funciones mencionadas se muestra en la Figura 11, en donde vale la pena aclarar que el ciclo hace referencia a una condición de terminación específica que busca asegurar la estabilidad de los parámetros a evaluar.

En términos generales, el simulador representa a los eventos por medio de mensajes, de tal forma que un evento hace referencia a una instancia de la clase cMessage ó a una de sus subclases; así que, no hay clases de eventos independientes. En cuanto al tiempo de simulación, OMNeT++ 4.0 lo almacena en un entero de 64-bits gracias a la clase SimTime y el generador de números aleatorios utilizado es el Mersenne Twister (MT)10 creado por M. Matsumoto y T. Nishimura. El algoritmo tiene un periodo de 219937-1, lo cual evita la correlación de los resultados obtenidos y proporciona una ventaja en el estudio de simulaciones de gran escala; Es además, tan rápido como el algoritmo rand( ) utilizado por el lenguaje de programación C.

2.3.3. Análisis estadístico

Uno de los grandes errores que se comenten en el análisis estadístico de los resultados arrojados por una simulación es el manejo inapropiado de la información. Muchas veces, se realiza una sola corrida cuya longitud m ha sido escogida de forma arbitraria y se toman los resultados como los valores estimados para el modelo de simulación. Sin embargo, estos valores son una muestra particular de la variable aleatoria X que puede llegar a tener una gran varianza, es decir, que los valores estimados de una corrida particular pueden llegar a diferir en gran medida de los valores reales correspondientes al modelo de simulación.

2.3.3.1. Estimador de la media muestral

Una corrida del modelo de simulación produce un conjunto de m muestras (xi1, xi2, … , xim), que forman una variable aleatoria Xi, cuya media poblacional y varianza poblacional son respectivamente, θ y σ2; otra corrida diferente proporciona una nueva variable aleatoria independiente de la anterior, pero con los mismos parámetros. Por lo tanto, al realizar k corridas, se obtendrán k variables aleatorias independientes Xi para i = 1, 2, … , k todas con la misma distribución, media poblacional θ y varianza poblacional σ2; es decir, θ = E[Xi] y σ2 = Var(Xi). Generalmente, en una simulación estos dos parámetros no se conocen, por lo que surge la necesidad de estimarlos [13].

El promedio aritmético de estos k valores es la media muestral X , y sirve como estimador de θ. Mientras que el promedio del cuadrado de la diferencia entre un dato y el estimador de la media (ya que ésta es desconocida) es la varianza muestral

2S , y sirve como estimador de σ2. Por lo tanto, tenemos los siguientes estimadores:

∑=

=k

i

i

k

XX

1

(10) ( )

∑= −

−=

k

i

i

k

XXS

1

22

1 (11)

Naturalmente, la desviación estándar muestral S, sirve como estimador de σ, y se obtiene como la raíz cuadrada de la varianza muestral.

Ya que nuestro análisis estadístico se centra en el estimador de la media poblacional θ, se llevará a cabo un estudio más al detalle sobre el comportamiento de este parámetro. De esta forma, X es una variable aleatoria con media [ ] θ=XE y varianza ( ) kXVar 2σ= como se muestra a continuación.

10 Código del algoritmo disponible en:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/991029/mt19937-1.c

19

[ ][ ]

(12)

1

1

θ

θ

=

=

=

=

∑

∑

=

=

k

k

k

XE

k

XEXE

k

i

i

k

i

i

( ) ( )

( )

(13)

1

1

2

12

1

2

k

XVark

Xk

Var

XVarXE

k

i

i

k

i

i

σ

θ

=

=

=

=

−

∑

∑

=

=

Estos valores permiten determinar la “bondad” de X como estimador de la media poblacional θ, ya que cuando la desviación estándar es pequeña, se dice que se tiene un buen estimador, esto es debido a que es poco probable que una variable aleatoria esté a una distancia de muchas desviaciones estándar de su media. La justificación a la afirmación anterior es una consecuencia de la desigualdad de Chebyshev, la cual se anuncia a continuación. Si Y es una variable aleatoria con media µ, varianza δ2 y desviación estándar δ, entonces para cualquier valor 0>c , la probabilidad de que Y difiera de su media por más de

c desviaciones estándar está acotada por 21 c .

{ }2

1

ccYP ≤≥− δµ (14)

Al aplicar la desigualdad de Chebyshev a la variable aleatorio de interés X , se obtiene la siguiente cota:

{ }{ }

(15) 1

Re1

Re1

Re1

2

2

2

2

ck

ScXP

kpormplazando

ckcXP

pormplazandoc

cXP

XporYmplazandoc

cXP

≤

≥−

≤

≥−

≤≥−

≤≥−

θ

σδσθ

θµδθ

δµ

Donde se ha remplazado la desviación estándar poblacional σ por su estimador S. La demostración formal de la Desigualdad de Chebyshev se puede encontrar en [13]. La aplicación directa de ésta cota, se conoce como el intervalo de confianza y se menciona en la siguiente sección.

2.3.3.2. Intervalo de confianza

A pesar de que el estimador X ofrece una muy buena aproximación de la media poblacional θ , es útil establecer un intervalo para el cual se tiene cierto grado de confianza de que θ esté en él. A partir de [12], [13] y [15] se define éste intervalo, para lo cual se requiere traer a colación el Teorema del Límite Central, a través del cual se establece que para un k grande la variable aleatoria kZ obedece a una distribución normal unitaria.

[ ])1,0(~

)(N

S

Xk

XVar

XEXZk

θ−=−= (16)

Por lo que la función de densidad de probabilidad de 12.

Y se cumple que:

α

<−

21

zZP k

Así que, para k suficientemente grande se tiene que el intervalo de confianza esta dado por (18) el valor del estimador, más o menos un error, que depende del porcentaje de seguridad deseado, es decir, se tiene un 100(1-α) porciento de confiabilidad de que la media poblaintervalo:

A manera de ejemplo, se escoge un porcentaje de confiabilidad del 95%, que al remitirse a la tabla de

densidad de probabilidad de la distribución normal tanto, el intervalo de confianza dado por la ecuación (18) es

Por otro lado, según la cota dada por (15), para este mismo porcentaje de confianza se tiene que

47.405.0/1 ==c , es decir, la probabilidad de que 5%. Si en cambio se toma el mismo intervalo de confianza de confianza obtenido de (18), se obtiene un porcentaje de seguridad del 26.03%. Por lo cual, se puede concluir que esta cota es un poco conservadora si se compara con el Teorema del Límite Centralaproximadamente el 5% [13].

20

Por lo que la función de densidad de probabilidad de kZ se puede representar como la gráfica de la

Figura 12. Densidad normal unitaria

Fuente: Tomado de [12]

α

θ

θ

αα

α

−≈

+<<−=

<−=

−−

−

1

21

21

21

k

SzX

k

SzXP

zS

XkP

suficientemente grande se tiene que el intervalo de confianza esta dado por (18) el valor del estimador, más o menos un error, que depende del porcentaje de seguridad deseado, es decir, se tiene

porciento de confiabilidad de que la media poblacional θ se encue

k

SzX

21

α−±


densidad de probabilidad de la distribución normal unitaria, se refleja en un valor de tanto, el intervalo de confianza dado por la ecuación (18) es:

k

SX 96.1± .


, es decir, la probabilidad de que X difiera de θ por más de 5%. Si en cambio se toma el mismo intervalo de confianza de confianza obtenido de (18), se obtiene un

guridad del 26.03%. Por lo cual, se puede concluir que esta cota es un poco conservadora Teorema del Límite Central, el cual establece que ésta probabilidad es

].

se puede representar como la gráfica de la Figura

(17)

suficientemente grande se tiene que el intervalo de confianza esta dado por (18) el valor del estimador, más o menos un error, que depende del porcentaje de seguridad deseado, es decir, se tiene

se encuentre en el siguiente

(18)


unitaria, se refleja en un valor de 96.12/1 =−αz , por lo


ás de kS47.4 es menor al 5%. Si en cambio se toma el mismo intervalo de confianza de confianza obtenido de (18), se obtiene un

guridad del 26.03%. Por lo cual, se puede concluir que esta cota es un poco conservadora , el cual establece que ésta probabilidad es

21

2.3.3.3. Prueba de Kolmogorov-Smirnov para datos continuos

Las pruebas de bondad y ajuste permiten dar validez a los modelos de simulación, ya que son útiles para evaluar formalmente si una distribución de probabilidad supuesta es congruente o no con un conjunto de datos dado. Para lo cual, es necesario establecer una hipótesis nula H0 siendo el resultado de la prueba es un valor binario h que representa, “h=1” si la prueba rechaza la hipótesis nula y “h=0” si la prueba falla en rechazar la hipótesis nula, lo cual implica que no se debe interpretar H0 como una hipótesis verdadera.

La prueba de Kolmogorov-Smirnov [12] y [13] permite comparar la función de distribución empírica ( )xFe con la función de distribución supuesta ( )xF por medio de la hipótesis nula H0, donde:

• ( )xF es una función de distribución continua dada, para la cual se realiza la suposición de que

todas las k variables aleatorias independientes kYYY ,...,, 21 tienen en común la función de

distribución ( )xF .

• ( )xFe es la función de distribución empírica, y representa la proporción de los valores observados que son menores o iguales a x, como se muestra en la siguiente ecuación.

( )n

xYixF i

e

≤=

:# (19)

La comparación entre ( )xF y ( )xFe se realiza a través de un parámetro D llamado estadístico de prueba,

el cual representa la mayor diferencia (distancia vertical) entre las funciones ( )xF y ( )xFe para todos los posibles valores de x, como se puede observar en la Figura 13.

Figura 13. Significado del parámetro estadístico de la prueba de Kolmogorov – Smirnov.


Teniendo en cuenta (19), para calcular el valor D de un conjunto de datos njyY jj ,...,1, == , y sean ( )jy

los valores de jy ordenados de manera ascendente, se tiene que:

22

( ) ( )( ) ( ){ } ( ) ( ){ }{ }

( )( ) ( )( ) ( )

{ }−+=

=

−−−=

−−=

−=

DDMáximo

kjk

jyFyF

k

jMáximo

xFxFMáximoxFxFMáximoMáximo

xFxFMáximoD

jj

ex

ex

ex

,

,...,1,1

,

,

(20)

Entiéndase de la Figura 13 que +D hace referencia al máximo valor entre ( ) ( )xFxFe − , mientras que −D

es el máximo valor entre ( ) ( )xFxF e− . En este caso, se concluye que += DD . Claramente, un valor grande para D significa un ajuste bastante pobre, por lo tanto, la prueba se basa en rechazar H0 si D excede una

constante α−1,nd , donde α significa el nivel de confianza de la prueba. El valor numérico del punto crítico

α−1,nd depende de la forma en que la función de distribución supuesta ( )xF fue especificada. La

ecuaciones (21) y (22) definen α−1,nd para una función de distribución normal ( )2, SXN y exponencial

( )Xexp , respectivamente. Algunas aplicaciones adicionales se encuentran en [12] y [15].

nn

cdn 85.0

01.0

11,

+−= −

−α

α (21)

( )( )5.026.0

5.026.02.031

1,++

+++= −

−nnn

nnncdn

αα (22)

Donde α−1c se obtiene de la Tabla 1, según [12].

Tabla 1: Valores para α−1c

1 – α

0.850 0.900 0.950 0.975 0.990

( )SXN , 0.775 0.819 0.895 0.955 1.035

( )Xexp 0.926 0.990 1.094 1.190 1.308

Por último, la probabilidad de que el valor D sea menor a α−1,nd es de (1-α) como se muestra en la

ecuación (23).

( ) ( )αα −=≤ − 11,nn dDP (23)

3. ESPECIFICACIONES

3.1. Descripción General y Diagrama en Bloques

El proyecto consiste en analizar el desempeño de una celda celular GSM M/M/n/n, cuyo modelo es implementado en una herramienta de simulación por eventos discretosobjetivo es determinar la probabilidad de bloqueo, la cual da un estimado del número de llamadas que no logran entrar al sistema, debido a que éste está ocupado. El parámetro anterior se evaluará considerando tres tipos de usuarios, diferente número

El modelo que se va a describir busca representar el tráfico de voz existente en la interfaz de celda GSM, siendo ésta el enlace entre el MS y el BTS, en donde se considerará la comunicación en dirección uplink, (del MS al BTS). De tal forma, la celda que se analiza incluye un único BTS y varios MS como se muestra en la Figura cuando se presenta una petición de simulación para el modelo planteado, donde se detallan cuales se explican a continuación:

• Las llamadas obedecen a diferentes tasas de arribo, las cuales pueden ser de tres tipos: Llamadas que han sido originadas en la celda y que corresponden bien sea, al usuario cuya tasa de arribo es λusuario cuya tasa de arribo es λotros. Llamadas provenientes de es λ3.

• La duración de las llamadas obedecen a diferentes tasastipos: µ1, µ2, y µ3, cada una de las cuales hace referencia a las llamadas realizadas por los usuarios cuyas tasas de arribo son λ

23

Descripción General y Diagrama en Bloques

El proyecto consiste en analizar el desempeño de una celda celular GSM a través de un sistema de espera implementado en una herramienta de simulación por eventos discretos

objetivo es determinar la probabilidad de bloqueo, la cual da un estimado del número de llamadas que no logran entrar al sistema, debido a que éste está ocupado. El parámetro anterior se evaluará considerando tres tipos de usuarios, diferente número de canales y bajo tres escenarios de análisis.

Figura 14. Esquema de la celda a analizar


El modelo que se va a describir busca representar el tráfico de voz existente en la interfaz de celda GSM, siendo ésta el enlace entre el MS y el BTS, en donde se considerará la comunicación en

(del MS al BTS). De tal forma, la celda que se analiza incluye un único BTS y varios MS Figura 14; teniendo dos tipos de salidas del sistema: Cuando una llamada termina y

cuando se presenta una petición de handover para salir de la celda. La Figura simulación para el modelo planteado, donde se detallan las condiciones de tráfico de voz heterogéneocuales se explican a continuación:

Las llamadas obedecen a diferentes tasas de arribo, las cuales pueden ser de tres tipos: Llamadas que han sido originadas en la celda y que corresponden bien sea, al usuario cuya tasa de arribo es λ

ya tasa de arribo es λ2, es decir se tienen subscriptores que llaman con mayor frecuencia que otros. Llamadas provenientes de handover, en dado caso corresponden a

La duración de las llamadas obedecen a diferentes tasas de servicio, las cuales pueden ser de tres , cada una de las cuales hace referencia a las llamadas realizadas por los usuarios

cuyas tasas de arribo son λ1, λ2 y λ3, respectivamente.

a través de un sistema de espera implementado en una herramienta de simulación por eventos discretos. El

objetivo es determinar la probabilidad de bloqueo, la cual da un estimado del número de llamadas que no logran entrar al sistema, debido a que éste está ocupado. El parámetro anterior se evaluará considerando

de canales y bajo tres escenarios de análisis.

El modelo que se va a describir busca representar el tráfico de voz existente en la interfaz de aire de una celda GSM, siendo ésta el enlace entre el MS y el BTS, en donde se considerará la comunicación en

(del MS al BTS). De tal forma, la celda que se analiza incluye un único BTS y varios MS ; teniendo dos tipos de salidas del sistema: Cuando una llamada termina y

Figura 15 muestra el escenario de las condiciones de tráfico de voz heterogéneo, las

Las llamadas obedecen a diferentes tasas de arribo, las cuales pueden ser de tres tipos: Llamadas que han sido originadas en la celda y que corresponden bien sea, al usuario cuya tasa de arribo es λ1 o, al

, es decir se tienen subscriptores que llaman con mayor frecuencia que usuarios cuya tasa de arribo

de servicio, las cuales pueden ser de tres , cada una de las cuales hace referencia a las llamadas realizadas por los usuarios

Figura

Lo anterior se puede relacionar con el tipo de plan que se ha fijado con el operador de servicios, pues si un usuario tiene mayor disponibilidad de minutos, es probable que la duración de sus llamadas sea mayor.

Razón por la cual, se ha establecido que las

pospago, prepago y de handover,

correspondiente a cada una de ellos.

Para la implementación del modelo de simulación como un sistema de espera M/M/n/n en OMNeT++ 4.0, es necesario tener presente sus diferentes archivos, extensiones, funciones y características que fueron mencionadas en la sección 2.3.2observa que la unidad principal, el Sistema, contiene cuatro módulos que permiten su funcionamiento, éstos son: Fuente, Switch, Servidor y Sumidero. Cada uno de los cuales consta demismos nombres pero con extensiones diferentes (4.1.

En cuanto a las especificaciones de software, laIntel® Core ™ 2 Duo E4600 @ 2.40GHz, 2GB de RAM, sistema operativo Microsoft Windows XP Professional Version 2002 Service Pack 3, propiedad de la Pontificia Universidad Javeriana (76460 – 0850537 – 23251).

MS

MS MS

MS

MS MS

MS

MS MS

24

Figura 15. Descripción de entradas y salidas en el modelo de la celda

Fuente: Presentación propia de los autores.


Razón por la cual, se ha establecido que las tasas de arribo 21 , λλ y 3λ

handover, respectivamente; siendo las tasas de servicio de ellos.

Para la implementación del modelo de simulación como un sistema de espera M/M/n/n en OMNeT++ 4.0, es necesario tener presente sus diferentes archivos, extensiones, funciones y características que fueron

2.3.2. La estructura general del modelo se muestra en la observa que la unidad principal, el Sistema, contiene cuatro módulos que permiten su funcionamiento, éstos son: Fuente, Switch, Servidor y Sumidero. Cada uno de los cuales consta demismos nombres pero con extensiones diferentes (.ned, .cc y .h), los cuales serán descritos en la sección

Figura 16. Estructura del modelo


En cuanto a las especificaciones de software, la simulación es llevada a cabo en un computador Lenovo, Intel® Core ™ 2 Duo E4600 @ 2.40GHz, 2GB de RAM, sistema operativo Microsoft Windows XP Professional Version 2002 Service Pack 3, propiedad de la Pontificia Universidad Javeriana (76460

MS

MS

MS

1

2

3

4

n

n servidores con tasas

de servicio

Llamadas con tasa de

arribo 1λ

...

Llamadas con tasa de

arribo 2λ

Llamadas provenientes

de handover Peticiones de

para salir de la celda

Llamadas terminadas

321 ó , µµµ

)( 3λ

de entradas y salidas en el modelo de la celda


hacen referencia a usuarios

respectivamente; siendo las tasas de servicio 21 , µµ y 3µ la duración

Para la implementación del modelo de simulación como un sistema de espera M/M/n/n en OMNeT++ 4.0, es necesario tener presente sus diferentes archivos, extensiones, funciones y características que fueron

La estructura general del modelo se muestra en la Figura 16, donde se observa que la unidad principal, el Sistema, contiene cuatro módulos que permiten su funcionamiento, éstos son: Fuente, Switch, Servidor y Sumidero. Cada uno de los cuales consta de tres archivos con los

), los cuales serán descritos en la sección

simulación es llevada a cabo en un computador Lenovo, Intel® Core ™ 2 Duo E4600 @ 2.40GHz, 2GB de RAM, sistema operativo Microsoft Windows XP Professional Version 2002 Service Pack 3, propiedad de la Pontificia Universidad Javeriana (76460 – 641

Peticiones de handover

para salir de la celda

Llamadas terminadas

25

4. DESARROLLO

El proceso llevado a cabo para la implementación y la validación del modelo de simulación como un sistema de espera M/M/n/n que representa una celda celular GSM, está constituido por varias etapas que buscan escalar en niveles de complejidad hasta llegar al objetivo, verificando los resultados de los valores esperados de las variables del sistema11, cuyas fórmulas son encontradas en [10]. La primera etapa se basa en la implementación de los sistemas de espera más simples como son el M/M/1 y el M/M/n a través de modelos de simulación, cuyo código se encuentra en el Anexo 8.2. Lo anterior, no sólo se hizo para obtener una mayor comprensión de la teoría sino también para adquirir un mejor dominio de la herramienta de simulación. La segunda etapa está fundamentada en la implementación y desarrollo del sistema de espera M/M/n/n, con ayuda de los modelos ya expuestos; el código completo se presenta en el Anexo 8.3. Para culminar esta fase, la tercera etapa incluye la validación del modelo de interés, en la cual la ejecución de la simulación es realizada para un tráfico de voz homogéneo, en donde algunos parámetros son resultados proporcionados por el análisis del sistema de espera M/M/1/1.

4.1. Implementación del modelo de simulación

En esta sección se exponen cada uno de los módulos mostrados en la Figura 16, teniendo en cuenta dos tipos de usuario para facilitar la comprensión del modelo.

4.1.1. Fuente

Es el bloque encargado de generar de manera aleatoria las llamadas que ingresan al sistema, de tal forma, que éstas representan un proceso de tipo Poisson. Sin embargo, como se quiere modelar un tráfico de voz heterogéneo, es necesario utilizar diferentes tasas de arribo, cada una de las cuales simboliza a un usuario de telefonía móvil con un plan de voz que indica la frecuencia con la que ingresa al sistema. El algoritmo para llevar a cabo esta función esta soportado en los archivos Fuente.h y Fuente.cc.

4.1.1.1. Fuente.h

Definición de variables:

• ControlTiempoDeArribo: Auto-mensaje que controla la tasa de arribo de las llamadas. • Llamada: Mensaje que representa la llamada que será analizada.

Definición de funciones:

• Inicialización: Creación e inicio de variables. • Constructor: Se crea un espacio de memoria para almacenar el auto-mensaje

ControlTiempoDeArribo. • Handle Message: Establece qué hacer cuando llegue el auto-mensaje

ControlTiempoDeArribo con una tasa de arribo en particular. • Destructor: Se elimina el espacio de memoria del auto-mensaje ControlTiempoDeArribo

con la función cancelAndDelete( ).

11 Tiempo de espera, tiempo de servicio, tiempo total en el sistema, número de entidades esperando, número de entidades en servicio, número total de entidades en el sistema

26

4.1.1.2. Fuente.cc

Este archivo tiene la estructura mostrada en la Figura 11 en donde la inicialización y el Handle Message se muestran en la Figura 17 y Figura 18, respectivamente.

Figura 17. Función Inicialización del Bloque Fuente


Figura 18. Función Handle Message del Bloque Fuente


27

4.1.2. Switch

Una vez recibida la llamada que ha sido generada por la fuente, el switch se encarga de direccionar la llamada a uno de los servidores que se encuentre disponible, situación que se implementa con la ayuda de un “vector binario” el cual representa el estado de los mismos. Éste contenedor se actualiza cada vez que algún servidor recibe la llamada o cuando ésta es enviada al sumidero. En caso de no ser posible enviar la llamada a un servidor, el switch la elimina, y de ésta forma, se puede cuantificar la probabilidad de bloqueo.

4.1.2.1. Switch.h


• tamVector: Almacena el número de servidores que tiene el sistema. • NumeroDeServidor: Representa al servidor que está libre. • Bandera: Indica cuando se ha encontrado un servidor libre. • Entidades Bloqueadas: Variable que cuenta las llamadas que no pueden ser atendidas • Entidades Totales: Variable que cuenta las llamadas bloqueadas y atendidas • NumTTotal: Numerador de la variable que representa el número promedio de las

entidades en el sistema • contEntidades: Variable que cuenta el número total de entidades en el sistema • QuienEnvia: Almacena el modulo del servidor que envía el mensaje de aviso de

disponibilidad. • Bitset Servidores: Es un contenedor especial que almacena bits, los cuales representan el

estado de los servidores, de la siguiente forma: Uno, servidor libre; cero, servidor ocupado.

• tAnterior: Variable que almacena el tiempo en el que llegó el penúltimo mensaje • tActual: Variable que almacena el tiempo en el que llegó el último mensaje


• Inicialización: Lectura e inicio de variables • Handle Message: Establece qué hacer cuando llegue el mensaje que representa la llamada

enviada por la fuente, ó, el aviso de disponibilidad por parte del servidor. • Finalización: Función que es llamada al final de cada corrida para que sean calculados la

probabilidad de bloqueo y el promedio del número de entidades totales en el sistema.

4.1.2.2. Switch.cc

Las funciones de Inicialización, Handle Message y Finish de este bloque se muestran respectivamente en las Figura 19, Figura 20 y Figura 21.

Figura 19. Función Inicialización del Bloque Switch


28

Figura 20. Función Handle Message del Bloque Switch


Figura 21. Función Finish del Bloque Switch


4.1.3. Servidor

Un servidor está encargado de atender a una llamada a la vez, generándole una tasa de servicio diferente según la tasa de arribo con la cual la llamada ha sido generada. Para aclarar éste concepto vale la pena recalcar que un usuario cuyo plan de voz es prepago tendrá una duración de llamada menor que un usuario pospago.

Este bloque puede ser instanciado tantas veces como número de servidores se deseen, lo cual se hace creando un vector de compuertas, cuyo tamaño es precisamente el número de servidores. Dicho vector se llama Puerto[ ], es declarado en el archivo Switch.ned, y se encuentra explicado en la Figura 27.

29

4.1.3.1. Servidor.h


• ControlTiempoDeServicio: Auto-mensaje que controla el tiempo de servicio, es decir, la duración de la llamada.

• LlamadaEnServicio: Mensaje que representa la llamada que está en cada servidor. • Aviso: Mensaje que indica la disponibilidad de cada servidor • contadorServidor: Contiene el número total de entidades que han sido atendidas por cada

servidor • NumTServicio: Contiene el numerador de la variable que representa el número promedio

de entidades en servicio • TiempoTotal: Almacena el tiempo total que dura una entidad en el sistema. • tTotal: Vector estadístico que almacena los diferentes valores que toma la variable

TiempoTotal • TiempoServicio: Almacena el tiempo de servicio de una entidad en el sistema. • tServicio: Vector estadístico que almacena los diferentes valores que toma la variable

TiempoServicio


• Inicialización: Creación e inicio de variables • Constructor: Se crea un espacio de memoria para almacenar el auto-mensaje

ControlTiempoDeServicio y los mensajes Aviso y LlamadaEnServicio. • Handle Message: Establece qué hacer cuando llegue el mensaje que representa la llamada

enviada por la fuente, ó, el auto-mensaje ControlTiempoDeServicio. • Finalización: Función que es llamada al final de cada corrida para que sean calculados el

promedio del tiempo total que tarda una entidad en el sistema, el promedio del tiempo de servicio de una entidad y el promedio del número de entidades en servicio.

• Destructor: Se elimina el espacio de memoria del auto-mensaje ControlTiempoDeSevicio con la función cancelAndDelete( ). Si el contenido de LlamadaEnServicio no es nulo se debe borrar.

4.1.3.2. Servidor.cc

Las funciones de Inicializacion, Handle Message y Finish de este bloque se muestran en la Figura 22, Figura 23 y Figura 24 respectivamente.

Figura 22. Función Inicialización del Bloque Servidor


30

Figura 23. Función Handle Message del Bloque Servidor


Figura 24. Función Finish del Bloque Servidor


4.1.4. Sumidero

Este bloque permite que se eliminen las llamadas que han sido procesadas, llevando un conteo de las mismas, con lo cual se controla en qué momento debe detenerse una corrida.

4.1.4.1. Sumidero.h


• Entidades procesadas: Contiene el número total de llamadas procesadas por el sistema.


• Inicialización: Inicio de variables • Handle Message: Establece qué hacer cuando llegue de algún servidor el mensaje que

representa la llamada.

31

4.1.4.2. Sumidero.cc

Las funciones de Inicialización y Handle Message de este bloque se muestran en la Figura 25 y Figura 26, respectivamente.

Figura 25. Función Inicialización del Bloque Sumidero


Figura 26. Función Handle Message del Bloque Sumidero


Una vez aclarado el contenido de los archivos .cc y .h, se finaliza con la definición de las estructuras y las compuertas incluidas en los archivos .ned, los cuales se encuentran detallados en la Figura 27.

4.2. Protocolo de comunicación

El protocolo de comunicación entre los bloques se presenta a través de la Figura 28, la cual muestra al costado izquierdo cada uno de los bloques que se encuentran involucrados en el proceso. Tanto los mensajes que entran como los mensajes que salen de los bloques, se simbolizan como flechas y representan, cada uno de ellos, un evento que se incrementa cronológicamente. Por lo tanto, el intercambio constante de mensajes, es el medio que permite la comunicación entre los bloques.

Para una mayor comprensión a continuación se narran los sucesos que ocurren en algunos eventos:

0. Se genera el auto-mensaje Control Tiempo De Arribo en la fuente. 1. La fuente recibe el auto-mensaje Control Tiempo De Arribo, lo cual indica que éste bloque debe

enviar al switch la Llamada. 2. Se genera un nuevo auto-mensaje Control Tiempo De Arribo en la fuente. 3. El switch recibe la Llamada proveniente de la fuente y de manera aleatoria escoge el servidor que

atenderá la Llamada, siempre y cuando éste se encuentre disponible; en este caso se escogió al Servidor[1].

4. El Servidor[1] recibe la Llamada y éste a su vez genera el tiempo de servicio de la misma, enviando el auto-mensaje Control Tiempo De Servicio.

32

5. El Servidor[1] recibe el auto-mensaje Control Tiempo de Servicio, indicando que se ha terminado de atender la Llamada, por lo cual ésta es enviada al sumidero y adicionalmente se le envía al switch el mensaje Aviso de disponibilidad, indicándole que éste servidor ha quedado libre.

6. El sumidero recibe la Llamada a ser eliminada. 7. El switch recibe el mensaje de Aviso de disponibilidad, que le permite actualizar el contenedor

que representa el estado de los servidores.

A partir del evento 7, se repite el mismo algoritmo de comunicación a pesar de que el estado de los servidores no siempre es igual. Por ejemplo, en la Figura 28 se observa como las llamadas que llegan al switch en los eventos 14 y 16 son descartadas debido a que los dos servidores se encuentran ocupados.

Figura 27. Descripción de los archivos .ned


Fuente.ned

Descripción de la estructura

• Definición de parámetros:

Tasas de arribo: Como variables cuyos valores son asignados en el

archivo omnetpp.ini

• Definición de compuertas:

Out: Compuerta de salida que está conectada a la compuerta In del

switch.

Switch.ned



tamVector: Variable que guarda el número de servidores, su valor es

asignado en sistema.ned


In: Compuerta de entrada que está conectada a la compuerta Out de

la fuente.

Puerto[ ]: Conjunto de compuertas de entrada y de salida que están

conectadas a la compuertas Puerto de cada uno de los servidores

Servidor.ned



Tasas de Servicio: Como variables cuyos valores son asignados en

el archivo omnetpp.ini


Puerto: Compuerta de entrada y de salida que está conectada de

cada servidor a las compuertas Puerto[ ] del Switch.

Out: Compuerta de salida que está conectada de cada servidor a la

compuerta In del sumidero.

Sumidero.ned



tamVector: Variable que guarda el número de servidores, su valor es

asignado en sistema.ned


In: Compuerta de entrada que está conectada a la compuerta Out

del servidor.

33

Figura 28. Protocolo de comunicación


De Arribo

Control

34

4.3. Configuración

Una vez se halla implementado el modelo de simulación como se describió anteriormente, es necesario realizar tanto la configuración de las variables requeridas para la simulación, como la asignación de los parámetros del modelo. Éste proceso se lleva a cabo en un archivo llamado omnetpp.ini, el cual se encuentra dividido en secciones, llamadas “Experimentos”, que llevan consigo una breve descripción, como se muestra en la Figura 29.

Figura 29. Experimentos en omnetpp.ini


La asignación de parámetros se puede realizar de manera independiente para cada uno de los experimentos, lo cual permite manejar diferentes escenarios de una forma más clara y ordenada. Dicha asignación se lleva a cabo especificando tanto el modulo donde se desea apuntar como la variable que se desea modificar, de una forma muy parecida al manejo de apuntadores.

Figura 30. Parámetros en omentpp.ini


35

A manera de ejemplo, la Figura 30 detalla los parámetros que han sido asignados para el experimento MMnn_F. Ésta asignación indica que el número de servidores con los cuales se va a trabajar es cinco, y que tanto el tiempo entre arribos como la duración de las llamadas son generados siguiendo una distribución probabilística de tipo exponencial cuyo parámetro esta dado en segundos y corresponde al inverso de λ1, λ2, µ1 y µ2.

La configuración de la simulación se puede realizar en la pestaña Configuration de la parte superior izquierda de la Figura 30. Sin embargo, debido a la extensa cantidad de opciones que se pueden modificar, a continuación se realiza una breve descripción de las opciones de configuración más relevantes.

• Repeat, establece el número de corridas que se deben hacer con los mismos parámetros (λ y µ) para la simulación. Este valor se encuentra disponible como ${repetition} y hace referencia al contador del ciclo en la simulación.

• Seed-Set, selecciona el k-ésimo conjunto de semillas para la simulación. Como en cada corrida se utiliza una semilla diferente, se puede asignar el valor ${repetition} para la selección de cada una de ellas.

• Output-Scalar-File, especifica la ruta, el nombre, y la extensión con la cual deben ser almacenados los archivos de tipo escalar. El valor predeterminado es ${resultdir}/${configname}-${runnumber}.sca

Una extensa lista de las opciones de configuración disponibles para los archivos .ini se puede encontrar en el apéndice G “Configuration Options” en [14].

4.4. M/M/1/1

El estudio del sistema de espera M/M/1/1, tiene como objetivo evaluar tanto el número de entidades que deben ser procesadas para obtener convergencia en los resultados del sistema, como el número de corridas necesarias para que los resultados sean confiables como se menciono en la sección 2.3.3.2.

En primer lugar, se llevo a cabo una simulación con cinco corridas, cada una de ellas con diferente semilla y para un máximo de 500000 llamadas procesadas, las cuales equivalen a 450000s en tiempo de simulación. Adicionalmente, se tomó una carga de tráfico ρ = 0.8 debido a que los sistemas actuales de telefonía móvil normalmente trabajan con cargas de tráfico inferiores a este valor, el cual puede resultar de una tasa de arribo λ = 2s y una tasa de servicio µ = 2.5s.

Para evaluar el número de entidades procesadas necesarias, se analizó el comportamiento del promedio acumulado de la probabilidad de bloqueo (mostrado en la Figura 31) para el sistema de espera planteado. Adicionalmente, el número de entidades totales y el tiempo total de una entidad en el sistema fueron graficados y se muestran en el Anexo 8.4.

Una vez obtenidas las gráficas, se observa que la respuesta en el tiempo de los parámetros del sistema es inestable hasta cierto punto, este comportamiento se denomina transitorio y se encuentra presente en toda simulación, allí nunca deben ser analizados los datos; por el contrario, éstos se deben tomar en un punto en el que la variabilidad de los resultados sea mínima para garantizar la convergencia de los mismos.

36

Figura 31. Promedio acumulado de la Probabilidad de bloqueo para 500000 llamadas procesadas


En la gráfica de la Figura 31, la respuesta en tiempo comienza a ser estable y por lo tanto converge a un valor alrededor de los 270000s, sin embargo, éste punto se encuentra en el límite y no es conveniente tomarlo como referencia, pues es deseable que la respuesta se encuentre contenida en un rango, definido como 1x10-3, lo cual se satisface cerca de los 360000s, valor que de ahora en adelante se tomará como una constante en todas las simulaciones y que corresponde a 400000 llamadas procesadas por servidor. Esto permite que el tiempo que tarda en completarse una corrida sea disminuido en un 20%.

En segundo lugar, para evaluar del número de corridas necesarias, se exportan a Matlab los resultados de la probabilidad de bloqueo entregados por OMNet++ 4.0 para 150 corridas. En donde se utiliza el código del Anexo 8.5 para calcular y graficar el promedio de este parámetro de manera sucesiva; este cálculo es llevado a cabo como se muestra en la ecuación (24), tomada de [13].

01

01

1 =+−

+= ++ X

j

XXXX

jj

jj

(24) Donde: Xj es el resultado de la probabilidad de bloqueo para la corrida j.

jX es el promedio acumulado de la probabilidad de bloqueo hasta la corrida j. y es el índice que representa el número de la corrida y se encuentra en el rango de 0 a 149.

La gráfica obtenida se muestra en la Figura 32 y se observa que los datos se empiezan a estabilizar alrededor de k=50 corridas, donde es importante mencionar que se tiene una resolución en la escala de 1x10-4, sin embargo, para asegurar que los resultados converjan a un valor se tomará como constante para todas las simulaciones el valor de k=100 corridas. También se ha seleccionado el valor de k=100, para garantizar que éste sea lo suficientemente grande, y así, poder demostrar que se satisface el Teorema del Límite Central expuesto en la sección 2.3.3.2.

x 1030 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360 380 400 420 440

0.465

0.460

0.455

0.450

0.445

0.440

0.435

0.430

0.425

0.420

0.415

0.410

0.465

0.460

0.455

0.450

0.445

0.440

0.435

0.430

0.425

0.420

0.415

0.410

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360 380 400 420 440 x 103

Número

de Corrida

1

2

3

4

5

37

Figura 32. Promedio acumulado de la probabilidad de bloqueo para 150 corridas


Al realizar el histograma de los 100 valores de la probabilidad de bloqueo se obtiene la Figura 33, en donde se observa una similitud con la gráfica de densidad de probabilidad de la distribución normal. Así que se quiere demostrar que no hay suficiente evidencia como para rechazar la hipótesis de que los

resultados obtenidos para la probabilidad de bloqueo provienen de una distribución normal con media X y desviación S.

Figura 33. Histograma de los valores de la probabilidad de bloqueo para 100 corridas


La suposición anterior es la hipótesis nula de la prueba de bondad y ajuste de Kolmogorov-Smirnov (Ver

Sección 2.3.3.3), en donde se quiere comparar las variables aleatorias obtenidas 10021 ,...,, YYY con un

distribución normal con media 44439554.0=X y desviación estándar 4102506967.6 −×=S . Valores que fueron obtenidos con el conjunto de ecuaciones (10) y (11) descritas en la sección 2.3.3.1 y cuyo código se

0.443 0.4435 0.444 0.4445 0.445 0.4455 0.4460

100

200

300

400

500

600

Histograma de la Probabilidad de BloqueoDistribución Normal Ajustada

38

encuentra en el anexo 8.6. Este código, también incluye la prueba que se ha llevado a cabo a través de la función kstest de Matlab, la cual compara las funciones de distribución empírica y supuesta, arrojando los siguientes resultados:

• h=0

• p=0.987886

• D=0.0433240

Los cuales indican que la hipótesis nula no ha sido rechazada y que se tiene un 98.79% de certeza de que

la máxima diferencia entre las funciones ( )xF y ( )xFe sea de 0.0433240 para un conjunto de 100 datos que se distribuye normal con los parámetros mencionados. En la Figura 34 se muestran las funciones de distribución, donde se puede observar de manera gráfica que la aproximación es bastante buena.

Figura 34. Comparación de la función de distribución empírica y la función de distribución supuesta


Una vez se ha establecido el valor de k y se ha demostrado que no se rechaza la hipótesis de que la probabilidad de bloqueo obedece a una distribución normal, se puede afirmar que por las propiedades de la normal se cumple el Teorema del Límite Central, descrito en la ecuación (16), razón por la cual es posible evaluar el intervalo de confianza a través del método descrito en la sección 2.3.3.2.

Entonces, teniendo en cuenta que se desea garantizar un porcentaje de seguridad del 99% de que la media poblacional se encuentra en dicho intervalo, se sabe que 99.01 =−α luego 01.0=α , valor que se refleja en las tablas de la distribución normal estándar y considerando su simetría se obtiene que 57,2

21

=−αz , por

lo tanto el intervalo de confianza es [0.444135, 0.444456], que resultó de evaluar la ecuación (18):

( )

4

4

21

106064.144429554.0

100

102506967.657.244429554.0

−

−

−

×±=

×±=±k

SzX α

39

4.5. Validación

La validación del modelo expuesto en la sección 3.1 es llevada a cabo mediante la simulación de un sistema de espera M/M/n/n con tráfico homogéneo, la cual se realizó según las condiciones de convergencia para una corrida y de cierto número de repeticiones por simulación explicados en 4.4. Por lo tanto, es de esperarse, que en una corrida cada uno de los servidores procese alrededor de 400000 eventos para que los resultados obtenidos converjan a un valor. Una vez terminada dicha corrida, ésta debe ser repetida 100 veces, cada una de ellas con diferente semilla.

Para cada una de las simulaciones se varían los parámetros de entrada, específicamente, la carga de tráfico ofrecida ρ en el intervalo [0, 1]. Para ello, las tasas de servicio µ1, µ2 y µ3 permanecen constantes en un valor de 2.5 (µ1 = µ2 = µ3 = 2.5) y se ajustan las tasas de arribo λ1, λ2 y λ3 a un mismo valor (λ1 = λ2 = λ3 = variable), de tal forma que la probabilidad de bloqueo se encuentre en el intervalo [0, 0.3]. Los intervalos fueron escogidos para que se ajusten a los parámetros actuales de una celda celular.

En la Figura 35, se presenta un diagrama en bloques cuya secuencia ejemplifica el proceso que OMNeT++ 4.0 lleva a cabo para realizar una simulación. Algunos parámetros de la simulación como el número de repeticiones y el conjunto de semillas se definen en el archivo omnetpp.ini como se mencionó en la sección 4.3.

Figura 35: Diagrama de flujo para llevar a cabo una simulación.


No Si

Corrida

Inicio

Omnet.ini

Repeat=100

Se genera el archivo MMnn_X-R.sca

� Cambiar semilla• Incrementar Repeat en uno

Fin de la simulación

40

Por lo tanto, una simulación comprende 100 corridas, cada una de ellas con un conjunto diferente de semillas pero con los mismos parámetros de entrada tanto para la tasas de servicio µ1, µ2 y µ3 como para las tasas de arribo λ1, λ2 y λ3.

Los resultados obtenidos en cada corrida corresponden a tres parámetros de interés de un sistema M/M/n/n: el número de entidades totales en el sistema, el tiempo promedio que permanece una entidad en el sistema y la probabilidad de bloqueo. Estos resultados fueron almacenados por medio de la función recordScalar( ) en archivos que contienen los valores obtenidos en cada una de las corridas y cuyo nombre tienen el formato MMnn_X-R.sca, donde la letra R, hace referencia a una corrida específica y se encuentra en el intervalo [0, 99]; y la letra X, significa el experimento que se ha seleccionado para la simulación.

Para poder manipular los archivos .sca y cualquier otra información almacenada en vectores e histogramas, es necesario crear un archivo con la extensión .anf. Allí, al seleccionar la pestaña Scalars y aplicar el filtro deseado se obtiene toda la información con respecto a los resultados de la simulación, que en este caso corresponden a escalares. La Figura 36, muestra algunos detalles acerca de cada una de las corridas, tales como:

• Run Id, el cual determina la fecha y hora en que se realizó la corrida.

• Module, es el que especifica el módulo que ha generado los resultados.

• File Name y Config Name, confirman tanto el nombre de los archivos como el experimento que se ha llevado a cabo.

• Value, muestra el resultado que se ha obtenido en cada una de las corridas.

Figura 36: Interfaz grafica del archivo .anf


41

Una vez terminada una simulación, se deben almacenar los datos obtenidos de los tres parámetros de interés mencionados anteriormente para cada una de las 100 corridas, por lo tanto, desde el archivo .anf, los resultados son exportados a Excel como se muestra en la Figura 37.

Figura 37: Diagrama de flujo para exportar los resultados de una simulación.


Se llevaron a cabo 14 simulaciones, en donde la carga de tráfico ρ en cada una de ellas es diferente, de tal forma, que se obtengan los resultados deseados para la probabilidad de bloqueo como se muestra en la Tabla 2.

Tabla 2: Equivalencias entre la simulación i con la probabilidad de bloqueo

Simulación 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Probabilidad de Bloqueo

0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.1 0.15 0.2 0.25 0.3

Sin embargo, es necesario obtener un estimador de la probabilidad de bloqueo como el valor esperado de los cien resultados correspondientes a una simulación, para lo cual, se utilizó la ecuación (10) junto con la herramienta de programación Matlab. Este procedimiento se repite para cada una de las 14 simulaciones, recopilando toda la información en el archivo llamado GraficasValidacion.xls, el cual se encuentra en el Anexo 8.7.1. Todo el proceso anterior se denomina “Realización” y se detalla en la Figura 38.

Crear en Omnet el archivo MMnn.anf

Exportar los resultados a Excel con los siguientes nombres:

•MMnn_TiempoTotal-1.csv•MMnn_EntidadesTotales-1.csv

•MMnn_ProbabilidadDeBloqueo-1.csv

Simulación

Inicio

Fin

Modificar las tasas de arribo, según la probabilidad de bloqueo deseada

No

Si

La simulación 14 ya fue procesada

42

Figura 38: Diagrama de flujo para llevar a cabo una realización


Se llevaron a cabo 9 realizaciones diferentes, cada una de ellas hace referencia a un experimento MMnn_X que representa un número específico de servidores, tal y como se muestra en la Tabla 3.

Tabla 3: Equivalencias entre un experimento MMnn_X con el número de servidores.

Experimento ( X ) B C D E F G H I J

Número de servidores

1 2 3 4 5 10 20 30 40

A manera de ejemplo, se invita al lector a detallar la Figura 36, donde se pueden observar los resultados obtenidos para la “probabilidad de bloqueo” de las primeras “21 corridas” de la “simulación 10” del experimento “MMnn_F”.

En el Anexo 8.7.2 se encuentran las tablas que incluyen tanto los parámetros como los resultados de la validación del sistema de espera M/M/n/n, allí se recopila la información más relevante del archivo GraficasValidacion.xls. En las tablas se pueden detallar las tasas de arribo que fueron utilizadas en las catorce simulaciones, para cada una de las nueve realizaciones, y por lo tanto, la correspondiente carga de tráfico ofrecida por servidor (ρ) y del sistema (a). Ésta última es de vital importancia para llevar a cabo la validación del modelo de simulación, ya que permite que se comparen los resultados obtenidos para la probabilidad de bloqueo con el modelo teórico propuesto por Erlang. En el Anexo 8.8 se adjunta la tabla de tráfico de Erlang-B para un máximo de cien servidores y una probabilidad de bloqueo hasta de un 40%.

43

Figura 39: Probabilidad de Bloqueo Vs Carga de tráfico del sistema (Eb) para diferente número n de servidores. Escala Logarítmica.


Así mismo, la Figura 39 y Figura 40 muestran respectivamente los resultados obtenidos de la probabilidad de bloqueo tanto para 1, 2, 3, 4 y 5 como para 10, 20, 30 y 40 servidores. Se ha decido separar los resultados en dos graficas debido a que las escalas en el eje horizontal son muy diferentes. Dichas gráficas se ajustan a los valores teóricos expuestos en la Figura 5-2 y la Figura 5-3, encontradas en [16].

Figura 40: Probabilidad de Bloqueo Vs Carga de tráfico del sistema (Eb) para diferente número n de servidores. Escala Logarítmica.


44

De la misma manera, éstas gráficas pueden ser comparadas con la presentación “Traffic Engineering” del profesor Zabih Ghassemlooy12.

Por otro lado, la Figura 41 muestra los resultados obtenidos para 1, 2, 3, 4, 5, 10, 20, 30 y 40 servidores. Si bien la escala lineal no es la más apropiada, éste tipo de gráfica permite que se comparen los valores obtenidos con la Figura 1 del artículo [17].

Figura 41: Probabilidad de Bloqueo Vs Carga de tráfico por servidor (ρ) para diferente número n de servidores. Escala lineal.


Finalmente, tanto la probabilidad de bloqueo teórica como la simulada para un número n de servidores, se grafica por medio del código de Matlab GraficaValidacion.m, mostrado en el Anexo 8.9. La Figura 42 muestra en el eje horizontal la carga de tráfico por servidor (ρ), y en el eje vertical la probabilidad de bloqueo en una escala logarítmica, cuyos valores teóricos se muestran por medio de las líneas continuas, mientras que los valores obtenidos a través del modelo de simulación se muestran como viñetas negras. Se puede observar que existen diferencias entre los valores teóricos y simulados, sin embargo, éstos son casi imperceptibles. Esto se debe a que los valores obtenidos en una simulación son un estimador del parámetro deseado, y es poco probable que dicho estimador sea exactamente el mismo valor teórico.

12 Presentación disponible en la página web: http://soe.unn.ac.uk/ocr/teaching.html.

45

Figura 42: Probabilidad de Bloqueo Vs Carga de tráfico por servidor (ρ) para diferente número n de servidores. Escala logarítmica.


46

5. ANÁLISIS DE RESULTADOS

Para llevar a cabo la simulación del modelo M/M/n/n con tráfico de voz heterogéneo es fundamental determinar las tasas de arribo (λ) y de servicio (µ) de las llamadas, para lo cual se analizaron los datos suministrados por el departamento de desempeño de la red de un operador de telefonía móvil. Esta información corresponde a llamadas que han entrado y salido de una celda en un periodo de 24 horas e incluye:

• La hora de inicio de la llamada

• La duración en segundos de cada una de las llamadas

• El tipo de llamada: Indica si la llamada proviene de un usuario con un plan pospago, prepago, o si bien el origen de la llamada se dio en otra celda, en cuyo caso proviene de handover. Es relevante mencionar que con cada uno de los tipos de llamada se hallaran dos tasas, la de arribo y la de servicio, para un total de seis tasas a ser determinadas.

El análisis inicia con la comprobación de que tanto la duración de las llamadas, como los intervalos de tiempo transcurridos entre los arribos de cada tipo se distribuyen exponencial en un intervalo de tiempo dado; por lo tanto, se evalúa cuál espacio de tres horas en el día presenta mayor cantidad de llamadas, obteniendo como resultado el periodo comprendido entre las 9AM y las 12M con un total de 139 llamadas pospago, 375 prepago y 502 handover. Se aclara que la escogencia de tres horas obedece a que si se toma un valor mayor, es más probable que los datos no respondan a una distribución exponencial debido a la gran diferencia en el número de llamadas que se tienen, dependiendo de la hora del día. Hay que señalar que al tomar el intervalo de tiempo con mayor cantidad de llamadas, se está analizando el caso en el que la celda se encuentra más ocupada, por lo tanto, se estaría contemplando el peor caso para cuantificar la capacidad de la red.

Una vez establecido el rango de las llamadas a analizar, se realizan los histogramas para el tiempo entre arribos y la duración de las llamadas de cada uno de los usuarios, mostrándose los resultados correspondientes a handover en la Figura 43 y en la Figura 44; para pospago y prepago, los histogramas se encuentran en el Anexo 8.10.1. Adicionalmente, se llevaron a cabo para estos datos las pruebas de bondad y ajuste, teniendo como hipótesis nula que los datos obedecen a una distribución exponencial. Los resultados obtenidos con ayuda del código de Matlab encontrado en el Anexo 8.10.2 son:

• Para Pospago: o No se rechaza la hipótesis. Cvλ = 0.1372; Dλ = 0.0544; pλ = 0.7877 ;

Cvµ = 0.1367; Dµ =0.0712; pµ = 0.4598 o Media del tiempo entre arribos: 1/λ1 = 78.1 o Media de la duración de las llamadas: 1/µ 1 =114.9

• Para Prepago:

o No se rechaza la hipótesis. Cvλ = 0.0837; Dλ = 0.0650; pλ = 0.0809 ; Cvµ = 0.0836; Dµ = 0.0547; pµ =0.2048

o Media del tiempo entre arribos: 1/λ2 = 28.2 o Media de la duración de las llamadas: 1/µ 2 = 87.9

• Para Handover:

o No se rechaza la hipótesis. Cvλ = 0.0724; Dλ = 0.0549; pλ = 0.0937 ; o Media del tiempo entre arribos: 1/λ3 = 21.5

47

Figura 43. Histograma del tiempo entre arribos para los usuarios de tipo Handover


o No se rechaza la hipótesis. Cvµ = 0.0723; Dµ = 0.0618; pµ = 0.0414 o Media de la duración de las llamadas: 1/µ 3 = 102.2

Figura 44. Histograma de la duración de las llamadas para los usuarios de tipo Handover


Con estos resultados se procede a determinar el porcentaje de cada uno de los tipos de llamadas pi de la siguiente manera:

%100

313274.121.453094

28.173797

/1

/1

772130.228.173797

78.101449

/1

/1

321

3

2

2

3

2

3

2

1

1

2

1

2

=++

====

====

ppp

p

p

p

p

λλ

λλ

λλ

λλ

(25)

Del conjunto de ecuaciones mostradas anteriormente, se obtiene que el porcentaje de llamadas provenientes de pospago (p1), de prepago (p2) y de handover (p3) es respectivamente 13.49036%, 37.29705% y 49.111258%.

0 50 100 1500

0.005

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.045

Histograma para las llamadas HandoverDistribucion Exponencial Ajustada

0 200 400 600 800 1000 12000

0.001

0.002

0.003

0.004

0.005

0.006

0.007

0.008

0.009

0.01

Histograma para las llamadas HandoverDistribucion Exponencial Ajustada

48

En resumen, con el objetivo de que la gráfica quede distribuida de la mejor manera, se debe llevar a cabo la simulación para diferente número de servidores, por lo tanto, para cada uno de ellos, se requiere conocer un conjunto de 16 valores. A su vez, cada valor consta de: tres tasas de servicio, µ 1 = 0.008705455, µ 2 = 0.011375356 y µ 3 = 0.00978138, las cuales permanecen constantes como se muestra en las columnas G-I de anexo 8.11.1; Tres tasas de arribo que se varían iterativamente basados en un porcentaje (ver Tabla 4) de la diferencia entre un valor máximo y un valor mínimo (ver Tabla 5). Nótese que las relaciones halladas en la ecuación (25) no cambian. De esta manera, los valores mostrados en las columnas J-L del Anexo, junto con las siguientes tres columnas (M-O) son ingresados como parámetros de entrada a la herramienta de simulación, obteniendo la probabilidad de bloqueo indicada en la columna Q.

Tabla 4. Porcentajes utilizados para el cálculo de las tasas de arribo.

Tasa de arribo Porcentaje

Tasa de arribo Porcentaje

Valor 1 0.0%

Valor 9 12.9%

Valor 2 1.4%

Valor 10 15.1%

Valor 3 2.8%

Valor 11 25.4%

Valor 4 4.6%

Valor 12 35.6%

Valor 5 6.3%

Valor 13 49.7%

Valor 6 7.9%

Valor 14 61.8%

Valor 7 9.3%

Valor 15 81.3%

Valor 8 11.3%

Valor 16 100.0%

Tabla 5. Valores mínimos y máximos de cada una de las tasas de arribo para diferente número de servidores

N° de servidoresValores Mínimo Máximo Mínimo Máximo Mínimo Máximo

λ1 0.00003557 0.00241582 0.00053349 0.00736222 0.00160048 0.01280386

λ2 0.00009859 0.00669698 0.00147892 0.02040903 0.00443675 0.03549397

λ3 0.00012948 0.00879497 0.00194222 0.02680266 0.00582667 0.04661332


λ1 0.00304854 0.01920579 0.00492456 0.02560772 0.01664502 0.05825756

λ2 0.00845095 0.05324096 0.01365153 0.07098795 0.04614217 0.16149758

λ3 0.01109841 0.06991999 0.01792820 0.09322665 0.06059732 0.21209062


λ1 0.04609389 0.12483763 0.07874374 0.19205790 0.11305808 0.25607719

λ2 0.12777831 0.34606624 0.21828794 0.53240960 0.31341179 0.70987947

λ3 0.16780796 0.45447990 0.28667194 0.69919985 0.41159565 0.93226647

20 30 40

1 2 3

1054

Mínimo

Máximo

49

5.1. Escenarios de Análisis

Una vez se han llevado a cabo las simulaciones, es preciso comparar los resultados bajo los siguientes escenarios:

5.1.1. Sistema homogéneo vs. Sistema heterogéneo

En la Figura 45, se muestra la gráfica comparativa de la probabilidad de bloqueo para los sistemas homogéneo (líneas punteadas) y heterogéneo (líneas continuas) en función de la carga de tráfico cursada por servidor (ρ). Este análisis es llevado a cabo para diferente número de servidores, representados con las viñetas correspondientes. Al respecto, se pueden hacer las siguientes observaciones:

• En un sistema heterogéneo se obtiene una probabilidad de bloqueo mayor que en un sistema homogéneo bajo una misma carga de tráfico cursada por servidor, lo cual no implica que la carga de tráfico ofrecida sea la misma para los dos modelos. A manera de ejemplo, se tomo el caso especifico de 10 servidores para un valor de ρ de 0.502747, donde el sistema heterogéneo tiene una probabilidad de bloqueo de 0.033709 y el sistema homogéneo de 0.021032, observando una disminución del 37.69% del segundo frente al primero.

• El sistema homogéneo requiere una carga de tráfico cursada por servidor mayor que el sistema heterogéneo para garantizar un mismo valor de la probabilidad de bloqueo. Continuando con el ejemplo anterior, se tiene que para una probabilidad de bloqueo del 0.033709, la carga de tráfico cursada por servidor para el sistema homogéneo es 0.548085 y para el heterogéneo es 0.502747, teniendo una disminución del 8.27% del segundo frente al primero.

Lo anterior se puede extender bajo la demostración llevada a cabo en la sección 2.2.4, donde se obtuvo que la carga de tráfico cursada (a) es igual al número esperado de servidores ocupados. Este resultado permite concluir que en un sistema homogéneo se espera que el número de servidores ocupados sea mayor que en un sistema heterogéneo para garantizar la misma probabilidad de bloqueo como se observa en la Figura 46.

El archivo fuente de éstas graficas se encuentra en el Anexo 8.11.2.

50

Figura 45. Probabilidad de bloqueo para sistemas homogéneos y heterogéneos


51

Figura 46. Número esperado de canales ocupados para sistemas homogéneos y heterogéneos


Esto significa, que los operadores de telefonía móvil deberían tener en cuenta este hecho en el momento de diseñar la red, especialmente para determinar el número de canales, pues les permitiría disminuir costos y optimizar la red, ya que se necesitan menos canales de voz para garantizar un determinado valor de probabilidad de bloqueo. Por ejemplo, la Tabla 6 muestra el número esperado de canales ocupados para garantizar una probabilidad de bloqueo aproximadamente del 4 %, teniendo en cuenta que las tasas de servicio son: µ1 = 0.00871, µ2= 0.01137 y µ3=0.00978, los cuales son valores constantes independientes del número de canales.

Tabla 6. Número esperado de canales ocupados para una probabilidad de bloqueo aproximadamente del 4%.

Número esperado de canales ocupados Tasas de arribo para el sistema heterogéneo

Homogéneo Heterogéneo λ1 λ2 λ3

1 0.04063 0.04063 0.03402 0.00015 0.00040 0.000532 0.03998 0.31993 0.27284 0.00117 0.00323 0.004253 0.03929 0.77389 0.67157 0.00287 0.00795 0.010444 0.04139 1.35888 1.19719 0.00512 0.01421 0.018665 0.04095 1.98850 1.77184 0.00758 0.02102 0.0276010 0.03816 5.60965 5.15461 0.02199 0.06097 0.0800620 0.03798 13.98658 13.17858 0.05621 0.15583 0.2046530 0.03838 22.93361 21.86255 0.09330 0.25865 0.3396840 0.03804 32.09112 30.80783 0.13144 0.36436 0.47850

CanalesProbabilidad de Bloqueo

52

5.1.2. Comparación de resultados con el modelo de Xian Liu

El objetivo de este escenario es llevar a cabo la comparación los resultados obtenidos por medio de la simulación con el modelo de Xian Liu presentado en [3], a través de la de la probabilidad de bloqueo bajo un tráfico heterogéneo. En el artículo, el modelo de Xian busca modelar un sistema heterogéneo como uno homogéneo, por lo cual se determina la probabilidad de bloqueo utilizando la fórmula de Erlang B de la ecuación (26), siendo la carga de tráfico ofrecida representada en (27), donde es claro ésta (r) aumenta a medida que se tenga un mayor número de perfiles de usuario.

( )∑=

=n

j

j

n

B

jr

nrP

1

!/

!/ (26)

∑ ∑= =

==u

j

u

j j

j

jar

1 1µλ

(27)

Donde: n = Número de servidores; u = Número de perfiles de usuarios.

Para cada uno de los perfiles de usuarios y según los valores de las tasas (λ1, µ1, λ2, µ2 y λ3, µ3) del Anexo 8.11.3, se calcularon las diferentes cargas de tráfico (aj), con las cuales se evalúa la probabilidad de bloqueo dada por la ecuación (26), y cuyos resultados se encuentran graficados en la Figura 47.

Figura 47. Probabilidad de bloqueo para el modelo de Xian.


53

Con el fin de tener mayor claridad sobre lo expuesto, se presenta a manera de ejemplo los resultados obtenidos cuando se bloquean aproximadamente el 4% de las llamadas entrantes, según el sistema heterogéneo representado en la Figura 45. Así que, en la Tabla 7 se muestran los valores de probabilidad de bloqueo y carga de tráfico cursada para cada uno de los casos de análisis de tráfico: simulado (Heterogéneo) y con carga de tráfico simplificada (Modelo Xian).

Tabla 7. Comparación de resultados Escenario 2.

Probabilidad de Bloqueo Carga de tráfico cursada

Servidores Heterogéneo (A) Modelo Xian (B) Heterogéneo (A) Modelo Xian (B)

1 0.04063 0.09611 137% 0.03402 0.09611 182.5%

2 0.03998 0.16390 310% 0.13642 0.35624 161.1%

3 0.03929 0.22476 472% 0.22386 0.54158 141.9%

4 0.04139 0.28550 590% 0.29930 0.66895 123.5%

5 0.04095 0.32714 699% 0.35437 0.74565 110.4%

10 0.03816 0.44261 1060% 0.51546 0.89579 73.8%

20 0.03798 0.53300 1303% 0.65893 0.95917 45.6%

30 0.03838 0.57061 1387% 0.72875 0.97590 33.9%

40 0.03804 0.59057 1453% 0.77020 0.98314 27.6%

Diferencias (%)

B-A

Diferencias

(%) B-A

El hecho que el cálculo de la probabilidad de bloqueo haya sido realizado con la fórmula de Erlang B hace que los resultados reposen sobre las líneas características de un sistema homogéneo. Así que para tener una mejor aproximación del sistema heterogéneo de manera matemática no basta con determinar una carga de tráfico para las diferentes tasas, sino que se requiere hallar la probabilidad de bloqueo de una manera diferente, como se muestra en la Tabla 7, en donde se evidencia las grandes diferencias porcentuales tanto para la probabilidad de bloqueo como para la carga de tráfico.

El modelo presentado en [3], muestra una aproximación que podría funcionar si se tienen variaciones pequeñas de las tasas de servicio. Lo cual, es más claro si se analiza el caso extremo en el que todas las tasas de servicio sean iguales, obteniendo que la carga de tráfico equivalente para este sistema es la relación de la sumatoria de las tasas de arribo y la única tasa de servicio; resultado que coincide con la teoría.

5.1.3. Caso Particular: Análisis de información suministrada por un operador de telefonía móvil colombiano

En este escenario se lleva a cabo el cálculo de la probabilidad de bloqueo para un conjunto de 1016 llamadas recibidas en la ventana de tiempo de tres horas ya mencionada; siendo el objetivo principal la comparación de la probabilidad de bloqueo obtenida para un tráfico heterogéneo y un modelo simplificado, que no hace distinción entre los tres perfiles de usuarios que llegan a la celda. Adicionalmente, se incluyen resultados basados en el modelo de Xian Liu. En todos los casos, se utiliza la información suministrada por el operador de telefonía móvil, buscando plasmar lo que éste enfrentaría al hacer uso del análisis de desempeño teniendo en cuenta que el tráfico es heterogéneo.

Para el cálculo de la probabilidad de bloqueo con la fórmula de Erlang B, es decir, para el modelo simplificado, se requiere conocer la media del tiempo entre arribos y de la duración de las llamadas sin tener en cuenta si provienen de prepago, de pospago o de handover. Los resultados obtenidos son:

10.6206896/1 =λ y 98.6761811/1 =µ

Así que, la Figura 48 muestra la probabilidad de observando que para el caso del sistema heterogéneo, la probmenor, lo cual se traduce en el hecho de que hoysobredimensionando las celdas para soportar el tráfico deseado.

Figura 48. Probabilidad de bloqueo en función del número de servidores para un ejemplo de tasas de un operador de telefonía móvil

Como se observa en la Tabla de probabilidad de bloqueo, que a su vez tiene asociada unaservidor, la cual disminuye cuando se hace la distinción de los difanaliza para 20, 30 y 40 servidores, la probabilidad de bloqueo obtenida simulación, razón por la cual no son tenidos en cuenta.

Tabla 8. Carga de tráfico y probabilida


Carga de tráfico cursada por servidor

Simplificado

1 0.902827

2 0.894382

3 0.884668

4 0.873460

5 0.860503

10 0.760370

Adicionalmente, se ha incluido la probabilidad de bloqueo y la carga de tráfico cursada por servidor, obtenidas según el modelo de Xian Liu. Se puede observar que estos resultados son similares a los presentados por el modelo simplificadoErlang B. Así que, se puede concluir que para un conjunto de tasas dado, el modelo de Xian es una buena aproximación al modelo simplificado utilizado por

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,0

1

Pro

babi

lida

d de

blo

queo

54

muestra la probabilidad de bloqueo resultante en función del número de servidores; observando que para el caso del sistema heterogéneo, la probabilidad de bloqueo es considerablemente menor, lo cual se traduce en el hecho de que hoy en día existen sobrecostos, debido a que se están sobredimensionando las celdas para soportar el tráfico deseado.

bloqueo en función del número de servidores para un ejemplo de tasas de un operador de telefonía móvil

colombiano.


Tabla 8, cada uno de los valores graficados en la Figura de probabilidad de bloqueo, que a su vez tiene asociada una determinada carga de tráfico cursada por servidor, la cual disminuye cuando se hace la distinción de los diferentes perfiles de usuarios.

30 y 40 servidores, la probabilidad de bloqueo obtenida simulación, razón por la cual no son tenidos en cuenta.

. Carga de tráfico y probabilidad de bloqueo para los datos de un operador de telefonía móvil

Carga de tráfico cursada por servidor Probabilidad de Bloqueo

Simplificado Xian Liu Heterogéneo Simplificado Xian Liu

0.903441 0.722355 0.902827 0.903443

0.895099 0.682392 0.807472 0.808669

0.885504 0.636883 0.714345 0.716080

0.874442 0.586440 0.623952 0.626169

0.861658 0.532988 0.536913 0.539543

0.762866 0.311189 0.181600 0.184672

, se ha incluido la probabilidad de bloqueo y la carga de tráfico cursada por servidor, obtenidas según el modelo de Xian Liu. Se puede observar que estos resultados son similares a los presentados por el modelo simplificado, lo cual se debe a que en ambos casos se utilizó la f

Así que, se puede concluir que para un conjunto de tasas dado, el modelo de Xian es una buena aproximación al modelo simplificado utilizado por un operador de telefonía móvil.

2 3 4 5 10Número de servidores

72% 10

0%

bloqueo resultante en función del número de servidores; abilidad de bloqueo es considerablemente

en día existen sobrecostos, debido a que se están

bloqueo en función del número de servidores para un ejemplo de tasas de un operador de telefonía móvil

Figura 48 corresponde a un valor carga de tráfico cursada por

erentes perfiles de usuarios. Cuando se 30 y 40 servidores, la probabilidad de bloqueo obtenida esta fuera del rango de

d de bloqueo para los datos de un operador de telefonía móvil

Probabilidad de Bloqueo

Xian Liu Heterogéneo

0.903443 0.772466

0.808669 0.566413

0.716080 0.390395

0.626169 0.249973

0.539543 0.146673

0.184672 0.002272

, se ha incluido la probabilidad de bloqueo y la carga de tráfico cursada por servidor, obtenidas según el modelo de Xian Liu. Se puede observar que estos resultados son similares a los

, lo cual se debe a que en ambos casos se utilizó la fórmula de Así que, se puede concluir que para un conjunto de tasas dado, el modelo de Xian es una buena

un operador de telefonía móvil.

10

Modelo simplificado

Heterogéneo

55

Para estos datos en particular, el sistema heterogéneo muestra una reducción de la probabilidad de bloqueo frente al homogéneo, siendo el porcentaje de disminución esquematizado para 5 servidores en la Figura 48 y calculado en la Tabla 9, en donde se evidencia el aumento de este porcentaje a medida que se incrementa el número de servidores.

Tabla 9. Porcentaje de disminución de la probabilidad de bloqueo del análisis heterogéneo frente al homogéneo.


Porcentaje de disminución de la Probabilidad de Bloqueo

1 14.439% 2 29.854%

3 45.349%

4 59.937%

5 72.682% 10 98.749%

Es claro, que si los puntos de la Tabla 8 se grafican, éstos deben reposar sobre una de las líneas mostradas en la Figura 45 dependiendo del número de servidores y del tipo de tráfico (homogéneo o heterogéneo), lo cual se observa en la Figura 49, en donde solo se han graficado los valores resaltados en la Tabla 8, dado que el resto de los valores se encuentran por fuera del rango [0.01, 0.4]. Lo anterior fue llevado a cabo con el objetivo de ejemplificar la generalidad y utilidad de la Figura 45.

Figura 49. Escenario 1 y escenario 3.


56

6. CONCLUSIONES

En este trabajo se definió un modelo de simulación de una celda celular GSM a través de un sistema de espera M/M/n/n, para el cual, la probabilidad de bloqueo se definió como el parámetro de desempeño, y éste se evaluó considerando un tráfico de voz heterogéneo. El modelo de simulación se implementó en una herramienta de simulación por eventos discretos llamada OMNeT++ 4.0 y se validó con la fórmula de Erlang B, a través de las curvas de desempeño expuestas.

Los datos de entrada al modelo de simulación fueron basados en la información suministrada por un operador de telefonía móvil colombiano, de la cual se evidenció un mayor intento de llamada por parte de los usuarios prepago, lo cual se debe a la diferencia que existe entre la cantidad de usuarios prepago frente a los pospago, aproximadamente de 6 a 1. Sin embargo, se encontró que en promedio la duración de las llamadas para un usuario pospago es mayor, hecho que era de esperarse, ya que la disponibilidad de tiempo al aire para usuarios con cargo fijo mensual es superior.

Al realizar el respectivo análisis de los resultados, se encontró que para garantizar la misma probabilidad de bloqueo, el número esperado de canales ocupados en un sistema heterogéneo es menor que en un sistema homogéneo, hecho que deberían tener en cuenta los operadores de telefonía móvil en el diseño de la red, en especial para determinar el número de canales, pues esto les permitiría disminuir costos y optimizar la red, ya que se necesitan menos canales de voz para garantizar un determinado valor de probabilidad de bloqueo.

Lo anterior, se reafirma al evaluar las tasas que suministró el operador, donde se obtuvo, a través del análisis del sistema heterogéneo, que la probabilidad de bloqueo es considerablemente menor, lo cual significa que hoy en día existen sobrecostos debido a que se están sobredimensionando las celdas para soportar el tráfico deseado. Adicionalmente, se puede concluir que las diferencias presentadas para la probabilidad de bloqueo en los dos sistemas se incrementa a medida que el número de canales aumenta, así que, entre más canales se dispongan para el tráfico es más significativo hacer un análisis apropiado del sistema heterogéneo.

Por otro lado, se encontró que para el caso de estudio, la aproximación expuesta en [3] muestra un modelo cuyos resultados difieren del modelo heterogéneo presentado en éste documento, ya que la carga de tráfico ofrecida es proporcional al número de perfiles de usuarios. Se concluye que para tener una mejor aproximación del sistema heterogéneo de manera matemática no basta con determinar la carga de tráfico ofrecida para las diferentes tasas, sino que se requiere hallar la probabilidad de bloqueo de una manera diferente.

Finalmente, los tiempos de simulación jugaron un papel fundamental en la ejecución de éste proyecto, ya que entre la validación del modelo y el sistema heterogéneo se realizaron alrededor de 280 simulaciones, que si bien en un computador de dos núcleos, pueden tardar de 5 a 8 minutos para un servidor, para 40 servidores el tiempo de simulación escila entre 300 y 430 minutos, lo cual significa un compromiso de tiempo importante.

Como trabajos futuros se puede plantear un modelo matemático que describa el comportamiento del sistema de espera M/M/n/n bajo un tráfico heterogéneo, analizar los reintentos de llamadas, voz y datos, y trabajar directamente con los operadores celulares, todo esto con el fin de obtener un modelo de simulación que se ajuste con mayor precisión a los sistemas de telefonía móvil actuales.

7. BIBLIOGRAFÍA

[1] Estadísticas tomadas del resumen de información de mercadeo de GSM Association publicado Septiembre de 2008. [En línea]. Disponible en: [http://www.gsmworld.com/newsroom/market-data/market_data_summary.htm]. [Consulta: Julio de 2009]

[2] YUE, Li; AWAN, I.; AL-BEGAIN, K. “Performance models in GSM and GPRS networks”. Computer Networks and Mobile Computing, 2003. ICCNMC 2003. 2003 International Conference on 20-23 Octubre 2003. p. 275–282.

[3] XIAN, Liu; “A method to minimize the blocking probability for heterogeneous traffic flows”. Wireless Communications and Networking Conference, 2006. WCNC 2006. IEEE. v. 4, 3-6 Abril 2006. p. 2312-2317

[4] HEINE, Gunnar. GSM Networks: Protocols, Terminology, and Implementation. 1998.

[5] SCOURIAS, John. “Overview of the Global System for Mobile Communications”. University of Waterloo. Octubre de 1997 [En línea]. Disponible en: [http://ccnga.uwaterloo.ca/~jscouria/GSM/gsmreport.html]. [Consulta: Agosto de 2009]

[6] RAHNEMA, M.. “Overview of the GSM system and protocol architecture”, Communications

Magazine, IEEE, v.31, no.4, Abril 1993. p. 92-100.

[7] NIELSEN, Thomas Toftegaard; WIGARD, Jeroen. Performance Enhancements in a Frequency Hopping GSM Network. 2002. p. 1-30.

[8] INTERNATIONAL TELECOMMUNICATION UNION. Recommendation Q.920. Marzo de 1993. [En línea]. Disponible en: [http://www.itu.int/rec/T-REC-Q.920-199303-I/en]. [Consulta: Septiembre de 2009]

[9] BOLCH, Gunter; GREINER, Stefan; DE MEER, Hermann; TRIVEDI, Kishor. Queueing Networks and Markov Chains. 1998. p. 209-262.

[10] JAIN, Raj. The art of computer systems performance analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling. 1991. p. 505-546.

[11] MEDHI, J.; Stochastic Models in Queueing Theory. 2a ed. 2003. p. 52, 95-100.

[12] LAW, Averill M.; KELTON, David. Simulation modeling and analysis. 3a ed. 2000. p. 1-60.

[13] ROSS, Sheldon. Simulación. 2a ed. 1999. p. 36-216

[14] OMNET++. User Manual, version 4.0. p. 1-50, 124

[15] LEEMIS, Lawrence M.; PARK, Stephen K. Discrete-Event Simulation: A first Curse. 2006. p. 350-363.

[16] CHAN, Wah Chun. Performance Analysis of Telecommunication and Local Area Networks. 2000. p. 228, 229

[17] POWELL, C.J.; LEUNG, V.C.M.; , "Traffic engineering for integrated telephone and dispatch land mobile radio traffic," Wireless Communications, 1992. Conference Proceedings., 1992 IEEE

International Conference on Selected Topics in 25-26 Jun 1992, vol., no., pp.168-171.

8. ANEXOS

8.1. Instalación de OMNeT++ 4.0

8.2. Código M/M/n (Implementado en OMNeT++ 4.0)

8.2.1. Fuente

8.2.2. Cola

8.2.3. Servidor

8.2.4. Sumidero

8.2.5. Otros

8.3. Código M/M/n/n (Implementado en OMNeT++ 4.0)

8.3.1. Fuente

8.3.2. Switch

8.3.3. Servidor

8.3.4. Sumidero

8.3.5. Otros

8.4. Gráficas de los parámetros del sistema de espera M/M/1/1 para 450000 s en tiempo de simulación

8.5. Código para Promedio acumulado de la probabilidad de bloqueo para 150 corridas (Implementado en Matlab)

8.6. Código de realización de Prueba de Bondad y Ajuste (Implementado en Matlab)

8.7. Recopilación de los resultados de la validación

8.7.1. Gráficas Validacion.xls

8.7.2. Tablas de resultados de la validación del sistema de espera M/M/n/n

8.8. Tabla Erlang B

8.9. Código de la gráfica de validación: Resultados simulados vs. Teóricos (Implementado en Matlab)

8.10. Análisis de los datos de entrada

8.10.1. Histogramas de los tiempos entre arribo y la duración de las llamadas para los usuarios pospago y prepago

8.10.2. Código de las prubas de Kolmogorov-Smirnov (Implementado en Matlab)

8.11. Resultados obtenidos para el tráfico heterogéneo

8.11.1. Tráfico Heterogéneo

8.11.2. Sistema Homogéneo vs Sistema Heterogéneo

8.11.3. Comparación con el modelo de Xian Liu

anÁlisis de desempeÑo de una celda celular gsm con …

Documents