Con el paso del tiempo, también se ha convertido en la tecnología de transporte más utilizada del mundo por proveedores de Internet y telefonía celular, ya que además de agilizar el backbone de telecomunicaciones, permite crear redes VPN muy seguras entre diferentes países, implementar Pseudowires (PWE3 o CES), o incluso segregar fácilmente tráfico con necesidades de QoS como VoIP.

MPLS se encarga de dirigir los datos de un nodo de red al siguiente utilizando etiquetas de ruta en lugar de direcciones de red. De esta forma conseguimos agilizar la red, pues los nodos no tienen que desencapsular direcciones de red muy largas y cotejarlas en una tabla de enrutamiento.

A MPLS se le conoce a menudo como un protocolo Layer 2.5, pues se encuentra entre la capa 2 y la capa 3 del modelo OSI.

La M de MPLS, viene de Multiprotocolo porque una ruta MPLS puede transportar cualquier cosa encima de cualquier cosa, independientemente del protoclo subyacente, sea Ethernet, ATM, PPP, SONET… A esta característica también se la conoce como AToM, de “Any Transport over MPLS“. Esa es una de las razones por las que las redes MPLS son tan versátiles.

Por ejemplo, podríamos etiquetar un paquete IP (Capa 3 – Red) con MPLS (Capa 2.5), que iría encapsulado sobre Ethernet (Capa 2 – Enlace), que a su vez estaría transportado sobre un canal óptico (Capa 1 – Física):

Terminología

Label

La susodicha “Etiqueta”. Los números de etiqueta del 0 al 15 están reservados para propósitos especiales. Por tanto no pueden utilizarse por un LSR (ver más abajo) para transmisiones normales. Cada etiqueta reservada tiene su función específica; por ejemplo, la etiqueta 3 significa NULL y la 14 es una alerta OAM.

MPLS VPN

La creación de redes privadas virtuales (VPN) sobre redes MPLS permite conectar diferentes clientes ubicados en diferentes zonas geográficas a través de un proveedor de servicios. En próximos artículos hablaremos de esta potentísima aplicación (¿te avisamos?).

CE (Customer Edge)

Se trata del dispositivo ubicado en el extremo del cliente. Puede ser cualquier enrutador que se use para comunicarse con el proveedor.

PE (Provider Edge)

Es un dispositivo en el extremo o en la frontera del proveedor, es decir, donde los clientes “terminan” (se conectan). Los encaminadores PE pueden hacer conmutación de etiquetas MPLS, así como examinar cabeceras IP.

P (Provider Router)

Son encaminadores ubicados en el núcleo del proveedor (core) y su interconexión conforman el así llamado “backbone MPLS”. El encaminamiento se realiza exclusivamente examinando sólo la etiqueta MPLS de cada paquete.

LSR (Label Switched Router)

También llamado róuter de tránsito. Algunos pueden ser de ingreso (Ingress LSR) o de regreso (Egress LSR). Tanto uno como otro se conocen como LER (Label Edge Router), ya que son responsables tanto de poner como de quitar etiquetas MPLS en las fronteras del dominio MPLS.

LSP (Label Switched Path)

Son los caminos en las redes MPLS a través de los cuáles viajan los flujos de tráfico.

VRF (Virtual Router and Forwarding)

Tablas de encaminamiento virtuales creadas en los PE routers para diferentes VPNs. VRF es un término Cisco, por su parte Huawei lo llama “Instancia VPN” (VPN Instance) y en Juniper se conoce como “Instancia de encaminamiento ” (Routing Instance).

FEC (Forwarding Equivalence Class)

Es un grupo de paquetes IP que son tratados de la misma manera sobre un mismo camino. Un FEC puede ser por ejemplo todas las IP de una subred o cualquier tráfico que sea tratado de la misma manera con respecto a unos parámetros QoS/CoS determinados.

CEF (Cisco Express Forwarding)

CEF is una tecnología IP de conmutación avanzada de Cisco que permite realizar una conmutación a nivel hardware para optimizar la performance. Huawei y Juniper también tienen sus tecnologías propietarias de fast-forwarding.

LDP (Label Distribution Protocol)

Es un protocolo utilizado para intercambiar información de enrutamiento de etiquetas entre encaminadores MPLS. LDP es un protocolo abierto, aunque también se utilizan comercialmente protocolos como IGP, BGP y RSVP:

