1

Anlisis de trfico en un servidor de VoIP

Orlando Micolini, Member, IEEE; Augusto J. Herrera, GSM, IEEE; Vctor Sauchelli
Abstract This paper describes a traffic study over a VoIP server. The aim is to perform a study to know the traffic of communications of the current system installed and so what is the bandwidth needed to replace the existing traditional phone system for a new IP telephony system. After this study we used a simulator to know which is the maximum traffic supported by the VoIP server, to know if the system can support all users connected. Finally there will be a study to know what the bandwidth needed to establish a link between two VoIP servers located at two sites separated by a distance of 3 Km. Resumen El presente trabajo busca realizar un estudio de trfico sobre un servidor de VoIP. Lo que se pretende realizar es un estudio que permita conocer cul es el trfico de comunicaciones del sistema actual instalado y de esta manera cual es el ancho de banda necesario para reemplazar un sistema de telefona tradicional actualmente instalado por un sistema de telefona IP. Luego de este estudio se utilizar un simulador para conocer cul es el trfico mximo soportado por el servidor de VoIP, de maneras de saber si puede soportar la carga del sistema completo. Por ltimo se har un estudio que permita conocer cul es el ancho de banda necesario para establecer un enlace entre dos servidores de VoIP ubicados en dos sedes separadas por una distancia de 3 Km. Keyword VoIP, ancho de banda, BW, trfico, Erlang, SIP, IAX, cRTP, cdec, g.711, g.729.

IAX, un protocolo propuesto por los desarrolladores de Asterisk como protocolo para usar en VoIP. A. Ancho de banda de las comunicaciones de VoIP Otro aspecto interesante es el cdec a utilizar en las comunicaciones, el cual incidir directamente en el ancho de banda necesario para implementar un sistema de VoIP. Al momento de elegir un protocolo hay muchas opciones, entre las ms importantes se encuentran los descriptos en la tabla I.

I. INTRODUCCIN

En nuestro caso solo no limitaremos realizar los clculos con la suposicin de que utilizaremos los protocolo g.711 y g.729, ya que realmente estos dos son los cdec que estn utilizando el servidor de VoIP instalado. Sin embargo hay que resaltar que el sistema maneja todos los protocolos arriba mencionados. B. Overhead agregado por los encabezados Como vemos en la tabla I los cdec utilizan poco BW (a excepcin del cdec g.711), sin embargo hay una sobrecarga adicional introducida por los encabezados IP, UDP y RTP en los paquetes de voz que termina incidiendo en el ancho de banda final necesario para establecer las comunicaciones. En nuestro caso, como ya dijimos, solo utilizaremos para realizar las pruebas los cdec g.711 y g.729, dentro de la red ethernet. De [2] [3] obtenemos que el ancho de banda aproximado necesario para cada cursar cada comunicacion ser de 95 kbps para el cdec g.711 (Ethernet + IP + UDP + RTP + G.711) y 31,2 kbps para g.729 (Ethernet + IP + UDP + RTP + G.729). Conociendo estos datos, haremos ahora un estudio para estimar cuantos canales se necesitan y cul es el ancho de banda necesario para cursar las comunicaciones. II. ANLISIS DE TRFICO MTODO ERLANG A. Mtodo Erlang Erlang es una unidad de medida utilizada en teletrfico[ 4] [5] para medir el trfico de las comunicaciones. En la prctica es usado para describir el volumen de trfico por hora. Estas medidas se hacen para establecer el tamao del troncal necesario para cursar el trfico de las comunicaciones. En

