Memoria Pro Yec To Final

Universidad de Valladolid
E. T. S. DE INGENIERA INFORMTICA
Ingeniera Informtica
Tcnicas AQM basadas en control predictivo
Alumno: Eduardo Hernndez Ramos

Tutora: M Teresa lvarez lvarez
En memoria de mi abuela Felisa
ndice
RESUMEN..................................................................................................9
CAPTULO I. INTRODUCCIN............................................................11
1. 1 Introduccin..............................................................................................................................11
1. 2 Propsito del proyecto..............................................................................................................12
1. 3 Planificacin..............................................................................................................................13
1. 4 Estructura de la memoria........................................................................................................13
CAPTULO II. INTRODUCCIN A LAS REDES DE

ORDENADORES.....................................................................................15
2. 1 Introduccin..............................................................................................................................15
2. 2 Pila de protocolos......................................................................................................................16
2. 3 TCP / IP.....................................................................................................................................18
2.3.1 Protocolo IP........................................................................................................................19
2.3.2 Protocolo TCP....................................................................................................................19
CAPTULO III. EL PROBLEMA DEL CONTROL DE LA

CONGESTIN..........................................................................................23
3. 1 Introduccin..............................................................................................................................23
3. 2 Principios generales del control de la congestin..................................................................24
3. 3 Mtodos de prevencin de congestin.....................................................................................25
3. 4 Primeras decisiones para el control de la congestin............................................................26
3. 5 Mtodos extremos para controlar la congestin....................................................................26
3.5.1 Algoritmo Drop Tail...........................................................................................................27
3.5.2 Algoritmo RED...................................................................................................................27
CAPTULO IV. AQM EN OPNET......................................................29

4. 1 Introduccin..............................................................................................................................29
4. 2 Estudio del nodo QoS...............................................................................................................29
5
4.2.1 Modelo de nodos del elemento QoS..................................................................................29

4.2.2 Modelo de procesos del nodo attribute_definer................................................................30
4. 3 Nodo router ethernet4_slip8_gtwy...........................................................................................32
4.3.1 Modelo de procesos ip_dispatch........................................................................................33
4.3.2 Modelo de procesos ip_output_iface.................................................................................45
CAPTULO V. EL CONTROL PID CLSICO.....................................59

5. 1 Introduccin..............................................................................................................................59
5. 2 Del PID continuo al PID discreto............................................................................................59
5.2.1 PID discretizado mediante aproximacin rectangular...................................................60
5.2.2 PID discretizado mediante aproximacin bilineal o de Tustin......................................60
5. 3 Trminos de un regulador PID y efectos asociados...............................................................61
5. 4 Windup del integrador.............................................................................................................63
5. 5 Sintonizacin de reguladores PID...........................................................................................64
5.5.1 Mtodo de la respuesta en salto........................................................................................64
5.5.2 Mtodo de sensibilidad ltima..........................................................................................65
5. 6 Implementacin del regulador PID en OPNET.....................................................................66
5.6.1 Anlisis de requisitos.........................................................................................................67
5.6.2 Diseo e implementacin del controlador PID................................................................71
CAPTULO VI. EL CONTROL PREDICTIVO BASADO EN

MODELO...................................................................................................77
6. 1 Introduccin..............................................................................................................................77
6. 2 Estrategia del MPC..................................................................................................................78
6. 3 Formulacin del problema.......................................................................................................80
6.3.1 Formulacin del GPC utilizando modelo funcin de transferencia..............................81
6. 4 El control predictivo aplicado al control de la congestin....................................................85
6.4.1 Linealizacin del modelo...................................................................................................85
6.4.2 Utilizacin del modelo en el MPC....................................................................................86
6. 5 Implementacin del MPC en OPNET....................................................................................87
6.5.1 Anlisis de requisitos.........................................................................................................87
6.5.2 Diseo e implementacin del control predictivo utilizando OPNET............................89
CAPTULO VII. SIMULACIONES Y RESULTADOS........................97

7. 1 Experimentos utilizando Control Predictivo..........................................................................97
7.1.1 Variaciones en el valor del horizonte..............................................................................102
7.1.2 Variaciones en el valor del retardo.................................................................................102
7.1.3 Variaciones en el periodo de muestreo...........................................................................103
7.1.4 Variaciones en el valor de .............................................................................................104

7. 2 Experimentos utilizando Control PID..................................................................................105
7.2.1 Variaciones en la constante proporcional......................................................................106
7.2.2 Variaciones en la constante integral...............................................................................107
7.2.3 Variaciones en la constante derivativa...........................................................................107
7.3 Comparacin de distintos mtodos de control de la congestin..........................................109
7.3.1 Primeros experimentos comparando el PID y el MPC................................................109
7.3.2 Comparando MPC y PID con RED y Drop Tail...........................................................110
7. 4 Conclusiones............................................................................................................................121
CAPTULO VIII. PRUEBAS Y PROBLEMAS..................................123

8. 1 Pruebas....................................................................................................................................123
8.1.1 Pruebas unitarias.............................................................................................................123
8.1.2 Pruebas de integracin....................................................................................................124
8. 2 Depurar cdigo en OPNET.................................................................................................124
8. 3 Problemas................................................................................................................................125
CAPTULO IX. CONCLUSIONES Y TRABAJO FUTURO.............127

9. 1 Conclusiones............................................................................................................................127
9. 2 Trabajo futuro.........................................................................................................................128
APNDICE A. LA HERRAMIENTA OPNET.................................129

A. 1 Introduccin...........................................................................................................................129
A. 2 Dominio de Red (Network Domain).....................................................................................131
A. 3 Dominio de Nodos (Node Domain).......................................................................................131
A.3.1 Mdulos............................................................................................................................132
A.3.2 Conexiones.......................................................................................................................134
A.3.3 Atributos..........................................................................................................................135
A. 4 Dominio de procesos..............................................................................................................135
A.4.1 Entorno de un Proceso....................................................................................................135
A.4.2 Componentes de un modelo de proceso........................................................................141
A. 5 Simulacin..............................................................................................................................148
A.5.1 Construccin de un modelo de simulacin...................................................................148
A.5.2 Simulacin de eventos discretos.....................................................................................149
APNDICE B. ADICIN DE ATRIBUTOS Y ESTADSTICAS.....153
Tcnicas AQM basadas en Control Predictivo
B. 1 Modificacin de atributos......................................................................................................153
B.1.1 Acceso a la tabla de atributos.........................................................................................153
B.1.2 Aadir un nuevo atributo...............................................................................................154
B.1.3 Aadir valores a un atributo ya creado.........................................................................154
B. 2 Adicin de nuevas estadsticas AQM....................................................................................156
APNDICE C. GUA DE INSTALACIN DE OPNET................159

C. 1 Instalacin de OPNET Development Kit module...............................................................159
C. 2 Instalacin de Visual Studio .NET Professional 2003.........................................................161
C. 3 Obtencin de la licencia.........................................................................................................164
APNDICE D. PRINCIPIOS BSICOS DEL CONTROL DIGITAL

..................................................................................................................167
D. 1 Introduccin al control digital..............................................................................................167
D. 2 Conceptos bsicos..................................................................................................................167
D.2.1 Lazo abierto y lazo cerrado............................................................................................167
D.2.2 Lazo de control digital....................................................................................................169
D. 3 Requisitos generales de un sistema de control....................................................................169
D.3.1 Estabilidad.......................................................................................................................169
D.3.2 Dinmica..........................................................................................................................169
D.3.4 Errores Estacionarios.....................................................................................................171
D.4 Conceptos bsicos de modelado.............................................................................................171
APNDICE E. CONTENIDO DEL CD...............................................173

APNDICE F. ACRNIMOS Y ABREVIATURAS...........................175
BIBLIOGRAFA.....................................................................................177
Resumen
La utilizacin de tcnicas del mundo de la automtica para lograr un ptimo control de la
congestin en las redes IP es algo asombroso. En el presente proyecto se detalla el estudio de
diferentes tcnicas de control de procesos, partiendo del conocido control PID clsico, hasta el ms
novedoso Control Predictivo basado en modelo. Dichas estrategias sern implementadas haciendo
uso de la potente herramienta de simulacin OPNET, la cul nos dar infinidad de posibilidades
para modelar, experimentar y comparar resultados.
Abstract
Using techniques from the world of automatics, to achieve an optimal control for IP networks
congestion, is something amazing. This project, details the study of different process control
techniques, starting from the well-known classical PID control (implemented in several ways), until
the newest based on model Predictive Control. These strategies will be implemented using the
powerful simulating tool, OPNET, which will give us infinity of posibilities for modeling,
experimenting and comparing results.
Captulo I
Introduccin
1. 1 Introduccin
La congestin de la red es el problema que surge cuando sta genera ms trfico del que se puede
cursar. Para lidiar con ello se han ido sucediendo diferentes tcnicas y propuestas a lo largo de
tiempo, partiendo de sencillos algoritmos generalistas muy aceptables, a otros mucho ms
complejos optimizados en determinadas circunstancias. El objetivo de este texto es exponer una
serie de tcnicas innovadoras para conseguir controlar esa congestin de forma eficiente.
El control de procesos se relaciona con el control de plantas industriales mediante la
optimizacin y actuacin sobre distintas variables y magnitudes que nos permiten obtener unos
resultados satisfactorios. Y, a cuento de qu viene esto? Muy fcil, utilizaremos tcnicas de
control de procesos para controlar la congestin en las colas del router.
Quizs el lector se sienta un poco confundido en el tema, por ello y a modo de introduccin
partiremos del smil mostrado en la Figura 1. 1.
Figura 1. 1 Control de plantas de diferente naturaleza
Este ejemplo nos permitir entender el control de procesos y el por qu nos resulta tan interesante.
Controlar un proceso, a grandes rasgos, se puede resumir en controlar el valor de una o varias
variables de salida en funcin de una o varias variables de entrada. El caudal de entrada de agua,
en el caso del tanque, se correspondera con el flujo de paquetes de datos de entrada en el caso del
router. El depsito en s sera equivalente a la cola en la que los paquetes esperan para ser
procesados. Los paquetes procesados por el router se liberan, de forma similar al lquido que sale
del tanque. Guardando las distancias, se podra asemejar una mayor o menor velocidad de
procesamiento a abrir o cerrar ms el grifo. Aunque de momento no lo justifiquemos, en ambos
procesos distinguimos:
Planta
Variables de entrada
Variables de salida
DEPSITO
Caudal de salida
Nivel del depsito
ROUTER
Probabilidad descarte paquete
Tamao de la cola
Como visin inicial es suficiente, ms adelante se tratar el mismo ejemplo de manera ms tcnica.
1. 2 Propsito del proyecto

La motivacin principal del presente proyecto ha sido el anlisis, diseo e implementacin de
nuevas tcnicas para controlar la congestin en un router.
Se parti del aprendizaje y estudio de la herramienta de simulacin OPNET, una aplicacin
perfecta para nuestro propsito, permita una comparativa detallada de resultados as como
indagar en su implementacin para aadir nuevas funcionalidades. OPNET de por s lleva ya
incluidos varios algoritmos de control de congestin existentes en la realidad, por lo que su estudio
ha sido un sustento enorme para el desarrollo de nuevas tcnicas.
La complejidad inherente de OPNET requiere de un estudio previo considerable. La poca
documentacin existente en la red sobre la herramienta ha sido un punto negativo, fijando
primordialmente el aprendizaje en la propia ayuda del producto [OPT09], as como en anteriores
proyectos llevados a cabo en la ETSII de la Uva ([Alv10] y [Nic10]). La mayora de tutoriales
localizados tocan aspectos muy generalistas de la herramienta, centrndose en diseos de alto nivel
y abstrayndose completamente del cdigo fuente de la herramienta. Por todo ello, se ha intentado
cubrir el enorme vaco de documentacin existente y los captulos relacionados con aspectos de la
herramienta sern tratados de la forma ms concisa posible.
Una vez que la herramienta dej de ser el problema, se procedi a la implementacin del
algoritmo de lazo cerrado PID, muy tpico en procesos industriales (como el descrito en [Ang11]),
para aplicarlo a nuestro problema de congestin. Me sumerg una vez ms en el mundo del
modelado, de la simulacin, del control de procesos industriales y, por ltimo, se model el
mecanismo de control de la congestin dentro de este marco. Esos mismos puntos, y queriendo dar
un gran paso ms, se siguieron posteriormente para aadir sobre la herramienta un controlador
predictivo basado en modelo.
Se ha intentando realizar un estudio lo ms realista y serio posible, pero, no olvidemos, que el
problema que estoy tratando de resolver es realmente complejo, dependiente de mltiples
variables, as que en muchas ocasiones, siendo humilde, los razonamientos y conclusiones estarn
basadas en mis destrezas explotadas al mximo como ingeniero, con las posibles faltas de
apreciacin y errores humanos que se cometen.
12
1. INTRODUCCIN
1. 3 Planificacin
Realmente la planificacin de este proyecto no ha sido tarea sencilla. Compaginar su desarrollo con
otros trabajos ha sido, en muchas ocasiones, complicado. Muchas tareas han sufrido demoras de
tiempo muy por encima de lo esperado inicialmente. En la Figura 1. 2 podemos ver el diagrama de
Gantt que nos muestra la evolucin del proyecto a lo largo de su tiempo de desarrollo. Aunque no
haya una relacin explcita entre las distintas tareas, su posicin a lo largo del tiempo indica su
posible vnculo.
1. 4 Estructura de la memoria
A modo de rpido vistazo, explicar a continuacin en unas pocas lneas el contenido de cada uno
de los captulos en los que se ha dividido la presente memoria.
Captulo 1. Captulo introductorio. Se ofrece una introduccin al texto, as como una

descripcin general del trabajo realizado.
Captulo 2. Introduccin a las redes de ordenadores. Se explicarn conceptos bsicos e
importantes para el entendimiento del proyecto. Recordaremos el modelo de referencia
OSI para despus centrarnos en la implementacin de TCP/IP.
Captulo 3. El problema del control de la congestin. Se explicar detalladamente en qu
consiste este fenmeno y se expondrn diferentes mtodos para reducir su efecto. Aqu
detallaremos los algoritmos utilizados actualmente y se mostrarn varias apreciaciones
sobre los mismos.
Captulo 4. Aqu se explicarn a fondo los elementos relevantes de la herramienta
OPNET relacionados con el control de la congestin.
Capitulo 5. Algoritmo PID clsico. Explicaremos detalladamente en qu consiste el
algoritmo, los procesos para los que es utilizado y, por ltimo, la manera paso a paso de
implementarlo en OPNET.
Captulo 6. Algoritmos de Control Predictivo. Se detallar en concreto el MBPC y
veremos como se ha implementado utilizando OPNET.
Captulo 7. Experimentos. Una gran cantidad de experimentos y simulaciones ocuparn
este captulo. Veremos comparativas entre los distintos algoritmos, as como el efecto que
tiene la variacin de multitud de parmetros en los resultados obtenidos en la simulacin.
Se harn apreciaciones objetivas para los resultados ms evidentes acompaadas de
connotaciones de ndole ms personal para detalles ms abstractos.
Captulo 8. Breve captulo en el que se expone la forma en la que se ha procedido a la
hora de realizar las pruebas.
Captulo 9. Conclusiones. Miradas al pasado y futuro en base al trabajo realizado.
Apndice A. Apndice concebido a modo de manual para el entendimiento, uso y
alteracin de la herramienta OPNET. Se explicarn los distintos niveles de modelado y
simulacin que ofrece este producto.
Apndice B. Se explicar paso a paso el proceso seguido para aadir nuevos atributos y
estadsticas de estudio sobre la aplicacin OPNET.
Apndice C. Es un pequeo tutorial para guiarnos en la instalacin de la herramienta de
simulacin OPNET.
Apndice D. Introduccin al Control Digital. Rpida visin del control de procesos.
Distincin entre control automtico y manual (lazo abierto y lazo cerrado), digitalizacin
del control, controladores ms importantes, fenmenos caractersticos...
Apndice E. Descripcin del contenido del CD adjunto a la memoria.
Apndice F. Acrnimos y definiciones mencionados a lo largo del documento.
13
Figura 1. 2 Diagrama de Gantt de la realizacin del proyecto
14
Captulo II
Introduccin a las redes de
ordenadores
2. 1 Introduccin
Internet, ese trmino tan desconocido, tan exclusivo de la gente moderna hace apenas 10 aos y
tan integrado en nuestras vidas a da de hoy. Actualmente, por lo menos en mi caso, es poco o
nada concebible la vida sin la red de redes. Desde primera hora de la maana ya estoy
consultando mi smartphone para enterarme de las ltimas noticias, mientras camino hacia mi
puesto de trabajo miro los ltimos tweets escritos por mis followings. Una vez en la oficina
accedo a la red corporativa y comienzo a desarrollar software, sincronizo mis cambios en ficheros
con los del resto de mi equipo a travs de SVN, despliego las aplicaciones en diferentes entornos,
consulto libros y documentacin online... Por fin se hace la hora de volver a comer a casa, por el
camino decido utilizar la aplicacin de ese famoso restaurante para pedir ese plato que tanto me
gusta. Tras reposar la comida me pongo a trabajar en el presente proyecto, veo que mi licencia de
la herramienta OPNET ha caducado, me conecto al servidor de licencias y la renuevo para unos
meses y as comienzo con mi quehacer vespertino. El cielo se va oscureciendo, una notificacin
de Whatsapp llega a mi telfono, mi grupo de amigos ha decidido salir a tomar unos pinchos y
caas y quieren que me apunte, para desconectar del duro da de trabajo decido marchar, actualizo
mi estado de facebook y acudo raudo y veloz. Durante la reunin un colega me ensea la nueva
aplicacin de su smartphone y cmo gracias a ella puede estar al tanto de los resultados y
horarios de los eventos deportivos que le interesan. Finalmente llego a casa, contesto varios emails y pujo en eBay por esa figura que llevo tanto tiempo queriendo conseguir. Es hora de irse a
la cama, escribo un tweet de buenas noches y cierro los ojos.
El da que acabo de describir no hubiese transcurrido de igual forma de no ser por internet.
Aunque no lo creamos estamos expuestos al trnsito de datos y, por extensin, de la informacin
durante todo el tiempo (Figura 2. 1).
Evidentemente, esta situacin no se ha dado de la noche a la maana. Las mejoras tanto en la
infraestructura como en la lgica de las redes ha ido mejorando notablemente con el transcurso de
los aos. El creciente consumo de datos ha venido acompaado de una mejora en la eficiencia de
la red.
Existen varios puntos y niveles desde los cuales se pueden contribuir a optimizar el trfico de
datos. En el presente proyecto he querido abordar la problemtica de la congestin de paquetes en
los router y para ello se ha realizado la implementacin y estudio de diferentes propuestas.
Para situarnos en el contexto que nos atae, se ha escrito este captulo introductorio para
explicar conceptos importantes relacionados con las redes de ordenadores.
Figura 2. 1 Simplificacin de una topologa WAN
2. 2 Pila de protocolos
Para reducir la complejidad de su diseo, la mayora de las redes estn organizadas como una pila
de capas o niveles, cada una construida a partir de la que est debajo de ella. El nmero de capas,
as como el nombre, contenido y funcin de cada una de ellas difieren de red a red. El propsito de
cada capa es ofrecer ciertos servicios a las capas superiores, a las cuales no se les muestran los
detalles reales de implementacin de los servicios ofrecidos.
Este concepto es muy conocido y utilizado en el campo de la informtica, donde se conoce de
diversas maneras, como ocultamiento de informacin, tipos de datos abstractos, encapsulamiento
de datos y programacin orientada a objetos. La idea bsica es que una pieza particular de software
(o hardware) proporciona un servicio a sus usuarios pero nunca les muestra los detalles de su
estado interno ni sus algoritmos. [Tan03]
Existe un modelo basado en una propuesta desarrollada por la ISO para estandarizar los
protocolos en un modelo de capas. Su nombre es modelo OSI y est formado por siete capas. En la
Figura 2. 2 se puede observar un esquema del modelo.
II. INTRODUCCIN A LAS REDES DE ORDENADORES
Figura 2. 2 Niveles OSI y relaciones host-router

Se va a proceder a resumir brevemente cada una de las capas del modelo de referencia OSI.
La capa fsica: En esta capa es donde se transmite la informacin, ya como bits, a travs
del canal de comunicacin. Los aspectos de diseo implican asegurarse de que cuando un
lado enva un bit 1, ste se reciba en el otro lado con valor 1. Las cuestiones a resolver en
este nivel estn relacionadas con valores de tensin, muestreos, conectores de red... Los
aspectos de diseo, por tanto, tienen que ver mucho con interfaces mecnicas, elctricas y
de temporizacin, adems del medio fsico de transmisin, que est justo por debajo de
esta capa.
La capa de enlace: Se encarga de transformar los datos del emisor en tramas
(normalmente, de algunos cientos o miles de bytes) y transmitirlas de forma secuencial.
En un servicio confiable el receptor enva una trama de confirmacin. A parte, esta capa
tambin se encarga de controlar el flujo de informacin para no saturar a receptores lentos.
La capa de red: Encargada de controlar las operaciones de la subred. Cmo aspecto muy
importante est el enrutamiento entre redes. Esta capa es la que ms nos importa en el
presente proyecto, en ella es donde se gestiona el control de la congestin (con permiso
de la capa de transporte) en los puntos donde se producen cuellos de botellas que colapsan
la red.
La capa de transporte: Esta capa tiene como principal objetivo fragmentar los datos que
le llegan de la capa superior y asegurarse de que stos se reciben correctamente en el
destino (control extremo a extremo).
17
La capa de transporte tambin determina qu tipo de servicio proporcionar a la capa de sesin y,

finalmente, a los usuarios de la red. El tipo de conexin de transporte ms popular es un canal
punto a punto libre de errores que entrega mensajes o bytes en el orden en que se enviaron. Sin
embargo, otros tipos de servicio de transporte posibles son el envo de mensajes aislados, que no
garantiza el orden de entrega, y la difusin de mensajes a mltiples destinos. El tipo de servicio se
determina cuando se establece la conexin. (Como observacin, es imposible alcanzar un canal
libre de errores; lo que se quiere dar a entender con este trmino es que la tasa de error es tan baja
que se puede ignorar en la prctica.)
La capa de transporte es una verdadera conexin de extremo a extremo, en toda la ruta desde
el origen hasta el destino. En otras palabras, un programa en la mquina de origen lleva a cabo una
conversacin con un programa similar en la mquina de destino, usando los encabezados de
mensaje y los mensajes de control. En las capas inferiores, los protocolos operan entre cada
mquina y sus vecinos inmediatos, y no entre las mquinas de los extremos, la de origen y la de
destino, las cuales podran estar separadas por muchos enrutadores [Tan03].
Capa de sesin: Permite a los usuarios de mquinas diferentes establecer "conversacin".

Servicios relacionados con las sesiones son el control del dilogo, administracin de
operaciones crticas y sincronizacin.
Capa de presentacin: Labores de anlisis sintctico y semntico de la informacin
transmitida.
Capa de aplicacin: Contiene los protocolos que utilizan los usuarios de forma directa.
Por ejemplo el famoso protocolo HTTP del WWW, el FTP de transferencia de ficheros o
el SMTP de correo electrnico, as como otros ms especficos tal como SNMP de
monitorizacin de redes.
2. 3 TCP / IP
El modelo OSI es slo una referencia, slo nos da las pautas y normas en la creacin de una pila de
protocolos. TCP/IP es una implementacin real multicapa extendida mundialmente. Como se
puede ver en la Figura 2. 3 se define un modelo de cuatro capas. En la Figura 2. 4 se muestran los
protocolos presentes en cada una de esas las capas.
Figura 2. 3 Equivalencias de la pila OSI con la pila TCP/IP
18
Figura 2. 4 Ejemplo de protocolos llevados a cabo en cada una de las capas
2.3.1 Protocolo IP
IP se encarga de realizar el encaminamiento entre redes, no entre nodos. Podemos numerar varias
de sus caractersticas ms importantes:
Es un protocolo no orientado a conexin.

Hay entidades al mismo nivel que IP que slo interactan con IP, utilizan protocolos
especiales y proporcionan servicios. Un ejemplo de estos protocolos puede ser ICMP y
ARP.
IP no es el encargado del encaminamiento entre nodos.
La funcin de direcciones IP es bsica, gestionar un dominio de direcciones.
Las direcciones IP contienen informacin de dos dominios. De la red concreta y del host
especfico dentro de una red.
Desde el punto de vista del encaminamiento IP no se distingue entre equipos de usuarios y
nodos de comunicacin.
En cuanto al encaminamiento, podemos tener dos tipos:
Directo: El nodo destino y el que encamina estn en la misma red. IP no interviene. Con
algunos mtodos como el flooding, no hay nada que encaminar, pero an as es necesario
conocer la direccin del destinatario. Para eso se utiliza ARP. El nmero de equipos
activos en una red en un momento dado cambia constantemente, mantener la tabla
completa en memoria es poco eficiente; y por ello ARP actualiza su tabla slo con los
equipos activos.
Indirecto: De un equipo de una red a otro de una red diferentes. Se utilizan tablas IP. Las
tablas de los gateways cambian de forma dinmicamente.
2.3.2 Protocolo TCP

TCP es un protocolo orientado a conexin que permite un intercambio de informacin en bruto. Se
ejecuta un mecanismo para establecer la conexin, es el denominado 3 Way Handshake. Durante
estos tres intercambios, el emisor y el destinatario se ponen de acuerdo sobre el tamao de los
buffers que se utilizarn para emitir y recibir los segmentos TCP intercambiados, el tamao
mximo de una trama de una red Ethernet lo llamamos MTU (Maximum Transfer Unit).
En TCP, adems, se ejecutan unos acuses de recibo (ACKs) para permitir validar
progresivamente las tramas recibidas. [Ate07]
19
Figura 2. 5 Niveles TCP/IP y relaciones host-router

TCP nos proporciona dos utilidades clave:
1.
2.
Direccionamiento: Utiliza puertos. El campo del identificador TCP permite hasta 65.536
direcciones (puertos) TCP diferentes, lo que parece ms que suficiente para cualquier red.
[CEB10]
Control del dilogo extremo a extremo.
A continuacin listamos las caractersticas principales de TCP:
20
Fiabilidad en el transporte de la informacin. Est orientado al flujo de octetos (octect

stream) fiable de extremo a extremo. Se quiere asegurar de que los paquetes llegan a su
destino.
Interfaz buffered con usuarios. Por cada usuario, TCP reserva recursos entre ellos
utilizando buffers.
Conexin full/duplex (es posible transmitir en ambos sentidos de forma simultnea).
No tiene en cuenta la estructura de los datos de usuario.
Es relativamente complejo pero bastante eficiente. Basado en la familia de procedimientos
sliding windows (ventana deslizante).
Control de dilogo: Garantiza que durante la transmisin no hay prdida de octetos y que
no se produzca saturacin ni bloqueo en los buffers.
TCP se encargar de controlar el flujo para que un emisor no llegue a saturar al receptor.
Del mismo modo, ya en TCP existir cierto control de la congestin, como veremos en el
prximo captulo, para evitar la saturacin de la red.
Algunos de los parmetros ms importantes en TCP se describen a continuacin:
Tamao de ventana: Mxima cantidad de

octetos que se pueden enviar en el siguiente
segmento. La entidad emisora puede enviar una
cantidad determinada de datos, pero antes debe
esperar un asentimiento con la actualizacin del
tamao de ventana por parte del receptor. [WF]
Ventana: Secuencia consecutiva de posiciones a
las que TCP tienen acceso.
ACK: Posicin del siguiente octeto que se quiere
enviar. Sirve de acuse de recibo de confirmacin
de recepcin del segmento (Figura 2. 6).
Figura 2. 6 Transaccin extremo a

extremo por TCP
21
Captulo III
El problema del control de la
congestin
3. 1 Introduccin
Cuando hay demasiados paquetes presentes en la subred (o en una parte de ella), hay una
degradacin del desempeo. Esta situacin se llama congestin. En la Figura 3. 1 se muestra este
sntoma. Cuando la cantidad de paquetes descargados en la subred por los hosts est dentro de su
capacidad de conduccin, todos se entregan (excepto unos pocos afligidos por errores de
transmisin) y la cantidad entregada es proporcional al nmero enviado. Sin embargo, a medida
que aumenta el trfico, los routers ya no pueden manejarlo y comienzan a perder paquetes. Esto
tiende a empeorar las cosas. Con mucho trfico el desempeo se desploma por completo y casi no
hay entrega de paquetes. [Tan03]
Figura 3. 1 Grfica de desempeo de la red ante casos de congestin
23
La congestin se puede deber a varias causas. Si los paquetes llegan a partir de varias lneas de
entrada, por ejemplo, cuatro clientes conectados a un router, y ste dispone de una nica lnea de
salida sobre la que redireccionar los paquetes, se puede dar el caso de que la cola se empiece a
llenar. Si no hay suficiente memoria para encolar todos los paquetes que llegan stos se perdern.
Una cola de tamao infinito tampoco sera solucin, ya que para cuando muchos paquetes
llegaran al principio de la cola su temporizador (TCP) ya habra expirado varias veces, lo que a su
vez hubiese generado nuevos reenvos de duplicados de esos paquetes. Estos paquetes, ya
inservibles, sern reenviados a lo largo de la red, aumentado la carga de forma muy notable.
Es bastante evidente que un procesador lento tambin puede causar congestin. Si la CPU es
lenta realizando las tareas de administracin necesarias, en la cola se irn acumulando paquetes a
la espera de ser procesados. Del mismo modo, lneas con poco ancho de banda, tambin pueden
ocasionar problemas de congestin. Hay que buscar un equilibrio entre todos los componentes de
la red, en caso contrario no se conseguir ms que localizar el cuello de botella en otra parte de la
red.
3. 2 Principios generales del control de la congestin

Los problemas de los sistemas complejos, como es el caso de las redes de ordenadores, se pueden
analizar desde el punto de vista de una teora de control. Podemos dividir las soluciones en dos
grandes grupos, de lazo abierto y de lazo cerrado. Bsicamente, las soluciones en lazo abierto
intentan resolver el problema en base a un buen diseo, intentando evitar que el error suceda.
Cuando el sistema ya est funcionando no se hacen correcciones. Mecanismos de este tipo seran
las decisiones de aceptacin de nuevo trfico, de descarte de paquetes, de calendarizacin. Todas
tienen en comn el hecho de que toman decisiones independientemente del estado actual de la red.
En contraste, las soluciones de lazo cerrado estn basadas en el concepto de un ciclo de
feedback. Este mtodo tiene tres partes cuando se aplica al control de congestin:
1.
2.
3.
Monitorizar el sistema para detectar cundo y dnde ocurren las congestiones.

Enviar esa informacin a los sitios donde se pueda actuar sobre el problema.
Corregir el problema desde esos lugares.
Se pueden utilizar varias mtricas para monitorizar la subred buscando congestiones. Las
principales son el porcentaje de paquetes descartados debido a falta de espacio de buffer, la
longitud media de las colas, la cantidad de paquetes para los cuales termina el temporizador y se
transmiten de nueva cuenta, el retardo promedio de los paquetes y la desviacin estndar del
retardo de paquete. En todos estos casos, un aumento en las cifras se traduce en un aumento en la
congestin. El segundo paso del ciclo de retroalimentacin es la transferencia de informacin
relativa a la congestin desde el punto en que se detecta hasta el punto en que puede hacerse algo al
respecto.
La manera ms obvia es que el router que detecta la congestin enve un paquete al origen (u
orgenes) del trfico, anunciando el problema. Por supuesto, estos paquetes adicionales aumentan
la carga precisamente en el momento en que no se necesita ms carga, es decir, cuando la subred
est congestionada.
Por suerte, existen otras opciones. Por ejemplo, en cada paquete puede reservarse un bit o
campo para que los routers lo llenen cuando la congestin rebase algn umbral. Cuando un router
detecta este estado congestionado, llena el campo de todos los paquetes de salida, para avisar a los
vecinos.
Otra estrategia es hacer que los hosts o routers enven de manera peridica paquetes de sondeo
para preguntar explcitamente sobre la congestin. Esta informacin puede usarse para enrutar el
trfico fuera de reas con problemas. Un smil sera, por ejemplo, una emisora de radio, la cul
tiene helicpteros sobrevolando por una ciudad, desde all se detectaran las calles con mayor
24
III. EL PROBLEMA DEL CONTROL DE LA CONGESTIN
trfico y se informara por radio a los conductores sobre la situacin, para que stos no circulen por
las vas conflictivas.
En todos los esquemas de feedback, la esperanza es que el conocimiento sobre la congestin
haga que los hosts emprendan acciones adecuadas con el propsito de reducir la congestin. Para
operar de forma correcta, la escala de tiempo debe ajustarse cuidadosamente. Si el router grita
ALTO cada vez que llegan dos paquetes seguidos, y SIGA, cada vez que est inactivo durante 20
seg, el sistema oscilar sin control y nunca converger. Por otra parte, si un enrutador espera 30
minutos para asegurarse antes de tomar una decisin, el mecanismo de control de congestin
reaccionar tan lentamente que no ser de utilidad. Para funcionar de forma ptima se requiere
encontrar la constante de tiempo correcta, pero ste no es un asunto trivial.
Se conocen muchos algoritmos de control de congestin. A fin de organizarlos lgicamente,
Yang y Reddy (1995) han desarrollado una taxonoma de los algoritmos de control de congestin.
Empiezan dividiendo los algoritmos por lazo abierto y lazo cerrado, de la misma forma que se
ha indicado anteriormente. Dentro del primer grupo, se podran destacar dos subcategoras, los
algoritmos que actan en el origen y los que lo hacen en el destino. Los algoritmos de lazo cerrado
tambin se dividen en dos subcategoras: retroalimentacin explcita e implcita. En los algoritmos
de retroalimentacin explcita, regresan paquetes desde el punto de congestin para avisar al
origen. En los algoritmos implcitos, el origen es el que intuye la existencia de una congestin
haciendo observaciones locales, como el tiempo necesario para que regresen las confirmaciones de
recepcin.
La presencia de congestin significa que la carga es (temporalmente) superior (en una parte
del sistema) a la que pueden manejar los recursos (coloquialmente, un cuello de botella). Existen
dos soluciones iniciales que se nos pueden ocurrir: aumentar los recursos o disminuir la carga. Por
ejemplo, la subred puede comenzar a utilizar lneas de acceso telefnico para aumentar de manera
temporal el ancho de banda entre ciertos puntos. La divisin del trfico entre varias rutas en lugar
de usar siempre la mejor tambin aumenta efectivamente el ancho de banda. Por ltimo, a fin de
contar con mayor capacidad, los routers de repuesto que normalmente sirven slo como respaldo
(para hacer que el sistema sea tolerante a fallas), pueden ponerse en lnea cuando aparece una
congestin severa. Sin embargo, a veces no es posible aumentar la capacidad, o sta ya ha sido
aumentada al mximo. Entonces, la nica forma de combatir la congestin es disminuir la carga.
Existen varias maneras de reducir la carga, como negar el servicio a algunos usuarios, degradar el
servicio para algunos o todos los usuarios y obligar a los usuarios a programar sus solicitudes de
una manera ms predecible.
3. 3 Mtodos de prevencin de congestin

En los sistemas de ciclo abierto se intenta prevenir la congestin antes de que sta suceda. Podemos
aplicar diferentes polticas a diferentes niveles de la pila. A continuacin se muestra una tabla con
una clasificacin de las mismas: [Tan03]
Capa
Polticas
Transporte
Poltica de retransmisin
Poltica de almacenamiento en cach de paquetes fuera de orden
Poltica de confirmaciones de recepcin
Poltica de control de flujo
Determinacin de terminaciones de temporizador
Red
Circuitos virtuales vs. datagramas en la subred

Poltica de encolamiento y servicio de paquetes
25
Enlace
Poltica de descarte de paquetes

Algoritmo de enrutamiento
Administracin de tiempo de vida del paquete
Poltica de retransmisiones
Poltica de almacenamiento en cach de paquetes fuera de orden
Poltica de confirmacin de recepcin
Poltica de control de flujo
3. 4 Primeras decisiones para el control de la congestin

Un router puede monitorizar el estado de sus lneas y ver el estado en el que se encuentran sus
recursos. Si se detecta que hay congestin, el router puede reaccionar de varias maneras:
El bit de advertencia: Cuando se detectaba congestin, el enrutador marcaba a 1 el bit de
advertencia. En el momento que el receptor obtena el paquete, si se encontraba el bit marcado, lo
indicaba de igual manera en el paquete de confirmacin de la recepcin. Cuando el origen reciba
este paquete, si vea signos de congestin, disminua el trfico y, si la situacin persista, lo segua
reduciendo progresivamente. En el momento que se restableciera la situacin y el bit ya no viniera
marcado el origen podra aumentar de nuevo la carga sobre la subred.
Paquetes reguladores: En este momento incidimos sobre el problema de forma directa. Si un
router detecta congestin, ste genera un paquete hacia el origen para indicarle el problema y
marca el paquete para que el resto de routers sepan que ya se ha notificado de la situacin (y no se
manden ms paquetes reguladores). El paquete regulador indica al origen que tiene que reducir un
porcentaje determinado el trfico sobre la red. Es probable que el host origen reciba ms paquetes
reguladores referentes a otros envos, para evitar la reduccin indiscriminada de trfico ignorar
los paquetes reguladores durante un periodo de tiempo; si pasado ese periodo se siguen recibiendo
paquetes hay que volver a reducir el trfico, as hasta que ya no se reciban, entonces es el momento
de volver a aumentar la carga.
Los hosts pueden reducir el trfico ajustando los parmetros de sus polticas, por ejemplo, su
tamao de ventana. Por lo general, el primer paquete regulador causa que la tasa de datos se
reduzca en 0,50 con respecto a su tasa anterior, el siguiente causa una reduccin de 0,25, etctera.
Los incrementos se dan en aumentos ms pequeos para evitar que la congestin se vuelva a
generar rpidamente.
Los paquetes reguladores pueden ser de distinto nivel para indicar la severidad de la
congestin (advertencia suave, una severa o un ultimtum).
Recordad que con este mtodo se monitoriza el estado de la lnea, sin embargo, existen
variantes en las que lo que se controla son los parmetros de los buffers/colas.
Este mtodo no funciona muy bien en distancias grandes o a altas velocidades porque la
reaccin a la congestin es demasiado lenta.
3. 5 Mtodos extremos para controlar la congestin