MPLS Control Plane

Es el plano de control, responsable de intercambiar información de rutas y etiquetas. El plano de control consiste en una LIB y una RIB, así como el ya mencionado LDP (o el protocolo de encaminamiento correspondiente). La LIB (Label Information Base) contiene todas las conexiones LDP, mientras que RIB (Routing Information Base) contiene las tablas de encaminamiento que veríamos utilizando el comando “show ip route”.

MPLS Data Plane

Es el plano de datos, responsable de reenviar paquetes basados en etiquetas y cabeceras IP. Los motores del plano de datos se llaman LFIB (Label Forwarding Information Base) y FIB (Forwarding Information Base). La LFIB es la tabla MPLS que contiene las etiquetas relacionadas con los prefijos IP y sus interfaces salientes; se usa para reenviar paquetes ya etiquetados. La FIB por su parte es la base de datos de reenvíos, una versión optimizada de la RIB.

Cabecera MPLS

El encabezado contiene los siguientes campos:

+ Label Value = valor de la etiqueta (20 bits)

+ EXP = indicador de CoS, Class of Service (3 bits)

+ S = BoS (Bottom of Stack, 1 bit), se utiliza para identificar la ¡ultima etiqueta. Si S=1, la etiqueta es la última de la pila.

+ TTL = Time To Live, indica por cuántos nodos puede pasar un paquete antes de ser descartado (8 bits)

Operaciones MPLS

Las operaciones MPLS se refieren a las operaciones que un router LSR puede hacer con una etiqueta:

• Push: agregar una nueva etiqueta
• Pop: quitar la etiqueta superior
• Swap: reemplazar la etiqueta más alta
• Multiple push: agregar varias etiquetas encima de los paquetes existentes
• Swap and Push: reemplazar la etiqueta superior y luego agregar otra etiqueta nueva en la parte superior
• Untagged (o “NO label”): la pila de etiquetas se elimina y el paquete se reenvía sin etiquetar

Cuando una entidad recibe un paquete etiquetado, hay 2 cosas que se determinan en la parte superior de la pila de etiquetas:

1) El siguiente salto así como interfaz de salida.

2) Qué operación de las anteriores realizará el LSR antes de reenviar.

La inserción de una etiqueta (push) la realiza normalmente el LSR de ingreso, mientras que las operaciones de intercambio como swap se realizan en los LSR intermedios. Sin embargo, la operación pop puede hacerse en el LSR de regreso, o también en el penúltimo salto (para implementar PHP o Penultimate Hop Popping, un proceso que pretende reducir la sobrecarga de búsqueda doble en el último nodo MPLS).

Transmisión básica de un paquete

Ahora ya estamos en condiciones de describir el paso de un paquete en redes MPLS:

El paquete enviado desde un router CE llega al router del proveedor PE y de ahí se reenvía al primer LSR de ingreso. Aquí el LSR determinará la clase equivalente de envío (FEC) y entonces insertará una o varias etiquetas MPLS. A continuación el paquete se envía al siguiente router del backbone MPLS según la información de ese túnel. Cuando un paquete ya etiquetado se recibe en un LSR intermedio, se examina primero la última etiqueta de la pila, realizando con ella alguna de las operaciones mencionadas (Push, Pop, PHP, Swap…).

Los encaminadores LSR de tránsito no examinan lo que haya debajo de la etiqueta MPLS; he aquí la razón de que MPLS sea independiente del protocolo.

Por último, en el LSR de regreso se retira la última etiqueta, consultándo el bit BoS. Ya sólo resta la carga útil o “payload”, sea un paquete IP o lo que haya por encima. Por tanto este último router debe contener la información de encaminamiento necesaria para que dicho paquete “desMPLSizado” pueda ser reenviado a su destino, que por ejemplo podría ser el router frontera PE del siguiente proveedor hacia el router CE de la red del destinatario.

Referencias y fuentes

+ Libros interesantes sobre redes MPLS.

+ Understanding MPLS Basics: https://ourtechplanet.com/understanding-mpls-basics%e2%80%8b/

+ Presentación:

La entrada Redes MPLS: entendiendo sus bases (casi desde cero) se publicó primero en BorrowBits.