os sistemas de telefona IP han tenido un rpido crecimiento y gran aceptacin en los ltimos aos, siendo actualmente instalados y utilizados en una gran cantidad de instituciones y universidades. El presente trabajo busca conocer cules son las limitaciones que un servidor de VoIP, de manera tal de conocer si es factible migrar el actual sistema de telefona tradicional instalado en la Facultad de Ciencias Exactas, Fsicas y Naturales (FCEFyN) de la Universidad Nacional de Crdoba (UNC) por un nuevo sistema de telefona IP. El sistema actual instalado en la FCEFyN consiste en una central de telefona tradicional con tres lneas directas conectadas a la PSTN, atendiendo 139 internos distribuidos en la facultad. El estudio que se har busca conocer cual son los requisitos necesarios para migrar este sistema a un sistema de VoIP. Para ello se realizarn estudios estimado el trfico cursado de manera de poder conocer cul es la cantidad de canales que se deben utilizar como as tambin el ancho de banda de cada canal. Conocer el ancho de banda (BW) necesario para las comunicaciones es uno de los puntos ms importantes de la voz sobre IP, y depender en gran medida del protocolo y cdec utilizado [1]. En nuestro caso realizaremos los clculos utilizando el protocolo SIP, un estndar muy usado y recomendado en varias RFCs, como as tambin el protocolo

2 nuestro caso lo utilizaremos para conocer cul es el volumen de trfico cursado, cual es el ancho de banda necesario y cuantos canales de datos o nmero de enlaces son necesarios para reemplazar el sistema de telefona existente en la FCEFyN. Una de las variables que necesitamos conocer o estimar para realizar los clculos es el grado de servicio (GoS), que define la probabilidad de que las llamadas sean bloqueadas por falta de lnea. En nuestro caso vamos a adoptar un GoS de 0,05 (5 llamadas bloqueadas cada 100 ofrecidas). Con todo esto estamos en condiciones de calcular la cantidad de canales necesarios y el ancho de banda para realizar las comunicaciones. Para ello estimaremos el trfico ofrecido y el volumen de trfico. B. Trfico ofrecido Para realizar una estimacin de trfico ofrecido vamos a suponer que cada uno de los 139 internos que hay en la FCEFyN realiza dos llamadas de 3 minutos en la hora cargada. El clculo utilizando esa estimacin suele ser bastante acercado a la realidad. Con estos datos podemos calcular el volumen de trfico, es decir el tiempo total acumulado de las comunicaciones. 1=

Fig. 1 Trfico ofrecido, cursado y canales necesarios para el caso estudiado.

C. Estimacin del ancho de banda necesario Conociendo la cantidad de canales estamos en condiciones de estimar el ancho de banda necesario, el cual depender de los cdec utilizados para las comunicaciones. Como vimos en la seccin anterior solo se utilizarn dos cdec, g.711 y g.729, que requieren un ancho de banda de 95 kbps y 31,2 kbps por llamada, respectivamente. Con todo esto el ancho de banda del enlace ser el mostrado en la tabla II.

V = 139 usuario * 2 llamada/usuario * 3 min/llamada

V 1,514 c dm = 834 minutos V t hora i

i 1

10

Donde c es la cantidad de solicitudes de servicio y dm la duracin media de cada llamada. La intensidad de trfico (o simplemente trfico) ser entonces:

Ancho de banda necesario para migrar el actual sistema de telefona de la FCEFyN a un sistema de VoIP.

V 1 n A ti V c d m Erlang T T i 1 T T

A = 834 minutos/60 minutos = 13,9 Erl

Donde T = 60 minutos corresponde a la hora cargada. Otra forma de calcular la intensidad de trfico es teniendo en cuenta el trfico por usuario. Trfico por usuario = 2 llam/hora * 3 min/llam/60 min Trfico por usuario = 0,1 Erl = 100 mErl Intensidad de Trfico = 139 usuarios *100 mErl = 13,9 Erl De las tablas de Erlang B [6] para un trfico de 13,9 Erl y una probabilidad de bloqueo del 5 % se obtienen la cantidad de canales necesarios. En este caso se obtienen 19 canales (Fig. 1) para cursar el trfico en el peor de los casos, que es la hora cargada.

