Embed Size (px)
Citation preview
PROYECTO DE GRADO
Presentado a:
UNIVERSIDAD DE LOS ANDES,FACULTAD DE INGENIERÍA,
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
Para obtener el título de:
INGENIERO ELECTRÓNICO
Por:
Julián David Villegas Gutiérrez
Simulación de una red celular con tecnología HSDPA para verificar los parámetros de desempeño
Asesor: Roberto Bustamanete Miller, Profesor asociado, Universidad de los Andes.
1
ÍNDICE GENERAL
ÍNDICE GENERAL.................................................................................................................................2 1 LISTADO DE ACRÓNIMOS...............................................................................................................4 2 INTRODUCCIÓN................................................................................................................................5
2.1. Introducción y justificación.......................................................................................................52.2. Objetivos generales....................................................................................................................62.3. Objetivos específicos.................................................................................................................62.4. Alcance......................................................................................................................................6
3 CARACTERÍSTICAS DE PROPAGACIÓN DE ONDAS DE RADIO..............................................73.1. Mecanismos de propagación......................................................................................................73.2. Pérdidas de propagación............................................................................................................7
3.2.1 Pérdidas por camino (Path loss)...................................................................................8 3.2.2 Desvanecimiento lento (Shadowing)...........................................................................9 3.2.3 Desvanecimiento rápido (Fast Fading)........................................................................9
3.3. Interferencia ............................................................................................................................10 4 CARACTERÍSTICAS BÁSICAS DE UMTS....................................................................................10
4.1. Fundamentos de WCDMA......................................................................................................104.2. Arquitectura de protocolos.......................................................................................................12
4.2.1 Capa MAC..................................................................................................................12 4.2.2 Capa RLC...................................................................................................................13 4.2.3 Stack IP/TCP de la capa de Red.................................................................................14
4.3. Algoritmos de manejo de los recursos de radio (RRM)..........................................................144.4. Algoritmos de planificación (Scheduling)...............................................................................144.5. Canales lógicos y de transporte...............................................................................................154.6. Canales físicos.........................................................................................................................164.7. Provisión de QoS.....................................................................................................................17
5 CARACTERÍSTICAS BÁSICAS DE HSDPA..................................................................................185.1. El nuevo canal común..............................................................................................................185.2. Rápida adaptación del enlace...................................................................................................185.3. HARQ......................................................................................................................................19
6 CARACTERÍSTICAS DE SIMULACIÓN........................................................................................196.1. Elección y características del simulador..................................................................................196.2. Características del módulo EURANE.....................................................................................206.3. Topología de estudio................................................................................................................206.4. Estructura física e interfaz Au..................................................................................................226.5. Filosofía y algoritmo de simulación........................................................................................24
6.5.1 Archivos de pre-procesamiento..................................................................................27 6.5.2 Archivos de post-procesamiento................................................................................29
7 MODELO DE TRÁFICO...................................................................................................................327.1. VoIP.........................................................................................................................................327.2. Streaming (Video)....................................................................................................................347.3. Web .........................................................................................................................................35
7.3.1 Modelo de Choi..........................................................................................................37 7.3.2 Modelo simplificado de Choi.....................................................................................39
8 RESULTADOS DE CAPACIDAD.....................................................................................................41
2
8.1. Capcidad de VoIP.....................................................................................................................418.2. Capacidad de Video.................................................................................................................458.3. Aplicaciones de Web Browsing...............................................................................................47
8.3.1 Modelo Choi inicial....................................................................................................47 8.3.2 Modelo Choi simplificado..........................................................................................49
9 COBRO POR EXTRALIMITACIÓN................................................................................................51 10 MEJORAS FUTURAS.....................................................................................................................54 11 CONCLUSIONES............................................................................................................................54 12 BIBLIOGRAFÍA..............................................................................................................................55 13 ANEXO A. CÓDIGO BASE TCL....................................................................................................57 14 ANEXO B. CÓDIGO PERL RETARDO..........................................................................................61
3
1 LISTADO DE ACRÓNIMOS
BS Estación base
UE User Equipment, Terminal
IP Internet Protocol
TCP Transport Control Protocol
DL Downlink
UL Uplink
3GPP Third Generation Partnership Project
QAM Quadrature Amplitude Modulation
QoS Quality of Service
UHF Ultra High Frecuency
HSDPA High Speed Downlink Packet Access
UMTS Universal Mobile Telecommunications System
FDD Frecuency Division Duplexing
TDMA Time Division Multiple Access
FDMA Frecuency Division Multiple Access
WCDMA Wideband Code Division Multiple Access
ADSL Asymmetrical Digital Subscriber Line
TTI Time to Transmision Interval
DS-SS Direct Secuence Spread Spectrum
FACH Forward Access Channel
RACH Random Access Channel
HS-DSCH High Speed Downlink Shared Channel
DCH Dedicated Channel
DPDCH Dedicated Physical Data Channel
DPCCH Dedicated Physical Control Channel
KPI Key Performance Indicator
4
2 INTRODUCCIÓN
2.1. Introducción y justificación
El propósito inicial de las redes celulares fue el de brindar servicios básicos de voz. Sin embargo,
mientras aparecían los primeros operadores con licencia para usar el espectro alrededor de los 90,
otorgando servicios de voz a los usuarios, se empezaba a investigar paralelamente sobre un sistema
móvil capaz de otorgar velocidades de conexión del orden de Mbps. La idea era que así se podrían
brindar otro tipo de servicios al usuario que fueran atractivos y quizá medianamente comparables (en
términos de desempeño) a los usados en los sistemas de banda ancha (ADSL) tradicional. Así surge un
proceso de investigación para desarrollar un sistema de radio capaz de brindar estas características de
conexión y al mismo tiempo tratar con la interfaz del aire, medio hostil a través del cual se propagan las
ondas en discusión.
La perspectiva actual es que los usuarios pueden usar servicios sobre protocolos de red (como IP/TCP)
que no solo compiten con el servicio de banda ancha, sino que en algunos casos lo superan, en términos
de tasas de transferencia. El surgimiento de nuevas técnicas de modulación, como 16 QAM y 64 QAM,
añadido a técnicas sofisticadas de retransmisión que permiten reducir los retardos entre BS y UE,
además de la demanda exponencial de servicios de “gamming”, “video streaming” y “web browsing”
entre otros, posibilitó que operadores de redes celular, migraran hacia tecnologías 3G pese al alto costo
de licencias y de instalaciones.
Las velocidades de conexión (al 2010 [HOL_10, p. 5]) son de 14 Mbps en el DL y de 5.76 Mbps en el
UL, de acuerdo con la Release 6 de la 3GPP. Esto hace que la capacidad de la red sea un parámetro
crítico de planeación para que no disminuya el desempeño de las aplicaciones que los usuarios están
corriendo. Además, el plan de tarificación que se le presenta al usuario es un modelo “plano” (flat,
[HOL_10, pp. 11-32], lo que quiere decir que al igual que en los sistemas de banda ancha, al usuario ya
no se le cobra por minuto consumido, sino que se le propone un límite de descargas mensual. Desde el
punto de vista del operador de red esto es altamente incoveniente: no solo porque la red es fácilmente
susceptible de saturarse, debido al gran número de usuarios que hacen uso de ella con aplicaciones de
alta demanda de recursos de radio (como “video streaming”, “gamming”), sino porque no es rentable
económicamente. Es por eso que es deseable conocer el número máximo de usuarios que se pueden
soportar por cada aplicación de alta demanda, para idear planes de tarificación que penalicen a aquellos
usuarios que utilizan las aplicaciones que más demanda requieren de la red de forma ilimitada.
Bajo estas características, este documento plantea un acercamiento a este plan de tarificación, basado
en simulaciones de una topología estándar de una red celular para conocer la capacidad de una celda en
términos de número de usuarios soportados por aplicación para un umbral de QoS requerido.
5
2.2. Objetivos generales
• Profundizar en el conocimiento de redes celulares con tecnología HSDPA.
• Profundizar en el conocimiento de herramientas de simulación de código abierto como el
software NS2 y el módulo de HSDPA EURANE.
• Identificar características de red (tasas de transferencia, retardos del enlace, etc...) o del modelo
de propagación de radio que determinan el desempeño de aplicaciones que se corren sobre
terminales con tecnología HSDPA.
2.3. Objetivos específicos
• Diseñar el modelo de tráfico de las aplicaciones del dominio PS.
• Obtener la capacidad por celda por aplicación, en términos de número de usuarios, para un
perfil de usuario, y una topología física y lógica de red dada.
• Diseñar un esquema simple de cobro de recargos, para usuarios que se extralimiten en el uso de
cada aplicación.
2.4. Alcance
Este proyecto usa modelos de tráfico ampliamente divulgados por la comunidad científica para realizar
simulaciones bajo diferentes escenarios de redes con tecnología UMTS-HSDPA. Tiene el propósito de
ser un acercamiento más cualitativo que cuantitativo (aún cuando se presentan resultados
cuantitativos), a la manera en como se determina la capacidad de una celda para que la QoS de ciertas
aplicaciones (del dominio PS) no se deterioren. No debe ser visto como un proyecto que propone
modelos de tráfico (solo ofrecemos una simplificación de un modelo web usado ampliamente). No debe
ser visto como un proyecto en el que se realice un estudio económico para determinar la tarifa mensual
que se le cobra a un usuario. Se simulan los escenarios determinados por las características que se
exponen en la sección 7.5 del presente documento.
El límite de usuarios que se puedan simular estará determinado por los límites que el sistema operativo
y el hardware usado impongan. Los scripts de simulación (archivos .tcl), las trazas obtenidas
(archivos .tr), scripts en perl y awk (archivos .pl y .awk), scripts en bash para acelerar las
simulaciones en el SO usado (Ubuntu) (archivos .sh), y los archivos de texto que arrojan los scripts de
matlab, perl y awk son el único documento físico (digital en este caso) que se tiene, ya que este
proyecto no propone la creación de un dispositivo electrónico o algo parecido.
6
3 CARACTERÍSTICAS DE PROPAGACIÓN DE ONDAS DE RADIO
3.1. Mecanismos de propagación
Las ondas de radio se dice que se propagan a través de un medio. El medio evidente en este caso es el
aire. El caso ideal de propagación es el de un medio sin obstáculos, que se conoce como “espacio libre”
[PRAKASH_11, p. 59]. El otro caso, más común en la práctica, es el de un medio donde existen
obstáculos y por ende la propagación de las ondas de radio tiene otro comportamiento. El
comportamiento de dichas ondas depende de la longitud de la onda, o en otros términos, de la
frecuencia de la misma. Las tecnologías celulares 2G (900 MHz) y 3G (1.8-2.1 GHz) están en la banda
de frecuencia UHF (300 MHz-3GHz), lo que da una longitud de onda del orden de (1m-10cm).
Dependiendo de este parámetro existen tres tipos fundamentales de comportamientos en la
propagación:
• Reflexión: La onda golpea contra una superficie que es comparativamente mayor a su longitud.
En este caso dicho objeto puede ser un edificio, la superficie de la tierra, etc...
• Difracción: El camino de propagación entre el transmisor y el receptor es obstaculizado por un
objeto con una superficie con bordes altamente irregulares.
• Dispersión: La onda golpea con un objeto de menor tamaño (un poste tal vez, los andenes de
una calle, etc...) al de su longitud y por ende se “desintegra” en varias ondas con menor energía
que la original.
Una completa explicación de los mecanismos de propagación puede ser hallada en [RAPPA_02, pp.
78-102].
3.2. Pérdidas de propagación
En un modelo de propagación es indispensable establecer una relación entre la potencia recibida, la
potencia transmitida y cierto componente de pérdidas debido a los factores mencionados anteriormente,
y a otros que ya mencionaremos. El comportamiento de la potencia recibida obedece a la estructura de
la Ecuación 1 [PRAKASH_11, p. 62].
Donde Gt y Gr son las ganancias de las antenas transmisora y receptora, respectivamente. Pt, es la
potencia de transmisión, mientras que L es el término de pérdidas de la propagación. El término de
pérdidas de propagación se puede descomponer en tres términos, como lo muestra la Ecuación 2.
7
Pr=Gt∗Gr∗Pt
L(1 )
L = LP∗LS∗LF (2 )
Los tres términos son: pérdidas por el camino de propagación (Lp), pérdidas por desvanecimiento lento
o shadowing (Ls) y pérdidas por desvanecimiento rápido (Lf). Si la Ecuación (2) se expresa en dB,
obtenemos una expresión lineal para las pérdidas totales. Las pérdidas por el camino de propagación a
menudo están determinadas por parámetros como la distancia (gran distancia) entre emisor y receptor,
la frecuencia de la onda, y el perfil del lugar donde se realiza la propagación. Se dice que este tipo de
pérdidas son a gran escala dado que se evalúan durante distancias amplias, que por ende implican
tiempos del orden de segundos. Pérdidas por shadowing son a una menor escala (decenas de metros) y
las pérdidas por desvanecimiento rápido son a una escala mucho menor. A menudo estas dos últimas
son trabajadas estadísticamente, y se deben a retardos de las ondas por reflexión, difracción y
dispersión, entre otros.
3.2.1 Pérdidas por camino (Path loss)
Las pérdidas por los caminos que toman las ondas, pueden ser modeladas de diferentes maneras. El
modelo Okumura-Hata es normalmente usado [PRAKASH_11, p. 63]. El modelo usado en esta tesis,
en los scripts de pre-procesamiento que se dan a cada usuario, es el presentado en [RAPPA_02, p. 70] y
conocido como modelo lognormal. Ya sea un modelo analítico o empírico el que se use, siempre se
llega a una relación inversa logarítmica entre las pérdidas de potencia por el camino de propagación y
la distancia entre transmisor y receptor. La Ecuación 3 describe las pérdidas por camino de
propagación:
PL(do) son las pérdidas promedio a una distancia base respecto de la antena transmisora, n es el
exponente de pérdidas por camino de propagación (este parámetro se variará durante la simulación, ver
Sección 7) durante la s y Xs es una variable aleatoria gaussiana con media cero (en dB) y desviación
estándar s (en dB). La variable aleatoria asegura que para varias distancias iniciales do iguales pero
ubicadas en sitios con características distintas (edificios en uno y en otro no, tal vez) las diferencias en
las pérdidas por caminos de propagación distintos, no difieran mucho, haciendo así al modelo
analíticamente consistente.
La Tabla 1 presenta algunos valores del exponente de pérdidas por camino de propagación, para
diferentes tipos de ambientes:
8
PL (d ) [ dB ] = PL (d0 ) + 10nlog( dd0
) + X s (3 )
Tabla 1. Valores del path loss exponent para diferentes ambientes.
3.2.2 Desvanecimiento lento (Shadowing)
El desvanecimiento rápido y lento, toma el nombre de fading en la literatura. Corresponde a pérdidas
de propagación en intervalos de distancia mucho más pequeños que el modelo anterior. El fenómeno
corresponde a variaciones aleatorias en la amplitud, para intervalos de tiempo y/o espacio muy
pequeños. El desvanecimiento es causado por la interferencia entre dos o más versiones de la misma
señal que llegan al receptor en tiempos diferentes debido a los mecanismos de propagación
[RAPPA_02, p. 139]. Las versiones retardadas de la onda original (y variables en amplitud y potencia)
se denominan ondas “multi-caminos” (multipath). Estas ondas se combinan en el receptor para producir
una onda superpuesta que tiene un perfil de retardos variable y amplitudes necesariamente aleatorias y
diferentes de la onda transmitida. En el módulo de EURANE este parámetro está implementado a
través de métodos sofisticados de cálculo del espectro Doppler y otras cantidades. El parámetro que se
puede ajustar es el de la desviación estándar de la variable aleatoria que modela el shadowing, dicho
valor se presenta en la sección 7.5.1.
3.2.3 Desvanecimiento rápido (Fast Fading)
El desvanecimiento es causado principalmente por [RAPPA_02, p. 140]:
• Cambios rápidos en la potencia de la señal, en cortos intervalos de tiempo o espacio.
• Modulación de frecuencia aleatoria, debida a los desfases Doppler de las señales que llegan por
diferentes caminos.
• El efecto de los retardos de propagación que causan dispersión temporal.
Este tipo de pérdidas se modelan a través de variables aleatorias de Rayleigh, y a menudo tienen en
cuenta la frecuencia de operación como un factor determinante. Algunas variables que se tienen en
cuenta son [PRAKASH_11, p. 71]:
9
• La tasa de fading, que indica el número de veces que la señal pasa a través del punto medio de
la variable aleatoria de Rayleigh. Este parámetro está relacionado con la velocidad del terminal
y la frecuencia de la portadora.
• Profundidad del fading, que indica el cociente entre el el valor cuadrático medio de la señal, y el
valor mínimo de la señal.
• Duración del fading, que indica el tiempo durante el cual la señal de fading se encuentra debajo
de cierto umbral especificado.
3.3. Interferencia
El concepto de interferencia es inevitable debido a la reutilización de la frecuencia, es decir, a
transmisiones en diferentes bandas de frecuencia. Existen numerosos tipos de interferencia que se
pueden distinguir: interferencia por bandas de otros operadores, interferencia por presencia simultanea
de varias tecnologías (HSDPA, GSM, LTE eventualmente), interferencia debida a las celdas de las que
no se quiere recibir información, interferencia debida a canales de radio que no se quieren “escuchar”,
que están siendo utilizados por otros usuarios. En [PRAKASH_11, p. 73] se exponen diversos tipos de
interferencia; en [TSE_05, p. 126] se describe matemáticamente -de manera breve- el impacto de reusar
la frecuencia en el desempeño de sistemas WCDMA.
En EURANE se emula el comportamiento de la interferencia a través de 2 parámetros: la interferencia
al interior de la celda (es decir, en el DL), la interferencia que generan celdas vecinas. Este parámetro
tiene un impacto en la forma como se calcula el SNR y por ende en el CQI que el UE envía a la BS, lo
que implica que la forma en que el terminal es servido (por el planificador) es altamente sensible de la
interferencia experimentada por cada terminal.
4 CARACTERÍSTICAS BÁSICAS DE UMTS
4.1. Fundamentos de WCDMA
El concepto de acceso al recurso de radio es fundamental para el desempeño adecuado de
características de retardo, jitter y tasa de transferencia. La idea de repartir el recurso de radio (ancho de
banda) entre los usuarios dividiendo el ancho del canal entre el número de usuarios se llama FDMA. La
técnica que hace lo propio pero dividiendo el tiempo entre el número de usuarios se denomina TDMA.
10
Una técnica diferente a esas dos y novedosa se denomina CDMA, y utiliza códigos binarios
ortogonales para asignar los recursos de radio a los usuarios. La diferencia entre las 3 técnicas se
aprecia en la Figura 1.
Figura 1. Diferentes técnicas de acceso múltiple.[LAI_06, p. 20]
Las técnicas CDMA hacen uso de señales de repartición del espectro (spread spectrum signals) para
asignar un mismo canal a varios UE. La idea es asignar códigos que tengan una muy baja correlación-
cruzada (crosscorrelation), es decir, que sean semi-ortogonales, para que en el proceso de
demodulación de la señal codificada, la correlación-cruzada de las señales recibidas de varias fuentes,
sea mínima [LAI_06, p.20].
Una de las ventajas de este tipo de técnicas es su robustez ante la interferencia de banda angosta, lo que
tiene una implicación en el proceso de mejoramiento del SIR, por la presencia de la “ganancia de
procesamiento”.
Para realizar el spreading de una señal se utilizan numerosas técnicas, una de ellas, -quizá la más
usada-, es la de DS-SS. El proceso es el siguiente:
• La señal a transmitir sigue el proceso de modulación digital que se esté usando (QPSK,
16QAM, OFDM).
• Luego, se vuelve a pasar por otro proceso de “modulación” pero esta vez a través de una señal
repartidora del ancho de banda (wideband spreading signal) que es portadora de código
denominado “código de canalización” (channelization code). Este código es OVSF y se
construye a través de la matriz de Hadamard.
• Después esta señal modulada se pasa por un proceso de scrambling en el que se utiliza una
secuencia semi-aleatoria denominada scrambling code.
El coeficiente de repartición (spreading factor) hace referencia al número de chips que existirán por
símbolo de datos. La tasa de transferencia de chips es de 3.84Mcps. Es necesario que la red planifique
la entrega de códigos de manera óptima pues solamente se pueden usar 512 scrambling codes en el DL.
11
4.2. Arquitectura de protocolos
La arquitectura de protocolos de una red UMTS, define las características de transmisión de la
información, al menos desde un plano lógico. Los protocolos o capas se pueden clasificar dentro de 2
grandes grupos: protocolos o capas del plano de control y protocolos o capas del plano del usuario. En
algunos casos, los protocolos hacen parte de ambos grupos, por lo que la clasificación no es intensiva.
En las Figuras 2 y 3, se muestran una arquitectura típica de protocolos.
Figura 2. Ejemplo de Arquitectura de protocolos UMTS del plano de control. [LAI_06, p. 31]
Figura 3. Ejemplo de Arquitectura de protocolos UMTS del plano del usuario. [LAI_06, p. 31]
Los protocolos más relevantes para los propósitos de esta tesis son: MAC, RLC y TCP.
4.2.1 Capa MAC
La capa MAC se encargará de (3GPP TS 25.321 v6.7.0):
• Mapeo de entre canales lógicos y canales de transporte.
• Elección de un formato de transporte (transport format) apropiado para cada canal de transporte
dependiendo de la tasa de transferencia instantánea de la fuente.
• Programación dinámica de UE con el fin de usar eficientemente los recursos de espectro.
• Identificación de UE en los canales compartidos.
• Multiplexación o demultiplexación de PDUs (Packet Data Unit) de capas superiores de o
desde conjuntos de bloques de transporte que se envían hacia o desde la capa física en canales
dedicados o compartidos de transporte.
12
• Medición de la cantidad de tráfico presente en los canales lógicos. Esta información es
notificada al protocolo RRC donde se toman decisiones de conmutación.
• Cifrado de paquetes para el modo TM del RLC.
• Conmutación de canales de transporte. Se debe asignar un canal de transporte adecuado para
cada UE de acuerdo con las características de radio disponibles y las aplicaciones usadas por el
UE.
4.2.2 Capa RLC
La capa RLC se encargará de (3GPP TS 25.322 v6.6.0):
• Segmentación y Reensamblado.
• Concatenación.
• Chequeo de secuencia de número.
• Detección y corrección de errores.
• Cifrado.
• Descarte de SDUs.
• Relleno de redundancia.
• Control de flujo.
Más importante es el modo de operación de la capa RLC. Tiene 3 modos de operación: TM, AM y UM,
pero solo AM y UM son soportados por EURANE. El modo de operación cumple el papel de un
protocolo de red pero a un nivel más bajo, lo que asegura que el número de retransmisiones se
disminuya y que el retardo producido por las mismas sea menor también. El modo de operación que se
utilice depende también del tipo de aplicación. En la Figura 4 se muestra un ejemplo de los modos RLC
dependiendo de la clase de QoS que se requiera en la aplicación.
Figura 4. Modos RLC para diferentes clases de QoS.
13
4.2.3 Stack IP/TCP de la capa de Red
El protocolo TCP de la capa de red se encargará de:
1. Una conexión confiable entre entidades iguales (peers), es decir, un canal lógico que garantice
la entrega de paquetes a través de retransmisiones si es necesario.
2. Segmentación y redundancia para paquetes grandes y pequeños.
3. Junto con el protocolo IP, realiza el proceso de enrutamiento de paquetes hacia las direcciones
IP fuente, a través de métodos de optimización de rutas (que se realizan en switches y routers).
4.3. Algoritmos de manejo de los recursos de radio (RRM)
El manejo de los recursos de radio es indispensable para un desempeño de red eficiente. El algoritmo
de ubicación de recursos se refiere a la funcionalidad que otorga potencia y códigos de canalización
(channelization codes) al Node B para transmisión de datos en HSDPA en cada celda. El algoritmo de
admisión de control es nuevo respecto al de la Release 99, debido a que este último estaba pensado
para un canal dedicado (DCH), mientras que la Release 5 está pensado para un canal compartido (HS-
DSCH). El algoritmo de manejo de movilidad también ha variado respecto a su versión en la Release
99, dado que la información solo se transmite desde una celda hacia el UE cada intervalo de tiempo, y
el manejo del almacenamiento efectivo en los buffers del Node B es necesario cada vez que existe un
proceso de Handover (tema que discutiremos más adelante). Cada uno de los algoritmos mencionados,
están explicados con detalle en [HOL_06]. En este estudio no son de particular interés los algoritmos
(como los ubicados en el RNC – excepto el Resource Allocation-, y el HS-SCCH Power Control
ubicado en el Node B) que ejecutan instrucciones de control dado que estas funcionalidades no están
soportadas por el módulo EURANE, y en este estudio no se pretende estudiar el comportamiento
integral de la red en cuanto esta depende de los procesos de señalización.
4.4. Algoritmos de planificación (Scheduling)
Eurane soporta tres algoritmos de planificación: Round robin (RR), Maximum C/I scheduling, Fast
dependent channel scheduling. El planificador es dependiente del operador, lo que quiere decir que
cada operador puede desarrollarlo por su cuenta con base en sus estudios. El planificador es crítico para
un buen desempeño de las aplicaciones que el usuario está corriendo en el terminal. Esto se debe a que
el canal HS-DSCH es un recurso compartido, por lo que se requiere determinar una forma para que
todos los usuarios puedan acceder a este recurso. Cada TTI (2ms en HSDPA) puede cambiarse el
usuario que está transmitiendo. La idea es identificar cuánto tiempo un usuario accede a ese recurso, y
cada cuanto lo realiza.
Una descripción breve de cada uno se presenta:
• El planificador RR es uno que se caracteriza por asignar a cada usuario el mismo tiempo de
14
acceso al recurso compartido, y por atender sin exclusión alguna a todos los UE. Este se dice
que es un algoritmo “justo” (fair), pero es ineficiente desde el punto de vista de consumo de
potencia. Esto es así porque RR no tiene en cuenta las condiciones del medio, entonces, para UE
que estén en malas condiciones aún así les asignará recursos sabiendo que esto llevará seguro a
numerosas retransmisiones y por ende retardos mayores; además como consecuencia de lo
anterior, UE que tienen buenas condiciones van a ser servidos poco tiempo.
• El planificador Maximum C/I evalúa las condiciones en las que se encuentra cada UE y sirve a
aquellos que tienen las mejores condiciones. Este planificador maximiza el ancho de banda de
la celda, pero es muy “injusto” dado que aquellos UE que se encuentran en el borde de la celda
nunca van a ser atendidos.
• El planificador Fair Channel Dependent (FCDS) es un algoritmo que trata buscar un
compromiso entre los planificadores anteriores. Este algoritmo está gobernado por ecuaciones
de flujo sofisticadas que están explicadas en [EUDAT_03, pp. 64-77]. El parámetro “alpha” de
este planificador es un coeficiente de peso que determina de que lado está el planificador, es
decir, si es más RR o más Maximum C/I (0 y 1, respectivamente).
4.5. Canales lógicos y de transporte
El concepto de canal es fundamental para entender la dinámica de señalización y flujo de datos de una
red UMTS-HSDPA. El canal de comunicaciones en su concepción más básica es el del portador de una
frecuencia de operación. Para las redes UMTS-FDD se utiliza una frecuencia portadora para el UL, y
otra frecuencia portadora para el DL. Estas frecuencias se reutilizan en todas las celdas [TSE_05, p.
122] y tienen un impacto preponderante sobre el SNR, SIR y el SNIR que existe en cada celda
[TSE_05, pp. 127-129] – especialmente sobre celdas con tecnología WCDMA-.
Sin embargo, el concepto de canal que usamos en esta sección es el de un portador de información, tal
que la información se ordena y clasifica dependiendo del tipo de canal. Los canales físicos, son los que
se encargan de transportar la información vista como “datos en bruto”. Algunos de los canales más
importantes son:
• RACH: Es un canal de subida de datos utilizado tanto para control de información
(señalización) como para tráfico. En el caso de información de tráfico, no soporta cantidades
altas de información dada la tasa relativamente baja de transferencia.
• FACH: Es un canal compartido de descarga de datos que puede servir para señalización o
tráfico invariablemente. En el caso de tráfico de datos, nunca es utilizado para servicios del
dominio CS (como una llamada de voz) en los que se requiere un ancho de banda dedicado; en
el caso de tráfico de datos del dominio PS, es decir llamadas de datos, se utiliza cuando la
información a descargar no es suficientemente alta y no tiene exigencias de ancho de banda
importantes, es decir, que en últimas, se utiliza para las clases de QoS, Background e
Interactive.
15
• DCH: Es un canal dedicado (es decir, en el cual se establece una comunicación punto a punto
entre el Node B y el UE) que puede usarse tanto para el enlace de descarga, como para el de
subida. Este canal es usado para servicios de voz o para aplicaciones que requieren un ancho de
banda dedicado e inmutable durante el tiempo de la trama; por tanto el ancho de banda dedicado
a un usuario no se puede modificar sino cuando ha pasado el tiempo de duración de una trama,
esto es, 10 ms.
• HS-DSCH: Es un canal compartido de desacarga de datos incorporado en la Release 5 de la
3GPP. Tiene diversas similitudes con el DCH, y podría que es la extensión de este canal para
soportar servicios más rápidos y con menores retardos, de una manera más eficiente. Este canal
soporta: modulación de orden mayor (como decíamos antes, aquí se utiliza 16QAM) con el
propósito de proporcionar tasas de datos pico mas altas; rápida adaptación de enlace (fast link
adaptation), algoritmo que supone una ventaja en el desempeño, puesto que a través de él se
conocen las condiciones de radio instantáneas de los canales y por tanto se permite mayor
capacidad en el envío de información; programación rápida dependiente de las condiciones de
canal (fast channel dependent schedulling), en la que cada usuario tiene un tiempo para usar-
basado en cierto algoritmo de schedulling- los recursos de radio disponibles en el Node B
(ancho de banda por ejemplo); ARQ rápida e híbrida (fast hybrid ARQ, o HARQ) que mejora la
eficiencia de los algoritmos de retransmisión de información, disminuyendo así, los retardos de
enlace y agregando robustez a la adaptabilidad que tiene el enlace.
4.6. Canales físicos
En UMTS la estructura de los canales físicos dedicados se presenta en la Figura 5. Todo canal de
transporte debe ser mapeado a un canal físico que contiene parámetros netamente físicos como:
frecuencia de la portadora, scrambling code, código de canalización, duración y en el UL fase relativa.
Los canales físico transportan información del usuario (como el DPDCH) y de control (como el
DPCCH).
Figura 5. Estructura de un canal físico dedicado
16
4.7. Provisión de QoS
En la norma 3GPP TS 23.107 se especifican las clases de QoS que existen para una red UMTS-HSDPA
y sus características (Tabla 2).
Clase de TráficoConversacional (Tiempo Real)
Streaming(Tiempo Real)
Interactiva Background
Características Fundamentales
-Preserva la relación temporal (en la variación)
entre entidades de información del
flujo.Patrón
conversacional (exigente y de bajo
retardo)
-Preserva la relación temporal (en la variación)
entre entidades de información del
flujo
Patrón petición-respuesta.
Preserva el contenido de información.
El destino no espera la llegada de los datos dentro de
un tiempo dado.
Preserva el contenido de la información.
Ejemplo de una aplicación
Voz Video Web browsing E-mail
Tabla 2. Clases de QoS en UMTS.
En la norma 3GPP TS 22.105 aparecen los atributos que deben tener las QoS, en términos de retardos,
tasas de transferencia a garantizar, probabilidad de pérdida de paquetes. Las Tablas 3, 4, y 5 presentan
un extracto de estos parámetros, que serán usados en las simulaciones como KPI.
Medio Aplicación Tasa de transferenciaKPI (End-to-End delay,
One-way)
Audio Voz (CS) 4-25 kbpsInferior a 150 ms (preferiblemente)
400 ms (valor límite)
Video Videophone 32-384 kbpsInferior a 150 ms (preferiblemente)
400 ms (valor límite)
Datos Juegos en RT Inferior a 60 kbpsInferior a 75 ms
(preferiblemente)
Tabla 3. Desempeño esperado desde el punto de vista del usuario, para las clase Conversacional.
Medio Aplicación Tasa de transferenciaKPI (End-to-end delay,
one way)
17
Audio Mensajes de voz 4-12 kbpsInferior a 1 s para
reproducirInferior a 2 s para grabar
Datos Web browsing Mejor esfuerzo Inferior a 4 s
Datos E-mail Mejor esfuerzo Inferior a 4 s
Tabla 4. Desempeño esperado desde el punto de vista del usuario, para la clase Interactiva.
Medio Aplicación Tasa de transferencia KPI (Jitter)
AudioMúsica de alta calidad,
grabaciones de música y voz.
5-128 kbps Inferior a 2 s
VideoMovie clips, Videos de
RT20-364 kbps Inferior a 2 s
Tabla 5. Desempeño esperado desde el punto de vista del usuario, para la clase “Streaming”.
5 CARACTERÍSTICAS BÁSICAS DE HSDPA
5.1. El nuevo canal común
La aparición del canal de transporte en el DL y compartido HS-DSCH, supone una serie de mejoras en
el desempeño de las redes UMTS [HOL_10, p. 354]:
• El spreading factor variable y el control rápido de potencia (presentes en UMTS), se eliminan y
se utiliza un esquema de modulación y codificación adaptativa, y un sistema de retransmisiones
rápido y eficiente.
La nueva modulación (16QAM) permite velocidades de conexión superiores y extiende el número de
usuarios que la celda puede soportar, parámretro este último de vital importancia. El TTI se disminuye
a 2 ms, lo que permite que se puedan servir más usuarios en un intervalo de tiempo.
En el canal físico (HS-DPCCH), la duración de cada subframe es de 2ms en lo que se envían 1 slot
(2560 chips) de acknowledge del proceso HARQ y dos slots (5120 chips) del CQI.
5.2. Rápida adaptación del enlace
Este mecanismo se diferencia del mecanismo de control rápido de potencia presente en la Release 99,
en que asegura una cantidad suficiente de energía por bit para que la calidad de los servicios ofrecidos
18
sea buena, variando la potencia que recibe el terminal y manteniendo constante la velocidad de
transmisión. Esto provee buena calidad al usuario, pero desde el punto de vista del operador, es
ineficiente dado que requiere suministrar mayores cantidades de potencia, a usuarios que están situados
en condiciones de radio desfavorables. En el caso de HSDPA, se deja constante la potencia y se
incrementa la velocidad de transferencia aumentando el esquema de modulación teniendo en cuenta el
CQI que cada terminal experimenta. La duración corta del TTI permite que la UTRAN pueda conocer
más seguidamente las condiciones de radio de cada terminal, para que en caso de que éstas cambien
rápidamente pueda asimismo servir a los terminales con base en la nueva información suministrada en
los CQI [EUDAT_03, p. 38-39].
5.3. HARQ
Un mecanismo de ARQ tradicional descarta aquellos paquetes que no han podido ser decodificados, y
pide la retransmisión de la trama enviada de acuerdo con el tamaño de la ventana que usa el algoritmo
(si usa un procedimiento de ventana). Con HARQ se pretende, que aquellos paquetes que no han sido
decodificados correctamente no sean descartados sino guardados y combinados “suavemente” (soft-
combining) con la información recibida hasta que se logre decodificar la información recibida. La
consecuencia que tiene este mecanismo es la de incrementar el cociente energía por bit-interferencia lo
que evidentemente incrementa la eficiencia espectral de la tecnología [EUDAT_03, p.39].
6 CARACTERÍSTICAS DE SIMULACIÓN
6.1. Elección y características del simulador
Para el proyecto usamos el simulador de redes NS2. La elección se justifica si se tiene en cuenta que es
un simulador de código abierto, licencia libre, lo que implica que cualquier persona puede modificarlo
y por ende mejorarlo. Las características del simulador junto con elementos puntuales de los diferentes
nodos se pueden encontrar en [NS_11]. Vale la pena resaltar que NS2 no tiene una interfaz gráfica para
realizar las simulaciones, sino que todo se debe realizar en código Otcl, lenguaje interpretado que
recibe los scripts de simulación y los ejecuta haciéndoles un enlace con lo módulos de C++, que
pertenecen al lenguaje compilado.
Del simulador NS2 se hace uso de los módulos de agentes, para crear un flujo de datos a nivel de red
que opere bajo TCP [NS_11, pp. 292-301]; también es de nuestro interés el módulo de número
aleatorios y distribuciones [NS_11, pp. 222-227], y aplicaciones -en particular, para este último,
usamos tráfico CBR- [NS_11, pp. 337-346].
Dentro de las aplicaciones de tráfico no existe una gran variedad, sino que solo se puede elegir entre
tráfico Exponencial On-Off, Pareto On-Off, CBR y tráfico parametrizado por trazas. El tráfico por
trazas tiene la limitación de que bajo el módulo de EURANE no pudo ser validado y por tanto no
19
funciona. Los tráficos Exponencial y Pareto no son útiles en casos donde el tráfico de aplicaciones
sigue distribuciones diferentes a estas dos; por esta razón se propone un modelo de tráfico construido
con el stack de distribuciones de NS2 y el tráfico CBR, también de NS2. Algunas de las características
de NS2 son:
• Los enlaces se modelan a través de retardos y no de distancias y características del enlace.
• Un mismo nodo no puede ser transmisor y receptor de información. (Es decir que no puede
tener adjuntados dos agentes TCP, uno que recibe y otro que envíe).
• No hay protocolos de compresión de encabezados como PDCP.
• No hay protocolos RTP en el simulador soportado.
6.2. Características del módulo EURANE
El módulo de EURANE es un módulo de UMTS desarrollado por el proyecto SEACORN, y es un
módulo que también soporta HSDPA. Las características del módulo están explicadas en [EUMAN_05]
y [EUDAT_03]. EURANE no soporta diversas características de una red HSPA real, algunas de ellas
son:
• No soporta HSUPA.
• Solamente soporta una celda (un nodo base), por lo que no se pueden evaluar características de
Handover. La interferencia de todas las celdas circundantes está incluido en el parámetro
“Iinter” de los archivos de preprocesamiento en MATLAB.
• HSDPA está soportado pero hasta la Release 5, es decir, velocidades pico de 1.4Mbps.
• No existe el Transparent Mode de la capa RLC.
• La interfaz del aire se modela aparte, a través de archivos en MATLAB que se adjuntan a cada
UE.
• Solo se modelan flujo de datos, es decir que características de señalización no existen.
• Soporta FACH, RACH, DCH y HS-DSCH, pero ningún otro canal, ni de transporte ni lógico.
• El CQI, se obtiene a través de un algoritmo de cálculo del SNR, y todo se realiza a través de los
archivos que se adjuntan a los UE. Sin embargo, no hay un modelamiento estrictamente directo
de la modulación (QPSK o 16QAM).
• No están soportados procedimientos de la capa física como el Compress Mode.
6.3. Topología de estudio
La topología de una red UMTS está delineada por la norma 3GPP TS 23.002 y se presenta en la Figura
6. Esta topología es la que se utilizará en el presente proyecto a excepción de que solamente se usará un
Nodo B (por limitaciones del simulador).
20
Figura 6. Topología elemental de una red UMTS para simulación.
Los nodos SGSN y GGSN son nodos de la “Core Network” que pertenecen al dominio PS, es decir a
aplicaciones diferentes a la de voz. Para aplicaciones de voz se utilizan dos nodos adicionales llamados
MSC y GMSC. Una topología más cercana a la realidad es la presentada en la Figura 7.
Figura 7. Topología de una red UMTS real.
No se incorpora esta última topología porque no se usarán aplicaciones de voz conmutadas por circuito.
Además, características reales de un operador de red como Control de Admisión y Seguridad no se
implementan, por lo que los nodos MSC, VLR, EIR, GMSC, HLR, AuC, GR y demás no tendrían en
NS2 funcionalidades claramente definidas, sino que serían nodos “génericos”. Añadido a esto, como ya
se dijo previamente, no es el propósito de esta tesis analizar características de la “Core Network” por lo
que el modelo de Core Network se abstrae a través de un enlace con un retardo y una cierta capacidad.
Haciendo el retardo suficientemente largo y la capacidad relativamente coherente, se asume que dicho
21
enlace entre el GGSN y el nodo Enrutador, es la Core Network. Es claro que aquí no se simulan las
características de enrutamiento que un operador realiza a través de la Core Network, lo que puede tener
un impacto en el desempeño de una red.
6.4. Estructura física e interfaz Au
Para poder realizar un escenario de simulación completo, se debe adjuntar a cada UE un archivo
procesado en MATLAB u OCTAVE, con los CQI que existen a lo largo de la simulación. Este
procedimiento es el modelamiento de la interfaz del aire Au. Los CQI son los encargados de decir que
tan buenas son las características del medio donde un usuario está, dependiendo de su distancia,
velocidad, interferencia y muchos otros factores. El Nodo B, coordina con el usuario procesos
periódicos de medición de las caracterísitcas del medio, para que finalmente el UE le envíe un número
entero entre 0 y 30, donde si mayor es el número, mejores son las características del medio.
En la norma 3GPP TS 34.122 se describe el procedimiento que el UE debe realizar para enviarle un
CQI a la UTRAN; el CQI es un número obtenido para un deseado BLER (típicamente del 10% como
mínimo) y se calcula como un promedio sobre una cantidad determinada de mediciones. El algoritmo
que se usa en este proyecto está detallado en [EUDAT_03, pp. 56-60] y se presenta en las Figuras 8 y 9.
Figura 8. Estructura del modelamiento de la capa física.
Figura 9. Bloque estimador del CQI.
El proceso que sigue el simulador para modelar una conexión lógica entre un UE y el nodo B usando el
canal HS-DSCH es el siguiente:
22
Una conexión HS-DSCH transmite un TB cada TTI (es decir, para HSDPA, 2ms), el TB tiene un
tamaño variable (TBS).
• La señal transmitida Stx tiene una potencia constante y el TBS variable.
• A esta señal se le suma la interferencia debida a los canales no-ortogonales que existen en la
misma celda. Típicamente esta interferencia se debe al SCH y se denomina “Intracell
interference”. Esta señal superpuesta es constante en magnitud en este modelo; en la vida real
existen fluctuaciones, dado que la “Intracell Interference” es una variable del tiempo. Sin
embargo, estas fluctuaciones no tienen un impacto preponderante en el modelo usado.
• Luego aparece el canal AWGN que reduce la potencia de la señal en un cantidad calculada a
través de la Ecuación 3 (pérdidas por el camino, o pérdidas por distancias largas, ver 4.2.1) y las
pérdidas por Shadowing (Pérdidas por desvanecimiento lento, ver 4.2.2) y las pérdidas por Fast-
Fading (Pérdidas por desvanecimiento rápido, ver 4.2.3).
• A esta señal atenuada se le superpone la interferencia debido a las celdas vecinas. Esta
interferencia se agrega para modelar el efecto de las otras celdas desde el punto de vista del
ruido. De nuevo la interferencia entre-celdas es modelada constante en magnitud, y cambios
reales en la interferencia no son importantes dado que son mucho mayores los cambios en el C/I
(carrier to interference ratio) introducidos por el medio [EUDAT_03, p. 57].
Para estimar la calidad del canal se utiliza el procedimiento de la Figura 9. El CQI es un campo de
datos de 5-bits que el UE envía al Node B. Cada CQI representa una combinación específica de
Número de códigos y Modulación que resulta en un TBS. El UE envía el mayor CQI posible, es decir,
el TBS más largo que el UE puede recibir con una probabilidad de error de 10%. Este procedimiento se
calcula en un período de 3 TTIs.
En la Figura 5 se utiliza el SNR para poder decidir cual es el CQI. El cálculo del SNR está basado en la
Ecuación 4.
Ltotal es la suma de las pérdidas Path loss, Shadowing y Fast-Fading.
Ptx es la potencia de código transmitida (Transmitted code power), es decir, la potencia transmitida en
un código de canalización para un “scrambling code” dado, para una frecuencia portadora dada
[LAI_06, p. 91].
El SNR calculado se pasa por tres bloques de retardo y se extrae el mínimo de los 3. Después se realiza
un mapeo entre el SNR y el CQI de la forma siguiente [EUMAN_05, p. 25]:
23
SNR = PTx − LTotal− 10log10 − (10(
Iintra
−LTotal
10 )+ 10
(Iinter
10 )) (4 )
• Se conocen los períodos del ciclo HARQ y por ende, el número de retransmisiones.
• Se calcula el primer estimado del SNR que es el que aparece en la Ecuación (4)
• Se calcula el segundo SNR: SNR 2 = SNR ( t+HARQCycle ) (5 )
• Se calcula el tercer SNR: SNR 3 = SNR ( t+2∗HARQCycle ) (6 )
• Se calcula el CQI:
Donde para esta simulación usamos: CQIdelayinTTI igual a 3, HARQCycle igual a 6, y Offset que es
un parámetro de calibración que se obtiene de mediciones de la capa física, es igual a 16.62. Además,
el CQI puede estar entre 0 y 30, siendo 0 cuando el SNR es menor o igual a -16dB y siendo 30 cuando
el SNR es mayor o igual a 14dB. Un CQI de 0 significa fuera de servicio. Los parámetros concernientes
a la capa física se presentan en la sección 7.5.1.
6.5. Filosofía y algoritmo de simulación
Se desea realizar una simulación para obtener características que a un operador de red podrían llegar a
interesarle, es decir, características de capacidad. De igual forma se desean variar parámetros que le
den buena cuenta al operador de red, del escenario donde se acentúa.
El diagrama de flujo de las simulaciones del presente proyecto se presenta en la Figura 10.
Se debe tener en cuenta que todas las variables llamadas “Cont--” son contadores del vector cuyo
nombre es el que está después de la palabra “Cont”. Estos vectores son los que se indican en la Tabla 6.
Nombre del vectorTipos de elementos pertenecientes a esa
variable/vectorDescripción
App VoIP, Video, Web, Gamming
Las aplicaciones end-user que se corren en los UE; son modeladas a través del tamaño del paquete,
tiempo entre packet-calls, y otros parámetros (Ver Sección 8)
PLE (Path loss Exponent) 1.6, 2.7, 3.3
Este parámetro pertenece al modelo logarítmico de pérdidas
por camino (o por distancias, path loss). Es el parámetro “n” de la Ecuación (3). Modela los
diferentes tipos de ambientes (ver Sección 7)
Alfa 0.3, 0.5, 0.7 Este parámetro es weighting
24
CQI (t ) = ⌊ SNR ( t−CQIdelayinTTI )
1 .02+Offset ⌋ (7 )
factor del algoritmo FDCS del planificador. Es el que decide si el planificador se comporta más
como RR (valores cercanos a 0) o como Maximum C/I (valores
cercanos a 1) (ver Sección 5.4)
QoS_App -
Es el valor calculado del parámetro de desempeño que me mide la QoS para la aplicación
que se está corriendo
TH_QoS_App
VoIP: E2E delay = 400 msVideo: Jitter = 2s
Web: E2E delay = 4s
Es el umbral que el parámetro de desempeño que mide la QoS de la aplicación puede tomar, antes
que el servicio se considere como uno de mala calidad.
Tabla 6. Vectores que se utilizan en el diagrama de flujo de la Figura 14.
En las próximas secciones se muestran los modelos de propagación que se deben procesar antes de
iniciar la simulación, es decir, -antes del primer paso del diagrama de flujo de la Figura 10-, y los
scripts de procesamiento de la información después de que se acaba una simulación, para obtener los
parámetros de desempeño de cada aplicación.
Así, el objetivo es simular para cada escenarios descrito por los parámetros de la Tabla 6, y obtener el
Retardo extremo a extremo como función del número de usuarios de la celda. Una vez obtenidos estos
parámetros se desea establecer una plan de tarificación a los usuarios que tenga en cuenta qué tipo de
aplicaciones saturan más rápido las celdas, para así cobrarle a los usuarios un precio justo pero que
“penalice” -cobrándole más dinero- a aquellos usuarios que usan más tiempo aplicaciones
demandantes. Es decir, se propone una forma de cobrar a usuarios por extralimitación en el uso de la
red (superan cierto umbral de GB). Este plan se introduce en la sección 10.
25
Figura 10. Diagrama de flujo de la simulación.
26
InicializaciónDe
VariablesTodos los contadores
Iguales a 1
Cómputo QoS_App_i
Simulación NS2:Alfa = Alfa kPLE = PLE jApp = App iNumUE = 1
ContAlfas<=NMaxAlfas
ContApps<=NMaxApps
QoS_App_i <= TH_QoS_App_i
ContPLE<=NMaxPLEsContApp++
ContAlfa++
ContPLE++
Agrego un UE al script de simulaciónNumUE++
Si
No
No
No
No
Si
Si
Si
Fin
6.5.1 Archivos de pre-procesamiento
Para que el script de simulación de Otcl pueda correr, a cada UE se le debe asignar un archivo de texto
que contenga los valores de CQI durante toda la simulación para los BLER y los CQI dados. Estos
archivos se procesan en MATLAB y siguen las directrices dadas en la sección 7.4. En la Tabla 7 se
muestran los valores de los parámetros usados con una descripción de cada uno de ellos.
Parámetro Valor Descripción
Longitud de onda 0.15 mEs la longitud de onda correspondiente a una
frecuencia de de 1.95GHz, típica de un operador de tecnologías 3G.
Duración TTI 2 ms Es la duración de la trama de HSDPA
Muestras por fade 100Mínimo de muestras para realizar los cómputos
de fading
Maximo número de muestras por TTI
10Muestras discretas para realizar los cálculos de
CQI, SNR, entre otros, para intervalos de tiempo discretos.
Potencia de transmisión 38 dBm – 6.31 WValor de la potencia de transmisión de un
terminal. Valor típico
Ganancia de la antena de la BS 17 dBiFactor de amplificación de la antena receptora
en el Nodo B. Valor típico.
Linit 137.4 dBPérdida por una distancia de 1km para una
antena de 30m de altura. Ecuación (3)
IntraCell Interferencia 30 dBmInterferencia debida a la no ortogonolidad de
los códigos de los canales compartidos.
InterCell Interferencia -70 dBmInterferencia debida a la presencia de otras
celdas.
Shadowing deviation 8 dBEs la desviación estándar de la variable
gaussiana de la Ecuación (3)
CQITTIdelay 3Número de TTIs entre una medición hecha por
el UE y el momento en que dicha medición puede ser usada por el planificador.
HARQCycle 6 Período de los procesos HARQ
Tabla 7. Parámetros de la capa física que se ingresan en simulador.
Además de los parámetros anteriores se debe ingresar la velocidad a la que se mueve cada UE, la
distancia respecto al Nodo B, y el tipo de ambiente: Pedestrian, Indoor, Outdoor, Vehicular, Rural,
Tipical Urban y Hilly Terrain. Siguiendo las recomendaciones de las normas 3GPP , simulamos un
ambiente Peatonal (Pedestrian) con velocidades para todos los terminales iguales a 3kmh.
27
Las distancias de los UE a la celda se organizan de acuerdo a una distribución uniforme entre 0.1km y
5km. Si asumimos una capacidad máxima de 240 UE las distancias que le corresponderán a cada UE
vendrán dadas por:
Es decir que cada UE estará 20 m espaciado respecto al anterior, empezando por una distancia de 100m
mínima. Esto quiere decir que la pérdidas máximas que hay para el UE que está situado cerca de los
5km son de, -según la Ecuación (3)-:
Path Loss Exponent Pérdidas por distancia (Path Loss) [dB]
1.8 149.981
2.7 156.272
3.3 160.466
Tabla 8. Path losses para una distancia de 5km y los diferentes Path loss exponents.
También es de interés para una cantidad máxima de pérdidas permitida para un servicio, basados en
algunos supuestos, decidir el rango de la celda. Este tipo de análisis corresponde al campo de
planeación y dimensionamiento de redes móviles que está bien detallado en [LAI_06]. En esa misma
referencia [LAI_06, p. 105] se asumen pérdidas máximas de 152.5 dB para un canal HS, contando una
serie extensa de parámetros que los archivos de procesamiento del presente proyecto no tiene. En
[HOL_10, pp. 173-178] se encuentra una aproximación similar para aplicaciones de CS voice. Se
utiliza el valor de 152.5 dB como una valor máximo de pérdidas, y para los diferentes path loss
exponent se calcula la distancia en km de la celda, como se muestra en la Tabla 9.
Path Loss Exponent Radio de la celda [km]
1.8 6.9
2.7 3.62
3.3 2.86
Tabla 9. Radio de la celda para 152.5 dB como valor máximo de pérdidas.
En el último caso modificamos la Ecuación (8):
para el caso de 200 usuarios como máximo.
28
dUE i [ km ] = 0 .1 + i∗⌊ 5−0 .1240 ⌋ (8 )
dUEi [ km ] = 0 .1 + i∗⌊ RadioCelda−0 .1200 ⌋ (9 )
6.5.2 Archivos de post-procesamiento
Los archivos que el simulador arroja, contienen mucha información redundante, además de que son
archivos de texto muy pesados (del orden de 100-500MB). Para ello se usan los programas AWK y
Perl, que son lenguajes de programación para procesar texto.
Las métricas de desempeño de cada aplicación son: Retardo extremo a extremo para aplicaciones VoIP,
Web, RealTime y Video Streaming. El algoritmo de cálculo de la métrica de desempeño “retardo
extremo a extremo” se muestra en el diagrama de flujo de la Figura 11. Se utilizan los códigos del
profesor Fione [FIORE] , en AWK, y códigos propios en PERL, que se presentan en el Anexo B.
No obstante lo anterior, las métricas de desempeño de aplicaciones de Video Streaming son muchas
más que el retardo extremo a extremo, incluyendo resolución, calidad del audio (desde un punto de
vista frecuencial), sincronización video-a-audio, jitter, etc... Como aparece indicado en la Tabla 6, la
característica que la ETSI recomienda, es la de un jitter menor a 2 segundos. El jitter para aplicaciones
de video, tiene que ver con la fluidez de la imagen.
El jitter sin embargo es más complicado de decidir, dado que cada intervalo de tiempo que pasa, el
jitter cambia irregularmente; es decir que para un instante de tiempo puede ser mayor a 2 segundos, y 5
ms segundos después ser menor a 2 segundos, lo que no deja claro si se está obteniendo un desempeño
adecuado. El procedimiento que realizamos para calcular la capacidad de acuerdo con el jitter es el
presentado en la Figura 12. El cálculo de los 4 jitters promedio por cada terminal, es parte del código
del profesor Fione.
29
Figura 11. Diagrama de Flujo para la métrica de retardo extremo a extremo.
30
InicioInicio
Vtiempo[Packet_IDActual] = TiempoActualVtiempo[Packet_IDActual] = TiempoActual
Evento = '+'Evento = '+'
FlowActual = Flow_ID'FlowActual = Flow_ID'
PackTypeAcual = PackTypeRecv'PackTypeAcual = PackTypeRecv'
Intervalo = TiempoActual -Vtiempo [Packet_IDActualIntervalo = TiempoActual -Vtiempo [Packet_IDActual
DelayAcum = DelayAcum + IntervaloDelayAcum = DelayAcum + Intervalo
NumPacks++NumPacks++
Fin TrazaSimulación
Fin TrazaSimulación
Evento = 'r'Evento = 'r'
FlowActual = Flow_ID'FlowActual = Flow_ID'
Si
No
Si
Si
Si
Si
No
No
No
No
No
Figura 12. Cálculo de la capacidad con base en la métrica jitter.
31
Calcular jitters De
Flujo i
Jitter 1 < 2s Jitter 2 < 2s Jitter 3 < 2s Jitter 4 < 2s
ContJitters++ ContJitters++ ContJitters++ ContJitters++
ContJitters = 4
NumUsuarios++
Flujo i < Flujo N-ésimo
InicioNumUsuarios = 0I = 1
ContJitters = 0
Si
No
SiSi Si Si
Si
NoNoNoNo
No
FIN
7 MODELO DE TRÁFICO
7.1. VoIP
El advenimiento de un canal compartido cuyas velocidades en el DL son del orden de Mbps, unido a
RTT del orden de 30 ms en el mejor de los casos y ~100 ms en el peor, permiten que aplicaciones
tradicionales del dominio CS puedan ser implementadas en el dominio PS. Esto unido a algoritmos de
compresión de encabezados como ROHC [HOL_10, p.17], han permitido diseñar técnicas de
codificación más eficientes y sobre todo técnicas de Inspección Profunda de Paquetes (Deep Packet
Inspection) con el propósito de determinar si los paquetes pertenecen a VoIP y así garantizar una tasa
de transferencia mínima. El modelamiento de esta fuente de tráfico se basa en diversas referencias,
pero principalmente en [HASS] y [YONG]. La fuente de tráfico se trata como una fuente ON-OFF, con
es decir con períodos de actividad (donde se transmiten paquetes) y con períodos muertos, donde no se
transmiten paquetes (formato DTX en HSDPA). La Figura 13 muestra este comportamiento.
Figura 13. Fuente ON-OFF VoIP [HASS].
Como se aprecia, durante el período de actividad se transmiten paquetes como una fuente CBR, y se
asume que el período de actividad está distribuido Exponencialmente con parámetro Lambda1. Los
períodos de inactividad de igual forma, está distribuidos exponencialmente con parámetro Lambda 2.
Los períodos de actividad se denominan Packet Calls, término que comúnmente se utiliza en
aplicaciones web.
Esta fuente ON-OFF se modela como una cadena de Markov con dos estados, y probabilidades de
transición Lambda1 y Lambda2. Los tiempos de actividad e inactividad son los inversos de los
parámetros Lambda. En la Tabla 10 quedan consignados los valores usados durante las simulaciones; el
valor depende del tipo de codec que se aplica.
Codec Ton [s] Toff[s]Avg Bitrate
[kbps]OnBitRate
[kbps]PacketSize
[Bytes]N
32
G729C 0.352 0.65 6.3 17.933 70 896
G729V 7.24 5.69 10.2 18.216 70 10
G729R 3.23 0.41 31.1 35.047 70 106
G711C 0.352 0.65 18.3 52.096 136 896
Tabla 10. Parámetros del modelo de tráfico de una fuente VoIP.
Donde L es la tasa de transferencia durante el tiempo ON (On BitRate), y viene dada por la ecuación
(10), este es el parámetro que se ingresa en el script de simulación.
En [HOL_06] se especifica que el tamaño del Payload más el encabezado RTP/UDP es del orden de 40
Bytes por cada frame de 20 ms, con algoritmos ROHC, y que la tasa de transferencia en ese caso es de
12.2kbps. En las Ecuaciones (11) y (12) se consignan otros parámetros del modelo de tráfico propuesto,
cuya descripción aparece en la Figura 14.
Figura 14. Parámetros adicionales del modelo de Tráfico VoIP.
N, corresponde al número de PacketCalls que se preveen usar durante toda la simulación. El cálculo de
N lo realizamos a través de la Ecuación (13), en donde dividimos el tiempo de simulación entre los
intervalos compuestos por los OnTime y OffTime, y a eso le restamos la desviación estándar de la
variables exponenciales de los tiempos On y Off.
33
L =Ton +Toff
T on
∗ƛ (10 )
StartTime2 StartTime3StartTime1 StartTimeN
StopTime1 StopTime2 StopTime3 StopTimeN
OnTime1 OnTime2 OnTime3 OnTimeN
OffTime1
OffTime2 OffTime(N-1)
StopTimei = StartTime i + OnTimei i=1,2 ,. . .,N (12 )
StartTimei = 0, i=1
StartTime i = StopTime (i−1 )+OFFTIME i , i=2,3 , .. . ,N (11 )
7.2. Streaming (Video)
Modelos para fuentes de tráfico que simulan el comportamiento del proceso de Streaming, se
encuentran en [STUCK_03, p. 73], [SOL_05, p. 50-52], [NYBERG_01], entre otros. Comúnmente este
tipo de tráfico se denomina VBR porque la tasa de transferencia es dinámica dependiendo de lo pesada
de la imagen. De esa forma se deben considerar al menos 3 casos de tipos de video, de acuerdo con
características de imagen: Claire, Carphone, Foreman [STUCK_03, p. 75].
1. Claire: Video de muy baja intensidad de movimiento, pueden ser vistos como una secuencia
característica de una video-conferencia o telefonía visual inactiva.
2. Carphone: Tiene períodos de alta intensidad de movimiento y otros de baja intensidad; es el
caso de video-conferencias muy activas participativas.
3. Foreman: Corresponde a videos con permanente actividad y alta intensidad de movimiento; es
el caso de eventos deportivos, trailers de películas.
Es claro que cuanto más demandante sea la aplicación de video, menor deberá ser la latencia y la
variación de la latencia. Aplicaciones de Video Streaming trabajan sobre protocolos TCP/RTP o
UDP/RTP. Para el presente proyecto se utilizan TCP y ningún protocolo de la capa de sesión del
modelo OSI (como el caso de RTP). En general, las fuentes de tráfico de Video son muy complejas y
contienen numerosos parámetros a ingresa, pero eso está fuera del alcance del presente proyecto.
La fuente de tráfico se modela nuevamente como en el caso de VoIP, a través de una cadena de Markov
con 2 estados, ON y OFF, durante los cuales la fuente de tráfico bien puede registrar actividad (envío
de datos) o actividad “nula” (datos de menor tamaño, o ningún dato). Así, al igual que el caso de VoIP
el modelo de tráfico queda determinado por los tiempos de ON y de OFF, el tamaño de los paquetes, la
tasa de transferencia durante el tiempo ON.
Sin embargo, en vez de especificar el parámetro del tiempo ON, especificamos (según el acercamiento
presentado [SOL_05, p. 51], y en [WANG_05]) la distribución del tamaño del Objeto que se desea
reproducir. Las características del modelo de Video están consignadas en la Tabla 11.
Parámetro DistribuciónValor Parámetros de
DistribuciónValor
Tasa de Transferencia - - 64 kbps
34
N =T Simulacion
TOn +TOff
−N (StdDev [ X(1/T On) ]+StdDev [X (1/TOff ) ]) =
T Simulacion
T On+T Off
−N (T On +TOff )
⇔N =T Simulacion
(T On +TOff ) (1+TOn +T Off )(13 )
Tamaño del buffer - - 8 s
Tamaño del Objeto Uniforme 160 kB – 3200 kB -
Tamaño del paquete - - 160
OFF-Time Exponencial 60 s -
Tabla 11. Parámetros que modelan el tráfico de Video Streaming.
El número de Packet Calls viene dado por la Ecuación (14):
El cálculo de los tiempos de actividad (Ton) viene dado por:
Al igual que en las aplicaciones VoIP, el tráfico es de tipo CBR en los períodos de actividad, y los
tiempos de inicio y parada de las fuentes CBR (N por UE, para un total de N*UE) están dados
nuevamente por las Ecuaciones (11) y (12); estos valores son se ingresan en el script de simulación
como una instancia del Simulador que llama las fuentes de tráfico creadas y las pone en actividad
durante el período que se “prende” y se “apaga” la fuente.
7.3. Web
El caso de Web Browsing es quizá el caso más común para evaluar resultados de capacidad [HOL_06,
pp. 130-140, 148-150]. Era el tráfico más utilizado en redes GPRS [DIRK_00, p. 4], y debido a
advenimiento de HSDPA y tasas de transferencia más altas es de esperarse que aumentó, teniendo en
cuenta los planes de tarificación flat que los operadores se han visto forzados a ofrecer a los usuarios.
En los primeros momentos de 3G la tecnología de web browsing está basada en el protocolo WAP, pero
con el transcurrir de los años, los terminales han alcanzado tal grado de sofisticación que se emula el
comportamiento de sesiones web iguales a las de un desktop o un laptop. Para ello el protocolo HTML
ha tenido gran fuerza, desplazando casi por completo al stack de protocolos WAP/XHTML [HOL_10,
p. 23].
Además, las páginas web contienen numerosos objetos “embebidos”, que incluyen archivos devideo, y
de audio, por lo que es un escenario propicio para caracterizar diversas fuentes de tráfico. Los modelos
de tráficos de páginas web son numerosos, cada uno de ellos presentando un nivel de complejidad
mayor o menor, y además, presentando resultados de desempeño de la red diferentes. Por eso, el
desempeño de la red, visto desde los escenarios de simulación y el punto de vista del operador
35
N MAX =HoldingTime
T On+T Off
(14 )
TOn=TamañoObjeto
TasaTransferencia(15 )
(resultados de capacidad), es sensible del modelo de tráfico usado. Un resumen de los diversos
modelos de tráfico web está resumido en la tabla presentada por [DIRK_00, p. 11].
Para el presente proyecto, nos concentraremos en el modelo clásico de Choi [CHO_99], y el modelo de
UMTS consignado en TR 101 112 v3.2.0 ETSI. En general un modelo de tráfico web está
esquematizado por los componentes de la Figura 15.
Figura 15. Modelo de tres niveles del tráfico web [JAHAN_08].
1. El primer nivel es de los paquetes. Está caracterizado por el tamaño del paquete (Bytes), y el
intervalo de tiempo entre paquetes, que en general está modelado por una distribución de
probabilidades. Para el presente proyecto, se usa intervalo de tiempo entre paquetes constante y
determinístico.
2. El segundo nivel es de las Llamadas de paquetes (Packet Calls es el término que hemos usado a
lo largo de este capítulo). Está caracterizado por un tiempo de actividad (ON), y un tiempo de
lectura (OFF). Ambos tiempos proceden de distribuciones de probabilidad.
3. El tercer nivel es el nivel de sesiones. Este nivel está caracterizado por el número de Llamadas
de paquetes (lo que constituiría el tiempo ON de la sesión), y el tiempo entre sesiones, que de
nuevo, proviene de una distribución de probabilidad específica.
Entre más alto el nivel, el tiempo promedio entre objetos de ese nivel es mayor. Así, si por ejemplo en
el nivel 1, el tiempo entre paquetes es de 20 ms, en el nivel 2, el tiempo entre Llamadas de paquetes es
de 3 segundos, y en el nivel 3, el tiempo entre sesiones es de 2 minutos. Los nombres de los parámetros
varían dependiendo del modelo a usar, y en general no todos los niveles están implementados.
36
7.3.1 Modelo de Choi
En este modelo, cada Llamada de paquetes tiene numerosos Objetos denominados In-Line Objects y un
Objeto central denominado Main Object. Por cada In-Line Object se establece una conexión TCP, y
existe un tiempo entre In-Line Objects modelado por una distribución de probabilidad. En el modelo de
Choi, no se considera el tercer nivel, y por ende solo tenemos en cuenta hasta el número de Llamadas
de paquetes. La Figura 16 provee un esquema del modelo y los parámetros se presentan en la Tabla 12.
Figura 16. Modelo de Tráfico web de Choi.
Parámetro Valor Medio Desviación Estándar Distribución
ObjectSize
Main 10710 B 25032 B Log Normal
In-Line 7758 B 126168 B Log Normal
Número de In-Line Objects
5.55 11.4 Gamma
Tiempo entre In-Line Objects
0.86 2.15 Gamma
Tiempo de lectura (OFF time)
39.5 92.6 Weibull
Tabla 12. Parámetros Modelo de tráfico web de Choi.
Sin embargo para poder utilizar este modelo es necesario encontrar los parámetros de las distribuciones
a partir de los parámetros dados en la Tabla 12.
37
Si X se distribuye Log-Normal con parámetros μX y σ X2 , entonces la transformación se da
como aparece en las Ecuaciones (16) y (17):
Si X se distribuye Gamma con parámetros α y β la transformación se da como aparece en las
Ecuaciones (20) y (21):
Los parámetros de la distribución Weibull, no tienen una forma analítica y es por eso que son hallados
empíricamente para que se ajusten a los valores dados por la Tabla 12. Los parámetros de la
distribución Weibull se denominan Escala y Forma y están consignados junto con los otros valores, en
la Tabla 13.
Parámetro Parámetro 1 Parámetro 2 Distribución
ObjectSize
Main 8.3459 3.3131 Log Normal
In-Line 6.1657 3.8124 Log Normal
Número de In-Line Objects
0.2370 23.4162 Gamma
Tiempo entre In-Line Objects
0.16 5.375 Gamma
Tiempo de lectura (OFF time)
18.5344 39.8 Weibull
Tabla 13. Parámetros de las distribuciones.
Para este modelo deducimos los valores de inicio y parada de cada fuente de tráfico CBR (Número de
Usuarios*Número de Llamadas de paquetes*Número de In-Line Objects), vienen dados por las
Ecuaciones (22), (23), (24)
38
μX = log( X̄2
√VAR [ X ]+ X̄2 ) (16 )
σ X = √( log (VAR [ X ]
X̄2+1)) (19 )
α =X̄β
(20 ) y β =VAR [ X ]
X̄(21 )
donde N, corresponde al número de Packet Calls, los TinicioMAIN son los tiempos de inicio de las
fuentes CBR que emulan el comportamiento del objeto central de la página; los TinicioIN son los
tiempos de inicio de las fuentes CBR que emulan el comportamiento de los In-Line Object, los
OFFTIME son el valor producido por el generador de números aleatorios cuya distribución ya se
especificó en las Tablas 12 y 13; los TMAIN son los tiempos de duración de los objetos centrales de la
página web y los TIN son los tiempos de duración de los objetos In-Line.
El inconveniente con este modelo es la forma para determinar los ONTIME, es decir el tiempo durante
el cual se envían el objeto central y todos los objetos In-Line, esto, principalmente debido a que los
tiempos de duración de los objetos In-Line se sobreponen entre sí y por ende no se sabe qué objeto
termina primero y cuándo terminan todos, dado que no es un modelo determinístico. Esto, unido a la
complejidad del modelo (para poder ser reproducido en un script de simulación de NS2 y EURANE) lo
hacen menos atractivo que otros, aún cuando su modelamiento incluye gran número de parámetros
importantes y a menudo es ampliamente usado en análisis de tráfico.
Para este tipo de modelo se usa un valor único para los ONTIME, -15 segundos-, que sea menor a los
OFFTIME, pero del mismo orden de magnitud. En la siguiente sección se presenta una simplificación
del modelo Choi, que usaremos también en las simulaciones.
7.3.2 Modelo simplificado de Choi
La abstracción que hacemos del modelo de Choi, es considerar el objeto central y el conjunto de In-
39
TStopIN (i,j ) = TinicioIN (i,j ) +TIN (i,j ) , i=1,2 , .. . ,N, j=1,2 ,. . ,N INLINEOBJECTS (26 )
TIN ( i,j) =ILINEObjSize ( i,j)
BitRate(27 )
TinicioMAIN i = 0, i=1
TinicioMAIN i = ONTIME ( i−1 )+OFFTIME ( i−1 ) +TinicioMAIN ( i−1 ) , i=2,3 , .. . ,N (22 )
TMAIN i =MAINObjSizei
BitRate, i=1,2 , .. . ,N (24 )
TStopMAIN i = TinicioMAIN i +TMAIN i , i=1,2 , .. . ,N (25 )
TinicioIN ( i,j) = TinicioMAIN j +TMAIN j , j=1, i=1,2 ,. .. ,N
TinicioIN (i,j ) = TinicioMAIN (i,j−1 ) +TinterIN ( j−1 ) , j=1,2, . .. ,N INLINEOBJECTS , i=1,2, . .. ,N (23 )
Line Objects como un solo objeto que puede ser modelado con una sola distribución y al cual se le
puede extraer el ONTIME (es decir, el período durante el cual se envía totalmente el objeto, dado su
tamaño y la tasa de transferencia).
Sean X1 y X2 variables Log-Normales con parámetros μ1 ,σ12 y μ2 ,σ 2
2 , entonces se
cumplen las siguientes propiedades:
1. Z = aX se distribuye Log-Normal con parámetros μZ = μ+ ln (a ) y σ Z2
= σ 2
2. Y = X 1+X 2 se distribuye aproximadamente Log-Normal [GAO_09] con parámetros
Definimos entonces el tamaño único del objeto como modelado por una distribución Log-Normal de
nombre XObjUnicos con parámetros:
Los valores de los parámetros de la distribución del Objeto Único son los presentados en la Tabla 14.
Parámetros de la distribución Log-Normal del Objeto Único
μObjUnico 15.3037
σObjUnico 0.0114
Tabla 14. Valores de los parámetros de la distribución del Objeto Único.
Así, solamente están los ONTIME y los OFFTIME, y con ellos los tiempos de inicio y parada de la
Figura 14 que quedan definidos por las Ecuaciones (11) y (12), y los ONTIME quedan definidos por la
Ecuación (15).
40
σY2 = log(∑ e
(2μ j +σj2) (e( σ j
2 )−1)
(∑ e(μ j +σ
j2/2))
2+1) (28 )
μY = log (∑ e(μ j +σ
j2/2))−σY
2
2(29 )
μObjUnico = μY : ( μ1=μMAINObj ;μ2=μZ : (μ=μINLINEObj ,a=N INLINEObj) )σ ObjÚnico
2 = σ Y2 (30 )
8 RESULTADOS DE CAPACIDAD
8.1. Capcidad de VoIP
En las siguientes gráficas presentamos los resultados de capacidad para la celda HS y la aplicación
VoIP. En las primeras gráficas están los retardos para cada Flujo de cada escenario simulado. Es decir,
ahí encontramos el retardo de cada usuario sin computarse un promedio. En las segundas gráficas, en
cambio, computamos el promedio de retardos por intervalos de a 20 usuarios; es decir, cada 20 usuarios
tenemos un retardo promedio para ese mismo número de usuarios, y este tipo de gráfica (dado que es
un promedio) es claro que es creciente monótonamente, a diferencia de la anterior en la cual un usuario
podía tener un flujo mucho mayor al promedio de su intervalo.
Figura 17. Retardos por usuario para un path loss exponent de 2.7 y para pérdidas de 152dB.
La Figura 17 nos indica que el comportamiento por usuario es prácticamente independiente del
planificador (modelado por el parámetro “alfa” aquí) hasta poco más de 50 usuarios. Casi todos los
terminales tienen el mismo comportamiento lo que indica que son servidos regularmente sin importar el
método del planificador. Sin embargo, a medida que se aumentan los usuarios agregados a la celda, el
comportamiento por usuario es mucho más aleatorio, lo que indica que no existe una regularidad al
servir a cada usuario. Esto se puede dar, principalmente porque la red empieza a congestionarse, de
donde es inevitable que se sirva más a algunos usuarios que a otros. Sin embargo, a pesar de que en la
gráfica no se observe muy detalladamente, cuando el “alfa” es cercano a 0 (planificador RR), el sistema
41
tiende a atender equitativamente a los usuarios por intervalos de 20; esto se puede apreciar al computar
las desviaciones estándar por intervalos de 20 para los diferentes valores de “alfa”, desviaciones que
aparecen en la Tabla 15.
Desviaciones estándar [ms] para un Path loss exponent de 2.7 y un máximo de pérdidas de 152 dB
20 UE 40 UE 60 UE 80 UE 100 UE 120 UE 140 UE 160 UE
Alfa 0.3 3.8987 7.7927 99.4361 121.274 514.82 550.6 353.33 307.3658
Alfa 0.5 3.0475 7.459 44.8133 75.918 407.35 490.81 386.89 355.69
Alfa 0.7 3.51 7.5420 65.7161 204.44 396.1 620.48 375.19 423.06
Alfa 0.9 3.8647 7.177 68.2851 79.1 499.6 431.38 336.077 432.72
Tabla 15. Desviaciones estándar en [ms] para un Path loss exponent de 2.7 y un máximo de pérdidas de
152 dB.
De la Tabla 15 se observa que a partir de 60 UE, conforme se incrementa el Alfa las desviaciones
estándar son mayores (esa parece ser la tendencia); esto se debe a que el Alfa menor implica que el
planificador usa RR lo que implica a su vez que cada UE es servido durante la misma cantidad de
tiempo, indistinto de sus condiciones de radio.
Figura 18. Retardo promedio según el número de usuarios, para un path loss exponent de 2.7, y
pérdidas máximas de 152 dB.
Así según la Figura 18, las capacidades para los diferentes valores de Alfa son respectivamente: 130
UE, 148 UE, 130 UE, 140 UE. Estos valores se tienen para el valor límite de retardo para una
42
aplicación VoIP, presentado en la sección 7.5.
El comportamiento exponencial de la Figura 18, da cuenta de lo rápido que la celda puede alcanzar los
niveles de saturación conforme se aumentan el número de usuarios. Además, cuando el planificador es
mixto (Alfa = 0.5), se obtienen los mejores resultados de capacidad (148 UE), lo que indicaría que este
planificador toma lo mejor de los planificadores RR y MaxC/I; sin embargo esta hipótesis debería ser
probada más extensamente (a través de más simulaciones) y ese no constituye el objetivo de esta tesis.
Por otra parte, cuando el planificador es más RR, para un número de UE pequeño (20) el retardo de la
aplicación es imperceptible, a diferencia de cuando el planificador es más Max C/I, aún para pocos
usuarios existe un retardo que incluso es cercano al valor preferible de retardo extremo a extremo
presentado en la sección 7.5.
Figura 19. Retardos por usuario para un path loss exponent de 3.3 y para pérdidas de 152dB.
Cuando el Path loss exponent se aumenta (Figura 19) se supone que aumentan las pérdidas pues según
la Ecuación (3) el valor de Path loss aumenta conforme aumenta este exponente. Esta vez la Figura 19,
y los valores de varianza (Tabla 16) no nos revelan mucha información, más que la intuición de que la
capacidad se ha reducido, dado que las pérdidas han aumentado. Esto lo confirmamos en la Figura 20.
Desviaciones estándar [ms] para un Path loss exponent de 3.3 y un máximo de pérdidas de 152 dB
20 UE 40 UE 60 UE 80 UE 100 UE 120 UE 140 UE 160 UE
Alfa 0.3 3.39 9.37 20.12 120.22 524.66 305.39 438.33 475.81
Alfa 0.5 3.48 6.5 31.26 62.47 524.49 456.27 437.61 395.02
Alfa 0.7 3.43 5.63 77.04 91.88 562.01 392.78 321.54 326.77
43
Alfa 0.9 3.04 7.41 24.82 180.05 495.31 235.28 438.32 326.97
Tabla 15. Desviaciones estándar en [ms] para un Path loss exponent de 3.3 y un máximo de pérdidas de
152 dB.
Figura 20. Retardo promedio según el número de usuarios, para un path loss exponent de 3.3 y
pérdidas máximas de 152 dB.
Las capacidades nuevas para este path loss exponent son de: 110 UE, 106 UE, 112 UE, 110 UE. Es
claro que estos valores son menores a los del caso anterior, lo que confirma nuestra hipótesis de que el
incremento en el path loss exponent ha causado una reducción en la capacidad de la celda. Más
interesante aún que esto, es que el comportamiento es menos exponencial que en el caso anterior, y
parece que es lineal por sectores. Esto implica que si se mejorara la tecnología -como para hacer el
retardo de la red, RTT, más bajo- se podrían agregar más usuarios sin que la capacidad se disminuya
tan abruptamente, sin embargo el número de usuarios soportados será inferior que para un ambiente
con path loss exponent de 2.7 (es decir, urbano).
Considerando el caso de aumentar el radio de la celda a 5km, y para un path loss exponent de 3.3
según la Tabla 8, las pérdidas máximas son de 160.466 dB, lo que implica que la capacidad va a ser
mucho menor. Efectivamente los resultados de capacidad disminuyen en más de un 77% siendo el
valor de capacidad cercano a 25 UE para todos los casos de Alfa. Sin embargo, la desviación estándar
de los promedios computados aumenta también considerablemente lo que hace que el resultado sea
poco confiable, indicando que se requerirían más simulaciones o un tiempo más largo de simulación
44
para analizar este caso. Presentamos los valores de desviación estándar para este caso de una celda con
radio de 5km, en la Tabla 16.
Desviaciones estándar [ms] para un Path loss exponent de 3.3 y un máximo de pérdidas de 160.466dB
20 UE 40 UE 60 UE 80 UE 100 UE 120 UE 140 UE
Alfa 0.3 46.26 22053 17447 75132 55110 150670 125000
Alfa 0.5 31.15 22066 16770 76624 54893 149940 125270
Alfa 0.7 40.18 22025 17523 72257 55127 150220 125210
Alfa 0.9 54.39 21940 17292 76071 55145 150220 125290
Tabla 16. Desviaciones estándar en [ms] para un Path loss exponent de 3.3 y un máximo de pérdidas de
160.466 dB.
Los valores de la Tabla 16, indican que existen usuarios que están siendo servidos muy poco por lo que
sus retardos alcanzan valores muy altos, y en esa medida hacen crecer el retardo promedio.
8.2. Capacidad de Video
En esta sección presentamos los resultados de las simulaciones del modelo de Video Streaming; para
152 dB simulamos para de Alfa de 0.5 y Path loss exponents (PLE) de 2.7 y 3.3.
Figura 21. Retardos por usuario para pérdidas de 152dB.
45
Figura 22. Retardo promedio según el número de usuarios, para pérdidas máximas de 152 dB.
Esta vez el retardo promedio según el número de usuarios es prácticamente lineal para ambos casos, y
de nuevo, si el PLE se hace mayor, el retardo promedio disminuye más rápido y por tanto la capacidad.
Si consideramos que las aplicaciones de Video Streaming no son tan exigentes respecto al retardo
promedio extremo a extremo, podemos considerar un retardo promedio de 500 ms uno aceptable.
Según esto las capacidades son de 20 UE y 25 UE para PLEs de 2.7 y 3.3 respectivamente. Sin
embargo, siguiendo el algoritmo de la sección 7.5 obtenemos un total de 100 UE para cada PLE. Dado
que la métrica que hemos asumido es la de jitter, consideramos el valor de capacidad igual al de 100
UE.
46
Figura 23. Retardo por cada usuario, para un radio de celda de 5km.
La Figura 23 demuestra que son pocos los terminales que puede albergar la celda dados los retardos
considerablemente altos. Esta gráfica no la usamos para determinar la capacidad sino como un medidor
del comportamiento cualitativo de la celda para los diferentes path loss exponent y alpha.
Según el jitter los resultados de capacidad son los de la Tabla 17.
Alfa 0.3 Alfa 0.5 Alfa 0.7 Alfa 0.9
PLE 1.8 88 59 56 64
PLE 2.7 84 57 58 58
PLE 3.3 61 59 55 58
Tabla 17. Número de usuarios permitidos para una celda de 5 km.
8.3. Aplicaciones de Web Browsing
8.3.1 Modelo Choi inicial
47
Las Figuras 24 y 25 muestran el caso del Modelo Choi complejo, para un máximo de pérdidas de 152
dB.
Figura 24. Retardos por cada usuario para el modelo de Choi inicial, para un máximo de pérdidas de
152 dB.
Figura 25. Retardos promedio del modelo Choi inicial, para un máximo de pérdidas de 152 dB.
Los resultados de las Figuras anteriores muestran los inconvenientes que el modelo de CHOI inicial
48
representa al implementarse en NS2; no son resultados que tengan mucha confiabilidad porque no
indican en ninguna forma un comportamiento esperado; los retardos promedio disminuyen cuando se
agregan más usuarios lo que no es consistente con la idea de capacidad y de limitación en los recursos
de radio, de códigos de WCDMA, etc... Por tanto presentamos las gráficas anteriores solo con el ánimo
de contrastarlas con los resultados del modelo Choi simplificado.
8.3.2 Modelo Choi simplificado
Figura 26. Retardos por cada usuario para el modelo de Choi simplificado, para un máximo de pérdidas
de 152 dB.
Es claro que el modelo Choi simplificado da resultados que son consistentes con la idea del
comportamiento de capacidad para una celda HS. Las capacidades no se alcanzan a establecer, porque
para un valor de 160 usuarios en todos los casos, los retardos extremo a extremo son mucho menores
que el valor de 4s. No se puede simular para más usuarios, por limitaciones de procesamiento.
49
Figura 27. Retardos promedio del modelo Choi inicial, para un máximo de pérdidas de 152 dB.
20 UE 40 UE 60 UE 80 UE 100 UE 120 UE 140 UE 160 UE
Alfa 0.3 2.57 2.87 7.48 33.75 236 715.16 1050.8 1121.7
Alfa 0.5 2.23 2.76 8.14 69.7 297.93 736 1079.7 986
Alfa 0.7 2.17 3.48 8.49 59.42 208.77 585.53 584.38 541.72
Alfa 0.9 2.33 2.55 6.55 16.22 193.85 376.33 293.38 175.12
Tabla 18. Desviaciones estándar [ms] para un PLE de 2.7 y 152 dB de pérdidas máximas.
20 UE 40 UE 60 UE 80 UE 100 UE 120 UE 140 UE 160 UE
Alfa 0.3 0.936 18.95 5.23 9.83 20.73 464.88 952.24 1127.9
Alfa 0.5 0.86 2.54 4.21 7.8 27.37 447.93 947 848.27
Alfa 0.7 0.85 2.93 4.38 8.83 30.86 351.8 687.17 497.44
Alfa 0.9 1.07 1.8 5.08 6.82 42.67 285.73 344.48 193.25
Tabla 19. Desviaciones estándar [ms] para un PLE de 3.3 y 152 dB de pérdidas máximas.
Los resultados de las desviaciones estándar consignadas en las dos tablas anteriores, dan constancia de
lo ajustado que es el modelo para cantidades de usuarios pequeñas; cuando incrementa el número de
50
usuarios, incrementa la desviación de los datos, en algunos casos pudiendo hacer que el retardo sea el
doble del presentadoen la Figura 27.
El modelo anterior presenta un comportamiento globalmente exponencial; sin embargo, alrededor de
los 130 usuarios (en otros casos 120 usuarios) la Figura 27 tiene un comportamiento lineal que nos
permitiría extraer los valores de capacidad, si logramos plantear el modelo lineal de estos intervalos.
Planteamos un modelo lineal para cada caso, teniendo en cuenta que conforme se incrementa el número
de usuarios parecería -según la Figura 27- que la pendiente por intervalos de 20 va disminuyendo hasta
hacerse casi igual a la del intervalo anterior; esto quiere decir que para más de 160 usuarios la
pendiente del intervalo 160-180 puede ser considerada casi igual a la del intervalo 140-160. Según esa
idea las capacidades y las ecuaciones de recta usadas, se consignan en la Tabla 20.
Alfa 0.3 Alfa 0.5 Alfa 0.7 Alfa 0.9
PLE 2.7
y = 23 .1x −2450279 usuarios
y = 24 .2x −2519269 usuarios
y = 27 .3x −2823249 usuarios
y = 30 .1x −2965231 usuarios
PLE 3.3
y = 21 .5x −2369296 usuarios
y = 23 .8x −2667280 usuarios
y = 25 .8x −2898267 usuarios
y = 25 .6x −2897259 usuarios
Tabla 20. Aproximaciones lineales para más de 160 usuarios y un máximo de pérdidas de 152 dB.
Es claro que la capacidad de aplicaciones de web browsing es la mayor de todas; este resultado es
favorable para un operador, dado que el tráfico web es el más concurrido por los usuarios [DIRK_00],
lo que implica que las celdas tolerarán gran cantidad de usuarios cuando se trata de tráfico web.
Añadido a esto, hay que decir que el sostenimiento de conexiones del terminal a la red no se realiza
nunca en una sola celda, siempre hay procedimientos de handover y celdas vecinas que envían
información al usuario simultáneamente, lo que tendría un impacto en la capacidad de la red, no solo
porque hay más “recursos” disponibles para el terminal (es servido por más “proveedores de recursos”,
las BS) sino porque también hay más interferencia, lo que siempre significa un reto para los
diseñadores de terminales.
9 COBRO POR EXTRALIMITACIÓN
Los planes de tarifas que los operadores manejan dependen de muchos factores y a menudo hacen parte
del triple proceso de planificación, análisis y optimización de una red celular. Últimamente se han
propuesto tarifas únicas que manejan un precio por mes, en el que se cobra un recargo al usuario
cuando incurre en un uso excesivo (supera un límite de capacidad en GB) del medio. El precio que se le
cobra al usuario cada mes se calcula con elementos inherentes a la red (costo mantenimiento
dispositivos, ubicación del servicio, etc..) y no es el propósito de esta sección (ni de este proyecto); en
51
vez de ello, se asume una tarifa mensual y se propone cuánto se le debería cobrar a un usuario por
extralimitarse en la cantidad de información descargada o usada durante su mes.
En [HOL_06, pp. 151-153] se expone una simplificación del cálculo de la cantidad de GB que un
usuario puede recibir por mes, hasta que la red no le pueda suministrar más recursos. Estos resultados
no diferencian entre servicios, sino que consideran a la información como un todo en “bruto”. Sin
embargo dado que hay ciertos servicios que saturan más rápido la red -en términos de QoS- dichos
servicios son los que determinan la calidad de la experiencia del usuario. Estos resultados los
presentamos y los usamos en lo que sigue. Hay ciertas suposiciones que vale la pena mencionar en ese
cálculo de capacidad:
• Eficiencia espectral de 2Mbps/celda, usando un terminal HSDPA con una sola antena y un solo
receptor RAKE.
• Eficiencia espectral de 4Mbps/celda usando un terminal HSDPA con diversidad de antena y un
receptor ecualizador.
• Porcentaje de uso de la red en horas de congestión: 80%
• Porcentaje del día de las horas de tráfico: 20%
El tráfico total en GB/mes/sector para los dos casos anteriores es de 650 (un solo receptor RAKE) y
1170 (receptor ecualizador). Esto implica que pueden ser suscritos aproximadamente 300 usuarios con
capacidades entre 2 y 4 GB por mes por sector. La Tabla 21 muestra la cantidad de GB/usuario/mes
como función de la cantidad de usuarios suscritos para un solo receptor RAKE (peor caso)
# suscritos 100 150 200 250 300 350 400 450 500 550 600
GB/usuario/mes
6.2 4.1 3.2 2.4 2 1.8 1.6 1.4 1.2 1 0.8
Tabla 21. GB por usuario por mes como función de la cantidad de usuarios suscritos, para un solo
receptor RAKE.
De igual forma el costo que cada GB le supone al operador, depende de gran cantidad de variables;
suponemos la aproximación en [HOL_06, p. 153] en donde se presenta el costo por cada GB (en euros)
como función del precio por sector por portadora. Asumiendo un precio por sector por portadora de
16000 euros, el precio que cada GB le cuesta a un operador es de 2 euros.
Primero extraemos lo que denominamos “coeficientes de cobro”, cocientes de proporción de cuánta
capacidad están por debajo las aplicaciones que se saturan más rápido. Vienen dados por la Ecuación
(31) (para el caso de Video, se tienen para un Alfa de 0.5 para pérdidas de 152 dB):
52
Coeficiente1 =CapacidadWebCapacidadVoIP
, Coeficiente2 =CapacidadWebCapacidadVideo
(31)
Coeficiente 1
PLE 2.7 PLE 3.3
Alfa 0.3 2.14 2.69
Alfa 0.5 1.81 2.64
Alfa 0.7 1.91 2.38
Alfa 0.9 1.65 2.35
Coeficiente 2
Alfa 0.5 2.69 2.8
Tabla 22. Coeficientes para el caso de pérdidas máximas de 152 dB.
Como el planificador está definido, esa no es una variable en el esquema de recargos, entonces
podemos elegir un Alfa cualquiera para realizar la tarifa de cobro. El PLE sin embargo, es variable,
depende del tipo de ambiente de propagación en el que se encuentre el usuario, y por tanto no se elije
uno preciso. Además la red conoce en qué tipo de ambiente se encuentra el terminal, y tiene una
sección de la Core Network encargada de tarifar al usuario, por lo que para cada PLE se le cobra de
una manera diferente al usuario.
Dado que se simula para 30 minutos, estas capacidades están dadas para esta cantidad de tiempo. Por
tanto, si el usuario está activo (descargando información) más de 30 minutos, por cada persona que
ingrese a la celda se le cobrará una cantidad igual a:
donde las variables son:
NPersonas30min , la cantidad de personas que ingresan en la celda y están un promedio de 30 min.
GB30min , la cantidad de GB que el usuario usa en el intervalo que se queda de 30 min.
TasaCambioEuro , conversión de Euros a Pesos colombianos.
Con la Ecuación (32) lo que se pretende es cobrarle al usuario por usar la red mucho tiempo continuo,
lo que en otras palabras quiere decir por los GB que usa demás a los permitidos, puesto que en el caso
de los permitidos es parte de la planificación del operador de red contar con la cantidad de GB que se le
permiten a un usuario (comúnmente esa cantidad de GB está en el rango de valores mostrados en la
Tabla 21).
La Ecuación (32) sin embargo no está teniendo en cuenta las aplicaciones que utiliza el usuario, y que
pueden hacer saturar la red más rápido; para tener esto en cuenta usamos la Ecuación (33):
53
Precio(Exceso /Per )$ = NPersonas30min∗2∗GB30min∗TasaCambioEuro (32)
DineroCobrado = %UsoVoIP∗Coeficiente1∗Precio(Exceso /Per )+%UsoVideo∗Coeficiente2∗Precio(Exceso /Per)
+%UsoWeb∗Precio(Exceso /Web) (33)
10 MEJORAS FUTURAS
Como una continuación del proyecto, o como un mejoramiento del mismo se podrían seguir las
recomendaciones de [MUT_08]:
• Reconsiderar modificar la forma de adjuntar archivos de propagación a los terminales.
Actualmente se utiliza MATLAB para anexar los CQI y SNR, pero estos archivos son
sumamente pesados (del orden de 200MB a 700 MB), dado que cada segundo de simulación
genera 23 KB de datos para cada usuario lo que implica que para nuestro caso, con 30 minutos
de simulación y 160 usuarios se requieren 5. 76 GB de memoria, lo que hace que este tipo de
simulaciones no puedan ser usadas en computadores de media gamma, y utilizan exagerados
recursos. Existen módulos desarrollados en C++ que pueden ser usados para traducir archivos
de MATLAB al lenguaje de C++.
• Se podrían desarrollar o usar módulos que implementen la funcionalidad de Handover tan
determinante en una red real celular.
• Implementar los modelos de tráfico como módulos aparte en C++, dado que al ser
implementados en un lenguaje de mayor nivel (Otcl) que C++ se desperdician recursos del
sistema, y se hacen pesadas las simulaciones.
• Desarrollar algoritmos de cálculo de las métricas de desempeño más sofisticados que incluyan
las características propias de cada aplicación; ejemplo, en el caso de video, codecs. Estos
algoritmos deben ser realizados en C++ para optimizar recursos de procesamiento, y
eventualmente estar compenetrados con el simulador.
• Modificar el módulo de trazas de NS2 o (desarrollar uno propio) para que se obtenga solo la
información requerida por el algoritmo de cálculo de las métricas de desempeño.
• Evaluar el desempeño de llamadas de voz, es decir las realizadas en el dominio CS.
• Evaluar el desempeño de VoIP sobre DCH, o de alguna otra aplicación sobre este canal.
11 CONCLUSIONES
• Las aplicaciones más demandantes de recursos (tasa de transferencia garantizada y alta, retardo
bajo) son las que saturan más rápidamente la celda. Más aún, el comportamiento de la métrica
de retardo extremo a extremo crece de una manera exponencial con el número de usuarios que
se agregan a la celda, lo que implica que se debe planificar muy bien la distribución de las
celdas para que la QoS que cada terminal experimenta no sea mala.
• La dependencia del desempeño de aplicaciones respecto al planificador usado, no se pudo
probar en su totalidad, si bien se realizó la hipótesis de que el desempeño de las aplicaciones era
54
sensible de esa elección; algunas de las razones principales para ello estriban en que las
simulaciones contienen modelos de tráfico que contienen distribuciones de probabilidad cuya
variación de simulación a simulación puede ser importante; así, por ejemplo, en una simulación
de Web se pueden hacer 10 Llamadas de paquetes, mientras que en otra se hacen 33 y en otra 2.
Se requieren por tanto varias muchas simulaciones, pero esto constituye también un
inconveniente debido a los tamaños de los archivos a procesar y a la gran cantidad de
información que se debe manejar y filtrar. Para solucionar esto, se deben incurrir en las mejoras
presentadas en la sección 11.
• La dependencia respecto al exponente de pérdidas por distancia es clara y definida. Esto implica
que cierto tipo de ambientes además de causar más pérdidas y una reducida capacidad,
representan un reto para el operador que ya no solo debe planificar la ubicación de las celdas (y
su tamaño), sino debe estar seguro de que la población de este tipo de ambientes es lo suficiente
como para justificar la inversión de comprar terrenos e implementar las celdas.
• El software de EURANE contiene algunas de las características más importantes de HSDPA.
Sin embargo, la versión usada es de hace más de 5 años lo que implica que se han quedado atrás
algunas cosas (por ejemplo la velocidad de transferencia del canal Hs-DSCH ha aumentado
considerablemente en el último período). Por otra parte requiere grandes cantidades de
memoria, lo que es una limitación si se quieren hacer simulaciones a pequeña escala sin una
inversión en computadores. El software es atractivo porque es de licencia libre y se usa en
investigación, pero para usos comerciales, debería ser considerado usar simuladores más
precisos y confiables.
12 BIBLIOGRAFÍA
[MUT_08] NS-2 Enhancements for Detailed HSDPA Simulations. MUTAIRI, Abdulmohsen,
BAROUDI, Uthman. 2008
[HOL_06] HSDPA/HSUPA for UMTS. HOLMA, Harri, TOSKALA, Antti. John Wiley & Sons.
2006.
[DIRK_00] Source Traffic Modeling of Wireless Applications. STAEHLE, Dirk, LEIBNITZ, K.,
TRAN-GIA, P. Universität Würzburg, Institu für Informatik, Research Report Series, Report 261. 2000.
[GAO_09] Asymptotic Behaviour of Tail Density for Sum of Correlated Lognormal Variables. GAO,
Xin, XU, Hong, YE, Dong. International Journal of Mathematics and Mathematical Sciences. 2009.
[JAHAN_08] Internet Traffic Modeling and Capacity Evaluation in UMTS. DADKAH, Jahangir,
HAKKAK, Mohammad, AZMI, Paeiz. International Journal of Hybrid Information Technology. Vol. 1,
No. 2, 2008.
55
[CHO_99] A Behavioral Model of Web Traffic. CHOI, Hyoung, LIMB, John. Network Protocols,
ICNP Proceedings, Seventh International Conference. 1999.
[HOL_10] WCDMA for UMTS: HSPA Evolution and LTE. HOLMA, Harri, TOSKALA, Antti. John
Wiley & Sons. Fifth Edition. 2010.
[WANG_05] Performance Enhancements of UMTS networks using end-to-end QoS provisioning.
WANG, Haibo, PRASAD, Devendra, TEYEB, Oumer, SCHWEFEL, Peter. Universidad Aalborg.
2005.
[SOL_05] QoS Managment in UMTS Terrestrial Radio Access FDD Networks. SOLDANI, David.
Helsinki University of Technology. Documento de Tesis Doctoral. 2005.
[STUCK_03] Traffic Engineering Concepts for Cellular Packet Radio Networks with QoS Support.
STUCKMAN, Peter. Universidad de Renania-Westfalia. Tesis Doctoral. 2003.
[NYBERG_01] A Streaming Video Traffic Model for the Mobile Access Network. NYBERG,
Henrik, JOHANSSON, Christer, OLIN, Birgitta. Ericson Research, Suercia. 2001.
[HASS] Aggregate Traffic Models for VoIP Applications. HASSAN, H., GARCIA, J.M.,
BOCKSTAL, C. Digital Telecommunications, ICDT International Conference. 2006.
[YONG] VoIP Service on HSDPA in Mixed Traffic Scenarios.YONG-SEOK, Kim.
Telecommunication Network Business, Samsung Electronics. 2006.
[FIORE] Archivos de procesamiento del profesor FIORE, Marco, disponibles en
http://perso.citi.insa-lyon.fr/mfiore/research.html.
[LAI_06] Radio Network Planning and Optimisation for UMTS. LAIHO, Jaana, WACKER,
Achim, NOVOSAD, Tomás. John Wiley & Sons. Second Edition. 2006.
[EUMA_05] Enhanced UMTS Radio Access Networks Extensions for NS-2: User Guide Release 1.6.
SEACORN Project, 2005.
[EUDAT_03] Deliverable D3.2v2: End-to-end network model for Enhanced UMTS. SEACORN,
Project, 2003.
[NS_11] The ns Manual (formerly ns Notes and Documentation). VINT Project, Xerox,
Universidad de Berkeley. 2011.
[TSE_05] Fundamentals of Wireless Communications. TSE, David, VISWANATH, Pramod.
Cambridge University Press, 2005.
[PRAKASH_11] Introduction to Wireless and Mobile Systems. PRAKASH, Dharma, ZENG,
Qing-An. Cengage Learning. Third Edition. 2011.
[RAPPA_02] Wireless Communications: Principles and Practice. RAPPAPORT, Theodore. Second
Edition. 2002.
56
13 ANEXO A. CÓDIGO BASE TCL
Código ejemplo de VoIP
global ns
remove-all-packet-headersadd-packet-header MPEG4 MAC_HS RLC LL Mac RTP TCP IP Common Flags
if {$argc == 1} { set users [lindex $argv 0]}set ns [new Simulator]set f [open "VoIP-$users-U-2.7-0.5.tr" w]set NumUE $users
UMTS/RLC/UMHS set flow_max_ 240Mac/Hsdpa set flow_max_ 240Mac/Hsdpa set scheduler_type_ 2Mac/Hsdpa set alpha_ 0.5proc finish {} {
global fclose $fputs " Simulation ended."exit 0
}
$ns node-config -UmtsNodeType rnc
set rnc [$ns create-Umtsnode]
$ns node-config -UmtsNodeType bs \-downlinkBW 384kbs \-downlinkTTI 10ms \-uplinkBW 384kbs \-uplinkTTI 10ms \-hs_downlinkTTI 2ms \-hs_downlinkBW 5.4Mbs \
set bs [$ns create-Umtsnode]
$ns setup-Iub $bs $rnc 622Mbit 622Mbit 15ms 15ms DummyDropTail 2000
57
$ns node-config -UmtsNodeType ue \-baseStation $bs \-radioNetworkController $rnc
for { set i 1 } { $i <= $NumUE } { incr i 1 } {set ue($i) [$ns create-Umtsnode]
}
set sgsn0 [$ns node]set ggsn0 [$ns node]
for { set i 1 } { $i <= $NumUE } { incr i 1 } {set k [expr $i - 1]set servidor($k) [$ns node]
}
$ns duplex-link $rnc $sgsn0 622Mbit 0.4ms DropTail 1000$ns duplex-link $sgsn0 $ggsn0 622MBit 10ms DropTail 1000
for { set i 1 } { $i <= $NumUE } { incr i 1 } {set k [expr $i - 1]$ns duplex-link $ggsn0 $servidor($k) 10MBit 35ms DropTail 1000
}$rnc add-gateway $sgsn0
set rng [new RNG]$rng seed 1
for { set i 1 } { $i <= $NumUE } { incr i 1 } {set k [expr $i - 1]set tcp($k) [new Agent/UDP]$tcp($k) set packetSize_ 512$tcp($k) set fid_ $k$ns attach-agent $servidor($k) $tcp($k)
}for { set i 1 } { $i <= $NumUE } { incr i 1 } {
set k [expr $i - 1]set sink($k) [new Agent/Null]$sink($k) set fid_ $k$ns attach-agent $ue($i) $sink($k)$ns connect $tcp($k) $sink($k)
}
################################ Fuentes de Trafico ###############################
set PacketCallsPerSession(1) 10set BitRate 64000
58
for {set i 1} {$i <= $NumUE} {incr i 1} {for { set j 1} {$j <= $PacketCallsPerSession(1) } {incr j 1} {
set RNTime($i$j) [new RNG]$RNTime($i$j) seed 0
set VoIP($i$j) [new Application/Traffic/CBR]; ### Corresponde a VideoStreamming$VoIP($i$j) set packetSize_ 70$VoIP($i$j) set rate_ [expr ($BitRate/8)]
set OffTimeTmp($i$j) [new RandomVariable/Exponential]$OffTimeTmp($i$j) set avg_ [expr (1/5.69)]$OffTimeTmp($i$j) use-rng $RNTime($i$j)set OffTime($i$j) [expr [$OffTimeTmp($i$j) value]]
set OnTimeTmp($i$j) [new RandomVariable/Exponential]$OnTimeTmp($i$j) set avg_ [expr (1/7.24)]$OnTimeTmp($i$j) use-rng $RNTime($i$j)set OnTime($i$j) [expr [$OnTimeTmp($i$j) value]]
}}
################ Asignación de aplicaciones a agentes TCP #################
for {set i 1} {$i <= $NumUE} {incr i 1} {set h [expr $i - 1]for { set j 1} {$j <= $PacketCallsPerSession(1) } {incr j 1} {
$VoIP($i$j) attach-agent $tcp($h)}
}######## Configuracion modulo HSDPA, capacidades y retardos en DL y en UL#######$ns node-config -llType UMTS/RLC/UM \
-downlinkBW 384kbs \-uplinkBW 384kbs \-downlinkTTI 10ms \-uplinkTTI 10ms \-hs_downlinkTTI 2ms \-hs_downlinkBW 5.4Mbs
$ns create-hsdsch $ue(1) $sink(0)
for { set i 2 } { $i <= $NumUE } { incr i 1 } {set k [expr $i - 1]$ns attach-hsdsch $ue($i) $sink($k)
}########## Asignacion de modelos de propagacion a los distintios UE ###############for { set i 1 } { $i <= $NumUE } { incr i 1 } {
59
set k [expr $i - 1]$bs setErrorTrace $k "./PedA2-Plexp-2.7-3kmh/PedA2_3km_plexp_2.7$i"
}
$bs loadSnrBlerMatrix "SNRBLERMatrix1"
for { set i 1 } { $i <= $NumUE } { incr i 1 } {$ue($i) trace-inlink $f 2
}
############# Filtro para los flujos en la traza ###############for { set i 1 } { $i <= $NumUE } { incr i 1 } {
set k [expr $i - 1]$ns trace-queue $ggsn0 $servidor($k) $f $ns trace-queue $servidor($k) $ggsn0 $f
}############### Asignacion de tiempos de inicio y de parada ################for {set i 1} {$i <= $NumUE} {incr i 1} {
for {set j 1} {$j <= $PacketCallsPerSession(1) } {incr j 1} {set k [expr $j - 1]if {$j == 1} {
set StartTime($i$j) 0set StopTime($i$j) $OnTime($i$j)
} else {set StartTime($i$j) [expr ($StopTime($i$k) + $OffTime($i$j))]set StopTime($i$j) [expr ($StartTime($i$j) + $OnTime($i$j))]
}$ns at $StartTime($i$j) "$VoIP($i$j) start"#puts "App(1$m$h) start $StartTime($m$l)"$ns at $StopTime($i$j) "$VoIP($i$j) stop"#puts "App(1$m$h) stop $StopTime($m$l)"
}}
$ns at 1750.0 "finish"puts " Simulation is running ... please wait ..."$defaultRNG seed 10$ns run
60
14 ANEXO B. CÓDIGO PERL RETARDO
Cálculo del retardo extremo a extremo total
$infile = $ARGV[0];
$traffic = $ARGV[1];
$size = $ARGV[2];
$NameOutput = $ARGV[3];
$Avg_E2E_Delay = 0;
$Delay_Acum = 0;
$cont = 1;
$Intervalo = 0;
@tiempo = ([0],[0]);
open(DATA,"<$infile")|| die "Can't open $infile $!";
open(Retardo,">>$NameOutput.txt");
while(<DATA>)
{
@x= split (' ');
if(($x[4] eq "$traffic")&&($x[5] == $size)&&($x[0] eq '+'))
{
$tiempo[$x[11]][$x[7]] = $x[1];
}
if(($x[4] eq 'AM_Data')&&($x[5] == 40)&&($x[0] eq 'r'))
{
if($tiempo[$x[11]][$x[7]]!=0)
{
$Intervalo = $x[1]-$tiempo[$x[11]][$x[7]];
$Delay_Acum = $Delay_Acum + $Intervalo;
$cont = $cont+1;
}
}
}
$Avg_E2E_Delay = $Delay_Acum/$cont;
print Retardo "$Avg_E2E_Delay \n";
close DATA;
close(Retardo);
exit(0);
61
