Aquí expongo brevemente algunas de las mejores técnicas que conozco para este fin:

1) Esquemas de modulación más altos

Los enlaces de microondas en el backhaul utilizan casi siempre modulación de amplitud en cuadratura o QAM , que modula tanto la amplitud como la fase de una señal. Desde QPSK hasta 4096-QAM, se puede incrementar el esquema de modulación para obtener mejoras en la capacidad total.

Sin embargo, hay que tener en cuenta que este incremento no es lineal y las mejoras sobre el throughput están bastante limitadas. Probablemente a partir de los 1024-QAM no merezca la pena seguir duplicando el esquema de modulación.

Otra cuestión a tener en cuenta es que un incremento en la modulación se consigue siempre a expensas de la ganancia del sistema, lo cual resulta en radioenlaces más cortos.

2) Técnicas de polarización dual co-canal y XPIC

El uso de doble polarización Horizontal y Vertical permite, literalmente, duplicar la capacidad del canal. No obstante, esta simultaneidad implica la generación de una interferencia conocida como interferencia de polarización cruzada, que limita la calidad de la señal recibida. Para cancelar dicha interferencia es necesario incluir en el receptor un sistema que filtre la componente contrapolar. A este sistema se le ha llamado Cross-Polarization Interference Cancellation (XPIC). En este artículo os explicábamos más detalles sobre el tema y en este otro os contábamos cómo diseñar radioenlaces con la técnica XPIC.

3) Uso de múltiples canales de frecuencia

El uso de varios canales de frecuencia para un mismo link permite multiplicar el throughput total, pero esto tiene la desventaja de que se deberán contratar tantas licencias radio como canales se deseen utilizar.

4) Uso de modulación adaptativa o Adaptive Modulation

La incorporación en nuestro diseño de mecanismos como AM (Adaptive Modulation) permite una mejora en el throughput, aunque implica una severa disminución en determinados escenarios. AM funciona variando dinámicamente la modulación según las condiciones climatológicas: mientras haga buen tiempo, se utilizará la modulación más alta posible; por el contrario, cuando llueve o nieva, la modulación descenderá a esquemas inferiores que, consecuentemente, reducirán el throughput (pero garantizarán, sin embargo, la disponibilidad del radioenlace).

5) Utilizar canales más anchos

Los canales de telecomunicación estándar suelen ser de 7, 14, 28, 56 y 112 MHz. Es posible realizar un “upgrade” sobre las unidades radio para pasar de un canal más estrecho a otro más ancho. Este cambio conlleva costes en el link-budget, que deberá ser actualizado y nos obligará, por tanto, a reajustar la potencia necesaria (o el tamaño de las antenas) para que la transmisión soporte un ancho de banda mayor sin incumplir los niveles de calidad y disponibilidad.

La entrada 5 técnicas para incrementar el throughput de un enlace de microondas terrestre se publicó primero en BorrowBits.

Un poco de lluvia nunca viene mal. Pero cuando hablamos de enlaces de microondas puede convertirse en un verdadero problema… La atenuación por lluvia o Rain Fade (RF) consiste en la absorción de parte de la señal debido a hidrometeoros como lluvia, nieve, granizo o niebla. También se considera parte de este fenómeno la degradación sufrida por la interferencia electromagnética en un frente tormentoso. En este artículo vamos a tratar de entender cómo predecirlo, así como a modelar su influencia a la hora de diseñar enlaces radio de alta disponibilidad.

Dependencia con la frecuencia y la polarización

El Rain Fade se puede obviar por debajo de los 5 GHz y se va haciendo más significativo conforme incrementamos la frecuencia. A partir de 10 GHz es más que conveniente tenerla en cuenta, ya que la atenuación empieza a ser superior a los 5 dB/km. Existe una recomendación (UIT-R  P.838) que permite modelar su influencia mediante un parámetro llamado atenuación específica (dB/km) que se obtiene a partir de la intensidad de lluvia (mm/h).