D. Enlace CU-Centro. Interconexin de dos server VoIP Seguidamente vamos a estimar el ancho de banda necesario para establecer un enlace que permita cursar trfico de comunicaciones de VoIP entre las facultades del centro y Ciudad Universitaria (CU). Cabe resaltar que esto est siendo estudiado y hay un proyecto a futuro para unir las dos sedes (Centro y CU) a travs de dos servidores de VoIP, utilizando el protocolo IAX. Para simular este enlace vamos a suponer que el volumen de llamadas entre las dos sedes es de 1600 minutos por da, siendo el 75 % de la carga en el trayecto C.U. - Centro y el restante 25 % en el trayecto Centro CU. Adems suponemos que la generacin de trfico es aleatoria (algo aproximado a la realidad), que las llamadas bloqueadas son rechazadas y que vamos a trabajar con un grado de servicio estimado de 0,02 (GoS = 2 %). En este caso para calcular la intensidad de trfico debemos estimar la cantidad de llamadas realizadas en la hora cargada, por lo que vamos a asumir que el 20 % de las llamadas se realizaron en esta hora. Como el volumen de trfico es conocido, en la hora cargada tendremos

c dmhora = 1600 min * 0,20 = 320 min V tV 1,514 i }

i 1

10

3 La intensidad de trfico en la hora cargada ser entonces:

V 1 n V c dm A ti Erlang T T i 1 T T

A = 240 minutos/60 minutos = 5,33 Erl

Utilizando el modelo Erlang B, y teniendo en cuenta un grado de servicio de 0,02 %, la cantidad de canales necesarios ser, utilizando la tabla, de 11 canales. Con todo esto, el ancho de banda ser el mostrado en la tabla III.
Disminucin del ancho de banda necesario para el segundo caso de estudio, utilizando compresin cRTP.

Ancho de banda necesario para establecer un enlace entre las sedes Centro y Ciudad Universitaria (CU) de la FCEFyN.

Con lo cual alcanza con contratar un ancho de banda dedicado de 1 MB para cursar el trfico estimado. Vale decir, con un ancho de banda de 1 MB (utilizando codificacin g.711) o 512 KB (utilizando codificacin g.729) se podrn cursar 5,33 Erl de trfico con un bloqueo del 2 % en las comunicaciones de VoIP entre ambas sedes de la FCEFyN. E. Estrategias de reduccin de ancho de banda Se puede reducir el en gran medida el ancho de banda utilizado en las comunicaciones de VoIP. Hay dos maneras muy utilizadas para hacerlo, una de ellas es utilizar compresin en el encabezado RTP, en el caso de utilizar el protocolo SIP, y la otra es utilizar el modo IAX Trunked, solo vlido en el caso de utilizar el protocolo IAX para las comunicaciones [7]. 1) Compresin RTP Esta tcnica, denominada cRTP (Real Time Protocol header Compression) permite llevar el overhead agregado por los encabezados IP/UDP/RTP de 40 bytes a solo 2 o 4 bytes, con lo cual el ancho de banda que ser necesario para cursar el trfico estimado en el punto anterior ser mucho menor. En el caso del cdec g.729 permite reducir el BW de cada llamada de 31,2 kbps a 11,2 kbps, mientras que el cdec g.711 puede reducirse de 96 kbps a 70,4 kbps. Con todo esto, BW necesario con compresin cRTP para cursar el trfico de VoIP de la FCEFyN se muestra en la tabla IV.

2) Compresin IAX Trunked Actualmente se estn realizando pruebas entre dos servidores de VoIP Asterisk con la idea de disponer uno en la FCEFyN sede Centro y otro en la sede CU. Estos servidores estn conectados mediante el protocolo IAX2 (propietario de Asterisk) y la utilizacin del modo trunked permite disminuir drsticamente el BW necesario para las comunicaciones. En el caso de utilizar el cdec g.729 solo se utilizarn 30 kbps para estableces la primera comunicacin y los dems encabezados sern reaprovechados, haciendo que cada comunicacin nueva no supere los 9,6 kbps. Para el cdec g.711 la primera comunicacin necesitar 81,2 kbps, mientras que las siguientes solo 65,9 kbps. Vale decir, esta tcnica utiliza el mismo encabezado cuando existe ms de una llamada. Existen muchos estudios relacionados con la compresin IAX [8], los cuales nos permiten calcular el ancho de banda necesario para establecer las llamadas estimadas en el punto anterior, mostrado en la tabla VI.