En casos extremos, cuando la congestin sea bastante elevada, no quedar otra que descartar
paquetes. Encontramos un smil en el tema de la energa elctrica, cuando la demanda de energa
es excesiva, se producen apagones controlados para evitar que toda la red elctrica se venga abajo
(por ejemplo en das calurosos de verano, como el da en el que escribo estas lneas, en los que se
usa sin conocimiento el aire acondicionado).
La primera aproximacin de realizar el descarte sera eliminar paquetes de manera aleatoria
cuando se produce el colapso. Sin embargo, dependiendo de la situacin, se pueden buscar otras
posibilidades ms ptimas. Imaginemos, por ejemplo, que se est realizando la transmisin de un
26
III. EL PROBLEMA DEL CONTROL DE LA CONGESTIN
fichero, supongamos que consta de 12 paquetes y que el nmero 3 se pierde, esto crear un hueco
en la recepcin que puede hacer necesaria la retransmisin de los paquetes del 3 al 12, en este caso
es preferible deshacerse de paquetes viejos que de los nuevos (crear menos retransmisiones). Un
caso opuesto es el de la transferencia de contenido multimedia, aqu es ms importante recibir
primero lo ms nuevo.
Puede existir la posibilidad en la que exista una diferenciacin de paquetes. Las aplicaciones
pueden marcar los paquetes con una prioridad en base a su importancia. El router eliminar de sus
colas los paquetes en funcin de su prioridad (importancia).
La razn podra ser monetaria, siendo ms barato el envo de paquetes de baja prioridad que el
de los de alta prioridad. Como alternativa, los emisores podran tener permitido enviar paquetes de
alta prioridad bajo condiciones de carga ligera, pero a medida que aumente la carga, los paquetes
podran descartarse, lo que hara que los usuarios ya no siguieran envindolos. Este caso podra
coincidir guardando las distancias con el de servicios de almacenamiento masivo de ficheros
(por ejemplo Rapidshare o el malogrado Megaupload), cuentas premium VS cuentas gratuitas.
3.5.1 Algoritmo Drop Tail

Drop tail es un algoritmo muy simple de gestin de colas para saber cuando eliminar un paquete.
En contraste con otros algoritmos ms complejos como RED, en Drop Tail todo el trfico es tratado
de la misma manera. Cuando la cola esta llena a su mxima capacidad, los nuevos paquetes que
lleguen sern descartados hasta que la cola vuelva a tener suficiente espacio para aceptar trfico
entrante.
La prdida de datagramas causa que el emisor TCP origen pase a un estado de arranque lento,
en el que TCP reducir el tamao de la ventana de congestin hasta que se vuelvan a recibir los
reconocimientos del receptor.
3.5.2 Algoritmo RED

Es bien sabido que tratar con la congestin despus de que se detecta por primera vez es ms
efectivo que dejar que dae el trabajo y luego tratar de solucionarlo. Esta observacin conduce a la
idea de descartar paquetes antes de que se ocupe todo el espacio de bfer. Un algoritmo popular
para realizar esto se conoce como RED (deteccin temprana aleatoria) (Floyd y Jacobson, 1993).
En algunos protocolos de transporte (entre ellos TCP), la respuesta a paquetes perdidos consiste en
que el origen disminuya su velocidad. El razonamiento detrs de esta lgica es que TCP fue
diseado para redes cableadas, y stas son muy confiables, por lo tanto, la prdida de paquetes se
debe principalmente a desbordamientos de bfer y no a errores de transmisiones. Este hecho puede
aprovecharse para reducir la congestin.
El objetivo de hacer que los enrutadores se deshagan de los paquetes antes de que la situacin
sea irremediable (de aqu el trmino temprana en el nombre), es que haya tiempo para hacer algo
antes de que sea demasiado tarde. Para determinar cundo comenzar a descartarlos, los enrutadores
mantienen un promedio mvil de sus longitudes de cola. Cuando la longitud de cola promedio en
algunas lneas sobrepasa un umbral, se dice que la lnea est congestionada y se toma alguna
medida.
Debido a que tal vez el enrutador no puede saber qu origen est causando la mayora de los
problemas, probablemente lo mejor que se puede hacer es elegir un paquete al azar de la cola que
puso en marcha la accin.
Cmo puede el enrutador informar al origen sobre el problema? Una forma es enviarle un
paquete regulador, como describimos anteriormente. Sin embargo, con ese mtodo surge un
problema ya que coloca todava ms carga en la ya congestionada red. Una estrategia diferente es
descartar el paquete seleccionado y no reportarlo. El origen notar en algn momento la falta de
confirmacin de recepcin y tomar medidas. Debido a que sabe que los paquetes perdidos por lo
general son causados por la congestin y las eliminaciones, responder reduciendo la velocidad en
lugar de aumentarla. Esta forma implcita de retroalimentacin slo funciona cuando los orgenes
27
responden a la prdida de paquetes reduciendo su tasa de transmisin. En las redes inalmbricas,

en las que la mayora de las prdidas se debe al ruido en el enlace de radio, no se puede utilizar
este mtodo.
El diagrama de flujo de la Figura 3. 2 muestra el comportamiento del algoritmo.
Cuando llega un paquete, se calcula el tamao medio de la cola y ya, directamente, se procede
a encolar o eliminar el paquete si el tamao de la cola se encuentra por encima o por debajo de dos
umbrales mximo y mnimo respectivamente.
Si el tamao est entre estos dos umbrales calculamos una probabilidad que nos permitir
tomar la decisin de deshacernos o no del paquete en funcin de la siguiente expresin:
Pd Max p ( avg min th ) /(max th min th )
Figura 3. 2 Diagrama de flujo del algoritmo RED

28
Captulo IV
AQM en OPNET
4. 1 Introduccin
En este captulo queremos estudiar a fondo los elementos de red que nos proporciona OPNET y
que tienen relacin directa con el control de la congestin. En el Apndice A existe un gua
extendida de OPNET que nos permite conocer a fondo la herramienta. En caso de que el lector no
est familiarizado con esta aplicacin es recomendable leer primero dicho texto.
En primera instancia se ir viendo paso a paso y nivel a nivel como se utiliza/implementa la
gestin activa de colas para, despus, aadir las modificaciones pertinentes para ampliar la
funcionalidad del simulador (esto ser ms adelante, en los captulos 5 y 6).
A nivel de topologa de red, los nodos de OPNET que nos interesan sern el nodo QoS y el
nodo Router.
4. 2 Estudio del nodo QoS

En este punto veremos la estructura interna de este objeto (Figura 4. 1), que es el que recoge, de
forma global, los atributos relacionados con la calidad de servicio sobre la red.
Figura 4. 1 Icono del elemento QoS

Primero detallaremos la estructura a travs del modelo de nodos, para despus sumergirnos sobre
su comportamiento en el modelo de procesos. En el apndice A se ven los conceptos y normas
utilizadas en cada nivel de desarrollo, de forma que invitamos al lector a acudir a dicho captulo si
necesita reforzar o entender alguno de los conceptos utilizados.
4.2.1 Modelo de nodos del elemento QoS

Como ya se ha dicho, este elemento se utiliza para configurar de manera global perfiles de QoS que
posteriormente se aplicarn sobre las interfaces de nuestro modelo de red (sobre todas o alguna de
ellas).
El modelo de nodos asociado al elemento QoS se denomina QoS Attribute Config, y consta de
un solo nodo de tipo procesador nombrado como attribute_definer.
29
Figura 4. 2 Procesador del modelo de nodos attribute_definer

Este modelo de nodos es as de sencillo porque su nico cometido consiste en la configuracin de
parmetros accesibles por otros modelos en el momento de la simulacin. No tiene funcin
equivalente a ningn dispositivo fsico. El modelo de procesos del nico nodo recoger los
atributos introducidos por el usuario. Otros elementos, como el de definicin de aplicaciones y
perfiles tienen una simplicidad similar a ste.
Para poder ver los atributos que ofrece este modelo de nodos al usuario, accesibles desde el
modelo de red, hay que mirar en el men InterfacesModel Attributes, pero como se puede
observar no existe ninguna entrada, eso es debido a que estos atributos son heredados directamente
del modelo de procesos. Poco ms podemos explicar a este nivel, bajemos un nivel ms abajo.
4.2.2 Modelo de procesos del nodo attribute_definer

En el modelo de procesos ser dnde realmente se recojan los parmetros introducidos por el
usuario a nivel de red.
Figura 4. 3 Modelo de procesos de attribute_definer

Como se ve en la figura, el modelo de procesos es denominado qos_attribute_definer.
Grficamente, el diagrama de estados de este nodo est formado por un nico estado, el estado
parse, que adems es el estado inicial (evidentemente al ser el nico). Ninguna transicin se
realiza. El color rojo del estado indica que ste es no forzado (unforced state). Sus enter executives
consta de 56 lneas y sus exit executives estarn vacas (tampoco tendra sentido que hubiera
alguna lnea, ya que no hay transicin alguna que obligue a ejecutar dicho cdigo).
A continuacin vamos a ver los diferentes apartados de descripcin de este modelo.
Header Block
Entre los ficheros de cabecera que se incluyen cabe destacar:
#include <oms_qm.h>
Este fichero define las estructuras asociadas al manejo de colas (queue management). Las
estructuras aqu definidas sern utilizadas en external file oms_qm.ex.c, el cual implementa
30
IV. AQM EN OPNET
funciones para la gestin de colas, entre ellas, las funciones especficas utilizadas en el control de la
congestin.
En el apartado en el que se predefinen las funciones es importante fijarse en la siguiente
attr_def_fifo_profiles_info_parse, la cul recoge los atributos guardados en el atributo compuesto
FIFO Profiles.
Variables de Estado
A destacar la variable my_objid (de tipo Objid), que servir como referencia para acceder a los
distintos atributos.
Variables Temporales
Sern utilizadas, como ya se ha visto, nicamente dentro del modelo de procesos. Son variables
auxiliares para el manejo e identificacin de objetos.
Enter Executives
Las acciones realizadas en esta porcin de cdigo son las siguientes:
Se inicializan las variables de estado y temporales al igual que ciertas estructuras.

Registra la existencia del modelo de procesos para que pueda ser accesible desde otros
modelos (por ejempo ip_dispatch dentro del nodo Router), mediante la funcin
oms_pr_process_register.
Invoca a la funcin attr_def_fifo_profiles_info_parse() para recoger los atributos del tipo
FIFO (si estn configurados).
Tambin llama a otras funciones relacionadas con otras disciplinas y protocolos.

