simulaciÓn de sistemas multimedia sobre sistemas

SIMULACIÓN DE SISTEMAS MULTIMEDIA SOBRE SISTEMAS SATELITALES NO GEOESTACIONARIOS

JOSÉ FERNANDO CASTILLO FERNÁNDEZ

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA

BOGOTA, D.C.

Simulación de Sistemas Multimedia Sobre Satélites No Geoestacionarios IEM-2002-II-02

1

INTRODUCCION

Los sistemas de comunicaciones móviles, por satélites no geoestacionarios (Non-GEO

MSS) permiten una cobertura mundial, llegando incluso a zonas remotas de difícil acceso,

donde inicialmente otras tecnologías serían altamente costosas. A medida que estos

sistemas han ido evolucionando también se han incrementado las posibles aplicaciones

sobre este tipo de sistemas, entre las que se encuentra la conmutación de paquetes, la cual

es una de las aplicaciones más recientes en este campo, permitiendo la transmisión de

diferentes flujos de información, tales como voz, datos y video, componentes básicos del

tráfico multimedia, el cual es la base de estudio de este proyecto.

En este proyecto se pretende realizar la simulación de aplicaciones multimedia, basado en

el software de simulación de sistemas Non-GEO, desarrollado con anterioridad en el

trabajo de tesis de maestría llamado “Servicio Móvil y Fijo en Sistemas Satelitales Móviles

No-Geoestacionarios (Non-GEO MSS)”, en el cual se desarrollo un software que permitía

la simulación de servicios de telecomunicaciones sobre los sistemas MSS, que fue aplicada

a los siguientes escenarios: Iridium, Globalstar e ICO. Dicha herramienta fue diseñada bajo

el esquema de conmutación de circuitos para un escenario mixto, conformado tanto por

usuarios fijos como móviles, basado en el concepto de GH (Guaranteed Handoff).

A partir de este desarrollo inicial, se procedió a ejecutar este nuevo proyecto, el cual se basa

principalmente en la simulación de trafico multimedia, para lograr esto fue necesario

realizar la adaptación del software, pasando de conmutación de circuitos a conmutación de

paquetes, a través de una serie de pasos intermedios, entre los cuales se tiene: pasar del

modelo de tráfico de Erlang B a Erlang C para permitir la simulación de sistemas de espera,

y la adaptación del software a conmutación de paquetes, para finalmente llegar a una

disciplina M/G/1/∞ con posibilidad de variar el tamaño del canal asignado a cada usuario.


2

OBJETIVO GENERAL

- Adaptar el software de simulación de servicios de telecomunicaciones en sistemas MSS

desarrollado con anterioridad, de tal forma que permita la simulación de sistemas

multimedia sobre sistemas satelitales No-Geoestacionarios, y poder así determinar el

desempeño de dichas redes.

- Aprovechar los conceptos desarrollados en el software anterior, como son el concepto de

GH, el manejo de tráfico mixto, variación de las condiciones de simulación, etc., que

permiten la simulación de diversos escenarios y mejorar el desempeño de la red.

OBJETIVOS ESPECIFICOS

- Modificar el software para permitir la implementación del modelo de tráfico de Erlang C.

- Modificar el software para pasar de la conmutación de circuitos a la conmutación de

paquetes necesaria para poder realizar las simulaciones multimedia.

- Determinar los posibles cambios que se deben realizar a la estructura del software, de tal

forma que permitan un mejor desempeño del mismo, así como la capacidad computacional

del programa.

- Realizar simulaciones de los sistemas satelitales SkyBridge y Teledesic con la finalidad

de probar el simulador.

ALCANCE DEL PROYECTO

El alcance inicial del proyecto estaba definido para realizar las simulaciones exhaustivas de

las constelaciones de tráfico multimedia más viables a implementar, las cuales son

SkyBridge y Teledesic. Sin embargo, este alcance fue recortado dados los problemas

presentados durante la generación de la herramienta, y se decidió dejar la campaña de

simulación como un proyecto de tesis posterior que se encargará de analizar el desempeño

tanto de estos sistemas, como de otros nuevos proyectos que puedan surgir o que sean de

interés dentro del proceso de simulación.


3

Debido a lo anterior el nuevo alcance del proyecto, es la generación de una herramienta de

simulación que permita la simulación de tráfico multimedia, mediante la adaptación del

software al modelo de tráfico de Erlang C y a la conmutación de paquetes. Adicionalmente,

se realizará una simulación basada en un sistema real, que permita validar la herramienta y

detectar posibles fallas que este pueda presentar.

METODOLOGÍA

La metodología bajo la cual se desarrollo este proyecto contemplaba las siguientes fases:

- Análisis del software desarrollado con anterioridad con la finalidad de comprender el

funcionamiento de este y así poder determinar la mejor forma de realizar las

modificaciones correspondientes, para poder adaptarlo al modelo de tráfico de Erlang C

y a la conmutación de paquetes; manteniendo las características principales de este

desarrollo, como son: la robustez del writter para generar bases de datos de capacidad

infinita que puedan ser utilizadas en simulaciones con diversas cargas de tráfico; y la

flexibilidad y velocidad del reader que permite correr simulaciones en un tiempo

relativamente corto y que además permite variar los parámetros de simulación en cada

corrida.

- Definición e implementación del modelo de tráfico de Erlang C a partir del modelo de

tráfico de Erlang B, con la finalidad de permitir al usuario un tiempo de espera para

conectarlo al sistema en la eventualidad de que todos los canales se encuentren

ocupados.

- Implementación de un modelo de simulación simultanea, en el cual la tierra es dividida

en subregiones en el momento de generar la base de datos, las cuales pueden ser

simuladas sobre varios computadores, y donde además cada una de estas regiones

requiere un tiempo menor de simulación debido a su menor cubrimiento que

corresponde a una menor cantidad de eventos a procesar. Esta modificación afecta tanto


4

al writter como al reader, ya que el reader también debe ser modificado para leer

eventos de las diferentes bases de datos generadas.

- Definición e implementación de la conmutación de paquetes, para a partir de está poder

ofrecer al sistema la opción de trabajar con distintos tipos de tráfico tales como voz,

datos y vídeo, los cuales son los componentes básicos del tráfico multimedia.


5

1. DESARROLLOS ANTERIORES

Mediante el análisis del software desarrollado en el proyecto de tesis anterior, se pretende

comprender el funcionamiento de este para poder usarlo con facilidad, así como realizar un

análisis del código mediante el cual se implementó, para posteriormente poder trabajar con

él. Este análisis se realiza con la finalidad de entender con exactitud los diferentes módulos

que conforman cada una de las partes del programa total, así como de identificar

claramente las diferentes variables, funciones y procedimientos definidos dentro de cada

uno de dichos módulos.

La arquitectura del simulador de MSS es mostrada en la Figura No. 1.