Disminucin del ancho de banda necesario para el primer caso de estudio, utilizando compresin IAX trunked.

En el caso del enlace entre los dos servidores Asterisk de CU y Centro, el ancho de banda necesario utilizando IAX Trunked es el mostrado en la tabla VII.

Disminucin del ancho de banda necesario para el segundo caso de estudio, utilizando compresin IAX trunked.

Disminucin del ancho de banda necesario para el primer caso de estudio, utilizando compresin cRTP.

En el caso del enlace entre los dos servidores VoIP de CU y Centro, el ancho de banda necesario utilizando compresin cRTP ser el mostrado en la tabla V.

Como podemos observar el ancho de banda requerido es levemente inferior en el caso de utilizar el cdec g.729 con IAX trunked respecto de compresin cRTP mientras que en el caso de utilizar el cdec g.711 el ancho de banda pasa a ser levemente superior en el caso de utilizar IAX trunked.

4 III. TRFICO MXIMO SOPORTADO POR EL SERVIDOR DE VOIP En la seccin anterior estimamos el trfico que puede ser cursado y la cantidad de canales y ancho de banda necesario para cursar ese trfico. Sin embargo desconocemos si el servidor de VoIP soporta este trfico, vale decir, si puede atender a los 139 internos que hay en la FCEFyN, sede CU. Debido a esto haremos un estudio que nos permita conocer cul es el trfico mximo que soporta el servidor, esto es cuantas llamadas simultneas pueden ser cursadas sin tener problemas de degradacin de rendimiento. A. Limitaciones de trfico Hay dos limitaciones en cuanto al trfico mximo de llamadas que podrn cursarse. Uno es el ancho de banda, que ya fue estimado en la seccin anterior y no presenta un problema a la hora de atender todas las solicitudes. El otro limitante es la capacidad del servidor para atender las llamadas, ya que cada solicitud requiere una cierta cantidad de procesamiento (ver tabla I). Hay que tener en cuenta que cada llamada utiliza una cierta cantidad de memoria y carga al servidor con una determinada cantidad de procesamiento. Si bien el BW puede ser suficiente, veremos que el servidor tiene un lmite en cuanto a cantidad de llamadas simultneas que puede atender ya que su poder de procesamiento es limitado. B. Medicin del trfico Para medir el trfico mximo soportado por el servidor se utilizar el simulador sipp y se generarn llamadas utilizando el protocolo SIP, verificando el trfico que puede ser atendido por el servidor de VoIP a medida que se incrementa de manera gradual el trfico de las llamadas. Lo que se simula con el software es el incremento en la carga del sistema, vale decir que se simulan llamadas telefnicas que son cursadas por el servidor. Estas llamadas pueden ser incrementadas gradualmente en el tiempo, esto se hace hasta llegar a un valor en el cual el servidor no puede atender ms llamadas debido a la elevada carga que presenta el sistema por la excesiva cantidad de llamadas que estn siendo cursadas simultneamente. Este valor es el que se quiere encontrar, el cual servir en un futuro para saber con exactitud cuntos internos se pueden disponer para trabajar sobre este servidor sin tener problemas de trfico. Lo que haremos a continuacin es medir el desempeo del servidor a medida que aumenta la cantidad de llamadas. Hay que resaltar que Asterisk maneja un gran cantidad de protocolos pero el que vamos a medir es este caso SIP, que es el protocolo ms usado actualmente en telefona IP. El generador de trfico sipp genera un nmero elevado de llamadas simultneas al servidor de VoIP. Este nmero, en cuanto a cantidad y duracin, es totalmente configurable, por lo que permite incrementar las llamadas gradualmente y de esa manera realizar las mediciones. Para realizar la medicin haremos una llamada telefnica (real) entre dos usuario SIP y con el programa sipp iremos aumentando gradualmente las llamadas (simuladas) hasta llegar a un momento en que la comunicacin establecida por los dos usuarios SIP presenta una calidad totalmente inaceptable. Esto nos permitir conocer el trfico mximo que el servidor puede cursar de manera tolerable con el hardware que disponemos. C. Simulador sipp Esta herramienta permite enviar trfico RTP, lo cual hace que los resultados obtenidos con el test sean totalmente confiables y muy aproximados a lo que realmente sucede cuando se cursa una llamada. Recordemos que el protocolo SIP trabaja enviando trfico RTP en cada llamada. Hay que tener en cuenta que esta herramienta utiliza un compilador de C++, las libreras ncurses, libnet, etc., por lo que todas estas aplicaciones deben estar instaladas en el servidor antes de instalar el simulador sipp. D. Configuracin del servidor de VoIP para la medicin del trfico Para poder utilizar el generador de trfico y poder realizar las mediciones debemos generar un usuario SIP en el servidor. Esto se hace modificando el archivo de configuracin sip.conf, creando un usuario que se utilizar para realizar las pruebas Luego se debe definir que comportamiento tendr este usuario cuando se llame a su extensin. En nuestro caso el contexto [contexto] del archivo extension.conf, que es el asignado a las llamadas que genera el simulador, solo reproduce un archivo de audio, sin realizar alguna tarea til. E. Diseo y configuracin del entorno de pruebas Este es un proceso fundamental ya que del buen planteamiento de las pruebas depende obtener resultados confiables. El primer paso es disear el escenario sobre el cual se van a realizar las pruebas, ya que nuestro objetivo es simular una situacin real de trfico sobre el servidor. El escenario mostrado en la figura 2 es el que vamos a utilizar, donde una PC ataca al servidor con una cantidad creciente de llamadas, simulando clientes que quieren realizar llamadas, y de esta manera cargando al servidor. Adems de esto estableceremos una llamada telefnica entre dos usuarios SIP que se encuentran en la misma red. Luego incrementaremos progresivamente la cantidad de llamadas generadas por el simulador hasta el momento en que la comunicacin se hace inaceptable. Esto nos permitir conocer la cantidad de llamadas mximas que puede cursar el servidor sin tener problemas de rendimiento.