Function Block
Vamos a centrarnos en la funcin nombrada anteriormente attr_def_fifo_profiles_info_parse.
static void attr_def_fifo_profiles_info_parse (void)
{
OmsT_Qm_Attributes* qm_attr_ptr = OPC_NIL;
OmsT_Qm_IP_Queue_Configuration* qconfig_ptr = OPC_NIL;
op_ima_obj_attr_get(my_objid,"FIFO Profiles", &qc_information_objid);
/*Obtener el nombre del perfil FIFO*/

op_ima_obj_attr_get (queuing_type_objid, "Profile Name", prof_name);
/*Reservar memoria para almacenar el atributo QoS usado por la interfaz
IP*/
qm_attr_ptr = ip_qos_attributes_create (IpT_Fifo_Pool, 1,
(int)OmsC_Buffer_Parent_Limit, OPC_TRUE);
qconfig_ptr = (OmsT_Qm_IP_Queue_Configuration*)
qm_attr_ptr->queue_configuration[0];
op_ima_obj_attr_get(queuing_type_objid,"Details",&(queue_configuration_obj
id));
op_ima_obj_attr_get (queue_configuration_child_objid, "Maximum Queue

Size", &max_queue_size);
qconfig_ptr->max_size = (double) max_queue_size;
31
/* En este punto se implementar, como se ver ms adelante, la

recoleccin y reserva de memoria de los atributos relacionados con el PID
y el MPC */
/* Registrar los datos del atributo FIFO Profiles en una base de datos
global pasando el puntero a la estructura qm_attr_ptr. As la informacin
es accesible para todos los objetos de la red, por ejemplo, los routers
IP */
oms_data_def_entry_insert ("FIFO Profiles", prof_name, qm_attr_ptr);
FOUT;
}
La estructura qm_attr_ptr, de tipo OmsT_Qm_Attributes, es realmente importante, guarda

informacin muy golosa sobre las colas como el nmero mximo de paquetes, nmero de colas por
defecto, y contiene otras estructuras para almacenar parmetros de cada una de las colas en
particular, del estilo a qm_attr_ptr->queue_configuration, que como se puede observar en el
cdigo, se le hace una asignacin del tipo OmsT_Qm_IP_Queue_Configuration, la otra estructura
importante, que mantiene parmetros IP especficos de las colas.
Con esto concluimos el estudio del nodo IP QoS. Resumiendo, todos los nodos IP, tales como
routers, estaciones de trabajo y servidores tienen un atributo compuesto IP QoS que utilizan para
especificar la configuracin QoS de forma local en el nodo. Utilizando un perfil IP QoS global
podemos configurar todos los nodos de una forma ms rpida y sencilla. En este apartado se ha
realizado un estudio exhaustivo de este nodo a varios niveles. A nivel de red y de nodos no haba
demasiado que decir, sobre todo porque se trata de un elemento auxiliar no existente en la realidad
sin mayor complejidad a estos niveles. Algo ms de miga ha tenido el estudio del modelo de
procesos.
4. 3 Nodo router ethernet4_slip8_gtwy

A continuacin vamos a tratar el nodo de estudio ms importante, ste es el router (en concreto el
ethernet4_slip8_gtwy). No debemos olvidar en ningn momento que nuestro propsito es actuar
sobre el control de la congestin, el cual, se realiza en la capa de Red y es el router el elemento que
tiene ms responsabilidades a este nivel.
Figura 4. 4 Icono del nodo rourter ethernet4_slip8_gtwy

Si nos metemos en las entraas de este dispositivo veremos un modelo de nodos bastante cargado.
Mltiples procesadores y colas, as como diferentes lneas de entrada y salida implementan el
modelo de nodos con el comportamiento del router, mltiples protocolos coexisten de forma
concurrente realizando labores de diversa ndole.
32
IV. AQM EN OPNET
Figura 4. 5 Modelo de nodos del elemento Router

Nos vamos a centrar en el nodo IP, all es dnde se encuentra todo el meollo de control de la
congestin. Debemos recordar que IP en la implementacin TCP/IP equivale, guardando las
distancias, al nivel de Red en el modelo de referencia OSI.
Para observar el comportamiento del procesador IP debemos acudir a su modelo de procesos
padre (como se observar, coexiste con otros procesos hijos que se ejecutan en paralelo).
4.3.1 Modelo de procesos ip_dispatch

El modelo de procesos padre se llama ip_dispatch y su diagrama de transiciones entre estados se
puede ver en la Figura 4. 6.
ip_dispatch implementa las funciones de enrutado IP, fragmentacin y reensamblado. Los
paquetes IP llegan sobre alguna interfaz y son enrutados a la interfaz de salida apropiada
basndose en la direccin de destino del paquete. El proceso ip_dispatch requiere una cantidad
determinada de tiempo para enrutar cada paquete. Los paquetes son remitidos utilizando una
disciplina FIFO.
El modelo de procesos ip_dispatch se encargar de repartir distintas interrupciones entre sus
hijos, los cules tienen responsabilidades y realizan tareas concretas.
33
Figura 4. 6 Modelo de procesos ip_dispatch

A continuacin iremos viendo los distintos bloques distintivos del modelo al igual que se hizo al
estudiar el nodo QoS.
Variables de estado
Podemos destacar la variable module_data, de tipo IpT_Rte_Module_Data. Es la variable que
almacena los datos compartidos por toda la jerarqua de procesos del mdulo por lo que es una de
las ms importantes. La estructura IpT_Rte_Module_Data est definida en el fichero de cabecera
ip_rte_support.h.
Variables temporales
Dentro de este bloque se declaran variables tiles para el procesamiento y seleccin de las
transiciones dentro del STD.
Header Block
En este bloque se incluyen varios ficheros de cabecera, como ip_rte_support.h, oms_qm.h e
ip_qos_support.h, utilizados tambin en el modelo de proceso del nodo QoS. Tambin hay
definicin de macros para simplificar las condiciones de las transiciones, y definiciones de
constantes. Adems, declara estructuras globales y funciones implementadas en el function block.
STD
Como se aprecia en la Figura 4. 6 est formado por varios estados. Una cosa interesante es que en
las exit executives de cada uno de los estados aparece la sentencia:
intrpt_type = op_intrpt_type();
Se est asignando a la variable temporal intrpt_type el cdigo del tipo de la interrupcin que se ha
producido. Este valor se utilizar para tomar la decisin de transitar al siguiente estado.
A continuacin iremos viendo lo que hace cada uno de los estados presentes en el modelo.
Para hacer la explicacin y la identificacin ms sencilla utilizaremos una tabla.
34
IV. AQM EN OPNET
Llamar a la funcin ip_dispatch_do_init(), la cual registra el puntero a la variable

que se utilizar como memoria compartida con otros procesos:
op_pro_modmem_install(&module_data);
Inicializa campos de esta estructura y paquetes de datos concernientes a IP.
Inicializa tablas y variables referentes a flujo IP, adems captura el tipo de
interrupcin para decidir sobre las futuras transiciones.
Durante la transicin al siguiente estado se ejecuta la funcin
ip_dispatch_wait_for_registrations(), que se asegura de que antes de continuar
todos los procesos hijos de IP han sido registrados (de forma que se eviten
incoherencias durante el resto de la simulacin).
Transita de estado a estado planificando auto-interrupciones, teniendo en cuenta

los tiempos de simulacin en el momento de interrumpir.
En la transicin de salida de wait_2 se ejecuta ip_dispatch_init_phase_2(),
que continua con la inicializacin de variables efectuada en el estado init.
En este estado tenemos dos posibilidades de transicin, bien al estado inactive (en
el caso de que todas las intefaces IP del nodo se encuentren fuera de servicio) o
bien al estado init_too, en el caso de que existan interfaces activas.
Al transitar al estado init_too, se ejecuta la funcin
ip_dispatch_distribute_routing_info(), que activa los distintos protocolos de
enrutamiento configurados en el router.
Este estado termina con la inicializacin del mdulo, en l se crean varios procesos
hijos encargados de realizar tareas especficas. Dentro de los exit executives
encontramos la llamada ip_dispatch_cleanup_and_create_child_processes(), esta
funcin es la que desencadena el procesamiento de las interfaces IP.
Estado al que se transita cuando las interfaces IP se encuentran inactivas.
Estado de funcionamiento estacionario del router.
35
Estudio del cdigo fuente

Realizaremso un barrido del cdigo fuente para entender su comportamiento. Empezaremos por
ip_dispatch_cleanup_and_create_child_processes()
ip_dispatch_cleanup_and_create_child_processes
En los comentarios del mismo cdigo fuente se explica el funcionamiento.
static void ip_dispatch_cleanup_and_create_child_processes (void)
{
List*proc_record_handle_list_ptr;
/* Lista para guardar los procesos registrados */

proc_record_handle_list_ptr = op_prg_list_create ();
/* Determina la disciplina de cola: FIFO, WFQ,... El proceso IP delegar
sus tareas en un proceso hijo para cada interfaz que enva datos. */
ip_rte_qos_information_process ();
...
FOUT;
}
ip_rte_qos_information_process
static void ip_rte_qos_information_process (void)
{
List qos_ifaces_list;
IpT_Qos_Info*intf_qos_info;
IpT_QoS_Iface_Config * qos_iface_config_ptr;
IpT_Rte_Iface_QoS_Data * interface_qos_data_ptr;
/** Crea los procesos hijos para procesar paquetes en la cola de salida.
Se genera un proceso hijo por cada interfaz. Cada uno modela un mecanismo
de encolado como FIFO, WFQ o PQ, adems de mecanismos de control de
congestin como RED/PID/MPC. **/
/* Guarda en la memoria compartida informacin acerca de cada interfaz*/
module_data.shared_mem.iprmd_ptr = &module_data;
/* Almacena en memoria compartida handles para paquetes enviados y
descartados. Tambien se comparten otras variables de estado con el modelo
de proceso de la interfaz de salida para tener en cuenta el trafico
background en las estadisticas de esa interfaz de salida.*/
module_data.shared_mem.locl_pk_dropped_hdl_ptr =
&module_data.locl_num_pkts_dropped_hndl;
module_data.shared_mem.globl_pk_dropped_hdl_ptr =
&module_data.globl_num_pkts_dropped_hndl;
module_data.shared_mem.locl_num_pkts_sent_hdl_ptr =
&module_data.locl_tot_pkts_sent_hndl;
/* Obtener num de interfaces.*/

iface_table_size = inet_rte_num_interfaces_get (&module_data);
36
IV. AQM EN OPNET
/* Inicializar la lista QoS iface. */

op_prg_list_init (&qos_ifaces_list);
/*Comprobar la existencia del objeto QoS Attributes Config. Si no existe
o no est configurado, crea perfiles por defecto.*/
ip_rte_qos_attr_config_info ();
/* Obtener y preprocesar la informacion de la IP QoS local */
ip_qos_info_process ((void *) &module_data, &qos_ifaces_list);
/* Obtener el numero de interfaces con QoS activa */
total_num_of_qos_ifaces = op_prg_list_size (&qos_ifaces_list);
/* Reservar memoria para el array de datos de la interfaz QoS */
module_data.interface_qos_data_pptr =
(IpT_Rte_Iface_QoS_Data**)op_prg_mem_alloc(iface_table_size *
sizeof(IpT_Rte_Iface_QoS_Data *));
/* Crear una tabla para buscar el objid de cada interfaz*/

intf_objid_lookup_table =
ip_rte_proto_intf_attr_objid_table_build
(module_data.ip_parameters_objid);
/* Recorrer todas las QoS active interfaces para inicializar parametros
relacionados con QoS. */
for (qos_iface_index = 0;
qos_iface_index < total_num_of_qos_ifaces;
qos_iface_index ++){
qos_iface_config_ptr = (IpT_QoS_Iface_Config *)
op_prg_list_remove(&qos_ifaces_list, OPC_LISTPOS_HEAD);
/* Obtener iface_info_ptr desde el nombre de la interfaz */
if (inet_rte_is_local_intf_name
(qos_iface_config_ptr->iface_name,
&module_data,&iface_id,&iface_info_ptr,
InetC_Addr_Family_Unknown)){
/* Habilitar Queuing en esta Interfaz */

if (qos_iface_config_ptr->qm_attr_ptr != OPC_NIL){
iface_info_ptr->queuing_scheme =
qos_iface_config_ptr->queuing_scheme;
/* Crear una estructura para pasar objid del qos_information_attribute al
modelo de proceso ip_output_iface*/
intf_qos_info = (IpT_Qos_Info*)
op_prg_mem_alloc (sizeof (IpT_Qos_Info));
intf_qos_info->bandwidth_type
= qos_iface_config_ptr->bandwidth_type;
intf_qos_info->q_profile_name
= qos_iface_config_ptr->q_profile_name;
intf_qos_info->buffer_size
= qos_iface_config_ptr->buffer_size;
intf_qos_info->attribs_ptr
= qos_iface_config_ptr->qm_attr_ptr;
/* Crear y generar proceso hijo ip_output_iface para la interfaz.*/
iface_info_ptr->output_iface_prohandle =
37
op_pro_create ("ip_output_iface", &module_data.shared_mem);

module_data.shared_mem.iface_index = iface_id;
op_pro_invoke(iface_info_ptr->output_iface_prohandle,
intf_qos_info);
}
A continuacin se explicarn varias funciones implementadas en ficheros externos a las que el

modelo de procesos tiene acceso mediante su declaracin en el bloque de cabecera.
ip_rte_qos_attr_config_info [ip_qos_attr_def_support.ex.c]
ip_rte_qos_attr_config_info (){
/** Comprueba la existencia de ip attribute object. **/
if (ip_attribute_object_exists == OPC_FALSE)
{
/* Comprueba la existencia del objeto mediante el registro de
procesos. */
op_prg_list_init (&proc_record_handle_list);
oms_pr_process_discover (OPC_OBJID_INVALID,
&proc_record_handle_list,
"protocol", OMSC_PR_STRING, "ip_qos_attribute_object", OPC_NIL);
if (op_prg_list_size (&proc_record_handle_list) == 0)
{
/* Si no existe el nodo QoS, crea los valores por defecto. */
oms_qm_package_init ();
ip_rte_queuing_profiles_defaults_register ();}
}
FOUT;
}
En esta funcin hay una llamada a la funcin oms_pr_process_discover, que es la que determina si
existe o no un atributo QoS global. Recordar que en el estudio del nodo QoS se haba registrado
llamando a la funcin oms_pr_process_register.
ip_qos_info_process [ip_qos_support.ex.c]
OMSC_EXPORT void ip_qos_info_process (void * data_ptr, List *
qos_ifaces_lptr)
{
Compcode status;
Objid attr_objid, iface_info_objid, sub_iface_info_objid, ith_attr_objid,
h_subiface_objid;
int num_rows, num_sub_ifaces, i, j;
List policies_list;
IpT_Rte_Module_Data * module_data_ptr;
IpT_QoS_Profiles_Dbase * profiles_dbase_ptr;
/** Procesamiento de la informacin de las interfaces IP. **/
38
IV. AQM EN OPNET
FIN (ip_qos_info_process (Objid attr_objid, qos_ifaces_lptr, ...));

/* Notificaciones */
ip_qos_notif_log_handles_init();
/* Hacer un cast para una variable local equivalente a module_data */
module_data_ptr = (IpT_Rte_Module_Data *) data_ptr;
/* Variable para guardar atributos IP QoS.*/
attr_objid = module_data_ptr->ip_qos_params_objid;
/* Acceso al atributos Interface Information del router, que guardar
informacin QoS pero esta vez de forma local, en el router. */
status = op_ima_obj_attr_get (attr_objid, "Interface Information",
&iface_info_objid);
/* Obtener el nmero de interfaces configuradas en el router. */
num_rows = op_topo_child_count (iface_info_objid, OPC_OBJTYPE_GENERIC);
/* Salir de sta funcin si no hay interfaces configuradas. */
if (num_rows == 0)FOUT;
oms_qm_package_init ();/* Inicializa ciertos valores QoS */
op_prg_list_init (&policies_list);
/* Creacin de base de datos para almacenar perfiles QoS locales. */
profiles_dbase_ptr = ip_qos_profiles_database_create (module_data_ptr);
/* Recorrer todas las interfaces IP del router. */
for (i = 0; i < num_rows; i++)
{
/* Recoger identificador del atributo interfaz */
ith_attr_objid = op_topo_child (iface_info_objid,
OPC_OBJTYPE_GENERIC, i);
/* Procesar la informacin en esta interfaz. */
ip_qos_iface_info_process (attr_objid, ith_attr_objid, qos_ifaces_lptr,
profiles_dbase_ptr, &policies_list,
OPC_FALSE);
/* Obtener informacin de subinterfaces. En nuestro caso est vaco*/
op_ima_obj_attr_get (ith_attr_objid, "Subinterface Information",
&sub_iface_info_objid);
/*Aqu hay procesamiento de subinterfaces, pero lo omitimos por no haber
configurado esa informacin. */
}
/* Liberar memoria */
ip_qos_local_profiles_memory_free (profiles_dbase_ptr, &policies_list);
FOUT;
}
En esta funcin se recoge toda la informacin introducida por el usuario relacionada con las
interfaces del nodo router (Interface Information, Figura 4. 7). Hemos obviado el procesamiento de
subinterfaces porque no las llegamos a utilizar.
39
Figura 4. 7 Configuracin de la interfaz IP n 1 del nodo Router

A continuacin estudiaremos la funcin que se encarga de gestionar los valores introducidos en el
atributo compuesto QoS Scheme (ip_qos_iface_info_process).
ip_qos_iface_info_process [ip_qos_support.ex.c]
static void ip_qos_iface_info_process (Objid qos_attr_objid, Objid
iface_objid, List * qos_ifaces_lptr,
IpT_QoS_Profiles_Dbase * profiles_dbase_ptr,
List * policies_lptr, Boolean is_subiface)
{
Compcode status;
Objid qos_scheme_objid, hold_q_objid;
int hold_q_capacity = -1, bandwidth;
char iface_name [256];
IpT_QoS_Bandwidth_Type bw_type;
IpT_QoS_Iface_Info * iface_qos_info_ptr;
IpT_QoS_Iface_Config * qos_iface_config_ptr = OPC_NIL;
/* Funcin que procesa la informacin de cada interfaz, incluyendo QoS.
*/
FIN (ip_qos_iface_info_process (Objid iface_objid,
List * qos_ifaces_lptr,));
/* Reservar memoria para la estructura QoS. */
iface_qos_info_ptr
= (IpT_QoS_Iface_Info *) op_prg_mem_alloc (sizeof (IpT_QoS_Iface_Info));
/* Initializar la estructura con valores por defecto. */
iface_qos_info_ptr->hold_q_capacity = (int) OmsC_Buffer_Parent_Limit;
iface_qos_info_ptr->reserved_bandwidth = 1.0;
iface_qos_info_ptr->bandwidth_type = IpC_QoS_Relative_Bandwidth;
iface_qos_info_ptr->buffer_size = 1000000;
iface_qos_info_ptr->scheduling_info = OPC_NIL;
iface_qos_info_ptr->red_info = OPC_NIL;
iface_qos_info_ptr->in_shaping_info = OPC_NIL;
iface_qos_info_ptr->out_shaping_info = OPC_NIL;
40
IV. AQM EN OPNET
/* Obtencin de varios atributos de la interfaz. */

op_ima_obj_attr_get (iface_objid, "Name", iface_name);
op_ima_obj_attr_get (iface_objid, "Maximum Reserved Bandwidth",
&bandwidth);
op_ima_obj_attr_get (iface_objid, "Reserved Bandwidth Type", &bw_type);
op_ima_obj_attr_get (iface_objid, "Buffer Size",

&iface_qos_info_ptr->buffer_size);
op_ima_obj_attr_get (iface_objid, "Hold Queue Capacity", &hold_q_objid);
op_ima_obj_attr_get (hold_q_objid, "Outbound", &hold_q_capacity);
/* Obtener el atributo QoS. */

status = op_ima_obj_attr_get (iface_objid, "QoS Scheme",
&qos_scheme_objid);
/* Ordenar la informacin QoS para la interfaz. */
ip_qos_iface_attribute_sort (profiles_dbase_ptr, iface_qos_info_ptr,
qos_attr_objid,qos_scheme_objid, policies_lptr);
/* Crear perfiles QoS para esta interfaz. */
ip_qos_iface_profiles_create (profiles_dbase_ptr, &qos_iface_config_ptr,
iface_qos_info_ptr, qos_attr_objid);
FOUT;
}
Como QoS Scheme es un atributo

ip_qos_iface_attribute_sort para registrarlo.
compuesto,
se
utiliza
la
funcin
resaltada
ip_qos_iface_attribute_sort [ip_qos_support.ex.c]
static void ip_qos_iface_attribute_sort (IpT_QoS_Profiles_Dbase *
profiles_dbase_ptr, IpT_QoS_Iface_Info * iface_qos_info_ptr, Objid
qos_attr_objid, Objid qos_scheme_objid, List * policies_lptr)
{
Compcode status;
Objid jth_attr_objid;
int j, num_entries;
char scheme_name [256];
IpT_QoS_Scheme_Type scheme_type;
IpT_QoS_Mechanism_Info * qos_mechanism_info_ptr;
/* Esta funcin clasifica la informacin QoS configurada dentro de la
interfaz en una de las siguientes categoras: scheduling,in/out CAR y
RED. Slo se muestra el cdigo perteneciente al caso que nosotros
tenemos: FIFO y AQM */
FIN (ip_qos_iface_attribute_sort (iface_qos_info_ptr,... ));
num_entries = op_topo_child_count (qos_scheme_objid, OPC_OBJTYPE_GENERIC);
for (j = 0; j < num_entries; j++){
jth_attr_objid = op_topo_child (qos_scheme_objid,
OPC_OBJTYPE_GENERIC, j);
/* Recoge los atributos Type y Name*/
op_ima_obj_attr_get (jth_attr_objid, "Type", &scheme_type);
41
op_ima_obj_attr_get (jth_attr_objid, "Name", scheme_name);

/* Obtiene scheme_type para las condiciones de despus y lo guarda en la
estructura qos_mechanism_info_prt */
strcpy (qos_mechanism_info_ptr->profile_name, scheme_name);

qos_mechanism_info_ptr->type = scheme_type;
if ((scheme_type==IpC_QoS_In_Traffic_Policy) ||
(scheme_type==IpC_QoS_Out_Traffic_Policy)){
/* No es nuestro caso. */
}else{
if ((scheme_type == IpC_QoS_DWFQ_Class_Based) ||
(scheme_type == IpC_QoS_FIFO) ||
{ /* This is a scheduling mechanism. */
if (iface_qos_info_ptr->scheduling_info == OPC_NIL){
/*Nuestro caso, valor dado en ip_qos_iface_info_process*/
iface_qos_info_ptr->scheduling_info = qos_mechanism_info_ptr;
profile_not_used = OPC_FALSE;
}
else{}
}
}
FOUT;
}
En estas funciones no se estn asignando muchos valores porque ya han sido configurados
anteriormente de manera global. Por esta razn parte del cdigo no se ha incluido.
ip_qos_iface_profiles_create [ip_qos_support.ex.c]
static void
ip_qos_iface_profiles_create (IpT_QoS_Profiles_Dbase * profiles_dbase_ptr,
IpT_QoS_Iface_Config ** qos_iface_config_pptr,
IpT_QoS_Iface_Info * iface_qos_info_ptr, Objid qos_attr_objid)
{
char * profile_name;
IpT_Queuing_Scheme queuing_scheme;
IpT_QoS_Mechanism_Info *qos_mechanism_ptr, *red_info_ptr;
OmsT_Qm_Attributes *qm_attr_ptr = OPC_NIL;
IpT_QoS_Iface_Config qos_iface_config, *qos_iface_config_ptr = OPC_NIL;
Boolean is_config_needed = OPC_FALSE;
/* Esta funcin crea perfiles QoS para las interfaces IP */
/* basada en la infomacin contenida en iface_qos_info_ptr.*/
FIN (ip_qos_iface_profiles_create (profiles_dbase_ptr,
qos_iface_config_ptr,
...));
/* Asignar el nombre de la interfaz. */
qos_iface_config.iface_name = iface_qos_info_ptr->iface_name;
qos_iface_config.qm_attr_ptr = OPC_NIL;
/* Ver si hay configuracin de QoS scheduling en la interfaz. */
if(iface_qos_info_ptr->scheduling_info != OPC_NIL){
qos_mechanism_ptr = iface_qos_info_ptr->scheduling_info;
/* Coger la informacin RED. */
42
IV. AQM EN OPNET
red_info_ptr = iface_qos_info_ptr->red_info;
profile_name = qos_mechanism_ptr->profile_name;
/* Obtener queuing scheme basndose en el tipo de perfil configurado */
switch (qos_mechanism_ptr->type)
{
case IpC_QoS_FIFO:
queuing_scheme = IpC_FIFO_Queuing;
qm_attr_ptr = ip_qos_fifo_profile_get (profiles_dbase_ptr,
iface_qos_info_ptr->hold_q_capacity,
qos_mechanism_ptr,red_info_ptr,qos_attr_objid);
break;
}
/* Guardar varios valores en la estructura qos_iface_config*/
qos_iface_config.queuing_scheme = queuing_scheme;
qos_iface_config.bandwidth_type = iface_qos_info_ptr->bandwidth_type;
qos_iface_config.reserved_bandwidth=
iface_qos_info_ptr->reserved_bandwidth;
qos_iface_config.buffer_size = iface_qos_info_ptr->buffer_size;
qos_iface_config.qm_attr_ptr = qm_attr_ptr;
/* Guardar el nombre del perfil */
qos_iface_config.q_profile_name = (char *) op_prg_mem_alloc
(sizeof (char) * (strlen (profile_name) + 1));
strcpy (qos_iface_config.q_profile_name, profile_name);
is_config_needed = OPC_TRUE;
}
if (is_config_needed){
/* Reservar memoria para configuracin de interfaz QoS. */
qos_iface_config_ptr = (IpT_QoS_Iface_Config *)
op_prg_mem_alloc (sizeof (IpT_QoS_Iface_Config));
*qos_iface_config_ptr = qos_iface_config;
*qos_iface_config_pptr = qos_iface_config_ptr;
}
FOUT;
}
ip_qos_fifo_profile_get [ip_qos_support.ex.c]
En esta funcin se comprueba la existencia de perfiles FIFO. En caso de que ya existiera (se ha
configurado de manera global con el nodo QoS), lo agrega a la interfaz del router de manera local.
En caso contrario crea uno por defecto.
static OmsT_Qm_Attributes * ip_qos_fifo_profile_get
(IpT_QoS_Profiles_Dbase * profiles_dbase_ptr, int hold_q_capacity,
IpT_QoS_Mechanism_Info * qos_mechanism_ptr,
IpT_QoS_Mechanism_Info * red_info_ptr, Objid qos_attr_objid)
{
void * tmp_ptr;
char * profile_name;
Boolean red_from_policy = OPC_FALSE;
OmsT_Qm_Attributes * qm_attr_ptr = OPC_NIL ;
43
IpT_QoS_Profile_Entry * profile_entry_ptr;
OmsT_Qm_IP_Queue_Configuration * qconfig_ptr = OPC_NIL;
OmsT_Qm_RED_Queue_Params * red_params_ptr = OPC_NIL;
/* Obtener el nombre del perfil. */
profile_name = qos_mechanism_ptr->profile_name;
/* Comprobar si el perfil ya existe en la base de datos local. Si es as,
salimos de la funcin. Si es default, creamos el perfil por defecto */
profile_entry_ptr = (IpT_QoS_Profile_Entry *) ip_qos_profile_dbase_access
(profile_name, profiles_dbase_ptr, IpC_QoS_Scheduling_Profile,
IpC_FIFO_Queuing, OPC_NIL);
/* Veamos directamente el caso de un perfil configurado globalmente en la

base de datos, pero todava no est en la local. Primero accedemos a la
base de datos global en busca del perfil*/
qm_attr_ptr = (OmsT_Qm_Attributes *)
oms_data_def_entry_access ("FIFO Profiles", profile_name);
/* Una vez encontrado, aade el perfil global al local del router desde
la base de datos mediante la siguiente funcin: */
ip_qos_profile_dbase_entry_add (profile_name, (void *) qm_attr_ptr,
OPC_NIL, profiles_dbase_ptr, IpC_QoS_Scheduling_Profile, IpC_FIFO_Queuing,
OPC_NIL);
FRET (qm_attr_ptr);
}
Tras esta pila de llamadas a funciones se devuelve el control a ip_rte_qos_information_process,

que definitivamente crea y lanza instancias del modelo de proceso ip_output_iface para cada una de
las interfaces IP del enrutador. En cada una de estas instancias se ejecutar de manera concurrente
el procesado de paquetes en cada una de las colas.
Declaracin de procesos hijos
El modelo de procesos ip_dispatch tiene una serie de modelos hijos que puede instanciar y ejecutar.
Para poder ver los procesos hijos del proceso padre, desde el men vamos a File Open Child
Process Model (Figura 4. 8), aqu aparecer el listado con el nombre de los diferentes procesos, si
queremos acceder a alguno de ellos no tenemos ms que pinchar sobre l. Existe la posibilidad de
declarar nuevos procesos, esto se puede realizar desde la opcin de men File Declare Child
Process Model.
44
IV. AQM EN OPNET
Figura 4. 8 Acceder al modelo de procesos hijo
4.3.2 Modelo de procesos ip_output_iface

Al igual que se ha hecho con ip_dispach, iremos haciendo un estudio de cada uno de los apartados
que definen este modelo de procesos.
Variables de estado
Aqu se definen un par de estructuras bastante importantes, OmsT_Qm_Info e IpT_Interface_Info
(Figura 4.9).
Estas variables son importantes porque, como se ha explicado anteriormente, sern las que
vayan guardando los valores que harn transitar el proceso de un estado a otro del STD. No
explicaremos ninguna en concreto, pero se puede ver cmo van tomando valores a medida que se
hacen llamadas a las funciones tanto del Function Block como de ficheros externos (ex.c).
Variables temporales
A destacar la variable invocation_mode, que nos permite diferenciar de qu manera se est
invocando el proceso.
45
Figura 4. 9 Variables de estado del modelo de proceso ip_output_iface

Header block
Se incluye el fichero de cabecera ip_qos_support.h, que a su vez incluye oms_qm.h.
La siguiente macro es importante:
#define RECEIVE_PACKET
((invocation_mode == OPC_PROINV_INDIRECT) && (rsvp_call_type ==
RsvpC_Invalid))
Que dispara una interrupcin ante cada llegada de un paquete. En este punto ser cuando se decida
qu hacer con el paquete en caso de congestin, cuando el procesador del router se encuentra
ocupado.
Ficheros externos
Son importantes ip_qos_support.ex.c y oms_qm.ex.c.
STD
En la Figura 4. 10 podemos ver el diagrama de estados de este modelo de procesos. Ahora mismo
nos encontramos en el punto al que queramos llegar, estamos en el modelo sobre el que tenemos
que disear y adaptar nuestros nuevos algoritmos de control de la congestin. Es aqu donde se
describe el comportamiento de la interfaz IP.
46
IV. AQM EN OPNET
Figura 4. 10 Modelo de procesos ip_output_iface

Se trata del estado inicial (se ve claramente por la flecha) y es de tipo no forzado
(color verde). Cuando se inicia el proceso entra por este estado y sale directamente
por la transicin incondicional (sin haber realizado ninguna tarea debido a la
ausencia de executives). En esta transicin se llama a la funcin do_init(), sta es
una funcin definida en el function block, su cometido consiste en inicializar
variables, destacando la variable de estado qm_info, de tipo OmsT_Qm_Info. Esta
variable es configurada por cada una de las interfaces y contiene informacin sobre
la misma (mximo nmero de paquetes en cada cola, funcionamiento del
procesador o lista de paquetes).
Este estado no dispone executives, por tanto no ejecuta cdigo internamente. Tiene
una transicin incondicional con una llamada a la funcin allocate_buffers(), la
cul est definida en el function block. Se lleva a cabo una segunda fase de la
inicializacin de las variables del proceso tras la ejecucin de la funcin do_init
nombrada anteriormente.
En sus exit excutives comprobar de qu tipo es la interrupcin que le ha llegado y
en funcin de ello tomar una u otra de las posibles transiciones de salida. A
nosotros, la transicin que ms nos interesa es la desencadenada cuando se recibe
un paquete (RECEIVE_PACKET). Cuando esta transicin se lleva a cabo se realiza
una llamada a la funcin enqueue_packet() (definida en el bloque de funciones), el
mismo nombre de la funcin ya nos indica concisamente en qu consiste la misma.
Esta funcin es la que procesa cada paquete y decide qu hacer con l: descartarlo o
encolarlo en la interfaz IP de salida (o bien procesarlo en el caso de que no haya
congestin).
Implementacin del encolado de paquetes.
En este apartado se har un detallado estudio del mecanismo que OPNET implementa para modelar
el comportamiento del encolado de paquetes en un router IP.
47
En primer veremos la manera de distribuir los buffers, para ello vamos a ojear el cdigo que
han implementado los desarrolladores de OPNET en la funcin allocate_buffers.
allocate_buffers
static void allocate_buffers (void)
{
IpT_Rte_Iface_QoS_Data* iface_qos_data_ptr;
OmsT_Buffer_Pool_Handle buffer_pool_handle;
char new_name [200], int f_name[128];
double processing_rate;
FIN (allocate_buffers ());
buffer_pool_handle = (OmsT_Buffer_Pool_Handle) op_pro_argmem_access ();
/* Registro de funciones en una tabla global */
ip_qos_sup_functions_register ();
/* Obtener los datos QoS de la interfaz. */
iface_qos_data_ptr = shared_mem_ptr->
iprmd_ptr->interface_qos_data_pptr[interface_index];
/* Initializa la estructura qm_info.*/

qm_info = Oms_Qm_Info_Create (ip_rte_intf_index_get (interface_info_ptr),
processing_rate, ip_qos_info_assign, buffer_pool_handle,
queuing_processing_scheme, op_pro_self (), OmsC_Qm_IP, (void*)
intf_qos_info_ptr);
FOUT;
}
ip_qos_sup_functions_register [ip_qos_support.ex.c]
Esta funcin registra varias funciones en la tabla global OmsI_Arch_Specific_Func_Table
relacionadas con la gestin de colas. Las distintas posiciones de la tabla se asocian a macros. Ms
adelante veremos la llamada a la funcin registrada ip_qos_packet_enqueue_test.
OMSC_EXPORT void ip_qos_sup_functions_register (void)
{
OmsI_Arch_Specific_Func_Table [OmsC_Qm_IP][OmsC_Qm_Enqueue_Test_Func]=
(OmsT_Qm_Arch_Void_Func ) ip_qos_packet_enqueue_test;
OmsI_Arch_Specific_Func_Table[OmsC_Qm_IP][OmsC_Qm_Drop_Policy_Vars_Create_Func]=
(OmsT_Qm_Arch_Void_Func ) oms_qm_red_vars_create;
OmsI_Arch_Specific_Func_Table[OmsC_Qm_IP][OmsC_Qm_Drop_Policy_Vars_Update_Func]=
(OmsT_Qm_Arch_Void_Func ) oms_qm_red_variables_update;
OmsI_Arch_Specific_Func_Table[OmsC_Qm_IP][OmsC_Qm_Drop_Policy_Vars_Delete_Func]=
(OmsT_Qm_Arch_Void_Func ) oms_qm_red_variables_delete;
48
IV. AQM EN OPNET
La tabla OmsI_Arch_Specific_Func_Table viene definida en el fichero oms_qm.h de la siguiente

manera:
extern OmsT_Qm_Arch_Void_Func OmsI_Arch_Specific_Func_Table
[OmsC_Qm_Max_Arch_Types] [OmsC_Qm_Max_Arch_Func_Types];
La palabra reservada extern eleva la variable a un mbito global para que sea accesible desde
diferentes funciones.
Podemos ver un ejemplo de macro asociada a esta tabla en el siguiente fragmento:
#define OMS_ENQ_TEST_FUNC (arch_type) ((OmsT_Qm_Enqueue_Test_Func)\
OmsI_Arch_Specific_Func_Table [arch_type] [OmsC_Qm_Enqueue_Test_Func])
De esta manera, se crea un acceso unificado a las funciones, por si hubiese distintas arquitecturas
con diferentes funciones. De esta forma, en vez de cambiar la llamada a la funcin, se hacen nuevas
asignaciones a la tabla y seguimos accediendo a ella utilizando la misma macro.
La funcin oms_qm_qscheme_specific_functions_register acta de forma similar a la que
acabamos de explicar. Asocia funciones sobre la tabla OmsI_Qscheme_Specific_Func_Table,
declarada en oms_qm.h. Esta tabla contendr funciones especficas para cada una de las disciplinas
de cola. Por ejemplo, esta asignacin se correspondera con la estructura FIFO:
OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_FIFO_Queuing]
[OmsC_Qm_Pkt_Deq_Complete]
= (OmsT_Qm_Qscheme_Void_Func) OPC_NIL;
OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_FIFO_Queuing]
[OmsC_Qm_Queue_Select]
= (OmsT_Qm_Qscheme_Void_Func) Oms_Qm_FIFO_Queue_Select;
Al igual que en el caso anterior, la invocacin de las funciones asociadas se realizar utilizando
macros. En oms_qm.h podemos ver:
#define OMS_PKT_DEQ_COMPLETE_FUNC(qscheme)
((OmsT_Qm_Pkt_Deq_Complete_Func)\
OmsI_Qscheme_Specific_Func_Table [qscheme][OmsC_Qm_Pkt_Deq_Complete])
#define OMS_QUEUE_SELECT_FUNC(qscheme) ((OmsT_Qm_Queue_Select_Func)\
OmsI_Qscheme_Specific_Func_Table [qscheme][OmsC_Qm_Queue_Select])
La funcin ip_qos_info_assign, definida en ip_qos_support.ex.c, es especfica del protocolo IP, y

da valores a ciertos campos de la estructura qm_info. Es una funcin bastante interesante porque
obtiene informacin de la base de datos global, como el nombre del perfil QoS. Inicializa colas
dependiendo de los valores obtenidos, y devuelve la estructura qm_info a la funcin
Oms_Qm_Info_create que la llama desde su cabecera para seguir asignando valores iniciales a
otros campos de la estructura.
49
Oms_Qm_Info_create [oms_qm.ex.c]
Se encarga de inicializar la estructura OmsT_Qm_Info. Esta estructura contiene toda la informacin
relevante relativa a la interfaz, desde el mximo nmero de paquetes hasta la estructura en s en la
que se almacenarn los paquetes.
OMSC_EXPORT OmsT_Qm_Info * Oms_Qm_Info_Create (int interface_index, double
speed, OmsT_Qm_Info_Assign_Func_Ptr assign_function_ptr,
OmsT_Buffer_Pool_Handle buffer_pool, OmsT_Qm_Queuing_Scheme q_scheme,
Prohandle qm_invoker_prohandle, OmsT_Qm_Arch_Type qm_client_type, void*
arch_info)
{
static Pmohandle qm_info_pmh = OPC_PMO_INVALID;
OmsT_Qm_Info *qm_info = OPC_NIL;
char intf_name [64];
oms_qm_qscheme_specific_functions_register ();
sprintf (intf_name, "Interface #%d", interface_index);
/* Inicializacin y reserva de memoria para la estructura OmsT_Qm_Info.*/
qm_info = (OmsT_Qm_Info *) op_prg_pmo_alloc (qm_info_pmh);
/* Inicializar miembros de sta estructura */

qm_info->child_queue_pool_ptr= OPC_NIL;
qm_info->default_queue_pool_ptr= OPC_NIL;
qm_info->qpool_in_service_ptr= OPC_NIL;
qm_info->buffer_pool_handle= OPC_NIL;
qm_info->arch_type= qm_client_type;
/* Creacin de colas para esta interfaz y otras operaciones, dependiendo

del protocolo*/
assign_function_ptr (interface_index, speed, qm_info, buffer_pool);
/* Devolver la estructura qm_info con toda la informacin concerniente a

las colas de una interfaz. */
FRET (qm_info);
}
Seguidamente, partiendo de la funcin enqueue_packet() iremos viendo a travs del cdigo los
distintos cometidos que se van desencadenando.
enqueue_packet
Almacena el paquete recibido en una de las listas de la estructura qm_info. Si el procesador de la
interfaz est libre, se procesa y es enrutado.
static void enqueue_packet (void)
{
Packet * pkptr = OPC_NIL;
int queue_id = -1;
Ici *qos_ici_ptr = OPC_NIL;
OmsT_Qm_Signal qm_signal;
OmsT_Qm_Queue_Pool*q_pool_ptr = OPC_NIL;
OmsT_Qm_Classifier_Func_Ptr classify_func_ptr = OPC_NIL;
50
IV. AQM EN OPNET
/* Obtener el paquete.*/
pkptr = (Packet *) op_pro_argmem_access ()) == OPC_NIL
/*Asigna clasificacion por defecto*/
classify_func_ptr = ip_qos_classifier;
/* Procesa el paquete que llega a la interfaz */
Oms_Qm_Packet_Process (pkptr, qm_info, classify_func_ptr, &q_pool_ptr,
&queue_id);
/* En este punto ya se sabe lo que hacer con el paquete. Se han aplicado
los algoritmos pertinentes y el paquete se procesa conforme a ello. */
qm_signal = qm_info->signal;
/* Registrar estadsticas */
output_iface_stats_register(q_pool_ptr, queue_id);
if (qm_signal == OmsC_Qm_Dropped_Packet)
{
/* Cuando hay congestion el paquete se descarta. Se actualizan */
/* las estadsticas y se imprime un warning. */
qos_ici_ptr = op_pk_ici_get (pkptr);
/* Destruir el paquete */
} else if (qm_signal == OmsC_Qm_Queued_Packet){

if (!qm_info->processor_busy){
/* El procesador esta libre, todas las colas estn vacas. */
/* Extraer el paquete, enviarlo y activar planificador.*/
doublepkt_svc_completion_time;
OmsT_Qm_Queue_Info* q_info_ptr = OPC_NIL;
/* Si en procesador de interfaz esta en espera, el */
/* paquete se extrae y manda inmediatamente.*/
q_info_ptr = q_pool_ptr->queue_info_parray [queue_id];
/* Extraer paquete y actualizar estadisticas */
pkptr = oms_qm_packet_extract_handler (qm_info, q_info_ptr, queue_id,
&pkt_svc_completion_time, OPC_NIL);
qm_info->sending_packet_ptr = pkptr;
qm_info->processor_busy = OPC_TRUE;
/* planificar el borrado del paquete despus de enviar */
output_iface_dequeue_schedule (pkptr, q_pool_ptr,
pkt_svc_completion_time);
/* Enviar el paquete a la red. */
output_iface_packet_send (pkptr, queue_id);
}
}
FOUT;
}
ip_qos_classifier [ip_qos_support.ex.c]
Esta funcin obtiene el criterio para conceder prioridad al paquete que llega, accediendo a la
informacin de dicho paquete y basndose en el ToS. De esta manera se permite al procesador
51
guardar el paquete en la cola correcta (dependiendo de la planificacin de colas que se ha

adoptado).
OMSC_EXPORT OmsT_Qm_Pkt_Info ip_qos_classifier (Packet* pkptr,
OmsT_Qm_Queue_Pool** main_qpool_pptr, int* enq_id_ptr)
{
int outgoing_phb;
Ici*ici_ptr;
OmsT_Qm_Pkt_Info qm_pkt_info;
IpT_Pkt_Info pkt_info;
IpT_Dgram_Fields*pk_fd_ptr = OPC_NIL;
OmsT_Qm_Queue_Pool*sel_qpool_ptr = OPC_NIL, *main_qpool_ptr = OPC_NIL;
/* Inicializa la informacin del paquete mediante la siguiente funcin:

*/
ip_qos_pk_info_init (&pkt_info);
if(op_pk_nfd_is_set (pkptr, "MPLS Shim Header") == OPC_TRUE){
//Obtener el tamao del paquete.
pkt_info.packet_size = (int) op_pk_total_size_get (pkptr);
ici_ptr = op_pk_ici_get (pkptr); // Obtain reference to the ICI
op_ici_attr_get (ici_ptr, "traffic_class", &outgoing_phb);
pkt_info.tos = (OmsT_Qm_Tos) outgoing_phb;
pkt_info.drop_precedence =
mpls_support_phb_to_drop_precedence_convert (outgoing_phb);
pkt_info.pk_fragment = OPC_FALSE;
}else if(op_pk_nfd_access (pkptr, "fields" ,&pk_fd_ptr)!=
OPC_COMPCODE_FAILURE){
int incoming_iface;
ici_ptr = op_pk_ici_get (pkptr);
op_ici_attr_get (ici_ptr, "incoming_iface", &incoming_iface);
/* Obtener el contenido del campo fields" en el datagrama IP para saber
el ToS, protocolo, y las direcciones fuente y destino.*/
ip_qos_pk_info_get (pkptr, incoming_iface, pk_fd_ptr, &pkt_info);
}
main_qpool_ptr = *main_qpool_pptr;
/* Aqu busca mediante una funcin en la jerarqua de colas una adecuada
para almacenar el paquete. Pero en nuestro caso, usamos una por defecto,
pues slo aplicamos FIFO */
sel_qpool_ptr = main_qpool_ptr->qmgmt_info_ptr->default_queue_pool_ptr;
*enq_id_ptr = sel_qpool_ptr->attributes_ptr->default_queue;
/* Almacenar la informacin en la estructura adecuada. */
pkt_info.queue_id = *enq_id_ptr;
qm_pkt_info.ip_pkt_info = pkt_info;
/* Devuelve la estructura a la funcin anterior */
FRET (qm_pkt_info);
}
En nuestros experimentos siempre tomaremos los valores por defecto, recordad que elegimos el
perfil FIFO y por tanto todos los paquetes sern tratados de manera similar sin distincin alguna.
52
IV. AQM EN OPNET
Oms_Qm_Packet_Process [oms_qm.ex.c]
Esta funcin determinar el clasificador y enviar el paquete a su procedimiento correspondiente de
encolado.
OMSC_EXPORT void Oms_Qm_Packet_Process (Packet *pkptr, OmsT_Qm_Info*
qm_info,
OmsT_Qm_Classifier_Func_Ptr classify_func_ptr,
OmsT_Qm_Queue_Pool** sel_pool_pptr, int *enqueue_id_ptr) {
OmsT_Qm_Queue_Pool*qpool_ptr = OPC_NIL;
OmsT_Qm_Pkt_Info pkt_info;
int enq_id = OMSC_UNASSIGNED;
/* Primero mira la disciplina de cola usada */
switch (qm_info->queue_processing_scheme)
{
case OmsC_Qm_FIFO_Queuing:
{
qpool_ptr = qm_info->child_queue_pool_ptr;
/* Encontrar la cola a la que este paquete pertenece */
pkt_info = classify_func_ptr (pkptr, &qpool_ptr, &enq_id);
*enqueue_id_ptr = enq_id;
/* Basndose en el status del procesador, guardar o enviar el paquete */
Oms_Qm_Incoming_Packet_Handler (pkptr, qm_info, qpool_ptr, enq_id,
pkt_info);
if(OMS_QSCHEME_VARS_UPDATE_ENQ_FUNC
(qm_info->queue_processing_scheme) != OPC_NIL)
(OMS_QSCHEME_VARS_UPDATE_ENQ_FUNC (qm_info->queue_processing_scheme))
(pkptr, qm_info, qpool_ptr, enq_id);
break;
}
case OmsC_Qm_No_Queuing:
{
qm_info->signal = OmsC_Qm_Send_Packet;
break;
}
default:break;
}
FOUT;
}
Oms_Qm_Incoming_Packet_Handler [oms_qm.ex.c]
Esta funcin gestionar los paquetes recibidos. Comprobar la existencia de espacio en la cola para
almacenar el paquete. Tambin actualiza estadsticas y variables de tiempo para futuros cmputos
como por ejemplo retrasos en la red.
static void Oms_Qm_Incoming_Packet_Handler (Packet* pkptr, OmsT_Qm_Info*
qm_info, OmsT_Qm_Queue_Pool* qpool_ptr, int enqueue_q_id, OmsT_Qm_Pkt_Info
pkt_info)
53
{
double current_time;
Ici*oms_qm_ici_ptr = OPC_NIL;
double insertion_time;
char qm_trace [64], mu_sim_trace [64];
OmsT_Qm_Queue_Info *q_info_ptr = OPC_NIL;
insertion_time = current_time = op_sim_time ();

oms_qm_ici_ptr = op_pk_ici_get (pkptr);
q_info_ptr = qpool_ptr->queue_info_parray[enqueue_q_id];
/* Almacenar el paquete en el buffer */

insert_ok = Oms_Qm_Packet_Enqueue (pkptr, qm_info, q_info_ptr,
pkt_info, current_time, enqueue_q_id);
if(insert_ok == OPC_FALSE){
/* El buffer se desborda. Descartar el paquete*/
qm_info->signal = OmsC_Qm_Dropped_Packet;
/* Destruir el paquete. */
}else{
/* Almacenar el paquete */
qm_info->signal = OmsC_Qm_Queued_Packet;
}
FOUT;
}
Oms_Qm_Packet_Enqueue [oms_qm.ex.c]
Comprueba que no haya congestin para almacenar el paquete en la cola correcta. Se aplica el
algoritmo correspondiente para determinar la existencia o no de congestin (Drop Tail, RED). Se
devolver OPC_TRUE si el paquete se puede encolar u OPC_FALSE en caso contrario.
OMSC_EXPORT Boolean Oms_Qm_Packet_Enqueue (Packet* pkptr, OmsT_Qm_Info*
qm_info, OmsT_Qm_Queue_Info* q_info_ptr, OmsT_Qm_Pkt_Info pkt_info, double
insert_time, int PRG_ARG_UNUSED (enqueue_q_id)){
if ((OMS_ENQ_TEST_FUNC (qm_info->arch_type))
(qm_info, q_info_ptr, pkptr, pkt_info)==OmsC_Buffer_Insert_After){
if (oms_buffer_enqueue (q_info_ptr->buffer_handle, pkptr,
OPC_NIL, insert_time) != OmsC_Buffer_Enqueue_Success) {
FRET (OPC_FALSE);
}
}else{
FRET (OPC_FALSE);
}
FRET (OPC_TRUE);
}
ip_qos_packet_enqueue_test [ip_qos_support.ex.c]
Como se ha visto en pginas anteriores, la macro OMS_ENQ_TEST_FUNC se haba definido en
oms_qm.h y se haba asignado a esta funcin a travs de ip_qos_sup_functions_register de manera
que al aparecer esa macro en el texto, se invoca ip_qos_packet_enqueue_test.
54
IV. AQM EN OPNET
Esta funcin se encargar de ver si hay espacio en la cola para el paquete. En primera
instancia, si la cola est llena, el paquete ser descartado incondicionalmente, en caso de que no
est llena, si se est aplicando algn algoritmo de control de la congestin, por ejemplo RED, es
posible que este mecanismo dicte que el paquete tenga que ser descartado o encolado (o
simplemente marcado).
OMSC_EXPORT OmsT_Buffer_Insert ip_qos_packet_enqueue_test (OmsT_Qm_Info*
qm_info, OmsT_Qm_Queue_Info* q_info_ptr, Packet* pkptr, OmsT_Qm_Pkt_Info
qm_pkt_info){
int max_number_of_pkts, max_subqueue_size;
int current_total_number_of_pkts, current_number_of_pkts;
double current_total_number_of_bytes, packet_size;
int queue_id;
IpT_Pkt_Infoip_pkt_info;
Boolean pkt_drop = OPC_FALSE, red_drop_status = OPC_FALSE
IpT_Dgram_Fields* ip_dgram_fields_ptr = OPC_NIL;
OmsT_Qm_RED_Vars* red_vars_ptr = OPC_NIL;
OmsT_Qm_Attributes* ip_attribs_ptr = OPC_NIL;
OmsT_Buffer_Pool_Handle buffer_pool;
OmsT_Qm_IP_Queue_Configuration* queue_config_ptr = OPC_NIL;
ip_pkt_info = qm_pkt_info.ip_pkt_info;
queue_id = ip_pkt_info.queue_id;
ip_attribs_ptr = q_info_ptr->parent_queue_pool_ptr->attributes_ptr;
buffer_pool = qm_info->buffer_pool_handle;
queue_config_ptr = (OmsT_Qm_IP_Queue_Configuration *)
ip_attribs_ptr->queue_configuration [queue_id];
/* Obtener el valor del mximo nmero de paquetes en la cola.*/
max_number_of_pkts = ip_attribs_ptr->max_total_no_buf_pkts;
/* Obtener nmero actual de paquetes almacenados en todo el conjunto de
colas*/
current_total_number_of_pkts = oms_buffer_pool_num_packets_get
(buffer_pool);
/* Obtener el nmero de paquetes almacenados en esta cola */
current_number_of_pkts =
oms_buffer_num_packets_get (q_info_ptr->buffer_handle);
/* Mximo nmero de paquetes permitido en perodos de congestin..*/
max_subqueue_size = queue_config_ptr->max_size;
/* Computar el tamao medio de cola para RED, etc. */
if(queue_config_ptr->red_status != OMSC_NO_RED){
Oms_Qm_Average_Queue_Size_Update(q_info_ptr,
queue_config_ptr->red_queue_params_ptr->exponential_weight_factor);
}
/* Obtener el tamao del paquete en bytes.*/
packet_size = (double) op_pk_total_size_get (pkptr) / 8;
current_total_number_of_bytes = oms_buffer_pool_num_bytes_get
(buffer_pool);
/* Hay 5 condiciones para decidir si se puede encolar el paquete. */
/* 1. Si no hay espacio en el buffer, descartar paquete.*/
/* 2. Si hay espacio, aceptar paquetes directamente. */
/* 3. Si va dirigida a una LLQ, comprobar si hay congestin. En caso que
si, forzar el lmite LLQ.*/
55
/* 4. Para situaciones de RSVP */

/* 5. Si no hay espacio basndose en un lmite, forzar un algoritmo para
controlarlo. */
/* ----CHECK #1----- Comprobar espacio*/
if (packet_size + current_total_number_of_bytes > qm_info>max_buffer_size){
/* Buffer lleno, descartar paquete */
FRET (OmsC_Buffer_Insert_Units_Overflow);
}
/* ----CHECK #2----- */
else if ((ip_pkt_info.protocol == IpC_Protocol_Ospf) ||
(ip_pkt_info.protocol == IpC_Protocol_Igrp) ||
(ip_pkt_info.protocol == IpC_Protocol_Eigrp)){
/* Para paquetes de control, guardarlo si no se excede el tamao del
buffer sin hacer otros clculos.*/
FRET (OmsC_Buffer_Insert_After);
}
else{
/* ----CHECK #5----- */
/* Comparar el nmero de paquetes en el buffer con el nmero permitido.
Si es mayor que lo permitido, aplicar el algoritmo elegido. Este es el
check utilizado en caso de configurar AQM */
if ((current_total_number_of_pkts >= max_number_of_pkts) &&
((int) current_number_of_pkts >= max_subqueue_size)){
pkt_drop = OPC_TRUE;
}else if(!is_micro_sim_pkt && queue_config_ptr->red_status!=OMSC_NO_RED){
red_vars_ptr = (OmsT_Qm_RED_Vars*) q_info_ptr->drop_policy_vars_ptr;
/* Comprobar si RED necesita descartar este paquete. */
red_drop_status=oms_qm_red_packet_drop(red_vars_ptr->average_queue_size,
queue_config_ptr->red_status,
queue_config_ptr->red_queue_params_ptr,
ip_pkt_info.tos);
/* Si est acitvado CE marking, en vez de descartar, marcar el paquete*/
if ((red_drop_status == OPC_TRUE) &&
(queue_config_ptr->red_queue_params_ptr->ce_marking == OPC_TRUE)){
pkt_drop = OPC_FALSE; /* No descartar */
op_pk_nfd_access(pkptr,"fields",&ip_dgram_fields_ptr);
if (ip_dgram_fields_ptr->ECT == OPC_TRUE){
/* Marcar el paquete indicando congestin y almacenarlo.*/
ip_dgram_fields_ptr->CE = 1;
}
}else if (red_drop_status == OPC_TRUE){
/* Descartar el datagrama */
pkt_drop = OPC_TRUE;
strcpy (disp_string1, "Packet dropped on RED's drop policy");
}
}
if (pkt_drop){
/* The packet can be dropped due to insufficient buffer or RED policy */
FRET (OmsC_Buffer_Insert_Ignore_Element);
}
}
/* El paquete es aceptado y almacenado al final de la cola */
FRET (OmsC_Buffer_Insert_After);
}
56
IV. AQM EN OPNET
Existen varias funciones interesantes especficas de RED que no explicaremos debido a su estudio
previo en otros trabajos [Alv10] [Nic10].
Tras devolver el control a la funcin enqueue_packet se ejecuta:
output_iface_stats_register [function block]
Registra estadsticas de la interfaz IP para que el usuario pueda realizar un estudio. A continuacin
se muestra la parte de la funcin relativa a AQM:
static void output_iface_stats_register(OmsT_Qm_Queue_Pool* qpool_ptr, int
q_index){
char queuing_scheme [256], new_name [256], intf_name [128];
char stat_annotation_str [256], queue_category_str [80]="\0";
int q_label, red_status;
Boolean llq_flag = OPC_FALSE;
Objid my_id;
OmsT_Qm_Queue_Info*qinfo_ptr = OPC_NIL;
OmsT_Dim_Stat_Handle dim_stathandle;
qinfo_ptr = qpool_ptr->queue_info_parray [q_index];
/* Obtener la ID del proceso.*/
/* Obtener el nombre del esquema de cola. */
/* Inicializar estadsticas para Buffer Usage (packets y bytes), queuing
delay, jitter, trfico descartado, enviado y recibido. */
/* Registrar estadsticas para RED si est habilitado. */
(OMS_ATTRIBUTE_GET_FUNC (OmsC_Qm_IP))
(qpool_ptr, OmsC_Qm_RED_Status, q_index, &red_status);
if (red_status == OMSC_RED){
sprintf (new_name, "RED Average Queue Size %s Q%d%s",
intf_name, q_label, queue_category_str);
dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "RED
Average Queue Size", stat_annotation_str, OPC_STAT_LOCAL);
Oms_Dim_Stat_Rename (dim_stathandle, new_name);
oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size,
dim_stathandle);
}
FOUT;
}
Aqu concluiramos el procesado del paquete en su correspondiente cola. En los captulos

posteriores mostraremos como, sobre esta base, se han implementado los mtodos PID y MPC para
realizar un control de la congestin.
57
Captulo V
El Control PID clsico
En este captulo se expondrn lo que son los reguladores PID. Tras una breve introduccin se
indicar resumidamente cmo se realiza su discretizacin, para despus ver los mtodos de
sintonizacin para conseguir un comportamiento adecuado. Por ltimo, veremos el proceso que se
ha llevado a cabo para realizar su implementacin dentro de la herramienta OPNET.
5. 1 Introduccin
Los controladores del tipo PID son con mucha diferencia los ms frecuentemente utilizados en la
industria de control de procesos, donde ms del 95% de los lazos de control utilizan controladores
PID. Su sencillez, versatilidad y capacidad para resolver los problemas bsicos que se presentan en
los procesos con dinmica favorable y requisitos de funcionamiento modestos hacen de ellos una
herramienta imprescindible en el control de procesos.
A lo largo de las ltimas dcadas los controladores PID han sobrevivido a diferentes cambios
tecnolgicos que van desde los primeros controladores desarrollados a partir de elementos
neumticos hasta los desarrollados con microprocesadores pasando por las vlvulas electrnicas,
los dispositivos analgicos, los transistores y los circuitos integrados. La incorporacin de los
microprocesadores ha tenido un impacto muy grande ya que ha permitido que los controladores
PID se enriquezcan en funciones colaterales sin perder ninguna de sus propiedades, as se les han
aadido posibilidades de ajuste automtico de los parmetros, posibilidades de ejecucin de reglas
lgicas o automatismos secuenciales.
Por todo ello, y aunque existen tcnicas de control ms sofisticadas, en el nivel ms bajo de
control de muchos procesos sigue estando presente o incluso es el mayoritario. [MBQ04]
5. 2 Del PID continuo al PID discreto

La expresin del PID continuo viene dada por:
1
u (t ) K e(t )
Ti
edt T
de
dt
Existen varias posibilidades para discretizar el PID continuo. Una forma muy sencilla es la
aproximacin rectangular, aunque su simplicidad viene ligada a una prdida mayor de informacin
de la expresin continua. La aproximacin bilineal o de Tustin nos proporciona un controlador
discreto ms realista.
59
5.2.1 PID discretizado mediante aproximacin rectangular

A partir de la expresin del PID continuo obtendramos:
1 t
e(t ) e(t 1)
u (t ) K e(t ) e(i )T Td
Ti i 1
T
t 1
1
e(t 1) e(t 2)
u (t 1) K e(t 1) e(i )T Td
Ti i 1
T
T
e(t ) 2e(t 1) e(t 2)
u (t ) u (t 1) K e(t ) e(t 1) e(t ) Td

Ti
T
g 0 e(t ) g 1e(t 1) g 2 (t 2)
Siendo:
T T
g0 K 1 d
Ti T
g1 K 1 2 d
T
g2 K
Td
T
Dode T es el periodo de muestreo y K, Ti y Td son los parmetros de sintonizacin del PID.
5.2.2 PID discretizado mediante aproximacin bilineal o de Tustin

Como deberamos saber, el trmino integral en el dominio transformado de Laplace es
1
.
s
Aplicando el trmino sobre la funcin de transferencia continua tenemos:
Y ( s)
1
X ( s)
s
[1]
La funcin x(t) viene definida en la Figura 5. 1. La discretizacin de la funcin y(t) en el dominio

temporal:
T
Y ( KT )
x(t )dt
0
y (( K 1)T )
T 1
x(t )dt
0
y ( KT ) y (( K 1)T )
x(t )dt
T 1
El clculo de la superficie bajo la curva se puede aproximar a travs del rea del rectngulo y del
tringulo que se aprecian en la Figura 5. 1.
60
V. EL CONTROL PID CLSICO
y ( KT ) y (( K 1)T ) Tx((k 1)T ) Tx ((k 1)T )
T
x( KT ) x(( K 1)T )
2
Con transformada z:
Y ( z )(1 z 1 )
T
X ( z )(1 z 1 )
2
T 1 z 1
Y ( z)
X ( z)
2 1 z 1
[2]
Si igualamos [1] y [2] el cambio de variable entre s y z ser:
1 T 1 z 1
s 2 1 z 1
Figura 5. 1 Aproximacin de Tustin
5. 3 Trminos de un regulador PID y efectos asociados

1. Trmino proporcional: Actuacin en funcin del error instantneo. El control proporcional
siempre existir.
61
Figura 5. 2 Efecto del trmino proporcional

2. Trmino integral: Teniendo en cuenta la expresin del error estacionario
ess lim sE ( s ) , un
s 0
control exclusivamente proporcional de una planta cuya funcin de transferencia no posee un
1
tendr un error estacionario no nulo ante una entrada escaln. En algunos sistemas
s
1
un trmino
en el regulador consigue eliminar este error permanente.
s
integrador
El trmino integral presenta valores no nulos cuando el error pasa por cero.
3. Trmino derivativo: No afecta al error estacionario. Responde a la velocidad de variacin del
error actuante y puede producir una correccin significativa, antes de que el valor del error actuante
sea demasiado alto.
Se anticipa al error iniciando una accin correctora temprana y tiende a aumentar la
estabilidad. A parte, aade amortiguamiento y permite el uso de trminos proporcionales de mayor
magnitud. Predice sobreimpulsos grandes, produciendo una compensacin anticipatoria.
Esta parte derivativa est recomendada para sistemas con una carga inercial alta.
62
Figura 5. 3 Efecto del trmino integral
5. 4 Windup del integrador

Aparece en reguladores con accin integral combinados con actuadores que se saturan: accin
integral sigue subiendo de forma innecesaria (intentando corregir el error estacionario) y
provocando un retardo ante eventuales cambios de signo en error (cambios en la referencia).
La solucin ms sencilla consiste en dejar de aplicar la accin integral ante situaciones de
saturacin del actuador, cuando ste no da ms de si.
Una implementacin ms elaborada consiste en realizar un seguimiento integral:
realimentacin extra, midiendo la salida del actuador (real) y formando una seal de error como la
diferencia entre la salida del actuador y la del controlador para detectar las situaciones de
saturacin. Sin entrar mucho ms en detalles tcnicos, en las grficas de la Figura 5.4 se ve muy
bien en qu consiste este fenmeno.
En nuestro caso de estudio especfico, el actuador sera la probabilidad de descarte/aceptacin
del paquete, como se puede observar, el rango del mismo es finito, va de 0 a 1 (probabilidades),
por lo tanto existe riesgo de saturacin, la seal de control puede requerir una probabilidad mayor
que 1 que, evidentemente, no ser factible. Para evitar el problema lo que se ha hecho, sin tener
que dejar de aplicar el trmino integral, es ajustar los valores de la seal de control a los lmites del
actuador en caso de que stos se sobrepasen o no se alcancen.
En [LPPC02] se aplica correccin anti-windup para un regulador PI que realiza control de la
congestin.
63
Figura 5. 4 Windup ante saturacin de los actuadores
5. 5 Sintonizacin de reguladores PID

La sintona de reguladores consiste en la eleccin adecuada de los parmetros Kp, Ti y Td para
lograr un control ptimo del proceso.
El comportamiento de un controlador PID discreto es muy similar al de un PID analgico si el
intervalo de muestreo es pequeo.
Aunque el procedimiento de obtencin pueda parecer muy rudimentario, por su carcter
heurstico y sistemtico, los resultados que se obtienen son realmente buenos.
5.5.1 Mtodo de la respuesta en salto

Se trata de un mtodo utilizado en lazo abierto. Se determina experimentalmente la respuesta al
salto unidad (step test) del proceso en lazo abierto. En funcin del resultado de salida se pueden
obtener varios valores que nos permite sintonizar de manera precisa nuestro regulador.
64
Figura 5. 5 Sintonizacin del PID mediante la respuesta en salto

La ganancia del proceso (PG) vendr dada por PG
dPV
, L se corresponde con el tiempo
dOP
muerto, el retardo antes de que la salida se empieza a enterar del cambio en la entrada y T es una
constante de tiempo dada por la tangente en el punto de inflexin de la curva de salida. El clculo
de los diferentes parmetros del regulador viene descrito en la siguiente tabla:
T
PG L
Tipo de regulador
P
PI
PID
Kp
0.9 K
1.2 K
Ti
3.3 L
2 L
Td
0 .5 L
5.5.2 Mtodo de sensibilidad ltima

Este mtodo se aplica directamente en lazo cerrado. Consiste en los siguientes pasos:
Se conecta el controlador al proceso slo con el trmino proporcional

Salto unidad en la referencia (set point step test)
Se incrementa la ganancia hasta que el sistema alcance una oscilacin automantenida
(lmite de estabilidad), siendo Ku dicha ganancia y Tu el periodo de oscilacin en el que
esto sucede.
65
Figura 5. 6 Sintonizando el PID por el mtodo de sensibilidad ltima
Tipo de regulador
Kp
Ku
2
PI
0.45 K u
PID
0.6 K u
Ti
Td
Tu
1.2
Tu
2
Tu
8
El intervalo de muestreo en reguladores PI se puede elegir en base al siguiente criterio:
T
Ti
entre 0.1 y 0.3;
T
L
entre 0.3 y 1;
T
Tu
entre 0.1 y 0.3
5. 6 Implementacin del regulador PID en OPNET

Llegados a este punto nos debe de quedar bastante claro el modo de funcionamiento del regulador
PID. Como en el captulo 4 ya se han descrito los aspectos principales del funcionamiento de los
componentes de nuestro inters de la herramienta de simulacin OPNET, estamos preparados para
su implementacin en la misma. Trabajos como [HYH08] han servido de referencia a la hora de
entender el uso del PID como controlador de la congestin.
Para aadir a OPNET esta nueva funcionalidad nos deberemos introducir en las entraas de la
herramienta y editar de forma directa cdigo de su ncleo, de manera que despus, desde los
niveles de modelado se le permita al usuario configurar y actuar utilizando este mecanismo.
A continuacin se irn describiendo los pasos para lograr nuestro propsito. Se ir
especificando cada una de las partes que se han modificado en los diferentes niveles de modelado.
Empezaremos por el nivel de red hasta sumergirnos en las modificaciones realizadas en el cdigo
fuente.
5.6.1 Anlisis de requisitos

66
Este apartado, a priori, iba a ser obviado. Este proyecto est ms relacionado con la investigacin y
estudio de resultados que con el desarrollo propiamente dicho. An as, la adicin de una nueva
funcionalidad dentro de la herramienta OPNET, exige cierto proceso de ingeniera del software,
por ello, y a modo aclaratorio, se le explicar al lector el anlisis y el diseo llevado a cabo para
desarrollar nuestros algoritmos.
Se listarn a continuacin los requisitos funcionales obtenidos por parte, en este caso, de la
tutora para el desarrollo de la funcionalidad.
REQNUM 1
Descripcin
Justificacin
Configuracin
El usuario podr configurar los atributos relacionados con el control PID
El usuario debe tener libertad para definir las caractersticas principales del
regulador.
REQNUM 1.1
Descripcin
Trayectoria de referencia
Se deber poder introducir una referencia variable a lo largo del tiempo de la
simulacin.
Los casos de estudio ms interesantes estn relacionados con simulaciones en
los que el valor de referencia va variando a lo largo del tiempo
Justificacin
REQNUM 1.2
Descripcin
Justificacin
Constantes de sintona del controlador PID

El usuario podr introducir las constantes Kp, Ki y Kd a su antojo para
sintonizar el regulador a su gusto
Permitir sintonizar el regulador
REQNUM 1.3
Descripcin
Justificacin
Periodo de muestreo
Se podr introducir el periodo que marcar el re-clculo de la seal de control.
Experimentos con diferentes periodos de muestreo.
REQNUM 1.4
Descripcin
Justificacin
Activacin/Desactivacin
El algoritmo slo se usar si el usuario lo habilita. En el caso de permanecer
habilitado al mismo tiempo que PID, prevalecer el MPC sobre ste.
Comparar el uso de este sistema de control de congestin con los otros.
REQNUM 2
Descripcin
Justificacin
Visualizacin de estadsticas
Se deben poder visualizar varias nuevas estadsticas al finalizar la simulacin.
Necesario para nuestro estudio.
REQNUM 2.1
Descripcin
Justificacin
Estadstica de trayectoria de referencia

Se quiere que la referencia sea visualizable en las grficas tras la simulacin
Permite observar bien el acercamiento de la salida a la referencia
REQNUM 2.2
Descripcin
Estadstica de probabilidad de descarte

Queremos que en las grficas se vea como va variando la probabilidad de
descarte para que la salida se aproxime al valor de consigna.
Permite ver la relacin entre entrada y salida del sistema SISO
Justificacin
Seguidamente, una breve lista de requisitos no funcionales:

67
REQNUM 3
Descripcin
Justificacin
Herramienta OPNET
El controlador deber ser implementado en esta herramienta
OPNET es una aplicacin para el estudio y simulacin de redes muy potente.
Es perfecta para implementar esta clase de algoritmos y realizar comparativas.
5.6.1.1 Diagramas del Modelo de Casos de Uso

El caso de uso que se va a describir a continuacin no pertenece exactamente a nuestro desarrollo
(ms bien a la herramienta OPNET), sin embargo, el algoritmo que vamos a crear tiene relacin
directa con l.
Caso de Uso: Simular
Descripcin Breve: El caso de uso tiene como objetivo que el usuario pueda ejecutar la
herramienta OPNET para realizar simulaciones de redes IP gestionadas por controladores PID para
controlar la congestin.
Precondiciones: El usuario tiene la herramienta OPNET abierta.
Flujo de Eventos
Flujo Bsico
1. El usuario configura los parmetros del PID e inicia una simulacin.
2. El sistema comienza la simulacin.
3. La simulacin finaliza con xito.
Flujo Alternativo 1
Precondicin: La simulacin est en curso.
1. El usuario para la simulacin.
Postcondicin: El sistema regresa a su posicin inicial.
Flujo Alternativo 2
Precondicin: La simulacin est en curso.
1. El usuario pausa la simulacin.
2. El sistema se detiene a la espera de que el usuario contine la simulacin.
3. El usuario hace que prosiga la ejecucin de la aplicacin.
4. El sistema contina desde el momento en el que se puls la pausa.
Postcondicin: El sistema regresa a su posicin inicial
Postcondiciones: El sistema muestra los resultados de la simulacin.
En la Figura 5. 7 se muestra el diagrama de casos de uso.
Figura 5. 7 Diagrama de casos de uso
68
5.6.1.2 Modelo esttico

Modelaremos la parte que nos concierne en base al desarrollo de nuestro algoritmo de control de la
congestin. Toda la funcionalidad que tendremos que implementar radica dentro de una de las colas
de un router, por ello, identificaremos una nica clase denominada InterfazIP.
El objeto CapaIP representa la capa de red IP de un router y ya se encuentra modelado e
implementado dentro de la herramienta OPNET. Las interfaces IP tambin se encuentran ya
modeladas, sin embargo hemos aadido ciertos atributos y operaciones necesarias para realizar
nuestro propsito y son stos los que se han representado en la clase InterfazIP de la Figura 5. 8.
Figura 5. 8 Diagrama de clases

5.6.1.3 Modelo dinmico
Siendo estrictos, en este punto en el que se desconoce el comportamiento interno de los objetos
cuando OPNET simula, podemos representar el escenario principal del caso de uso simular como
se representa en la Figura 5. 9. Aqu vemos OPNET como una caja negra sobre la que el usuario
realiza sus simulaciones.
Figura 5. 9 Diagrama de colaboracin general

Intentaremos describir el comportamiento interno del sistema, centrndonos slo en la parte
relacionada con el control de la congestin, que, en resumidas cuentas, es lo que nos interesa.
69
Figura 5. 10 Diagrama de colaboracin especfico

A continuacin realizaremos el diagrama de mquina de estados. Este diagrama nos servir para
representar, en base al control de la congestin, el ciclo de vida de una interfaz del router: estados
de respuesta a eventos y las transiciones y acciones/actividades asociadas.
En la mquina de estados de la Figura 5. 11 se observa el comportamiento de la cola. sta
permanecer activa controlando la congestin (en dicho estado) mientras la simulacin siga en
proceso. Ante una seal de reloj recalcular la seal de control y en base a este valor, cuando
llegue un nuevo paquete, se ver qu hacer con l.
Figura 5. 11 Mquina de estados de la interfaz IP (control de congestin)

El comportamiento de la operacin controlador se define en la Figura 5. 12, mediante un diagrama
de actividad. El evento llegada de paquete ya se encuentra implementado (por eso aparece de forma
ms tenue), simplemente en esta parte se deben de tener en cuenta los resultados calculados por el
controlador si se da el caso.
La operacin controlador() tiene un comportamiento sencillo. Obtenemos una probabilidad de
descarte -- el diseo e implementacin de esta funcionalidad ser descrito en la seccin posterior y en base a esa probabilidad, de manera aleatoria, se decide si encolar o descartar el siguiente
paquete que sea recibido.
70
Figura 5. 12 Diagrama de actividad operacin controlador()

Todos los diagramas de este apartado se han realizado utilizando la tcnica UML [RJB05].
5.6.2 Diseo e implementacin del controlador PID

Empezaremos aadiendo los atributos de usuario necesarios para que el usuario pueda
configurarlos desde el mdulo QoS. Para ello, desde el nivel de modelado de procesos, en concreto
desde qos_attribute_definer, definimos los atributos que vamos a aadir. Pinchamos en Interfaces
Model Attributes, teniendo sealado el atributo FIFO Profiles, damos al botn Edit Properties,
se nos abrir una ventana emergente con los atributos compuestos en los que consiste dicho
atributo. Del mismo modo, seleccionamos el atributo Details y pulsamos Edit Properties. Dentro de
este atributo es dnde aadiremos uno nuevo llamado PID Parameters de tipo compuesto y, una
vez ms, seleccionaremos Edit Properties para aadir los atributos por los que est formado. Al
final tenemos que tener algo similar a lo de la Figura 5. 13.
71
Figura 5. 13 Nuevos atributos aadidos para el controlador PID

El valor del atributo PID Status queremos que le aparezca como Enabled o Disabled al usuario (en
vez de 0 o 1), para ello seleccionamos sobre este atributo simple, otra vez, Edit Properties.
Tendremos que de nombrar distintos smbolos en representacin de varios valores (Figura 5. 14).
Figura 5. 14 Nombrado de valores de atributo

El atributo de Referencia tambin ser compuesto, y consistir en una especie de array con varias
filas, donde se indicar el valor de cada una de las referencias y el tiempo de simulacin que
permanecer ste activo (Figura 5. 15). Debemos asegurarnos de que en este atributo se permite la
definicin de varias filas.
Figura 5. 15 Atributos del atributo compuesto referencia

En este punto, el usuario ya debera de tener visibles los valores de estos atributos tal y como se
muestra en la Figura 5. 16.
Definiremos una estructura en oms_qm.h de manera que nos permita asociar todos estos
parmetros de configuracin sobre una de las colas del router.
typedef struct {
double valor;
double duracion;
} OmsT_Qm_Ref_Definition;
Qm_Ref_Definition2;
typedef struct {
int pid_status;
double sample_time;
OmsT_Qm_Ref_Definition*
double kp;
double ki;
double kd;
} OmsT_Qm_PID_Queue_Params;
72
/* To enable or disable PID */

/* sampling period */
referencia;
/* proportional constant */
/* integral constant */
/* derivative constant*/
Figura 5. 16 Interfaz de usuario para configurar el regulador PID

Dicha estructura estar referenciada en la estructura (valga la redundancia) OmsT_Qm_Attributes.
struct OmsT_Qm_Attributes
{
int pool_type;
int no_queues;
.
.
.
OmsT_Qm_PID_Queue_Params*
};
pid_queue_params_ptr;
A mayores, crearemos una funcin dentro de ip_qos_support.ex.c que nos permita reservar
memoria para esta estructura. Debemos tener en cuenta que el nmero de filas en la referencia es
indeterminado hasta el momento de la simulacin, por ello es necesario pasar a la funcin este
parmetro para saber cunto espacio debemos de reservar exactamente.
OMSC_EXPORT OmsT_Qm_PID_Queue_Params*
ip_qos_pid_queue_params_mem_alloc (int nr)
{
static Pmohandle
pid_params_pmh = OPC_PMO_INVALID;
static Pmohandle
referencia = OPC_PMO_INVALID;
OmsT_Qm_PID_Queue_Params* pid_params_ptr = OPC_NIL;
int num_rows = 0;
/** Function to allocate memory for PID parameters
/** that were configured by the user.
FIN (ip_qos_pid_queue_params_mem_alloc (void));
*/
*/
if (pid_params_pmh == OPC_PMO_INVALID){
pid_params_pmh = op_prg_pmo_define ("IP QoS Queue PID Parameters",
sizeof (OmsT_Qm_PID_Queue_Params), 70);
73
referencia = op_prg_pmo_define ("Referencia",

sizeof (OmsT_Qm_Ref_Definition)*nr, 70);
}
pid_params_ptr
(pid_params_pmh);
=(OmsT_Qm_PID_Queue_Params*)
op_prg_pmo_alloc
pid_params_ptr->referencia=(OmsT_Qm_Ref_Definition*)
op_prg_pmo_alloc (referencia);
FRET (pid_params_ptr);
}
La reserva de memoria se realizar dentro del modelo de procesos qos_attribute_definer. Aqu es

donde se encuentra el comportamiento del nodo QoS y aqu es donde los parmetros de usuario se
deben transcribir en las estructuras de la interfaz anteriormente creadas en oms_qm.h. En las
siguientes lneas de cdigo se ve la llamada a la reserva de memoria y la obtencin de l parmetro
de usuario PID Status para configurar la cola.
pid_queue_params_ptr = ip_qos_pid_queue_params_mem_alloc(nr);
op_ima_obj_attr_get(pid_parameters_child_objid,"PID Status",
&(pid_queue_params_ptr->pid_status));
Hecho esto, nos centraremos en el modelo de procesos ip_output_iface, es aqu donde se realiza el
control de la congestin y dnde van a tener uso nuestros algoritmos. Ir definiendo las
modificaciones realizadas en cada uno de los bloques, as como dentro del propio diagrama de
estados.
Dentro del grupo State Vars, aadiremos los siguientes atributos.
Tipo
double
Nombre
probabilidad
double
double
double
double
boolean
probabilidad_ant
tref
tant
t2ant
descartar
Descripcin
Probabilidad de descarte presente en cada momento dentro de la
cola.
Probabilidad de descarte en el periodo de muestreo anterior
Trayectoria de referencia a seguir en el momento actual.
Tamao de la cola en el periodo de muestreo anterior
Tamao de la cola hace 2 periodos de muestreo
Para saber, si en el periodo actual, se debe de aceptar o rechazar
el paquete
En el estado init aprovecharemos para inicializar todas estas variables.

Como ya se sabe, el PID recalcula el valor de la seal de control cada periodo de muestreo.
Dicho periodo debe ser una interrupcin, definida como CLOCK dentro del estado idle, dando
lugar cada vez que se produce a una computacin del nuevo valor de la probabilidad de descarte,
dentro de la funcin controller. (Figura 5. 17)
Dentro del bloque Header Block se encuentra definida la transicin CLOCK:
#define
74
CLOCK (op_intrpt_type() == OPC_INTRPT_SELF)
Figura 5. 17 Nueva transicin aadida ante la seal de reloj

El cdigo viene a decir, que esa transicin se debe tomar, y la consecuente llamada a controller(),
cada vez que suceda una auto interrupcin en el estado. La primera interrupcin de este tipo ser
programada tras realizar allocate_buffers, las interrupciones de periodos siguientes sern
programadas en el periodo actual dentro de controller.
La funcin controller es la que hace la labor de controlador PID, all se realizarn los clculos
necesarios para obtener la seal de control adecuada.
t = (double) oms_buffer_num_packets_get ((OmsT_Buffer_Handle) qm_info>child_queue_pool_ptr->queue_info_parray[0]->buffer_handle);
e = tref - t;
eant = tref - tant;
e2ant = tref - t2ant;
probabilidad = probabilidad_ant + kp*(1+periodo/ki+kd/periodo)*e + kp*(-12*(kd/periodo))*eant + kp*(kd/periodo)*(e2ant);
if(probabilidad > 1) probabilidad = 1;
if(probabilidad < 0) probabilidad = 0;
probabilidad = 1-probabilidad;
if (random_number > probabilidad) {
descartar = OmsC_Qm_Queued_Packet;
}else{
descartar = OmsC_Qm_Dropped_Packet;
}
Lo que se realiza dentro de la funcin es sencillo. Se obtiene el tamao actual de la cola y en base a
ese dato y valores antiguos de error se obtiene una probabilidad de descarte (acotada por los valores
0 y 1). En funcin de esa probabilidad, de manera aleatoria, se decide si se descarta o encola el
paquete (se asigna el valor sobre la variable de estado descartar). Se puede observar que la ley de
control discreta se ha implementado utilizando la aproximacin rectangular.
Para terminar se programa la siguiente interrupcin.
op_intrpt_schedule_self (op_sim_time()+periodo,0);
75
El valor de descartar nos ser til dentro de la funcin enqueue_packet(). Cuando usamos control
PID, el valor de qm_infosignal ser el almacenado en la variable descartar. La variable qm_info
contiene informacin relevante de la interfaz actual.
qm_info->signal = descartar;
En dicha funcin y en base a ese valor se decide qu hacer con el paquete en caso de que no pueda
ser procesado.
Con estas indicaciones queda claramente explicados los pasos que se han llevado a cabo para
realizar la implementacin del controlador PID.
76
Captulo VI
El Control Predictivo basado en
modelo
El control predictivo basado en modelo (Model Predictive Control, MPC) se ha desarrollado
considerablemente en las ltimas dcadas tanto en la industria como en la comunidad de
investigacin. Este xito se debe a que el Control Predictivo basado en Modelo es quizs la forma
ms general de formular el problema de control en el dominio del tiempo. El control predictivo
integra control ptimo, control de procesos con tiempos muertos, procesos multivariables y utiliza
las referencias futuras cuando estn disponibles. Al utilizar una estrategia con horizonte de
control finito permite la consideracin de restricciones y procesos no lineales. Este artculo
describe el control predictivo y sus posibilidades y pretende actuar como motivacin para su
utilizacin. [CB04]
6. 1 Introduccin
El Control Predictivo surgi a finales de los 70, y desde entonces se ha investigado y desarrollado
sobre l. Cuando hablamos de Control Predictivo no nos referimos a una estrategia de control
particular, sino a un conjunto de mtodos de control que utilizan de forma explcita un modelo del
proceso a controlar para obtener la seal de control ptima (a travs de una funcin objetivo).
Esta clase de controladores suelen tener la misma estructura y elementos, los cules numeramos a
continuacin:
Uso directo de un modelo que nos permita predecir el funcionamiento del sistema en el
futuro.
Minimizacin de una funcin objetivo para obtener la seal de control ptima para anular
el error.
Se utilizar un horizonte de control finito y deslizante sobre el cul se realizar el clculo
de la seal de control en cada uno de los muestreos del mismo (como veremos ms
adelante, slo se utilizar la primera seal de la secuencia y se repetir el proceso en el
periodo siguiente).
Los diferentes algoritmos de control predictivo se diferencian en el tipo de modelo usado
para representar al proceso y las perturbaciones, as como la eleccin de la funcin
objetivo considerada. Existen aplicaciones del control predictivo sobre procesos de muy
distinta ndoles, desde control de robots, anestesia clnica, industria del cemento,
desecadoras, brazos robticos, columnas de destilacin, plantas de PVC, generadores de
vapor...
Las ventajas que nos proporciona el control predictivo sobre otros mtodos son varias:
77
Se trata de una tcnica particularmente atractiva para los operadores, requieren unos
conocimientos bsicos sobre control predictivo y la sintonizacin del controlador es
bastante sencilla.
Se puede utilizar para controlar procesos de distinta naturaleza, con dinmicas diferentes,
susceptibles de perturbaciones y con varias entradas y salidas.
Su carcter predictivo lo hace compensar de forma intrnseca los tiempos muertos.
Introduce un control anticipativo, de forma natural se compensan las perturbaciones
medibles.
La ley de control resultante se puede implementar de forma sencilla (como veremos
posteriormente).
Realmente til cundo se conocen las referencias futuras.
Permite tratar restricciones de forma conceptualmente muy simple durante la fase de
diseo.
No todo son ventajas en el control predictivo, podemos enumerar tambin varios inconvenientes:
Su implementacin es bastante ms complicada y laboriosa que la de los clsicos PID.

Si el clculo de la ley se puede hacer fuera de lnea (dinmicas no cambiantes y sin
restricciones) todo es muy simple, sin embargo, cuando esto no es posible todo se
complica (numerosos clculos numricos por parte de las CPUs). En el actual trabajo nos
centraremos en el caso ms sencillo, ya que obtiene unos resultados bastante convincentes
e ilustrativos de la tcnica.
Sin duda la mayor complicacin del Control Predictivo radica en la obtencin de un
modelo del proceso. Un modelo demasiado alejado del sistema real no nos proporcionar
unos resultados satisfactorios. Se debe buscar un equilibrio entre abstraccin, complejidad
y correccin.
[Nor] y [Tad] han sido textos de referencia en este captulo.
6. 2 Estrategia del MPC
78
VI. EL CONTROL PREDICTIVO BASADO EN MODELO
Figura 6. 1 Explicacin grfica del control predictivo

La forma de proceder de los controladores de la familia MPC se muestra a continuacin. La
Figura 6. 1 nos servir de gua ilustrando el proceso que se describir en los siguientes tres puntos
claves (se ha tomado como referencia la exquisita explicacin en [CB04]).
1.
2.
3.
Las salidas futuras para un horizonte determinado N, llamado horizonte de prediccin, se

predicen cada instante t utilizando el modelo del proceso. stas predicciones de la salida
y(t+k|t) (prediccin de la salida t+k en el instante t) para k = 1..N dependen de los valores
conocidos hasta el instante t (entradas y salidas conocidas) y de las seales de control
u(t+k|t), k = 0...N-1, que han de ser calculadas y enviadas al sistema.
La secuencia de seales de control futuras se calcula minimizando un criterio para
mantener al proceso lo ms cerca posible de la trayectoria de referencia w(t+k). Este
criterio suele tomar la forma de una funcin cuadrtica del error entre la salida predicha y
la trayectoria de referencias futuras. En la mayor parte de los casos se incluye tambin el
esfuerzo de control dentro de la funcin objetivo. La solucin explcita se puede obtener
cuando el criterio es cuadrtico y el modelo lineal: en caso contrario se ha de utilizar un
mtodo numrico para buscar la solucin (mucho ms costoso computacionalmente
hablando).
La seal de control u(t | t) se enva al proceso mientras que el resto de seales calculadas
no sern consideradas, ya que en el instante siguiente de muestreo y(t+1) es ya conocida y
los pasos anteriores se repiten con este nuevo valor. Por lo que u(t+1 | t+1) se calcula con
informacin diferente y en principio ser tambin diferente de u (t+1 | t) (la prediccin
que se realiz en el muestreo anterior).
En la Figura 6. 2 vemos la estructura bsica que se necesita para implementar el control

predictivo. Como ya se ha dicho, se utiliza un modelo para predecir las salidas futuras a partir de
los valores de entrada y salida ya conocidos. Las acciones de control futuras se calculan mediante
un optimizador, que considera la funcin de coste y posibles restricciones.
79
Figura 6. 2 Partes constituyentes del controlador predictivo

El modelo del proceso es el elemento clave del controlador. La correccin del modelo definir el
correcto funcionamiento del controlador y su simplicidad facilitar su comprensin y posterior
implementacin. Las diferentes tcnicas de control predictivo difieren principalmente en el tipo
de modelo utilizado.
El optimizador es otra parte fundamental de la estructura, nos permitir obtener la seal de
control ptima a aplicar en cada uno de los instantes de muestreo. Si la funcin de coste utilizada
es cuadrtica, el modelo lineal y no existen restricciones, se puede obtener una solucin de manera
analtica. Si ste no fuera el caso se deber recurrir a un mtodo numrico de optimizacin con una
cantidad de clculo mucho mayor. El tamao del problema resultante depende del nmero de
variables, de los horizontes de control y prediccin y del nmero de restricciones, aunque por lo
general los problemas de optimizacin en este campo no suelen ser demasiado complicados.
A continuacin vamos a ver un curioso e ilustrativo smil entre la conduccin de un automvil
y el control predictivo (Figura 6. 3). El conductor conoce la trayectoria de referencia deseada para
un horizonte de control finito, es decir, ve la carretera en frente de l fijndose en ella hasta cierto
punto. El conductor en base a lo que est viendo y consciente de las caractersticas del vehculo modelo mental del mismo - decide tomar una accin (frenar, acelerar, girar, cambiar de marchar...)
para seguir la trayectoria deseada. El conductor, aun conociendo lo que piensa que tendr que
hacer despus, slo aplica la primera accin de control calculada mentalmente. El mismo proceso
se ir repitiendo sucesivamente. Se puede observar claramente el concepto de horizonte deslizante.
En base al mismo ejemplo, podemos explicar el control PID clsico. En este tipo de control slo se
utilizan las entradas y salidas en instantes del pasado, seria algo as como conducir fijndonos
nicamente en el espejo retrovisor del automvil. An as hay que reconocer, de todas formas, que
el control predictivo utiliza bastante ms informacin para lograr su propsito.
80
Figura 6. 3 Smil entre la conduccin de un vehculo y el control predictivo
6. 3 Formulacin del problema

A continuacin vamos a desgranar detalladamente la tcnica del GPC, desde la obtencin del
modelo, hasta el clculo de la seal de control minimizando la funcin de coste. En [Zub10] se
explica de forma muy amigable y precisa el caso del GPC monoviariable que, como veremos
posteriormente, es el que nos interesa a nosotros.
El Control Predictivo Generalizado (Generalized Predictive Control o GPC), es una tcnica de
control predictivo ampliamente estudiada a nivel acadmico e implementada a nivel industrial (un
ejemplo en [GT06]). Su funcionamiento se corresponde con el del resto de tcnicas de MPC, en el
que se pretende calcular una secuencia ptima de seales de control minimizando una funcin de
coste a lo largo de un horizonte de prediccin finito. En el caso concreto del GPC, se pretende
minimizar el error de seguimiento de trayectoria, as como el coste de control.
Aunque el GPC admite la inclusin de perturbaciones medibles en el modelo y el uso de
restricciones, en este proyecto slo se abordar el caso ms simple, el GPC sin restricciones para
un sistema SISO.
6.3.1 Formulacin del GPC utilizando modelo funcin de transferencia

Generalmente, la mayor parte de sistemas dinmicos suelen ser de carcter no lineal. Sin embargo,
considerando un determinado punto de operacin del sistema, en un entorno pequeo alrededor del
punto el comportamiento del sistema es equivalente al de uno lineal. Muchas aplicaciones se basan
en este principio de linealizacin.
Para definir la planta se utiliza un modelo CARIMA (Controller Auto-Regressive Integrated
Moving-Average) que toma la siguiente forma:
A( z 1 ) y (t ) B ( z 1 ) z d u (t 1) C ( z 1 )
e (t )
1 z 1
Donde
81
A( z 1 ) 1 a1 z 1 a 2 z 2 ... a na z na
B ( z 1 ) bo b1 z 1 b2 z 2 ... a nb z nb
C ( z 1 ) 1 c1 z 1 c 2 z 2 ... a nc z nc
y(t) es la salida del sistema (en nuestro caso el tamao de la cola), u(t) la seal de control
(probabilidad de descarte), e(t) es el ruido y d es el tiempo muerto del sistema, si este existiera.
Ntese que el modelo CARIMA ya incluye un trmino de ruido para las perturbaciones no
medibles en su definicin. Si el polinomio C fuera igual a 1, entonces e(t) ser un ruido blanco y
su media aritmtica ser nula. Si no es ste el caso general, el polinomio C definir el color del
ruido.
La funcin de coste a minimizar es una funcin genrica que incluye el error de seguimiento
de trayectoria en la ponderacin del trmino de control:
J ( N1 , N 2 , N u )
N2
Nu
(y (t k | t ) w(t k | t )) 2 (u(t k 1 | t )) 2
k N1
k 1
donde u (t ) u (t ) u (t 1) (1 z ) u (t ) es el operador diferencial, N1 y N2 son los

horizontes mnimo y mximo, respectivamente, de prediccin y N u es el horizonte de control. Aqu
viene bien puntualizar las diferencias entre cada uno de los horizontes. El horizonte de prediccin
est relacionado con el rango de instantes en los que se calcula la prediccin de la seal de salida,
en contraposicin, el horizonte de control tiene que ver con las seales de control que satisfacen las
salidas predichas, estas seales no se tienen por qu dar en los mismos momentos que las de salida,
existen tiempos muertos que hacen que haya desfase entre la entrada y la salida, de forma que el
efecto de una accin de control no se ve reflejado hasta d periodos de muestreo tras aplicarlo. Ms
adelante se profundizar ms sobre esto y se ver la forma en la que se establecen los valores de los
distintos horizontes.
6.3.1.1 Clculo de la ecuacin de prediccin utilizando la ecuacin diofntica
Nuestro objetivo ser lograr una expresin de la siguiente forma:
y Gu f
Donde Gu es la respuesta forzada del sistema y f es la respuesta libre.
Sabiendo lo que queremos, empezamos a operar sobre el modelo CARIMA anteriormente
descrito. Lo primero que haremos ser despejar la salida:
y (t )
B ( z 1 ) d
C ( z 1 )
z
u
(
t
1
)
e(t )
A( z 1 )
A( z 1 )(1 z 1 )
Para optimizar la funcin de coste J, es necesario calcular la prediccin de salida y(t+k) del modelo
durante el horizonte de prediccin para k N1 y k N2. Para lograr tal objetivo se utiliza un
artificio matemtico para transformar la anterior expresin, reescribiendo el polinomio del ruido
C(z-1) de forma que cumpla la siguiente ecuacin diofntica.
C ( z 1 ) E k ( z 1 )(1 z 1 ) A( z 1 ) z k Fk ( z 1 )
Donde, si el grado del polinomio A(z-1) es na, entonces Ek(z-1) es un polinomio de grado k-1 y
Fk(z-1) es de grado na. El clculo de estos polinomios se detalla en [Zub10].
Se considerar que e(t) es un ruido blanco, de modo que a partir de ahora tomaremos el
polinomio C como igual a 1. Si multiplicamos la anterior expresin por (1- z-1)Ek(z-1) z-k
82
E k ( z 1 ) A( z 1 ) y (t k ) E k ( z 1 ) Bk ( z 1 ) u (t d k 1) E k ( z 1 ) e(t k )
Jugando con las dos expresiones anteriores y reescribiendo obtenemos:
y (t k ) Fk ( z 1 ) y (t ) E k ( z 1 ) B ( z 1 ) u (t d k 1) E k ( z 1 ) e(t k )
Para obtener la prediccin de y(t+k), debemos estimar el valor del error e(t+k). En el caso que
estamos considerando, y dado que Ek(z-1) es un polinomio de grado k-1, todos los valores de error
pertenecern a instantes futuros, de manera que la mejor estimacin de estos es 0, es lgico que
queramos un error nulo de manera que la salida se ajuste al valor de consigna. Esto es debido a que
se trata de un error blanco. Por tanto la prediccin para un instante t+k calculada a partir del tiempo
t vendra dada por:
y (t k | t ) Gk ( z 1 ) u (t d k 1) Fk ( z 1 ) y (t )
Donde Gk(z-1) = Ek(z-1) B(z-1)
Utilizando este modelo podemos plantear una prediccin de las salidas para un horizonte de
muestreo N. En este caso, se considerar N u = N. Es importante darse cuenta de que el sistema
general tiene un retardo de d unidades de muestreo, como ya se ha dicho anteriormente, con lo que
la salida del sistema y(t) ser influenciada por la entrada u(t) tras d periodos de muestreo. Dicho
esto, planteamos la siguiente ecuacin para predecir la salida a lo largo del horizonte N:
y (t d k | t ) Fd k ( z 1 ) y (t ) Gd k ( z 1 ) u (t d k 1)
Donde, por definicin tenemos que:
G d k ( z 1 ) g k , 0 g k ,1 z 1 g k , 2 z 2 ... g k , k 1 nb z ( k 1 nb )
Es decir, de manera coloquial, como este polinomio acta sobre la entrada, no tenemos que
considerar los retardos.
Para resolver el problema del GPC, se hace necesario obtener la secuencia de seales de
control u(t), u(t+1), , u(t+N) que optimice la expresin J. Como el proceso tiene un tiempo
muerto de d periodos de muestreo, la salida slo se ver influenciada por la seal de control u(t)
tras d+1 periodos. Los horizontes se pueden definir por tanto como N 1=d+1, N2=d+N y Nu=N.
Vase que no tienen ningn sentido hacer N1<d+1, ya que los trminos que se aadiran a la
prediccin slo dependeran del pasado, y es absurdo encontrar un valor ptimo de algo que ya se
conoce y que ya ha sucedido. Por otra parte, si N 1>d+1 los primeros puntos de la prediccin, que
son los que mejor se estiman, no se consideraran, dando lugar a un control ineficiente.
Consideremos ahora el siguiente conjunto de predicciones de j pasos:
y (t d 1) G d 1 ( z 1 ) u (t ) Fd 1 ( z 1 ) y (t )
y (t d 2) G d 2 ( z 1 ) u (t 1) Fd 2 ( z 1 ) y (t )
y (t d N ) G d N ( z 1 ) u (t N 1) Fd N ( z 1 ) y (t )
Que podramos reescribir de forma matricial de la siguiente manera:
y Gu F ( z 1 ) y (t ) G ' ( z 1 ) u (t 1)
Con
83
g0
g
0
G

g N 1
0
g0
g N 2
0
0
G ' ( z 1 )
g0
(G d 1 ( z 1 ) g 0 ) z
(G d 2 ( z ) g 0 g1 z ) z
1
( N 1)
) z N
(G d N ( z ) g N 1 z
Fd 1 ( z 1 )
Fd 2 ( z 1 )
1
F (z )
1
Fd N ( z )
Los dos ltimos trminos de la ecuacin anterior slo dependen del pasado y por tanto podran ser
agrupados en un mismo vector f (respuesta libre del sistema) dando lugar a:
y Gu f
Que se trata de la misma ecuacin que queramos buscar desde el principio. En caso de que las
condiciones iniciales sean nulas la respuesta libre tambin lo ser. Si aplicramos un escaln
unitario a la entrada en el instante t, es decir u(t) = 1, u(t+1) = 0, , u(t+N-1) = 0, la
secuencia de salida t [ y (t 1), y (t 2),..., y (t N )]T es igual a la primera columna de la
matriz G.
La funcin de coste se puede escribir como:
J (Gu f w) T (Gu f w) u T u
El vector w se corresponde con los valores que ir tomando la seal de referencia a lo largo del
tiempo.
w [ w(t d 1) w(t d N )]T

Resolviendo un problema de optimizacin podemos obtener los valores adecuados de la seal de
control para aplicar sobre la planta.
u (G T G I ) 1 G T ( w f )
Como se coment anteriormente, en la estrategia de horizonte deslizante slo aplicamos la primera
de todas las seales de control calculadas (se vuelven a recalcular en cada periodo de muestreo).
Por tanto, podemos escribir:
u (t ) K ( w f )
Donde K es la primera fila de la matriz (G T G I ) 1 G T . Este hecho tiene un significado muy
claro, el cul se puede derivar fcilmente de la Figura 6. 4: si no existen errores futuros (predichos),
84
es decir, en el caso en que w f = 0, entonces no hay movimientos en la seal de control, ya que el

objetivo se satisfar con la evolucin libre del proceso. Sin embargo, en cualquier otro caso existir
un incremento de la accin de control proporcional (con factor K) al error futuro. Obsrvese que la
accin se toma respecto a errores futuros, no a errores pasados como en el caso de los controladores
realimentados convencionales (PID por ejemplo).
Figura 6. 4 Lazo de control predictivo

En cuanto al costo computacional, el GPC precisa de la inversin de una matriz de dimensin NxN
que requiere una carga de cmputo bastante elevada. Este problema no tiene demasiada
importancia debido a los potentes procesadores existentes a da de hoy en el mercado.
6. 4 El control predictivo aplicado al control de la congestin

Un modelo dinmico del comportamiento del protocolo TCP se puede obtener en base al modelo
del flujo de fluidos [ASB] [ASM] (intuitivamente pudimos apreciar esta similitud en el captulo 1).
El modelo estara descrito por las ecuaciones diferenciales siguientes:
W (t )
1
W (t ) W (t R (t R (t )))
p (t R (t ))
R (t )
2
R (t R(t ))
N (t )
q0
W (t ),
R (t )
N (t )
0,C
W (t ) , q 0
R (t )
q (t )
max
Dnde:
W Tamao medio, en paquetes, de la ventana TCP.
q Tamao medio de la cola en paquetes.
R Round trip time =
q
T p (segundos).
C
C Capacidad del enlace (paquetes/segundo).

Tp Retardo de propagacin (segundos).
85
N Factor de carga (n de sesiones TCP)

p Probabilidad de descartar un paquete.
La primera de las ecuaciones describe el control dinmico de la ventana TCP. La segunda modela el
cuello de botella en la cola como una diferencia acumulativa entre la llegada de paquetes y la
capacidad del enlace. El tamao de cola y de ventana son valores positivos. En esta formulacin, el
tamao de ventana TCP se incrementa en uno cada RTT si no se ha detectado congestin en la
interfaz y dividido a la mitad en el caso contrario. Adems, se asume que el esquema AQM que se
implementa marca los paquetes utilizando ECN para informar a la fuente TCP de la inminente
congestin.
6.4.1 Linealizacin del modelo

Como se puede observar por la expresin del apartado anterior, el modelo del router AQM utilizado
no es lineal (el mismo proceso no lo es), para analizar ciertos tipos de propiedades y disear
nuestro controlador necesitaremos un modelo lineal.
Para linealizar, asumimos que el nmero de sesiones TCP activas y la capacidad del enlace
son constantes, por ejemplo N(t) = N y C(t) = C. La dependencia del tiempo de retardo t-R sobre el
tamao de la cola q es ignorado y se considera con el valor t R0. El resultado de la linealizacin
son las siguientes ecuaciones:
R02 C
N
1
W (t ) 2 (W (t ) W (t R0 )) 2 (q(t ) q (t R0 ))
p (t R0 )
R0 C
R0 C
2N 2
q (t )
N
1
W (t )
q (t )
R0
R0
Donde dW(t) = W-W0, dq = q-q0 y dp = p-p0. El punto de operacin vendr dado por:
R0
q0
RC
2
T P , W0 0 , p 0 2
C
N
W0
La ecuacin anterior se puede separar en dos partes. El comportamiento de baja frecuencia del de
alta frecuencia (dinmica de la ventana).
C 2 /( 2 N )
P(s)
( s (2 N ) /( R02 C ))( s 1 / R0 )
2N 2
(s)
(1 e R0 S )
3
R0 C
6.4.2 Utilizacin del modelo en el MPC
Como ya se ha visto en este mismo captulo, el Control Predictivo basado en Modelo es una
estrategia de control basada en el uso explcito de un modelo de la planta para predecir la salida de
un proceso sobre un rango de tiempos. Para ello se utiliza una estrategia de horizonte deslizante. En
base a las salidas predichas se obtendrn las seales de control ptimas para lograr nuestro
objetivo. Slo la primera seal de entrada ser aplicada (en el periodo siguiente se volvern a
recalcular). El ptimo se obtiene minimizando una determinada funcin de coste.
El Control Predictivo Generalizado es un controlador predictivo clsico. Aunque hay
formulaciones para el caso multivariable (sistemas MIMO), el caso que nos acontece tiene una
86
nica entrada y una nica salida (sistema SISO). En el modelo AQM descrito anteriormente
tenemos la entrada p y la salida q aadiendo perturbaciones no medibles. De este modo, la funcin
que usaremos para realizar la prediccin de las salidas futuras vendr dado nicamente por el
modelo en baja frecuencia.
PGPC ( s)
C 2 /( 2 N )
( s (2 N ) /( R02 C ))( s 1 / R0 )
2
Eligiendo el periodo de muestreo como Ts 0.2 12 22 donde 1 R0 C /( 2 N ) y 2 R0 .
Obteniendo la expresin discreta de la funcin de transferencia tenemos:
PGPC ( z 1 ) z d
b1 z 1 b2 z 2
1 a1 z 1 a 2 z 2
Los coeficientes ai y bi se calculan directamente en la discretizacin y d representa el retardo del

sistema en periodos de muestreo. En nuestro caso, simplificando, si R 0 es el retardo de tiempo
continuo, entonces d=ceil(R0/Ts).
6. 5 Implementacin del MPC en OPNET

Este apartado es muy similar al del captulo anterior. La mayor diferencia radica en el tipo de
algoritmo de control que se va a implementar, pero a nivel de anlisis todo es bastante parecido.
Comentaremos los aspectos relevantes para el Control Predictivo de este apartado, e indicaremos al
lector acudir al captulo anterior para las secciones iguales.
6.5.1 Anlisis de requisitos

Estos son los requisitos que pode identificar en las sesiones de tutora y en los correos
intercambiados con la tutora del proyecto.
REQNUM 1
Descripcin
Justificacin
Configuracin
El usuario podr configurar los atributos relacionados con el control predictivo
El usuario debe tener libertad para definir las caractersticas principales del
sistema.
REQNUM 1.1
Descripcin
Trayectoria de referencia
Se deber poder introducir una referencia variable a lo largo del tiempo de la
simulacin.
Los casos de estudio ms interesantes estn relacionados con simulaciones en
los que el valor de referencia va variando a lo largo del tiempo
Justificacin
REQNUM 1.2
Descripcin
Justificacin
Modelo
Se deber de poder especificar un modelo de la red, de manera que el usuario,
previo modelado, pueda indicar uno que se aproxime a las caractersticas de la
topologa. Este modelo ser de tipo CARIMA y estar definido por dos
polinomios A(z-1) y B(z-1) as como de un valor d de retardo.
Hacer el control predictivo adaptable a cualquier topologa posible.
87
REQNUM 1.3
Descripcin
Justificacin
Horizonte de control
El usuario introducir un horizonte de control a su antojo. El horizonte de
prediccin ser fijado de manera automtica en base al valor del retardo d.
Realizar estudios con distintos horizontes y encontrar los valores que mejor
resultados ofrece.
REQNUM 1.4
Descripcin
Justificacin
Periodo de muestreo
Se podr introducir el periodo que marcar el re-clculo de la seal de control.
Experimentos con diferentes periodos de muestreo.
REQNUM 1.5
Descripcin
Justificacin
Activacin/Desactivacin
El algoritmo slo se usar si el usuario lo habilita. En el caso de permanecer
habilitado al mismo tiempo que PID, prevalecer el MPC sobre ste.
Comparar el uso de este sistema de control de congestin con los otros.
REQNUM 2
Descripcin
Justificacin
Visualizacin de estadsticas
Se deben poder visualizar varias nuevas estadsticas al finalizar la simulacin.
Necesario para nuestro estudio.
REQNUM 2.1
Descripcin
Justificacin
Estadstica de trayectoria de referencia

Se quiere que la referencia sea visualizable en las grficas tras la simulacin
Permite observar bien el acercamiento de la salida a la referencia
REQNUM 2.2
Descripcin
Estadstica de probabilidad de descarte

Queremos que en las grficas se vea como va variando la probabilidad de
descarte para que la salida se aproxime al valor de consigna.
Permite ver la relacin entre entrada y salida del sistema SISO
Justificacin
En cuanto a los requisitos no funcionales:

REQNUM 3
Descripcin
Justificacin
Herramienta OPNET
El controlador deber ser implementado en esta herramienta
OPNET es una herramienta de estudio de redes muy importante. Es ideal para
implementar esta clase de algoritmos y realizar comparativas.
6.5.1.1 Diagramas del Modelo de Casos de Uso

Caso de Uso: Simular
Idntico al del captulo del PID, pero configurando los parmetros pertenecientes al MPC.
6.5.1.2 Modelo esttico
A este nivel de modelado todo sucede exactamente de la misma forma explicada en el captulo 5.
6.5.1.3 Modelo dinmico
En este apartado, en lo referente a diagramas de colaboracin, es tal cul se explic en el anterior
captulo.
No ocurre lo mismo con los diagramas de estado. Aqu podemos notar alguna leve diferencia.
El control predictivo (sin modelo cambiante), necesita de un estado previo, antes de empezar el
88
control de la congestin, para inicializar sus parmetros en base al modelo introducido por el
usuario (Figura 6. 5).
Figura 6. 5 Diagrama de mquina de estados para el MPC

Una vez configurados los parmetros, la mquina transitar al estado en el que la interfaz IP
permanecer activa desempeando la tarea de control de congestin. El evento reloj,
desencadenar una llamada a la operacin controlador(), su comportamiento se puede describir en
el diagrama de actividad de la Figura 6. 6.
Se puede observar que este diagrama de actividad es casi idntico al del captulo previo,
exceptuando el estado en el que se calcula la prediccin. Centrndonos en este estado, que no
representa exactamente una operacin atmica, se podra definir un nuevo diagrama de actividad
que defina el comportamiento exacto de la prediccin del MPC (o del PID), sin embargo, viendo
esta labor ms comn de la fase de diseo, los detalles de funcionamiento de los algoritmos sern
definidos en la seccin posterior.
89
Figura 6. 6 Diagrama de actividad de la operacin controlador()
6.5.2 Diseo e implementacin del control predictivo utilizando OPNET

A continuacin se ir describiendo paso a paso el proceso de adicin de este nuevo mtodo dentro
de la herramienta OPNET (en MATLAB, por ejemplo, existe un paquete que implementa el
control predictivo [MR98]). Muchos aspectos ya han sido tratados en la implementacin del PID,
por tanto, si fuera necesario profundizar en alguna parte el lector puede remitirse al anterior
captulo.
Al igual que hicimos en el caso del PID, lo primero que haremos ser aadir los atributos
necesarios para que el usuario pueda configurar el control predictivo desde el mdulo QoS. Desde
el modelo de procesos qos_attribute_definer, como se explic anteriormente, aadiremos un nuevo
atributo compuesto, en este caso llamado MPC Parameters, ste estar compuesto de los atributos
mostrados en la Figura 6. 7.
90
Figura 6. 7 Atributos aadidos para el control predictivo

Los atributos a y b sern compuestos, son sendos arrays de doubles que representarn el modelo
utilizado para las predicciones.
A continuacin aadimos en oms_qm.h las estructura necesarias para que se almacenen estos
valores.
typedef struct
{
double* a; /* polynomial A(z^-1) */
double* b; /* polynomial B(z^-1) */
OmsT_Qm_Ref_Definition*
referencia;
int lambda;
int d; /* delay */
int h; /* prediction horizon */
int na;
int nb;
int mpc_status; /* To enable or disable MPC */
double sample_time;
} OmsT_Qm_MPC_Queue_Params;
Las variables na y nb contendrn la informacin del grado de los polinomios a y b respectivamente.

El tipo OmsT_Qm_Ref_Definition es, como ya se vio en el captulo anterior, el que tiene la
estructura de definicin de una trayectoria de referencia.
En OmsT_Qm_Attributes tendremos una variable que haga referencia a este tipo
(OmsT_Qm_MPC_Queue_Params).
Para realizar la reserva de memoria, crearemos una funcin en ip_qos_support.ex.c, llamada
ip_qos_mpc_queue_params_mem_alloc, de manera que dispongamos del espacio suficiente para
almacenar todos los valores de todos los atributos introducidos por el usuario.
OMSC_EXPORT OmsT_Qm_MPC_Queue_Params*
ip_qos_mpc_queue_params_mem_alloc (int nr, int na, int nb){
static Pmohandle
mpc_params_pmh = OPC_PMO_INVALID;
static Pmohandle
referencia = OPC_PMO_INVALID;
static Pmohandle
a = OPC_PMO_INVALID;
static Pmohandle
b = OPC_PMO_INVALID;
OmsT_Qm_MPC_Queue_Params* mpc_params_ptr = OPC_NIL;
OmsT_Qm_Ref_Definition* ref = OPC_NIL;
int num_rows = 0;
/** Function to allocate memory for MPC parameters
/** that were configured by the user.
*/
*/
91
FIN (ip_qos_mpc_queue_params_mem_alloc (void));

if (mpc_params_pmh == OPC_PMO_INVALID){
mpc_params_pmh = op_prg_pmo_define ("IP QoS Queue MPC Parameters",sizeof
(OmsT_Qm_MPC_Queue_Params), 70);
referencia = op_prg_pmo_define ("Referencia",sizeof
(OmsT_Qm_Ref_Definition)*nr, 70);
a = op_prg_pmo_define ("a",sizeof (double)*na, 70);
b = op_prg_pmo_define ("b",sizeof (double)*nb, 70);
}
mpc_params_ptr = (OmsT_Qm_MPC_Queue_Params*) op_prg_pmo_alloc
(mpc_params_pmh);
mpc_params_ptr->a=(double*) op_prg_pmo_alloc (a);
mpc_params_ptr->b=(double*) op_prg_pmo_alloc (b);
mpc_params_ptr->referencia=(OmsT_Qm_Ref_Definition*) op_prg_pmo_alloc
(referencia);
FRET (mpc_params_ptr);
}
Cabe destacar que, al igual que pasa con la referencia, el nmero de valores de los arrays a y b es
indeterminado, y por tanto, hasta que no comience la simulacin no se sabr el espacio exacto
necesario a reservar (de ah que se pasen los valores na y nb como parmetro a la funcin). Esta
reserva de espacio se realizar dentro del modelo de procesos ip_qos_attribute_definer, del mismo
modo que la transcripcin de los valores configurables de usuario a las estructuras de descripcin
de la cola.
op_ima_obj_attr_get(mpc_parameters_child_objid, "a",&att_pointer);
num_rows = op_topo_child_count (att_pointer, OPC_OBJTYPE_GENERIC);
mpc_queue_params_ptr->na = num_rows-1;
for(i=0;i<num_rows;i++){
att_pointer2 = op_topo_child (att_pointer, OPC_OBJTYPE_GENERIC,i);
op_ima_obj_attr_get(att_pointer2, "a", &(mpc_queue_params_ptr->a[i])) ;
}
En el cdigo de ejemplo se observa como se obtiene el atributo a, se calcula cuntos valores (hijos)
tiene y se copian los valores dentro del vector definido en la estructura de la cola.
La mayor parte de la implementacin se localiza dentro del modelo de procesos
ip_output_iface. Las variables de estado definidas quedan resumidas en la siguiente tabla:
Tipo
double
double
double
double
double*
double**
double**
Nombre
tref
probabilidad
probabilidad_ant
probabilidad_2ant
Ks
Gp
F
Descripcin
Tamao de la cola en el periodo de muestreo anterior
Probabilidad de descarte presente en cada momento dentro de la cola.
Probabilidad de descarte en el periodo anterior
Probabilidad de descarte hace 2 periodos
Submatriz de K utilizada en el control predictivo
Matriz G dentro del control predictivo
Matriz F del control predictivo
double
f_act
Variable temporal para los clculos del MPC
92
double*
int
int
boolean
ht
na_
h_
descartar
double
tref
Contendr valores de histricos necesarios en los clculos del MPC

Grado del polinomio A(z-1)
Horizonte de control del MPC
Para saber, si en el periodo actual, se debe de aceptar o rechazar el
paquete
Trayectoria de referencia a seguir en el momento actual.
El diagrama de estados para tratar el MPC ha sido modificado. Se ha aadido un nuevo estado
forzado, control_predictivo, que se encargar de todas las tareas de inicializacin y carga de datos
de matrices necesarias para que el controlador predictivo pueda funcionar (Figura 6. 8).
Figura 6. 8 Nuevo aspecto del modelo de procesos ip_output_iface

En el estado init inicializaremos las variables. Tras realizarse el allocate_buffers(), si el control
predictivo est activo, realizaremos su configuracin llamando a la siguiente funcin:
configurar_control_predictivo(Ks, Gp, F, a, b, na_, nb, h_, d, lambda);
Esta funcin est definida en un fichero externo, control_predictivo.h e implementada en

control_predictivo.ex.cpp. Para que el modelo de procesos tenga visibilidad de estos archivos es
necesario indicrselo. Para ello vamos a File Declare external files, y en la ventana emergente
que se abre marcamos el control predictivo.
Seguidamente describiremos brevemente lo que se realiza dentro de la funcin
configurar_control_predictivo().
93
En primer lugar, en base al horizonte h definido y al retardo del proceso, obtendremos los
lmites mnimo y mximo del horizonte de prediccin:
int h1 = d + 1;
int h2 = d + h;
Seguidamente llamaremos a una funcin de inicializacin con los siguientes parmetros:

inicializarControlPredictivo(a, b, h, h1, h2, Ks, F, Gp, na, nb, lambda);
Esta funcin se encargar de realizar los clculos necesarios para obtener las matrices descritas en
la seccin 6.3.1.1 y en base a las cuales podremos obtener nuestra ecuacin de prediccin.
Sabiendo el valor de la primera fila de la matriz F, podemos ir calculando el resto en base a
valores anteriores (se podra haber programado tambin de manera recursiva).
for(int j = 0; j <= na; j++){
F[0][j] = -producto[j+1];
}
for(int i = 1; i < h2; i++){
for(int j = 0; j <= na; j++){
F[i][j] = F[i-1][j+1]-F[i-1][0]*(a[j+1]-a[j]);
}
F[i][na] = F[i-1][0]*a[2];
}
producto es un array auxiliar que nos permitir obtener el valor de la primera fila de F.
De la matriz F, slo nos interesan los valores que caen dentro del horizonte de prediccin, por
tanto nos quedaremos con una submatriz que no contenga los valores del polinomio en instantes
que caen dentro del retardo d.
La matriz E tambin se obtiene a partir del valor de su primera fila (el valor del polinomio) y
haciendo uso de la matriz F recin calculada.
Como suponemos un ruido blanco de media 0, este primer valor ser igual a 1.
E[0][0] = 1.0; //ruido blanco de media 0
for(int i=1; i < h2; i++){
for(int j=0; j < i; j++){
E[i][j] = E[i-1][j];
}
E[i][j] = F[i-1][0];
for(int j = i+1; j < h2; j++){
E[i][j] = 0;
}
}
Teniendo F calculada, se puede obtener el valor de Gk.

for(int i = 0; i <= nb; i++){
Gk[0][i] = b[i];
}
for(int i=1; i<h2; i++){
94
for(int j=0; j < i; j++){

Gk[i][j] = Gk[i-1][j];
}
for(int j=0; j <= nb; j++){
Gk[i][i-1+(j+1)] = Gk[i-1][i-1+(j+1)]+F[i-1][0]*b[j];
}
}
El array b es el polinomio B(z-1) representado en la funcin CARIMA.

De la matriz G se obtienen directamente las matrices G y G tal y como se muestra en la
siguiente implementacin:
for(int i=0; i<h; i++){
for(int j=0; j < h; j++){
G[i][j]=0;
}
}
int ib=0;
int jb=0;
jb=0;
for(int j=i; j >= 0; j--){
G[ib][jb]=Gk[i][j];
jb++;
}
ib++;
}
ib=0;
jb=0;
jb=0;
for(int j=i+1; j <= nb+i; j++){
Gp[ib][jb]=Gk[i][j];
jb++;
}
ib++;
}
A continuacin calculamos (G T G I ) 1 G T . De todos estos clculos cabe destacar la llamada

