u622580

Vista previa del material en texto

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.......................................................................................................5
2.2. Objetivos generales....................................................................................................................6
2.3. Objetivos específicos.................................................................................................................6
2.4. Alcance......................................................................................................................................6
 3 CARACTERÍSTICAS DE PROPAGACIÓN DE ONDAS DE RADIO..............................................7
3.1. Mecanismos de propagación......................................................................................................7
3.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......................................................................................................10
4.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)..........................................................14
4.4. Algoritmos de planificación (Scheduling)...............................................................................14
4.5. Canales lógicos y de transporte...............................................................................................15
4.6. Canales físicos.........................................................................................................................16
4.7. Provisión de QoS.....................................................................................................................17
 5 CARACTERÍSTICAS BÁSICAS DE HSDPA..................................................................................18
5.1. El nuevo canal común..............................................................................................................18
5.2. Rápida adaptación del enlace...................................................................................................18
5.3. HARQ......................................................................................................................................19
 6 CARACTERÍSTICAS DE SIMULACIÓN........................................................................................19
6.1. Elección y características del simulador..................................................................................19
6.2. Características del módulo EURANE.....................................................................................20
6.3. Topología de estudio................................................................................................................20
6.4. Estructura física e interfaz Au..................................................................................................22
6.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...................................................................................................................32
7.1. VoIP.........................................................................................................................................32
7.2. Streaming (Video)....................................................................................................................34
7.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.....................................................................................................................41
8.2. Capacidad de Video.................................................................................................................45
8.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 UltraHigh 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 unafrecuencia 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áfico
Conversacional 
(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 transferencia
KPI (End-to-End delay, 
One-way)
Audio Voz (CS) 4-25 kbps
Inferior a 150 ms 
(preferiblemente)
400 ms (valor límite)
Video Videophone 32-384 kbps
Inferior a 150 ms 
(preferiblemente)
400 ms (valor límite)
Datos Juegos en RT Inferior a 60 kbps
Inferior 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 transferencia
KPI (End-to-end delay, 
one way)
17
Audio Mensajes de voz 4-12 kbps
Inferior a 1 s para 
reproducir
Inferior 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)
Audio
Música de alta calidad, 
grabaciones de música y 
voz.
5-128 kbps Inferior a 2 s
Video
Movie clips, Videos de 
RT
20-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 ventanaque 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 seagrega 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(
I
intra
−L
Total
10 )
+ 10
(
I
inter
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 vector
Tipos de elementos 
pertenecientes a esa 
variable/vector
Descripció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 ms
Video: 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ón
De 
Variables
Todos los contadores
Iguales a 1
Cómputo QoS_App_i
Simulación NS2:
Alfa = Alfa k
PLE = PLE j
App = App i
NumUE = 1
ContAlfas<=NMaxAlfas
ContApps<=NMaxApps
QoS_App_i <= TH_QoS_App_i
ContPLE<=NMaxPLEsContApp++
ContAlfa++
ContPLE++
Agrego un UE al script de simulación
NumUE++
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 m
Es 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 100
Mínimo de muestras para realizar los cómputos 
de fading
Maximo número de muestras por 
TTI
10
Muestras discretas para realizar los cálculos de 
CQI, SNR, entre otros, para intervalos de 
tiempo discretos. 
Potencia de transmisión 38 dBm – 6.31 W
Valor de la potencia de transmisión de un 
terminal. Valor típico
Ganancia de la antena de la BS 17 dBi
Factor de amplificación de la antena receptora 
en el Nodo B. Valor típico.
Linit 137.4 dB
Pérdida por una distancia de 1km para una 
antena de 30m de altura. Ecuación (3)
IntraCell Interferencia 30 dBm
Interferencia debida a la no ortogonolidad de 
los códigos de los canales compartidos.
InterCell Interferencia -70 dBm
Interferencia debida a la presencia de otras 
celdas.
Shadowing deviation 8 dB
Es la desviación estándar de la variable 
gaussiana de la Ecuación (3)
CQITTIdelay 3
Nú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] = TiempoActual
Vtiempo[Packet_IDActual] = TiempoActual
Evento = '+'
Evento = '+'
FlowActual = Flow_ID'
FlowActual = Flow_ID'
PackTypeAcual = PackTypeRecv'
PackTypeAcual = PackTypeRecv'
Intervalo = TiempoActual -Vtiempo [Packet_IDActual
Intervalo = TiempoActual -Vtiempo [Packet_IDActual
DelayAcum = DelayAcum + Intervalo
DelayAcum = DelayAcum + Intervalo
NumPacks++
NumPacks++
Fin Traza
Simulación
Fin Traza
Simulació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 = 0
I = 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ón
Valor Parámetros de 
Distribución
Valor
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
Object
Size
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 σ X
2 , 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
Object
Size
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 deLlamadas 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 ,σ1
2 y μ2 ,σ 2
2 , entonces se 
cumplen las siguientes propiedades:
1. Z = aX se distribuye Log-Normal con parámetros μZ = μ+ ln (a ) y σ Z
2
= σ 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
σY
2 = log(∑ e
(2μ j +σ j
2) (e( σ j
2 )
−1)
(∑ e(μ j +σ j
2
/2))
2
+1) (28 )
μY = log (∑ e(
μ j +σ j
2/2))−σY
2
2
(29 )
μObjUnico = μY : ( μ1=μMAINObj ;μ2=μZ : (μ=μINLINEObj ,a=N INLINEObj) )
σ ObjÚnico
2 = σ Y
2 (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