• netstat – es una herramienta que muestra un listado de las conexiones activas de una computadora, sean entrantes o salientes: protocolo en uso, las tablas de rutas, las estadísticas de las interfaces y el estado de la conexión.
• lsof – es una herramienta de monitorización para Unix que se utiliza para mostrar todos los archivos de disco que mantienen abiertos los procesos, incluyendo los sockets de red abiertos, tuberías, etc.

Son herramientas bastante diferentes en su naturaleza, y sin embargo en este caso son igual de eficientes. Vamos a utilizar ambas para averiguar qué servicios está escuchando el puerto 80…

Utilizando netstat

En realidad lo único que estamos haciendo es aplicar el filtro de cadenas que contengan :80 a la salida de netstat -tulpn, que por sí solo muestra todas las conexiones abiertas en el sistema.

netstat -tulpn | grep :80

Utilizando lsof

Resulta que lsof tiene un modo especial para mostrar los procesos que escuchan un determinado puerto: se trata del parámetro -i. Con el filtro LISTEN nos aseguramos de que solamente se muestran los procesos “en servicio”. 

lsof -i :80 | grep LISTEN

Y esto es todo: hemos averiguado que, en este caso, el servicio que corre en el puerto 80 es nginx, un servidor web ligero de alto rendimiento.

Y vosotros, ¿conocéis alguna forma aún mas rápida de averiguar qué aplicaciones escucha un determinado puerto? Os retamos

La entrada Atajos Linux: cómo averiguar qué servicios corren en un determinado puerto se publicó primero en BorrowBits.

Hace unos meses os contábamos que existe, por así decirlo, un paso intermedio entre 4G y 5G que ya está empezando a comercializarse con el nombre de VoLTE (Voice over LTE). En resumen, este protocolo permite realizar llamadas de voz directamente sobre datos.  El principio de funcionamiento es similar a VoIP tradicional, con la salvedad de que en este caso el servicio se opera a nivel de red y no a nivel de aplicación. Es decir: no necesitaríamos aplicaciones como Skype, Viber o Whatsapp, ya que las llamadas de datos estarían integradas directamente en nuestro teléfono.

Durante algunos años, LTE coexistirá con las tecnologías de conmutación de circuitos de voz, también conocidas como Circuit Switch. No obstante, desde hace unos años los proveedores están reemplazando todos sus sistemas de conmutación de datos (Circuit Switched Data, CSD) por sistemas basados 100% en Ethernet. En esta coyuntura, es de esperar que tarde o temprano todas las llamadas de voz móvil se operen exclusivamente sobre datos.

Mientras tanto, muchos nos preguntamos cuál es exactamente la diferencia entre VoLTE y VoIP:

La diferencia está en la QoS

Tradicionalmente, las aplicaciones de voz como Skype han confiado en Internet para entregar los paquetes. Y esto es un mal asunto: la naturaleza intrínseca de Internet no garantiza la entrega de paquetes, y es por esto que se la conoce como una tecnología Best Effort: las aplicaciones que funcionan sobre Internet se ponen una venda en los ojos y cruzan los dedos.

No ocurre así cuando hablamos de VoLTE, ya que éste exige la presencia de un componente de Calidad de Servicio (Quality of Service, QoS).

¿En qué consiste la QoS?

QoS es un conjunto de tecnologías que garantizan la transmisión de cierta cantidad de información en un tiempo dado. Esto es: throughput. Es especialmente importante cuando hablamos de aplicaciones de tiempo real como voz y video.  Existen algunos problemas que afectan a la calidad del servicio y son los que QoS pretende resolver:

Paquetes sueltos

Los routers pueden sufrir pérdidas de paquetes si llegan cuando los buffers ya están llenos. Dependiendo del estado de congestión de la red, se podrían perder uno o muchos paquetes. Un problema que podría solventarse mediante la solicitud de retransmisión de paquetes sueltos por parte del receptor. Como es fácil suponer, esto provoca la aparición de graves retardos.

Retardos

Puede ocurrir que los paquetes tarden un largo período de tiempo en alcanzar su destino, debido a que pueden permanecer en largas colas o tomen una ruta menos directa para prevenir la congestión de la red. En algunos casos, los retardos excesivos pueden llegar a inutilizar las aplicaciones VoIP.

Jitter

Los paquetes del transmisor pueden llegar a su destino con diferentes retardos. Un retardo de un paquete varía impredeciblemente con su posición en las colas de los encaminadores a lo largo de la ruta entre el transmisor y el destino. Esta variación en retardo se conoce como jitter y puede afectar seriamente a la calidad del flujo de audio y/o vídeo.