a la funcin MatrixInversion. Esta rutina nos permitir obtener la matriz inversa (tercer ltimo
parmetro) de la matriz origen (primer parmetro) indicando la dimensin (segundo parmetro).
MatrixInversion(GtG, h, Inversa);
Una vez hechas estas operaciones, obtendremos la matriz K.

El objetivo final es obtener las matrices Gp, F y Ks (primera fila de la matriz K), las cuales
nos permitirn crear la ecuacin que defina las predicciones.
Realizado el estudio de cmo se consigue inicializar el control predictivo, vamos a ver cmo
acta el algoritmo para realizar las predicciones. Al igual que en el PID, dentro del estado idle
tenemos una transicin CLOCK que desencadena la llamada a la funcin controller(). Esta funcin
dispondr tambin del comportamiento deseado para el control predictivo.
95
t = (double) oms_buffer_num_packets_get ((OmsT_Buffer_Handle) qm_info>child_queue_pool_ptr->queue_info_parray[0]->buffer_handle);

dif_probabilidad = 0;
ht[0] = t;
f_act = 0;
for(i=0;i<h_;i++){
for(j=0;j<=na_;j++){
f_act += F[i][j]*ht[j];
}
dif_probabilidad+=Ks[i]*((tref)-(f_act+Gp[0][i]*(probabilidad_antprobabilidad_2ant)));
f_act = 0;
}
probabilidad = probabilidad_ant + dif_probabilidad;
La variable ht contendr el histrico de tamaos de cola. En funcin de este array y de la matriz F