Como vemos en la gráfica, la atenuación específica aumenta drásticamente entre 10 GHz y 100 GHz, en proporción a la intensidad de la lluvia.

Además de una dependencia con la frecuencia, existe una dependencia con el tipo de polarización, siendo más acusada para la polarización Horizontal que para la Vertical (debido a la forma “achatada” que adquieren las gotas de lluvia durante la caída):

¿Cómo saber cuánto llueve en cada zona?

Existen varios modelos estadísticos para predecir cuánta lluvia va a caer al cabo del año. Normalmente, la mayoría de los microwave planner prefieren el modelo ITU-R P.837, que proporciona una serie de valores medios para cada zona hidrometeorológica:

Cada una de estas zonas se identifica con una letra (a España, por ejemplo, le corresponde las zonas K y H), y se le asocia una intensidad de lluvia media. A la postre sólo son valores estadísticos, pero resultan muy útiles para tratar de ofrecer una alta disponibilidad de nuestro radioenlace. Por ejemplo, si en la zona K llueve más de 42 mm/h durante menos del 0,01% del tiempo, para garantizar la disponibilidad del 99,99% será necesario realizar nuestros cálculos teniendo en cuenta dicha intensidad de lluvia.

Los valores de disponibilidad típicos son “tres nueves” (99,9%), “cuatro nueves” (99,99%) y el de mayor disponibilidad: “cinco nueves” (99,999%)

¿Cómo tener en cuenta la lluvia en un diseño real?

Las herramientas de simulación que utilizan los ingenieros de radioenlaces tienen en cuenta este fenómeno. Veamos un ejemplo práctico:

Supongamos que deseamos predecir la disponibilidad anual que tendrá un enlace de 7 km en relación a la atenuación por lluvia. El primer paso consistiría en averiguar qué zonas hidrometeorológicas vamos a atravesar. En base a las coordenadas de las estaciones A y B, obtendríamos una distribución del Rain Rate por nuestro programa de simulación:

Observamos que en nuestro ejemplo, el enlace va a atravesar dos zonas: a lo largo del 58.57% del enlace, la intensidad de lluvia será de 32 mm/h durante el 0.01% del tiempo; a lo largo del 41.43% restante obtendremos 30mm/h durante el 0.01% del tiempo. En general tomamos el peor caso posible para garantizar el mejor resultado.

Ojo con la polarización

Como os hemos contado antes, la lluvia afecta más a la polarización Horizontal que a la Vertical, con lo cual es importante diseñar el enlace teniendo en cuenta que nuestro peor valor de lluvia lo obtendremos para dicha polarización. Esto significa que si queremos diseñar un enlace en Horizontal o con polarización dual (Vertical y Horizontal a la vez), debemos realizar el cálculo de Rain Fade en dicha configuración.

Por último, sólo quedaría calcular la disponibilidad para nuestro valor de lluvia, que en la práctica se traduce a pulsar un botón que realiza “automágicamente” todas las operaciones matemáticas por nosotros:

Hemos obtenido un “cuatro nueves“, lo cual es un valor bastante bueno: significa que nuestro enlace va a estar disponible durante el 99.99% del tiempo…

¿Qué hacer si el valor de Rain Unavailability es demasiado alto?

Aunque cada caso tiene su solución particular, existen varias estrategias que nos permitirán obtener mejores valores frente a lluvia. En orden de preferencia (en general):

1. Aumentar la potencia de transmisión de
   los equipos.
2. Utilizar antenas de mayor diámetro.
3. Utilizar receptores con mayor sensibilidad.
4. Bajar de banda de frecuencia.
5. Bajar el ancho de banda.
6. Diseñar sólo en polarización vertical
7. Reducir la modulación mínima y usar un esquema adaptativo. 32QAM -> QPSK con “Adaptive Modulation (AMC)”
8. Activar la característica ATPC (Automatic Transmit Power Control), que regula automáticamente el nivel de potencia de transmisión en función del nivel recibido.