5 y luego observamos la pantalla del simulador y del servidor. La pantalla nos mostrar las llamadas generadas por segundo y el lmite mximo que se puede cursas simultneamente en el sistema. Las llamadas generadas se pueden incrementar unitariamente con la tecla + o duplicar con la tecla *. De la misma manera se pueden utilizar las teclas y / para decrementar las llamadas generadas. La duracin de cada llamada la setearemos en 30 segundos, mientras que la cantidad mxima de llamadas simultneas ser 1000. Para las pruebas se aumentar el nmero de llamadas en forma proporcional y progresiva, mantenindose el ratio de llamadas (generacin de llamadas por segundo) constante, comprobando en cada ejecucin el uso de CPU y memoria y llamadas completadas, para as obtener el lmite mximo de llamadas que se pueden cursar. La figura 3 muestra la distribucin en el tiempo de las llamadas generadas en funcin del nmero de llamadas totales.
Fig. 2 Entorno de pruebas utilizado para la simulacin. En amarillo, la llamada real cursada entre dos usuarios SIP. En rojo las llamadas simuladas por el software sipp contra el servidor de VoIP.

Hay que resaltar que no se utilizar transcoding, por lo que la carga del servidor ser menor y su rendimiento el mayor que puede obtenerse. F. Medicin del trfico mximo soportado Una vez que estn los usuarios creados y su comportamiento en el dialplan pasaremos a medir el trfico mximo. Para ello utilizaremos uno de los escenario que trae la herramienta que permite enviar trfico RTP utilizando el cdec uLaw, uno de los ms comunes. Para que el test resulte exitoso debemos elegir un promedio de duracin de llamadas elevado de manera que el nmero de llamadas que se crean por segundo sea mayor que las que terminan, caso contrario ser imposible encontrar la capacidad mxima del servidor. Con todo esto podremos encontrar el momento en el cual el servidor de VoIP deja de funcionar adecuadamente, haciendo imposible cursar una comunicacin entre dos usuarios SIP. 1) Corrida del simulador Para utilizar los escenarios que trae la aplicacin simplemente se agrega la opcin -sn seguida del nombre del escenario. Tambin se puede controlar la duracin de las llamadas con la opcin -d y la cantidad mxima de llamadas simultneas con la opcin -l. Con la opcin -s seguida de la IP del servidor especificamos el interno al cual llamaremos (definido en el archivo extensions.conf) y con la opcin -i el IP de la PC que lanz el simulador, en caso de que no sea el mismo servidor de VoIP. Para correr el simulador con estos parmetros nos ubicamos en la carpeta donde esta descomprimido y compilado y ejecutamos la siguiente lnea de comandos. $ ./sipp -sn auc pacp -d 30000 -s 502 200.16.19.19 -l 200.16.19.24

