Chapter 6: Conclusion and Future Work
6.2 Recommendations for Future Work
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
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.
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
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 −2450 279 usuarios y = 24 . 2x −2519 269 usuarios y = 27 . 3x −2823 249 usuarios y = 30 .1x −2965 231 usuarios PLE 3.3 y = 21 .5x −2369 296 usuarios y = 23 . 8x −2667 280 usuarios y = 25 . 8x −2898 267 usuarios y = 25 . 6x −2897 259 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
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):
Coeficiente1 = CapacidadWeb
CapacidadVoIP, Coeficiente2 =
CapacidadWeb
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):
Precio(Exceso/ Per )$ = NPersonas30min∗2∗GB30min∗TasaCambioEuro (32)
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
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.
[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.
13 ANEXO A. CÓDIGO BASE TCL
Código ejemplo de VoIPglobal ns
remove-all-packet-headers
add-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_ 240 Mac/Hsdpa set flow_max_ 240
Mac/Hsdpa set scheduler_type_ 2 Mac/Hsdpa set alpha_ 0.5
proc finish {} { global f close $f
puts " 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 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) 10
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 } {
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) 0
set 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
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);