podemos obtener el valor que nos interesa f_act. Con este valor y la matriz Gp podemos ir
acumulando el valor diferencial de probabilidad p y a partir de ste obtenemos la seal de control
deseada.
96
Captulo VII
Simulaciones y resultados
Este captulo se puede considerar como la culminacin de los estudios y trabajos descritos
anteriormente. Es ahora cuando toca comprobar la bondad de los resultados obtenidos utilizando
los nuevos algoritmos implementados en OPNET. Lo primero que haremos ser valorar los
resultados utilizando control PID y predictivo, estudiaremos la evolucin del sistema ante la
variacin de los diferentes parmetros que los definen. A continuacin, ambos mtodos sern
comparados entre ellos mismos y con los ya existentes en la herramienta.
En cada uno de los apartados, lo primero que se har ser mostrar los distintos valores de los
atributos a travs de los cuales se ha configurado el modelo, as como sus distintos perfiles de
ejecucin. Si bien es muy complicado (imposible) mostrar todos los parmetros relacionados con
la configuracin del modelo, s se vern los ms relevantes.
7. 1 Experimentos utilizando Control Predictivo.

Partiremos de esta sencilla topologa mostrada en la Figura 7. 1.
Figura 7. 1 Topologa de estudio

La estacin de trabajo Equipo1 ser la encargada de generar el trfico en la red. Router1
encaminar los paquetes hasta Router2, el cul los entregar sobre el servidor Ethernet destino
(Servidor). A mayores, se definirn tres objetos de configuracin, Aplicaciones, Perfiles y
QoS para establecer normas sobre la generacin y el tratamiento del trfico en la red.
97
Un resumen de la aplicacin definida en el nodo Aplicaciones se muestra en la siguiente

tabla:
Atributo
Tipo de aplicacin
Frecuencia de las peticiones
Tamao de los ficheros
Valor
FTP
1 segundo
5500000 bytes
Se toma la frecuencia de las peticiones y el tamao de los archivos como constantes para, en
principio, facilitar el aprendizaje.
El nodo Perfiles quedara de la siguiente manera:
Atributo
Aplicacin que se ejecuta
Umbral de inicio de ejecucin
Duracin
Inicio de sesin
Cierre de sesin
Valor
Aplicacin FTP definida anteriormente
60 segundos
40000 segundos
Inmediato
Final de la simulacin
A continuacin configuraremos el nodo que ms nos interesa, el de la calidad de servicio o QoS.

En este apartado nos centraremos en los parmetros del MPC. Los valores del modelo de
prediccin se han obtenido directamente de [ASB] y [ASM].
Atributo
Tamao mximo de la cola
Polinomio A(z-1)
Polinomio B(z-1)
Retardo
Referencia
Periodo de muestreo
Valor
600 paquetes
1-1,476 z-1+0.5416 z-2
-14,9-12,15 z-1
1
3
0
500p (5h) - 350p (5h) - 425p - (5h)
0,3 segundos
La referencia viene expresada por el nmero de paquetes que se desea que haya en la cola y el
tiempo durante el que se quiere que esto sea as. Por ejemplo, empezamos con una referencia a
500 paquetes durante 5 horas.
Teniendo todas estas configuraciones descritas, el siguiente paso es disponer los distintos
parmetros de lo que seran los objetos fsicos reales.
La estacin de trabajo Equipo1 quedara de la siguiente manera.
Atributo
Perfiles soportados
Valor
El perfil FTP descrito anteriormente
En el caso del servidor de la topologa tendremos lo siguiente:

Atributo
Servicios soportados
Valor
Actuar como servidor FTP
Ya slo nos quedara configurar los dos enrutadores antes de comenzar nuestra simulacin. Al
igual que en el resto de elementos, en la siguiente tabla vemos los atributos ms importantes que
se han considerado:
98
VII. SIMULACIONES Y RESULTADOS
Atributo
Mximo ancho de banda reservado
Valor
3500 bits por segundo (absoluto)
Slo se han realizado modificaciones en la capacidad del enlace que une los dos routers, queremos
que esta lnea no sea demasiado rpida para que facilite la generacin de un cuello de botella en la
red y se forme la consecuente congestin.
Por ltimo, antes de iniciar la simulacin, tenemos que configurar las interfaces IP para que
hagan uso del Control Predictivo implementado. Para ello, seleccionamos el enlace entre los dos
routers y en el men Protocols IP QoS Configure QoS Aparecer una ventana
emergente similar a la de la Figura 7. 2.
Figura 7. 2 Configuracin de interfaces IP

Nos aseguramos de que los datos son concordantes con los de la figura y damos OK. Si todo ha
ido bien veremos como el enlace seleccionado cambia de color (Figura 7. 3).
Figura 7. 3 Enlace entre routers

El siguiente paso ser elegir las estadsticas de inters. Las ms importantes sin duda en el control
automtico son la entrada (probabilidad de descarte), la salida (utilizacin del buffer) y la
referencia (Figura 7. 4).
99
Figura 7. 4 Estadsticas locales seleccionadas

Para tener constancia de la bondad del algoritmo, tambin sacaremos una grfica con la
estadstica global de los paquetes descartados (Figura 7. 5).
Figura 7. 5 Estadsticas globales seleccionadas

A continuacin lanzaremos una simulacin de 15 horas. La duracin real en mi PC ha sido de
poco ms de medio minuto. Una vez terminada podemos ver los distintos resultados.
Nos centraremos en el Router1 (dnde hemos creado el cuello de botella). En la figura 7.6
se puede ver el valor del buffer a lo largo del tiempo y su adaptabilidad a la referencia
Observamos que la salida se adapta de forma bastante ptima a la referencia. A los 40.000
segundos finaliza el perfil de generacin de trfico que hemos definido, sin embargo, tras esperar
60 segundos vuelve a comenzar. Vemos como en este pequeo intervalo la cola se comienza a
vaciar, ante la ausencia de trfico, pero, en el momento que vuelve a generarse carga sobre la red,
se vuelve a alcanzar nuevamente el valor de 425 en la referencia.
El trfico perdido, se sita, en media, en torno a los 3.2 paquetes por segundo de media (se
puede apreciar en la Figura 7. 7).
100
Figura 7. 6 Variable controlada y referencia
Figura 7. 7 Media de trfico descartado
101
7.1.1 Variaciones en el valor del horizonte

A continuacin vamos a comparar los resultados de varias simulaciones en las que la variable
cambiante ser el horizonte de control.
h
1
3
8
En la Figura 7.8 se pueden apreciar los resultados. Para los valores de horizonte de prediccin 3 y
8, a pesar de ser uno ms del doble que el otro, los resultados obtenidos son casi idnticos.
Figura 7. 8 Ocupacin de la cola en funcin del horizonte

Es para el caso de un horizonte igual a 1 cuando el control se hace inexistente, parece ser que para
un horizonte tan pequeo no se consiguen predicciones correctas para calcular una seal de
control adecuada. Vemos que tanto para un horizonte 3 como 8 se comporta muy bien, sin
embargo, el de 8 es algo ms ptimo. En el intervalo sin carga, parece que el horizonte mayor
consigue predecir con mayor exactitud lo que suceder a continuacin y no se ve una reduccin
tan pronunciada de la ocupacin tamao de la cola.
7.1.2 Variaciones en el valor del retardo

Manteniendo un valor del horizonte de control constante, igual a 3, estudiaremos cuatro
escenarios en los que los valores de d se movern entre los de la siguiente tabla. El resto de
valores seguirn siendo iguales a los descritos en el punto 7.1 para el MPC (de aqu en adelante
todos los atributos que no se mienten de forma explcita conservarn el valor de dicho apartado).
102
d
1
3
6
9
En la Figura 7. 9 se puede ver que, a pesar de las variaciones en el retardo, los resultados
obtenidos son similares. La adaptacin a la referencia es en todos los casos bastante buena.
Destacamos el intervalo sin trfico, aqu, el valor 6 es el que mejor resultados proporciona. Es
muy probable que ese valor del retardo sea el que mejor se adapte a la topologa representada.
Figura 7. 9 Ocupacin de la cola en funcin del retardo
7.1.3 Variaciones en el periodo de muestreo

Estos experimentos no van tan referidos al control predictivo en s, sino a cualquier tipo de
control digital. Veremos en qu influye la variacin del tiempo de muestreo de cara a la bondad
de los resultados. En la siguiente tabla se muestran los valores con los que se ha probado:
T
0,3
1,3
10
Los resultados obtenidos se pueden apreciar en las grficas de la Figura 7. 10. Como era de
esperar, a medida que el periodo de muestreo se hace ms grande los resultados se vuelven menos
precisos. La lnea azul marino (0,3 segundos) se ajusta mucho a la trayectoria de referencia,
aumentando un segundo el periodo de muestreo (lnea roja) los resultados siguen siendo muy
buenos, pero el resultado es ms impreciso, por ltimo, la trayectoria verde es la de T=10
segundos, se ve a simple vista que la salida es extremadamente mala. En la eleccin del periodo
de muestreo hay que buscar un equilibrio entre la correccin y el coste computacional. A da de
103
hoy, los grandes avances y la reduccin de costes en los microprocesadores y el hardware en

general hace que el segundo aspecto pueda ser despreciable.
Figura 7. 10 Ocupacin de la cola en funcin del periodo de muestreo
7.1.4 Variaciones en el valor de

Veremos el comportamiento del regulador MPC ante variaciones en el parmetro .
0
150
250
Como se puede apreciar en la figura, no es un parmetro demasiado determinante a la hora de
realizar el control. En los tres experimentos, con valores tan dispares del parmetro, se han
conseguido unos resultados muy satisfactorios. Una vez ms nos centraremos en el intervalo de
tiempo en el que no hay carga sobre la red, por lo que vemos, se deja decrecer ms la cola a
medida que el parmetro tiene un valor mayor.
104
Figura 7. 11 Ocupacin de la cola en funcin de
7. 2 Experimentos utilizando Control PID.

Repetiremos los experimentos del apartado anterior, pero en esta ocasin desactivaremos el
control predictivo y habilitaremos el control PID clsico tradicional. El valor de los parmetros
independientes del tipo de control sern similares a los mostrados en el apartado 7.1. Nos
centraremos en los parmetros del controlador PID. A continuacin se muestran varios valores
obtenidos de forma emprica mediante los cuales se consigue sintonizar el controlador.
Atributo
Kp
Ki
Kd
Periodo de muestreo
Referencia
Valor
600
1
0,2
1 segundo
500p (5h) - 350p (5h) - 425p - (5h)
En la Figura 7. 12 se pueden ojear los resultados obtenidos. Vemos que por lo general el resultado
es muy bueno, el sistema se adapta muy bien a los cambios en su referencia y de manera bastante
rpida. En el intervalo famoso, en el que no hay carga, no se reduce casi nada el tamao de la
cola.
105
Figura 7. 12 Ocupacin de la cola a lo largo del tiempo en el controlador PID
7.2.1 Variaciones en la constante proporcional

Seguidamente vamos a estudiar como afecta al control la variacin del valor de la constante Kp.
El resto de constantes permanecern igual que las indicadas en el apartado 7.2.
Kp
0.5
10
600
En la Figura 7. 13 podemos ver los resultados. Es curioso ver que para valores tan alejados como
10 y 600, el resultado es prcticamente coincidente, lo cul nos muestra que llegado a cierto punto,
el aumento de Kp no proporciona una respuesta ms rpida ni ms ptima. Vemos que para el caso
de 0,5 si que existe cierta diferencia en la salida, en el intervalo libre el vaciado de la cola es ms
brusco que en los otros dos casos estudiados.
106
Figura 7. 13 Ocupacin de la cola en funcin de la constante proporcional del PID
7.2.2 Variaciones en la constante integral

Usaremos los siguientes valores para la constante integral:
Ki
0,5
2
10
El valor de 0,5 se ajusta muy bien a la trayectoria de referencia, sin embargo, responde peor a
variaciones de carga en la red. El valor 2 ya se ha visto en anteriores experimentos. Por ltimo, un
valor de 10 nos aleja de la trayectoria de referencia, genera una salida ms oscilatoria y, adems,
genera cierto error estacionario de valor considerable. (Figura 7. 14)
7.2.3 Variaciones en la constante derivativa

Estos sern los valores con los que jugaremos:
Kd
0.2
2
10
En la Figura 7.15 vemos cmo los resultados obtenidos para los valores anteriores son muy
diferentes. Se puede observar como a medida que aumentamos el valor de Kd nos alejamos
ligeramente de la referencia. El caso de Kd = 2, a pesar de alejarse levemente de la referencia,
responde muy bien ante las variaciones de carga.
107
Figura 7. 14 Ocupacin de la cola en funcin de la constante integral del PID
Figura 7. 15 Ocupacin de la cola en funcin de la constante derivativa del PID
108
7.3 Comparacin de distintos mtodos de control de la congestin

Hemos llegado al punto cumbre del desarrollo de este proyecto. En este apartado se vern las
mejoras y carencias de cada uno de los algoritmos implementados (PID, MPC) frente a los ya
existentes (Drop Tail, RED). Se expondrn una serie de modelos y escenarios de diversa ndole y
se har hincapi en el foco importante de estudio en cada uno de los casos.
7.3.1 Primeros experimentos comparando el PID y el MPC

En primer lugar vamos a realizar un experimento, basndonos en el mismo modelo estudiado
hasta ahora, en el que compararemos los dos algoritmos que hemos implementado, el controlador
PID y el basado en Control Predictivo. Para ambos casos se tomarn los siguientes valores como
periodo y trayectoria de referencia.
Atributo
Periodo de muestreo
Referencia
Valor
0.3 segundos
100p (2,5h) - 50p (2,5h) - 250p - (2,5h)
500p (2,5h) - 150p (2,5h) - 325p - (2,5h)
El valor de la salida y referencia para ambos algoritmos se muestra en la Figura 7. 16. Se ve

claramente como ambos controladores funcionan de una forma bastante ptima, adaptndose a la
referencia sin problemas en cada uno de los saltos. En las variaciones de carga el control
predictivo presenta un comportamiento algo mejor que el PID (). En cuanto al error
estacionario, en la mayora de los casos es menor para el MPC (). En la Figura 7. 17 podemos
ver una versin ampliada de la salida al comienzo de la simulacin.
Figura 7. 16 Comparacin de la salida del MPC y el PID
109
Figura 7. 17 Zoom sobre la anterior figura

Por ltimo, para caracterizar la bondad de cada uno de los algoritmos veremos cuantos paquetes
se han perdido en cada uno de los casos. En la Figura 7. 17 vemos que, aunque el nmero de
paquetes perdidos en ambos experimentos es similar, el controlador MPC es causante del descarte
de ms paquetes.
Figura 7. 18 Trfico descartado en el experimento, tanto para MPC como para PID
7.3.2 Comparando MPC y PID con RED y Drop Tail

Partiremos de una topologa similar, visualmente, a la ya utilizada en los puntos anteriores.
Intentaremos exponer casos ms realistas, la carga en la red se corresponder con casos reales de
alta carga en la transferencia de ficheros FTP.
A continuacin se muestran los atributos relevantes de configuracin de cada uno de los
elementos de la red.
110
En el nodo Aplicaciones definiremos el comportamiento del protocolo FTP de la siguiente

manera:
Atributo
Tipo de aplicacin
Valor
FTP
Distribucin exponencial de media 50 seg.
300000 bytes
Sobre Perfiles definiremos un comportamiento de utilizacin de la aplicacin FTP definida

anteriormente.
Atributo
Duracin
Repeticiones de ejecucin de aplicacin
Tiempo de espera para que comience otra
repeticin de ejecucin de aplicacin.
Patrn de repeticin
Repeticiones del perfil
Tiempo entre repeticiones del perfil
Inicio de sesin
Cierre de sesin
Valor
60 segundos
4.000 segundos
1
0 segundos
Concurrente
1
0 segundos
Inmediato
Fin de la simulacin
El Equipo1 utilizar este perfil de ejecucin. En cuanto a los algoritmos de control de la

congestin, tendremos los siguientes valores:
En el caso del MPC:
Atributo
Polinomio A(z-1)
Polinomio B(z-1)
Retardo
Referencia
Periodo de muestreo
Valor
600 paquetes
1-1,476 z-1+0.5416 z-2
-14,9-12,15 z-1
1
3
100 paquetes
0,2 segundos
Para el PID:
Atributo
Kp
Ki
Kd
Periodo de muestreo
Referencia
Valor
600
1
0,2
0,2 segundos
100 paquetes
Para RED se usarn los siguientes valores de atributos:

Atributo
Factor de peso exponencial
Umbral mnimo
Umbral mximo
Valor
9
50
150
111
Denominador de probabilidad de marcado

Marcado CE
10
Deshabilitado
Las estadsticas de estudio se muestran a continuacin

Estadsticas Globales
FTP
Trfico Recibido (paquetes/segundo)
Trfico Enviado (paquetes/segundo)
IP
Trfico Descartado (paquetes/segundos)
TCP
Contador de retransmisiones
Retardo
Estadsticas Locales
IP
Trfico Recibido (paquetes/segundo)
Trfico Enviado (paquetes/segundo)
Interfaz IP
Utilizacin de la cola (paquetes)
Probabilidad de descarte (en %)
Referencia (paquetes)
Estadsticas de Enlace
Utilizacin del enlace
Para el Router1 atenderemos sobre todos al atributo:
Atributo
Valor
1000 bits por segundo
Con toda esta informacin, realizaremos una simulacin de 4000 segundos.

En primer lugar, veremos las grficas de ocupacin de la cola a lo largo de la simulacin de
los 4 algoritmos de control de congestin utilizados.
Mientras que PID y MPC intentan seguir el valor de la referencia fijada, RED usa sus
estimaciones probabilsticas para realizar el descarte de paquetes. Por otra parte, Drop Tail
funciona de forma muy simple, mientras siga habiendo espacio en la cola, los paquetes seguirn
siendo encolados (Figura 7. 19).
Observamos como Drop Tail llega a superar los 200 paquetes en cola, los mximos de RED
rondan los 150 paquetes y los 50 de mnimo, correspondindose con los umbrales con los que se
configuro, por ltimo, PID y MPC siguen la trayectoria de referencia establecida en 100 paquetes
(PID de manera ms regular).
Algoritmo
Drop Tail
RED
PID
MPC
112
Color
Figura 7. 19 Salida obtenida para los cuatro algoritmos de control de la congestin

Nos fijaremos a continuacin en los valores de la variable de entrada de los algoritmos PID y MPC
(Figura 7. 20). Mientras que en el PID las variaciones probabilidad son muy bruscas (dejando un
grfico poco, o nada, descriptivo), en el MPC se suceden de manera ms suave. En el caso de
actuadores lgicos, como el que nos atae, no es algo demasiado importante, sin embargo, con
actuadores fsicos, ante cambios bruscos en la seal de control, podemos terminar rompiendo la
maquinaria (vlvulas, llaves, bombas ).
Figura 7. 20 Entrada obtenida para PID (grfico superior) y MPC (grfico inferior)
113
Veamos que es lo que pasa con el nmero de paquetes descartados.
Figura 7. 21 Media de paquetes descartados por segundo

En la Figura 7. 21 se ve como el nmero de paquetes descartados para Drop Tail es siempre cero.
Estamos en un caso en el que la cola nunca llegar a llenarse, y, por lo tanto, usando este mtodo,
nunca ser necesario realizar un descarte de datagramas IP. MPC y PID, en su afn de alcanzar una
referencia, descartan paquetes para lograr tal propsito. De la misma forma, RED, para mantenerse
entre los umbrales definidos, tiene que recurrir al descarte de paquetes.
Fijmonos ahora en la estadstica que nos proporciona TCP relacionada con el reenvo de
informacin (Figura 7. 22). Estos resultados son realmente importantes, a pesar de que Drop Tail y
RED eran los algoritmos que menos descartes provocaban, son los que ms reenvos, a nivel de
transporte, necesitan. Esto es debido a que cuando los paquetes llegan al servidor destino, muchos
de ellos han finalizado su RTO y, a pesar de recibirse, ya no son vlidos porque fue solicitado el
reenvo de los mismos. Como MPC y PID descartan paquetes antes de tiempo evitan, en parte,
este problema. Como ya se habl en el captulo 3, una cola de mayor tamao no es indicio de
obtencin de mejores resultados.
En la siguiente tabla se muestran los valores de RTO con los que estn configurados los
equipos clientes.
Atributo
RTO Inicial
RTO Mnimo
RTO Mximo
114
Valor
3 segundos
1 segundo
64 segundos
Figura 7. 22 Retransmisiones a nivel de transporte
7.3.2 Simulaciones en un periodo de tiempo ms corto

Hasta ahora, todas las simulaciones realizadas tenan una elevada duracin, desde una hora hasta
varios das. En este apartado, realizando varias modificaciones en la topologa de forma que se
adapte ms al modelo utilizado por el MPC realizaremos experimentos situados en un intervalo
menor de tiempo.
En primer lugar definiremos la nueva topologa utilizada. A grandes rasgos, como se puede
observar en la figura 7. 23, la red cuenta con 40 estaciones de trabajo generando trfico sobre el
Router 1 por enlaces de alta capacidad. El Router 1 encaminar trfico hacia el Router 2 y este lo
mandar hacia el servidor FTP al que estn conectadas las estaciones de trabajo.
El nodo de aplicaciones tendr las siguientes caractersticas:
Atributo
Tipo de aplicacin
Valor
FTP
1 seg.
500000 bytes
Queremos originar un cuello de botella por excesivo trfico, de ah que tengamos la frecuencia de
las peticiones a un valor tan bajo.
115
Figura 7. 23 Nueva topologa de estudio

El perfil de comportamiento que tendrn las estaciones de trabajo queda definido en la tabla
siguiente:
Atributo
Duracin
Repeticiones de ejecucin de aplicacin
Tiempo de espera para que comience otra
repeticin de ejecucin de aplicacin.
Patrn de repeticin
Repeticiones del perfil
Tiempo entre repeticiones del perfil
Inicio de sesin
Cierre de sesin
116
Valor
Sin umbral
Hasta que acabe la simulacin
Ilimitadas
1 segundo
Serie
1
0 segundos
Inmediato
Fin de la simulacin
Para el caso del nodo QoS tendremos los siguientes parmetros:

En el caso del MPC:
Atributo
Polinomio A(z-1)
Polinomio B(z-1)
Retardo
Referencia
Periodo de muestreo
Valor
600 paquetes
1-1,476 z-1+0.5416 z-2
-14,9-12,15 z-1
3
3
100
100 p (100 seg) 50 p (100 seg) 200 p (100 seg)
0,2 segundos
Para el PID:
Atributo
Kp
Ki
Kd
Periodo de muestreo
Referencia
Valor
600
1
0,2
0,2 segundos
100 p (100 seg) 50 p (100 seg) 200 p (100 seg)
De la configuracin del Router 1, dnde se generar el cuello de botella, nos interesa el valor del
ancho de banda.
Atributo
Valor
3.500 bps (absoluto)
Si lanzamos una simulacin de 300 segundos, obtenemos el siguiente resultado. Con esta red, con
ambos algoritmos PID y MPC conseguimos que en cuestin de segundos la referencia sea
alcanzada.
Figura 7. 24 Salida del sistema
117
Los valores de la entrada se pueden ver en las Figura 7. 25. Se aprecian bastante mejor las
variaciones de la probabilidad de descarte que en las simulaciones de larga duracin de apartados
anteriores.
Figura 7. 25 Entrada del sistema

En los momentos en los que hay cambios de referencia, se puede apreciar como el MPC, el de la
grfica superior, empieza actuar con anterioridad al PID.
7.3.3 Estudio del retardo y la ocupacin del canal

A continuacin realizaremos un estudio de los parmetros de retardo de TCP, de manera global, y la
ocupacin del canal que une los dos routers. Hasta ahora, el enlace utilizado para unir los dos
routers era 1000BaseX, ste era de tipo duplex y operaba a una velocidad de 1Gbps. Para forzar
una ocupacin mxima del enlace ste ser sustituido por un cable de tipo PPP_56K, mucho ms
lento que el anterior. Las caractersticas de la interfaz ahora sern:
Atributo
Tamao del buffer
Tipo de reserva de ancho de banda
Valor
1MByte
Relativa
100% de la capacidad del enlace
A continuacin, basndonos en el experimento del apartado anterior. Realizaremos una comparativa

de los cuatro mtodos de control de la congestin.
118
Figura 7. 26 Ocupacin de la cola para las diferentes tcnicas de control de la congestin

En la figura 7.26 podemos ver la ocupacin del buffer. En la siguiente tabla mostramos la leyenda
de los distintos algoritmos.
Algoritmo
Drop Tail
RED
PID
MPC
Referencia (algoritmos de control)
Color
Vemos como los algoritmos de control intentan seguir la trayectoria de referencia. MPC no
consigue adaptarse muy bien al primer valor de 100 paquetes, sin embargo, el resto de la
simulacin responde muy bien ante los cambios. PID tampoco responde de forma perfecta, pero
funciona bastante bien en intervalos de tiempo tan cortos. En cuanto a RED, ha sido fijado con
unos umbrales mnimo y mximo de 60 y 180 paquetes respectivamente. Por ltimo, Drop Tail va
llenando la cola siguiendo una trayectoria exponencial hasta alcanzar un valor de unos 450
paquetes al finalizar la simulacin (bastante coherente si vemos la definicin de generacin de
trfico en el nodo de aplicaciones).
En una red es siempre interesante mantener una ocupacin de los enlaces alta, esto es un
indicio de un uso eficiente de los recursos disponibles. En la Figura 7.27 podemos observar la
ocupacin (en media) del enlace que une los dos routers. Resulta agradable ver como los dos
algoritmos implementados, PID y MPC, obtienen mejores resultados que los ya existentes. En este
caso concreto PID ofrece un porcentaje algo ms alto de ocupacin que MPC. An as, los cuatro
mtodos logran unos valores cercanos al 100%, no existe ningn caso que podamos considerar
desastroso.
119
Figura 7. 27 Ocupacin del enlace
Figura 7. 28 Retardo de los paquetes en las capas TCP (en segundos)

Otro estudio interesante es el del retardo de los paquetes recibidos por las capas TCP en toda la red,
para todas las conexiones. Esta es una medida del tiempo que tarda un paquete enviado de una
fuente TCP en ser recibido al completo (todos sus fragmentos) por parte de la capa TCP del nodo
destino. En la Figura 7. 28 podemos ver los resultados obtenidos y, por lo visto, nuestros algoritmos
de control son los que menores retardos ocasionan en la recepcin de paquetes. Esto est muy
120
ligado al nmero de reenvos y a la finalizacin de temporizadores de la que se ha hablado

anteriormente.
7. 4 Conclusiones
Se ha intentado con esta coleccin de experimentos intentar demostrar al lector como, mediante un
control dinmico de las colas, es posible obtener un mejor desempeo de una red congestionada.
Del mismo modo, se ha intentado poner de manifiesto que una mayor tasa de descarte de paquetes
no implica un funcionamiento ms deficiente, todo lo contrario, descartando paquetes antes de
tiempo, muchas veces, nos ayuda a descongestionar la red.
121
Captulo VIII
Pruebas y problemas
8. 1 Pruebas
El anterior captulo de resultados se puede considerar una amplia batera de pruebas para observar
el correcto funcionamiento de los algoritmos implementados. En el actual captulo veremos la
forma de proceder para realizar las pruebas en el cdigo generado y poner de manifiesto diferentes
errores cometidos. Podemos clasificar las pruebas en dos grupos:
Pruebas unitarias: Cada mdulo de la aplicacin se comprueba por separado.

Pruebas de integracin: Comprueban que al juntar varios mdulos que funcionan
correctamente de forma separada, lo siguen haciendo bien cuando trabajan de forma
conjunta.
8.1.1 Pruebas unitarias

Se han realizado varias pruebas unitarias en la funcin que configura el control predictivo, sta es:
void inicializarControlPredictivo(double *a, double *b, int h, int h1, int
h2, double *Ks, double **Fs, double **Gp, int na, int nb, double lambda);
Se hicieron pruebas del estilo a la siguiente, en la que tenemos como parmetros de entrada los
siguientes valores:
a = [1 -1.476 0.5416]
b = [-14.9 -12.15]
h = 3
h1= 4
h2 = 6
na = 3
nb = 2
lambda = 100
Las matrices resultados que se obtienen se pueden ver a continuacin:
123
Fs = [7.229525
8.567545
9.730186
-9.332758 3.103233
-11.483056 3.915511
-13.370369 4.640183]
Gp = [-12.150000
-30.083400
-49.972658]
Ks: [-0.013471
-0.017594
0.001685]
Tras varios accesos invlidos a memoria y modificaciones en el cdigo, el mdulo pasaba las
pruebas unitarias.
Dentro de la configuracin de los datos del MPC, hay una llamada a cdigo de terceros para
calcular la inversa de una matriz (MatrixInversion). Debemos tener cuidado al introducir cdigo de
terceros y asegurarnos de que las funciones que introducimos han sido probadas minuciosamente
de manera que aseguren un correcto funcionamiento. Se ha probado el correcto clculo de la
inversa de la matriz desde la herramienta online accesible en [Blu].
8.1.2 Pruebas de integracin

A nivel general, para probar el funcionamiento de todo el cdigo implementado, se realizaron
varias simulaciones configuradas con valores propensos a devolver resultados incorrectos, por
ejemplo, si configuramos una simulacin del MPC con todos sus parmetros nulos obtenemos la
siguiente salida en la consola de OPNET.
<<< Program Abort >>>
Vos_Define_Object requested to define object of 0 bytes.
Request failed.
T (0), EV (2), MOD (top.Office Network.QoS.attribute_definer)
Esta salida no es considerada un error de implementacin porque se entiende que para que el
usuario inicie una simulacin, ste debe de haber introducido primero los parmetros de
configuracin necesarios para el correcto funcionamiento del algoritmo.
Lo mismo sucede en el caso del PID.
8. 2 Depurar cdigo en OPNET

He querido aadir aqu este apartado, porque de cara a probar el cdigo de los algoritmos, sin duda,
el debugger de OPNET, ha sido una herramienta de gran utilidad para ver dnde se producan las
excepciones en la ejecucin del cdigo.
Existen varias herramientas en Windows que nos permite depurar cdigo. Una de ellas es el
CDB (Console Debugger) que, integrado con OPNET, nos permitir depurar el cdigo en tiempo
de ejecucin cuando estn corriendo las simulaciones. Instalarlo y enlazarlo con OPNET no es
muy complicado.
1.
2.
En primer lugar descargamos de la pgina de Microsoft el paquete con las herramientas

de depuracin (debugging tools).
A continuacin lo instalamos en nuestro equipo. La ruta donde se realice la instalacin se
le debe indicar a OPNET para que sepa desde donde lo puede ejecutar.
124
VIII. PRUEBAS Y PROBLEMAS
3.
4.
5.
Desde la pantalla principal de OPNET, dentro del men EditPreferences debemos

configurar el atributo Show Console View a true.
A continuacin activamos el ODB (Opnet Debugger) desde el men
DESConfigure/Run DES, opcin ExecutionOpnet Debugger y marcando la opcin
Use Opnet Simulation Debugger (ODB).
Desde la pantalla Simulation Execution accedemos al men Simulation Attach
Windows Debugger (CDB). Una ventana similar a la de la Figura 8. 1 aparecer.
Figura 8. 1 CDB en OPNET

Podemos establecer los puntos de ruptura (breakpoints) en el cdigo de dos formas:
Mediante lnea de comandos utilizando el comando bp seguido del nombre del mtodo
dnde queremos situar el punto de ruptura. Por ejemplo, bp controller.
Desde la ventana donde est el cdigo, situndonos en la lnea deseada y seleccionando
con el botn derecho del ratn la opcin Set breakpoint.
Para movernos por las distintas instrucciones de cdigo tenemos tres botones:
Continue: Avanza hasta el siguiente breakpoint.

Source Step: Ejecuta lneas de cdigo de forma anidada, es decir, si encuentra alguna
funcin entra dentro de su cdigo.
Source Next: Ejecuta la siguiente lnea de cdigo sin entrar dentro de las funciones.
8. 3 Problemas
Durante el ciclo de vida del proyecto nos hemos topado varias veces con contratiempos que han
dificultado el trabajo llevado a cabo. Como de los errores se aprende, me ha parecido conveniente
aadir una pequea lista, a modo de resumen, con los problemas que han ido a surgiendo, por
diferentes motivos, a medida que el proyecto avanzava.
OPNET es una herramienta muy potente, sin embargo por desgracia la

documentacin y referencias a la misma existentes es bastante limitada. Googleando no se
encuentra demasiado y generalmente lo que hay son pequeos tutoriales en los que se
ensea la herramienta a muy alto nivel, diseo de topologas y configuraciones de
125
126
simulaciones sencillas. La mayor parte de la documentacin se encuentra dentro de

[OPT09], es decir, la ayuda de la propia herramienta.
Mencin a parte merecen las licencias de la herramienta. stas se obtienen por un tiempo
limitado, y se otorgan de manera gratuita si la utilizacin de la herramienta va a estar
relacionada con el mbito de la investigacin, sin propsito de lucro. Resulta molesto el
estar atado a un equipo para usar el programa, si se quiere utilizar en una mquina
diferente es necesario realizar una liberacin de la licencia y una nueva obtencin, una
labor bastante tediosa. Por si esto fuera poco comentar una lamentable experiencia que
tuve. Si se desea formatear el equipo sobre el que corre actualmente OPNET, recordad
que antes es necesario dejar libre la licencia, desconociendo esta peculiaridad perd uno de
mis acuerdos y fue necesario realizar una nueva solicitud (con el consiguiente tiempo
perdido derivado de ello).
Tambin relacionado con OPNET, es curioso que la herramienta te cree una carpeta
OPNET_license, con informacin de la licencia, en la raz de diferentes discos que puedas
tener en el equipo. Esto no trae ms que posibles incoherencias entre licencias disponibles
y caducadas y crea incertidumbre en el usuario.
El aprendizaje y adaptacin a un nuevo lenguaje como C y derivados (C++, Proto-C)
tampoco fue sencillo. No estoy muy acostumbrado a desarrollar software en lenguajes en
los que necesito gestionar la memoria de forma explcita, acostumbrarme a ello ha sido
tarea dura a la par que instructiva.
Captulo IX
Conclusiones y trabajo futuro
9. 1 Conclusiones
Llegados hasta aqu, merece la pena echar la mirada atrs y sacar conclusiones sobre el trabajo
realizado. El poder reflexionar sobre lo aprendido nos har solidificar los conocimientos y nos
permitir ser crticos con la labor desempeada. A continuacin se enumerarn varios puntos a
modo de corolario del proyecto.
En primer lugar, diremos que el control de la congestin no es una tarea ni mucho menos
trivial. Est condicionada por multitud de variables, lo que hace realmente complicado su
estudio.
El manejo de herramientas de simulacin profesionales, como OPNET tampoco es algo
sencillo. Su aprendizaje requiere de bastante tiempo y familiarizarse con la herramienta no
es inmediato.
El uso de tcnicas de control automtico para controlar la congestin es realmente curioso.
Antes de comenzar con el desarrollo de este proyecto todas los procesos de control que
haba visto estaban relacionados con procesos de ndole industrial (tanques de lquido,
calentadores, columnas de destilacin, antenas de seguimiento). Aplicar control sobre
las redes es algo, cuanto menos, innovador e interesante.
Tengo la sensacin de no haber hecho ms que vislumbrar por encima las posibilidades y mejoras
que pueden ofrecer este tipo de controladores para una regulacin ptima de la carga en la red.
Por otra parte, resulta gratificante el haber adquirido una importante cantidad de
conocimientos y destrezas durante la realizacin del proyecto. Me gustara enumerar unos cuantos:
Se ha aprendido a utilizar una herramienta compleja de simulacin discreta como

OPNET. A parte, se ha logrado el ms difcil todava y se ha conseguido entender y
modificar su cdigo interno para aadirla nuevas funcionalidades de usuario.
He profundizado sobre conceptos de redes aprendidos durante la carrera y he adquirido
una visin ms ntida del protocolo TCP/IP.
He conseguido comprender el problema de la congestin hasta el punto de poder
implementar nuevas tcnicas para tal propsito.
He podido escribir cdigo en un lenguaje de programacin desconocido por m hasta el
momento, C++ [CA04].
127
9. 2 Trabajo futuro
Muchas cosas se pueden seguir haciendo llegados a este punto. A continuacin enumerar las ms
importantes de cara a que, en un futuro, alguien o yo mismo pueda seguir investigando y
estudiando sobre el tema.
1.
2.
3.
4.
5.
6.
Los controladores implementados funcionan en base a una seal de reloj que se genera
con cierta frecuencia. Estara muy bien comprobar el desempeo de los algoritmos tanto
RED como MPC localizando el clculo de la seal de control cuando llega un nuevo
paquete sin necesidad de utilizar la seal de reloj.
El controlador MPC creado no tiene en cuenta restricciones. En un primer momento se
consider su implementacin, pero finalmente, por falta de tiempo, no se lleg a realizar.
Tambin relacionado con el MPC, se podra mirar la posibilidad de realizar variaciones del
modelo dinmicamente, a medida que avanza la simulacin, eso le hara ms flexible y
adaptable a las condiciones cambiantes de la red.
Hacer hincapi en las labores de modelado y obtener modelos de red para el MPC ms
realistas que los usados en los casos de estudio, de manera que se mejore la eficiencia de
este mtodo de control automtico.
La cantidad de parmetros configurables en una red nos abre un abanico inmenso de
nuevos estudios. Jugando con los distintos parmetros de los distintos protocolos podemos
realizar nuevos experimentos a distintos niveles de red.
Estudio de nuevas topologas. El actual trabajo se ha limitado a redes Ethernet cableadas.
Sera interesante el estudio de redes de distinta naturaleza, por ejemplo redes inalmbricas.
128
Apndice A
La herramienta OPNET
A. 1 Introduccin
OPNET Modeler es un programa extensamente utilizado en la industria para modelar y simular
sistemas de comunicaciones. Su nombre se identifica con las siglas de OPtimized Network
Engineering Tool. La empresa que lo distribuye fue fundada en 1986 y se abri mercado en el ao
2000. Este programa posibilita disear y estudiar redes, dispositivos, protocolos y aplicaciones.
Est basado en la teora de redes de colas e integra las libreras para proporcionar el modelado de
las topologas de red. Soporta un amplio rango de tecnologas tipo LAN, MAN y WAN.
Figura A. 1 . Pantalla de inicio de OPNET Modeler 16.0

OPNET Modeler emplea varios niveles de modelado o paradigmas para representar los distintos
componentes de una red. Cada nivel est asociado a un dominio y a un editor. Para facilitar el
desarrollo y que sea ms intuitivo al usuario, los editores se ordenan jerrquicamente, de manera
que los modelos desarrollados en el editor de Proyectos (Project Editor) dependen de elementos
desarrollados en el Editor de Nodos (Node Editor), que utiliza tambin modelos definidos en el
Editor de Procesos (Process Editor). Junto a estos 3 principales editores de OPNET, se encuentran
tambin otros complementarios como Link Model Editor (para crear, editar y ver modelos de link),
Packet Format Editor (para desarrollar paquetes con un formato determinado) o Probe Editor
(para la configuracin de estadsticas que se quieren obtener durante una simulacin), estos tres
ltimos no se han usado durante el desarrollo del proyecto.
129
Figura A. 2 Diferentes niveles de modelado en OPNET

Para describir un sistema, existen dos conceptos fundamentales: objetos y procedimientos. Los
objetos van a representar la estructura del sistema y los procedimientos su comportamiento, ambos
conceptos trabajan de forma simultnea.
Los objetos van a describir de forma natural la estructura de las redes de comunicaciones.
Adems de capturar las caractersticas fsicas de los componentes del sistema, los objetos pueden
utilizarse para representar su descomposicin e interconexin interna. Algunos ejemplos de objetos
fsicos de las redes que se han utilizado en este proyecto han sido: router, switch, servidor, cliente
y links, que son al final, los componentes que forman las redes, y a los que se puede acceder a
travs de la paleta de objetos del Project Editor. Tambin existen objetos abstractos como
procesos, o contadores, sin embargo, son dinmicos y no forman parte de la estructura del sistema.
En OPNET, los trminos objeto y modelo estn muy ligados. Cuando se crea en la red un
objeto, en definitiva, se crea una instancia del modelo que define a ese objeto, con lo que podemos
decir que ese modelo es una clase. Esto se debe a que OPNET est muy unido a la programacin
orientada a objetos, ya que as se proporciona una forma centralizada de controlar un gran nmero
de objetos: hacer cambios en un objeto conlleva que todos los objetos creados a partir de l
incorporarn ese cambio.
Un modelo incluye la informacin comn a todas sus instancias. Esto incorpora
especificaciones de interfaz de los objetos, comportamiento y estructura interna. La interfaz
describe cmo un objeto interacta con su entorno, incluyendo especificaciones relacionadas con
interconexiones fsicas y mecanismos de comunicacin con otros objetos.
Los modelos, adems de las interfaces de los objetos, describen su comportamiento. Esto es,
cmo reaccionan a estmulos externos y cmo actan. Un ejemplo es un cliente, que siendo un
objeto, actuar en algn momento generando trfico. El comportamiento de un objeto depende de
varias variables como estmulos internos, informacin de estado, tiempo o variables aleatorias.
Esto se implementar en su mayor parte mediante un modelo de procesos.
130
A. LA HERRAMIENTA OPNET
Por ltimo, entre la informacin del modelo se encuentra la estructura interna del objeto. Esto
se representa con la descomposicin del objeto en otros componentes, que a su vez pueden ser
objetos con su propio modelo. Como ejemplo podemos sealar los modelos de nodos, que estn
especificados en trminos de objetos denominados mdulos y conexiones. Un ejemplo de modelo
de nodos sera el que define el comportamiento de un router, dentro del cual se encuentra el
mdulo IP.
Quedan por explicar los atributos. Al representar un objeto, hay caractersticas de ste que se
consideran privadas y, por tanto, permanecen escondidas en su interior. Sin embargo, hay otras que
se consideran tiles para mostrar al usuario. Estas ltimas son las llamadas atributos. Estos pueden
estar asociados con clases de objetos, o con un objeto particular. Normalmente tienen dos
objetivos: informar al usuario de las caractersticas seleccionadas de un objeto y permitir que esas
caractersticas se puedan modificar por el usuario para una aplicacin ms especfica, en POO
seran los valores de los atributos con los que se instancia el objeto.
A. 2 Dominio de Red (Network Domain)

El Dominio de Red tiene como objetivo definir la topologa de una red de comunicaciones. Las
entidades de comunicacin se llaman nodos y las capacidades de cada nodo estn definidas
mediante su modelo de nodos asociado. stos se desarrollan utilizando el editor de nodos. En un
modelo de red, pueden encontrarse varios nodos basados en el mismo modelo de nodos.
Una topologa puede contener tantos nodos y modelos de nodos como el usuario considere
oportuno. De esta forma, los usuarios pueden desarrollar su propia librera de modelos de nodo,
adaptndola a cada funcionalidad.
El editor de proyectos (Project Editor) aporta un contexto geogrfico para el desarrollo de un
modelo de red. Es posible seleccionar localizaciones en un mapa mundial o de un pas para redes
de rea extensa o WANs, y reas dimensionadas para redes de rea local o LANs, lo que permite
ayudar a crear un entorno intuitivo a la hora de modelar y, adems aadir a la red una nocin de
distancia, til para calcular retardos de comunicacin entre nodos.
Los nodos por lo general necesitan comunicarse con otros para poder cumplir su funcin
dentro de la red. Los tipos de links que cumplen esta tarea son variados: simplex (unidireccional) y
dplex (bidireccional) para conectar una pareja de nodos, y bus link para emisin de datos a un
conjunto de nodos. Cada tipo de link puede ser adaptado a las necesidades del usuario editando sus
atributos o con el editor de links.
Para restar complejidad a los modelos de red, se utilizan subredes para crear una topologa.
Una subred es una agrupacin de dispositivos que forman una red en s misma, y pertenece a una
red principal. Las subredes pueden estar conectadas por diferentes tipos de links, dependiendo del
tipo de subred. Es posible anidar unas subredes dentro de otras, estableciendo una jerarqua en la
que el nivel ms bajo est compuesto simplemente por nodos y links.
En [SP03] encontramos varios ejemplos para familiarizarnos con la herramienta a este nivel.
A. 3 Dominio de Nodos (Node Domain)

El dominio de nodos proporciona el comportamiento de los dispositivos de comunicacin o nodos
que se usan e interconectan en un modelo de redes. La estructura interna de los nodos que forman
los modelos de redes (Network Models), en OPNET no es visible a nivel de red (o lo que es lo
mismo, desde el Project Editor).
Un modelo de nodos se compone de una serie de bloques conectados denominados mdulos.
Cada uno de ellos comprende un conjunto de entradas y salidas, memoria de estado y un mtodo
para obtener las salidas a partir de las entradas y la informacin en la memoria. El procesamiento
va a depender del tipo de mdulo ya que algunos tienen un comportamiento predefinido con un
objetivo establecido, mientras que otros pueden ser definidos por el usuario.
Mediante unos objetos denominados conexiones (connections), se unen las entradas y salidas
de los diferentes mdulos en un modelo de nodos. Existen dos tipos de conexiones: una para
131
transportar paquetes de datos y otra para transmitir valores individuales. Un mdulo puede enviar
paquetes a travs de sus output packet streams (canales de salida de paquetes) y recibirlos de sus
input packet streams. Por otra parte, puede enviar valores individuales a travs de output statistics
y recibirlos de input statistics. Podemos hablar tambin de las asociaciones lgicas entre mdulos,
pero a nivel de modelado no tienen inters, salvo para simplificar la comprensin del modelo de
nodos.
A.3.1 Mdulos
Los mdulos representan aquellas partes del modelo en que se genera, consume o procesan datos.
Existen diferentes tipos de mdulos dependiendo de su funcin dentro de un nodo tales como:
procesadores (processors), colas (queues), receptores (receivers) y transmisores (transmitters).
Algunos de stos, como los procesadores y colas, tienen funciones estrictamente internas del nodo,
sin embargo, otros como los receptores y transmisores tienen conexiones externas con los links de
transmisin del dominio de redes. El comportamiento de los procesadores y colas viene dado por
modelos de procesos que puede modificar el usuario, como ocurre con el mdulo IP, definido
mediante el modelo de procesos ip_dispatch y sus hijos. Sin embargo, otros mdulos tiene un
comportamiento ya predefinido, slo modificable cambiando el valor de sus atributos.
El algoritmo interno de un mdulo se invoca cuando se produce un evento externo que afecta
al estado de ese mdulo. Esto se debe al mtodo de simulacin por eventos que utiliza OPNET.
A continuacin se explican los mdulos que se han considerado relevantes en el proyecto:
A.3.1.1 Procesador
Figura A. 3 Icono de un procesador en el editor de nodos

Este mdulo es uno de los ms importantes. Es habitual utilizarlo para procesamiento general de
paquetes. Su comportamiento viene dado por su atributo process model que especifica el modelo
de proceso que va a ser ejecutado en el mdulo. ste puede responder a eventos externos o
interrupciones segn el comportamiento que est implementado. Es posible conectar los
procesadores a otros mdulos para intercambiar paquetes a travs de packet streams.
Dentro de un modelo de nodos, se puede usar tambin un procesador como controlador.
Siendo as, se comunicar con otros mdulos a travs de cables estadsticos o interrupciones
remotas.
Un procesador, como todos los objetos, tiene atributos para configurar su comportamiento, y
pueden ser especificados usando la interfaz grfica del editor de nodos. Sin embargo, cuando se
selecciona un modelo de procesos, los atributos pueden cambiar. Esto va a depender de los
atributos declarados en el modelo de proceso asociado y en sus interfaces. Los atributos de un
modelo de proceso permiten aadir nuevos atributos, que automticamente sern heredados por el
mdulo procesador.
132
A.3.1.2 Cola
Figura A. 4 Icono de una cola en el editor de nodos

Un mdulo cola, como los mdulos procesador, permite ejecutar un modelo de proceso que
describe el comportamiento de un determinado protocolo, y puede estar conectado a otros mdulos
a travs de packet streams, posibilitando enviar y recibir paquetes. El modelo de proceso tambin
afectar en este caso a la lista de atributos que posea el mdulo.
La diferencia que ms destaca entre un procesador y una cola es que las colas contienen
recursos internos adicionales denominados subcolas (subqueues). Las subcolas facilitan las tareas
de almacenamiento y de gestin de la coleccin de paquetes guardada en ellas. De esta forma, se
ofrece al usuario una forma ms sencilla para implementar disciplinas de cola.
Cada cola contiene un nmero definido de subcolas subordinadas a ella, con sus propios
atributos. Como se puede controlar el comportamiento del mdulo mediante un modelo de
proceso, es posible modelar cualquier tipo de protocolo de cola definiendo la manera en que se
accede y controlan las subcolas.
A.3.1.3 Transmisor
Figura A. 5 Iconos de transmisores punto a punto y bus en el editor de nodos

Los mdulos transmisores actan de interfaz de salida del modelo de nodos con el modelo de red
al que el nodo pertenece. Existen dos tipos de nodos, correspondientes a los dos tipos de links de
comunicacin, que son punto a punto y bus, y se diferencian en sus mecanismos de comunicacin.
En un modelo de nodo, los transmisores son considerados sumideros de datos. Desde el punto
de vista del modelo de red, estos mdulos actan como puertos de salida del nodo a los que
conectar los links. El papel de estos mdulos en una red est representado en la siguiente
ilustracin:
133
Figura A. 6 Conexin de nodos a travs de transmisores
A.3.1.4 Receptor
Figura A. 7 Iconos de receptores punto a punto y bus en el editor de nodos

Un mdulo receptor se utiliza como interfaz entre los links externos al nodo y los packet streams
dentro del nodo. Existen dos tipos de mdulos receptores: punto a punto y bus, al igual que en los
transmisores.
Los receptores pueden distribuir los paquetes entre uno o varios output packet streams despus
de obtenerlos del link.
En un modelo de nodos, los receptores son considerados fuentes de trfico, y desde el punto
de vista de la red, un puerto de entrada al nodo.
A.3.2 Conexiones
Las conexiones representan los caminos y asociaciones entre los distintos mdulos de un nodo. En
un modelo de nodos existen tres tipos de conexiones diferentes:
A.3.2.1 Packet Streams
Su misin es transportar los paquetes desde un mdulo destino a uno fuente. Representan el flujo
de datos a travs de las interfaces hardware y software dentro de un nodo de comunicaciones. Se
caracterizan por no tener errores de transmisin, retrasos, ni lmite de ancho de banda. Tienen
capacidad ilimitada para almacenar los paquetes en orden de llegada al mdulo destino.
En OPNET se puede transferir un paquete a travs de un stream y notificar al mdulo de su
llegada, a travs de tres mtodos: planificado, forzado y silencioso. Mediante la versin
planificada, llega una interrupcin de canal o stream interrupt, y se requiere de un tiempo de espera
hasta que llegue el turno de recoger el paquete. Sin embargo, con la forzada, cuando ocurre la
interrupcin, el paquete es procesado de inmediato, sin ejecutar los eventos anteriores. Por ltimo,
con el mtodo silencioso, no hay interrupcin, y el paquete se almacena en el buffer hasta que el
mdulo lo solicite.
A.3.2.2 Statistic Wires
Su funcin es transportar datos desde un mdulo fuente hasta un mdulo destino. Cada Statistic
Wire transporta un valor individual. Se utilizan habitualmente como interfaces en las que el
mdulo fuente comparte ciertos valores con el destino, incluida informacin de estado. Adems,
son utilizados como mecanismos de sealizacin, permitiendo que el mdulo origen informe al
destino cuando una condicin de inters se ha cumplido.
Cada mdulo dentro de un nodo tiene un conjunto de local output statistic cuyos valores son
actualizados durante la simulacin. Este conjunto de estadsticas es el que acta como fuente de los
statistic wire. Los procesadores y colas, en concreto, tienen estadsticas cuya manipulacin e
interpretacin est definida por el modelo de proceso, y cuya actualizacin tiene lugar cuando
dentro de ste se llama a un procedimiento predefinido en OPNET, opt_stat_write(). Sin embargo,
otros mdulos tienen unas estadsticas predeterminadas que son actualizadas automticamente por
el Simulation Kernel cuando es conveniente.
Los statistic wires se utilizan habitualmente de dos maneras: en primer lugar, pueden ser
empleadas para monitorizar el estado de algn otro componente dentro de un nodo. En segundo
134
lugar, posibilitan que un mdulo avise a otro (procesador o cola) para que cambie de estado,
enviando valores que comprueba el proceso asociado.
A.3.2.3 Logical Associations
Son conexiones especiales que no transportan datos, ni existen durante la simulacin.
Sencillamente, se utilizan como mecanismos de especificacin, es decir, indican que hay relacin
entre dos mdulos de un nodo. Asimismo, se consideran de ayuda para interpretar la estructura de
un modelo de nodo.
A.3.3 Atributos
Es posible crear nuevos atributos y asociarlos a un modelo de nodos. stos pertenecern al modelo
en general, y no a un objeto en particular del dominio de nodos. Al crear un objeto nodo en un
Project Editor heredar esos atributos. Por ello se dice que los atributos del modelo de nodos
proporcionan una forma de aumentar el conjunto de atributos de un nodo u objeto de la red.
Si se hacen pblicas algunas caractersticas del modelo de nodos, y se permite que se
modifiquen, es ms sencillo que los modelos sean ms aptos para la reutilizacin en diferentes
situaciones de modelado. Igualmente ocurre con los atributos de los modelos de proceso, que
permiten que se introduzcan nuevos atributos en los mdulos del modelo de nodos. Por ello,
dependiendo del mbito de utilizacin de los atributos, se declaran en el modelo de procesos, en el
caso de que se vayan a necesitar a nivel de implementacin de nodos, o en el de nodos, si interesa
que sean visibles en el dominio de red.
A. 4 Dominio de procesos
Como se ha explicado en el apartado anterior, los modelos de proceso se utilizan para definir el
comportamiento de los mdulos de tipo procesador y cola existentes en el Dominio de Nodos.
Implementan una gran variedad de subsistemas tanto hardware como software, incluyendo
protocolos de comunicacin, algoritmos, recursos compartidos como discos o memoria, disciplinas
de cola, y en general todo tipo de comportamiento que se pueda necesitar en un modelo de redes
de comunicacin.
A partir de este punto, se llamar a los procesadores o colas con las abreviaturas QP, para
facilitar la lectura. Para proporcionar una funcionalidad particular dentro de un QP, se pueden
definir uno o varios procesos. Un proceso es una instancia de un modelo de proceso, definido
mediante el Editor de Procesos.
A.4.1 Entorno de un Proceso