Entrega de paquetes fuera de orden

Cuando un conjunto de paquetes relacionados del mismo flujo son encaminados hacia Internet, los paquetes pueden tomar diferentes rutas, resultando en diferentes retardos. Básicamente, esto ocasiona que los paquetes lleguen desordenados. Para solventar este problema requerimos de un protocolo que pueda reordenar los paquetes a un estado isócrono una vez que estos lleguen a su destino.

Errores

Los paquetes y los políticos tienen algo en común: algunos se corrompen durante su trayectoria. En este caso, el receptor tiene que detectarlos y solicitar una retransmisión de los mismos.

¿Cómo se implementa QoS en VoLTE?

VoLTE utiliza una combinación de la arquitectura IMS (IP Multimedia Subsystem) y la alta velocidad de la red de acceso (Radio Access Network) para garantizar la QoS. En ese sentido, la calidad de las llamadas VoLTE no tienen nada que envidiar a las llamadas tradicionales basadas en circuitos E1 o T1, y es por esto que se espera que VoLTE desplace a VoIP, al menos cuando nos referimos a dispositivos móviles.

¿Cómo se implementa QoS en sistemas VoIP?

Sin embargo, si de algo se echa de menos en VoIP es la calidad de los sistemas telefónicos tradicionales. Este componente QoS, al contrario que ocurre en VoLTE, se puede implementar en VoIP como una característica opcional y no como una condición necesaria. Existen múltiples técnicas para implementar QoS a nivel de interfaz en VoIP (a nivel de una red global no es posible, en tanto que usa Internet como hemos mencionado anteriormente):

Este es un modelo que es bastante útil para comprender de qué formas podemos intentar garantizar la QoS y con cuáles conseguirlo. En esta figura están representadas las dos acciones fundamentales asociadas a garantizar la QoS:

• Clasificación: El tráfico que entra al equipo y que se ha de transmitir se tiene que clasificar. Pueden usarse muchos criterios de clasificación: Por equipo destino, por marcas en los paquetes, por aplicación… Es algo que siempre hay que hacer ya que si no el propio concepto de QoS no existe. Básicamente, la clasificación es buscar a qué parámetros de QoS negociados o contratados pertenece un paquete (o tráfico) en particular: Tráfico máximo en ráfaga, tráfico mínimo sostenido, latencia máxima, variación en la latencia…
• Asignación de recursos: Una vez que se tiene el tráfico clasificado, y por tanto se saben qué parámetros de QoS se deben cumplir, hay que asignar los recursos en la interfaz. Hay que permitir que los paquetes se transmitan al medio (el aire o un cable).

La fase de clasificación es común a todos los tipos de interfaz que necesitan garantizar la QoS, pero la principal diferencia viene en la fase de asignación de recursos. Existen 2 mecanismos que son lo bastante amplios como para merecer que les demos un nombre “QoS a nivel 3 (L3QoS o IPQoS)” y “QoS a nivel 2 (L2QoS o MACQoS)”.

Existen múltiples estándares y sistemas VoIP profesionales implementados mediante software o hardware que en gran medida tratan de controlar el tráfico de la red para disminuir las posibilidades que se produzcan caídas en el rendimiento.

Como conclusión…

Incluso si los mecanismos para garantizar la QoS en VoIP fueran iguales a los de VoLTE (algunas arquitecturas VoIP implementan IMS), aún tendríamos la ventaja de que éste último ofrece una red de acceso radio y un backbone diseñado especialmente para transportar datos de forma mucho más eficiente que la red IP tradicional.

La entrada VoLTE vs VoIP: la diferencia está en la QoS se publicó primero en BorrowBits.

El estándar Wi-Fi (IEEE 802.11) puede operar básicamente en dos modos:

• Infraestructura (o “managed”), en el que los clientes se conectan a un punto de acceso o router.
• Ad-hoc, también llamado punto a punto, en el que los clientes se conectan entre sí sin ningún punto de acceso.

En el modo ad hoc cada equipo actúa como cliente y como punto de acceso simultáneamente. El rango de esta red está determinado por el de cada estación: ¿y qué significa esto?