Constellation Database

ConstCn parameters

Traffic grid

Traffic Database

Event Database

Traffic parameters

Scenario Simulator

Scenario parameters

Scenario QoS parameters

Constellation Parameters

Constellation Database

Traffic Database

Events Database

Scenario Simulator

Scenario parameters

Traffic parameters

Traffic grid

Scenario QoS results

FIGURA No. 1. ARQUITECTURA DEL SIMULADOR DE MSS

Como se puede observar en la figura anterior, el simulador está compuesto por 4 módulos

que son: Constellation Database, Traffic Database, Events database y Scenario Simulator,

descritos a continuación.


6

1.1. CONSTELLATION DATABASE

Este módulo es el encargado de generar la constelación del sistema satelital que se va a

simular, para esto es necesario que el diseñador introduzca los parámetros de la

constelación, descritos por la notación de Walker, el tipo de constelación (polar ó

inclinada), altitud de la órbita, y el tamaño de la huella. A partir de estos datos, el programa

calcula y almacena la posición de cada uno de los satélites que conforman la constelación,

en el momento en que esta se establece. La simulación se realiza para sistemas satelitales

LEO y MEO como: Iridium, Globalstar e ICO.

1.2. TRAFFIC DATABASE

Este módulo está basado en una proyección cilíndrica de la superficie de la tierra, y asume

grillas con igual latitud (alto) y longitud (ancho), el diseñador define el tamaño de la grilla.

Se establece una grilla de división de la tierra, determinando las coordenadas de cada una

de ellas. Por lo tanto, el diseñador crea un mapa de tráfico, definiendo un coeficiente de

densidad de tráfico normalizada (Erl/Km2) para cada una de las grillas. La normalización

es hecha con respecto a la grilla con mayor carga de tráfico. Este mapa de tráfico es

almacenado en una base de datos. La generación del tráfico es un proceso estocástico que

se establece con base en el número de grillas en que se divida la tierra. La simulación puede

realizarse tanto para una distribución de tráfico homogénea, como para una distribución

heterogénea.

1.3. EVENTS DATABASE

Dadas las bases de datos anteriores, el diseñador selecciona una constelación y un mapa de

tráfico; adicionalmente, el diseñador introduce los siguientes datos: máxima carga de

tráfico esperada, la duración media de la llamada y la duración de la simulación. Se asume

que la constelación tiene una capacidad infinita de canales, entonces, todos los eventos

pueden ocurrir y deben ser atendidos exitosamente; también se asume que todos los

usuarios son del tipo GH. La disciplina de asignación de satélite está basada en el mejor


7

satélite disponible para cada evento en un instante, por lo tanto, una vez un usuario es

conectado a un satélite dado, este mantendrá su conexión el mayor tiempo posible en base a

estos parámetros. El simulador genera intentos de llamada, definiendo el instante en que

ellos ocurren, su duración, y el próximo instante en donde se generará una nueva llamada;

entonces se localizan uniformemente todas las llamadas sobre la superficie de la tierra, y la

grilla de asignación resultante es encontrada. Una vez este punto es definido, el simulador

determina la trayectoria del usuario, y calcula la secuencia de eventos (handovers,

reservaciones y terminaciones de llamadas) con su respectivo instante de ocurrencia, y los

satélites involucrados en cada uno. Cuando la generación de eventos a terminado, ellos son

ordenados cronológicamente, y finalmente, los eventos y su información asociada son

almacenados en una base de datos.

1.4. SCENARIO SIMULATOR

Primero que todo se selecciona una base de datos de eventos. Entonces el diseñador

especifica: una nueva carga de tráfico (menor que la de la base de datos de eventos), una

nueva distribución relativa de tráfico, el porcentaje de usuarios GH y la capacidad de

canales del satélite. Basado en estos parámetros, el simulador reduce la carga de tráfico de

cada grilla, omitiendo algunos de los eventos de intentos de llamada (y sus siguientes

eventos asociados) en la base de datos; los usuarios pueden ser tomados como regulares

ignorando los eventos de reservación. El simulador genera contadores para el estado de

ocupación y su QoS asociada para cada satélite y para cada grilla. Los contadores son

reestablecidos cada vez que un evento ocurre, y de acuerdo al resultado del servicio

(servido ó perdido). Al final de la simulación, esta base de datos tiene almacenado el

comportamiento de cada satélite y cada grilla.


8

2. HERRAMIENTA DE SOFTWARE

2.1. IMPLEMENTACION DE ERLANG C

En esta fase se definió la forma de implementar el modelo de tráfico de Erlang C, a partir

del modelo de tráfico de Erlang B desarrollado con anterioridad, para posteriormente poder

adaptar el software hacia la conmutación de paquetes, conservando el concepto de

simulación sobre WORM (Write Once, Read Many).

La modificación del software para adaptarlo al modelo de tráfico de Erlang C está basada

prácticamente en modificar el modelo de tráfico que define como los intentos de llamada

van a ser tenidos en cuenta en el momento en que estos se establecen, estas modificaciones

afectan directamente el modulo de escritura (Scenario Simulator), ya que es en este donde

realmente se determina como va ser la conexión de cada uno de los intentos de llamada

contenidos en la base de datos de eventos, es decir, las bases de datos generadas con

anterioridad: Constellation, Traffic y Events Database se mantienen igual independiente del

modelo de tráfico que se utilice.

El nuevo programa va a permitir la simulación de sistemas satelitales definidos tanto con el

modelo de tráfico de Erlang B como con el modelo de tráfico de Erlang C, así como

definir el parámetro del tiempo de espera necesario para modelar el tráfico de Erlang C.

Esto es posible dadas las características de los dos modelos, las cuales solo difieren en el

hecho de que en el modelo de tráfico de Erlang B el tiempo de espera es cero, y en el

modelo de tráfico de Erlang C este está definido de acuerdo con la aplicación específica.

Para la implementación del modelo de tráfico de Erlang C se deben considerar 3 casos, los

cuales se describen a continuación:


9

a. Cuando la fila de espera de los usuarios GH es mayor que cero, implica que el sistema

esta saturado (C + R = Ctotal), por lo tanto, el grado de ocupación para los tiempos t y t+1

se muestra en la Tabla No.1.

TIEMPO OCUPADOS RESERVADOS ESPERA ERL C

ESPERA GH

t C R Werl Wgh t+1 C-1 R+1 Werl Wgh-1

TABLA No. 1. GRADOS DE OCUPACION PARA EL CASO A

En este caso el siguiente canal que se libere, será inmediatamente reservado para un

usuario GH en la fila de espera Wgh. Nótese que el sistema permanece saturado, (C+R =

C-1 + R+1 = Ctotal), pero se reduce la fila de espera (el canal liberado es inmediatamente

reservado para una de las llamadas GH en su respectiva fila de espera).

