<?xml version="1.0" encoding="ISO-8859-1"?><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<front>
<journal-meta>
<journal-id>1815-5928</journal-id>
<journal-title><![CDATA[Ingeniería Electrónica, Automática y Comunicaciones]]></journal-title>
<abbrev-journal-title><![CDATA[EAC]]></abbrev-journal-title>
<issn>1815-5928</issn>
<publisher>
<publisher-name><![CDATA[Universidad Tecnológica de La Habana José Antonio Echeverría, Cujae]]></publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id>S1815-59282012000300008</article-id>
<title-group>
<article-title xml:lang="es"><![CDATA[Sistema de balance de carga para redes malladas inalámbricas multi-interfaces]]></article-title>
<article-title xml:lang="en"><![CDATA[A system for load balancing in multi-interface wireless mesh networks]]></article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Köbel]]></surname>
<given-names><![CDATA[Christian]]></given-names>
</name>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Baluja García]]></surname>
<given-names><![CDATA[Walter]]></given-names>
</name>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Habermann]]></surname>
<given-names><![CDATA[Joachim]]></given-names>
</name>
</contrib>
</contrib-group>
<aff id="A01">
<institution><![CDATA[,Instituto Superior Politécnico José Antonio Echeverría (ISPJAE) Departamento de Telecomunicaciones ]]></institution>
<addr-line><![CDATA[La Habana ]]></addr-line>
<country>Cuba</country>
</aff>
<aff id="A02">
<institution><![CDATA[,Instituto Superior Politécnico José Antonio Echeverría (ISPJAE) Rectorado ]]></institution>
<addr-line><![CDATA[La Habana ]]></addr-line>
<country>Cuba,</country>
</aff>
<aff id="A03">
<institution><![CDATA[,TH Mittelhessen University of Applied Sciences Electrical Engineering & Mechatronics Department for ICT]]></institution>
<addr-line><![CDATA[Friedberg ]]></addr-line>
<country>Germany</country>
</aff>
<pub-date pub-type="pub">
<day>00</day>
<month>12</month>
<year>2012</year>
</pub-date>
<pub-date pub-type="epub">
<day>00</day>
<month>12</month>
<year>2012</year>
</pub-date>
<volume>33</volume>
<numero>3</numero>
<fpage>85</fpage>
<lpage>98</lpage>
<copyright-statement/>
<copyright-year/>
<self-uri xlink:href="http://scielo.sld.cu/scielo.php?script=sci_arttext&amp;pid=S1815-59282012000300008&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://scielo.sld.cu/scielo.php?script=sci_abstract&amp;pid=S1815-59282012000300008&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://scielo.sld.cu/scielo.php?script=sci_pdf&amp;pid=S1815-59282012000300008&amp;lng=en&amp;nrm=iso"></self-uri><abstract abstract-type="short" xml:lang="es"><p><![CDATA[Las redes malladas inalámbricas, basadas en las normas 802.11, fueron desarrolladas inicialmente con propósitos militares pero actualmente se han desplegado ampliamente en redes de usuario final e industriales. Desde hace más de diez años se realizan investigaciones en esta área. Sin embargo, los temas de enrutamiento y de calidad de servicio (QoS) no están agotados, sobre todo tomando en consideración que el tamaño de las nubes y backbones mesh ha crecido considerablemente. En estas condiciones puede ser muy beneficioso introducir nodos con múltiples interfaces inalámbricas, lo cual no representa grandes costos, por lo que el tema ha atraído el foco de atención de múltiples investigaciones en la actualidad. Esta posibilidad introduce entonces la necesidad de emplear métodos más complejos para estas redes, como el balance de carga y la asignación de canales, incluyendo la posible combinación de interfaces en cada nodo de la red. El presente artículo propone un sistema para implementar los aspectos mencionados arriba entiéndase, proveer diversos modos de balance de carga, considerando la posibilidad de asignar canales y de combinarlos en la comunicación entre nodos mesh. Esto redunda en una gestión mucho más eficiente de los recursos de las redes malladas inalámbricas. Se describen los componentes y funcionalidades más novedosos del sistema propuesto, los cuales están distribuidos en cada nodo, y se ubican en una capa intermedia entre la de enlace y la de red. Por último se presentan los resultados de las simulaciones del sistema propuesto en escenarios concretos.]]></p></abstract>
<abstract abstract-type="short" xml:lang="en"><p><![CDATA[Wireless mesh networks based on IEEE 802.11 have been initially designed for military purposes, but recently have been deployed widely in customer-based and industrial networks. For more than 10 years wireless mesh networks are in the focus of investigation. Still, topics on routing and quality of service (QoS) are constantly investigated and improved, especially since current wireless mesh hardware allows bigger and highly scalable mesh clouds (e.g., backbone networks). Independently of the application of mesh technology, the deployment of multi-interface nodes offers advantages in terms of capacity and network efficiency. Decreasing prices for wireless hardware benefit this trend. But multi-interface mesh networking generally comes with the cost of a higher system complexity. Especially load balancing and channel assignment have to be carefully adapted. In the presented paper a system which implements the above mentioned aspects is proposed. It includes diverse load balancing modes, taking the possibility of channel assignment algorithms into account. Included interface bundling management results in a more efficient usage of resources. Regarding components and their functionalities are described. An evaluation of the introduced system is provided in form of measurements in different mesh scenarios.]]></p></abstract>
<kwd-group>
<kwd lng="es"><![CDATA[asignación de canales]]></kwd>
<kwd lng="es"><![CDATA[balance de carga]]></kwd>
<kwd lng="es"><![CDATA[combinación de canales]]></kwd>
<kwd lng="es"><![CDATA[multi salto]]></kwd>
<kwd lng="es"><![CDATA[nodos multi interfaces]]></kwd>
<kwd lng="es"><![CDATA[redes ad-hoc]]></kwd>
<kwd lng="es"><![CDATA[redes malladas inalámbricas]]></kwd>
<kwd lng="en"><![CDATA[channel bundling]]></kwd>
<kwd lng="en"><![CDATA[channel assignment]]></kwd>
<kwd lng="en"><![CDATA[load balancing]]></kwd>
<kwd lng="en"><![CDATA[multihop]]></kwd>
<kwd lng="en"><![CDATA[multinterfaces]]></kwd>
<kwd lng="en"><![CDATA[ad-hoc networks]]></kwd>
<kwd lng="en"><![CDATA[wireless mesh networks (WMN)]]></kwd>
</kwd-group>
</article-meta>
</front><body><![CDATA[ <div align="right"><font size="2" face="Verdana"> </font> </div>    <P align="right"><strong><font size="2" face="Verdana">ARTICULO  ORIGINAL </font> </strong></P>    <P align="right">&nbsp;</P>    <P align="left"><font size="4" face="Verdana"><B>Sistema  de balance de carga para redes malladas inal&aacute;mbricas multi-interfaces </B></font></P>    <P align="left">&nbsp;</P>    <P align="left"><font size="2"><font size="3" face="Verdana"><B>A  system for load balancing in multi-interface wireless mesh networks</B></font>  </font></P>    <P>&nbsp;</P>    <P>&nbsp;</P>    <P><font size="2"><b><font face="Verdana">Ing.Christian  K&ouml;bel<sup>1</sup>, Dr.Walter Baluja Garc&iacute;a<sup >2</sup>, Dr. Joachim  Habermann<sup>3</sup> </font> </b> </font></P>    <P><font size="2" face="Verdana">  1. Departamento de Telecomunicaciones, Instituto Superior Polit&eacute;cnico Jos&eacute;  Antonio Echeverr&iacute;a (ISPJAE), CP 11500 Marianao, La Habana, Cuba, <U><FONT  COLOR="#0000ff"><a href="mailto:christian.koebel@iem.thm.de">Christian.Koebel@iem.thm.de</a>    ]]></body>
<body><![CDATA[<br>  </FONT></U></font><font size="2" face="Verdana">2. Rectorado, Instituto Superior  Polit&eacute;cnico Jos&eacute; Antonio Echeverr&iacute;a (ISPJAE), CP 11500 Marianao,  La Habana, Cuba, <U><FONT  COLOR="#0000ff"><a href="mailto:walter@tesla.cujae.edu.cu">Walter@Tesla.CUJAE.edu.cu</a></FONT></U>      <br> 3. Department for ICT, Electrical Engineering &amp; Mechatronics, TH Mittelhessen  University of Applied Sciences, D-61169 Friedberg, Germany, <U><FONT COLOR="#0000ff"><a href="mailto:joachim.habermann@iem.thm.de">Joachim.Habermann@iem.thm.de</a></FONT></U></font></P>    <P>&nbsp;</P>    <P>&nbsp;</P><hr>      <P><font size="2"><b><font face="Verdana">RESUMEN</font></b></font></P>    <P><font size="2" face="Verdana">Las  redes malladas inal&aacute;mbricas, basadas en las normas 802.11, fueron desarrolladas  inicialmente con prop&oacute;sitos militares pero actualmente se han desplegado  ampliamente en redes de usuario final e industriales. Desde hace m&aacute;s de  diez a&ntilde;os se realizan investigaciones en esta &aacute;rea. Sin embargo,  los temas de enrutamiento y de calidad de servicio (QoS) no est&aacute;n agotados,  sobre todo tomando en consideraci&oacute;n que el tama&ntilde;o de las nubes y  backbones mesh ha crecido considerablemente. En estas condiciones puede ser muy  beneficioso introducir nodos con m&uacute;ltiples interfaces inal&aacute;mbricas,  lo cual no representa grandes costos, por lo que el tema ha atra&iacute;do el  foco de atenci&oacute;n de m&uacute;ltiples investigaciones en la actualidad.  Esta posibilidad introduce entonces la necesidad de emplear m&eacute;todos m&aacute;s  complejos para estas redes, como el balance de carga y la asignaci&oacute;n de  canales, incluyendo la posible combinaci&oacute;n de interfaces en cada nodo de  la red. El presente art&iacute;culo propone un sistema para implementar los aspectos  mencionados arriba enti&eacute;ndase, proveer diversos modos de balance de carga,  considerando la posibilidad de asignar canales y de combinarlos en la comunicaci&oacute;n  entre nodos mesh. Esto redunda en una gesti&oacute;n mucho m&aacute;s eficiente  de los recursos de las redes malladas inal&aacute;mbricas. Se describen los componentes  y funcionalidades m&aacute;s novedosos del sistema propuesto, los cuales est&aacute;n  distribuidos en cada nodo, y se ubican en una capa intermedia entre la de enlace  y la de red. Por &uacute;ltimo se presentan los resultados de las simulaciones  del sistema propuesto en escenarios concretos. </font></P>    <P><font size="2" face="Verdana"><B>Palabras  claves</B>: asignaci&oacute;n de canales, balance de carga, combinaci&oacute;n  de canales, multi salto, nodos multi interfaces, redes ad-hoc, redes malladas  inal&aacute;mbricas. </font>    <br> </P><hr> <font size="2" face="Verdana"><B>ABSTRACT</B></font>      <P> <font size="2" face="Verdana">Wireless mesh networks based on IEEE 802.11  have been initially designed for military purposes, but recently have been deployed  widely in customer-based and industrial networks. For more than 10 years wireless  mesh networks are in the focus of investigation. Still, topics on routing and  quality of service (QoS) are constantly investigated and improved, especially  since current wireless mesh hardware allows bigger and highly scalable mesh clouds  (e.g., backbone networks). Independently of the application of mesh technology,  the deployment of multi-interface nodes offers advantages in terms of capacity  and network efficiency. Decreasing prices for wireless hardware benefit this trend.  But multi-interface mesh networking generally comes with the cost of a higher  system complexity. Especially load balancing and channel assignment have to be  carefully adapted. In the presented paper a system which implements the above  mentioned aspects is proposed. It includes diverse load balancing modes, taking  the possibility of channel assignment algorithms into account. Included interface  bundling management results in a more efficient usage of resources. Regarding  components and their functionalities are described. An evaluation of the introduced  system is provided in form of measurements in different mesh scenarios.</font></P>    <P><font size="2"><font face="Verdana"><B>Key  words: </B>channel bundling, channel assignment, load balancing, multihop, multinterfaces,  ad-hoc networks, wireless mesh networks (WMN). </font> </font>    ]]></body>
<body><![CDATA[<br> </P><hr>     <P>&nbsp;</P>    <P>&nbsp;</P>    <P><font size="3" face="Verdana"><B>INTRODUCCION</B>  </font></P>    <P><font size="2" face="Verdana">Las redes inal&aacute;mbricas <I>ad-hoc</I>  utilizan interfaces de red (<I>Wireless Network Interface Cards</I>, WNIC) IEEE  802.11 empleadas habitualmente en redes inal&aacute;mbricas locales (<I>Wireless  Local Area Network</I>, WLAN). Se caracterizan por su movilidad y el no empleo  de puntos de acceso, pues permiten la comunicaci&oacute;n directa entre nodos  inal&aacute;mbricos, entre otros aspectos que le garantizan flexibilidad y escalabilidad  al sistema. </font></P>    <P><font size="2" face="Verdana">Las redes malladas inal&aacute;mbricas  son un subconjunto dentro de las redes <I>ad-hoc</I>, caracterizadas por la poca  o ninguna movilidad de sus nodos, y los potentes recursos de hardware en cuanto  a procesamiento, memoria y energ&iacute;a. Los nodos t&iacute;picos de estas redes  son laptops, computadoras personales entre otros, lo cual puede incluir dispositivos  propietarios como nodos orientados a la conformaci&oacute;n de <I>backbones</I>  inal&aacute;mbricos. El hardware m&aacute;s moderno permite incluir esquemas m&aacute;s  sofisticados de enrutamiento y de gesti&oacute;n de tr&aacute;fico en los nodos.  </font></P>    <P><font size="2" face="Verdana">Con respecto a los roles, funcionalidades  y limitaciones de los nodos de una red mallada existen m&uacute;ltiples definiciones  en la bibliograf&iacute;a. La <a href="/img/revistas/eac/v33n3/t0108312.jpg">Tabla  1</a> ofrece un acercamiento a este tema. </font></P>    
<P align="left"><font size="2" face="Verdana">Las  redes malladas inal&aacute;mbricas basadas en nodos de una sola interface permiten  implementar un gran n&uacute;mero de escenarios. En t&eacute;rminos de la introducci&oacute;n  de la tecnolog&iacute;a <I>mesh</I> y del posible papel de sus nodos en una red  de telecomunicaciones de &aacute;rea amplia, Akyildiz et. al. [1] propone una  clasificaci&oacute;n general. Los autores distinguen entre una red mallada h&iacute;brida  (<I>Hybrid WMN) </I>y una red con arquitectura de infraestructura m&aacute;s <I>backbone.  </I>En el primer caso los nodos est&aacute;n presentes en los niveles de <I>backbone</I>  y de clientes. En el segundo el <I>backbone</I> consiste en un grupo de nodos  <I>mesh</I> (routers) y su nivel de jerarqu&iacute;a est&aacute; separado del  nivel de los clientes. Los clientes simplemente se conectan a puntos de acceso  locales que permiten la conexi&oacute;n de entrada al <I>backbone</I>. </font></P>    <P><font size="2" face="Verdana">En  el presente trabajo los nodos se agrupan en un &uacute;nico nivel jer&aacute;rquico  que puede representar un <I>backbone</I> o una red cliente <I>peer-to-peer</I>.  Los tipos de nodos que se utilizan est&aacute;n marcados en naranja en la <A HREF="/img/revistas/eac/v33n3/t0108312.jpg">Tabla  1</A>. Los Router de borde y los Gateway cumplen el mismo papel en este caso,  atendiendo a su relevancia como pr&oacute;ximos saltos de la red. </font></P>    
<P><font size="2" face="Verdana">Las  redes malladas tienen numerosas aplicaciones. En escenarios de recuperaci&oacute;n  de desastres, militares o de comunicaci&oacute;n de autoridades p&uacute;blicas  (bomberos, polic&iacute;a, defensa civil), entre otros, se requiere una infraestructura  muy robusta que ofrezca confiabilidad. Por otra parte, en aplicaciones de usuarios,  frecuentemente se intercambia recursos de multimedia. Ambos sistemas deben considerar  la introducci&oacute;n de esquemas de calidad de servicio (QoS). </font></P>    ]]></body>
<body><![CDATA[<P><font size="2" face="Verdana">Una  red de acceso metropolitana (<I>backbone</I>) debe incluir caracter&iacute;sticas  de los dos casos mencionados arriba. Esta diversidad de topolog&iacute;as, prop&oacute;sitos  y aplicaciones ha derivado en varios protocolos de enrutamiento para redes malladas  y/o <I>ad-hoc</I>. Sin embargo, en la capa de enlace se mantiene el hardware compatible  con WLAN 802.11. </font></P>    <P><font size="2" face="Verdana">Por otra parte, a  diferencia de los nodos de una &uacute;nica interface, el equipamiento multi interface  permite trabajar aspectos como la gesti&oacute;n de reservaci&oacute;n-asignaci&oacute;n  de canales y el balance de carga, con el objetivo de satisfacer los requerimientos  de los diferentes tipos de redes malladas. A partir de la necesidad de utilizar  m&uacute;ltiples interfaces WLAN en un nodo y de soportar diversas aplicaciones  de las redes malladas, el presente trabajo introduce modos predefinidos para optimizar  el balance de carga (LB-<I>modes</I>) buscando una mejor calidad del servicio.  Cada LB-<I>mode</I> selecciona la interface (WNIC) que ser&aacute; utilizada para  transmitir el siguiente paquete (en el caso de que estuvieran disponibles varias  interfaces para la comunicaci&oacute;n con el pr&oacute;ximo salto). Esta es una  decisi&oacute;n que se toma para cada paquete, en cada comunicaci&oacute;n <I>unicast</I>.  Cuando se trata de una comunicaci&oacute;n por difusi&oacute;n (<I>broadcast</I>)  se transmitir&aacute; una copia del paquete por cada interface. </font></P>    <P><font size="2" face="Verdana">Adicionalmente,  se concibe el empleo de un canal de control, para el intercambio de este tipo  de paquetes de forma diferenciada del tr&aacute;fico de datos. Este canal pudiera  ser empleado para el intercambio de informaci&oacute;n sobre el trabajo y configuraci&oacute;n  de los LB-<I>modes</I>.</font></P>    <P>&nbsp;</P>    <P><font size="3" face="Verdana"><B>TRABAJO  RELACIONADO</B> </font></P>    <P><font size="2" face="Verdana">La selecci&oacute;n  inicial de los modos de balance de carga fue inspirada por el <I>Linux Ethernet  Bonding Driver</I> [2], que ya existe en las redes cableadas sobre sistemas Linux.  Haciendo modificaciones en el <I>kernel</I> se hace trabajar varias tarjetas Ethernet  como si fuera una sola. Una funcionalidad importante del <I>Ethernet Bonding Driver</I>  es la gesti&oacute;n de     <BR> las direcciones IP y MAC de las tarjetas. Dentro  del grupo de interfaces combinadas se elige una sola direcci&oacute;n MAC e IP.  As&iacute; se puede identificar un host en la red a trav&eacute;s de una sola  direcci&oacute;n en las capas de red y de enlace, lo cual reduce la complejidad  del enrutamiento entre otros aspectos. El sistema presentado en este trabajo aplica  un m&eacute;todo similar para las redes malladas inal&aacute;mbricas, de forma  que para direccionar un nodo, se eligen las direcciones IP/MAC de su primera interface.  </font></P>    <P><font size="2" face="Verdana">Kim et. al. [3] han desarrollado el  framework MIMC-SIM, que es un sistema gen&eacute;rico y flexible para simular  redes malladas con nodos multi interfaces y con acceso a m&uacute;ltiples canales  a la vez. De forma similar al sistema introducido en este articulo, aquel grupo  ha dise&ntilde;ado una capa intermedia entre las capas de enlace y de red, que  controla la gesti&oacute;n de los canales en las interfaces. La estructura de  su sistema no se enfoca en el balance de carga, sino en proveer un framework para  implementar y evaluar diferentes protocolos de asignaci&oacute;n de canales (AC).  </font></P>    <P><font size="2" face="Verdana">Kim et. al. analizan diferentes aspectos  de los algoritmos AC. MIMC-SIM da soporte fundamentalmente a dos tipos de algoritmos.  El primero es <I>node-based</I>. Aqu&iacute; cada nodo recibe un grupo de canales  asignados del modulo AC para comunicarse con sus vecinos. Ese m&eacute;todo se  aplica para el sistema presentado en este art&iacute;culo. Antes de distribuir  tr&aacute;fico a trav&eacute;s las interfaces combinadas, se determina el canal  de cada interface a partir de una tabla, que debe ser creada por un modulo de  AC externo. El segundo tipo de algoritmo AC es <I>link-based</I>. En este caso  se distingue entre los tr&aacute;ficos de entrada y de salida para la asignaci&oacute;n  de canales con cada vecino. </font></P>    <P><font size="2" face="Verdana">Este grupo  de trabajo tambi&eacute;n identifica algunos problemas b&aacute;sicos del simulador  OMNeT++ [4] en combinaci&oacute;n con INETMANET [5]. El INETMANET soporta el uso  de m&uacute;ltiples interfaces por nodo, pero con la gran limitaci&oacute;n de  que se pueden comunicar por un solo canal. Tambi&eacute;n, INETMANET permite que  los canales ortogonales que est&eacute;n siendo utilizados no causen interferencia  entre s&iacute;. Sin embargo, en ciertos casos existe un comportamiento indeseable  cuando dos nodos dentro del mismo rango de interferencia y que usan dos tecnolog&iacute;as  de acceso diferentes en el mismo canal f&iacute;sico (por ejemplo, IEEE 802.11  <I>Wireless LAN</I> y IEEE 802.15.4 ZigBee), no producen interferencia al transmitir  simult&aacute;neamente. Rectificar este mal funcionamiento es un logro importante  del grupo de Kim et. al. </font></P>    ]]></body>
<body><![CDATA[<P>&nbsp;</P>    <P><font size="3" face="Verdana"><B>MODOS  MULTI PROP&Oacute;SITO DE ORDENAMIENTO DE PAQUETES</B> </font></P>    <P><font size="2" face="Verdana">En  esta secci&oacute;n se ofrece una breve descripci&oacute;n de cada modo de balance  de carga propuesto (LB-<I>modes</I>). Es importante mencionar que los modos definidos  se refieren a la distribuci&oacute;n de carga dentro de un mismo <I>bundle</I>  (grupo de canales combinados entre dos nodos que se emplean simult&aacute;neamente  para intercambiar informaci&oacute;n, permitiendo utilizar un mayor ancho de banda  [6]). Cada <I>bundle</I> puede transportar un flujo diferente de paquetes en cada  momento. </font></P>    <P><font size="2" face="Verdana">En la <a href="/img/revistas/eac/v33n3/t0208312.jpg">Tabla  2</a> se presenta un resumen de los modos de trabajo del balance de carga que  se proponen. Son aplicables para tr&aacute;fico <I>unicast</I> y <I>multicast</I>.  </font></P>    
<P><font size="2" face="Verdana"><B>Modo Round-Robin</B> </font></P>    <P><font size="2" face="Verdana">Se  aplica un mecanismo simple de Round Robin tradicional. Asume que existen un n&uacute;mero  de interfaces disponibles en un <I>bundle</I> (<I>numInterfaces</I>). Cada interface  tiene asignado un n&uacute;mero que la identifica (<I>i</I>) y que se almacena  en el arreglo <I>Available_Interface [numInterfaces]</I>. <I>Available_Interface  [n]</I> identifica la interface a utilizar, donde <I>n</I> se encuentra en el  rango entre 0 y <I>numInterfaces -1</I>. </font></P>    <P><font size="2" face="Verdana">Para  cada paquete <I>unicast</I> se asigna una interface por la cual enviarlo, <I>Available_Interface  [n]</I>. El valor <I>n </I>se incrementa luego de la transmisi&oacute;n, mientras  no exceda el valor de <I>numInterfaces</I>. De esta forma los paquetes son distribuidos  entre todas las interfaces del <I>bundle</I>. La frecuencia de conmutaci&oacute;n  (<I>fc</I>) puede ser especificada a un valor por encima de 1 paquete. Esto implica  que se transmitir&aacute;n <I>fc</I> paquetes antes de seleccionar la pr&oacute;xima  interface a utilizar dentro del <I>bundle</I>. </font></P>    <P><font size="2" face="Verdana"><B>Modo  de Control de fallos</B> </font></P>    <P><font size="2" face="Verdana">La principal  causa de p&eacute;rdida de paquetes en redes inal&aacute;mbricas (WiFi) de gran  tama&ntilde;o es la interferencia de radio en el mismo canal o en canales adyacentes  al que se utiliza para la comunicaci&oacute;n [7]. El objetivo de este modo de  trabajo es evitar este tipo de errores para un canal determinado. El procedimiento  se ejecuta de forma proactiva, antes de transmitir los datos. Se toma en consideraci&oacute;n  la cantidad de paquetes enviados (<I>num<SUB>Sent</SUB></I><SUB>)</SUB> y el n&uacute;mero  de colisiones (<I>num<SUB>Collisions</SUB></I><SUB>)</SUB> de la capa de enlace.  El valor de <I>num<SUB>Collisions</SUB> </I>se obtiene habilitando el empleo de  los paquetes ACK (<I>acknowledgements</I>) de la capa de enlace y colocando el  n&uacute;mero m&aacute;ximo de retransmisiones en 4 (valor por defecto). Se calcula  entonces el nivel de colisiones para cada interface con la siguiente <a href="eac08312.htm#e1">expresi&oacute;n</a>:  </font></P>    <P align="center"><img src="/img/revistas/eac/v33n3/e0108312.jpg" width="212" height="57">  <a name="e1"></a></P>    
]]></body>
<body><![CDATA[<P></P>    <P><font size="2" face="Verdana">Se emplean las mismas  variables que en el modo Round Robin en lo concerniente a las interfaces dentro  del <I>bundle</I>. En este caso la interface de transmisi&oacute;n no se cambia  a menos que <I>rate<SUB>Collision </SUB></I>sobrepase determinado umbral. La interface  utilizada inicialmente se denomina <I>main</I>, la cual es prefijada a un canal  determinado en cada nodo. El par&aacute;metro <I>rate<SUB>Collision</SUB></I>  es chequeado para cada paquete a procesar. Cuando el umbral es sobrepasado, se  incrementa <I>n</I> y se selecciona la siguiente interface para transmitir. En  este momento var&iacute;an los par&aacute;metros de calidad del enlace de las  capas 1 y 2 (relaci&oacute;n se&ntilde;al ruido, paquetes perdidos, paquetes con  error, nivel de retransmisiones, entre otros). </font></P>    <P><font size="2" face="Verdana">El  valor del umbral es variable, en las mediciones realizadas en este trabajo se  ha utilizado un valor de 3% [8]. </font></P>    <P><font size="2" face="Verdana"><B>Modo  Redundante</B> </font></P>    <P><font size="2" face="Verdana">Apuesta por introducir  la redundancia en la transmisi&oacute;n. Con el objetivo de incrementar la estabilidad  y la confiabilidad de la red se utilizan todos los canales disponibles. Esto implica  que se transmita el mismo paquete por todas las interfaces disponibles en el <I>bundle</I>.  En este caso los paquetes <I>unicast</I> y <I>broadcast</I> reciben un tratamiento  similar. Adem&aacute;s, no se requiere controlar los par&aacute;metros relativos  a la calidad del enlace en las interfaces o los canales, como se hace en el resto  de los modos. </font></P>    <P><font size="2" face="Verdana"><B>Modo Adaptativo</B>  </font></P>    <P><font size="2" face="Verdana">La organizaci&oacute;n o planificaci&oacute;n  del env&iacute;o de paquetes se acomoda a los dos principales protocolos de transporte  utilizados en las redes de datos: UDP y TCP (<I>Transmission Control Protocol</I>).  Puede compararse con el modo Round Robin, pero se realiza una diferencia entre  los paquetes TCP (Datos y control) y los paquetes UDP. Se aplica Round Robin para  cada grupo de canales, un grupo est&aacute; dedicado a paquetes TCP y otro a paquetes  UDP. Esa distribuci&oacute;n de canales se realiza partiendo de las estad&iacute;sticas  de los paquetes transmitidos en el nodo hasta ese momento. </font></P>    <P><font size="2" face="Verdana">Se  extrae la informaci&oacute;n del protocolo de transporte de la cabecera IP (<I>Internet  Protocol</I>) de cada paquete. En las pruebas realizadas hasta ahora se han empleado  las interfaces con identificadores pares para los paquetes TCP (<I>n mod 2 = 0)  </I>y las impares para UDP (<I>n mod 2 = 1)</I>. El resto de los paquetes se transmiten  por la interface <I>n = 1</I>. </font></P>    <P><font size="2" face="Verdana"><B>Modo  <I>Weighted-Fair-Queuing</I></B> </font></P>    <P><font size="2" face="Verdana">Se  aplica el principio de tratamiento de colas WFQ [9]. WFQ se emplea para organizar  los paquetes y asignarlos a las interfaces de acuerdo a las capacidades que tienen  para transmitir. Puede ser visto como un Round Robin avanzado, ya que toma en  cuenta la calidad de los enlaces a partir de las m&eacute;tricas de los protocolos  de enrutamiento de la red mallada. </font></P>    ]]></body>
<body><![CDATA[<P><font size="2" face="Verdana">En  este caso se trata de un <I>ancho de banda residual</I> del enlace. En comparaci&oacute;n  con el esquema de <I>Strict Priority</I>, WFQ ofrece la ventaja que no desecha  interfaces con residual peque&ntilde;o. WFQ est&aacute; dise&ntilde;ado para asignar  prioridad de env&iacute;o ante m&uacute;ltiples flujos que deben transmitirse  utilizando el mismo canal o enlace de salida. En la presente propuesta a la entrada  del sistema solo se considera el tama&ntilde;o total del paquete, no se prioriza  de acuerdo a niveles de QoS. Se asigna un peso o prioridad relacionado directamente  con los valores de los estados de los enlaces, por lo que WFQ asignar&aacute;  m&aacute;s paquetes a las interfaces de mejores caracter&iacute;sticas (menor  costo de enlace) dentro del <I>bundle</I>. Por esta raz&oacute;n, se emplea una  tabla de prioridad o peso de interface <I>Interface Weight Table, IWT)</I>. Se  asigna entonces un factor individual de peso <I>w<SUB>i</SUB> </I>(<I>0 d&#187;  w<SUB>i</SUB> d&#187; 1</I>) a cada interface, basado en la calidad de su enlace.  </font></P>    <P><font size="2" face="Verdana">Para determinar por d&oacute;nde enviar  el paquete, se introduce un contador para cada interface. Se emplea una ventana  de <I>window<SUB>WFQ</SUB> </I>paquetes. Si el costo de un enlace es m&aacute;s  bajo, el porciento de paquetes de <I>window<SUB>WFQ</SUB></I> que se debe mandar  sobre esa interface ser&aacute; m&aacute;s alto. Con cada paquete enviado a trav&eacute;s  de una interface, su contador se decrementa en uno. Si el contador llega a cero,  se emplear&aacute; la pr&oacute;xima interface para transmitir paquetes. La transmisi&oacute;n  comienza por la interface con el costo de enlace m&aacute;s bajo para cada ciclo  de paquetes <I>window<SUB>WFQ</SUB></I>. </font></P>    <P><font size="2" face="Verdana"><B>Empleo  de un Canal de Control</B> </font></P>    <P><font size="2" face="Verdana">Se ha concebido  la posibilidad de incluir una interface para un Canal de Control, lo cual resulta  relativamente f&aacute;cil en una red mallada multi interface. Cada nodo podr&aacute;  tener una interface fija designada para transmitir o recibir informaci&oacute;n  de control. Adicionalmente, se reservar&aacute; un canal para este tipo de intercambio.  Los nodos que no tengan interfaces suficientes podr&aacute;n transmitir esta informaci&oacute;n  utilizando cualquier interface, pero siempre por el mismo canal. </font></P>    <P><font size="2" face="Verdana">Este  tipo de estrategia permite separar la transmisi&oacute;n de datos y de se&ntilde;alizaci&oacute;n,  organizar el uso de informaci&oacute;n de control y facilita la incorporaci&oacute;n  de nuevos nodos a la red mallada. Puede incluir la transmisi&oacute;n de informaci&oacute;n  de control incluso de niveles superiores, identific&aacute;ndolos a partir de  la cabecera de los paquetes. </font></P>    <P>&nbsp;</P>    <P><font size="3" face="Verdana"><B>SOLUCI&Oacute;N  DE LA CAPA INTERMEDIA Y COMPONENTES MODIFICADOS</B> </font></P>    <P><font size="2" face="Verdana">Para  implementar los modos de balance de carga descritos en la secci&oacute;n anterior  se introduce la arquitectura general del sistema propuesto que se muestra en la  <A HREF="#f1">Figura 1</A>. Los componentes en gris representan elementos que  ya existen en la suite de protocolos IP / IEEE 802.11. Los componentes en verde  contienen elementos del proceso de asignaci&oacute;n de canales el cual se encuentra  en un estado preliminar [10]. La gesti&oacute;n de m&uacute;ltiples interfaces  y la distribuci&oacute;n de paquetes entre ellas est&aacute;n incluidas en los  componentes en naranja. El tr&aacute;fico o flujo de paquetes que sale del nodo  local (1 en la <a href="eac08312.htm#f1">Figura 1</a>) puede contener paquetes  <I>unicast</I>, <I>multicast</I> o <I>broadcast</I>, creado en capas superiores  o reenviados por la capa IP. El flujo de paquetes que entran al nodo local (2  en la <a href="eac08312.htm#f1">Figura 1</a>) puede contener paquetes destinados  al nodo local o paquetes que ser&aacute;n reenviados. Seguidamente se explican  los detalles de cada componente. </font></P>    <P align="center"><img src="/img/revistas/eac/v33n3/f0108312.jpg" width="514" height="579">  <a name="f1"></a></P>    
<P></P>    ]]></body>
<body><![CDATA[<P></P>    <P><b><font size="2" face="Verdana">1</font></b><font size="2"><b><font face="Verdana">.1.  Informaci&oacute;n Requerida de la Capa de Red</font></b></font></P>    <P><font size="2" face="Verdana"><U>Costo  del Enlace</U> </font></P>    <P><font size="2" face="Verdana">Cada implementaci&oacute;n  del protocolo OLSR (<I>Optimized Link State Routing</I>) [11] contiene una o varias  m&eacute;tricas para el enrutamiento de las cuales se puede extraer la informaci&oacute;n  relativa a la calidad de los enlaces. En el caso de OMNeT++ [4], el m&oacute;dulo  de software OLSR incluye la m&eacute;trica de conteo de saltos (<I>Hop Count</I>),  la <I>Expected Transmission Count</I> (ETX) y la </font></P>    <P><font size="2" face="Verdana"><I>Expected  Transmission Time</I> (ETT) [12]. Para este trabajo, se aplica la m&eacute;trica  <I>ETT<SUB>SLCA </SUB></I>[13], que est&aacute; basada en la m&eacute;trica ETT:  en lugar de incluir solamente el ancho de banda que ofrece un enlace, se calcula  la diferencia entre el ancho de banda m&aacute;ximo y el ancho de banda actual.  Como ETX y ETT, ETT<SUB>SCLA</SUB> est&aacute; basado en la comprobaci&oacute;n  activa del enlace, usando peque&ntilde;os paquetes propios para determinar el  estado de enlace. </font></P>    <P><font size="2" face="Verdana"><U>Distinci&oacute;n  de los Tipos de Nodos del Pr&oacute;ximo Salto</U> </font></P>    <P><font size="2" face="Verdana">A  trav&eacute;s del protocolo de enrutamiento OLSR, cada nodo es capaz de construir  la topolog&iacute;a completa de la red mallada inal&aacute;mbrica. La topolog&iacute;a  est&aacute; guardada en forma de informaci&oacute;n sobre la conectividad entre  nodos y el estado de enlace de cada conexi&oacute;n entre dos nodos vecinos. Desde  el punto de vista del nodo local es muy importante conocer la informaci&oacute;n  sobre el tipo del nodo del pr&oacute;ximo salto. El tipo de nodo se distingue  entre las variantes (<a href="/img/revistas/eac/v33n3/t0108312.jpg">Ver Tabla  1</a>): </font></P>    
<P><font size="2" face="Verdana">1. Vecino con acceso directo  al Internet (nodo Gateway) </font></P>    <P><font size="2" face="Verdana">2. Vecino,  que tiene un nodo Gateway en su vecindad a un salto. En otras palabras, un vecino  que forma parte de la ruta a un Gateway </font></P>    <P><font size="2" face="Verdana">3.  Vecino regular (Router) </font></P>    ]]></body>
<body><![CDATA[<P><font size="2" face="Verdana">La prioridad  entre los vecinos a un salto coincide con la lista anterior, la prioridad m&aacute;s  alta se asigna a los vecinos del grupo 1. La informaci&oacute;n sobre el tipo  del pr&oacute;ximo salto se utiliza en la gesti&oacute;n de la combinaci&oacute;n  de interfaces (<I>bundles</I>). </font></P>    <P><font size="2" face="Verdana"><U>Direcciones  IP y MAC</U> </font></P>    <P><font size="2" face="Verdana">De la tabla de rutas  y de la tabla ARP se extraen las direcciones IP y MAC de cada interface utilizada  en la vecindad de un salto del nodo local. </font></P>    <P><font size="2" face="Verdana"><B>1.2.  M&oacute;dulo de la Capa Intermedia</B> </font></P>    <P><font size="2" face="Verdana">Como  se ha mencionado, los componentes novedosos del sistema se ubican en una capa  intermedia entre la capa de enlace y la de red. Como el sistema usa adem&aacute;s  componentes de esas capas, se puede clasificar como un sistema <I>cross layer</I>.  Cada componente se a&ntilde;ade a cada nodo con m&uacute;ltiples interfaces en  la red mallada. En esta etapa de investigaci&oacute;n los componentes que se han  desarrollado implementan la asignaci&oacute;n de canales (en verde en la <a href="eac08312.htm#f1">Figura  1</a>) y el balance de carga en la comunicaci&oacute;n con un vecino a trav&eacute;s  de un <I>bundle</I> (componente naranja en la <a href="eac08312.htm#f1">Figura  1</a>). </font></P>    <P><font size="2" face="Verdana"><B>1.2.1. Funcionalidad de  la Asignaci&oacute;n de Canales</B> </font></P>    <P><font size="2" face="Verdana">El  sistema presentado no define un algoritmo concreto de asignaci&oacute;n de canales  (AC), aunque se trabaja en uno de forma paralela a esta investigaci&oacute;n [10],  pero define el producto de un algoritmo AC en forma de tabla. As&iacute; el sistema  est&aacute; abierto para utilizar una variedad de algoritmos de asignaci&oacute;n  de canales, siempre que ofrezcan la salida que se necesita. Generalmente, el algoritmo  AC debe aprovechar todos los recursos de un nodo o, lo que es lo mismo, todas  las interfaces 802.11 instaladas. Adem&aacute;s de aprovechar el n&uacute;mero  de interfaces disponibles, todos los canales disponibles a trav&eacute;s de cada  interface deben ser identificados. Un algoritmo AC puede trabajar proactivamente,  que significa distribuir los canales antes de una transmisi&oacute;n, o reactivamente,  que significa adaptar la asignaci&oacute;n de canales durante una transmisi&oacute;n.  El algoritmo AC que se aplique en el sistema propuesto debe considerar el tipo  de nodo del pr&oacute;ximo salto en el proceso de la selecci&oacute;n y asignaci&oacute;n  de canales, y otorgar la prioridad de acuerdo a lo comentado anteriormente en  la secci&oacute;n 4.1. La salida del modulo AC debe especificar qu&eacute; canales  puede usar el nodo local con cada uno de sus vecinos. </font></P>    <P><font size="2" face="Verdana"><B>1.2.2.  Gesti&oacute;n de la Combinaci&oacute;n de Interfaces (gesti&oacute;n de <I>bundles</I>)</B></font></P>    <P><font size="2" face="Verdana">El  modulo de gesti&oacute;n de la combinaci&oacute;n de interfaces tiene varias tareas.  Debe tomarse en consideraci&oacute;n que la implementaci&oacute;n de <I>bundles</I>  es un mecanismo proactivo, los <I>bundles</I> existen entre los nodos a&uacute;n  cuando no hay tr&aacute;fico para transmitir. Este m&oacute;dulo determina: </font></P>    <P><font size="2" face="Verdana">1.  La cantidad de <I>bundles</I> que hay que formar con cada vecino: el nodo local  tiene en cuenta las direcciones IP fuente y destino de cada paquete. Para cada  par de flujos de paquetes (un flujo para cada direcci&oacute;n entre una fuente  y un destino), se crea un <I>bundle</I>. Es posible, que un nodo comparta m&uacute;ltiples  <I>bundles</I> con un solo vecino. </font></P>    ]]></body>
<body><![CDATA[<P><font size="2" face="Verdana">2.  La cantidad de interfaces a usar en cada <I>bundle</I>. La decisi&oacute;n est&aacute;  basada en la prioridad del pr&oacute;ximo salto (ver 4.1). Adicionalmente, si  existe la informaci&oacute;n de una <I>sesi&oacute;n</I> entre dos nodos (IP fuente,  IP destino, puerto fuente, puerto destino, y el protocolo de transporte usado)  la asignaci&oacute;n de la cantidad de interfaces puede ser calculado de forma  m&aacute;s exacta. En este caso, un <I>bundle</I> es usado exclusivamente para  una sesi&oacute;n. </font></P>    <P><font size="2" face="Verdana">3. Asignar el canal  que ser&aacute; utilizado en cada interface dentro del <I>bundle</I>, de acuerdo  a la informaci&oacute;n de la tabla salida del algoritmo AC. No todos los canales  asignados en la tabla AC tienen que ser usados con el vecino correspondiente.  </font></P>    <P><font size="2" face="Verdana">4. Repetir los pasos 1-4 c&iacute;clicamente.  </font></P>    <P><font size="2" face="Verdana"><B>1.2.3. Organizaci&oacute;n de los  Paquetes (<I>packet scheduling</I>) y Balance de Carga</B> </font></P>    <P><font size="2" face="Verdana">En  el m&oacute;dulo de la organizaci&oacute;n de paquetes se realiza la distribuci&oacute;n  de paquetes seg&uacute;n el modo de balance de carga elegido (Ver<a href="/img/revistas/eac/v33n3/t0208312.jpg">  Tabla 2</a>). Se implementan las funcionalidades descritas para cada modo. Este  m&oacute;dulo no adiciona una cola de paquetes extra, sino que los atiende en  la medida en que van llegando. La interface que se utilizar&aacute; para la transmisi&oacute;n  se elige para cada paquete individualmente. </font></P>    
<P><font size="2" face="Verdana"><B>1.3.  Modificaci&oacute;n de la Capa de Enlace (MAC)</B> </font></P>    <P><font size="2" face="Verdana">Para  el modo de balance de carga con el n&uacute;mero 2, Control de Fallos, es necesario  obtener el par&aacute;metro <I>num<SUB>Collisions</SUB></I> de la capa MAC. Por  tal motivo, en la implementaci&oacute;n del sistema presentado es necesario extraer  este valor din&aacute;micamente y hacerlo visible para el m&oacute;dulo descrito  en la secci&oacute;n 4.2. </font></P>    <P>&nbsp;</P>    <P><font size="3" face="Verdana"><B>IMPLEMENTACI&Oacute;N  EN OMNET</B> </font></P>    <P><font size="2" face="Verdana">El sistema descrito fue  implementado en el simulador de eventos discretos OMNeT++. El trabajo m&aacute;s  intenso estuvo en la introducci&oacute;n de los elementos de la capa intermedia  del sistema. Para incluir los protocolos comunes de la suite IEEE 802.11 y TCP/IP,  se trabaj&oacute; con el framework INETMANET [5] como base. Dentro de INETMANET,  se decidi&oacute; utilizar el tipo de nodo <I>MobileManetRoutingHost</I> para  luego incluirle los m&oacute;dulos con las funcionalidades y caracter&iacute;sticas  descritas hasta el momento. El resultado se muestra en la <a href="eac08312.htm#f2">Figura  2</a>. </font></P>    ]]></body>
<body><![CDATA[<P align="center"><img src="/img/revistas/eac/v33n3/f0208312.jpg" width="421" height="566">  <a name="f2"></a>     
<P><font size="2" face="Verdana">Otro elemento a&ntilde;adido  al tipo de nodo <I>MobileManetRoutingHost</I> fue la capacidad de utilizar m&uacute;ltiples  interfaces, aspecto esencial para el sistema descrito en este trabajo. A trav&eacute;s  del par&aacute;metro <I>numMIRadios</I> se pueden especificar la cantidad de interfaces  utilizadas en cada nodo. La funcionalidad de la organizaci&oacute;n de paquetes  (<I>packet scheduling</I>), seg&uacute;n el modo de balance de carga elegido (Ver<a href="/img/revistas/eac/v33n3/t0208312.jpg">  Tabla 2</a>), se encuentra implementada en el nuevo m&oacute;dulo <I>scheduler</I>,  que se ejecuta entre la capa de red (<I>networkLayer</I>) y las interfaces inal&aacute;mbricos  (<I>wlan[numMIRadios]</I>). </font></P>    
<P>&nbsp;</P>    <P><font size="3" face="Verdana"><B>MEDICIONES  REALIZADAS</B> </font></P>    <P><font size="2" face="Verdana">Durante las mediciones  realizadas en dos escenarios diferentes se comprob&oacute; el desempe&ntilde;o  de una misma topolog&iacute;a conformada por nodos (sihost) de una sola interface  inal&aacute;mbrica y conformada luego por nodos (mihost) de cuatro interfaces  inal&aacute;mbricas (en las <a href="/img/revistas/eac/v33n3/f0308312.jpg">figuras  3</a>, <a href="/img/revistas/eac/v33n3/f0408312.jpg">4</a> y <a href="/img/revistas/eac/v33n3/f0508312.jpg">5</a>  se muestran las topolog&iacute;as en este &uacute;ltimo caso). En las mediciones  con nodos multi interfaces se decidi&oacute; emplear el mismo grupo de canales  en cada nodo. La asignaci&oacute;n de estos canales se realiz&oacute; manualmente  a trav&eacute;s de las facilidades de configuraci&oacute;n del OMNeT. Se utiliz&oacute;  el protocolo de enrutamiento OLSR para mallas inal&aacute;mbricas, el mismo que  se ha venido utilizando en toda la investigaci&oacute;n. </font></P>    
<P><font size="2" face="Verdana">El  primer escenario sobre el que se realizaron mediciones contiene una cadena simple  de cuatro nodos <a href="/img/revistas/eac/v33n3/f0308312.jpg">(Figura 3)</a>.  El nodo 0 transmite dos flujos (uno TCP y uno UDP) de forma simult&aacute;nea  hacia el nodo 3. En la <A HREF="/img/revistas/eac/v33n3/f0408312.jpg">Figura  4</A> se puede ver una variante de este escenario, donde se incluyen 6 nodos extras  que intercambian tr&aacute;fico de &#171;fondo&#187;, el cual consiste en tres  flujos TCP que se env&iacute;an desde los nodos 4, 5 y 6 hacia los nodos 7, 8,  y 9 respectivamente. </font></P>    
<P><font size="2" face="Verdana">La <a href="/img/revistas/eac/v33n3/f0508312.jpg">Figura  5</a> muestra el segundo escenario utilizado. En este caso, se emplea una malla  de 16 nodos. Nuevamente, se eval&uacute;an dos flujos de TCP y UDP (ancho de banda  de transmisi&oacute;n: 1 Mbit/s), que se env&iacute;an simult&aacute;neamente  desde el nodo 0 hacia el nodo 15. En una segunda versi&oacute;n del escenario,  se introducen tres flujos de tr&aacute;fico TCP de fondo, enviados desde los nodos  1, 3 y 11 hacia los nodos 4, 12 y 14. </font></P>    
<P><font size="2" face="Verdana">Los  resultados de los dos escenarios simulados y sus variantes se muestran en las  <a href="/img/revistas/eac/v33n3/f0608312.jpg">Figuras 6</a> y <a href="/img/revistas/eac/v33n3/f0708312.jpg">7</a>.  Se compara el desempe&ntilde;o de las variantes con nodos de una interface y los  de cuatro interfaces, los cuales aplican los modos de balance de carga Round-Robin,  Control de Fallos y Adaptivo, los &uacute;nicos implementados hasta el momento.</font></P>    
<P><font size="2" face="Verdana">Los  resultados obtenidos con los nodos de m&uacute;ltiples interfaces son visiblemente  mejores en comparaci&oacute;n con los nodos convencionales, lo cual es un resultado  a esperar y que debe ser mucho m&aacute;s evidente cuando los niveles de tr&aacute;fico  crecen. En cuanto a los modos de balance de carga comprobados, generalmente el  modo Round-Robin ofrece la mejor respuesta de desempe&ntilde;o, especialmente  en el segundo escenario. Debe tomarse en consideraci&oacute;n que las mediciones  han sido realizadas sobre escenarios y ejemplos de tr&aacute;fico muy b&aacute;sicos.  Adicionalmente, puede se&ntilde;alarse que de forma general para el tr&aacute;fico  TCP se obtienen los mejores desempe&ntilde;os a excepci&oacute;n del modo de Control  de Fallos, sobre el cu&aacute;l deber&aacute; revisarse la opci&oacute;n de modificar  el par&aacute;metro decisor del algoritmo. </font></P>    <P>&nbsp;</P>    ]]></body>
<body><![CDATA[<P><font size="3" face="Verdana"><B>CONCLUSIONES</B>  </font></P>    <P><font size="2" face="Verdana">En el art&iacute;culo presentado se  propone un sistema de balance de carga para redes malladas inal&aacute;mbricas,  que aprovecha la asignaci&oacute;n de canales y la combinaci&oacute;n de interfaces  para proporcionar una mejor calidad de servicio. Este sistema permite gestionar  de forma mucho m&aacute;s eficiente los recursos de los nodos en las redes malladas  inal&aacute;mbricas multi interfaces. El sistema tiene su n&uacute;cleo en una  capa intermedia entre las capas de red y de enlace, y utiliza algunas facilidades  existentes en esas capas, por lo que constituye una soluci&oacute;n <I>cross-layer</I>.  </font></P>    <P><font size="2" face="Verdana">Los diferentes modos de trabajo propuestos,  aunque no agotan todas las posibilidades, son aplicables en diversos escenarios.  Para alcanzar el balance de carga de acuerdo los modos de trabajo introducidos,  el sistema contiene elementos para la gesti&oacute;n de combinaci&oacute;n de  interfaces y la gesti&oacute;n de las direcciones IP y MAC de las interfaces.  </font></P>    <P><font size="2" face="Verdana">Hasta el momento, los resultados de  las mediciones de los modos que se simularon muestran que el modo Round-Robin  es el m&aacute;s efectivo en t&eacute;rminos de desempe&ntilde;o (<I>throughput</I>).  No obstante, debe continuarse trabajando en la comprobaci&oacute;n y refinamiento  de todos los modos presentados. </font></P>    <P><font size="2" face="Verdana">Dentro  del trabajo de futuro se tomar&aacute;n en consideraci&oacute;n par&aacute;metros  adicionales como la prioridad del tr&aacute;fico, en favor de la calidad de servicio.  Adem&aacute;s, se investigar&aacute; en los efectos de los modos presentados en  rutas multi-salto. </font></P>    <P>&nbsp;</P>    <P><strong><font size="3" face="Verdana">REFERENCIAS</font></strong></P>    <!-- ref --><P><font size="2" face="Verdana">1.  I. F. Akyildiz and Xudong Wang: &#171;A survey on wireless mesh networks&#187;,  IEEE Communications Magazine, vol. 43, no. 9, pp. S23 S30, Sep. 2005.     </font></P>    <!-- ref --><P><font size="2" face="Verdana">2.  Linux Ethernet Bonding Driver, <A HREF="http://www.kernel.org/doc/Documentation/networking/bonding.txt" TARGET="_blank">http://www.kernel.org/doc/Documentation/networking/bonding.txt</A>  </font><!-- ref --><P><font size="2" face="Verdana">3. H. Kim; Q. Gu; M. Yu; W. Zang;  and P. Liu: &#171;A simulation framework for performance analysis of multi-interface  and multi-channel wireless networks in INET/OMNET++,&#187; in Proceedings of the  2010 Spring Simulation Multiconference, Orlando, Florida, 2010, pp. 101:1101:8.      </font></P>    <!-- ref --><P><font size="2" face="Verdana">4. &#171;OMNeT++ Network Simulator  Framework&#187;, <A HREF="http://www.omnetpp.org" TARGET="_blank">http://www.omnetpp.org</A>  </font><!-- ref --><P><font size="2" face="Verdana">5. &#171;INETMANET Framework&#187;,  <A HREF="https://github.com/inetmanet/inetmanet/blob/master/README.INETMANET" TARGET="_blank">https://github.com/inetmanet/inetmanet/blob/master/README.INETMANET</A>  </font><P><font size="2" face="Verdana">6. Kobel, C.; Garcia, W.B.; Habermann,  J.; Bayer, N.; Sivchenko, D.; , &#171;Dynamic channel bundling in 802.11a based  media-transport mesh networks,&#187; Consumer Communications and Networking Conference  (CCNC), 2011 IEEE , vol., no., pp.979-980, 9-12 Jan. 2011 </font></P>    <!-- ref --><P><font size="2" face="Verdana">7.  A. Sheth; S. Nedevschi; R. Patra; S. Surana; E. Brewer; and L. Subramanian: &#171;Packet  loss characterization in WiFi-based long distance networks,&#187; in INFOCOM 2007.  26th IEEE International Conference on Computer Communications. IEEE, 2007, pp.  312320.     </font></P>    <!-- ref --><P><font size="2" face="Verdana">8. I. Kozintsev and J. M.  Veigh: &#171;Improving last-hop multicast streaming video over 802.11,&#187; Proceedings  of BROADNETS, San Jose, California, USA, vol. 38, 2004.     </font></P>    <P><font size="2" face="Verdana">9.  A.Parekh and R.Gallager: &#171;A generalized processor sharing approach to flow  control in integrated services networks- the </font></P>    ]]></body>
<body><![CDATA[<P><font size="2" face="Verdana">multiple  node case&#187;, in INFOCOM'93. Proceedings.Twelfth Annual Joint Conference of  the IEEE Computer and Communications Societies. Networking: Foundation for the  Future. IEEE ,1993, pp. 521530 vol.2. </font></P>    <!-- ref --><P><font size="2" face="Verdana">10.  A. Fadraga: &#171;Dise&ntilde;o de algoritmo para la distribuci&oacute;n din&aacute;mica  de canales en redes malladas inal&aacute;mbricas&#187;, Tesis de diploma, Instituto  Superior Polit&eacute;cnico Jos&eacute; Antonio Echeverr&iacute;a, Ciudad de La  Habana, 2012.     </font></P>    <!-- ref --><P><font size="2" face="Verdana">11. T. Clausen and P.  Jacquet: &#171;Optimized link state routing protocol (OLSR),&#187; IETF Network  Working Group RFC 3626, Oct. 2003.     </font></P>    <!-- ref --><P><font size="2" face="Verdana">12.  P. M. Esposito; M. Campista; I. M. Moraes; L. Costa; O. Duarte, and M. G. Rubinstein:  &#171;Implementing the Expected Transmission Time Metric for OLSR Wireless Mesh  Networks,&#187; in Wireless Days, 2008. WD '08. 1st IFIP, 2008, pp. 15.     </font></P>    <!-- ref --><P><font size="2" face="Verdana">13.  Christian K&ouml;bel; Walter Baluja Garc&iacute;a, and Joachim Habermann: &#171;Selective  Link Cost Alteration in Reservation-Based Multi-Hop Wireless Mesh Networks&#187;,  in ICN 2012: The Eleventh International Conference on Networks, IARIA, pp. 153-158,  2012.    </font></P>    <P>&nbsp;</P>    ]]></body>
<body><![CDATA[<P>&nbsp;</P>    <P><font size="2" face="Verdana">Recibido: Julio  2012    <br> Aprobado: Septiembre 2012 </font></P>      ]]></body><back>
<ref-list>
<ref id="B1">
<label>1</label><nlm-citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname><![CDATA[I. F.]]></surname>
<given-names><![CDATA[Akyildiz]]></given-names>
</name>
<name>
<surname><![CDATA[Xudong]]></surname>
<given-names><![CDATA[Wang]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[A survey on wireless mesh networks]]></article-title>
<source><![CDATA[IEEE Communications Magazine]]></source>
<year>Sep.</year>
<month> 2</month>
<day>00</day>
<volume>43</volume>
<numero>9</numero>
<issue>9</issue>
<page-range>S23 S30</page-range></nlm-citation>
</ref>
<ref id="B2">
<label>2</label><nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[I. F.]]></surname>
<given-names><![CDATA[Akyildiz]]></given-names>
</name>
</person-group>
<person-group person-group-type="editor">
<name>
</name>
</person-group>
<source><![CDATA[Linux Ethernet Bonding Driver]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B3">
<label>3</label><nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[H]]></surname>
<given-names><![CDATA[Kim]]></given-names>
</name>
<name>
<surname><![CDATA[Q.]]></surname>
<given-names><![CDATA[Gu]]></given-names>
</name>
<name>
<surname><![CDATA[M.]]></surname>
<given-names><![CDATA[Yu]]></given-names>
</name>
<name>
<surname><![CDATA[W]]></surname>
<given-names><![CDATA[Zang]]></given-names>
</name>
<name>
<surname><![CDATA[P.]]></surname>
<given-names><![CDATA[Liu]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[A simulation framework for performance analysis of multi-interface and multi-channel wireless networks in INET/OMNET++]]></article-title>
<source><![CDATA[Proceedings of the 2010 Spring Simulation Multiconference]]></source>
<year>2010</year>
<page-range>101:1101:8</page-range><publisher-loc><![CDATA[Orlando^eFlorida Florida]]></publisher-loc>
</nlm-citation>
</ref>
<ref id="B4">
<label>4</label><nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[H]]></surname>
<given-names><![CDATA[Kim]]></given-names>
</name>
</person-group>
<person-group person-group-type="editor">
<name>
</name>
</person-group>
<source><![CDATA[OMNeT++ Network Simulator Framework]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B5">
<label>5</label><nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[H]]></surname>
<given-names><![CDATA[Kim]]></given-names>
</name>
</person-group>
<person-group person-group-type="editor">
<name>
</name>
</person-group>
<source><![CDATA[INETMANET Framework]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B6">
<label>6</label><nlm-citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Kobel]]></surname>
<given-names><![CDATA[C.]]></given-names>
</name>
<name>
<surname><![CDATA[Garcia]]></surname>
<given-names><![CDATA[W.B.]]></given-names>
</name>
<name>
<surname><![CDATA[Habermann]]></surname>
<given-names><![CDATA[J.]]></given-names>
</name>
<name>
<surname><![CDATA[Bayer]]></surname>
<given-names><![CDATA[N.]]></given-names>
</name>
<name>
<surname><![CDATA[Sivchenko]]></surname>
<given-names><![CDATA[D.]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[Dynamic channel bundling in 802.11a based media-transport mesh networks]]></article-title>
<source><![CDATA[Consumer Communications and Networking Conference (CCNC)]]></source>
<year>Jan.</year>
<month> 2</month>
<day>01</day>
<page-range>979-980</page-range><publisher-name><![CDATA[2011 IEEE]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B7">
<label>7</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[A.]]></surname>
<given-names><![CDATA[Sheth]]></given-names>
</name>
<name>
<surname><![CDATA[S.]]></surname>
<given-names><![CDATA[Nedevschi]]></given-names>
</name>
<name>
<surname><![CDATA[R.]]></surname>
<given-names><![CDATA[Patra]]></given-names>
</name>
<name>
<surname><![CDATA[S.]]></surname>
<given-names><![CDATA[Surana]]></given-names>
</name>
<name>
<surname><![CDATA[E.]]></surname>
<given-names><![CDATA[Brewer]]></given-names>
</name>
<name>
<surname><![CDATA[L.]]></surname>
<given-names><![CDATA[Subramanian]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[Packet loss characterization in WiFi-based long distance networks]]></article-title>
<source><![CDATA[INFOCOM 2007]]></source>
<year>2007</year>
<page-range>312320</page-range><publisher-name><![CDATA[26th IEEE International Conference on Computer Communications. IEEE]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B8">
<label>8</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[I.]]></surname>
<given-names><![CDATA[Kozintsev]]></given-names>
</name>
<name>
<surname><![CDATA[J. M.]]></surname>
<given-names><![CDATA[Veigh]]></given-names>
</name>
</person-group>
<source><![CDATA[Improving last-hop multicast streaming video over 802.11]]></source>
<year>2004</year>
<volume>38</volume>
<publisher-loc><![CDATA[San Jose^eCalifornia California]]></publisher-loc>
<publisher-name><![CDATA[Proceedings of BROADNETS]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B9">
<label>9</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[A.]]></surname>
<given-names><![CDATA[Parekh]]></given-names>
</name>
<name>
<surname><![CDATA[R.]]></surname>
<given-names><![CDATA[Gallager]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[A generalized processor sharing approach to flow control in integrated services networks- the multiple node case]]></article-title>
<source><![CDATA[INFOCOM'93]]></source>
<year>1993</year>
<volume>2</volume>
<page-range>521530</page-range><publisher-name><![CDATA[Proceedings.Twelfth Annual Joint Conference of the IEEE Computer and Communications Societies. Networking: Foundation for the Future. IEEE]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B10">
<label>10</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Fadraga]]></surname>
<given-names><![CDATA[A.]]></given-names>
</name>
</person-group>
<source><![CDATA[Diseño de algoritmo para la distribución dinámica de canales en redes malladas inalámbricas]]></source>
<year>2012</year>
<publisher-loc><![CDATA[Ciudad de La Habana ]]></publisher-loc>
<publisher-name><![CDATA[Instituto Superior Politécnico José Antonio Echeverría]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B11">
<label>11</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[T.]]></surname>
<given-names><![CDATA[Clausen]]></given-names>
</name>
<name>
<surname><![CDATA[P.]]></surname>
<given-names><![CDATA[Jacquet]]></given-names>
</name>
</person-group>
<source><![CDATA[Optimized link state routing protocol (OLSR)]]></source>
<year>Oct.</year>
<month> 2</month>
<day>00</day>
<publisher-name><![CDATA[IETF Network Working Group RFC 3626]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B12">
<label>12</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[M. Esposito]]></surname>
<given-names><![CDATA[P.]]></given-names>
</name>
<name>
<surname><![CDATA[Campista]]></surname>
<given-names><![CDATA[M.]]></given-names>
</name>
<name>
<surname><![CDATA[M. Moraes]]></surname>
<given-names><![CDATA[I.]]></given-names>
</name>
<name>
<surname><![CDATA[Costa]]></surname>
<given-names><![CDATA[L.]]></given-names>
</name>
<name>
<surname><![CDATA[Duarte]]></surname>
<given-names><![CDATA[O.]]></given-names>
</name>
<name>
<surname><![CDATA[G. Rubinstein]]></surname>
<given-names><![CDATA[M.]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[Implementing the Expected Transmission Time Metric for OLSR Wireless Mesh Networks]]></article-title>
<source><![CDATA[Wireless Days]]></source>
<year>2008</year>
<page-range>15</page-range><publisher-name><![CDATA[WD '08. 1st IFIP, 2008]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B13">
<label>13</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Köbel]]></surname>
<given-names><![CDATA[Christian]]></given-names>
</name>
<name>
<surname><![CDATA[Baluja García]]></surname>
<given-names><![CDATA[Walter]]></given-names>
</name>
<name>
<surname><![CDATA[Habermann]]></surname>
<given-names><![CDATA[Joachim]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[Selective Link Cost Alteration in Reservation-Based Multi-Hop Wireless Mesh Networks]]></article-title>
<source><![CDATA[ICN 2012: The Eleventh International Conference on Networks]]></source>
<year>2012</year>
<page-range>153-158</page-range><publisher-name><![CDATA[IARIA]]></publisher-name>
</nlm-citation>
</ref>
</ref-list>
</back>
</article>