Que si dos estaciones de la red están fuera del rango de la otra, no podrán verse a menos que exista un protocolo de descubrimiento + encaminamiento. Aquí es donde entra en juego la importancia de las redes MANET, como ya hablamos en su momento.

Es bien sabido que a día de hoy Android es el sistema operativo móvil líder, con cerca del 80% de la cuota de mercado. Y sin embargo, a la hora de establecer redes ad hoc presenta un enorme inconveniente:

Android tiene deshabilitado el modo ad hoc por defecto. Y no hay expectativas de que esto vaya a cambiar. Es decir, sólo permite operar en modo “managed”.

Ya os podéis imaginar el quebradero de cabeza que supone para los desarrolladores (como un escribiente servidor) que tratan de implementar redes MANET, redes Mesh o redes de sensores en Android.

Android en el fondo sólo es Linux

Ya sabéis que lo que hay bajo Android es Linux puro y duro. Sin entrar en detalles, Android por sí mismo no es más que una gruesa “capa” que envuelve al kernel de Linux ofreciendo una serie de librerías y un completo entorno de ejecución (Android Runtime) que funciona a golpe de máquinas virtuales Dalvik (Dalvik Virtual Machine, DVM), que ejecutan código Java.

No obstante, el lenguaje subyacente (el del núcleo de Linux) sigue siendo C. Esto significa que podemos “bajar de nivel” y escribir código en dicho lenguaje gracias a la Interfaz Nativa de Java (JNI), que permite ejecutar código C/C++ desde una aplicación Java.

¿Configurar un adaptador de red con iwconfig?

Así pues, podríamos pasarnos por el forro las restricciones que impone el framework de Android y ejecutar comandos de Linux que nos permitan configurar el adaptador inalámbrico vía JNI, como es el caso del clásico comando iwconfig.

iwconfig ath0 mode ad-hoc

Sin embargo para poder usar el comando iwconfig de Linux nuestro dispositivo debe tener soporte para la API de extensiones Wireless. Por desgracia, normalmente sólo los dispositivos que usan un chips de Broadcom soportan dichas extensiones, con lo cual muchos modelos se quedarían fuera de nuestro alcance (Samsung Galaxy Nexus, Asus EeePad Transformer y Motorola Razr Maxx, por citar algunos). Pero incluso aunque Samsung y ASUS hayan liberado el código de su kernel a la comunidad open-source, dista mucho de ser una solución universal. Así pues, sólo cabría estudiar los diferentes casos que nos pueden presentar los modelos existentes en el mercado y discernir entre cada uno de ellos para implementar el comando adecuado. Una tarea poco escalable y de difícil mantenimiento.

¿Rootear el dispositivo? Una solución nefasta

A esta pobre solución se le añade un impedimento más: para habilitar la ejecución de comandos del sistema necesitamos “rootear” el dispositivo. Esto implica modificar nuestra tablet o smartphone para poder adquirir privilegios de superusuario (root), lo cual se puede hacer mediante la instalación de un sistema operativo modificado o “Mod”. Las consecuencias de rootear el dispositivo son nefastas:

• Posible pérdida de datos
• Pérdida de garantía por parte del fabricante
• Inestabilidad y agujeros de seguridad

Y aún así algunos proyectos MANET actuales tratan de implementar redes ad-hoc siendo el rooteo un requisito indispensable, por ejemplo el proyecto SPAN de Mitre o B.A.T.D.R.O.I.D.

El panorama es desalentador. Así que cabe preguntarse: ¿existe una solución mejor? ¿Podemos implementar redes ad hoc sin necesidad de rootear nuestro dispositivo? La respuesta a esta pregunta aquí.

La entrada El problema de desplegar redes ad hoc en Android OS: ¿rootear el dispositivo? se publicó primero en BorrowBits.

Imaginaos que un tsunami o un huracán se lleva por medio todas las antenas y estaciones base del operador móvil (Movistar, Vodafone, Orange…) dejando toda tu ciudad incomunicada, sumida en el caos, a merced de los malos y dificultando las operaciones de rescate. ¿A quién hemos de llamar? A Batman, por ejemplo.

No, no me refiero al superhéroe murciélago, sino a B.A.T.M.A.N (Best Approach To Mobile Adhoc Networks), un reciente protocolo de enrutamiento móvil empleado en las denominadas redes MANET (Mobile ad hoc Networks).

¿Y qué es una red MANET?