En este punto describiremos el contexto en el que trabajan los procesos en OPNET:
A.4.1.1 Ejecucin basada en interrupciones
Los procesos, como todos los elementos en OPNET, trabajan en base a eventos. Si un evento
afecta a un proceso, lo hace en forma de interrupcin. Una de las primeras acciones que realiza un
proceso al recibir una interrupcin es determinar su tipo.
Cuando empieza la ejecucin de un proceso, ste siempre est en modo de reposo o
bloqueado, esperando a ser invocado. Por consiguiente, una invocacin permitir al proceso
reanudar su ejecucin y hacer nuevas tareas. Una vez finalizado, el proceso se vuelve a bloquear,
devolviendo el control a Simulation Kernel para que otros procesos puedan ser ejecutados.
El tiempo de simulacin al principio y al final de una invocacin no vara, es decir, una
invocacin no consume tiempo.
135
A.4.1.2 Procesos Dinmicos

Al comenzar la simulacin, cada QP aloja slo un proceso, automticamente creado por Simulation
Kernel. Este proceso es una instancia del modelo de proceso designado en el atributo process
model del QP correspondiente. Este proceso, denominado proceso raz, puede crear durante la
simulacin otros procesos que cooperan para hacer la tarea designada. Los procesos que son
creados por otros procesos se les denominan procesos dinmicos.
Jerarqua de procesos
Debido a la metodologa de creacin de procesos dentro de un QP, se puede establecer una
jerarqua en la que el proceso raz acta como padre, siendo los procesos que crea ste los hijos. A
su vez, stos podran crear otros y as sucesivamente, dando lugar a una estructura de rbol, donde
tenemos un ejemplo en la siguiente figura. No hay lmite en el nmero de generaciones.
Figura A. 8 Jerarqua de procesos

Adems de crear procesos, es posible borrar, y por tanto, la jerarqua de procesos durante un QP
vara dinmicamente durante la simulacin. La excepcin se encuentra en el proceso padre que no
se puede borrar, y ser el responsable de transferir las interrupciones al resto de procesos de la
jerarqua.
Un detalle que nos llama la atencin del dominio de procesos, es que es posible borrar un
proceso padre sin que desaparezcan sus hijos, a excepcin del proceso padre, como se ha
mencionado anteriormente. Tambin podr crear hijos basados en cualquier modelo de proceso,
incluyendo el suyo propio, o el del proceso padre, siempre que los modelos de proceso
correspondientes estn declarados en una lista.
Esa lista forma parte de la implementacin de cada modelo de proceso y debe ser declarada
antes de la simulacin e instanciacin del proceso. Para acceder a la lista, lo haremos desde el
Editor de Procesos, dentro del men File: Declare Child Process Model para permitir nuevos hijos
y Open Child Process Model para acceder a la lista.
136
Memoria Compartida
Cuando dentro de un QP se ejecutan varios procesos para implementar su funcionalidad, stos
requieren comunicarse entre ellos para compartir informacin. Existen tres mecanismos de
comunicacin:
Memoria Compartida a nivel QP (module memory): Los procesos de la jerarqua

comparten la informacin guardndola en un rea comn definida por el QP, en forma de
estructura de datos. Los procesos asignan y obtienen la direccin de esa rea mediante las
operaciones
del
KP
(Kernel
Procedures)
op_pro_modem_install
()
y
op_pro_modem_access (). Para confirmar que todos los procesos utilizan de forma
consistente esa estructura compartida, todos tienen una definicin de ella en su bloque de
cabecera o header block, accesible desde el editor de procesos.
Memoria compartida padre-hijo: Es un rea privada que se crea a la vez que el proceso
hijo con el que se comparte. Pero no todos los procesos tienen acceso a ella (cada uno
tiene su propia memoria con su proceso padre). El Kernel mantiene, por lo tanto, un
bloque de memoria para cada par padre-hijo del sistema.
Figura A. 9 Memoria compartida

Un proceso hijo obtiene la direccin de la memoria que comparte con su padre mediante la
rutina op_pro_parmen_access().
Paso por argumento: Mediante la primitiva op_pro_invoke(), se pasa al otro proceso la

direccin de un bloque de memoria. De esta forma, el proceso invocado, obtiene
parmetros que pueden llegar a afectar a su comportamiento, o modificar la memoria para
devolver su status, al proceso que lo invoc. A diferencia de los dos anteriores, en este tipo
de mecanismos, la memoria no es persistente. Esto es, en cada invocacin, se debe pasar
una direccin de memoria.
Operaciones con procesos dinmicos

Como se mencion anteriormente, un proceso raz puede llegar a crear varios procesos hijos. La
manera de hacerlo es mediante la funcin op_pro_create(). Si esto ocurre, el nuevo proceso se
aade automticamente a la jerarqua del padre. De esta operacin se devuelve un valor, el process
handle, que es el identificador del nuevo proceso dentro de todo el sistema (no slo en la jerarqua).
Este nmero es exclusivo para cada proceso, y se puede acceder a l mediante op_pro_id().
137
Algunos procesos dinmicos poseen un tiempo de vida reducido al tiempo que tardan en
realizar la tarea que se haya encomendado. Al acabar se le elimina de la jerarqua y as no consume
recursos, mediante la funcin op_pro_destroy, que puede ser empleada por otros procesos o por l
mismo.
nicamente puede haber un proceso ejecutndose a la vez. Un proceso est en ejecucin
cuando progresa a travs de las instrucciones que integran su modelo. Si un proceso necesita
invocar a otro creado anteriormente, lo hace mediante la funcin op_pro_invoke(). A partir de esta
llamada el proceso invocado se bloquea, cediendo el control del hilo de ejecucin al proceso
invocado, que realiza su tarea y cuando acaba devuelve el control al proceso que lo llam, que
sigue ejecutndose donde se haba quedado.
Cuando un proceso invoca a otro, se a su vez puede invocar a otro, y as sucesivamente,
actuando como un mecanismo de llamadas orientado a pila, por tanto, no soporta recursividad
(porque los procesos, una vez van invocando a otro, permanecen bloqueados hasta que acaba la
llamada).
S que podra existir, sin embargo, entre distintas instancias de un mismo proceso de modelo,
invocndose una a la otra.
Durante la invocacin, el proceso invocado puede acceder a cualquiera de los recursos del QP,
como paquetes o estadsticas. Esto puede dar lugar a que, despus de una invocacin, ciertos
valores puedan cambiar.
La totalidad de las operaciones citadas para manejar los procesos dinmicos y otras muchas no
sealadas, forman parte del llamado Process Package, uno de los paquetes de operaciones
existentes dentro de los Kernel Procedures o KP. Estas funciones ya estn definidas, y es posible
usarlas directamente en el cdigo de los modelos de proceso, lo que facilita mucho la tarea de
implementacin de nuevos protocolos o aplicaciones dentro de OPNET.
Control de Interrupciones
Una interrupcin nos va a indicar que ha ocurrido un evento de inters en el sistema, como por
ejemplo la expiracin de un temporizador o la llegada de un paquete. Cuando un proceso recibe una
interrupcin, realiza una accin como respuesta y se bloquea, esperando una nueva interrupcin.
Los modelos de proceso utilizan procedimientos predefinidos para obtener la informacin acerca
del tipo y origen de la interrupcin. En la mayora de los casos, las interrupciones tienen
informacin adicional a la que los procesos acceden para concretar qu accin llevar a cabo. Por
ejemplo, una interrupcin ocasionada por la llegada de un paquete tiene como consecuencia que el
proceso tenga que obtener el paquete y procesarlo.
Todas las interrupciones, por defecto, que llegan a un QP son dirigidas al proceso raz, y ste
elige a quin invocar para que realice las operaciones debidas. No obstante, hay procesos que
pueden solicitar recibir ciertos eventos, basndose en el tipo de evento o su procedencia.
A.4.1.3 Recursos de un proceso
Los procesos siempre van a operar dentro del contexto de un QP. Por este motivo, el objeto QP,
proporciona a sus procesos ciertos recursos que implcitamente forman parte del entorno de cada
proceso.
stos son:
Canales de entrada/salida (Input and Output Streams)
Como hemos visto anteriormente, los packet streams, son objetos que existen en el modelo de
nodos y conectan unos mdulos con otros. En concreto, comunican estructuras dinmicas en los
nodos fuente y destino llamadas output e input streams respectivamente.
Un input streams dentro de un QP recibe paquetes de fuentes externas. Ms tarde, los paquetes
se almacenan automticamente dentro del stream, siguiendo un orden FIFO, y desde ah pueden
ser accedidos por los procesos del QP que lo soliciten.
138
Los input streams son reservados dinmicamente segn sean necesarios para soportar las
entregas, ya que Simulation Kernel no sabe el rango de canales que sern utilizados previamente.
Cuando se recibe un paquete en un input stream, se invoca uno de los procesos del QP
mediante una interrupcin de canal (stream interrupt). El proceso determinar por qu canal llega
el paquete llamando a la funcin op_intrpt_strm(), que devuelve el ndice asociado a un stream.
Conocido el canal, se recoger el primer paquete que lleg mediante op_pk_get().
Figura A. 10 Canales de entrada/salida a un proceso

El lado opuesto al anterior de un packet stream es el output stream. Estos canales realizan la
comunicacin de paquetes mediante las funciones del tipo op_pk_send. Los output streams tienen
tambin un ndice asociaciado, sin embargo, nicamente sern vlidos los que estn asociados a un
objeto fsico packet stream.
Estadsticas (Input Statistics y Local Output Statistics)
Los dos tipos de estadsticas van a conformar los estremos de los statistic wires, mencionados
anteriormente en el modelo de nodos.
Los input statistics son construcciones internas que aceptan valores numricos enviados por
otros mdulos dentro del mismo nodo. Las construcciones mencionadas, se identifican por un
entero, y nicamente retienen el ltimo valor que ha llegado desde statistic wire (en este caso, no
hay buffer, al contrario de lo que ocurrira con los output/input streams. En el caso de que haya
varios statistic wire conectados a un mismo input statistic, el ltimo valor de la ltima estadstica
que se haya actualizado es el que prevalece. El valor resultante, es accesible para cualquier proceso
del mdulo mediante op_stat_local_read().
Las Local output statistics son el otro extremo del cable, y se denominan local para
diferenciarlas de las estadsticas globales, que pueden ser compartidas por varios QP dentro de un
modelo de nodos. Este tipo de recursos permiten enviar estadsticas definidas por el usuario, que
son privadas para cada QP. Los procesos actualizan las local output statistics llamando a
op_stat_write(). Una sola de stas puede enviar datos a travs de varios statistic wire a la vez. Si
queremos acceder a una estadstica de este tipo, los procesos tienen que saber primeramente su
identificador a travs de op_stat_reg().
139
Los procesos dentro de un QP comparten las local output statistic existentes, cualquiera de
ellos puede actualizarlas. Pero los procesos pueden declarar cules van a utilizar, mediante la
operacin del editor Edit local statistics, como se puede ver en la figura siguiente:
Figura A. 11 Estadsticas locales a un proceso

Estadsticas Globales
stas recogen toda la actividad de todo el sistema de comunicaciones. Normalmente, son la media
de los valores de las estadsticas locales de los diferentes componentes del sistema. Ejemplos de
estas estadsticas son el retardo extremo a extremo, jitter o rendimiento de la red.
Cada modelo de proceso debe declarar las estadsticas globales que va actualizar durante la
simulacin mediante la operacin Global statistics del editor de procesos, como sucede con las
estadsticas locales.
Para acceder a una estadstica global, es necesario primeramente, que un proceso obtenga su
identificacin mediante op_stat_reg(), para despus actualizarla mediante op_stat_write().
Subcolas
Los mdulos cola pueden ser configurados para contener cualquier nmero de subcolas que
permiten almacenar paquetes de una manera determinada. Todos los procesos dentro de una cola
tienen el mismo derecho a acceder a las subcolas y pueden insertar y extraer paquetes cuando lo
requieran para implementar una determinada disciplina de cola (FIFO, PQ, WFQ, ect).
Atributos
140
Los QP poseen un conjunto de atributos que especifican alguna de sus caractersticas ms

importantes. Todos los procesos dentro de un QP pueden modificar y obtener los valores de estos
atributos utilizando respectivamente las funciones: op_ima_obj_attr_set() y op_ima_obj_attr_get().
Los atributos que definen el comportamiento de un mdulo estn declarados en el modelo de
proceso, y es posible que el usuario, pueda declarar nuevos para obtener caractersticas especficas
para un tipo de aplicacin especfica. La manera de hacer esto, es en el editor de procesos, con la
opcin Interfaces Model Attributes.
Para poder ser vistos en otros niveles de modelado, los atributos se heredan en los QP que
alojan esos modelos de proceso. Entonces, los atributos de un QP van a ser el conjunto de atributos
del proceso raz y de sus hijos. Para impedir que haya conflictos en los nombres de los atributos,
cada uno lleva de prefijo el nombre del modelo de proceso del que proviene, excepto los del
proceso raz.
El mbito de los atributos es slo el mdulo al que pertenecen. Cada QP tiene una copia
privada de los atributos, por lo que los cambios en uno de ellos no tienen efecto en los atributos de
los dems objetos.
Tambin hay atributos de mbito global, son los llamados atributos de simulacin o
simulation attributes. Son declarados igualmente en el modelo de procesos y compartidos por
varias entidades del sistema.
A.4.2 Componentes de un modelo de proceso

Un modelo de proceso va a especificar el comportamiento dinmico de un proceso. Para que un
modelo de proceso sea completo tiene que describir las acciones que el proceso implementar en
todas las circunstancias posibles.
Tambin, es habitual que un modelo de proceso represente protocolos o algoritmos existentes
en la vida real, por lo que su implementacin debe ajustarse a las especificaciones y estndares
oficiales de dichos protocolos o algoritmos. Por ejemplo, la implementacin TCP/IP est definida
segn los documentos RFC.
A.4.2.1 Proto- C: el lenguaje de los modelos de proceso
Es el lenguaje especial que utiliza OPNET Modeler. Est basado en C y en C ++ para desarrollar
modelos de proceso eficiente para describir el comportamiento de sistemas discretos de eventos.
Las caractersticas de este lenguaje son:
Basado en Diagramas de Transicin de Estados (STD) o Mquinas de Estado Finitas

(FSM). Proto-C utiliza STD, por ser el mtodo adecuado para describir la evolucin de
sistemas de eventos discretos y mantener la informacin de estado.
Combina la representacin visual y textual. La representacin visual la emplea para la
transicin de estados, sin embargo, la representacin textual, se utiliza para la informacin
detallada o toma de decisiones. La especificacin textual est contenida dentro de los
estados y transiciones representados grficamente. Adems, se incluye una gran librera de
procedimientos (las funciones citadas hasta ahora forman parte de estos procedimientos).
Representacin de la informacin de estado. La informacin de estado es un conjunto de
datos proporcionado o generado por el proceso. Esa informacin es guardada en forma de
variables, que sern utilizadas durante la ejecucin.
Creacin de Procesos Dinmicos. Como se ha dicho anteriormente, los procesos van a
crear otros, en funcin de las exigencias de ejecucin.
Ejecucin eficiente. La estructura del lenguaje Proto-C lo garantiza.
A.4.2.2 Diagramas de Transicin de Estados
141
Los diagramas de transicin de estados construdos en Proto-C consisten en dos tipos de

componentes bsicos: estados y transiciones. Los estados normalmente representan las situaciones
en las que un proceso puede entrar. Las transiciones especifican los cambios de estado posibles en
un proceso. Adems hay otros elementos como declaracin de variables, atributos y acciones
asociadas a cada estado, que no se ven grficamente en el diagrama de estados.
Figura A. 12 Diagrama de transicin de estados del procesador TCP

Estados Forzados y No Forzados
Conforme van sucediendo los eventos, la informacin de estado est constantemente
actualizndose. En trminos de un STD, la palabra estado se refiere a un objeto que est en uno de
los modos o situaciones en que se puede encontrar un proceso. Los estados son mutuamente
excluyentes y complementarios, es decir, que un proceso siempre estar exactamente en un estado,
nunca habr ms de un estado ocupado en un instante determinado en un modelo de proceso. Las
transiciones que parten de un estado indican qu estado se ocupar despus y las condiciones que
cada cambio requiere.
La especificacin de acciones en Proto-C est asociada con cada estado, y se denominan
executives. Las executives en cada estado se clasifican en enter executives, que se realizan cuando
un proceso entra en el estado, y exit executives, que se realizan antes de abandonarlo para ejecutar
una de las transiciones posibles.
Proto-C delimita dos tipos de estados: forced y unforced que se diferencian en el tiempo de
ejecucin. La manera de distinguirlos en un diagrama es mediante el color. Los forced se
142
simbolizan con crculos de color verde, mientras que los unforced son rojos, como la siguiente
ilustracin:
Figura A. 13 Estados forzados y no forzados
Unforced States: Pueden modelar estados reales del sistema, ya que permiten una pausa
entre el enter y el exit executive. Despus de completar el enter executive de un estado, el
proceso se bloquea y devuelve el control al hilo de ejecucin en el que fue invocado. Ese
contexto puede ser por ejemplo, otro proceso que lo invoc mediante la funcin de KP
op_pro_invoke(), o en el caso de que el proceso fuera invocado por el Simulation Kernel,
si se bloqueara, sealara el final del evento, y por lo tanto, el Kernel podra elegir el
siguiente evento para empezar su ejecucin. En este punto, el proceso se mantiene
suspendido hasta que una nueva invocacin lo haga continuar con el exit executive del
estado en el que se encuentra.
En la Figura A. 15 se describe el flujo de ejecucin de un STD a travs de estados no
forzados. En la Figura 7. 14 se muestra el flujo de ejecucin de eventos a travs de estados
no forzados, es decir, todo el proceso hasta llegar a bloquearse.
Forced states: Cuando un proceso entra en este tipo de estado, ejecuta las enter
executives, y seguidamente las exit executives, por lo que no permiten esperar al proceso.
Es habitual dejar estas ltimas en blanco en este tipo de estados. A pesar de no ser tiles
para modelar sistemas reales, s que lo son en algunos casos para separar acciones
grficamente, o para controlar decisiones de flujo comunes a varios unforced states.
Separando grficamente las acciones a ejecutar ayuda a la modularidad, a la vez que se
obtiene un STD ms informativo.
Figura A. 14 Transiciones entre estados forzados y no forzados
143
Figura A. 15 Ejecucin en los estados forzados

Estado Inicial
Tiene que estar en todo modelo de proceso. Es posible convertir un estado existente en inicial a
travs de la opcin set initial state, en el editor de procesos. Estado inicial se identifica
grficamente mediante una flecha a su izquierda. Es el punto en el que empieza la ejecucin cuando
el proceso es invocado.
Puede jugar el papel de un estado normal, pero suele contener inicializaciones y otras
sentencias que deberan dar lugar nicamente una vez, con lo que la mayora de los modelos de
proceso no incluyen transiciones de vuelta a l.
Transiciones
stas van a describir el posible movimiento de un proceso entre un estado y otro, y las condiciones
bajo las cuales, ese cambio puede ocurrir. Hay cuatro componentes en la especificacin de una
transicin: el estado fuente, el estado destino, la condicin y la accin o executive.
La especificacin de la transicin se lee: Si la condicin es cierta, ejecutar lo indicado en el
executive y transferir el control al estado destino.
En el editor de procesos las transiciones se representan grficamente. Cada estado puede ser
origen o destino de varias transiciones, dibujadas como arcos con la punta de la flecha apuntando
al nodo destino. La condicin y el executive aparecen en forma de etiqueta al lado del arco.
144
Siempre que se crea una transicin, el editor de Procesos automticamente encierra la condicin
entre parntesis seguida de la barra /, y el executive. Las transiciones que tienen condicin tienen
el arco formado por una lnea discontinua, y las que no tienen condicin, el arco es una lnea
continua. En el grfico siguiente, se muestran los distintos tipos de transiciones:
Figura A. 16 Diferentes tipos de transiciones entre estados no forzados

Para saber si se debe pasar al siguiente estado o no, las condiciones de transiciones se evalan. Un
proceso evala las transiciones de salida una vez ha completado la ejecucin de las exit executives
del estado en el que est.
El manejo de las condiciones de una transicin es muy flexible, pueden ser muy simples, o por
el contrario, formar una expresin compleja que involucran variable de estado, atributos y otra
informacin almacenada en la memoria local o global. Asimismo, puede involucrar llamadas a
procedimientos definidos por el usuario que devuelvan un valor booleano que si se cumple o no la
condicin. Alternativamente, es posible evaluar las condiciones de transicin en el propio estado
origen, al final del exit executive.
Hay una condicin especial (default), que asegura que pese a que no se cumplan las
condiciones de transicin, siempre se pueda transitar a otro estado. La transicin default se cumple
solamente cuando no lo hacen las otras transiciones.
Las transiciones que estn configuradas con una condicin vaca son equivalentes a
transiciones en las que su condicin siempre es true. A este tipo de transiciones, en el modelo de
procesos se las llama transiciones incondicionales. Un estado que tenga una transicin
incondicional, no tiene condicionales saliendo de l.
Cada transicin incorpora un atributo que especifica una accin o executive, que es ejecutada
en el momento en que el proceso decide atravesar esa transicin. Es decir, posteriormente a evaluar
las posibles transiciones, el proceso selecciona una de ellas, ejecuta su executive y pasa a las enter
executives del siguiente estado.
A.4.2.3 Macros
Prcticamente todas las macros utilizadas en un modelo de proceso se definen en su Header Block
o HB.
Header Block o Bloque de Cabecera es un rea de cdigo C y C++, similar a la cabecera de un
fichero en C o C++. Las Macros se utilizan, por lo general, para representar constantes,
condiciones de transicin, transition executives, u operaciones comunes. Para reconocerlos en el
bloque de cabecera, las macros empiezan con la directiva #define.
Tambin se pueden encontrar macros en ficheros de definicin externa (con el sufijo .h, del
tipo oms_qm.h o ip_qos_support.h), que se incluyen en el header block con la directiva
#include. Este mtodo resulta til cuando varios modelos de proceso tienen que compartir un
conjunto de definiciones. Va a favorecer la reutilizacin.
145
A.4.2.4 Variables
Los procesos en Proto-C tienen acceso a varias formas de memoria para almacenar informacin,
cada una con las caractersticas necesarias para usos particulares. Algunas de estas formas,
llamadas variables, van a permitir ser referenciadas y manipuladas mediante nombres ordinarios, y
no direcciones de memoria. Existen tres tipos de variables en los modelos de proceso: de estado,
temporales y globales.
La siguiente tabla muestra los dos tipos de variables y su mbito y visibilidad:
Function
Block
Tipo de Variable \ Visibilidad
State Executives
Temporal
Estado
Global (como las definidas en
ficheros externos o en HB)
X
X
Funciones en
ficheros Externos
(extensin .ex.c)
X
(Usando extern)
La declaracin de cada uno de los tipos de variables utiliza un mecanismo diferente, para indicar al
compilador qu categora aplicar. Las caractersticas de cada uno de ellos son:
146
Variables de Estado (State variables): Se utilizan para representar la informacin

acumulada o retenida por un proceso. Se denominan as porque representan el estado
completo de un proceso en cualquier instante, junto con la posicin que ocupa el proceso
dentro del STD. Se caracterizan por mantener su valor a travs del tiempo desde la
perspectiva de cada proceso, es decir, son persistentes. nicamente pueden ser
modificadas mediante las acciones ejecutadas por el propio proceso, lo que conlleva que
los valores de las variables de estado permanezcan inalterados mientras el proceso est
bloqueado, y cuando ste contina su ejecucin, todo se queda como lo haba dejado.
Una caracterstica relevante de estas variables es que a pesar de su persistencia, son
privadas para cada proceso, lo que conlleva que aunque haya dos instancias del mismo
modelo de proceso existentes en el mismo mdulo, sus variables de estado guardarn la
informacin de manear independiente, sin conflictos, a pesar de que el nombre de las
variables sea el mismo.
Las variables de Estado se declaran en un rea especfica del modelo llamada state
variables block, accesible desde el editor de procesos (men Code blocks State
Variables), en el cual se pueden crear nuevas, o modificar las existentes. Cuando el
proceso es invocado por primera vez, no tienen valores iniciales particulares (no se las
puede dar valores durante su declaracin), es responsabilidad del propio proceso asignar
esos valores de forma consistente. En realidad, esa suele ser una de las principales
actividades que se realizan en las executives del estado inicial.
Variables Temporales (Temporary Variables): stas almacenan informacin que no

requiere persistencia, por lo que es posible que entre una invocacin y otra del mismo
proceso hayan cambiado. Por ello, es habitual utilizarlas como instrumentos auxiliares
para facilitar la ejecucin de expresiones complejas en un instante de tiempo. Ejemplos de
este tipo de variables son: un paquete recin extrado de un stream o el ndice de un bucle.
stas variables se declaran en una ventana que aparece al seleccionar Code Blocks
Temporary Variables. Es posible dar valores iniciales a las variables incorporando una
asignacin en su declaracin.
Variables Globales (Global variables): Facilitan un mtodo para que diferentes procesos
guarden informacin en un rea comn. Pueden ser de cualquier tipo predefinido en C u
OPNET, incluyendo igualmente tipos de datos definidos por el propio usuario. En el
momento en el que un proceso modifica una variable global, puede afectar en las
operaciones de otros procesos.
Estas variables se definen en header block, y cada una tiene que tener una declaracin
principal en el header block del modelo de proceso con el que ms asociado est. En el
caso de que otros procesos compartan acceso a ella, su bloque de cabecera incluir una
declaracin externa. Puede haber muchos procesos que tengan declaraciones externas de
una variable, pero slo uno tendr una declaracin principal. Las declaraciones externas se
definen con extern.
Las variables globales se pueden inicializar en el momento de su declaracin
mediante la asignacin de un valor, pero slo en la declaracin principal, al igual que las
variables temporales. La inicializacin se ejecutar previamente al comienzo de la
simulacin.
A.3.4.2.5 Uso de Funciones
Para hacer los modelos de proceso ms modulares y sencillos, una de las tcnicas que se ha dicho
anteriormente es utilizar forced states en el diagrama de estados, para as mostrar de forma ms
intuitiva el flujo de ejecucin de un proceso. La otra forma es el uso de funciones.
Las funciones son especificaciones de una aplicabilidad determinada que pueden aceptar
argumentos. Podemos usar funciones dentro de un modelo de proceso mediante dos mecanismos:
Function Block: Dentro de un modelo de proceso, las funciones pueden ser definidas
dentro de una seccin denominada function block o FB. El bloque FB se puede editar
desde el editor de procesos pinchando en el botn con su mismo nombre. Cada funcin
modulara una funcionalidad que cualquier elemento del diagrama de estados puede
utilizar. De esta manera se consigue un modelo de procesos ms simple y modularizado,
fomentando una alta reutilizacin.
External Object Files: Es una alternativa al mtodo anterior, existe la posibilidad de

utilizar funciones definidas en ficheros externos, que se vinculan al modelo de procesos
durante la simulacin. Esto permite desarrollar y mantener funciones de manera
centralizada y compartida por varios modelos de proceso. Estos ficheros se suelen
encontrar en la ruta OPNET\14.5.A\Models\std, y suelen terminar con el sufijo .ex.c.
Es necesario indicar los ficheros externos que un determinado modelo de procesos
necesita, para ello tenemos la opcin File Declare External Files
A.3.4.2.6 Atributos del modelo de procesos

OPNET modeler nos proporciona atributos con el propsito de permitir desarrollar modelos de
forma parametrizada. Son los modelos de procesos los que suelen utilizar este mecanismo, ya que
es el modelador el que programa el cdigo y elige los valores que deben de ser interpretados como
atributos de cara al comportamiento del proceso.
Un atributo puede ser declarado dentro del editor utilizando la opcin Interfaces Model
Attributes. Cada atributo se define con un nombre nico y unas propiedades.
Durante la simulacin estos atributos aparecen como atributos del procesador o cola del
modelo de nodos. Las funciones para leer o escribir sobre los atributos son op_ima_obj_attr_set()
y op_ima_obj_attr_get() respectivamente. Es raro tener que cambiar el valor de un atributo durante
la simulacin, se suelen utilizar para configurar el proceso al inicio de la misma.
Attribute Interfaces
Los procesos mantienen un conjunto de interfaces de atributos distintos a los de su modelo. Por lo
general suelen contener atributos promocionados desde objetos dentro del modelo, as como
especificaciones de los atributos que usar el modelo. En el caso de los modelos de procesos,
ninguno de sus objetos puede promocionarlos. Por tanto, attribute interfaces consistir
147
simplemente en atributos del respectivo procesador o cola del modelo de nodos. Usando este
mecanismo, el usuario puede especificar por adelantado los valores y propiedades del procesador (o
cola) que usar este modelo.
A. 5 Simulacin
En los siguientes apartados se describirn los componentes necesarios para que se lleve a cabo una
simulacin de un sistema. Despus veremos como se lleva a cabo una simulacin desde el punto de
vista del tiempo, los eventos y las interrupciones.
Podemos definir la simulacin como el proceso de disear un modelo de un sistema real y
llevar a trmino experiencias con l, con la finalidad de comprender el comportamiento del sistema
o evaluar nuevas estrategias - dentro de los lmites impuestos por un cierto criterio o un conjunto
de ellos - para el funcionamiento del sistema [WF].
Un modelo de simulacin discreto es la representacin de un sistema en el que su estado
cambia solamente en instantes concretos de tiempo. OPNET es un simulador catalogado dentro del
grupo de sistemas de eventos discretos.
Para entender los siguientes apartados resulta interesante conocer los siguientes conceptos:
Modelo de simulacin: es el conjunto de hiptesis acerca del funcionamiento del sistema

expresado mediante relaciones matemticas y/o lgicas entre sus distintos elementos. Se
trata de la representacin lgica del sistema del mundo real que queremos estudiar.
Proceso de simulacin: se trata de generar virtualmente el funcionamiento del sistema a

lo largo del tiempo para poder estudiar su comportamiento ante diferentes situaciones.
A.5.1 Construccin de un modelo de simulacin

Previamente a la simulacin de un sistema, se debe obtener un programa de simulacin compilado,
compuesto por instrucciones mquina que la computadora pueda ejecutar. Un programa de
simulacin consiste en partes separadas de cdigo objeto. Cada parte tiene un papel especfico
dentro de la simulacin. Varios ficheros objeto son proporcionados por OPNET, mientras que otros
nos vienen de la configuracin establecida por el usuario.
A continuacin veremos varios componentes que forman parte de un programa de simulacin
en OPNET:
148
Simulation Kernel: se trata de una librera de cdigo objeto que contiene algoritmos y
varios servicios utilizados en la simulacin. Proporciona el marco para todas las
simulaciones, incluyendo los servicios esenciales de carga de modelos, planificacin y
gestin de eventos, recoleccin de estadsticas, reservas de memoria Contiene todos los
Kernel Procedures (KP) llamados por los modelos de procesos.
Process Models: cada modelo de proceso que interviene en la simulacin se traduce en un
fichero fuente escrito en C, teniendo extensin pr.c. Estos ficheros se compilan justo
antes de iniciar la simulacin utilizando un compilador disponible en el equipo (en este
proyecto se ha utilizado Visual C++ 2003), generando un fichero objeto con sufijo pr.o.
Pipeline Stages: referencia a los links del sistema e implementan operaciones modulares
y actividades relacionadas con la transmisin de paquetes entre mdulos transmisores y
receptores. Su extensin es ps.c.
External Object Files: estos ficheros contienen funciones utilizadas por los modelos de
procesos y los pipeline stages durante la simulacin. Se pueden desarrollar en C o en otros
lenguajes que puedan ser invocados desde C. Su extensin es ex.c. Su uso en el modelo
de procesos depende de su previa declaracin.
External Archives: similares a los anteriores, pero empaquetados de forma que contienen
varios ficheros objetos.
Una vez obtenidos todos estos componentes, OPNET proporciona un programa ejecutable para
realizar la simulacin.
A.5.2 Simulacin de eventos discretos

A.5.2.1 Eventos y simulation time
Por lo general, una simulacin de eventos discretos, crea una secuencia de estados para un sistema.
ste va evolucionando por los diferentes estados a medida que avanza el tiempo, basndose en las
especificaciones de comportamientos de sus componentes y en la interaccin existente entre ellos.
La nocin de tiempo en una simulacin no tiene que ver con el tiempo real utilizado para llevar a
cabo dicha simulacin. El tiempo de simulacin es una variable que mantiene el programa, y
permite especificar el tiempo que vamos a suponer que el sistema est en funcionamiento. Esta
variable es conocida como simulation time, para distinguirla del tiempo real.
Mediante simulation time y los eventos es posible estudiar el comportamiento que tendra un
sistema a lo largo de un tiempo (real) determinado (empleando para ello un tiempo real pequeo).
En una simulacin de eventos discretos, la progresin del modelo durante el simulation time
se descompone en instantes individuales, conocidos como eventos, en los que suceden cosas. Cada
evento representa la necesidad de que el modelo realice un cambio en su estado o tome alguna
decisin. Eventos tpicos son la recepcin de paquetes, expiracin de temporizador, terminacin
del alguna tarea, fallo
Cuando se produce un nuevo evento, se dice que es ejecutado por la simulacin. Pueden
ocurrir varios eventos en el mismo valor de simulation time. Los eventos no tienen por qu
repartirse de manera uniforme durante el tiempo que dura la simulacin. Es tpico que su densidad
vare a medida que progresa la simulacin.
Figura A. 17 Distribucin tpica de eventos durante el tiempo de simulacin

Simulation time slo vara en los intervalos entre eventos. Durante la ejecucin de un evento el
tiempo no vara (duracin 0, instantneo).
A.5.2.2 Planificacin y lista de eventos
Una simulacin en progreso se puede ver como un generador y sumidero de eventos. Algunos
componentes generan eventos en base a sus planificaciones, los cuales afectan a otros de forma
determinada.
La simulacin de eventos discretos gestiona los eventos mediante la llamada lista de eventos.
Esta lista asegura una correcta ejecucin de los eventos generados.
Un evento tiene un tiempo de simulacin asociado en el que se espera que ste suceda. La
solicitud de nuevos eventos se denomina event scheduling, y se pueden solicitar para un instante
futuro o para el instante actual, pero nunca para un instante del pasado (lo que pas, pas). No es
raro que los eventos se planifiquen para el tiempo actual como consecuencia de una reaccin en
cadena, esto es, se producen varios eventos sucesivos, cada uno desencadenado por el anterior, sin
que el tiempo de simulacin avance.
La lista de eventos mantiene todos los eventos ordenados por orden cronolgico, as el
siguiente evento se ejecutar una vez el evento actual ha finalizado su ejecucin. El evento ms
cercano al tiempo de simulacin actual es la cabeza de la lista, y el que se planifica para un
149
instante ms lejano se encuentra en la cola. Durante la simulacin, el Kernel ir aadiendo eventos

a esta lista en cualquiera de sus posiciones, por lo que la cabeza y la cola irn variando de manera
dinmica a lo largo de la simulacin, del mismo modo que lo har el mismo tamao de la lista. El
Kernel ser tambin el encargado de sacar los eventos y ejecutarlos. Cada simulacin tendr su
propio patrn de crecimiento/decrecimiento en funcin de las actividades modeladas.
Existe un grupo de procedimientos (Ev package) dentro de los Kernel Procedures dedicados al
manejo de esta lista y a todo lo relacionado con la planificacin.
Una simulacin contina slo en el caso de tener nuevos eventos que ejecutar. Por tanto,
cuando la lista queda vaca, la simulacin finaliza (incluso si no se ha alcanzado el tiempo fijado
por el usuario).
Figura A. 18 Organizacin de una lista de eventos durante el tiempo de ejecucin

Cuando se ejecuta una simulacin, sta debe recibir por lo menos un evento para poderse iniciar.
Existe un tipo especial de evento, begin simulation, que los procesos alojados en los QP pueden
lanzar si tienen habilitado el atributo begsim intrpt.
A.5.2.3 Planificacin y lista de eventos
Atributos de los eventos
Antes se ha dicho que un evento tiene asociado un tiempo concreto en el que debe ocurrir. Esta es
una de las propiedades de los eventos, pero tienen varias ms. Cada evento tiene un conjunto de
atributos que almacenan su informacin. Parte de esa informacin es utilizada por el Simulation
Kernel cuando debe ejecutarlo. Algunos de estos atributos son:
150
time: instante de simulacin en el que el evento debe ocurrir.

execution ID: identificador de la orden de ejecucin del evento.
module: mdulo en el que el evento ocurrir.
process: proceso que recibe el evento.
type: tipo de evento, dependiendo de la actividad con la que est relacionado.
Tipos de eventos
En OPNET existen 13 tipos de eventos que soportan varias actividades de modelado. Algunos de
ellos sirven para propsitos muy concretos, mientras otros son ms generales y estn relacionados
con actividades ms variadas. Podemos destacar unos cuantos:
self: para contadores y modelado de delays.

stream: comunicacin de paquetes entre mdulos de un modelo de nodos.
statistic: notificacin asncrona de cambios en estadsticas y seales.
begin simulation: notificacin de comienzo de la simulacin, permitiendo a los procesos
inicializar su estado.
end simulation: notificacin de fin de la simulacin, permitiendo a los procesos registrar
estadsticas.
process: invocacin directa de un proceso dentro de un mdulo.
Procesamiento de Eventos Interrupciones

Cuando un modelo de proceso recibe un evento analiza ciertos atributos del mismo, entre ellos el
tipo de evento. Una operacin muy tpica es la realizacin de la llamada a op_intrpt_type(), para
identificar el tipo de evento que ha sucedido.
Las interrupciones son un concepto dinmico. Consisten en la invocacin que resulta de la
ejecucin del evento por el Simulation Kernel. Ocurren cuando un evento llega a la cabeza de la
lista y es ejecutado. Tienen los mismos atributos que los eventos que las generan.
Una vez que se ha recibido una interrupcin y ha sido determinado su tipo, procedencia y
dems informacin, el modelo de proceso es el que decide cmo ser tratada y las acciones a
realizar, en funcin de las especificaciones dadas por el usuario.
151
Apndice B
Adicin de atributos y estadsticas
B. 1 Modificacin de atributos
Los atributos es la forma que el operador, desde el nivel de redes, puede configurar los distintos
nodos y elementos que componen su topologa. Facilita al usuario la cumplimentacin de
parmetros a travs de una interfaz grfica amigable abstrayndole de la complejidad y conceptos
aplicados en los niveles de nodos y procesos.
Esa interfaz de usuario puede ser extendida, de manera que la comunidad de investigadores
pueda aadir nuevas funcionalidades sobre la herramienta. Esto se puede realizar tanto desde el
editor de nodos como desde el de procesos (segn queramos modificar la interfaz en un nivel u
otro de modelado).
B.1.1 Acceso a la tabla de atributos

En la barra de tareas del editor de procesos, debermos acceder al men InterfacesModel
Attributes. La ventana que nos aparecer ser similar a esta:
Figura B. 1 Atributos proporcionados por el modelo de procesos para

qos_attribute_definer
Analizando esta ventana, vemos que en realidad es una tabla con varias columnas. Veamos cada
una de ellas:
Attribute Name: indica el nombre del atributo

Group: grupo al que pertenece el atributo (no hemos hecho ninguna clase de agrupacin
de atributos, por lo que esta columna no tendr valor para nosotros).
Type: tipo de informacin que guarda el atributo. Un atributo puede ser de tipo integer,
double, compound, string, El valor compound significa que el atributo guardar
informacin de tipo Objid, es decir, que contendr otros objetos atributo anidados, y que
en el nivel de redes aparece como ().
Units: unidades en que estar expresado el atributo. Vemos que esta columna permanece
vaca para toda la tabla por ser todos atributos compuestos.
153
Default Value: valor por defecto proporcionado por el sistema cuando el atributo es
requerido y no ha sido configurado por el usuario. Tambin se usa para sugerir un valor al
usuario.
Tags: palabras claves para identificar el atributo dentro del men Edit Attributes a la hora
de realizar una bsqueda.
Desde esta ventana podemos explorar e ir viendo los detalles de cada uno de los atributos. Como se
ha visto, muchos de estos atributos son compuestos. Sealando cualquiera de estos atributos y
pulsando en Edit Properties accederemos a la estructuracin del atributo compuesto en cuestin.
B.1.2 Aadir un nuevo atributo

Para aadir un nuevo atributo hay que proceder de la siguiente manera. Desde la ventana Model
Attributes vemos que hay un campo de texto que nos permite aadir un nuevo atributo sin ms que
escribir su nombre y pulsar en el botn Add. El atributo aparecer en la tabla y podremos
configurar los distintos campos vistos en el apartado anterior. Si el atributo es compuesto podemos
configurar su rbol de atributos a nuestra eleccin.
B.1.3 Aadir valores a un atributo ya creado

Para poder modificar un atributo debemos hacer pblico su conjunto de valores. Para ello,
sealamos dicho atributo y pinchamos en la opcin Edit Compound Attributes Properties. Una
nueva ventana emerger.
Explicaremos un poco los campos de esta ventana:
Data Type: Nos dice el tipo del atributo que estamos editando (en el ejemplo de la captura
se trata de un atributo compuesto).
Default Value: Valor que aparecer por defecto en el atributo, es decir, valor que tomar
el atributo en la simulacin si el usuario no lo modifica.
Units: Unidades en las que se expresa el atributo (en el ejemplo, como ste es compuesto
aparece vaco).
Comments: Comentario que explica para qu se utiliza el atributo.
Symbol Map: Son los posibles valores que podr tomar el atributo. Las opciones son las
que el usuario ve cuando edita el atributo.
Figura B. 2 Valores del atributo compuesto
154
B. ADICIN DE ATRIBUTOS Y ESTADSTICAS
Figura B. 3 Ventana de adicin de valores a un atributo

Para poder ver el conjunto de valores del Symbol Map debemos entrar en el modo privado.
Attribute Properties: Las propiedades de los atributos se guardan en un archivo dentro del
sistema de ficheros. Si queremos modificar las propiedades, debemos elegir el modo Private y, de
esta forma, pasaremos a editar un nuevo fichero.
Podemos observar que se han habilitado muchos de los campos que antes aparecan
inoperativos. Ahora podramos aadir un nuevo smbolo con una nueva configuracin dentro del
Symbol Map.
Figura B. 4 Aadiendo un nuevo smbolo
155
Pulsamos OK para salir de las propiedades y volver a la anterior pantalla, recordando que seguimos
en modo privado. Ahora si que se nos est permitido editar las propiedades de un atributo (Edit
Properties), a diferencia de lo que ocurra en modo pblico. Seleccionando esta opcin aparecer
una nueva ventana con un nuevo Symbol Map, que deberemos modificar para aadir el nuevo valor.
Pulsamos Ok y regresamos a la ventana anterior para volver a entrar en Edit Attribute
Properties para cambiar otra vez al dominio pblico (habilitamos la casilla Public). Se crear un
nuevo fichero de propiedades. Si pulsamos Save public podremos guardar el nuevo fichero en el
directorio que queramos de nuestro sistema.
B. 2 Adicin de nuevas estadsticas AQM

OPNET nos permite seleccionar una amplia gama de resultados estadsticos para recolectar durante
la simulacin. Cuando nos interesa algn resultado concreto no disponible por defecto, necesitamos
crear nosotros mismos esa estadstica y preocuparnos de que sus muestras se recuperan cuando es
necesario.
En los resultados del control digital es especialmente importante la evolucin de dos valores a
lo largo del tiempo, estos son la entrada y la salida del proceso, o lo que es lo mismo en nuestro
caso particular, la probabilidad de descarte de un paquete y el tamao de la cola. Este ltimo valor
se puede obtener de forma directa si se selecciona desde Choose Individual DES Statistic la
estadstica local de nodo Buffer usage (packets) (dentro del apartado IP Inteface). No sucede lo
mismo con la probabilidad de descarte, la cual deber ser obtenida por nosotros mismos.
En el FB de ip_output_iface existe una interesante funcin que deberemos modificar,
output_iface_stats_register, la cual registra las estadsticas para una de las colas. Para aadir la
probabilidad de descarte:
sprintf (new_name, "%s Discart probability %s Q%d%s", queuing_scheme,
intf_name, q_label, queue_category_str);
dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "Probabilidad
descarte", stat_annotation_str, OPC_STAT_LOCAL);
Oms_Dim_Stat_Rename (dim_stathandle, new_name);
oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_Probability,dim_stathandle);
La variable new_name almacenar el texto que le aparecer al usuario para que seleccione la
estadstica. dim_stathandle nos permitir identificar y actuar sobre esa estadstica de forma
inequvoca. Por ltimo, OmsC_Qm_Probability es una constante que definir la estadstica. sta
deber ser definida previamente en oms_qm.h:
typedef enum OmsT_Qm_Stat_Index
{
OmsC_Qm_Buffer_Size_Bytes
OmsC_Qm_Buffer_Size_Packets
...
OmsC_Qm_RED_Avg_Queue_Size
OmsC_Qm_Probability
OmsC_Qm_Max_Stat_Index
} OmsT_Qm_Stat_Index;
= 0,
= 1,
= 10,
= 11,
= 12
/* must remain last */
Ser aadida con valor 11. La constante OmsT_Qm_Stat_Index debe de ser incrementada para
mantener la coherencia.
Daremos valores a la estadstica de estudio cada vez que la probabilidad de descarte se
modifique, esto ocurrir en cada uno de los periodos de muestreo.
156
B. ADICIN DE ATRIBUTOS Y ESTADSTICAS
manejador=(OmsT_Dim_Stat_Handle) qm_info->child_queue_pool_ptr>queue_info_parray[0]->queue_stats [OmsC_Qm_Probability].shandle;