En general cualquier cosa que permita ajustar el Link Budget a la atenuación introducida por la lluvia. La lluvia en telecomunicaciones es un auténtico problema, pero como podéis ver tiene solución. Así que… ¡a mal tiempo, buena cara! Si os ha gustado el artículo, no dudéis en compartirlo y en dejarnos vuestros comentarios.

La entrada ¿En qué consiste el Rain Fade y cómo afecta al diseño de enlaces de microondas? se publicó primero en BorrowBits.

Hace unos años, imberbe, empecé a dar soporte técnico por mi cuenta a algunas empresas pequeñas. Te llamaban por teléfono y te pedían que les desinfectaras un ordenador de virus. Ibas a las oficinas, lo hacías y le pasabas la factura: son cinco mil…  ¡Ah pues oye! Ya que estás aquí, ¿por qué no le configuras a Pepi su cuenta de Outlook, que la pobre no sabe? Uno tiene buena fe y le da pena la pobre Pepi. Y total, que son cinco minutos y ya me he ganado cinco mil pesetas.  Empezaban así, con cositas inofensivas, y acababan llamándote a todas horas preguntándote dudas absurdas de las que poco o nada sabías acerca de cualquier cosa que tuviera pilas o conector USB. Y tú, hijo de buena familia y fan de Spiderman, no veías razón para no echarles una mano.

Un día me harté de que me tomaran el brazo cada vez que les ofrecía mi sudorosa mano y empecé a cobrar por las pequeñas cosas que me hacían perder cantidades ingentes de tiempo. Incluidas las exasperantes consultas telefónicas los sábados a las 8 de la mañana: Pues no puedo responder a eso ahora, señor Nerfández. Pero le ofrezco un servicio de asesoramiento excelente y baratísimo que puede contratar mensualmente, incluyendo atención telefónica, Skype, email… ¡Cabrón! Clic.

El cliente quiere garantía ilimitada y gratis. Y probablemente también quiera cazar elefantes en Botsuana con Su Majestad, y después ir a cenar con Alyssa Milano. ¿Pero quién eres tú, pobre ingeniero o programador mortal, para proveerle tales caprichos? ¿Acaso el servidor que le has instalado ha sufrido un ataque DoS porque tu política de seguridad era débil, o porque el jefe ha dejado entrar a su sobrino de 8 años en el cuarto de telecomunicaciones? ¿Es para solucionar un bug o para recordarle al secretario del gerente cómo se imprimen los albaranes? Pero si hasta les has enviado unos videotutoriales con Loquendo monísimos… Pero tu cliente insiste en cosas como que la interfaz es demasiado complicada, que la cámara IP instalada hace que la gente se vea un poco gorda y púrpura, que esperaba que ciertos campos se rellenasen automáticamente… Y por supuesto, que si la pifian en algún momento, se les aparezca el Hada Madrina y les solucione el entuerto. Porque si no viene, amigo mío, la culpa será tuya. Del informático. Ese tío raro que se pasa el día jugando con ordenadores. Que es un abuso eso de que, encima que no hace nada en condiciones, cobre por dedicarse a su hobby. Y válgame Dios.

Todas estas situaciones pueden parecer ridículamente exageradas, pero por desgracia la realidad supera a los ejemplos. Echad si no un vistazo al blog de Wardog, un BOFH (Bastard Operator From Hell) que cuenta sus desventuras en un entorno de lusers (loser + user) en clave humorística y cruel.

Delimitación moral de la responsabilidad. ¿Hasta qué punto es tu responsabilidad cargar con la cruz? Ésta es la cuestión. Ya hablamos en su día de la importancia de un contrato que delimite tu responsabilidad y que declare con la mayor exactitud las especificaciones y casos que tu proyecto de aplicación o sistema vayan a implementar. Y cuáles no. Muchas veces existirán lagunas de las que los clientes malvados tratarán de sacar partido y que te pueden llevar a un eterno proceso de mejora y desarrollo. Infinite debugging. Al final acabas haciéndoles todo su trabajo. Un ser humano, imperfecto en su naturaleza, jamás podría llegar a crear algo genuinamente perfecto. Es una reflexión ontológica que también se puede expresar de otra manera: Puede que tu aplicación sea perfecta, pero el usuario nunca lo es. ¿Recuerdas? Así pues, si crees que lo que tu cliente reclama es injusto, no te compete y no es de recibo, sencillamente no lo hagas. Y si lo haces, cóbrale por ello. Sin piedad. Ahí es donde duele.