Fig. 3 Llamadas totales y llamadas simultneas generadas por el simulador y cursadas por el servidor de VoIP.

Como se observa en la figura, las llamadas llegan al servidor de forma progresiva (lnea roja). Luego de 30 segundos se alcanza el nmero mximo de llamadas simultneas configurado (lnea azul), el cual se mantiene durante un periodo de tiempo, ya que algunas llamadas finalizan a la vez que otras cuantas son generadas. En ese momento el servidor est consumiendo el mayor nmero de recursos. Cuando el lmite de llamadas totales a realizar ha sido alcanzado, el cliente sipp ya no genera ms llamadas y las llamadas que estn llevndose a cabo van finalizando progresivamente hasta que no queda ninguna en curso. G. Resultados obtenidos Mientras el simulador corra se observaron el consumo de CPU y memoria en el servidor a medida que aumenta el nmero de llamadas generadas. Las tablas VIII y IX muestran los resultados obtenidos luego de varias simulaciones.

Fig. 5 Resultados de la segunda corrida. Se puede con ms detalle que a las 400 llamadas el consumo de CPU es mayor al 80%, mostrando el servidor problemas de rendimiento.

Con todo esto, la cantidad mxima de llamadas simultneas que pueden cursarse no debe exceder las 400 comunicaciones, una cantidad ms que suficiente para atender los 139 internos que presenta la sede CU de la FCEFyN. IV. CONCLUSIONES En la el presente informe se hace un estudio de trfico sobre un servidor de VoIP. En la primera parte se estudia cuantos canales se necesitan para migrar el sistema telefnico actual a un sistema de VoIP y cul es el ancho de banda necesario, llegndose a la conclusin de que con una lnea dedicada de 2 MB es suficiente, utilizando el protocolo SIP e IAX con los cdec g.711 y g.729 para las comunicaciones. Se observ adems que la compresin IAX trunked es mejor si utiliza el cdec g.729, mientras que si utilizamos el cdec g.711 para las comunicaciones lo mejor ser utilizar compresin cRTP. En la segunda parte del informe se estudia la capacidad mxima del servidor, para conocer si es capaz de soportar a todos los internos actualmente instalados. Con el simulador sipp se pudo observar que el servidor puede cursar ms de 400 llamadas simultneas sin tener problemas de rendimiento, con lo cual puede atender a todos los internos sin presentar problemas de degradacin en la calidad de las llamadas. REFERENCIAS
[1] [2] J. M. Gonzbal, Clculo de Ancho de Banda en VoIP, 2008. M. A. Vasco Martnez, Dimensionamiento de una central telefnica IP utilizando estndares abiertos y software libre, ESPOL, 2009, pp. 93 95. J. C. Varela, Trfico telefnico en redes VoIP, Univ. Costa Rica, 2006, pp. 135-136. (Webpage/Online sources) Wiki, Erlang. Available:http://es.wikipedia.org/wiki/Unidad_Erlang. (Webpage/Online sources). Wikitel. Teletrfico. Available:es.wikitel.info/wiki/Teletrfico. (Basic Book/Monograph Online Sources) D. Tipper. Erlang B Traffic Table. Available: www.sis.pitt.edu/~dtipper/2110/erlang-table.pdf (E-bbok/Cisco) Cisco,Voice over IP - Per Call Bandwidth Consumption. Available:www.cisco.com/en/US/tech/tk652/technologies_tech_note091 86a0080094ae2.shtml (Webpage/Online Sources) Voip-info.org. Asterisk Bandwidth iax2. Available: www.voip-info.org/wiki/view/Asterisk+bandwidth+iax2