if (Oms_Dim_Stat_Handle_Is_Valid (manejador))
{
Oms_Dim_Stat_Write (manejador,probabilidad);
}
En primer lugar obtendremos la variable manejador, la cul nos permitir acceder a la estadstica.
Posteriormente, si el manejador es vlido, tomaremos una muestra de la probabilidad en el instante
de tiempo actual.
Seguidamente procederemos a declarar la estadstica local dentro del modelo de procesos
(ip_output_iface). Para ello accederemos a la opcin InterfacesLocal Statistics. Se nos abrir
una ventana emergente sobre la que deberemos aadir nuestra nueva estadstica.
Figura B. 5 Descripcin de una nueva estadstica

Daremos valor al nombre de la estadstica y configuraremos los distintos parmetros. Indicaremos
que pertenece al grupo IP Interface y seleccionaremos un estilo de dibujo lineal (a pesar de su
naturaleza discreta, el ver el resultado de forma continua queda ms claro).
A continuacin deberemos promocionar la estadstica, ya desde el modelo de nodos, para que
la opcin este disponible para el usuario del nivel superior. Seleccionaremos la opcin
InterfacesNode Statistics. Veremos varias lneas con estadsticas, para aadir una nueva no
tenemos ms que pinchar en la lnea en blanco tras la ltima estadstica, se abrir la ventana de la
figura:
Seleccionamos la estadstica que creamos en el nivel inferior y se aadir sobre la anterior
ventana. Los valores no sern modificados respecto de los del modelo de procesos.
Ya tenemos todo listo para poder estudiar la entrada del proceso. Antes de comenzar la
simulacin, desde el men Choose Individual DES Statistic ya tendremos disponible esta nueva
opcin.
Figura B. 6 Promocionar estadstica

157
Apndice C
Gua de instalacin de OPNET
En este apndice daremos las pautas bsicas para configurar el entorno de desarrollo de forma
ptima. En nuestro caso concreto se ha realizado una instalacin de OPNET sobre windows vista
proffessional.
C. 1 Instalacin de OPNET Development Kit module

En primer lugar instalaremos el paquete odktools_160A_PL1_10106_win en nuestro equipo.
Para ello se seguirn los pasos del instalador.
Tras la pantalla de introduccin, seleccionaremos el directorio del equipo sobre el que
queremos que se realice la instalacin.
Figura C. 1 Directorio de instalacin de OPNET
159
En el siguiente paso configuraremos de forma opcional el Servidor de Reports.
Figura C. 2 Configuracin del servidor de reports

A continuacin se establecen las opciones del acuerdo de licencia del producto. Nosotros hemos
utilizado la primera de las opciones, Standalone.
Figura C. 3 Configuracin del servidor de licencias

160
C. GUA DE INSTALACIN DE OPNET
A continuacin aparecer un resumen con la informacin de la instalacin que se va a llevar a cabo.

Tras ver que todo es correcto pulsaremos sobre el botn Install.
Una barra de estado nos ir marcando el curso de la instalacin.
El siguiente paso sera instalar las libreras de la herramienta, sin embargo, antes de ello, se
recomienda la instalacin de un compilador de C++ que ser necesario. Los modelos y las
simulaciones son en esencia programas escritos en C y C++ y por tanto, para que puedan ser
ejecutados, necesitamos un compilador de dichos lenguajes. Yo he elegido el compilador de C++
includo en Microsoft Visual Studio .NET Professional 2003.
C. 2 Instalacin de Visual Studio .NET Professional 2003

Ejecutamos el programa de instalacin es_vs.net_2003_pro_full.exe y damos Unzip. Cuando
termine de descomprimir comenzar el asistente de instalacin.
Figura C. 4 Instalacin de Visual Studio

Clicamos en el paso 2 para comenzar con la instalacin del producto. En un primer momento se nos
pedir la clave de licencia, en mi caso, por ser estudiante de una titulacin de informtica en la
Uva, dispongo de una licencia gratuita de disfrute del producto.
Existen varios elementos que podremos instalar. Para utilizar y desarrollar sobre OPNET lo
nico necesario son las herramientas del lenguaje C++, por ello slo marcamos esta casilla en la
instalacin.
161
Figura C. 5 Seleccin de la herramienta Visual C++

A continuacin, siguiendo el FAQ #1219 [VB] se configuran las variables de entorno del sistema.
En concreto tenemos que tocar:
DevEnvDir
C:\Archivos de programa\Microsoft Visual Studio .NET 2003\Common7\IDE
INCLUDE
c:\Archivos
de
programa\Microsoft
Visual
Studio
.NET
2003\SDK\v1.1\include\;
C:\Archivos
de
programa\Microsoft
Visual
Studio
.NET
2003\Vc7\atlmfc\include;
C:\Archivos de programa\Microsoft Visual Studio .NET 2003\Vc7\include;
C:\Archivos
de
programa\Microsoft
Visual
Studio
.NET
2003\Vc7\PlatformSDK\Include;
C:\Archivos
de
programa\Microsoft
Visual
Studio
.NET
2003\SDK\v1.1\include;
C:\Archivos
de
programa\Microsoft
Visual
Studio
.NET
2003\Vc7\PlatformSDK\Include;
C:\Archivos
de
programa\Microsoft
Visual
Studio
.NET
2003\SDK\v1.1\include;
C:\Program Files\OPNET\16.0.A\models\std\include;
LIB
c:\Archivos de programa\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\;
C:\Archivos de programa\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\lib;
C:\Archivos de programa\Microsoft Visual Studio .NET 2003\Vc7\lib;
C:\Archivos
de
programa\Microsoft
Visual
Studio
.NET
2003\Vc7\PlatformSDK\Lib;
MSVCDir
Path
C:\Archivos de programa\Microsoft Visual Studio .NET 2003\Common7\IDE;
C:\Archivos de programa\Microsoft Visual Studio .NET 2003\Vc7\bin;
162
C:\Archivos de programa\Microsoft Visual Studio .NET 2003\Common7\Tools;

C:\Archivos
de
programa\Microsoft
Visual
Studio
.NET
2003\Common7\Tools\Bin;
C:\Archivos de programa\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin;
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;
VCINSTALLDIR
C:\Archivos de programa\Microsoft Visual Studio .NET 2003
VSINSTALLDIR
Una vez hecho esto se puede proceder a instalar las libreras sin ningn problema. El asistente de
instalacin es similar al utilizado anteriormente. A destacar esta pantalla que antes no apareca que
sirve para vincular la herramienta a los tipos de fichero .prj (proyectos) y .m (modelos).
Figura C. 6 Instalacin de libreras adicionales

Con todo esto ya estaramos preparados para comenzar a utilizar nuestra herramienta. Deberamos
de tener un icono de acceso directo en el escritorio de Windows y/o bien en el men de inicio junto
al resto de programas.
Figura C. 7 accesos directos a la herramienta
163
C. 3 Obtencin de la licencia
Al intentar abrir la aplicacin veremos que obtenemos el siguiente mensaje:
Figura C. 8 Obtencin de la licencia

No podremos empezar a usar la herramienta hasta que obtengamos y registremos una licencia para
nuestro equipo. Para gestionar este tema pulsamos en License Management. Se abrir una
ventana con la utilidad de gestin de licencias.
Figura C. 9 Gestin de licencias

164
Si pulsamos en Add License nos aparecen cuatro posibilidades para agregar licencias:
Figura C. 10 Mecanismos para aadir una nueva licencia

En m caso he utilizado la segunda eleccin (Browser). Se abrir el navegador, nos autenticaremos
con nuestras credenciales y procederemos a asignar una de las licencias disponibles (si las hay y no
estn caducadas) a nuestro equipo.
165
Apndice D
Principios bsicos del control
digital
D. 1 Introduccin al control digital
En muchos de los sistemas de ingeniera modernos, existe la necesidad la controlar la evolucin a
lo largo del tiempo de una o varias variables. Son necesarios controladores para asegurar el
correcto funcionamiento de estos sistemas. Para garantizar un desempeo satisfactorio ante la
presencia de perturbaciones e incertidumbres en el modelo, muchos de los controladores que se
utilizan a da de hoy utilizan realimentacin negativa. Son necesarios sensores para medir las
variables controladas y comparar su comportamiento frente a una seal de referencia. La accin de
control est basada en una seal de error, que es la diferencia entre el valor de la variable medida y
la seal de referencia.
Los controladores que manipulan la seal de error para determinar la accin de control
deseada han sido clsicamente sistemas analgicos, que incluyen componentes elctricos,
neumticos, mecnicos y de fluidos. Todos estos sistemas tienen entradas y salidas analgicas. A lo
largo del tiempo los controladores analgicos se han ido reemplazando por controladores digitales,
cuyas entradas y salidas estn definidas de forma discreta. Los reguladores digitales se basan en el
uso de circuitos digitales, ordenadores y microprocesadores.
Intuitivamente, uno pensara que los controladores que monitorizan de forma continua la
salida deberan de ser superiores a aquellos que lo hacen slo en instantes discretos de tiempo
(definidos por un periodo de muestreo). Esto es completamente cierto! Pero, entonces, a qu se
debe la migracin de sistemas analgicos a digitales? [Sam09]
La respuesta a la pregunta se basa en la velocidad de procesamiento de los microprocesadores
digitales y a la posibilidad de generar complejos y costosos algoritmos de control (instrucciones
ejecutadas por el microprocesador).
D. 2 Conceptos bsicos
Salida o variable controlada (y, cv): Variable medible cuyo comportamiento se desea controlar.
Entrada o variable manipulada (u, mv): Variable que puede ser manipulada de forma directa y
que modifica el comportamiento del sistema, afectando de esta forma a la salida.
Referencia o set point (ref, sp): Valor al que queremos que se site la variable controlada.
Controlador o regulador: Elemento que puede calcular de forma matemtica (analtica,
numrica...) el valor a aplicar en la entrada para conseguir alcanzar el set point
Algoritmo de control: u f ( ref , y ) Calcula la entrada en funcin de la referencia y del valor.
Seal de error: ref y , por lo tanto podemos redefinir el algoritmo de control como u f (e)
D.2.1 Lazo abierto y lazo cerrado

El control en lazo abierto se puede considerar un control manual y el control en lazo cerrado un
control automtico. Cuando el sistema se encuentra en lazo abierto, el valor de la seal de entrada
es manejado de forma manual, el controlador no tienen ninguna utilidad, un valor en la referencia
167
en modo automtico no tendr ningn sentido. En contraposicin, el modo de operacin automtico

va calculando a travs del regulador los distintos valores de la seal de entrada para alcanzar el
valor de referencia. En automtico movemos la referencia y en manual la entrada. Las figuras D. 1
y D. 2 son muy ilustrativas en relacin a esto.
Figura D. 1 Esquema de conmutacin entre modos automtico y manual
Figura D. 2 Operando en automtico y manual
168
D. PRINCIPIOS BSICOS DEL CONTROL DIGITAL
D.2.2 Lazo de control digital
Figura D. 3 Lazo de control digital

La Figura D. 3 nos proporciona una forma rpida y sencilla lo que va sucediendo con las distintas
seales al pasar por cada uno de los elementos de control. A continuacin se ir explicando cada
uno de los pasos que se van sucediendo partiendo desde la obtencin de la seal de error (e):
1.
2.
3.
4.
5.
6.
7.
8.
9.
La seal de error es analgica.

Muestreamos y cuantizamos dicha seal.
Se codifica la seal cuantizada.
La seal digital se puede ejecutar en el microprocesador.
Se obtiene una seal digital de salida.
Seguidamente se procede a la descodificacin para obtener una seal analgica (en el
caso de que el actuador sea analgico).
El circuito mantenedor nos permite obtener una seal analgica continua en el tiempo.
Esa seal analgica es aplicada sobre el actuador.
Finalmente el actuador genera una seal sobre la planta.
Una seal de reloj sincroniza la parte digital.
D. 3 Requisitos generales de un sistema de control

D.3.1 Estabilidad
Respuesta acotada a entrada acotada.

Se puede definir tanto en lazo abierto como en lazo cerrado. (ver figuras D. 4 D.7)
Con un sistema inestable es imposible trabajar.
D.3.2 Dinmica
Relacionado con la rapidez de la respuesta y los amortiguamientos. En este mbito se pueden
realizar estudios tanto en lazo abierto como en lazo cerrado. La sintona de reguladores influye en
la dinmica del sistema.
En muchos sistemas nos interesa un control sin sobrepicos aunque tengamos un acercamiento
ms lento, en otros quizs sea ms importante la velocidad.
169
Figura D. 4 Sistema estable lazo abierto
Figura D. 5 Sistema inestable lazo abierto
Figura D. 6 Sistema estable lazo cerrado
Figura D. 7 Sistema inestable lazo cerrado
170
D. PRINCIPIOS BSICOS DEL CONTROL DIGITAL
D.3.4 Errores Estacionarios

Se estudian en automtico (lazo cerrado). Lo ideal sera que la salida fuera igual que la referencia,
sin embargo no suele ser as y el sistema se estabiliza con una cierta cantidad de error.
D.4 Conceptos bsicos de modelado

Existen muchos tipos de modelos (modelos fsicos, modelos mentales, modelos simblicos) para
representar los sistemas en estudio. Puesto que uno de los objetivos para los cuales se van a
desarrollar los modelos es su uso en computadores (entornos de simulacin digital), es necesario
que los modelos formalicen el conocimiento que se tiene del sistema de modo conciso, sin
ambigedades (interpretacin nica), y que puedan ser procesados por un ordenador. Estas
caractersticas determinan el uso de modelos simblicos matemticos como herramienta para
representar la dinmica de cualquier sistema en un entorno de simulacin digital. Los modelos
simblicos matemticos mapean las relaciones existentes entre las propiedades fsicas del sistema
que se pretende modelar en las correspondientes estructuras matemticas. Teniendo en cuenta que
uno de los objetivos es encontrar una representacin lo ms simple posible de las dinmicas de
inters, el tipo de formalizacin matemtica que se utilice va a depender de las caractersticas
intrnsecas de las dinmicas que se quieran representar [Gua09].
Modelo conceptual: Simplificaciones y suposiciones sobre los fenmenos fsicos reales. Al
modelar la realidad hay que buscar un equilibrio entre la simplicidad y la correccin. Un modelo
demasiado simple puede deshacerse de caractersticas importantes que alejen al modelo abstracto
de su referente en el mundo real, en contraposicin, un modelo muy correcto, que no omita ningn
detalle de la realidad (muchos de ellos irrelevantes), puede ser tan complejo y costoso de
implementar (incluso imposible) que no nos va a ayudar en nuestros propsitos.
La representacin ms usual de estos modelos es mediante una expresin matemtica basada
en balances de energa, materia, momento, leyes de equilibrio Una vez obtenida la expresin es
posible ajustar sus parmetros en base a datos empricos sobre el elemento real.
El modelado no es algo trivial, exige un conocimiento extremo del proceso a tratar, as como
cierta experiencia y un tiempo de desarrollo bastante elevado.
171
Apndice E
Contenido del CD
El CD adjunto al presente texto contiene todo el trabajo realizado, as como documentacin y
artculos de referencia de inters. La estructura queda reflejada en el siguiente rbol de directorios.
CD
memoria
memoria.pdf: el presente texto en formato electrnico.
bibliografia: copias electrnicas de varios elementos referenciados en la

bibliografa, se han nombrado con el mismo formato de nombre que vemos en la
memoria.
codigo
ficheros_externos: ficheros aadidos o modificados durante el desarrollo del

proyecto. Para poder utilizarlos en posteriores trabajos, ser necesario aadir o
sobreescribir los ya existentes en la herramienta OPNET.
control_predictivo.ex.cpp
control_predictivo.h
ip_qos_support.ex.c
oms_qm.ex.c
oms_qm.h
modelos_procesos: Son los modelos de procesos modificados listados en

formato .c.
ip_output_iface.pr.c
qos_attribute_definer.pr.c
experimentos: Varios proyectos de inters sobre los que realizar simulaciones.
experimentos varios
herramienta: Ejecutables para instalar la herramienta OPNET 16. Tras su instalacin

ser necesario disponer de una licencia vlida para poder usar el programa.
173
Apndice F
Acrnimos y Definiciones
ACRNIMOS Y ABREVIATURAS
ACK: Acknowlement (reconcomiento)
AQM: Active Queue Management
ARP: Address Resolution Protocol
CPU: Central Proccesing Unit
ECN: Explicit Congestion Notification
FB: Function Block (OPNET)
FTP: File Transfer Protocol
GPC: Generalized Predictive Control
HB: Header Block (OPNET)
HTTP: Hypertext Transfer Protocol
ICMP: Internet Control Message Protocol
IP: Internet Protocol
KP: Kernel Procedures
LAN: Local Area Network
MBPC: Model Based Predictive Control
MIMO: Multiple Input Multiple Output
MPC: Model Predictive Control
MTU: Unidad Mxima de Transferencia
OPNET: OPtimized Network Engineering

Tool.
OSI: Open System Interconnection
PID: Proportional Integral Derivative
QP: Queue-Processor (OPNET)
QoS: Quality of Service
RED: Random Early Detection
RFC: Request For Comments
RTO: Retransmission TimeOut
RTT: Round Trip Time
SISO: Single Input Single Output
SMTP: Simple Mail Transfer Protocol
SV: State Variables (OPNET)
TCP: Transmission Control Protocol
ToS: Type of Service
TV: Termporary Variables (OPNET)
UML: Unified Modeling Language
WAN: Wide extension Area Network

DEFINICIONES
Ecuacin diofntica: Se llama ecuacin

diofntica a cualquier ecuacin algebraica,
generalmente de varias variables, planteada
sobre el conjunto de los nmeros
enteros
o los nmeros naturales , es
decir, se trata de ecuaciones cuyas
soluciones son nmeros enteros.
Ethernet: Es un estndar de redes de rea

local para computadores con acceso al
medio
por
contienda CSMA/CD.
CSMA/CD (Acceso Mltiple por Deteccin
de Portadora con Deteccin de Colisiones),
es una tcnica usada en redes Ethernet para
mejorar sus prestaciones. El nombre viene
del concepto fsico de ether. Ethernet
define las caractersticas de cableado y
sealizacin de nivel fsico y los formatos
de tramas de datos del nivel de enlace de
datos del modelo OSI.
Gateway: Se trata de un equipo para

interconectar redes.
Jitter: El jitter es un efecto de las redes de

datos no orientadas a conexin y basadas
en conmutacin de paquetes. Como la
informacin se discretiza en paquetes cada
uno de los paquetes puede seguir una ruta
distinta para llegar al destino. El jitter se
define tcnicamente como la variacin en el
tiempo en la llegada de los paquetes,
causada por congestin de red, perdida de
sincronizacin o por las diferentes rutas
seguidas por los paquetes para llegar al
destino.
Macro de C: Se aplica en el mundo de las

telecomunicaciones y redes informticas al
tiempo que tarda un paquete enviado desde
un emisor en volver a este mismo emisor
habiendo pasado por el receptor de destino.
Round Trip Time: Se aplica en el mundo

de las telecomunicaciones y redes
informticas al tiempo que tarda
un paquete enviado desde un emisor en
volver a este mismo emisor habiendo
pasado por el receptor de destino.
175
Router: Un router es un dispositivo que

proporciona conectividad a nivel de red o
nivel tres en el modelo OSI. Su funcin
principal consiste en enviar o encaminar
paquetes de datos de una red a otra, es
decir, interconectar subredes, entendiendo
por subred un conjunto de mquinas IP que
se pueden comunicar sin la intervencin de
un router (mediante bridges), y que por
tanto tienen prefijos de red distintos.
Ruido blanco: El ruido blanco o sonido

blanco es una seal aleatoria que se
caracteriza por el hecho de que sus valores
de seal en dos tiempos diferentes no
guardan correlacin estadstica.
Como
consecuencia de ello, su densidad espectral
de potencia (PSD, siglas en ingls de power
spectral density) es una constante, es decir,
su grfica es plana. Esto significa que la
seal contiene todas las frecuencias y todas
ellas muestran la misma potencia.
Ruido coloreado: Aunque el ruido es una

seal aleatoria, puede tener caractersticas y
propiedades
estadsticas.
La densidad
espectral (potencia y
distribucin
en
el espectro de frecuencia), es una de esas
propiedades, que pueden ser utilizadas para
distinguir los diferentes tipos de ruido. Esta
clasificacin por densidad espectral se da la
terminologa, con el nombre de diferentes
tipos diferentes colores, y es comn en
diferentes disciplinas, donde el ruido es un
factor importante
Transformada de Laplace: Es la ms
conocida y utilizada de las transformadas
integrales. Se ha mostrado de gran utilidad
a la hora de resolver multitud de problemas
de la ciencia y tecnologa, aplicndose de
manera efectiva al estudio de temas
fundamentales como teora de vibraciones,
circuitos electrnicos, bsqueda de
soluciones de ecuaciones en derivadas
parciales
Workstation: En informtica una estacin

de trabajo (en ingls workstation) es un
microordenador de
altas
prestaciones
destinado para trabajo tcnico o cientfico.
176
Bibliografa
[Alv10]
lvarez Cuesta, V., (2010), Algoritmos AQM basados en teora de control en

OPNET
[Ang11]
Angulo Garca, F., (2011), Modelado y control de una columna de destilacin

binaria
[ASB]
Alvarez, T., Salim, A., Bolajraf, M., Congestion control of TCP/AQM networks
using predictive control and on-line linearized models
[ASM]
Alvarez, T., Salim, A., Maestre, J.M., A control theoretical approach to

congestion control of TCP/AQM networks
[Ate07]
Atelin, P., (2007), TCP/IP y protocolos de internet, Eni
[Blu]
Bluebit
Software,
Bluebit,
<http://bluebit.gr/matrix-calculator>
[CA04]
Class, P., Altadill Izura, P. X., (2004), Tutorial de C++
[CB04]
Camacho, E.F., Bordons, C., (2004), Control Predictivo: pasado, presente y

futuro
[CEB10]
Cerf, V.G., Erustes Camps, B., Briz Velasco, L., (2010), Antologa de Vinton
G. Cerf
[GT06]
Gonzlez T., J.P., Toro Garca, N., (2006), Control predictivo generalizado
implementado a dos tanques acoplados
[Gua09]
Guasch Petit, A., (2009), Modelado y simulacin. Aplicacin a procesos

logsticos de fabricacin y servicios.
[HYH08]
Hong, Y., Yang, O.W.W., Huang, C., (2008), Self-Tuning PI TCP Flow
Controller for AQM Routers With Interval Gain and Phase Margin Assignment
[LPPC02]
Lim, H., Park, K.J., Park, E.C., Choi, C.H., (2002), Proportional-Integral
Active Queue Management with an Anti-Windup Compensator
[MBG04]
Moreno, L., Balaguer Bernaldo de Quirs, C., Garrido Bulln, S, (2004),

Ingeniera de Control: Modelado, Anlisis y Control de Sistemas Dinmicos
[MR98]
Morari, M., Ricker, N.L., (1998), Model Predictive Control Toolbox for use
with MATLAB, The Math Works Inc.
[Nic10]
Nicolas Fernndez, Lourdes, (2010), Control de Congestin con OPNET
[Nor]
Normey Rico, J.E., Control Predictivo basado en modelo
[OPT09]
OPNET Technologies,
Documentation
[RJB05]
Rumbaugh, J.; Jacobson, I. y Booch, G., (2005), El Lenguaje Unificado de

Modelado, (2 Edicin), Addison-Wesley
[RRQ03]
Ryu, S., Rump, C., Qiao, C., (2003), Advances in Internet Congestion Control
[SKCZ]
Sun, J., Chany, S., Koy, K., Cheny, G., Zukermanz, M., Neuron PID: A Robust
AQM Scheme
[SP03]
Svensson, T., Popescu, A., (2003), Development of laboratory exercises based
Inc.,
ltimo
(2009)
acceso:
OPNET Modeler
04/Julio/2012,
16.0
Product
on OPNET Modeler
[SV09]
Sam Fadali, M., Visio, A., (2009), Digital Control Engineering: Analysis and
Design
[Tad]
Tadeo Rico, F.J., Introduccin al control predictivo
[Tan03]
Tanenbaum, A., (2003), Redes de computadoras, (4 edicin), Pearson
[Vaq]
Vaquero Lpez, J., PCSim: Herramienta interactiva de control predictivo en la

enseanza de la automtica
[VB]
vBulletin, edaboard.com, ltimo acceso: 09/Septiembre/2009,

<http://www.edaboard.com/thread188067.html>
[WF]
Inc.Wikimedia Foundation, Wikipedia, ltimo acceso: 23/Agosto/2012,

<http://es.wikipedia.org/>
[YL]
Yang, D.R., Lee, J.H., Other process control applet series, Ultimo acceso:
13/Junio/2012, <http://cheric.org/education/control/Start/AppletsPC.html>
[YSCS]
Yu, L., Shi, Z., Chen, K., Shu, Y., Designing Robust PID Congestion
Controller Supporting TCP Flows Based on H Optimal Control Theory
[ZA]
Zheng, B., Atiquzzaman, M., Study of Active Queue Management Using

OPNET
[Zub10]
Zubizarreta, A., (2010), Control Predictivo

Memoria Pro Yec To Final

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Memoria Pro Yec To Final

Enviado por

Direitos autorais:

Formatos disponíveis

Universidad de Valladolid

Tcnicas AQM basadas en control predictivo

Alumno: Eduardo Hernndez Ramos

En memoria de mi abuela Felisa

CAPTULO II. INTRODUCCIN A LAS REDES DE

CAPTULO III. EL PROBLEMA DEL CONTROL DE LA

CAPTULO IV. AQM EN OPNET......................................................29

4.2.1 Modelo de nodos del elemento QoS..................................................................................29

CAPTULO V. EL CONTROL PID CLSICO.....................................59

CAPTULO VI. EL CONTROL PREDICTIVO BASADO EN

CAPTULO VII. SIMULACIONES Y RESULTADOS........................97

7.1.4 Variaciones en el valor de .............................................................................................104

CAPTULO VIII. PRUEBAS Y PROBLEMAS..................................123

CAPTULO IX. CONCLUSIONES Y TRABAJO FUTURO.............127

APNDICE A. LA HERRAMIENTA OPNET.................................129

APNDICE B. ADICIN DE ATRIBUTOS Y ESTADSTICAS.....153

Tcnicas AQM basadas en Control Predictivo

APNDICE C. GUA DE INSTALACIN DE OPNET................159

APNDICE D. PRINCIPIOS BSICOS DEL CONTROL DIGITAL

APNDICE E. CONTENIDO DEL CD...............................................173

Figura 1. 1 Control de plantas de diferente naturaleza

Tcnicas AQM basadas en Control Predictivo

Nivel del depsito

Probabilidad descarte paquete

1. 2 Propsito del proyecto

Captulo 1. Captulo introductorio. Se ofrece una introduccin al texto, as como una

Figura 1. 2 Diagrama de Gantt de la realizacin del proyecto

Tcnicas AQM basadas en Control Predictivo

Figura 2. 1 Simplificacin de una topologa WAN

II. INTRODUCCIN A LAS REDES DE ORDENADORES

Figura 2. 2 Niveles OSI y relaciones host-router

Tcnicas AQM basadas en Control Predictivo

La capa de transporte tambin determina qu tipo de servicio proporcionar a la capa de sesin y,

Capa de sesin: Permite a los usuarios de mquinas diferentes establecer "conversacin".

Figura 2. 3 Equivalencias de la pila OSI con la pila TCP/IP

II. INTRODUCCIN A LAS REDES DE ORDENADORES

Figura 2. 4 Ejemplo de protocolos llevados a cabo en cada una de las capas

Es un protocolo no orientado a conexin.

En cuanto al encaminamiento, podemos tener dos tipos:

2.3.2 Protocolo TCP

Tcnicas AQM basadas en Control Predictivo

Figura 2. 5 Niveles TCP/IP y relaciones host-router

A continuacin listamos las caractersticas principales de TCP:

Fiabilidad en el transporte de la informacin. Est orientado al flujo de octetos (octect

II. INTRODUCCIN A LAS REDES DE ORDENADORES

Algunos de los parmetros ms importantes en TCP se describen a continuacin:

Tamao de ventana: Mxima cantidad de

Figura 2. 6 Transaccin extremo a

Figura 3. 1 Grfica de desempeo de la red ante casos de congestin

3. 2 Principios generales del control de la congestin

Monitorizar el sistema para detectar cundo y dnde ocurren las congestiones.

III. EL PROBLEMA DEL CONTROL DE LA CONGESTIN

3. 3 Mtodos de prevencin de congestin

Circuitos virtuales vs. datagramas en la subred

Tcnicas AQM basadas en Control Predictivo

Poltica de descarte de paquetes

3. 4 Primeras decisiones para el control de la congestin

3. 5 Mtodos extremos para controlar la congestin

III. EL PROBLEMA DEL CONTROL DE LA CONGESTIN

3.5.1 Algoritmo Drop Tail

3.5.2 Algoritmo RED

Tcnicas AQM basadas en Control Predictivo

responden a la prdida de paquetes reduciendo su tasa de transmisin. En las redes inalmbricas,

/Obtener el nombre del perfil FIFO/