Al igualar el número total de canales ocupados, reservados y en lista de espera tanto en t

como en t+1 se puede comprobar que realmente es liberado un canal en el sistema, está

verificación se muestra a continuación:

∑∑∑∑

∑∑

−+++=+++

−++++−=+++

+=

1

)1()1()1(

1

WghWerlRCWghWerlRC

WghWerlRCWghWerlRC

tt

b. Cuando la fila de espera de los usuarios GH es cero, y la fila de espera de los usuarios

con modelo de tráfico de Erlang C es mayor que cero, el sistema nuevamente se encuentra

saturado (C+R = Ctotal), por lo tanto, el grado de ocupación para los tiempos t y t+1 se

muestra en la Tabla No.2.


ESPERA GH

t C R Werl 0 t+1 C R Werl-1 0

TABLA No. 2. GRADOS DE OCUPACION PARA EL CASO B


10

En este caso el siguiente canal que se libere será ocupado inmediatamente por un usuario en

la fila de espera del modelo de tráfico de Erlang C. Nótese que el sistema sigue saturado

(C(t)+R(t) = C(t+1) + R(t+1) = Ctotal), pero se reduce el tamaño de la fila de espera de

nuevas llamadas (el canal liberado es inmediatamente ocupado por una de las nuevas

llamadas en fila de espera).

Nuevamente, al realizar la suma total de los canales en los tiempos t y t+1 se puede

comprobar que en este instante un canal es liberado en el sistema, la verificación se muestra

a continuación:

∑∑∑∑

∑∑

−++=++

+−++=+++

+=

1

)1(

1

WerlRCWerlRC

WghWerlRCWghWerlRC

tt

c. Cuando tanto la fila de espera de usuarios GH como la fila de espera de los usuarios con

modelo de tráfico de Erlang C son cero, no siempre el sistema estará saturado, por lo tanto

C + R puede ser menor o igual que Ctotal, y el grado de ocupación para los tiempos t y t+1

se muestra en la Tabla No.3.


ESPERA GH

T C R 0 0 t+1 C-1 R 0 0

TABLA No. 3. GRADOS DE OCUPACION PARA EL CASO C

En este caso en el momento en que un canal se libere, este quedará disponible para ser

usado por una nueva comunicación que se genere.

En esta opción también se puede verificar que un canal es liberado en el sistema entre los

tiempos t y t+1, la verificación se muestra a continuación:


11

∑∑∑∑

∑∑

−+=+

+++−=+++

+=

1

)1(

1

RCRC

WghWerlRCWghWerlRC

tt

Para que un usuario pueda ser conectado dentro del tiempo de espera dado por el modelo de

tráfico de Erlang C, se deben analizar todos los eventos que ocurrirán dentro del periodo

que haya sido determinado. Si dentro de este periodo el número de liberaciones del satélite

de interés es mayor que el número de usuarios GH en lista de espera de ese satélite más el

número de usuarios en lista de espera del modelo de tráfico de Erlang C de ese satélite,

entonces el nuevo usuario podrá ser conectado dentro de dicho tiempo de espera y, por lo

tanto, se le puede ofrecer el servicio. Si por el contrario el número de salidas es menor o

igual, entonces la conexión debe ser rechazada y contarse como una llamada perdida, esto

con la finalidad de evitar que una llamada en curso se pierda, lo cual sería más perjudicial

para el usuario.

El hecho de sí existe o no un canal libre dentro del tiempo de espera establecido, se puede

determinar en el instante en que el usuario intenta conectarse, debido a que los eventos son

determinísticos, y por lo tanto, se puede saber con exactitud lo que sucederá durante ese

tiempo de espera.

Cuando se evalúa el número de canales liberados y el número de usuarios GH en la lista de

espera, no es necesario tener en cuenta las nuevas entradas en Wgh, ya que estas entradas

no serán copasajeros del evento en cuestión.

El tiempo de espera usado inicialmente para las simulaciones es 10 seg., sin embargo, en la

implementación este será un parámetro de entrada y podrá ser determinado por el usuario

del programa, para así mediante la simulación exhaustiva determinar cual es el valor o el

rango adecuado de este parámetro de acuerdo al tipo de tráfico que se maneje.

La secuencia de eventos que deben ser tenidos en cuenta para agregar la capacidad de

Erlang C al simulador son las siguientes:


12

1 Llegada de un usuario X al satélite i en el tiempo t0, con modelo de tráfico de Erlang C.

2 Localizar el primer handover del usuario, en el satélite j.

3 Calcular el tiempo de ocurrencia del handover Thj con respecto al tiempo t0 (tiempo de

establecimiento de la llamada). Thj=thj-t0.

4 Determinar si el handover ocurre en un tiempo menor al tiempo de Erlang C. Thj<terl

5 Si la condición del punto 4 se cumple, entonces se realiza un nuevo intento de conexión

al satélite j en el cual ocurre el primer handover, y se realiza nuevamente el

procedimiento en el tiempo restante, es decir, Terl-thj. Esto se realiza con la finalidad

de evitar un handover de más en el sistema, el cual puede ocurrir en un instante muy

próximo al de conexión.

6 Si la condición del punto 4 no se cumple, se determina el número de canales libres del

satélite i, Ci+Ri, si este valor es menor que CTi el usuario se conecta inmediatamente.

7 Si no existen canales libres, se determina el número de canales liberados durante el

tiempo de Erlang C, terl. Si este número es mayor que el número de usuarios en la lista

de espera de GH más el número de usuarios en la lista de espera de Erlang C, entonces

el nuevo usuario es colocado dentro de la lista de espera de Erlang C, debido a que

durante el transcurso de terl se le podrá brindar el servicio.

8 En caso contrario, el usuario no se puede conectar y es necesario aumentar el contador

de llamadas bloqueadas y resetear los eventos anteriores del mismo usuario que fueron

marcados como posibles. Se procede a analizar el caso de un nuevo usuario de Erlang

C.

9 Si no existen nuevos usuarios, entonces el programa se detiene.

La Figura No. 2 muestra en el diagrama de flujo de una forma más clara la recopilación de

los pasos anteriores y su secuencia lógica:


13

1 Pasa a atender al siguiente usuario

INICIO

Llega usuario x al satélite i (Si) en t0

Localizar el primer handoff thj

Ci+ Ri<CTi

Thj<Terl

Determinar No. de canales libres en Si

Calcular ThjThj=thj-t0

NO

SI

SI

NO

Aumenta la fila de espera Werl

Nuevo intento de conexión al satélite j

Terl =Terl -thj

ΣClib>WGH+Werl

Localizar liberacio-nes en Si en terl

SI

NO

Conexión del usuario x

1

Aumenta contador llamadas bloqueadas

El usuario no se puede conectar

1

Resetea los eventos del usuario

1

Hay más usuarios?

SI1

FIN

1 Pasa a atender al siguiente usuario

INICIO



Ci+ Ri<CTi

Thj<Terl



NO

SI

SI

NO



Terl =Terl -thj

ΣClib>WGH+Werl


SI

NO


1



1


1

Hay más usuarios?

SI1

FIN

INICIO



Ci+ Ri<CTi

Thj<Terl



NO

SI

SI

NO



Terl =Terl -thj

ΣClib>WGH+Werl


SI

NO


1



1


1

Hay más usuarios?

SI1

FIN

FIGURA No. 2. DIAGRAMA DE FLUJO, PARA IMPLEMENTAR EL MODELO DE ERLANG C


14

Metodología

Para la implementación del modelo de tráfico de Erlang C, se desarrolló una metodología

en la cual primero se definieron los pasos a seguir y posteriormente se procedió al diseño

del algoritmo respectivo. El cual se reviso y reevalúo, en la búsqueda de deficiencias que

pudieran existir, para finalmente llegar a su diseño óptimo.

En la implementación del modelo de tráfico de Erlang C, el sistema se modificó para que

pudiera simular escenarios con modelos de tráfico Erlang B ó Erlang C. Para que el

software pueda discernir entre los 2 tipos de modelo el tiempo de espera será definido por

el usuario, de esta forma si el usuario introduce un tiempo de espera de 0 segundos, el

simulador asumirá el modelo de tráfico de Erlang B; en el caso contrario donde el usuario

introduce un valor para el tiempo de espera mayor de 0 segundos, el simulador asumirá el

modelo de tráfico de Erlang C.

El tiempo de espera tomado inicialmente para las simulaciones del modelo de tráfico de

Erlang C, es de 10 segundos, que es el tiempo durante el cual el simulador analizará las

liberaciones de canales que ocurren en el satélite en el que el usuario desea conectarse, para

así determinar la posibilidad de conexión del nuevo usuario. Sin embargo, este es un valor

tomado para realizar las simulaciones, pero el rango en el cual este debe estar, será

determinado como resultado de las simulaciones que se realicen.

Una vez definido este valor, el simulador analizará el número de liberaciones que ocurren

en el satélite en cuestión durante este intervalo de tiempo, si al analizar las liberaciones se

obtiene que se liberarán el número de canales requeridos, entonces el usuario será agregado

a la lista de espera de los usuarios que serán atendidos por el sistema. En caso contrario,

sino se liberan los canales suficientes, entonces la llamada del usuario será rechazada y se

considerará como una llamada bloqueada. Este bloqueo es preferible para el usuario, ya que

así el esperará un tiempo e intentará nuevamente su llamada y no se le darán falsas


15

expectativas de posibilidad de comunicación, cuando realmente el sistema no lo pueda

atender.

El modelo de Erlang C, solamente será aplicado para la conexión inicial del usuario en el

momento en que se establece la llamada, ya que si este modelo se aplicara a los handover

que pueden ocurrir durante el trascurso de la llamada, esto se observaría como una

interrupción momentánea de la llamada en progreso que generalmente no sería aceptada por

un usuario del servicio de voz.

La definición inicial del modelo de Erlang C se realizó considerando que todos los usuarios

utilizan únicamente el servicio de telefonía convencional, pero más adelante cuando se

implementó la conmutación de paquetes, ésta fue modificada para trabajar con diferentes

tipos de tráfico.

La nueva pantalla del módulo Escenario Simulator del software de simulación , que incluye

la parte correspondiente al tráfico con modelo de tráfico de Erlang C se muestra EN LA

Figura No. 3.

FIGURA No. 3. MODULO SCENARIO SIMULATOR


16

2.2. IMPLEMENTACION DE LA SIMULACION SIMULTANEA

Como estrategia para agilizar el proceso de simulación en la parte referente a la generación

de la base de datos de eventos, se modificó el módulo events database y scenario simulator

para realizar simulaciones simultáneas, en las cuales la tierra se divide en varias regiones de

igual tamaño determinadas por medio de sus coordenadas de longitud y latitud. Con esta

metodología se espera reducir considerablemente los tiempos de simulación en la

generación de los eventos, ya que este proceso para un caso real en un solo equipo podría

tardar alrededor de 10 días. Al poder realizar simulaciones simultaneas en varios equipos o

en un equipo de procesamiento en paralelo, este tiempo se disminuirá sustancialmente, lo

cual permitirá realizar un número mayor de simulaciones, y obtener así mejores resultados

del proceso de simulación.

Para garantizar que las simulaciones simultaneas trabajen con la misma lista de eventos,

cada una de estas regiones se simula a partir de la misma base de datos de eventos (la

misma semilla), para mantener una coherencia en todas las regiones de las llamadas que

dada su duración y ubicación deben atravesar más de una de estas regiones. Para lograr esta

coherencia se modificó el writter, de tal forma que este en el momento de generar la base de

datos con la lista de eventos, pregunta al usuario el número de zonas en las cuales quiere

dividir la tierra, así como las coordenadas que limitan dicha zona. De esta forma todas las

bases de datos se generan a partir de la misma semilla y se crea una coherencia para los

usuarios que por estar cerca de una frontera, tengan eventos en dos bases de datos

consecutivas.

Este procesamiento paralelo o simultaneo solo es aplicado al writter, ya que es este el que

realmente requiere una gran cantidad de tiempo para ejecutarse. El reader seguirá

funcionando como un solo proceso al tiempo, sin embargo, este también fue modificado ya

que el proceso de lectura ya no se realiza a partir de una sola base de datos de eventos. En

este caso el reader cargará las n bases de datos generadas con el writter e irá buscando en

ellas los eventos secuencialmente, de tal forma que el simulador las vea como una sola.


17

Este proceso no implica un aumento considerable del tiempo de procesamiento del reader,

pero si una mejora sustancial en el desempeño del simulador como tal.

A partir de estas divisiones el tráfico total generado que se vaya a simular, será repartido en

proporciones iguales para cada una de estas zonas, permitiendo así que la simulación de

cada una de ellas sea más ágil, a la vez que se garantiza la simulación del mismo tráfico que

se simularía tomando toda la tierra.

La economía en tiempo que se logre con esta metodología depende del número de regiones

en las que se divida la tierra, por ejemplo, una simulación que dure 10 días, al ser dividida

en 4 regiones tendrá un ahorro de 7.5 días, ya que cada región simulará un cuarto del tráfico

total el cual tomaría alrededor de 2.5 días en ser simulado. Si se puede realizar

procesamiento en paralelo, cada simulación de una de las regiones se demorará 2.5 días

pero todas pueden ser realizadas al mismo tiempo, por lo tanto al final de este periodo se

tendrá el resultado total de simular el mismo tráfico sobre toda la tierra.

La forma de definir la región a simular se puede observar al final de la Figura No. 4, donde

nos pregunta las coordenadas de la región sobre la cual se quiere generar la base de datos.

FIGURA No. 4. MODULO EVENTS DATABASE


18

2.3. IMPLEMENTACION DE LA CONMUTACIÓN DE PAQUETES

Para la implementación de la conmutación de paquetes, se modificó el sistema en los

programas writter y reader, para que permitieran simular usando las diferentes bases de

datos de cada uno de los tipos de tráfico y fuera recorriéndolas secuencialmente en el

tiempo en la búsqueda del nuevo evento.

Para lograr esta implementación, en el writter se le pregunta al usuario el tipo de tráfico de

la base de datos a generar, como uno más de los parámetros de entrada. Adicionalmente, se

agregó un campo más a los eventos, con la finalidad de agregar la información

correspondiente al tipo de tráfico del evento.

En el reader, se definieron contadores de llamadas perdidas, llamadas bloqueadas, llamadas

terminadas, etc., para cada uno de los tres tipos de tráfico a manejar, los cuales se

incrementan teniendo en cuenta la bandera que identifica el tipo de tráfico del evento.

Además, se creo una granularidad de los canales, con la finalidad de hacer más eficiente su

uso; se definió una granularidad de 16 KHz, por lo tanto, para un evento de voz se utilizará

únicamente un canal de 16 KHz, para un evento de datos se utilizarán 4 canales de 16 KHz

para obtener finalmente un ancho de banda de 64 KHz, y finalmente, para un evento de

video se utilizarán 16 canales de 16 KHz para así obtener un ancho de banda de 256 KHz.

Para lograr esta granularidad el reader, de acuerdo al tipo de tráfico al que pertenece el

evento, reserva o libera el número de canales necesarios.

Para la simulación, se deben generar 3 bases de datos diferentes cada una de las cuales

simula un tipo de tráfico en especial, es decir, se generará una base de datos para voz, una

para datos y una para vídeo. La finalidad de generar estas tres bases de datos es poder

aprovechar la funcionalidad del writter para especificar los parámetros que caracterizan

cada uno de los tráficos, los cuales difieren básicamente en el tiempo medio.

A pesar de generar tres bases de datos diferentes, estas también se beneficiarán de la

simulación en paralelo, ya que dada la nueva funcionalidad del writter cada una de las bases


19

de datos, podrá ser dividida en un número igual de regiones y simularse en varios procesos

al mismo tiempo.

En el reader serán tomadas las 3 bases de datos, con sus subdivisiones respectivas (si

existen) y se unificarán, además, se consolidan los eventos de un mismo usuario que debido

a la simulación simultanea se encuentren en diferentes regiones.

La selección del tipo de tráfico en el momento de generar la base de datos se puede

observar en la Figura No. 4, en su primera parte donde nos pregunta el tipo de tráfico que se

quiere simular.


20

3. CONSTELACIONES

El proceso de simulación de tráfico multimedia, se realizará básicamente sobre 2 tipos de

constelaciones, las cuales son las más viables a ser implementadas. Estas son SkyBridge y

Teledesic, las cuales se definen a continuación:

3.1. SKYBRIDGE

El sistema está basado en una constelación de 64 satélites LEO, los cuales se

encuentran dentro de una órbita circular a una altura de 1457 Km de la tierra. La

constelación está divida en dos subconstelaciones simétricas de Walker de 32 satélites cada

una. Cada satélite tiene un radio de cobertura de 3000 Km dividido en 6 haces fijos de 350

Km de radio. El bajo retardo en la trayectoria (típicamente 20 ms) de la constelación LEO

seleccionada para SkyBridge es compatible con el protocolo TCP/IP usado en las

aplicaciones terrestres.

El bajo retardo de los satélites LEO contribuye a tener enlaces con alta calidad de servicio,

similares a los usados en las redes terrestres asegurando su integración con las redes

terrestres.

El sistema SkyBridge es un sistema global de comunicaciones diseñado para proveer

usuarios residenciales y corporativos con aplicaciones multimedia interactivas tan buenas

como las ofrecidas por una red LAN o por las aplicaciones clásicas de la RDSI. El sistema

acomoda aplicaciones de tiempo real altamente interactivas ayudado por al bajo retardo

inherente al sistema.

SkyBridge puede usarse para conexiones de banda ancha asimétricas con la red fija,

mediante terminales residenciales, hasta de 60Mbps (en incrementos de 16 Kbps) en el


21

sentido downstream y hasta de 2 Mbps (en incrementos de 16Kbps) en el sentido upstream.

Velocidades mayores podrían ser alcanzadas mediante terminales profesionales. El diseño

del sistema es optimizado para las comunicaciones Internet, las cuales están caracterizadas

ráfagas de transmisión de datos asimétricos. Adicionalmente, el pequeño tamaño de los

incrementos provee a los usuarios con ancho de banda por demanda.

Los conceptos básicos de está arquitectura posicionan a SkyBridge dentro del campo de las

aplicaciones de tiempo real altamente interactivas tales como:

• Acceso a Internet de alta velocidad, servicios en línea.

• Comunicación con servidores corporativos y redes de área local, correo electrónico

y transferencia de archivos.

• Videoconferencia y videotelefonía

• Telemedicina

• Servicios de entretenimiento: video interactivo por demanda y juegos electrónicos.

SkyBridge ha sido diseñado para realizar reuso de frecuencias que estén siendo usadas por

otros servicios que operen en la misma banda, que incluye tanto sistemas geoestacionarios

así como sistemas terrestres.

Para mantener los niveles de interferencia bajos, se usan los siguientes métodos:

• Cuando un satélite entra en un zona no operativa vista desde una estación terrena de

SkyBridge, el rayo proveniente desde dicho satélite y que ilumina la zona bajo

consideración, es apagado y el tráfico es enviado a otro satélite de la constelación a

través de un procedimiento trasparente para el usuario final.

• La misma técnica se aplica para evitar interferencias desde las gateway de

SkyBridge o terminales hacia el terminal geoestacionario.


22

3.2. TELEDESIC

Teledesic inicialmente estaba formado por una red de 840 satélites ubicados en 21 planos,

sin embargo, está constelación fue rediseñada y quedo conformada por 288 satélites los

cuales serían ubicados sobre 12 planos. Finalmente, como parte del mejoramiento del

diseño de la red satelital, se definió una nueva constelación que permita proveer servicios

corporativos a un costo significativamente menor. Está nueva red estaría conformada por

un total de 30 satélites MEO, ubicados en 6 planos orbitales. Con sus primeros 12 satélites,

Teledesic se enfocará en proveer servicios corporativos críticos; cuando los 18 satélites

adicionales sean desplegados, La red Teledesic soportará un conjunto global, flexible y

eficiente de servicios de comunicaciones que van desde la telefonía básica hasta soluciones

empresariales, con el objetivo de proveer una alternativa asequible para prestar servicios de

voz y de datos de alta calidad a través del mundo.

La nueva red de órbita media reduce significativamente los normalmente largos retardos

que experimentan las redes de comunicaciones satelitales geoestacionarias y habilita el uso,

de pequeños equipos de usuario que envían y reciben datos, y que pueden ser conectados a

una red de computadores o a un PC.

Teledesic opera en el rango de frecuencia de la banda Ka del espectro de frecuencias (28.6

– 29.1 GHz para el uplink y 18.8 – 19.3 GHz para el downlink).


23

3.3. PARAMATROS DE LAS CONSTELACIONES

Un resumen de los principales parámetros que definen las constelaciones de SkyBridge y

Teledesic es mostrado en la Tabla No. 4.

Parámetro SkyBridge Teledesic*

Tipos de servicios Voz, datos, fax, video

Voz, datos, fax, video

Número de (sub) constelaciones 2 1 Número de satélites 64 288 Satélites/órbita 8/4 24/12 Altura (Km) 1457 1350 Inclinación (°) 53 98 Tipo de órbita Inclinada Polar Comunicación Intersatelital No Si Tipo de Cobertura EFC** EFC** Espectro de Frecuencia Ku Ka Tamaño de los canales 16 Kbps 16 Kbps Anchos de banda (Up/Down) 2/60 Mbps Número de canales de 16 Kbps -- 100000

Método de Acceso

CDMA, TDMA, FDMA, WDMA

MF-TDMA

* Los datos de está constelación fueros tomados a partir del diseño de 288 satélites, debido a que no se tiene datos acerca del último diseño donde se usarán 30 satélites MEO. **EFC (Earth Fixed Cell) Celdas Fijas en Tierra.

TABLA No. 4. PARÁMETROS DE LAS CONSTELACIONES


24

4. TIPOS DE TRÁFICO

Se han definido tres tipos de tráfico ha manejar dentro de las simulaciones, estos son: voz,

datos y video; los cuales representan los usos más comunes de una comunicación

multimedia. Dentro de ellos, también se ha delimitado su uso, es decir, para el tráfico de

datos este ha sido limitado a la transferencia de archivos de un tamaño promedio de 3MB y

para el tráfico de vídeo se estableció como uso principal el videochat o vídeos de baja

duración y calidad.

Los tiempos medios que se manejan en cada uno de los tipos de tráfico es diferente, y se

definieron de la siguiente manera:

1 Para el tráfico de voz, el tiempo medio es de 3 minutos como se ha trabajando en todas

las simulaciones anteriores, y que corresponde al estándar definido para este tipo de

tráfico.

2 Para el tráfico de datos se simulará la transferencia de archivos, para los cuales se tomo

como referencia la trasferencia de archivos de audio como mp3 que es uno de los usos

más frecuentes, sobretodo en la mayoría de los usuarios no comerciales. Estos archivos

son de un tamaño variable pero como se definió anteriormente se tomará un tamaño

promedio de 3 MB, en base a este tamaño y a la granularidad el sistema calculará el

tiempo medio de este tipo de tráfico.

3 El tráfico de vídeo, se analizará en base a videos de corta duración y baja calidad. En

este tipo de tráfico se definió un tiempo medio de 30 minutos.


25

5. SIMULACIONES

Para efectos de verificar y evaluar la herramienta de simulación desarrollada, se realizó una

simulación en la cual la tierra se dividió en 6 regiones iguales y sobre cada una de ellas se

simuló un tráfico de voz de 1500 Erlangs, durante un tiempo de simulación de 24 horas

(1440 minutos), con una duración promedio de llamada de 3 minutos. Lo que nos permitía

un tráfico total de 9000 Erlangs. Adicionalmente, este tráfico fue distribuido sobre 16

celdas en tierra de igual tamaño y con la misma carga de tráfico.

Como resultados de esta simulación, en cuanto a la verificación de la validez del simulador

se encontró lo siguiente:

• En la parte referente a la simulación simultanea se obtuvo una economía en tiempo,

basada principalmente en el hecho de que la generación de cada una de las bases de

datos podía ser realizada en aproximadamente 3 días. Se generaban 3 bases de datos

al mimo tiempo, para evitar sobrecargar la máquina SIE y bloquear a otros usuarios.

Por lo tanto, esta simulación se realizó en 6 días, que bajo otras condiciones

hubieran podido ser más de 10 días en un PC convencional.

• En la parte referente a la lectura de dichas bases de datos, no se sacrificó tiempo por

el hecho de realizar la lectura a partir de varias bases de datos, ya que en promedio

cada corrida del simulador para leer dichas bases de datos tardaba alrededor de 10

minutos, el cual es un tiempo relativamente bajo con respecto al tiempo de

generación de las mismas.

Como parte de las pruebas realizadas al simulador se realizaron varias corridas en las cuales

se variaban los parámetros de entrada de estas, para este caso se realizaron las siguientes

corridas: Simulación de distintas cargas de tráfico (6000, 6600, 7200, 7800, 8400 y 9000

Erlangs), además de variar el número de canales en el sistema (20, 40 500 y 1000 canales).

Estas pruebas fueron realizadas para dos casos, uno inicial en el cual el tiempo de Erlang C

era 0 segundos y otro en el cual este tiempo era igual a 10 segundos.


26

Los resultados de la simulación tomando el valor de Erlang C = 0 segundos, y realizando

las pruebas para diferentes valores de tráfico y de canales son mostrados en la Tabla No. 5.

TRAFICOCANALESNReg BReg HReg DReg EReg NGH BGH BGo BGc BGr HGH DGH EGH

6000 20 44420 38521 1554 1195 4639 45230 40467 39307 1160 0 395 4 46886000 40 44420 33921 2708 1800 8554 45230 36282 34601 1681 0 1049 9 88146000 500 44420 1341 10843 362 42249 45230 1548 1361 187 0 10933 0 431506000 1000 44420 0 11160 0 43952 45230 0 0 0 0 11397 0 446986600 20 49185 43199 1623 1299 4607 49560 44797 43671 1126 0 371 7 46986600 40 49185 38336 2809 1901 8789 49560 40358 38642 1716 0 957 24 90706600 500 49185 2254 11776 604 45748 49560 2495 2202 293 0 11481 0 465536600 1000 49185 0 12338 0 48606 49560 0 0 0 0 12294 0 490487200 20 53653 47669 1605 1274 4641 54063 49296 48085 1211 0 347 6 46917200 40 53653 42756 2861 1993 8768 54063 45052 43200 1852 0 940 21 88617200 500 53653 3434 12753 925 48706 54063 4028 3494 534 0 12017 0 494337200 1000 53653 0 13633 0 53064 54063 0 0 0 0 13427 0 534607800 20 57881 89873 85 5 5101 110953 85358 76020 1599 0 27 0 10717800 40 57881 81191 136 7 9661 110953 78453 68618 2579 0 65 0 20317800 500 57881 8449 638 0 55757 110953 9159 7335 1017 0 666 0 96947800 1000 57881 0 666 0 62429 110953 0 0 0 0 690 0 97778400 20 62419 56319 1671 1326 4695 62997 58096 56796 1300 0 326 5 48428400 40 62419 51066 2988 2168 9038 62997 53677 51582 2095 0 905 26 91738400 500 62419 6276 14258 1582 53850 62997 7154 6223 931 0 13262 0 551618400 1000 62419 6276 14258 1582 53850 62997 7154 6223 931 0 13262 0 551619000 20 66756 105357 93 5 5136 128142 99933 89020 1648 0 18 1 10589000 40 66756 96260 155 12 9798 128142 92817 81422 2675 0 62 0 19869000 500 66756 13779 719 0 61009 128142 14685 11654 1625 0 742 0 111089000 1000 66756 0 762 0 71937 128142 0 0 0 0 775 0 11250

TABLA No. 5. RESULTADOS DE LA SIMULACIÓN CON ERLANG C = 0 SEGUNDOS

Los resultados de la simulación tomando el valor de Erlang C = 10 segundos, y realizando

las pruebas para diferentes valores de tráfico y de canales son mostrados en la Tabla No. 6.

TRAFICOCANALESNReg BReg HReg DReg EReg NGH BGH BGo BGc BGr HGH DGH EGH

6000 20 44420 42555 129 113 686 45230 44475 44436 39 0 87 0 7336000 40 44420 40652 276 221 1443 45230 43618 43527 91 0 191 0 15736000 500 44420 142 10220 718 39985 45230 3623 3337 286 0 10203 0 410756000 1000 44420 0 11160 0 43952 45230 0 0 0 0 11396 0 446986600 20 49185 47335 121 107 666 49560 48775 48725 50 0 69 0 7656600 40 49185 45425 257 210 1427 49560 47944 47850 94 0 173 1 15776600 500 49185 794 10425 1004 41582 49560 6402 6085 317 0 10208 9 426376600 1000 49185 0 12338 0 48606 49560 0 0 0 0 12293 0 490487200 20 53653 51815 132 116 637 54063 53315 53262 53 0 70 0 7297200 40 53653 49904 264 214 1407 54063 52475 52369 106 0 166 1 15517200 500 53653 2036 10664 1181 42412 54063 9978 9575 403 0 10134 12 434727200 1000 53653 0 13633 0 53064 54063 0 0 0 0 13425 0 534607800 20 57881 97316 1 0 704 110953 91973 83708 56 0 2 0 3777800 40 57881 94070 6 0 1495 110953 90682 82462 105 0 6 0 8037800 500 57881 6892 550 0 46023 110953 22547 20392 527 0 591 0 95257800 1000 57881 0 666 0 62429 110953 0 0 0 0 690 0 97778400 20 62419 60557 134 121 659 62997 62274 62227 47 0 70 0 7088400 40 62419 58612 277 231 1447 62997 61501 61393 108 0 157 0 14528400 500 62419 6858 10363 1262 42953 62997 17883 17391 492 0 9986 4 444328400 1000 62419 0 15795 0 61706 62997 0 0 0 0 15776 0 623109000 20 66756 112906 2 0 677 128142 106488 96775 58 0 1 0 3649000 40 66756 109570 2 0 1472 128142 105240 95579 105 0 9 0 8119000 500 66756 0 762 0 71937 128142 0 0 0 0 775 0 112509000 1000 66756 0 12338 0 75236 49560 0 0 0 0 12293 0 49048

TABLA No. 6. RESULTADOS DE LA SIMULACIÓN CON ERLANG C = 10 SEGUNDOS


27

En estas tablas se observan los contadores de estado entregados por el sistema como

resultados estadísticos de cada una de las simulaciones realizadas, el significado de cada

uno de los contadores para los usuarios regulares es el siguiente:

- NReg: Número total de eventos generados para usuarios regulares.

- BReg: Número de llamadas bloqueadas para usuarios regulares.

- HReg: Número de handoffs del sistema para usuarios regulares.

- DReg: Número de llamadas perdidas por desvanecimiento para usuarios regulares.

- EReg: Número de llamada del tipo Erlang C generadas para usuarios regulares.

Y para los usuarios GH tenemos los siguientes contadores:

- NGH: Número de eventos generados para usuarios GH.

- BGH: Número de llamadas bloqueadas para usuarios GH.

- BGo: Número de llamadas bloqueadas en el origen para usuarios GH.

- BGc: Número de llamadas bloqueadas en el momento de la conexión para usuarios GH.

- BGr: Número de llamadas bloqueadas en el momento de la reserva para usuarios GH.

- HGH: Número de handoffs del sistema para usuarios GH.

- DGH: Número de llamadas perdidas por desvanecimiento para usuarios GH.

- EGH: Número de llamada del tipo Erlang C generadas para usuarios GH.

A continuación se muestran las gráficas obtenidas a partir de estos resultados, en la Figura

No. 5 vemos los resultados para los usuarios regulares con tiempo de Erlang C igual a O

segundos; en la Figura No. 6 vemos los resultados para los usuarios regulares con tiempo

de Erlang C igual a 1O segundos; en la Figura No. 7 vemos los resultados para los usuarios

GH con tiempo de Erlang C igual a O segundos; y en la Figura No. 8 vemos los resultados

para los usuarios GH con tiempo de Erlang C igual a 1O segundos.


28

6000 ERL - 44420 REGULARES

-5000

5000

15000

25000

35000

45000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg

6600 ERLANG - 49185 REGULARES

-10000

0

10000

20000

30000

40000

50000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg


-5000

5000

15000

25000

35000

45000

55000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg


29


-20000

0

20000

40000

60000

80000

100000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg


-5000

5000

15000

25000

35000

45000

55000

65000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg


-10000

10000

30000

50000

70000

90000

110000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg

FIGURA No. 5. USUARIOS REGULARES CON ERLANG C IGUAL A 0 SEGUNDOS


30

6000 ERL - 44420 REGULARES

-5000

5000

15000

25000

35000

45000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg


-10000

0

10000

20000

30000

40000

50000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg


-5000

5000

15000

25000

35000

45000

55000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg


31


-20000

0

20000

40000

60000

80000

100000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg


-5000

5000

15000

25000

35000

45000

55000

65000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg


-20000

0

20000

40000

60000

80000

100000

120000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BReg HReg DReg EReg

FIGURA No. 6. USUARIOS REGULARES CON ERLANG C IGUAL A 10 SEGUNDOS


32

6000 ERL - 45230 GH

-10000

0

10000

20000

30000

40000

50000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S

BGH BGo BGc BGr HGH DGH EGH

6600 ERL - 49560 GH

-10000

0

10000

20000

30000

40000

50000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S


7200 ERL - 54063 GH

-10000

0

10000

20000

30000

40000

50000

60000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S



33

7200 ERL - 54063 GH

-10000

0

10000

20000

30000

40000

50000

60000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S


8400 ERL - 62997 GH

-10000

0

10000

20000

30000

40000

50000

60000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S


9000 ERL - 128142 GH

-20000

0

20000

40000

60000

80000

100000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S


FIGURA No. 7. USUARIOS GH CON ERLANG C IGUAL A 0 SEGUNDOS


34

6000 ERL - 45230 GH

-10000

0

10000

20000

30000

40000

50000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S


6600 ERL - 49560 GH

-10000

0

10000

20000

30000

40000

50000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S


7200 ERL - 54063 GH

-10000

0

10000

20000

30000

40000

50000

60000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S



35

7800 ERL - 110953 GH

-20000

0

20000

40000

60000

80000

100000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S


8400 ERL - 62997 GH

-10000

0

10000

20000

30000

40000

50000

60000

70000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S


9000 ERL - 128142 GH

-10000

10000

30000

50000

70000

90000

110000

0 100 200 300 400 500 600 700 800 900 1000

NUMERO DE CANALES

NU

ME

RO

DE

EV

EN

TO

S


FIGURA No. 8. USUARIOS GH CON ERLANG C IGUAL A 10 SEGUNDOS


36

Al analizar estas gráficas se observa que al tomar el tiempo de Erlang igual a 10 segundos,

la probabilidad de bloqueo de llamadas disminuye, especialmente en los casos donde se

tiene un número menor de canales por satélite. Igualmente el efecto de Erlang C, también

se ve en el número de Handoffs de los usuarios, ya que este valor también disminuye con

respecto al valor obtenido cuando Erlang C es igual a 0 segundos. Finalmente, el número de

eventos perdidos por desvanecimiento también es menor, sin embargo, este no es muy

apreciable ya que sus valores generalmente son muy cercanos al cero.


37

2. CONCLUSIONES

• Los sistemas de órbita baja como Iridium, Globalstar e ICO desarrollados

recientemente apuntan principalmente a satisfacer las necesidades de un segmento

muy reducido del mercado que requiere contar con un sistema de comunicación que

les garantice el acceso telefónico sin importar su ubicación geográfica. Existe otro

grupo de proyectos más ambiciosos como Teledesic y SkyBridge, que pretenden

implementar redes satelitales con capacidad de permitir el acceso de los usuarios

con grandes anchos de banda, de tal forma que puedan disfrutar de toda la gama de

servicios de telecomunicaciones como son la transmisión de voz, datos y video.

• La cantidad de eventos nuevos generados dada la introducción de los otros dos tipos

de tráfico (vídeo y datos), produce una mayor ocupación de memoria creando

invasiones de los datos. Por lo tanto, fue necesario modificar el software para que

las variables que almacenan los contadores de estado y de desempeño del sistema,

fueran almacenadas en archivos y no en memoria como se venía realizando.

• Como resultados de las simulaciones se observa, que efectivamente se logró una

mejoría en los tiempos de simulación, especialmente en la generación de las bases

de datos cuando se realiza la simulación simultanea. Además, el tiempo de Erlang C

permite mejorar el desempeño del sistema, ya que al variar este parámetro se puede

disminuir el número de bloqueos que se presentan.

• El simulador desarrollado, será una buena herramienta que contribuirá al análisis del

desempeño de este tipo de redes satelitales, así como la viabilidad de los proyectos

en desarrollo actualmente. Además, dada su capacidad de manejar diferentes tipos

de tráfico, se podrán analizar las aplicaciones más adecuadas para este tipo de

sistemas satelitales.


38

• Posteriormente, este software podrá ser adaptado a nuevos tipos de tráfico, o

diferentes calidades de los tráficos existentes, es decir, se podrá adaptar por ejemplo

hacia video en tiempo real o aplicaciones de datos que utilicen anchos de banda

diferentes a los de las aplicaciones tomadas como referencia.

Trabajos Futuros: los estudios analíticos pueden extenderse a las condiciones reales de las

constelaciones Teledesic y SkyBridge (carga de tráfico, tipo de tráfico y capacidad de

canales). Actualmente se está probando y afinando la herramienta de simulación, con la

finalidad de validar los modelos analíticos.


39

3. BIBLIOGRAFIA

• Mosquera O. 1999. Los satélites de orbita baja. Proyecto Observatorio.

• P. Suárez. 2000.Primer reporte trimestral de noticias referentes al sector de las

comunicaciones por satélite.

• Restrepo J. & Maral G. 1998. Aspectos generales de las constelaciones de satélites no

geoestacionarios. Parte I: Fundamentos de órbitas y coberturas. Revista Colombiana de

Telecomunicaciones, CINTEL, Vol. 5. No. 14.

• Restrepo J. & Maral G. 1998. Aspectos generales de las constelaciones de satélites no

geoestacionarios. Parte II: Dimensionamiento y comparación de constelaciones. Revista

Colombiana de Telecomunicaciones, CINTEL, Vol. 5. No. 15.

• Restrepo J. & Maral G. 1998. Extended analytical model for calculating the quality of

service (QOS) in a mobile satellite systems (MSS) with a guaranteed handover (GH)

service.

• Restrepo J. & Maral G. 1998. Performance analysis for a guaranteed handover service

in a LEO constellation with a “Satellite-fixed cell” system.

• Restrepo J. & Maral G. 1999. Comunicaciones móviles basadas en constelaciones de

satélites no geoestacionarios (MSS). Revista Colombiana de Telecomunicaciones,

CINTEL. Vol. 6. No. 18.

• Restrepo J. & Maral G. 2000. Enhanced service in non-geo constellation with satellite-

fixed cell (SFC).

• Restrepo, J. 2000. Servicio mixto fijo y móvil en sistemas móviles por satélites no

geoestacionarios. Colciencias – Ministerio de Comunicaciones.

• Restrepo J. & Maral G. 2000. Several applications of guaranteed handover (GH) service

in mobile satellite system (MSS).

• Restrepo J., Maral G & Massy G. 2001. NON-GEO satellite constellation simulator:

services and scenarios, software tool architecture and validation.


40

• Restrepo J., Maral G., Massy I., Castillo J. 2002. Simulador de constelaciones

satelitales multimedia Non-GEO: Arquitectura del software, servicios, escenarios y

validación.

• www.iridium.com

• www.globalstar.com

• www.ico.com

• www.teledesic.com

• www.skybridgesatellite.com

simulaciÓn de sistemas multimedia sobre sistemas

Documents