En pocas palabras, son redes móviles cuyos nodos se conectan entre sí mediante tecnología Wi-Fi ad hoc y que poseen completa libertad para desplazarse geográficamente, por lo que se trata de una topología de red muy dinámica, cambiante y descentralizada. Por esta razón, cada nodo (o smartphone) debe realizar por sí mismo tareas de router como localizar a sus móviles vecinos, mantener tablas de rutas, decidir cuál es el mejor camino, etc.

Ello nos permitiría realizar llamadas gratis (como VoIP) o enviar mensajes de texto sin necesidad de operador móvil, por lo que es una implementación muy útil para situaciones de emergencia o desastres naturales. ¿Significa esto “bye-bye Movistar”? Esa es otra historia que ya discutiremos en otra ocasión.

Vale, ¿pero cómo funcionan?

Durante los últimos 30 años se han desarrollado decenas (¿cientos?) de protocolos para prácticamente todos los escenarios. BATMAN entre ellos. No entraremos en detalles escabrosos, así que aquí va una explicación un tanto burda de qué es un protocolo de routing:

Es el mecanismo que permite a cada nodo conocer “dónde” se encuentra dentro de la red en relación a sus vecinos para así poder encaminar (o “enrutar”) de forma eficiente un mensaje o llamada saltando de nodo a nodo hasta llegar a un destinatario.

En una red local o LAN como la que tenemos en nuestra casa no hay muchos cambios en la topología, sin embargo en una red móvil constantemente aparecen y desaparecen nodos que no contentos con ello cambian de ubicación a cada segundo

¿Entonces cómo puede conocer un móvil la topología de la red, si está en constante cambio?

En redes ad-hoc los nodos no conocen a priori la topología de su red, por lo que primero tienen que descubrirla. En este concepto reside la complejidad del encaminamiento en redes MANET:

La idea es que los nodos móviles anuncian su presencia periódicamente con un paquete broadcast de saludo. Los vecinos escuchan estos saludos y poco a poco van aprendiendo y actualizando nuevas rutas: “le paso mi mensaje al nodo A, que dice que conoce a un nodo B, que a su vez conoce al destinatario C“. Para lograr esto, las tablas de encaminamiento deben ser propagadas o intercambiadas periódicamente.

Para terminar, ¿cuántos protocolos de enrutamiento MANET existen?

Muchos. Pero se pueden clasificar en unos pocos grupos:

1. Proactivos. Estos protocolos mantienen una lista actualizada de destinos y rutas que redistribuyen periódicamente a través de la red con las desventajas que ello conlleva en términos de mantenimiento y velocidad de reacción ante cambios o fallos. Algunos ejemplos: el mencionado BATMAN y OLSR (Optimized Link State Routing Protocol).
2. Reactivos o bajo demanda (“on-demand”). Como su nombre indica, estos protocolos “inundan” la red con peticiones de ruta (paquetes “Route Request”) con los problemas de latencia y congestión que pueden provocar. Algunos ejemplos son AODV (Ad hoc On-Demand Distance Vector) o su sucesor: DYMO.
3. Híbridos. Estos protocolos tratan de superar las desventajas de los anteriores de la siguiente forma: en una primera etapa se comporta como un protocolo proactivo y más tarde, cuando ya ha descubierto algunas rutas, empieza a actuar como uno reactivo. Un ejemplo: ZRP (Zone Routing Protocol).
4. Jerárquicos. Son protocolos híbridos, pero en otro sentido. Pueden enrutar proactiva o reactivamente en función del nivel jerárquico en que se encuentren dentro de la red. Ejemplo: CBRP (Cluster Based Routing Protocol).

En próximos artículos veremos que no todo el monte es orégano y profundizaremos en este interesante y novedoso campo de las telecomunicaciones aplicado a smartphones Android.

La entrada Las bases del encaminamiento MANET: en caso de emergencia avisar a BATMAN se publicó primero en BorrowBits.

El objetivo de esta serie de artículos es compilar dentro de la nueva sección Herramientas PFC todas aquellas herramientas que puedan hacer falta para desarrollar un proyecto de Telecomunicaciones o Informática, por lo que os pedimos vuestra colaboración para seguir engrosando y actualizando la lista. Sin duda, será de gran utilidad para muchos compañeros, de prácticamente cualquier ingeniería. Salvo ineludibles excepciones, trataremos de seleccionar aplicaciones Open Source por razones obvias.