Como puede observarse en la primera corrida, con intervalos de muestras cada 250 llamadas, el servidor empieza a mostrar dificultades a las 500 llamadas, con un utilizacin del CPU de ms del 80 %. En la figura 4 se represetan los datos de la tabla.

[3] [4] [5] Fig. 4 Resultados de la primera corrida. Se puede observar que a las 500 llamadas el consumo de CPU es mayor al 80%. [6] [7]

Para encontrar un valor ms exacto se tomaron muestrascon intervalos de 100 llamadas, mostrando en realidad a las 400 llamadas el servidor empieza a mostrar problemas, por lo que no es capaz de cursar esta cantidad de llamadas simultneas, ya que empieza a mostrar problemas de rendimiento (fig. 5).

[8]

7 BIBLIOGRAFA
Victor Sauchelli. Recibi su ttulo de Ingeniero Electricista Electrnico en la Facultad de Ciencias Exactas, Fsicas y Naturales (FCEFyN) de la Universidad Nacional de Crdoba (UNC) el ao 1971. Posteriormente recibi su ttulo de Especialista en Educacin Universitaria en la Universidad Tecnolgica Nacional Fac. Regional Crdoba en el ao 1999. En el ao 1997 recibi el ttulo de Doctor en Ciencias de la Ingeniera, tambin en FCEFyN de la UNC. Actualmente es docente e investigador en la FCEFyN y director de la Maestra en Telecomunicaciones de la misma Universidad. Orlando Micolini (M87) Naci en la ciudad de Crdoba, Argentina, en el mes de diciembre, del ao 1956. Se gradu de Ingeniero Electricista Electrnico en la Facultad de Ciencias Exactas, Fsicas y Naturales de la Universidad Nacional de Crdoba (UNC) el ao 1982. Recibi su ttulo de Especialista en Telecomunicaciones en el ao 2000, en la misma Universidad. En el ao 2006 recibi el ttulo de Magster en Telecomunicaciones, tambin de la UNC. Actualmente es alumno del doctorado en Ciencias Informticas de la Universidad Nacional de La Plata y investigador de la Secretaria de Ciencia y Tecnologa (SECyT), Director de la carrera Ingeniera en Computacin (FCEFyN-UNC) y Asesor externo en las empresas SCS SRL y Nutus. Augusto Herrera (SM04GSM07) Naci en La Plata, provincia de Bs. As., Argentina, en el ao 1980. Recibi su ttulo de Ingeniero Electrnico en la Facultad de Ciencias Exactas, Fsicas y Naturales de la Universidad Nacional (UNC) de Crdoba el ao 2006. Actualmente se encuentra finalizando los estudios de Maestra en Ciencias de la Ingeniera, mencin Telecomunicaciones, en la misma Universidad. En sus aos de estudiante realiz una pasanta en el Departamento Universitario de Informtica de la UNC y particip del proyecto Implementacin de Software y Hardware para la optimizacin y paralelizacin de Sistemas Computacionales aplicado a la Ingeniera Hidrulica y Aeronutica, un proyecto de computacin distribuida patrocinado por la Secretaria de Ciencia y Tecnologa (SECyT) de la provincia de Crdoba. Actualmente es becario del Laboratorio de Arquitectura de Computadores de la FCEFyN, donde realiza su trabajo final de maestra.