<?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>1405-7743</journal-id>
<journal-title><![CDATA[Ingeniería, investigación y tecnología]]></journal-title>
<abbrev-journal-title><![CDATA[Ing. invest. y tecnol.]]></abbrev-journal-title>
<issn>1405-7743</issn>
<publisher>
<publisher-name><![CDATA[Universidad Nacional Autónoma de México, Facultad de Ingeniería]]></publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id>S1405-77432008000100002</article-id>
<title-group>
<article-title xml:lang="es"><![CDATA[Diseño de procedimientos Handoff en redes inalámbricas de banda ancha basado en el protocolo IEEE 802.16]]></article-title>
<article-title xml:lang="en"><![CDATA[Design of handoff procedures for broadband wireless access IEEE 802.16 based networks]]></article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Rangel-Licea]]></surname>
<given-names><![CDATA[V]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Cota-Guajardo]]></surname>
<given-names><![CDATA[J.E.]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Gómez-Castellanos]]></surname>
<given-names><![CDATA[J]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Reyes-García]]></surname>
<given-names><![CDATA[J]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
</contrib-group>
<aff id="A01">
<institution><![CDATA[,UNAM Facultad de Ingeniería Departamento de Ingeniería en Telecomunicaciones]]></institution>
<addr-line><![CDATA[ ]]></addr-line>
</aff>
<pub-date pub-type="pub">
<day>00</day>
<month>03</month>
<year>2008</year>
</pub-date>
<pub-date pub-type="epub">
<day>00</day>
<month>03</month>
<year>2008</year>
</pub-date>
<volume>9</volume>
<numero>1</numero>
<fpage>17</fpage>
<lpage>29</lpage>
<copyright-statement/>
<copyright-year/>
<self-uri xlink:href="http://www.scielo.org.mx/scielo.php?script=sci_arttext&amp;pid=S1405-77432008000100002&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://www.scielo.org.mx/scielo.php?script=sci_abstract&amp;pid=S1405-77432008000100002&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://www.scielo.org.mx/scielo.php?script=sci_pdf&amp;pid=S1405-77432008000100002&amp;lng=en&amp;nrm=iso"></self-uri><abstract abstract-type="short" xml:lang="es"><p><![CDATA[El protocolo IEEE 802.16 es un estándar de nueva creación para conexiones inalámbricas fijas de banda ancha que está buscando agregar movilidad entre sus usuarios. Sin embargo, primero deben solucionarse algunos obstáculos técnicos, como es el caso de "handoff" HO (cambio de conexión que ejecuta un nodo en movimiento entre dos "estaciones base" BS). En este artículo, se aborda la problemática de HO tratando de conservar la calidad y servicio (QoS) de los usuarios. Varios mecanismos y algoritmos para el cambio de conexión son presentados. También se menciona un modelo de programación basado en OPNET MODELER ¹ para simular y evaluar los mecanismos de HO aquí presentados. Finalmente, se demuestra que es posible implementar mecanismos confiables de HO sobre el protocolo IEEE 802.16, capaces de mantener una QoS aún durante el cambio de conexión, incluyendo usuarios con aplicaciones intolerantes al retardo como voz sobre IP (VoIP).]]></p></abstract>
<abstract abstract-type="short" xml:lang="en"><p><![CDATA[Abstract IEEE 802.16 is a protocol for fixed broad band wire less access that is currently trying to add mobility among mobile users in the standard. However, mobility adds some technical barriers that should be solved first, this is the case of HO "handoff" (change of connection between two base stations "BS" by a mobile user). In this paper, the problem of HO in IEEE 802.16 is approached try ing to maintain the quality of service (QoS) of mobile users. A mechanism for changing connection during HO is pre sented. A simulation model based on OPNET MODELER1 was developed to evaluate the performance of the proposed HO mechanism. Finally, this paper demonstrates that it is possible to implement a seam less HO mech a nism over IEEE 802.16 even for users with de manding applications such as voice over IP.]]></p></abstract>
<kwd-group>
<kwd lng="es"><![CDATA[Handoff]]></kwd>
<kwd lng="es"><![CDATA[IEEE 802.16]]></kwd>
<kwd lng="es"><![CDATA[WiMax]]></kwd>
<kwd lng="es"><![CDATA[BWA]]></kwd>
<kwd lng="es"><![CDATA[VoIP]]></kwd>
<kwd lng="es"><![CDATA[QoS]]></kwd>
<kwd lng="en"><![CDATA[Handoff]]></kwd>
<kwd lng="en"><![CDATA[IEEE 802.16]]></kwd>
<kwd lng="en"><![CDATA[WiMax]]></kwd>
<kwd lng="en"><![CDATA[BWA]]></kwd>
<kwd lng="en"><![CDATA[VoIP]]></kwd>
<kwd lng="en"><![CDATA[QoS]]></kwd>
</kwd-group>
</article-meta>
</front><body><![CDATA[ <p align="justify"><font face="verdana" size="4">Estudios e investigaciones recientes </font></p>     <p align="center"><font face="verdana" size="2">&nbsp;</font></p>     <p align="center"><font face="verdana" size="4"><b>Dise&ntilde;o de procedimientos Handoff en redes inal&aacute;mbricas de banda  ancha   basado   en   el   protocolo   IEEE   802.16</b></font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="center"><font face="verdana" size="3"><b>Design of handoff procedures for broadband wireless access IEEE 802.16 based networks</b></font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="center"><font face="verdana" size="2"><b>V. Rangel&#150;Licea, J.E. Cota&#150;Guajardo, J. G&oacute;mez&#150;Castellanos y J. Reyes&#150;Garc&iacute;a</b></font></p>     <p align="center"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><i>Departamento de Ingenier&iacute;a en Telecomunicaciones.     <br>   Facultad de Ingenier&iacute;a, UNAM    ]]></body>
<body><![CDATA[<br>   </i><b>E&#150;mails:</b> <a href="mailto:victor@fi-b.unam.mx">victor@fi-b.unam.mx</a>, <a href="mailto:eduardocg@fi-b.unam.mx">eduardocg@fi-b.unam.mx</a>, <a href="mailto:javierg@fi-b.unam.mx">javierg@fi-b.unam.mx</a>, <a href="mailto:jrg307@fi-b.unam.mx">jrg307@fi-b.unam.mx</a></font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2">Recibido: enero de 2006    <br> Aceptado: junio de 2007</font></p>     <p align="center"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Resumen</b></font></p>     <p align="justify"><font face="verdana" size="2">El protocolo IEEE 802.16 es un est&aacute;ndar de nueva creaci&oacute;n para conexiones inal&aacute;mbricas fijas de banda ancha que est&aacute; buscando agregar movilidad entre sus usuarios. Sin embargo, primero deben solucionarse algunos obst&aacute;culos t&eacute;cnicos, como es el caso de <b><i>"handoff" </i>HO </b>(cambio de conexi&oacute;n que ejecuta un nodo en movimiento entre dos "estaciones base" BS). En este art&iacute;culo, se aborda la problem&aacute;tica de HO tratando de conservar la calidad y servicio (QoS) de los usuarios. Varios mecanismos y algoritmos para el cambio de conexi&oacute;n son presentados. Tambi&eacute;n se menciona un modelo de programaci&oacute;n basado en OPNET MODELER <sup>1</sup> para simular y evaluar los mecanismos de HO aqu&iacute; presentados. Finalmente, se demuestra que es posible implementar mecanismos confiables de HO sobre el protocolo IEEE 802.16, capaces de mantener una QoS a&uacute;n durante el cambio de conexi&oacute;n, incluyendo usuarios con aplicaciones intolerantes al retardo como voz sobre IP (VoIP).</font></p>     <p align="justify"><font face="verdana" size="2"><b>Descriptores: </b>Handoff, IEEE 802.16, WiMax, BWA, VoIP, QoS</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b><i>Abstract</i></b></font></p>     ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2"><i>IEEE 802.16 is a protocol for fixed broad band wire less access that is currently trying to add mobility among mobile users in the standard. However, mobility adds some technical barriers that should be solved first, this is the case of HO "handoff" (change of connection between two base stations "BS" by a mobile user). In this paper, the problem of HO in IEEE 802.16 is approached try ing to maintain the quality of service (QoS) of mobile users. A mechanism for changing connection during HO is pre sented. A simulation model based on OPNET MODELER1 was developed to evaluate the performance of the proposed HO mechanism. Finally, this paper demonstrates that it is possible to implement a seam less HO mech a nism over IEEE 802.16 even for users with de manding applications such as voice over IP.</i></font></p>     <p align="justify"><font face="verdana" size="2"><b>Key words:</b><i> Handoff, IEEE 802.16, WiMax, BWA, VoIP, QoS.</i></font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Introducci&oacute;n</b></font></p>     <p align="justify"><font face="verdana" size="2">Una   gran    demanda    por   conexiones   de    banda ancha a Internet, as&iacute; como la tendencia a utilizar canales inal&aacute;mbricos, han dado surgimiento a las redes de acceso inal&aacute;mbrico de banda ancha (Broadband Wireless Access&#150;BWA). A diferencia de otras tecnolog&iacute;as de banda ancha como: xDSL (Digital Subscriber Line), FITL (Fiber In The Loop), WITL (Wireless In The Loop) entre otros, los sistemas BWA son f&aacute;ciles de desplegar y expandir, requieren de una baja inversi&oacute;n inicial y de mantenimiento, son f&aacute;ciles de actualizar y prometen tener un buen futuro, debido al evidente crecimiento del mercado de banda ancha en &aacute;reas urbanas. Sin embargo, no fue hasta esta &uacute;ltima d&eacute;cada que se empezaron a realizar esfuerzos por estandarizar este tipo de tecnolog&iacute;as, surgiendo de este modo, protocolos como Wireless ATM y IEEE 802.16  (Eklund et al, 2002).</font></p>     <p align="justify"><font face="verdana" size="2">El protocolo IEEE 802.16 provee de una conexi&oacute;n inal&aacute;mbrica que puede soportar conexiones que van desde 1 Mbps hasta 34 Mbps con coberturas de hasta 50 km para usuarios fijos. Est&aacute; clasificado como red de tipo MAN (Metropolitan Area Network) se puede utilizar indistintamente del protocolo utilizado en las capas superiores (ATM o IP, por ejemplo).</font></p>     <p align="justify"><font face="verdana" size="2">Actualmente, se est&aacute;n haciendo esfuerzos por agregar movilidad al est&aacute;ndar IEEE 802.16, para lo cual se cre&oacute; el grupo de trabajo IEEE 802.16e. Con esto se pretende incrementar el mercado potencial para los sistemas BWA a&ntilde;adiendo el nuevo servicio de movilidad. Sin embargo, movilidad introduce muchos problemas t&eacute;cnicos, entre ellos, el problema de HO. A continuaci&oacute;n, se presenta una descripci&oacute;n general de la operaci&oacute;n del protocolo IEEE 802.16 y posteriormente se introduce el procedimiento de HO en donde se implement&oacute; un modelo se simulaci&oacute;n en OPNET MODELLET v11.0 para estudiar su comportamiento din&aacute;mico.</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Descripci&oacute;n del protocolo   IEEE 802.16</b></font></p>     <p align="justify"><font face="verdana" size="2">Desde la aparici&oacute;n de la primera versi&oacute;n del protocolo IEEE 802.16 en abril del 2002, se han ido desarrollando mejoras y adaptaciones que han sido registradas como nuevas versiones dentro del mismo grupo de est&aacute;ndares. La &uacute;ltima versi&oacute;n IEEE 802.16 e (2004), describe el modo de operaci&oacute;n en las frecuencias de 10&#150;66 GHz con un apartado para frecuencias por debajo de los 11 GHz, que permite conexiones NLOS (sin l&iacute;nea de vista), pensando en futuras comunicaciones m&oacute;viles. Este protocolo define la operaci&oacute;n de las capas f&iacute;sicas y MAC (Control de Acceso al Medio) dentro de una red.</font></p>     ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Descripci&oacute;n de la capa f&iacute;sica</b></font></p>     <p align="justify"><font face="verdana" size="2">Generalmente, se utiliza una arquitectura PMP (punto&#150;multipunto) donde una BS provee de una conexi&oacute;n a un conjunto de SS (nodos fijos) o MSS (nodos m&oacute;viles). El canal de <i>uplink </i>(canal de subida) es compartido por todos los usuarios para enviar datos hacia la BS, mientras que el canal <i>downlink </i>(canal de bajada) es utilizado s&oacute;lo por la BS para enviar datos hacia los nodos. Se utiliza FDD (Duplexaje por Divisi&oacute;n de Frecuencia) para separar los canales <i>uplink y downlink. </i>Dentro del canal <i>downlink </i>se utiliza TDM (Multiplexaje por Divisi&oacute;n de Tiempo), y a su vez, el canal <i>uplink </i>utiliza TDMA (Acceso M&uacute;ltiple por Divisi&oacute;n de Tiempo) Y DAMA (Acceso M&uacute;ltiple por Asignaci&oacute;n de Demanda), los cuales se utilizan para definir regiones de tiempo para usos espec&iacute;ficos como se muestra en la <a href="#f1">figura 1</a>.</font></p>     <p align="center"><font face="verdana" size="2"><a name="f1"></a></font></p>     <p align="center"><font face="verdana" size="2"><img src="/img/revistas/iit/v9n1/a2f1.jpg"></font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Descripci&oacute;n de la capa MAC</b></font></p>     <p align="justify"><font face="verdana" size="2">Cuatro clases  de  QoS  est&aacute;n  definidos:   UGS (Unsolicited Grant Service), rtPS (real time Polling Service), nrtPS (non real time Polling Service) y BE (Best Effort). UGS es para aplicaciones que generan paquetes de tama&ntilde;o fijo de manera constante, como VoIP por ejemplo; rtPS es para aplicaciones que generan paquetes de tama&ntilde;o variable y per&iacute;odo fijo, como en el caso de video MPEG; nrTPS es ideal para aplicaciones que transmiten con una tasa de transmisi&oacute;n variable y en forma regularmente peri&oacute;dica sin exigencias de tiempo real, como es el caso de FTP (Protocolo de Transferencia de Archivos) de alta velocidad; BE es ideal para tr&aacute;fico de tipo Internet, ya que provee el mejor servicio posible sin garant&iacute;a de ning&uacute;n tipo.</font></p>     <p align="justify"><font face="verdana" size="2">Dependiendo de la QoS asignada a un usuario, ser&aacute; el procedimiento que &eacute;ste ejecute en la capa MAC para poder transmitir sus paquetes hacia la BS. Los tres m&eacute;todos para poder transmitir datos hacia la BS son:</font></p>     <blockquote>       ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">A) Por solicitudes:  es el  mecanismo que utiliza un nodo para indicar a la BS que necesita BW (ancho de banda) para transmitir. Las solicitudes se pueden enviar en un encabezado de BW o en forma de <i>piggyback</i><sup>2</sup>;</font></p>       <p align="justify"><font face="verdana" size="2">B) Por reservaciones:  es cuando  un  nodo transmite datos en ranuras reservadas de antemano por la BS;</font></p>       <p align="justify"><font face="verdana" size="2">C) Por consulta: es el proceso mediante el cual, la BS asigna BW a los nodos para uso exclusivo de peticiones de BW. Estas asignaciones pueden direccionarse a un nodo espec&iacute;fico (unicast) o a un grupo de nodos (multicast)  en  cuyo caso,   los  nodos  involucrados deber&aacute;n entrar en contenci&oacute;n para mandar sus requerimientos de BW.</font></p> </blockquote>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Resoluci&oacute;n de colisiones</b></font></p>     <p align="justify"><font face="verdana" size="2">Una colisi&oacute;n resulta cuando dos o m&aacute;s nodos transmiten de tal forma que la se&ntilde;al llega exactamente al mismo tiempo a la BS, ocasionando que &eacute;sta no pueda entender a ninguno de ellos.</font></p>     <p align="justify"><font face="verdana" size="2">Para resolver  colisiones,   los  nodos  utilizan   el algoritmo <i>exponential backoff binario truncado, </i>como se describe en (Rangel et <i>al, </i>2001&#150;a), el cual utiliza los par&aacute;metros "ventana de <i>backoff </i>inicial" y "ventana de <i>backoff </i>final". Este algoritmo se resume de la siguiente forma: Cuando un SS tiene informaci&oacute;n para enviar y necesita entrar en el proceso de resoluci&oacute;n de colisiones, &eacute;ste selecciona aleatoriamente un n&uacute;mero "n" que se encuentre dentro de la ventana de <i>backoff </i>&#91;0, 2<sup> backoff inicial</sup>&#93;. Este valor "n" indica el n&uacute;mero de oportunidades de transmisi&oacute;n <i>(slots) </i>en la regi&oacute;n de contenci&oacute;n que deber&aacute; dejar pasar antes de transmitir su requerimiento. Si el nodo no recibe ninguna notificaci&oacute;n para transmitir dentro de un tiempo especificado por parte de la BS despu&eacute;s de haber mandado su petici&oacute;n, se considera que la transmisi&oacute;n de solicitud de BW colision&oacute; con un mensaje de otro nodo, y por lo tanto, que se ha perdido. En este caso, el SS incrementa la ventana de <i>backoff </i>por un factor de 2, esto es una ventana de 0 a 2  <sup>(backoff</sup> <sup>inicial</sup> <sup>+ 1)</sup> , y vuelve a escoger un n&uacute;mero "n" aleatorio que est&eacute; dentro de esta nueva ventana y espera "n" oportunidades para volver a enviar su solicitud de BW. Si el SS recibe ahora una asignaci&oacute;n de BW, por parte de la BS, termina el proceso de resoluci&oacute;n de colisiones. Pero por el contrario, si vuelve a pasar un tiempo especificado sin recibir una asignaci&oacute;n de BW, el nodo considera que hubo otra colisi&oacute;n y vuelve nuevamente a incrementar la ventana de <i>backoff </i>(&#91;0, 2 <sup>backoff inicial + 2</sup>&#93;) y repite el proceso hasta que el nodo reciba una asignaci&oacute;n de BW o hasta que la ventana de <i>backoff </i>sea igual al valor de ventana de <i>backoff </i>final (&#91;0, 2 <sup>backoff final</sup>&#93;). Si esto &uacute;ltimo sucede, el nodo descarta el paquete para el cual estaba solicitando el BW.</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Proceso de inicializaci&oacute;n</b></font></p>     <p align="justify"><font face="verdana" size="2">El proceso de inicializaci&oacute;n mostrado en la <a href="/img/revistas/iit/v9n1/a2f2.jpg" target="_blank">figura 2</a>, es llevado a cabo por todos los nodos que deseen entrar a la red por primera vez. La fase de <i>ranging y ajuste autom&aacute;ticos </i>es la m&aacute;s cr&iacute;tica para el proceso de HO, ya que es aqu&iacute; donde el nodo env&iacute;a el primer mensaje de registro hacia la BS, el cual deber&aacute; enviarlo en la regi&oacute;n de contenci&oacute;n. Tambi&eacute;n es en esta fase donde se corrige el <i>offset </i>de tiempo y se ajusta la potencia de transmisi&oacute;n del nodo, para lo cual, numerosos mensajes entre el MSS y la BS pueden ser intercambiados. El tiempo que transcurre en la ejecuci&oacute;n completa de esta fase es aleatorio. En la <a href="/img/revistas/iit/v9n1/a2f2.jpg" target="_blank">figura 2</a>, se muestra el proceso de inicializaci&oacute;n donde los retardos por inicializaci&oacute;n pueden ir desde unos pocos segundos hasta varios minutos, en el peor de los casos, como se describe en (Cota, 2005).</font></p>     ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">Cuando un MSS se aleja demasiado de la BS, debe ejecutar un procedimiento de HO con el fin de conectarse con otra BS que est&eacute; m&aacute;s cerca y le pueda proveer de una mejor conexi&oacute;n. El proceso de HO debe ejecutarse de la manera m&aacute;s r&aacute;pida posible, ya que aplicaciones como VoIP, exigen retardos muy bajos (en el orden de 20 a 50 ms) para la transmisi&oacute;n de paquetes, por lo que la QoS debe mantenerse a&uacute;n durante el proceso de HO. La forma natural de ejecutar un proceso de HO ser&iacute;a terminar el servicio con la BS actual e iniciar uno nuevo con  la BS m&aacute;s cercana,  pero esto causar&iacute;a la interrupci&oacute;n moment&aacute;nea del servicio, debido a los grandes retardos de inicializaci&oacute;n ya mencionados. Por consiguiente, es indispensable proveer de un mecanismo de HO transparente que permita mantener la calidad de servicio al cambiarse de BS. A continuaci&oacute;n, se presenta nuestra propuesta de HO en IEEE 802.16.</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Propuesta de mecanismo de <i>Handoff</i></b></font></p>     <p align="justify"><font face="verdana" size="2">En la <a href="#f3">figura 3</a> se muestra de forma detallada el procedimiento para el cambio de BS. Una vez que un MSS pasa por la etapa de inicializaci&oacute;n (como se describi&oacute; en la secci&oacute;n anterior), deber&aacute; solicitar a la BS servidora que se le asigne un tiempo de reconocimiento para que pueda escuchar los <i>beacons </i>o mensajes de configuraci&oacute;n de red (ADV MSG) provenientes de las BS vecinas, como se muestra en el punto (1) de la <a href="#f3">figura 3</a>. Todas las BS deber&aacute;n transmitir peri&oacute;dicamente mensajes de forma <i>broadcast "beacons" </i>para informar a los MSS circundantes, tanto de su presencia como de su configuraci&oacute;n. Gracias a estos <i>beacons, </i>un MSS puede saber desde antes de ejecutar el procedimiento de HO, cu&aacute;les BSs vecinas est&aacute;n al alcance y qu&eacute; relaci&oacute;n SNR (se&ntilde;al/ ruido) guarda con cada una de ellas. Para garantizar que un cambio de BS sea transparente, es necesario que un MSS realice una asociaci&oacute;n de la etapa de <i>Ranging </i>y que se lleve acabo un pre&#150;registro con las BS vecinas, las cuales hacen que el cambio de BS sea mucho m&aacute;s r&aacute;pido. La asociaci&oacute;n de la etapa de <i>Ranging </i>(2) permite al MSS ponerse en sincron&iacute;a y ajustar su potencia de transmisi&oacute;n con las BS vecinas. La etapa de pre&#150;registro permite a un MSS negociar los par&aacute;metros de operaci&oacute;n, como por ejemplo: nuevos CIDs, estimaci&oacute;n de tipo de servicio &#150;QoS, tipo de modulaci&oacute;n, tipo de FEC y CRC, entre otros.</font></p>     <p align="center"><font face="verdana" size="2"><a name="f3"></a></font></p>     <p align="center"><font face="verdana" size="2"><img src="/img/revistas/iit/v9n1/a2f3.jpg"></font></p>     <p align="justify"><font face="verdana" size="2">El procedimiento de HO inicia cuando la BS servidora detecta que la se&ntilde;al proveniente del MSS empieza a caer por debajo de un umbral definido previamente (3), como se aprecia en la <a href="#f3">figura 3</a> y <a href="#t1">tabla 1</a>, &eacute;sta env&iacute;a el mensaje HO&#150;BS&#150;REQ (4) hacia el MSS para que dispare su mecanismo de HO. Por el contrario, cuando es el MSS, quien detecta una se&ntilde;al d&eacute;bil proveniente de la BS servidora, el proceso de HO empieza en el paso (5) de la <a href="#f3">figura 3</a>. Hecho esto, el MSS env&iacute;a el mensaje HO&#150;REQ a la BS servidora como respuesta (5). Dentro de este mensaje se deben incluir los datos obtenidos a trav&eacute;s de los <i>beacons </i>y las etapas de asociaci&oacute;n  de <i>ranging </i>y pre&#150;registro,  como mediciones de SNR y tipo de calidad de servicio requerida. El MSS deber&aacute; esperar la llegada del mensaje <i>HO&#150;RSP&#150;MSS </i>(9) de la BS servidora. En paralelo, la BS servidora manda el mensaje <i>HO&#150;REQ&#150;NOT</i>(6) a cada una de las BSs vecinas que el MSS ha incluido dentro del mensaje <i>HO&#150;REQ. </i>El mensaje <i>HO&#150;REQ&#150;NOT </i>contiene entre otros par&aacute;metros la QoS y el tipo de conexi&oacute;n que el MSS necesita para continuar con su operaci&oacute;n actual. Cada BS vecina que haya recibido el mensaje <i>HO&#150;REQ&#150;NOT, </i>deber&aacute; enviar como respuesta el mensaje <i>HO&#150; RSP&#150;NOT </i>(7) a la BS servidora. Si la BS vecina puede aceptar al MSS con los requerimientos especificados, deber&aacute; incluir el CID que el MSS ocupar&aacute; dentro de esta BS vecina, tambi&eacute;n deber&aacute; mencionar si necesita m&aacute;s informaci&oacute;n del MSS. Si la BS vecina no puede aceptar al MSS con lo requerimientos espec&iacute;ficos, podr&aacute; incluir adem&aacute;s, otra QoS inferior que pudiera en su caso concederle al MSS. Cabe destacar que el env&iacute;o de mensajes entre BS se realiza mediante un enlace dedicado y con la mayor prioridad, por lo que no se requiere ning&uacute;n m&eacute;todo de acceso para el env&iacute;o de los mismos, y por lo tanto, los mensajes entre BS deber&aacute;n intercambiarse de una forma fluida y sin contratiempo.</font></p>     <p align="center"><font face="verdana" size="2"><a name="t1"></a></font></p>     <p align="center"><font face="verdana" size="2"><img src="/img/revistas/iit/v9n1/a2t1.jpg"></font></p>     <p align="justify"><font face="verdana" size="2">Una vez que la BS servidora ha detectado que todas  las  BSs vecinas  a quienes  les envi&oacute;  el mensaje <i>HO&#150;REQ&#150;NOT </i>le han contestado con el mensaje <i>HO&#150;RSP&#150;NOT, </i>deber&aacute; recopilar toda la informaci&oacute;n y tomar la decisi&oacute;n de cu&aacute;l BS vecina ser&aacute; seleccionada como BS objetivo (8) (BS con quien se mudar&aacute; el MSS). Para la elecci&oacute;n de la BS objetivo, la BS servidora elegir&aacute; aquella que en primer lugar pueda atender de la mejor forma al MSS de acuerdo con sus necesidades de QoS y BW. En caso de que varias BSs vecinas tengan total disponibilidad para atender al MSS, entonces la que tenga mejor SNR ser&aacute; elegida como BS objetivo. En este punto, la BS servidora mandar&aacute; dos mensajes, el primero de ellos <i>HO&#150;RSP&#150;MSS </i>(8) ir&aacute; dirigido al MSS, y dentro del mismo se informar&aacute; cu&aacute;l BS ha sido marcada como BS objetivo, as&iacute; como el CID que ser&aacute; v&aacute;lido con esta BS. El segundo mensaje <i>HO&#150;RSP&#150;BS </i>(8) se mandar&aacute; exclusivamente a la BS vecina que ha sido marcada como BS objetivo. Dentro del mensaje, se indica el CID del MSS (el que tiene actualmente) que va a realizar el HO, y si es el caso, m&aacute;s informaci&oacute;n relativa al mismo.</font></p>     ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">La BS vecina, que ha sido seleccionada como objetivo, empezar&aacute; a asignar <i>slots unicast </i>para <i>ranging (IEs), para el nuevo MSS que est&aacute; en proceso de HO (10), con lo cual se evita la regi&oacute;n de contenci&oacute;n, que es la etapa que produce m&aacute;s del 90 % de los retardos en un HO como se indica en (Cota, 2000). Por otra parte, el MSS una vez que ha recibido el mensaje HO&#150;RSP&#150;MSS, </i>dejar&aacute; de transmitir datos aunque tenga paquetes pendientes en la cola de espera. Si un paquete se genera en este momento, ser&aacute; trasladado hacia una cola especial mientras termina la parte cr&iacute;tica del cambio de conexi&oacute;n a la BS objetivo (BS2). Ahora el MSS cierra conexiones con la BS servidora y cambia las frecuencias tanto en su transmisor como en su receptor para sincronizarse nuevamente con la BS objetivo. Durante el proceso de inicializaci&oacute;n con la BS objetivo (11), las etapas de "negociar capacidades b&aacute;sicas" y "autorizaci&oacute;n e intercambio de llaves" son ignoradas, ya que los par&aacute;metros que son intercambiados durante estas etapas ya han sido traspasadas entre la BS servidora y la BS objetivo mediante el mensaje HO&#150;<i>RSP&#150;BS. </i>La etapa de "transferir par&aacute;metros adicionales" tambi&eacute;n es ignorada porque no se espera que estos par&aacute;metros cambien. La etapa de "tiempo del d&iacute;a" ya ha sido establecida durante el proceso de inicializaci&oacute;n normal,  por lo que no es necesario que se lleve a cabo otra vez. Las etapas de "registrarse con la BS" y "levantar las conexiones", debido a su naturaleza, deber&aacute;n ser completadas r&aacute;pidamente. Cuando el MSS est&aacute; trabajando bajo el protocolo IP, necesita forzosamente ejecutar la fase "establecer conexi&oacute;n IP".</font></p>     <p align="justify"><font face="verdana" size="2">Existen varias propuestas para movilidad con IP (Campbell et <i>al., </i>2002), aunque Mobile IP (Perkins, 1997) suena como la m&aacute;s recomendable, ya que el nodo establece direcciones IP temporales con la BS objetivo, por lo que no es necesario que ejecute nuevamente el mecanismo DHCP (Dynamic Host Control Protocol) para la obtenci&oacute;n de una nueva direcci&oacute;n IP. En la siguiente secci&oacute;n se presenta un an&aacute;lisis del comportamiento din&aacute;mico que se tendr&iacute;a hasta la etapa de "establecer conexi&oacute;n IP".</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Modelo de simulaci&oacute;n y resultados</b></font></p>     <p align="justify"><font face="verdana" size="2">Para la implementaci&oacute;n de nuestro algoritmo de HO, se utiliz&oacute; el simulador OPNET MODELER v.11, el cual permiti&oacute; analizar los retardos de propagaci&oacute;n de los paquetes generados por los nodos m&oacute;viles, as&iacute; como la tasa de transmisi&oacute;n instant&aacute;nea durante el cambio de conexi&oacute;n, par&aacute;metros que indicar&aacute;n la calidad de nuestro mecanismo de HO. En las simulaciones que llevamos a acabo, algunas aplicaciones como VoIP, exigen retardos de propagaci&oacute;n del orden de 20 a 50 ms (Rangel, <i>et al., </i>2001&#150;b) que garantizan la ausencia de ecos durante el per&iacute;odo de conversaci&oacute;n.</font></p>     <p align="justify"><font face="verdana" size="2">Por otro lado, una disminuci&oacute;n en la tasa de transmisi&oacute;n durante el HO, har&iacute;a que la conversaci&oacute;n fuese de mala calidad o incluso intangible. Algunas otras aplicaciones no son tan exigentes en este aspecto, tal es el caso de tr&aacute;fico tipo Internet, el cual es generalmente asociado con una QoS de BE.</font></p>     <p align="justify"><font face="verdana" size="2">Para las simulaciones realizadas se utiliz&oacute; un modelo jer&aacute;rquico como el que se muestra en la <a href="/img/revistas/iit/v9n1/a2f4.jpg" target="_blank">figura 4</a>, donde en el nivel m&aacute;s alto se encuentran los componentes de la red, en este caso las BSs, los SSs y los MSSs (<a href="/img/revistas/iit/v9n1/a2f4.jpg" target="_blank">Figura 4A</a>). En el siguiente nivel, se define el modo de operaci&oacute;n de los componentes del nivel superior mediante bloques que representan sus componentes internos como pueden ser: el generador de tr&aacute;fico, las antenas, la capa MAC, etc&eacute;tera (<a href="/img/revistas/iit/v9n1/a2f4.jpg" target="_blank">figura 4.B</a>). El siguiente nivel define la operaci&oacute;n de cada uno de los bloques anteriormente mencionados mediante FSM (m&aacute;quinas de estado finito) como se aprecia en la <a href="/img/revistas/iit/v9n1/a2f4.jpg" target="_blank">figura 4.C</a>. Finalmente, el nivel m&aacute;s bajo define mediante c&oacute;digo Proto C, el funcionamiento de cada uno de los estados dentro de un FSM.</font></p>     <p align="justify"><font face="verdana" size="2">El escenario utilizado en las simulaciones, est&aacute; formado por tres estaciones base de igual capacidad y de misma distancia de cobertura con una configuraci&oacute;n tipo celular, como se aprecia en la <a href="#f5">figura 5</a>. La cantidad de nodos que cada BS puede soportar, depender&aacute; del tr&aacute;fico que genere cada uno de ellos. Para la comunicaci&oacute;n inter&#150;BS se utilizaron enlaces duplex dedicados con una capacidad E1 (2048 kbps). Los par&aacute;metros utilizados durante las simulaciones se muestran en la <a href="#t2">tabla 2</a>.</font></p>     <p align="center"><font face="verdana" size="2"><a name="f5"></a></font></p>     <p align="center"><font face="verdana" size="2"><img src="/img/revistas/iit/v9n1/a2f5.jpg"></font></p>     ]]></body>
<body><![CDATA[<p align="center"><font face="verdana" size="2"><a name="t2"></a></font></p>     <p align="center"><font face="verdana" size="2"><img src="/img/revistas/iit/v9n1/a2t2.jpg"></font></p>     <p align="justify"><font face="verdana" size="2">Para el estudio del comportamiento din&aacute;mico se utilizaron dos tipos de tr&aacute;fico:</font></p>     <blockquote>       <p align="justify"><font face="verdana" size="2">1) Tr&aacute;fico Internet (IP). Para este tipo de tr&aacute;fico se utiliz&oacute; la distribuci&oacute;n presentada en (Rangel, et <i>al., </i>2001&#150;b) en donde la distribuci&oacute;n de los mensajes es como sigue: Tramas de 64 bytes 60%, Tramas de 128 bytes 6%, Tramas de 256 bytes 4%, Tramas de 512 bytes 2%, 1024 Tramas 25% y Tramas de 1518 bytes 3%. La tasa de transmisi&oacute;n para este tipo de tr&aacute;fico es de 38.4 kbps en la capa f&iacute;sica (o 32 kbps en la capa IEEE 802.16 MAC) y es atendido con una QoS de BE; y</font></p>       <p align="justify"><font face="verdana" size="2">2) Tr&aacute;fico VoIP. Se utiliz&oacute; el <i>codec </i>G723.1 (ITU&#150;T Recommendation G.723.1, 1996) en la modalidad de 5.3 kbps (frames de 20 bytes cada 30 ms), este <i>codec </i>es el recomendado por ITU (International Telecomunications Union) para enlaces de voz con bajo requerimiento. Este <i>codec </i>demanda una tasa de transmisi&oacute;n de 25.6 kbps en la capa f&iacute;sica y utiliza supresi&oacute;n de encabezados como se recomienda en (ETSI ES 200 800, 2001). El tr&aacute;fico de VoIP ser&aacute; atendido con una QoS UGS.</font></p> </blockquote>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Resultados para tr&aacute;fico Internet (con servicio Best Effort)</b></font></p>     <p align="justify"><font face="verdana" size="2"><a href="/img/revistas/iit/v9n1/a2f6.jpg" target="_blank">La figura 6</a>, muestra el <i>throughput </i>y los retardos obtenidos cuando un MSS lleva acabo el procedimiento de HO propuesto, para una QoS BE y un tr&aacute;fico de tipo Internet. En este an&aacute;lisis se consider&oacute; una red con 40 nodos, aproximadamente un 70% de su capacidad m&aacute;xima. Podemos apreciar que los retardos no son continuos, debido a la naturaleza de BE y al algoritmo exponential <i>backoff binario truncado, </i>como se muestra en la <a href="/img/revistas/iit/v9n1/a2f6.jpg" target="_blank">figura 6</a>.</font></p>     <p align="justify"><font face="verdana" size="2">El cambio de BS es transparente al MSS por la asociaci&oacute;n de <i>ranging </i>y pre&#150;registro. El retardo aproximado, reportado por nuestro simulador, para el cambio de BS fue de 11 ms. El la <a href="/img/revistas/iit/v9n1/a2f6.jpg" target="_blank">figura 6</a>, el retardo acumulado de MSS cuando env&iacute;a su primer mensaje en la nueva BS fue de 14.5 ms, la diferencia de 2.5 ms, es consecuencia del tiempo que tard&oacute; la nueva BS en hacer la reservaci&oacute;n del canal.</font></p>     ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">Para evitar el riesgo de colisi&oacute;n cuando un usuario se cambia de BS, la etapa de Reconocimiento de BS vecinas nos ayuda a simplificar la etapa m&aacute;s cr&iacute;tica del proceso de inicializaci&oacute;n, que es la etapa de <i>ranging. </i>En la figura los retardos provocados por esta etapa fueron de 2 ms (de los 11ms en total). Esto se logra al hacer que el usuario m&oacute;vil, mucho antes de activar su mecanismo de HO, ya est&eacute; sincronizado y pre&#150;registrado con las estaciones base vecinas. La variaci&oacute;n del <i>throughput </i>se debe a la distribuci&oacute;n exponencial de las llegadas y la distribuci&oacute;n de los paquetes utilizada para modelar tr&aacute;fico tipo Internet, el cual oscila entre los 31 y 32 kbps en la capa IEEE 802.16 MAC.</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Resultados para tr&aacute;fico de voz (con servicio UGS)</b></font></p>     <p align="justify"><font face="verdana" size="2">La <a href="#f7">figura 7</a> muestra el retardo de los paquetes cuando se utiliza VoIP con una QoS de UGS. La raz&oacute;n por la que se aprecia un aumento de aproximadamente 30 ms despu&eacute;s de ejecutar el procedimiento de HO, es porque durante el cambio de conexi&oacute;n se le proh&iacute;be transmitir al MSS. Sin embargo, &eacute;ste sigue generando paquetes cada 30 ms por lo que despu&eacute;s de ejecutar el cambio de conexi&oacute;n, el MSS tiene un paquete en el buffer, esperando ser transmitido, &eacute;ste se desfasa un tiempo (igual al tiempo entre llegas de los frames de voz) como se aprecia en la <a href="/img/revistas/iit/v9n1/a2f8.jpg" target="_blank">figura 8</a>. Para solucionar este problema, se proponen tres m&eacute;todos:</font></p>     <p align="center"><font face="verdana" size="2"><a name="f7"></a></font></p>     <p align="center"><font face="verdana" size="2"><img src="/img/revistas/iit/v9n1/a2f7.jpg"></font></p>     <blockquote>       <p align="justify"><font face="verdana" size="2">A) Eliminar  los  paquetes  generados  en  el lapso de HO.</font></p>       <p align="justify"><font face="verdana" size="2">B) Conceder m&aacute;s <i>slots </i>al MSS despu&eacute;s del proceso de HO para que pueda transmitir los paquetes pendientes.</font></p>       <p align="justify"><font face="verdana" size="2">C) Aprovechar los momentos de silencio para ajustar el retardo enviando el paquete que se encuentre en ese momento en la cola de espera.</font></p> </blockquote>     ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">La <a href="/img/revistas/iit/v9n1/a2f9.jpg" target="_blank">figura 9 </a>muestra los resultados obtenidos para A), B) y C), respectivamente. De la <a href="/img/revistas/iit/v9n1/a2f9.jpg" target="_blank">figura 9.A</a> se puede observar que el retardo ya no sufre aumentos, el peque&ntilde;o retardo que se sigue apreciando despu&eacute;s de ejecutar el procedimiento de HO, es debido al mecanismo de QoS UGS y no al proceso de HO. La variaci&oacute;n del retardo del MSS que se aprecia en la <a href="/img/revistas/iit/v9n1/a2f9.jpg" target="_blank">figura 9.A</a>, antes de ejecutar el procedimiento de HO, es porque la BS est&aacute; cercana al punto de saturaci&oacute;n (aproximadamente a un 90% de su capacidad de carga m&aacute;xima), pero esta variaci&oacute;n est&aacute; dentro de los l&iacute;mites para soportar tr&aacute;fico de VoIP, el cual no excede los 50 ms de jitter permitidos. La reca&iacute;da en el <i>throughput </i>(en el tiempo 4.48s de la <a href="/img/revistas/iit/v9n1/a2f9.jpg" target="_blank">figura 9.A</a>) es resultado del paquete que se elimin&oacute;. De la <a href="/img/revistas/iit/v9n1/a2f9.jpg" target="_blank">figura 9.B</a><sup>3</sup> se puede ver que el paquete que es retenido hasta que el proceso de HO es completado, eleva moment&aacute;neamente los retardos. Sin embrago, el <i>throughput </i>se recupera con mayor rapidez que en el caso anterior. De nueva cuenta, la peque&ntilde;a diferencia que se sigue apreciado en el retardo despu&eacute;s del proceso de HO es por el mecanismo de UGS. Finalmente, de la figura <a href="/img/revistas/iit/v9n1/a2f9.jpg" target="_blank">9.C</a><sup>4</sup> podemos concluir que los momentos de silencio pueden ser bien aprovechados, ya que efectivamente el retardo es nuevamente ajustado sin necesidad de tirar paquetes o de consumir m&aacute;s <i>slots.</i></font></p>     <p align="justify"><font face="verdana" size="2">Para ambos escenarios (Internet y VoIP), no se incluy&oacute; una discusi&oacute;n en este art&iacute;culo sobre el impacto de los errores de canal, debido a limitaciones de espacio. Los errores en el canal inal&aacute;mbrico pueden degradar el servicio (QoS) asignado a los MSS en varias formas. Por ejemplo, para el servicio UGS, la p&eacute;rdida de paquetes en el canal inal&aacute;mbrico debido a errores pueden representar una violaci&oacute;n de incumplimiento del acuerdo de la clase de servicio asignado al MSS. Para solucionar este problema, estamos investigando nuevas formas de asignaci&oacute;n de recursos de aire en Ortiz (2006) y Rangel (2005). Una soluci&oacute;n a este problema ser&iacute;a la asignaci&oacute;n de oportunidades de transmisi&oacute;n adicionales a los MSS que enfrentan problemas de comunicaci&oacute;n, por causa de interferencias, para poder mantener la QoS contratada por el MSS.</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Conclusiones</b></font></p>     <p align="justify"><font face="verdana" size="2">Este art&iacute;culo colabora a los esfuerzos por situar al protocolo IEEE 802.16 como una tecnolog&iacute;a de vanguardia, al hacer propuestas y proponer soluciones contra los obst&aacute;culos que implica la adici&oacute;n de movilidad.  Durante el  desarrollo del mismo, se demuestra que IEEE 802.16 cuenta con los elementos necesarios para mantener la QoS dentro de los par&aacute;metros exigidos durante el cambio de conexi&oacute;n (HO). Se ha desarrollado una propuesta de HO funcional, que ha sido probada bajo los esquemas de UGS y BE con dos formas distintas de tr&aacute;fico: Internet y VoIP. En lo que a tr&aacute;fico de Internet con un servicio BE respecta, se ha obtenido que el tiempo de ejecuci&oacute;n de HO var&iacute;a de forma directamente proporcional al n&uacute;mero de usuarios en operaci&oacute;n, ya que a mayor cantidad de usuarios, mayor n&uacute;mero de colisiones, y por lo tanto, mayores retardos (para BE, no se evita la regi&oacute;n de contenci&oacute;n durante el proceso de HO). Si consideramos que BE est&aacute; dise&ntilde;ado para usuarios, cuyos servicios no son exigentes, entonces se ha desarrollado un mecanismo de  HO que no consume recursos innecesarios para un servicio que no lo necesita. Para el caso de VoIP con una QoS de tipo UGS, se ha demostrado que se pueden cumplir con las exigencias de retardo, al no sobrepasar los 50 ms de tiempo tolerados por este tipo de aplicaciones. Actualmente se investigan nuevas formas de asignaci&oacute;n de recursos para diferentes clases de servicio (UGS, rtPS, nrtPS y BE), as&iacute; como an&aacute;lisis del impacto que tienen los errores del canal inal&aacute;mbrico sobre la QoS asignada a los MSS.</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Agradecimientos</b></font></p>     <p align="justify"><font face="verdana" size="2">A la Direcci&oacute;n General de Asuntos del Personal Acad&eacute;mico de la UNAM, por su apoyo y financiamiento en la culminaci&oacute;n del proyecto PAPIIT No IN110805 e IN104907.</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Referencias</b></font></p>     ]]></body>
<body><![CDATA[<!-- ref --><p align="justify"><font face="verdana" size="2">Campbell A., G&oacute;mez J., Kim S. y Wan C.Y. Comparison of IP Micromobility Protocols. <i>IEEE Wireless Communications, </i>9: 72&#150;82, 2002.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239757&pid=S1405-7743200800010000200001&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Cota E. Dise&ntilde;o de procedimientos Handoff en redes inal&aacute;mbricas de banda ancha basado en el est&aacute;ndar IEEE 802.16. Tesis (Maestr&iacute;a en ingenier&iacute;a el&eacute;ctrica). M&eacute;xico. Divisi&oacute;n de Estudios de Posgrado, UNAM. Junio 2005.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239758&pid=S1405-7743200800010000200002&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Eklund C., Marks R., Standwood K.L., y Wang S. IEEE standard 802.16: A Technical overview of the wireless MANTM air interface for broadband wireless access. <i>IEEE Communications Magazine, 40 (6): 2002, 98&#150;107. 2002.</i></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239759&pid=S1405-7743200800010000200003&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">ESTI ES200 800. Digital video broadcasting: Interaction channel for cable TV distribution system (CATV). ESTI, Ver. 1.3.1, 2001</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239760&pid=S1405-7743200800010000200004&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Perkins C. Mobile IP. <i>IEEE Communications Magazine, 40 (5): 66&#150;82. 1997.</i></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239761&pid=S1405-7743200800010000200005&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Ortiz J. An&aacute;lisis y dise&ntilde;o de t&eacute;cnicas de calidad de servicio en redes inal&aacute;mbricas de banda ancha. Tesis (Maestr&iacute;a en ingenier&iacute;a el&eacute;ctrica). M&eacute;xico. Divisi&oacute;n de Estudios de Posgrado, UNAM. Enero 2006.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239762&pid=S1405-7743200800010000200006&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Rangel V., Edwards, R. and K. Shunke (2001&#150;a). Contention resolution algorithms for CATV network based on the DVB/DAVIC cable modem protocol specification (ETS EN 200 800). In: Proc. of IBC. Vol. 1, Amsterdam, 2001, pp 193&#150;202, Sept.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239763&pid=S1405-7743200800010000200007&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Rangel V., Edwards, R. (2001&#150;b). Performance analysis and optimization of the digital video broadcasting/digital audio visual council cable modem protocol for the delivery of isochronous stream. In: Proc. of IEEE GLO&#150; BECOM. Vol. 1, 2001, pp. 430&#150;434, Nov.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239764&pid=S1405-7743200800010000200008&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">Rangel V., G&oacute;mez J. (2005). Performance Analysis of QoS Scheduling in Broadband IEEE 802.16 Based Networks. Enviado a IEEE ICC&#150;2006.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239765&pid=S1405-7743200800010000200009&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2"><b>Bibliograf&iacute;a sugerida</b></font></p>     <!-- ref --><p align="justify"><font face="verdana" size="2">IEEE 802.16 e. Part 16: Air interface for Fixed Broadband Wireless Access System. IEEE 802. 16 Working Group, October 2004.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239768&pid=S1405-7743200800010000200010&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><p align="justify"><font face="verdana" size="2">ITU&#150;T Recommendation G.723.1. Speech coders: Dual rate speech coder multimedia communications transmitting at 5.3 and 6.3 kbits/s. ITU, 1996.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=4239769&pid=S1405-7743200800010000200011&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     <p align="justify"><font face="verdana" size="2"><b>Notas</b></font></p>     <p align="justify"><font face="verdana" size="2">1 La licencia de operaci&oacute;n de OPNET MODELER v. 11, se obtuvo a trav&eacute;s del proyecto UNAM&#150;PAPIIT N&deg; 1N&#150;110805 "T&eacute;cnicas de mejoramiento de capacidad de redes inal&aacute;mbricas de banda ancha".</font></p>     <p align="justify"><font face="verdana" size="2">2 M&eacute;todo para solicitar m&aacute;s ancho de banda utilizando cabeceras extendidas dentro de los paquetes de datos para evitar entrar en la regi&oacute;n de contenci&oacute;n cada vez que se requiera transmitir un nuevo paquete.</font></p>     <p align="justify"><font face="verdana" size="2">3 Para la <a href="/img/revistas/iit/v9n1/a2f9.jpg" target="_blank">gr&aacute;fica 9.B</a>, se utilizaron solo 2 minislot para contenci&oacute;n por mapa.</font></p>     <p align="justify"><font face="verdana" size="2">4 La escala en el eje "X" de la <a href="/img/revistas/iit/v9n1/a2f9.jpg" target="_blank">figura 9.C</a> no es lineal, existen tiempos muertos entre las r&aacute;fagas de paquetes.</font></p>     <p align="justify"><font face="verdana" size="2">&nbsp;</font></p>     ]]></body>
<body><![CDATA[<p align="justify"><font face="verdana" size="2">S<b>emblanza de los autores</b></font></p>     <p align="justify"><font face="verdana" size="2"><i>V&iacute;ctor Rangel&#150;Licea. </i>En 1996, se titul&oacute; como ingeniero en computaci&oacute;n en la Facultad de Ingenier&iacute;a, UNAM. En 1998, recibi&oacute; el grado de maestr&iacute;a en telem&aacute;tica, otorgado por la Universidad de Sheffield, Reino Unido. Posteriormente se gradu&oacute; como doctor en telecomunicaciones por la misma instituci&oacute;n en el 2002. Durante su estancia en el extranjero, labor&oacute; en ARRIS INTERACTIVE (Boston) y NETTONICS Ltd. (Sheffield) como consultor. Sus l&iacute;neas de investigaci&oacute;n se orientan a t&eacute;cnicas de optimizaci&oacute;n en redes celulares y redes inal&aacute;mbricas de banda ancha. Desde 2002, es profesor e investigador del Departamento de Telecomunicaciones de la UNAM y pertenece al SNI.</font></p>     <p align="justify"><font face="verdana" size="2"><i>Javier G&oacute;mez&#150;Castellanos. </i>Obtuvo el grado de ingeniero mec&aacute;nico electricista en 1993 por la UNAM, as&iacute; como los grados de maestro en ciencias y el doctorado en telecomunicaciones en 1996 y 2002, respectivamente, ambos por la Universidad de Columbia, Nueva York, E.U. Trabaj&oacute; en el IBM TJ&#150;Watson Research Center en Hawthorne, New York. Sus intereses de investigaci&oacute;n incluyen QoS, dise&ntilde;o de algoritmos eficientes de energ&iacute;a y redes de sensores inal&aacute;mbricos, as&iacute; como redes <i>ad hoc. </i>Desde el oto&ntilde;o del 2002, se desempe&ntilde;a como profesor titular en el Departamento de Ingenier&iacute;a en Telecomunicaciones de la Universidad Nacional Aut&oacute;noma de M&eacute;xico y pertenece al SNI.</font></p>     <p align="justify"><font face="verdana" size="2">Jos&eacute; <i>Eduardo Cota&#150;Guajardo. </i>Se titul&oacute; como ingeniero electr&oacute;nico en 2001 por el ITC (Instituto Tecnol&oacute;gico de Culiac&aacute;n) en Culiac&aacute;n, Sinaloa; becado por fundaci&oacute;n Telmex. En el a&ntilde;o de 2005, obtuvo el grado de maestro en ingenier&iacute;a el&eacute;ctrica por parte de la UNAM, en el &aacute;rea de redes inal&aacute;mbricas de banda ancha. Durante su estancia en el posgrado, particip&oacute; en el proyecto PAPIIT No: 1N&#150;110805 y fue becado por fundaci&oacute;n Telmex y CONACYT. Actualmente reside en Culiac&aacute;n, Sinaloa, en donde busca continuar bajo la misma l&iacute;nea de investigaci&oacute;n de redes inal&aacute;mbricas.</font></p>     <p align="justify"><font face="verdana" size="2">Jes&uacute;s <i>Reyes&#150;Garc&iacute;a. </i>Es ingeniero mec&aacute;nico electricista por la Facultad de Ingenier&iacute;a de la UNAM. Realiz&oacute; sus estudios de maestr&iacute;a en ingenier&iacute;a el&eacute;ctrica (&Aacute;rea de comunicaciones) en el Posgrado de Ingenier&iacute;a de la UNAM. Ha sido profesor de tiempo completo en el &aacute;rea de telecomunicaciones durante los &uacute;ltimos 27 a&ntilde;os en la Facultad de Ingenier&iacute;a de la UNAM. Ha impartido materias relacionadas con el electromagnetismo aplicado, sistemas de comunicaciones, comunicaciones &oacute;pticas y sistemas de radiocomunicaciones. Ha dirigido m&aacute;s de 50 tesis y participado en diversas conferencias. Fue uno de los profesores que particip&oacute; en la creaci&oacute;n de la carrera de ingenier&iacute;a en telecomunicaciones en la Facultad de Ingenier&iacute;a de la UNAM.</font></p>      ]]></body><back>
<ref-list>
<ref id="B1">
<nlm-citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Campbell]]></surname>
<given-names><![CDATA[A]]></given-names>
</name>
<name>
<surname><![CDATA[Gómez]]></surname>
<given-names><![CDATA[J]]></given-names>
</name>
<name>
<surname><![CDATA[Kim]]></surname>
<given-names><![CDATA[S]]></given-names>
</name>
<name>
<surname><![CDATA[Wan C]]></surname>
<given-names><![CDATA[Y]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[Comparison of IP Micromobility Protocols]]></article-title>
<source><![CDATA[IEEE Wireless Communications]]></source>
<year>2002</year>
<numero>9</numero>
<issue>9</issue>
<page-range>72-82</page-range></nlm-citation>
</ref>
<ref id="B2">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Cota]]></surname>
<given-names><![CDATA[E]]></given-names>
</name>
</person-group>
<source><![CDATA[Diseño de procedimientos Handoff en redes inalámbricas de banda ancha basado en el estándar IEEE 802.16]]></source>
<year>Juni</year>
<month>o </month>
<day>20</day>
</nlm-citation>
</ref>
<ref id="B3">
<nlm-citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Eklund]]></surname>
<given-names><![CDATA[C]]></given-names>
</name>
<name>
<surname><![CDATA[Marks]]></surname>
<given-names><![CDATA[R]]></given-names>
</name>
<name>
<surname><![CDATA[Standwood K]]></surname>
<given-names><![CDATA[L]]></given-names>
</name>
<name>
<surname><![CDATA[Wang]]></surname>
<given-names><![CDATA[S]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[IEEE standard 802.16: A Technical overview of the wireless MANTM air interface for broadband wireless access]]></article-title>
<source><![CDATA[IEEE Communications Magazine]]></source>
<year>2002</year>
<volume>40</volume>
<numero>6</numero>
<issue>6</issue>
<page-range>98-107</page-range></nlm-citation>
</ref>
<ref id="B4">
<nlm-citation citation-type="book">
<source><![CDATA[ESTI ES200 800. Digital video broadcasting: Interaction channel for cable TV distribution system (CATV)]]></source>
<year>2001</year>
<publisher-name><![CDATA[ESTI]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B5">
<nlm-citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Perkins]]></surname>
<given-names><![CDATA[C]]></given-names>
</name>
<name>
<surname><![CDATA[Mobile]]></surname>
<given-names><![CDATA[IP]]></given-names>
</name>
</person-group>
<source><![CDATA[IEEE Communications Magazine]]></source>
<year>1997</year>
<volume>40</volume>
<numero>5</numero>
<issue>5</issue>
<page-range>66-82</page-range></nlm-citation>
</ref>
<ref id="B6">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Ortiz]]></surname>
<given-names><![CDATA[J]]></given-names>
</name>
</person-group>
<source><![CDATA[Análisis y diseño de técnicas de calidad de servicio en redes inalámbricas de banda ancha]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B7">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Rangel]]></surname>
<given-names><![CDATA[V]]></given-names>
</name>
<name>
<surname><![CDATA[Edwards]]></surname>
<given-names><![CDATA[R]]></given-names>
</name>
<name>
<surname><![CDATA[Shunke]]></surname>
<given-names><![CDATA[K]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[Contention resolution algorithms for CATV network based on the DVB/DAVIC cable modem protocol specification (ETS EN 200 800)]]></article-title>
<source><![CDATA[Proc. of IBC]]></source>
<year>2001</year>
<month>-a</month>
<day>20</day>
<volume>1</volume>
<page-range>193-202</page-range><publisher-loc><![CDATA[Amsterdam ]]></publisher-loc>
</nlm-citation>
</ref>
<ref id="B8">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Rangel]]></surname>
<given-names><![CDATA[V]]></given-names>
</name>
<name>
<surname><![CDATA[Edwards]]></surname>
<given-names><![CDATA[R]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[Performance analysis and optimization of the digital video broadcasting/digital audio visual council cable modem protocol for the delivery of isochronous stream]]></article-title>
<source><![CDATA[Proc. of IEEE GLO- BECOM]]></source>
<year>2001</year>
<month>-b</month>
<day>20</day>
<volume>1</volume>
<page-range>430-434</page-range></nlm-citation>
</ref>
<ref id="B9">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Rangel]]></surname>
<given-names><![CDATA[V]]></given-names>
</name>
<name>
<surname><![CDATA[Gómez]]></surname>
<given-names><![CDATA[J]]></given-names>
</name>
</person-group>
<source><![CDATA[Performance Analysis of QoS Scheduling in Broadband IEEE 802.16 Based Networks]]></source>
<year>2005</year>
</nlm-citation>
</ref>
<ref id="B10">
<nlm-citation citation-type="book">
<source><![CDATA[IEEE 802.16 e: Part 16: Air interface for Fixed Broadband Wireless Access System]]></source>
<year>Octo</year>
<month>be</month>
<day>r </day>
<publisher-name><![CDATA[IEEE 802. 16 Working Group]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B11">
<nlm-citation citation-type="book">
<source><![CDATA[ITU-T Recommendation G.723.1. Speech coders: Dual rate speech coder multimedia communications transmitting at 5.3 and 6.3 kbits/s.]]></source>
<year>1996</year>
<publisher-name><![CDATA[ITU]]></publisher-name>
</nlm-citation>
</ref>
</ref-list>
</back>
</article>