A raíz de ello, iremos también ampliando las aportaciones con artículos detallados, reviews de aplicaciones o minitutoriales particularizando algunos tipos de proyecto que podréis identificar por la etiqueta #HerramientasPFC. Por ejemplo, herramientas y tutoriales para desarrollar un proyecto en Android (como es mi caso), para un proyecto sobre redes de sensores (como es el caso de visego), y así sucesivamente con las experiencias de todos nuestros colaboradores internos o externos.

Si la idea os parece motivadora y estáis interesados en colaborar sólo tenéis que comentar este artículo, aunque siempre estaréis invitados a participar desde el backend con vuestra cuenta de colaborador. Podéis solicitarla enviándonos un e-mail a esta dirección.

Periódicamente iremos informando de las actualizaciones en nuestra cuenta de twitter o en mini-entradas desde este mismo blog. ¡Hasta muy pronto!

La entrada Nueva serie: Herramientas imprescindibles para un proyecto de TIC se publicó primero en BorrowBits.

Hoy voy a hablar un poco del GPS (Global Positioning System), todos asociamos el GPS a no perdernos por una ciudad. Y creemos que con un mapa solventaríamos la ausencia de este sistema, pero no es así…

En 1973 la Armada estadounidense, y las Fuerzas Aéreas de este mismo país unificaron sus fuerzas para desarrollar este sistema de navegación. Entre 1978 y 1985 se lanzaron 11 satélites experimentales (NAVSTAR), a los que fueron sucediendo otras generaciones de satélites hasta completar la constelación actual.

GPS se basa en la determinación de una posición a partir de la señal recibida de 24 satélites, divididos en 6 planos orbitales. Si conocemos la posición de un satélite y calculamos el tiempo que tardamos en recibir su señal (mediante cálculos sobre efecto Doppler), podemos saber a que distancia nos encontramos de él. Si este cálculo lo realizamos sobre tres satélites, podemos triangular nuestra posición.

Aunque parezca una idea fácil, diseñar y desarrollar hace más de 30 años un sistema que con la precisión que conocemos actualmente es uno de los mayores logros de la humanidad. Pero no todo es positivo.

GPS emite varias señales, unas de uso civil, y otras de uso militar. La señal de uso civil, es la que utilizamos en nuestros navegadores. Además se usa para entre otras cosas, sincronizar antenas de telefonía. Al ser un sistema muy extendido, poder sincronizar las comunicaciones entre centrales de conmutación mediante GPS ha abaratado y extendido la cobertura y  la capacidad de las comunicaciones móviles.

Pero esta señal civil, tiene un ruido agregado a propósito, con el objetivo de poder aumentar el error en una localización. Imaginémonos que estamos en Irak, si disponemos de la señal militar (indescifrable), podemos conocer la localización de nuestras tropas con una precisión de centímetros (mucho mayor que la señal civil). Mientras que si usamos receptores comunes, o nuestros misiles se guían por GPS civil, nos equivocaremos tanto o más como quieran los que controlan el sistema.

Pero podemos ir más allá, pueden literalmente apagar la señal GPS. No sabemos medir con certeza los efectos que puede tener esto en el mundo occidental. Posiblemente la red de telefonía movil se inutilizaría, se imposibilitaría la comunicación vía internet en amplias zonas geográficas, y en unas bases de datos cada vez más centralizadas, nos imposibilitarían por ejemplo sacar dinero en un cajero. Lo que hoy en día puede ser un desastre total. Una guerra civil a nivel mundial.

Ante esta realidad, Europa respondió proponiendo Galileo (que con la crisis, ni se sabe que pasará). EEUU respondió firmando un acuerdo de que jamás apagará el GPS de uso civil. Básicamente estamos indefensos ante un poderío tecnológico del que no nos hacemos una idea real. Es tal la supremacía, que aunque simplemente no desplieguen un ejercito, tienen el control de medio mundo.

Esperemos que no tengamos que ver el poder del GPS, y simplemente disfrutemos de su uso, pero la reflexión queda ahí.

Nota: La ilustración anterior es de Pawła Kuczyńskiego, un dibujante polaco cuyas obras son asombrosas, podéis visitarlas en http://capu.pl/node/271

La entrada ¿Navegamos? se publicó primero en BorrowBits.