No podemos olvidar que una empresa es un sistema que trata de optimizar beneficios y tú, como proveedor freelance de un servicio necesario, eres un gasto que quieren minimizar a toda costa. Siendo justos con la realidad económica que nos ha tocado vivir, nada hay de reprobable en ello. Simplemente debemos tenerlo en cuenta para que no nos tomen por el pito del sereno.

Continuará…

La entrada Cómo evitar ser un freelance esclavo (II) se publicó primero en BorrowBits.

Cuando se es un programador freelance neófito también se tiende a ser un poco ingenuo. Y el mundo empresarial es un lugar hostil, plagado de carroñeros oportunistas dispuestos a aprovecharse de cualquier resquicio de honestidad. Ésto no quiere decir que por tal de sobrevivir debamos vender nuestra alma al diablo, ni mucho menos. Pero sí se deben extremar las precacuciones, especialmente cuando llega el momento de firmar un contrato.

Imagina que vas a diseñar y programar una aplicación, un servicio web o una base de datos. ¿Qué cláusulas van a gobernar vuestro acuerdo? El cliente suele tenerlo bastante claro: quiere todas las garantías a corto, medio y largo plazo. Hasta aquí bien, es de pleno derecho que uno quiera asegurarse de que compra algo que funciona. El problema viene cuando no se saben definir correctamente los límites de este derecho: por ejemplo, el cliente puede pretender exigirnos asistencia técnica de por vida para su nuevo software – sí, estas cosas pasan -, o puede pretender que seamos nosotros mismos quienes se lo gestionemos a “nivel usuario”.

Hay que ser muy estúpido o estar muy desesperado para aceptar algo así. Pero claro, uno es un novato y lanzalibre: corren malos tiempos, no tenemos un sueldo a fin de mes, ni una cantidad fija de ingresos. Habrá que comer y pagar la Seguridad Social, ¿no? En un momento de desesperación podemos cometer el error de aceptar las condiciones que un cliente deshonesto nos exije.

Pan para hoy, malos ratos para mañana

“Total, seguro que todo va bien, no creo que luego haya problemas“, puedes querer pensar con la osadía del principiante. ¡Ah, juventud! Divino tesoro… Antes de empezar ya has omitido la Ley de Murphy y algunos de sus corolarios:

1. Siempre hay problemas a posteriori, por pequeños e insignificantes que sean.
2. Puede que tu aplicación sea perfecta, pero el usuario nunca lo es. Al fin y al cabo estás programando para humanos, ¿no?
3. Todo fluye, nada permanece. Y los lenguajes de programación, sus estándares y sus librerías ¡menos aún! Lo primero lo decía Heráclito, pero lo segundo es de sentido común.
4. El cliente ha pagado y por tanto siempre tiene la razón. Incluso cuando no la tiene. El empresario va a querer exprimir al máximo la inversión que ha hecho, a tu costa claro. Dado que él tiene razón y tú no, sólo una barrera se interpone entre él y tu libertad: el contrato.

Si olvidas estas máximas a la hora de redactar tus condiciones, corres el gran peligro de someterte a una esclavitud consentida y perfectamente legal. Lo que se dice pan para hoy, y muchos malos ratos para mañana.

Detalles más específicos para evitar estas dolorosas situaciones en la siguiente entrega. ¿Habéis sufrido experiencias similares en vuestros comienzos?

La entrada Cómo evitar ser un freelance esclavo (I) se publicó primero en BorrowBits.